KEPServerEX v5 OPC and Communications Server Features

KEPServerEX v5 is the next generation of Kepware communications technology and represents over 10 man year's worth of development, delivering both architectural and feature enhancements. KEPServerEX v5 is

the most advanced communication technology and OPC Server on the market and will remain the foundation for future Kepware development. As a result of our new licensing utility, Kepware is providing new vertical driver suites including Building Automation, Oil and Gas, and Water and Waste Water to name a few.

KEPServerEX v5 has been re-designed from the ground up to take advantage of new technology, and is positioned to move onto new automation platforms while delivering legacy compatibility.

Features:

OPC Connection Security

The Secure by Default feature enables users to select whether or not the server should respect the DCOM security settings as they appear in the DCOM Configuration Utility. When this setting is enabled, users can select the authentication, launch and access security requirements through the DCOM Configuration Utility. This allows users to specify the level of security they want to implement and also restrict access for certain users and/or applications.

When this setting is disabled, the server will override the DCOM settings set for the application and will not perform any authentication on the calls received from client applications. It will impersonate the security of the client when performing any actions on behalf of the client application.

Process Mode

KEPServerEX runtime Process features are used to specify how the servers runtime process mode will operate and utilize PC resources. It is used to specify whether the server will be running as System Service or Interactive.

KEPServerEX also allows you to set its own process priority giving the server priority access to resources.

Processor Affinity

This parameter allows the user to specify which CPUs the server can be executed on when it is run on PCs containing more than one.

Host Name Resolution

KEPServerEX allows for host name resolution which is an alias assigned to identify a TCP/IP host or its interfaces. Host names are used in all TCP/IP environments and user can specify host name instead of an IP address when using KEPServerEX v5.

OPC UA (Unified Architecture)

KEPServerEX supports OPC UA Client Connections and the OPC DA data set.

OPC AE (Events)

KEPServerEX exposes event log data (Events) to OPC AE Client applications. The Event server works in runtime and service modes supporting 3 Event categories (Information, Warning, Error). KEPServerEX also supports AE client filtering by event type, severity, and category and is OPC Compliant.

Server Administration Properties

The User Management system of the server controls what actions a user can take within a server project. The User Properties dialog is used to configure the name, password and privileges available for each account.

Multiple Tag Generation Utility

Quickly and dynamically construct multiple tags using the KEPServerEX driver nomenclature. It will allow for a wide variety of address formats such as ranges utilizing hex, octal, decimal, and binary number systems. It will also include the ability to increment the user selected data-type to avoid data overlap.

 Other Features:

1. Auto Demotion
2. Automatic Tag Database Generation
3. Ethernet Encapsulation
4. Modem Support (PDF)
5. Application Connectivity
6. OPC Quick Client
7. 2 Hour Free Demo

KEPServerEX v5 is designed to allow quick and easy configuration of your communications.

1. Select a driver to create channel
2. Specify the device or system to communicate with
3. Select the items or tags for your database

Evaluation of software: Buying /licensing software development environment

If you are in the buying process of an IEC 61131-3 development environment, there are nowadays a large number of (independent software) suppliers to choose from. To make your selection process easier, the following topics can help you in the evaluation. They are not so much technical details, but additional topics which should be evaluated. 

First: there is no best overall product. A product should meet your needs, which means that you have to evaluate it. Below are some guidelines for it. 

Even if there is a best product nowadays, it can be surpassed with a new release of a competitor. Also, the actual status of the software product itself can be of minor importance: a next version is probably around the corner.

