In view of the increasing complexity of concepts such as Industry 4.0 and the Internet of Things, the major challenge is to make automation simple. IEC 61499 provides ideal conditions for this, especially when it comes to engineering control technology.

As a reminder, IEC 61499 is the successor standard to IEC 61131 and aims to overcome its limitations, particularly with regard to distributed control systems. Similar to IEC 61131, the IEC 61499 model is based on an object-oriented approach with function blocks - however, the cyclical execution model of the old standard is replaced by an event-driven model in IEC 61499. The greatest advance of the standard is probably the ability to model entire systems or plants and to distribute the control logic flexibly to different devices. In addition, interoperability, configurability and portability promote far-reaching system openness.

The example of a conveyor belt line with a variable number of conveyor belt segments, segmented start-up warnings and emergency stop circuits is a good illustration of how very simple solutions in the sense of single line engineering can be implemented on the basis of IEC 61499 and the nxtStudio software suite from nxtControl that is based on it. The latter is a type of programming in which function blocks with simple connecting lines can be interconnected to form complex applications based on the IEC 61499 adapter concept. The decisive advantage here is that the full complexity of the application remains hidden from the automation engineer. This saves time and money and avoids many sources of error.

HMI visualization of the example application 'conveyor belt line': Since the visual representation is always part of an encapsulated automation object, visualizations can be created very quickly.

© nxtControl

In this application, the emergency stop signals must be connected to the individual conveyor drives. The start-up warning sequence (traffic light signal) must run before the drives are switched on. Furthermore, the conveyor belt drives should be switched on one after the other, for example to avoid material jams. Conversely, when switching off, in the event of a drive failure or when an emergency stop signal occurs, all drives must stop simultaneously. Last but not least, it should be possible to expand the system quickly and with little effort at any time by adding further sub-segments (conveyor belt section with start-up warning and emergency stop).

The corresponding control program for the application described is made up of the function blocks for central system functions, the conveyor belt drives, the start-up warning sequence and the emergency stop function. The individual function blocks each contain a 'socket' and 'plug' of an adapter type as a connection point, via which the signal exchange between the function blocks is bidirectional. A socket is an instance of an IEC 61499 adapter that is used on the output side of a function block; the instance is referred to as a plug if it is used on the input side of a function block. Sockets and plugs therefore differ in that the interfaces defined on the IEC 61499 adapter are reversed.

Data always consistent

An IEC 61499 adapter type enables the formulation of an interface as a function block. The association of an event to data at the interface ensures data consistency, as when an event occurs, the associated data is seen together as a single information package and is transferred between connected adapters in distributed systems, even across device boundaries. In abstract terms compared to high-level programming languages, an adapter can be regarded as an interface. Its events represent method identifiers, the connected data the member variables of a method.

The creativity now lies in using the adapter concept in such a way that the number of connecting lines is reduced to a minimum for the interconnection of function blocks. To do this, the data must be processed or evaluated accordingly; only cumulative results are then forwarded to the next function block.

Example of an adapter type: The picture above shows the adapter with the event data association, below left the adapter as a socket (FB output) and below right the adapter as a plug (FB input).

© nxtControl

Each function block processes its own data as a black box. The interface of an adapter type defines the information that - viewed as a black box - is exchanged with the predecessors and successors of a processing chain. In this programming concept, an 'information package' is passed sequentially from one black box to the next. Data within the information package can be read, written or changed in the data flow. Thus, in the best case, a simple line connecting the adapters is sufficient for the interconnection - hence the term single line engineering.

With this approach, the actual complexity of the solution is not visibly implemented in the individual function blocks for the automation engineer. This results in complete libraries with automation objects that make life much easier for the application programmer. The libraries themselves are built and tested by specialists and then made available to project engineers. If these libraries are designed for aspect-oriented engineering, the individual automation objects also contain their visualization (HMI/SCADA), the I/O connection, testing and commissioning, documentation and the control logic.

