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. 

Status of the Standard IEC

Enhanced IEC 61131-3: Proven standard fit for future

The international standard "IEC 61131-3" was released in 1993 and, since its adoption, has become widely accepted by the international user and vendor community. Today, it is, as such, the worldwide recognized standard for programming and configuring industrial control devices. The popularity of IEC 61131-3 in the industry is evident. The world’s leading industrial control manufacturers have adopted the programming model for a wide range of controllers; various software companies offer compliant development tools; and the standard is certainly the world’s leading paradigm for industrial control languages. The success of PLCopen and its increasing number of members prove this, too.

Why then revise a successful standard ?

There are, however, several reasons why the standard must be revised: First of all, since 1993 a great deal of practical experience has been gained in which a number of inconsistencies and contradictions have been detected. These include inconsistent definitions and features which are needlessly complicated. Several of these inconsistencies strongly prevent one of the most important objectives of PLCopen, namely the language portability to various PLC types. In order to remedy this, many users of the standard proposed revisions and enhancements. These can be found in the Addendum and in the Corrigendum as belonging to the standard. In addition, the demands on industrial control systems and their engineering environments have considerably changed over the years, where the most important item is the migration of large centralized control systems towards distributed systems. IEC 61131-3 exclusively applies to local controllers including their communication interfaces to other local systems, not the programming of distributed systems. That is why the reciprocal integration of the IEC 61131-3 programming languages with IEC 1499 (the new architectural model for distributed industrial process measurement and control systems) is absolutely necessary. Only through this, long-term company investments in control systems can be assured.

This is the reason why IEC 1131 is now being revised in three stages, each summarized below:

1. "Corrigendum": correction of errors.
2. "Amendment": more consistent structuring of the standard accompanied by additional implementation of features required in everyday controls situations.
3. Harmonization between IEC 61131-3 and IEC 1499.

In the course of this, the major goal to maintain upward compatibility for all amendments. This means, a control program which complies with the previous standard is also expected to comply with the new standard without conflicts.

Stage 1: Corrigendum

The initial stage exclusively eliminates hard errors and non-compliances within the existing standard. In addition to correcting misprints, this especially resolves semantic discrepancies in the main section and inconsistencies between the main section and appendices. During last four years, the IEC task force collected, evaluated and adapted the relevant modifications. This occurred with the active assistance of numerous experts, especially from the PLCopen group. None of the changes shall cause incompatibility.

Stage 2: Amendment

The second stage extends beyond a pure revision of errors and defines improvements to the standard. These include two main points. Firstly, the chapter concerning the programming language "Instruction List" has been reworked in order to remove existing inconsistencies. Secondly, the definition of functions is revised. The possibilities of using parameters with functions are too inflexible in the existing IEC-1131, sometimes resulting in awkward constructions. Moreover, the usage of "Enable Input/Output" has caused substantial confusion. This will be revised in the new release, and a serious stumbling block will have been overcome in the effort toward portable control programs. A number of less significant amendments still complement these two main points. They are, for the greatest part, upwards compatible with the present standard. The main objective of these amendments is to increase the acceptance of 1131-3 languages by the application programmers through unified and practice-orientated language constructs. In this relationship, enhanced utilization of the control hardware is to be achieved. In addition, IEC increases actual semantic portability for control programs, eliminating interpretation latitude for particular language constructs.

Stage 3: Harmonization with IEC 1499

The last stage of the intended revision concerns the desired harmonization with the architecture standard IEC 1499 – ”Function Blocks”. This standard for distributed industrial control systems does not define its own specific programming languages for algorithms. The languages contained in IEC 61131-3 are used instead, since they are best suited in modified or enhanced form for many industrial application domains. Again, the most important guideline for developing these revisions even in this case, is, to ensure as much upward compatibility as possible. Harmonization with IEC 1499 will open many opportunities for IEC 1131 and, thus, continue to increase its acceptance.

Current state

