• What are the benefits from using IEC 61499?
IEC 61499-compliant distributed industrial-process measurement and control sys- tems (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, program-
ming 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 firm- ware technologies should reduce hardware costs. The most significant cost items in modern control hardware are its embedded 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 integra- tion of system elements, will yield higher reliability and maintainability over the system life cycle.
5. IEC 61499 provides an abstract, implementation-independent means for 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 realise the benefits listed in the previous answer, distributed industrial- process measurement and control systems (IPMCSs) will need:
1. communication profiles which define standard communications function blocks and their mapping to standard open communication services such as those under development in IEC 61158 Fieldbus
2. standard programming languages such as those defined in IEC 61131-3 for the specification of algorithms in basic function block types
3. standardized function block types and guidelines for their application in specific domains, such as the process control function blocks under develop- ment by IEC SC65C/WG7; this working group is developing function blocks for process control applications.
• Will IEC 61499 have any impact on existing IEC 61131 products?
In the short term no. However there is an intention that the PLC software standard IEC 61131-3 will be revised so that the function block model becomes compatible with IEC 61499. In fact, IEC 61131 function blocks can be easily converted into a form that fits the IEC 61499 model by being encapsulated as basic function blocks. It is also possible to use IEC 61131-3 languages such as Structured Text (ST) and Ladder Diagram (LD) to define algorithms within IEC 61499 function block type specifications.
• I already have a huge amount of legacy programs based on IEC 61131-3 and
other procedural languages. How can this be re-used?
Procedural control algorithms will have to be encapsulated in IEC 61499 basic
how soon software tools will be available to support this migration. It is certainly fairly straightforward to take algorithms expressed in IEC 61131-3 Structured Text and encapsulate them as IEC 61499 function blocks.
• 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 communica- tion function blocks. Also, subapplications may interface with each other via event connections and data connections.
• Why doesn’t 61499 define applications as instances of application types?
An application contains a complete definition for its distribution of function blocks and subapplications over many resources. It is not possible to create an application instance from an application type because each application instance would require specific configuration information on how its internal component function blocks are distributed.
• How are applications distributed?
The applications can be distributed using the following process:
1. Create and interconnect one or more instances of the subapplication 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 subapplications representing the application.
4. If necessary to improve the distribution, remove the encapsulation around the subapplications, exposing their component function blocks (which may also be subapplications) as re-distributable elements of the application. 5. Remove the encapsulation of all of the newly exposed subapplications,
repeating as necessary.
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: it is envisaged that the engineering support tools will automatically insert service interface function blocks to maintain event and data flows between connec- ted blocks when they are distributed to run on different resources.
• 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.
• What is the difference between a Composite Function Block and a Subapplication?
A Composite Function Block can have Internal Variables, and it has guarantees for the sampling of input and output data when these are associated with events. For these reasons, it is not distributable, i.e. it is not possible to break the internal connections between component blocks and run them on different processing resources. However, to achieve the same effect this can be done by converting the composite block type into a subapplication type.
• Can alternative graphical representations be used?
Software tools can use alternative graphical, textual or tabular representations, as long as accompanying documentation specifies an unambiguous mapping to the graphical elements and associated textual syntax defined in IEC 61499-1. It should be noted that IEC 61499 defines a model not a graphical programming language.
• How can a function block respond to faults and exceptions?
In the IEC 61499 model, faults and exceptions are modelled 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 (modes are discussed in chapter 6).
• 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 the starting of applications, either locally or remotely via communication function blocks.
Note: The communications protocol and interactions to load and start-up
applications are not defined within IEC 61499 and are not part of its scope. This should be defined in domain specific standards. However, IEC 61499 does define a textual syntax and file exchange format to allow applications to be ported between systems.
• 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. For example, configuration parameters can be encapsulated in a function block that is then connected to other blocks that require the values.
• What is an ECC? Why should it be used and when?
An Execution Control Chart (ECC) is a specialised state machine to enable multiple events to trigger multiple algorithms, possibly dependent on some internal state.
It should be used when it is necessary to have maximum flexibility in algorithm selection and scheduling, or when there is a requirement for a high-performance, event-driven state machine. It is defined in IEC 61499 as a formal and precise way to show how events can trigger the execution of internal algorithms. (This is discussed in chapter 3.)
• 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 using function blocks to model device and resource management are:
1. a consistent model of all applications in the system, including management applications
2. a consistent means of encapsulating and re-using all functions, including management functions
3. re-use of existing data types
4. use of existing, standardised means for the definition of required new data types and specification of management messages.
• What is the difference between event and data?
More formally the difference can be expressed as:
• Event an instantaneous occurrence that is significant to scheduling the execution of an algorithm
• Data a reinterpretable representation of information in a formalised manner suitable for communication, interpretation or processing.
It is important to note that an event signifies some form of state change that may signal that an algorithm should be run. In practical terms, it is sometimes difficult to decide when an event is required or whether a state change can be reflected in the value of an input or output. For example, a function block mode change could be signalled by a dedicated mode input event. Alternatively, it could also be signalled by a mode input variable and an update event.
Also note that data cannot be transferred between blocks without an accom- panying event.