IEC 61499 FAQ

This document is a compilation of responses by the Experts of IEC TC65/WG6 to Frequently Asked Questions (FAQs) about the draft IEC Standard 61499, Function Blocks for industrial-process measurement and control systems. The contents of this document are not normative and do not form a part of the draft Standard.

Yokohama Workshop Questions&Answers (Q&A)

General Questions

What good is IEC 61499?
IEC 61499-compliant distributed industrial-process measurement and control systems (IPMCSs), devices, and their associated life-cycle support systems will be able to deliver a number of significant benefits to their owners and system integrators, including:
1. IEC 61499-compliant life cycle support systems will be able to reduce engineering costs through integrated facilities for configuration, programming and data management. Additional engineering cost savings will result from the ease of system integration provided by IEC 61499's simple yet complete model of distributed systems. This model provides hardware- and operating system-independent representations for all functions of the system, including control and information processing as well as communications and process interfaces.
2. Economies of scale from uniform application of common software and firmware technologies should reduce hardware costs . The most significant cost items in modern control hardware are its firmware and supporting software!
3. Engineers and technicians will be able to reduce system implementation time by applying a common set of concepts and skills to all elements of the system. Further reductions in implementation time will result from the elimination of software patches and "glueware" formerly required to integrate incompatible system elements and software tools.
4. The elimination of patchware and glueware, the availability of interoperable software toolsets, the portability of engineering skills, and the ease of integration of system elements, will yield higher reliability and maintainability over the system life cycle.
5. IEC 61499 provides an abstract, implementation-independent means of representing system functions. This common "target" will lead to simplified migration from existing systems to 61499-compliant systems, and from older to newer technological platforms (operating systems, communications, etc.) in 61499-compliant systems.
Is IEC 61499 a "stand-alone" standard?
No. In order to realize the benefits listed above, distributed industrial-process measurement and control systems (IPMCSs) will need:
- Communication profiles which define standard communication function blocks and their mapping to standard open communication services such as those under development in IEC Project 1158 (Fieldbus).
- Standard programming languages such as those defined in IEC 61131-3 for the specification of algorithms in basic function block types.
Standardized function block types and guidelines for their application in specific domains, such as the process control function blocks under development by IEC SC65C/WG7.

Object Orientation

Why use such a heavily object-oriented model?
The degree of object orientation used in IEC 61499 is necessary in order to achieve the required level of distributability of encapsulated, reusable software modules (function blocks).
Isn't this very expensive to implement?
Not necessarily; a full object-oriented implementation is not required by the IEC 61499 model - only that the externally visible behaviors of a compliant device conform to the requirements for the device compliance class as defined in subclause 5.2 of IEC 61499-1. The implementation of a "Class 0" device can be quite economical.
Why not use a general-purpose distributed object model, like DCOM or CORBA?
1. Implementation of the features specified for these information-technology models would be too expensive, and their performance would almost always be too slow, for use in a distributed real-time industrial-process measurement and control system (IPMCS).
2. There is no standard, easily understood graphical model for representing the interconnections of events and data among these kinds of objects in distributed applications.
Are data and event connections a kind of object?
Data and event connections can be considered objects insofar as IEC 61499 defines a textual syntax for their declaration and a management service for their creation, query and deletion. However, the only attributes that IEC 61499 defines for a connection are its source and destination. Software tools may require additional attributes, such as scheduling priority for event connections, communication timeliness constraints for both data and event connections in order to determine whether a proposed system configuration is feasible. Software tools should also check the types of data and event inputs and outputs for consistency. Annex J of IEC 61499-1 will define syntax and semantics for the declaration of additional attributes.

The Event-Driven Model

Why an event-driven model?
Any execution control strategy (cyclic, time scheduled, etc.) can be represented in terms of an event-driven model, but the converse is not necessarily true. IEC 61499 opts for the more general model in order to provide maximum flexibility and descriptive power to compliant standards and systems.
How can a change in a data value generate an event?
E_R_TRIG and E_F_TRIG function block types are defined in Annex A of IEC 61499-1 which propagate an input event when the value of a Boolean input rises or falls, respectively, between successive occurrences of the input event. Instances of this type may be combined with with other function blocks to produce rising- and falling-edge triggers, threshold detection events, etc.
What are event types? What are they used for?
An event type is an identifier associated with an event input or an event output of a function block type, assigned as part of the event input or output declaration, as described in IEC 61499-1-2.2.1.1. It can be used by software tools to assure that event connections are not improperly mixed, for instance to assure that an event output that is intended to be used for initialization is not connected to an event input that is intended to be used for alarm processing.