The corrections and amendments were reviewed and modified in the first half of 1998 by the international IEC 61131-3 task force. It circulated as Committee Draft in 1999. It collected many comments, and will be circulated as Committee Draft for Vote (CDV). The CDV spans a 5 month period. A revised version is published as Final Draft International Standard, FDIS, for 4 months. If approved, it will be published as International Standard, IS, within 2 month. The total time from CDV till publication takes about 1 year. This looks long compared to de-facto standards, but during half the time the standard should be stable already, and so usable to develop products. Parallel to it, a French edition has to be made and circulated. Overall, a new edition of this standard has been published as International Standard in 2003. The third proposed stage is in a much less mature development stage. This planned harmonization work can lead to a third edition of the standard. To keep them alive, standards are always subject to change and undergo evolutionary changes in regard to technology advancements and market needs. On the other hand, the essentials of a standard must be established on a solid and long-lasting basis. For this reason, caution must always be applied to all exercised amendments: The investments of the industrial end users and hardware and software control vendors are always expected to be the primary concern. The approach described here represents an appropriate compromise to this concern.

What about this ‘6’ in IEC 1131 ?

The International Electrotechnical Commission, IEC, is a world wide standardization body. Nearly all countries over the world have their own, national standardization bodies. In Germany for instance this is the Deutsche Elektrotechnischen Kommission, DKE. These commissions have agreed to accept the IEC approved and published standards. At local publication, often after translation, the standard was published under a local number. This local number often had no match to the number of the IEC published standard. For a standardization body this looked awkward. To harmonize this, they searched for a world wide numbering system that was available to use. This is where the famous ‘6’ came in. And so IEC 61131-3 became IEC 61131-3, without any changes to the standard itself. Moreover, during the current transition phase, you have to order the IEC 6-1131 standard to get a publication that clearly has on its front cover ‘IEC 61131-3’. As this might be confusing to non-insiders, we decided to wait for a new edition of the standard to migrate to the new number. In this way it is coupled to change. How to order the Standard ?

Introduction into IEC 61131-8 Guidelines for the application and implementation of programming languages

Scope

This technical report applies to the programming of programmable controller systems using the programming languages defined in IEC 61131-3. It also provides guidelines for the implementation of these languages in programmable controller systems and their programming support environments (PSEs).
IEC 61131-4 should be consulted for other aspects of the application of programmable controller systems.

Overview

The intended audience for this technical report consists of:

• users of programmable controller systems as defined in IEC 61131-3, who must program, configure, install, and maintain programmable controllers as part of industrial process measurement and control systems; and
• implementors of programming languages, as defined in IEC 61131-3, for programmable controller systems. This may include vendors of software and hardware for the preparation and maintenance of programs for these systems, as well as vendors of the programmable controller systems themselves.
IEC 61131-3, in contrast, is mainly oriented toward the implementors of programming languages for programmable controllers. Users who wish a general introduction to these languages and their application should consult any of several generally available textbooks on this subject. Subclause 1.4 of IEC 61131-3 should be consulted by those who wish a "top-down" overview of the contents of IEC 61131-3.

Clause 2 of this technical report provides a general introduction to IEC 61131-3, while clause 3 provides complementary information about the application of some of the programming language elements specified IEC 61131-3. Clause 4 provides information about the intended implementation of some of these programming language elements, while Clause 5 provides general information about requirements for hardware and software for program development and maintenance. Hence, it is expected that users of programmable controllers will find Clauses 2 and 3 of this document most useful, while programming language implementors will find Clauses 4 and 5 more useful, referring to the background material in Clauses 2 and 3 as necessary.

TABLE OF CONTENT IEC 61131-8