Points of attention:

	adaptation costs: how much do they ask to adopt the package to your hardware? How much to include your additional hardware and /or software libraries
	the initial costs are different. In most cases the software environment needs adaptations. These can range over a broad area:
	the name of the product as appears on the screen the adaptation to your specific hardware environment the adaptation of the user manuals to you needs the creation of user manuals under your own name the inclusion of additional requirements, like linking to your specific compiler

	licensing: besides the initial adaptation costs, licensing can be applicable. How much doe they charge? How much for a one time buy-out? Do the royalties include future updates?
	strategy to deal with minor and mayor updates
	the quality of the software and training manuals, and there availability in the required languages
	is the products itself, including the on line help functions, available in the required languages
	support: they all claim it, but who provides it best, and in your language. And at which costs. What is their strategy with respect to dealing with errors, minor and mayor
	training: can they provide on-site training for your people. Can they help your users. How does their training manuals look. In which language are they? Can you use their material as basis for your own training?
	Update: how do they deal with updates? How do you deal with updates?
	does the system provide on-line help? In which languages? Does that cover your needs
	is the company financial stable?
	which references / installations does the company have? Do they include your competitors? Does that help you? Can you contact some of their references?
	how well can the company cope with your future architectures? Do they support distributed systems, if needed?
	if you have existing code which you want to include, can they support you? Does the environment support it? How well does it match? How much effort is estimated by them and by you to do the job? Are they willing to do it (at fixed costs), showing confidence and giving you a guarantee? At which costs? Which time frmae
	can they provide an evaluation package?
	how fast are they in their response?
	do they speak your language, not only in your home language, but also do they know your environment?
	is the product certified by PLCopen? At which level? For which language? How many updates after their certificate? Can they show (a copy of) the certificate?
	can they provide a compliance statement by sending the IEC 61131-3 feature tables showing clearly what they support?
	what are your main (expected) programming languages for this environment? How long are these languages supported? Which release are they on?

Remember: you don't want to be the guinea pig: testing takes time and costs money. 

A good way to get started:

1. describe your (initial) requirements clearly on paper, including quotation procedure and deadline
2. send to all potential suppliers, minimal 5, preferably on the same day (fax)
3. note when the quotations get in, giving you a first impression of response speed
4. compare the overall quality of the offer
5. compare the fulfilment of your requirements
6. check the differences
7. talk to at least 3 companies

IEC 61131-3 (PLC Programming Languages)
This document is a compilation of responses by the Experts of IEC TC65B/WG7/TF3 task force to Frequently Asked Questions (FAQs) about the IEC Standard 61131-3. The contents of this document are not normative and do not form a part of the Standard. 

Will IEC 61131-3 reduce the innovation of new languages and concepts for PLCs? The main objective of IEC 61131-3 has been to standardise existing PLC languages. There is no intention that IEC 61131-3 should reduce the development of new PLC languages. Any PLC vendor is free to provide extensions and additional languages where required. Because the standard allows proprietary function blocks to be programmed in non IEC 61131-3 languages such as C++, it always possible to provide extensions fairly 'seamlessly' e.g. packaged as function blocks. This is well demonstrated by IEC 61131-7 "Fuzzy control programming" which defines language extensions for implementing fuzzy logic encapsulated as function blocks.

Why does IEC 61131-3 have 'resources'? Is a resource just another name for a PLC? A resource is a general name for anything that is able to provide the appropriate access to I/O and services to allow IEC 61131-3 programs to execute. Normally a PLC that can execute IEC 61131-3 programs can be regarded as a single resource. However, other processors, such as a personal computer (PC) if able to support the execution of IEC 61131-3 programs may also be regarded as resources.