Event types cannot be detected by execution control charts (ECCs), so the type of an event cannot be used to influence the processing of events in basic function block types.

IEC 61499 does not define any standard event types other than the default type EVENT.
Why and when should I use the WITH construct?
When you are designing function block types, you use the WITH construct to specify:
- which input variables to sample when an event occurs at the associated event input of an instance of the type;
- which output variables to sample when an event occurs at the associated event output of an instance of the type.
When using the WITH construct, you should bear in mind that this information will be used by software tools to assist the designer of applications using instances of these types to assure that:
- The data used by an algorithm in one function block is consistent with the data produced by an algorithm in another function block and delivered over one or more data connections associated with one or more event connections.
- The messages transmitted over communication connections between resources in a distributed application carry consistent data and events between the function block instances in the application in the way intended by the application designer.
How can this model accommodate sampled-data systems?
The major issues in sampled-data systems such as those used in motion, robotic and continuous process control are:
1. how to achieve synchronized sampling of inputs;
2. how to assure that all data has arrived in time for processing by control algorithms;
3. how to assure that all outputs are present and ready for sampling before beginning the next cycle of sampling and execution.
Solutions to these problems typically require specialized communication and operating system services, which can be represented in terms of the IEC 61499 model by service interface function blocks. The inputs and outputs to be sampled can likewise be represented by service interface function blocks, while the algorithms to be performed will typically be encapsulated in basic function blocks. The relationships between the system services, input and output sampling, and algorithm execution can then be expressed as event connections and data connections.
What happens if a critical event is lost by the communication subsystem?
This issue is common to all distributed control systems and its solutions are well known, e.g., via periodic communication, missing event detection and/or positive acknowledgment protocols. The IEC 61499 model provides for notification of abnormal operation via the IND-, CNF- and INITO- service primitives and STATUS output of service interface function blocks.

Engineering methodologies

How can I use IEC 61499 to design and implement state-machine control?
There are various formal and informal methodologies for the design of state-machine control systems. A general outline of these methods and how IEC 61499 models and software tools can be used is as follows:
1. Define the desired sequence of operations for the controlled machine or process, as well as possible abnormal sequences which may occur. This may be done informally in ordinary language, or using more formal notations such as Petri nets or IEC 61131-3 Sequential Function Charts (SFCs).
2. Define the actuators that are to be used to implement the desired behaviors, the sensors that are to be used to determine the actual state of the controlled machine or process, and their interfaces to the state-machine controller(s). IEC 61499 service interface function block types may be used for this purpose; such type definitions will typically be provided for this purpose by the supplier of the 61499-compliant sensor and actuator devices.
3. Model the behaviors of the machine or process in response to commands (events plus data) given to the actuators, and the resulting, observable time-dependent outputs (events plus data) from the sensors. This modeling may be done formally using notations such as Petri nets, or informally using simulation models (which may be implemented with appropriate IEC 61499 models).
4. Define the appropriate state-machine controllers, typically as the ECCs and algorithms of basic function block types. Methodologies for doing this step may be informal, based on engineering experience, or more formal, using for example Petri-net theory. Best of all is to reuse existing, proven state-machine controllers from an IEC 61499 function block library!
5. Validate the proposed state-machine controllers versus the model of the controlled machine or process. In order to catch possible design or specification errors, this should normally be done using simulation in addition to more formal validation methods if available.
6. Finally, replace the simulated sensor and actuator interfaces with the service interfaces to the actual machine or process to be controlled. This installation is normally to be done piecewise for testing purposes.

To be updated...