1.	General	7
1.1	Scope	7
1.2	Normative references	7
1.3	Overview	7
2.	Introduction to IEC 61131-3	8
2.1	General considerations	8
2.2	Overcoming historical limitations	10
2.3	Basic features in IEC 61131-3	11
2.4	New features in the second edition of IEC 61131-3	12
2.5	Software engineering considerations	12
2.5.1	Application of software engineering principles	12
2.5.1.1	Encapsulation and hiding	12
2.5.1.2	Explicit representation of state	13
2.5.1.3	Mapping to the application domain	13
2.5.1.4	Mapping of design to implementation	13
2.5.1.5	Structured programming	14
2.5.1.6	Software reuse	14
2.5.2	Portability	15
2.5.2.1	Inter-language portability	15
2.5.2.2	Inter-system portability	15
3.	Application guidelines	16
3.1	Use of data types	16
3.1.1	Type vs. variable initialization	16
3.1.2	Use of enumerated and subrange types	17
3.1.3	Use of BCD data	17
3.1.4	Use of REAL data types	19
3.1.5	Use of character string data types	19
3.1.6	Use of time data types	20
3.1.7	Use of multi-element variables	21
3.1.8	Use of bit string data types	21
3.2	Data passing	21
3.2.1	Global and external variables	22
3.2.2	In-out (VAR_IN_OUT) variables	23
3.2.3	Formal and non-formal invocations and argument lists	25
3.3	Use of function blocks	29
3.3.1	Function block types and instances	29
3.3.2	Scope of data within function blocks	30
3.3.3	Function block access and invocation	31
3.4	Differences between function block instances and functions	32
3.5	Use of indirectly referenced function block instances	32
3.5.1	Establishing an indirect function block instance reference	33
3.5.2	Access to indirectly referenced function block instances	35
3.5.3	Invocation of indirectly referenced function block instances	35
3.5.4	Recursion of indirectly referenced function block instances	38
3.5.5	Execution control of indirectly referenced function block instances	38
3.5.6	Use of indirectly referenced function block instances in functions	38
3.6	Recursion within programmable controller programming languages	39
3.7	Single and multiple invocation	39
3.8	Language specific features	40
3.8.1	Edge triggered functionality	40
3.8.1.1	Edge triggering in LD language	40
3.8.1.2	Use of edge triggered function blocks	41
3.8.2	Use of EN/ENO in functions and function blocks	42
3.8.3	Use of non-IEC 61131-3 languages	43
3.9	Use of SFC elements	43
3.9.1	Action control	44
3.9.2	Boolean actions	45
3.9.3	Non-SFC actions	50
3.9.4	SFC actions	51
3.9.5	SFC function blocks	53
3.9.6	"Indicator" variables	53
3.10	Scheduling, concurrency, and synchronization mechanisms	54
3.10.1	Operating system issues	54
3.10.2	Task scheduling	56
3.10.2.1	Performance effects	57
3.10.2.2	Concurrency effects	57
3.10.3	Semaphores	57
3.10.3.1	General	57
3.10.3.2	Deadlocks	58
3.10.4	Messaging	58
3.10.4.1	Global storage	59
3.10.4.2	Mailboxes and queues	59
3.10.5	Time stamping	59
3.11	Communication facilities in ISO/IEC 9506/5 and IEC 61131-5	59
3.11.1	Communication channels	60
3.11.2	Reading and writing variables	60
3.11.3	Communication function blocks	60
3.12	Recommended programming practices	61
3.12.1	Global variables	62
3.12.2	Jumps in Function Block Diagram (FBD) language	62
3.12.3	Multiple invocations of function block instances in FBD	62
3.12.4	Coupling of Sequential Function Chart (SFC) networks	62
3.12.5	Dynamic modification of task priorities	63
3.12.6	Execution control of function block instances by tasks	63
3.12.7	Use of RTC (Real Time Clock) Function Blocks	63
4.	Implementation guidelines	64
4.1	Resource allocation	64
4.2	Implementation of data types	64
4.2.1	REAL and LREAL data types	64
4.2.2	Character strings	64
4.2.3	Time data types	65
4.2.4	Multi-element variables	65
4.3	Execution of functions and function blocks	65
4.3.1	Functions	66
4.3.2	Function blocks	66
4.4	Implementation of Sequential Function Charts (SFCs)	67
4.5	Task scheduling	67
4.5.1	Classification of tasks	68
4.5.2	Task priorities	68
4.6	Error handling	69
4.6.1	Error handling mechanisms	69
4.6.2	Run-time error handling procedures	71
4.6.2.1	Reporting of errors	71
4.6.2.2	System-defined error handling procedures	71
4.6.2.3	User-defined error handling procedures	73
4.7	System interface	73
4.8	Compliance	73
4.8.1	Compliance statement	73
4.8.2	Controller instruction sets	73
4.8.3	Compliance testing	74
4.9	Compatibility with IEC 617-12, 617-13, and 848	74
5.	Programming support environment (PSE) requirements	74
5.1	User interface	74
5.2	Programming of programs, functions and function blocks	75
5.3	Application design and configuration	76
5.4	Separate compilation	76
5.5	Separation of interface and body	77
5.5.1	Invocation of a function from a programming unit	77
5.5.2	Declaration and invocation of a function block instance	78
5.6	Linking of configuration elements with programs	79
5.7	Library management	82
5.8	Analysis tools	83
5.8.1	Simulation and debugging	83
5.8.2	Performance estimation	83
5.8.3	Feedback loop analysis	83
5.8.4	SFC analysis	83
5.9	Documentation requirements	86
5.10	Security of data and programs	87
5.11	On-line facilities	87
Annex A	Changes to IEC 61131-3 2nd Edition	88
A.1	Reasons for the 2nd edition of part 3	88
A.2	Corrigendum	88
A .3	Amendment	89
A.3.1	Numeric literals (2.2.1) – typed literals	90
A.3.2	Elementary data types (2.3.1) - double-byte strings	90
A.3.3	Derived data types (2.3.3) - enumerated data types	90
A.3.4	Single element variables (2.4.1.1) - 'wild-card' direct addresses	91
A.3.5	Declaration (2.4.3) - Temporary variables	91
A.3.6	Type assignment (2.4.3.1) - RETAIN and NON_RETAIN Variable attributes	92
A.3.7 of	Function ( 2.5.1) – Use EN/ENO	92
A.3.8	Declaration (2.5.1.3) - Function invocation with VAR_IN_OUT	92
A.3.9	Type conversion functions (2.5.1.5.1)	93
A.3.10	Functions of time data types (2.5.1.5.6)	93
A.3.11	Function blocks (2.5.2) - Extended initialisation facilities	93
A.3.12	Pulse action qualifiers (2.6.4.4)	94
A.3.13	Action control (2.6.4.5)	94
A.3.14	Configuration initialisation (2.7.1)	94
A.3.15	Instruction List (3.2)	95
A.3.16	Formal specification of language elements (Annex B)	97
A.3.17	Further amendments	97
ANNEX B	SOFTWARE QUALITY MEASURES	99
ANNEX C	INDEX	101