IEC 61131-3 seems to be very complicated. Is it still possible to create simple Ladder programs by users unfamiliar with IEC 61131-3?  An IEC 61131-3 system can still be programmed as a single Ladder program if required. Programming systems may provide a option to create a simple IEC 61131-3 configuration containing one resource, one task, and one program instance of a program type. All of this could be created automatically so the user is only concerned with developing a single ladder program. Function blocks and other IEC 61131-3 constructs do not need to be used.

	Will IEC 61131-3 languages result in applications that run more slowly and require more memory than using simple ladder? Attempting to implement IEC 61131-3 constructs such as function blocks on PLCs that were originally only designed to support ladder programs, will inevitably have performance and memory overheads. PLCs specifically designed with firmware to support the execution of IEC 61131-3 programs should not be noticeably slower than classical ladder based PLCs. The improvements in software structure from IEC 61131-3 should allow users to be able to write more efficient applications that will be significantly easier to maintain than monolithic ladder programs.
	Is it really possible to port IEC 61131-3 software from one vendor's PLC to another? possible No it is not simply to take an application that runs on one type of PLC and copy it over to another type. There are several problems preventing the direct porting of IEC 61131-3 software. The PLC I/O systems use different addressing schemes. The task scan rates supported on different PLCs vary. Each PLC vendor may have implemented a different sub-set of IEC 61131-3 features. Similarly each vendor may have different values for implementation specific parameters such as maximum array sizes, string lengths etc. Finally there is not a standard file format in which to store and port IEC 61131-3 applications. Notwithstanding these constraints, at the function and function block level, it may be possible to re-implement identical POUs on different vendors PLCs. Textual source code for POUs developed in ST or IL can be ported between different types of PLCs.
	Is it possible to automatically convert between IEC 61131-3 languages, for example, can a POU written using LD be viewed and edited in ST or FBD? This is a favourite IEC 61131-3 myth. There has never been any intention that it should be possible to convert any language into any other language. If a restricted sub-set of each language is used some limited portability may be possible but there are some significant problems. For example, there is no way to represent expressions involving array variables in the FBD language.
	Can function blocks also have execution control variables EN and ENO, like functions?  The standard is not explicit about whether function blocks may have execution control variables, e.g. for connecting function blocks within ladder rungs. However, from the IEC 1131 languages user guidelines, (part 8 of the IEC 61131 standard), it is implied that for consistency, both functions and function blocks should use EN and ENO variables for execution control in ladder diagrams. It is an implementation decision whether function blocks have EN and ENO variables that can be used in the FBD language for explicit execution control. This may be useful in eliminating execution order ambiguities that might arise in FBD networks.
	In a full graphic implementation of FBD, is there anyway to distinguish between lines that cross-over and lines that join. The graphical format of lines, cross-overs and junctions in full graphics implementations of languages LD, FDB and SFC is not specified in IEC 61131-3. It is a implementation decision outside the scope of the standard how fine graphic details such a line cross-overs are depicted.
	Where are type definitions actually defined and what is their scope? All type definitions for datatypes and POUs can be regarded as outside the entire IEC 61131-3 configuration and apply to all entities within the configuration, i.e. all type definitions have global scope. This is as if all type definitions exist in a conceptual 'header file' that is pre-processed before any entity within a configuration is compiled. Extensions to IEC 61131-3 are now being considered to provide a more flexible range of type scopes. With large applications, more specific type scopes may be necessary, such as, a library scope for type definitions that only apply to POUs within a specific library.
	Do IEC 61131-3 languages enforce data type consistency? All IEC 61131-3 languages except IL, enforce strict data type consistency, i.e. it is not possible to directly assign (or connect) variables of one data type to variables of different data types. Data type conversion functions are necessary to convert the values of variables to the appropriate type, e.g. an INT value should be converted to a REAL before being assigned to a REAL variable. In the IL language, it is not always possible for a compiler to check that the type of value in the accumulator will match the data type of any variable to be loaded from the accumulator. With IL, run-time checks are required to ensure data type consistency.
	When are the actions in an SFC actually executed? Every SFC is encapsulated in a function block or program POU. When the POU is invoked, e.g. because it has been scheduled by a task, the contained SFC is evaluated once, i.e. The current set of active steps is determined. All transitions associated with active steps are evaluated Actions which nominally ceased execution in the previous SFC evaluation ( because their Q flag has been cleared ) are executed one last time. All actions that are active are executed once. Any active steps that precede transition conditions that are true are deactivated and their succeeding steps are activated. The encapsulating POU should be repeatedly invoked for the SFC to progress through its various steps.
	How can the execution of all actions in an SFC be halted and the SFC restarted? The execution of all actions in an SFC can be halted by suspending the invocation of the encapsulating POU, see When are the actions in an SFC actually executed? If, at a later time, the POU is again repeatedly invoked, the active actions in the contained SFC will continue to be executed. The only way to re-start an SFC from its initial step and clear all active actions is for the resource containing the POU to have a 'cold start'. A jump back to the initial step is always possible using an explicit branch, e.g. back from the last step in a sequence. However, this cannot guarantee to clear any stored actions or simultaneous sequences which may be been started.
	Can more than one variable be fixed at the same direct address using the AT construct? The standard does not forbid this. Allowing variables to be at the same or to use overlapping memory locations is an implementation issue. This however may invalidate data type consistency - see Do IEC 61131-3 languages enforce data type consistency?.
	When using the AT attribute, does the size of a memory location specified by a direct address have to match the size of the variable? The standard is unclear; there are two ways of interpreting the purpose of the direct address. It either specifies a) the actual memory location, in which case the location size and variable type size should match or b) the starting address from which the variable will be located, in which case sizes do not need to match.
	When are user specified initialisation values for variables used? User specified initial values apply to non-retentive variables both at "cold restart" and "warm restart", but they only apply to retentive variables at "cold restart". On "warm restart" retentive variables have the same values as existed when their resource stopped executing, e.g. due to a power outage. The 61131-3 amendment allows initialisation values defined by the VAR_CONFIG construct to override type specific initial values. Therefore, VAR_CONFIG specified initial values apply at "cold restart" or "warm restart" for non-retentive variables, and to "cold restart" for retentive variables.
	Can function block instances be passed as inputs to other blocks?  Yes if function block FB1 is passed as an input to a second function block FB2, it is possible to invoke the function block FB1 within the body of FB2. Any input parameters of FB1 not defined in the invocation call within FB2 will take values defined by earlier invocations of FB1 made outside of FB2. Function block instances should be passed as VAR_IN_OUT parameters otherwise the values produced within the internal invocation will not be preserved.
	Are the assignments of inputs and outputs to programs at the resource level fixed or can they change dynamically? They are fixed. Programs are the highest level IEC 61131-3 programmable organisation unit. It is not possible to have language statements outside of a program. In a resource declaration it is only possible to assign input and output variables to the program interface. If it is necessary to change the inputs used by part of a program, then all inputs concerned should be passed to the program and any dynamic selection of particular inputs should be done within the program body, e.g. to switch between using two different sets of sensors.