Why doesn't 61499 define applications as instances of application types?
In liaison with SC65C/WG7, TC65/WG6 determined that an implementation-independent specification of an application type would be identical to a composite function block type; however, this view has now evolved to that of a sub-application type. The configuration of applications could then be carried out according to the following process:
1. Create and interconnect one or more instances of the sub-application types representing the application.
2. Create instances of the service interface function blocks representing the process interfaces of the application.
3. Create appropriate event connections and data connections between the process interface function blocks and the sub-applications representing the application.
4. Remove the encapsulation around the sub-applications, exposing their component function blocks (which may also be sub-applications) as distributable elements of the application.
5. Remove the encapsulation of all of the newly exposed sub-applications, repeating as necesary.
6. Distribute the application by allocating its function block instances to appropriate resources.
7. Create and configure appropriate communication function block instances to maintain the event and data flows of the application.
  - Note 1 - Part 2 will define the requirements for software tools to maintain a consistent system namespace during this process.
  - Note 2 - Part 2 will also define the converse of this process, i.e., implosion (encapsulation for re-use) of an application.
Can an application contain "sub-applications"?
Yes. See subclause 2.4 of Part 1.
Can an application interface with other applications?
No, since there is no application type within which an interface could be defined. However, applications may communicate with each other by means of communication function blocks. Also, sub-applications may interface with each other via event connections and data connections.
Why can't a composite function block have internal variables?
Internal variables are not required in composite function blocks, since sampling and storage is defined for all possible sources of data, i.e., input variables or outputs of component function block instances.
How can "contained parameters" be accessed?
External access to internal variables of function blocks is contrary to the principles of good software design. Nonetheless, to accommodate exceptional cases and previous practice, the READ and WRITE services and associated access paths to internal variables are defined for management function blocks. However, this practice may substantially degrade system performance, reliability, maintainability and safety.
Are extensible user-defined function blocks permitted?
IEC 61499 follows the usage of IEC 61131-3 and does not define a mechanism for specification of extensible inputs and outputs of user-defined function blocks. The use of the ellipsis (...) and accompanying textual descriptions is considered adequate for the specification of extensible inputs and outputs of standard function blocks in IEC 61499.
Can alternative graphical representations be used?
Software tools can use alternative graphical, textual or tabular representations, so long as accompanying documentation specifies an unambiguous mapping to the graphical elements and associated textual syntax defined in IEC 61499-1.
How can a function block respond to faults and exceptions?
In the IEC 61499 model, faults and exceptions are modeled as event outputs and associated data outputs of service interface function blocks. These outputs can be connected to appropriate event inputs and associated data inputs of any function blocks which must respond to the fault or exception, e.g., by changing their operational modes.
How is the loading and starting of applications managed?
Software tools for this purpose will take as input a system configuration and generate sequences of commands to management function blocks to perform loading and starting of applications, either locally or remotely via communication function blocks.
How can "trend" and "view" objects be created?
A view is a collection of data values from various sources, arranged for remote access. This function is performed by standard communication function blocks. A trend is a sequence of data values from the same source. The function of collecting trend data can be implemented as an algorithm of a basic function block, and remote access to the data so collected can be provided by standard communication function blocks. See Annex C of IEC 61499-1.
Is there any way to distinguish between "process events" and "execution scheduling events"?
These events can be distinguished from each other by the new event type mechanism. These can be used by software tools to show only the event types of interest.
Why are there no GLOBAL or EXTERNAL variables?
All variables are encapsulated. There is no guarantee that there will be an implicit global distribution mechanism available. When such mechanisms are available, they can always be mapped to service interface function blocks.
What is an ECC? Why should I use it and when?
An ECC is a specialized state machine to enable multiple events to trigger multiple algorithms, possibly dependent on some internal state. You should use it when you need maximum flexibility in algorithm selection and scheduling, or when you need a high-performance, event-driven state machine. Otherwise you can just use the mechanisms in Annex D for converting IEC 61131-3 function blocks to 61499-style blocks.
Why use function blocks to model device or resource management applications?
This usage is described in subclauses 1.4.7, 3.3 and Annexes F and G of IEC 61499-1. The benefits of this approach are:
- A consistent model of all applications in the system, including management applications
- A consistent means of encapsulating and reusing all functions, including management functions
- Reuse of existing data types
- Use of existing, standardized means for the definition of required new data types and specification of management messages.

Last updated: 1999-11-19.
Read the Function Block News.