IEC 61131-7 Fuzzy Control Programming released

With the voting process closed on June 30, 2001, we have a new approved part to the IEC 61131 standard. It is part 7,

and deals with Fuzzy Control Programming.

The goal of this Standard is to offer the manufactures and the users a well defined common understanding of the basic 

means to integrate fuzzy control applications in the Programmable Controller languages according to Part 3, as well as the

possibility to exchange portable fuzzy control programs among different programming systems.

The theory of fuzzy logic in the application of control is named fuzzy control. Fuzzy control is emerging as a technology 

that can enhance the capabilities of industrial automation, and is suitable for control level tasks generally performed in 

Programmable Controllers (PC).

Fuzzy Control is based upon practical application knowledge represented by so-called linguistic rule bases, rather than by 

analytical (either empirical or theoretical) models. Fuzzy control can be used when there is an expertise that can be 

expressed in its formalism. That allows to take available knowledge to improve processes and perform a variety of tasks,

for instance:

	control (closed or open loop, single or multi-variable, for linear or non linear systems)
	on-line or off-line setting of control systems' parameters
	classification and pattern recognition
	real-time decision making (send this product to machine A or B ?)
	helping operators to make decisions or tune parameters
	detection and diagnosis of faults in systems

Its wide range of applications and natural approach based on human experience makes Fuzzy Control a basic tool that

should be made available to Programmable Controller users as a standard.

Fuzzy control can also in a straightforward way be combined with classical control methods.

The application of fuzzy control can be of advantage in such cases where there is no explicit process model available, or in

which the analytical model is too difficult to evaluate or when the model is too complicated to evaluate in real time.

Another advantageous feature is, that human experience can be incorporated in a straightforward way. Also it is not

necessary to model the whole controller with fuzzy control: sometimes fuzzy control just interpolates between a series of

locally linear models, or dynamically adapts the parameters of a "linear controller", thereby rendering it non linear, or

alternatively just "zoom in" onto a certain feature of an existing controller that needs to be improved.

Fuzzy control is a multi-valued control, no longer restricting the values of a control proposition to "true" or "false". This

makes it particularly useful to model empirical expertise, stating, which control actions have to be taken under a given set

of inputs.

The existing theory and systems already realized in the area of fuzzy control differ widely in terms of terminology

(definitions), features (functionalities) and implementation (tools).

Fuzzy control is used from small and simple applications up to highly sophisticated and complex projects. To cover all kinds

of usage by this part of IEC 61131, the features of a compliant fuzzy control system are mapped into defined

conformance classes.