Standards do not define libraries, so the extent to which a library supports the user depends on the expertise and experience of the respective provider. In any case, a library element in nxtStudio contains a consistent, encapsulated image of an object with all its different aspects. Depending on the context, these aspects are made available to the user in the engineering process. Related information is managed and automatically enriched by the tool (e.g. variable connection for HMI, cross-communication, etc.).

Hide complexity from the user

For a better understanding of the hidden complexity for the application programmer, let's take a closer look at the emergency stop function: In principle, the interlocking logic is structured in such a way that a drive must switch off if the following drive is not running. For this purpose, a Boolean signal (followerNotRunning) is exchanged between the function blocks. This signal is logically linked by the emergency stop function block for switching off segment by segment.

The function block is placed in the interconnected chain at the segment end of a safety circuit. On the one hand, it evaluates the physical status of the I/O signal and, on the other, it links the status of the downstream drives to this signal. If no emergency stop signal is present, the logical result of the successors is passed on. However, if an emergency stop signal is present, a switch-off signal is sent to all predecessors.

In the sense of single line engineering, the interconnection and thus the logical link between the individual elements - as already mentioned - is realized by a single adapter connection during application programming! By using SIFBs (service function blocks) for abstract access to physical I/O signals within the function block, the function block interface is reduced to functionally necessary signals. The I/O connection is defined and hierarchically structured inside the function block and offered for physical connection in the editor or hardware configurator.

Despite the complexity of an application distributed over several control units with two differently distributed safety zones, the control program is very simple.

© nxtControl

The concept described above makes it easy to create and segment a conveyor belt application. This means that only function block instances for the desired number of drives, start-up warnings and safety circuits need to be created by dragging and dropping the type in the editor and connecting them to individual lines. The sequence of the linking defines the segmentation and responsibility for the start-up warning and safety circuit.

Changing the application is just as easy. Any adjustments can be made by simply adding or removing function block instances and integrating them into the interconnection chain. All logical links to fulfill the shutdown sequence or the start-up warnings are already included in the function block types and are automatically interconnected to form an overall application.

Even very complex project requirements can be covered on the basis of this concept. This means that a (partial) automation program can change its configuration at runtime or detect it at system startup and adapt its program flow accordingly. As a concrete example, any number of temperature sensors can be connected to a temperature control system via adapters. The controller defines the expected signal, such as the average, minimum or maximum value. The configuration information is forwarded to the sensors via an adapter event, and the sensors in turn deliver the temperature value to the controller in a correctly processed sequence. The controller does not require any information about the number and characteristics of the sensors, but requests data in the required form via the adapter.

This also makes it much easier to program systems across different technologies.

Technology mix is also supported

Program of a (simplified) emergency stop function block. Orange indicates the use of the adapter as a socket and plug for sequential data transfer.

© nxtControl

The concept of the adapter interface supports such a mix of technologies. For example, an interface in high-level languages (.Net, C++, Java class) can be mapped as an adapter and connected directly to a control program as a communication point. The data flow is encapsulated in the adapter as a black box, but can be used transparently in the application thanks to its interface.

So far, it can be said that By using adapters as an interface between applications and/or modules, flexible adaptation of the system is possible at any time. What's more, the definition of interfaces between applications is a basic requirement for modern production concepts such as Plug & Produce. The IEC 61499 adapters offer a standardized way of providing data-consistent interfaces through the combination of data and event description or data and event association. At the end of the day, this saves engineering time and achieves consistent quality.

Admittedly: At first glance, a standard such as IEC 61499 is definitely a 'bulky' thing. On closer inspection, however, or once you have developed a detailed understanding of the mechanisms behind it, it becomes clear that this standard is ideally suited to meeting the challenges of the digital Industry 4.0 world.

Authors:
Gernot Kollegger is Head of Development at nxtControl;
Horst Mayer is Managing Partner of nxtControl.