How to recognize an IEC 61131-3 Programming System in 8 easy steps

1. There is a solidly defined range of Standard Data Types, which exactly specifies how the content of a variable has to be interpreted.
   

Advantage: Thereby, that for each datatype only certain operations are allowed (e.g. mathematical operations for numerical data-types and not for bit-patterns), the program-security and the overview are improved. 





2. The possibility exists to define Derived Data Types like Fields and Structures.

Advantage: the programming system supports possibilities as used in PC-High-Level-Languages. Matching data can be meaningfully grouped, and securely and easily used.

3. User-programs can be subdivided in exactly defined structuring elements, the Program Organization Units (POU) Program, Function and Function Blocks.
   

Advantage: The problem can be structured into sub tasks, making it much clearer than "spaghetti-programs." The spin-off of recurrent sub-tasks into own function blocks save in the programming effort.

4. All Program Organization Units (POUs) can contain local data, i.e. data, which are only known and usable within this POU. This principle of data encapsulation stems also from the modern programming languages.

Advantage: A real decomposition of the work is possible, because the programmers do not need a on going coordination with respect to variables. Eroniuos overwriting of variables is hardly possible anymore. POUs are adress-independent and can be reused without any problems (see also point 5 and 6).

5. For the data-exchange between POUs there are well defined interfaces. Type and scope of the transfer are unambiguously defined.

Advantage: Recurrent functionalities can be transferred to libraries of Functions and/or Function Blocks. They are usable like "Black Boxes", therefore without knowledge of the internals, like Integrated Circuits with dedicated connections. 



6. Functions and Function Blocks become pure symbolic, i.e. address and module independent programs.

Advantage: Through the connection between local data and pure symbolic programming, no unexpected interference between user-programs can occur. Function and Function Blocks are independent of the target system, and in many cases even independent supplier, and so reusable (see also point 8).

7. The used programming languages comply to those as specified within IEC 61131-3, i.e. comply with the unambiguously defined syntax and semantics. In addition, the standard Functions and Function Blocks are supported.

Advantage: users, having learned the languages and commands of the standard, can use this knowledge on different programming systems. The training-expenditure is reduced; users and especially service personnel meet a world-wide comprehensible and unified programming system. Programs and program parts can be used across systems.

8. The Programming System is certified to one of the PLCopen defined compliancy levels, i.e. by an independent test-institute on conformity with the IEC 61131-3 standard.

Advantage: The user is assured that the used programming system complies to the standard, that he can reuse his knowledge with respect to IEC-programming and that the system is future-proof. With the certification at Portability Level he can exchange the Functions and Function Blocks, written compliant to the standard, with the common file-exchange-format with other certified systems, therefore saving time and money.