Industry 4.0 applications, the Internet of Things (IoT) and similar concepts are based on the distribution of various functions to different controllers and the controlled cooperation of components. The new approach goes far beyond traditional control concepts, which are generally based on the principle of programmable logic controllers (PLCs) and use digital industrial communication systems to decentralize sensors and actuators.

With the support of the PLCopen organization, the IEC 61131 standard has become established on the market for programming industrial control systems. With the third edition of the IEC 61131-3 part, an object-oriented concept of function blocks including abstract interfaces is now also provided. A further step towards the exchange of control programs between engineering tools has been taken with PLCopen-XML. This format is currently being standardized as part 10 of the standards series.

The exchange of data between controllers at runtime is more difficult. This communication must always be configured explicitly, whereby industrial communication systems such as Profinet with the controller-to-controller profile or the OPC UA information model developed jointly between PLCopen and the OPC Foundation also have a simplifying effect. The OPC UA client can already be implemented on the controller. If this is not available, additional orchestration of the data connections between the OPC UA services running on the controllers must be carried out.

From the perspective of the control programs, the IEC 61131-3 mentioned above has taken an important step towards software quality. The function block concept introduced in it allows good encapsulation of the program parts and at the same time increases the testability and reusability of the program code. However, the demands on software quality continue to increase. It is therefore advisable to use formal means when creating programs that are used in the area of functional safety. Approaches based on the principle of the state machine (finite automaton) have proven successful. The notation of the logic is relatively simple and the result can be represented formally. The disadvantage is that large networks quickly become confusing with regard to the respective states and transitions. This can be remedied by hierarchizing the states. Based on the theory of finite automata, Petri nets were developed, for example, which are primarily used for discrete, distributed behavioral descriptions.

In addition to the aforementioned design tools, however, a runtime environment is required that can execute the programs designed in this way. If the focus is on a single controller, appropriate tools can be integrated into the engineering environments. In the case of a network of heterogeneous control systems, however, an additional abstraction layer must be introduced. Computer science has coined the term 'middleware' for this newly added layer. In VDI/VDE 2657 (Sheet 1), the topic was approached in such a way that features and requirements regarding the selection and use of this software were described. Sheet 2 defines a process model that can be used for middleware engineering processes, highlighting the different roles from the manufacturer to the user. Ideally, middleware is used without the knowledge of the end user. However, the use of middleware always represents a system decision.

Figure 1: Layers of middleware: Services for related tasks are organized according to the layer model.

© Ifak

The advantages of using middleware lie not only in the abstraction to a specific platform but also in the improvement of interoperability between heterogeneous systems. Figure 1 shows a possible design of a middleware that also provides a distribution layer based on the platform abstraction with services such as memory management (e.g. portable auto-pointers), threads, synchronization, network/sockets, file system mechanisms or character set handling. One version of this layer will be discussed separately later.

The general services of a distribution middleware include locating all computers in the network, time synchronization, starting/stopping/terminating local or remote processes or introspection (self-observation) of nodes. Domain-specific services are also important for the use of middleware in the automation of production processes, for example for compliance with real-time requirements.

Orchestration at a higher level

The approach of Cyber Physical (Production) Systems (CPS) contributes significantly to making control programs more flexible. A CPS is a combination of computing power, (internet) communication and access to the process via corresponding I/O interfaces integrated into a device.

In order for the generally heterogeneous CPS to be able to cooperate with each other at application level, they must be orchestrated at a higher level. The IEC 61131 described above, together with exchange formats such as PLCopenXML or AutomationXML, provides a good starting point for designing collaborative CPS and orchestrating overall applications. However, the use of different programming tools is not an option for every user. One way out is to use middleware that enables the harmonization of heterogeneous nodes and engineering tools. Based on this middleware, applications can be designed and functions loaded onto the CPS involved. This approach is also supported by IEC 61499, for example, which can distribute a function block network as an overall application to different nodes. The disadvantage of this concept is the overhead of the separate data and event connections between the blocks, which increases the engineering effort enormously.

Figure 2: An actuator can both receive messages and react to them as well as actively execute its own logic and send messages. Actuators only communicate with each other via messages.

© Ifak

From a software architecture perspective, the actuator model approach(Fig. 2) appears to be more suitable for distributing functions across any number of CPSs. This envisages implementing partial functions of the overall system in independent software objects - the actuators. The actuator model is also based on the principle that the actuators communicate with each other via messages that are sent non-blocking and processed asynchronously. It therefore also follows the event-driven programming model and provides for a very loose coupling of the cooperation between the objects due to the purely message-oriented interaction between the actuators. Furthermore, it is initially abstracted from the computer on which an actuator is executed. This approach makes it possible to build scalable systems that can be easily readjusted if necessary.

Following this basic principle, modifications have been made for a suitable implementation - for example in the form of Active Objects. Active objects have their own execution context, for example in the form of an operating system thread. A further variant was described in the ROOM approach (Real-Time Object-Oriented Modeling) as early as 1994: namely the equipping of actuators with ports. The ports serve as explicit linking points between the actuators. This makes it possible to prefabricate objects analogous to function blocks and store them in libraries in the form of classes (types). During application design, the objects are instantiated and data and information flows are established via the port connections.

The 'Distributed Object Model Environment' (DOME) concept developed at the Institute for Automation and Communication (ifak) in Magdeburg picks up on these architectural patterns and extends them from the perspective of a runtime environment/middleware for distributed applications to include suitable mechanisms for the port connections. Within DOME, ports can be linked between objects that are executed either locally on the same CPS or on a remote CPS. The middleware always ensures that connections can only be established between ports of the same type.

A self-description - i.e. reflection - of the objects is used. Each object in DOME provides information about itself and therefore also about its ports. The ports in turn are also able to provide information about themselves and describe their signature, i.e. the data types of the input and output parameters or the return value in the event of blocking processing. All information on objects or ports is available both at engineering time and at application runtime. This allows new objects to be added to applications flexibly and dynamically, additional connections between ports to be established or connections or objects to be removed.

Objects describe themselves

Figure 3: Distributed application based on objects linked via ports.

© Ifak

Figure 3 schematically shows a distributed application in which the object network is distributed across three CPSs. The colors of the ports symbolize the different port types. The middleware only establishes connections between ports of the same or compatible type. Depending on the location of the communication partner, the 'correct' connections are automatically established, i.e. a network connection is automatically set up for a connection to a remote object. Important for the establishment of such system setups based on CPS (Systems of CPS) is the ability to explore the capabilities of the CPS at any time. This means that prefabricated components with statically defined functions (which nowadays correspond to field devices with function preprocessing, for example) or dynamically loadable functions can be determined at runtime via open interfaces.

These basic concepts in the DOME middleware provide the basis for a wide range of application patterns. This allows classic IEC 61131 function block concepts to be implemented, IEC 61499-compliant applications to be created or applications to be designed on the basis of formal state machines, whereby these can be processed in a distributed manner on the CPS. Using the so-called 'State Design Pattern', state machines can be converted into an object-oriented representation. Individual states are modeled as classes that implement the same base class. All possible transitions are stored as methods in this class. Each state implements the transitions to which the state can switch. A class for management controls the state change in a generic way by providing methods for transitions (=> signals) and carrying the current state.

Distributed control - an example

Figure 4: Example traffic signal system: The sequence of phases is shown at the top left.

© Ifak

The control of a traffic light system (LSA) serves as a simple example of how a control system based on CPS or using the DOME middleware with a distributed state machine can be implemented. The application is implemented as a distributed state machine. The control system consists of two cooperating controllers, each of which controls the traffic lights for one main direction of travel. The control task is as follows: Each of the directions of travel is served by a signal group (s0 - s3 in Fig. 4). After a cycle is complete, i.e. in the 'red' state again, a signal is sent to the next signal group, which then begins its cycle. In this way, the traffic lights control each other (cooperatively) without the need for a central control device.

The traffic lights at this junction are integrated into the overall traffic concept of a city. In addition to regular operation, the 'night shutdown' mode (flashing yellow in all directions) is supported. For this purpose, each of the signal groups has a switch for the operating mode. The phases are controlled as follows: A transition from the 'red' state of this state machine is connected to the 'red-yellow' state of the state machine in the opposite direction. If a signal group switches from 'Green' via 'Yellow' to 'Red', a 'Continue switching' event is triggered when the 'Red' state is reached, which triggers the above-mentioned transition and thus sets the opposite direction to 'RedYellow' (see Fig. 5). The phases are controlled in this way without a central control unit; it is carried out cooperatively by the components.

The status machines of the individual signal groups are connected to a status machine for the entire traffic light system. The connection to the city's traffic management system was also established here. The latter triggers 'mode changeover' events that lead to a change between regular operation and night-time shutdown.

The individual state machines are not copied for this control example. Instead, states can be combined into reusable groups. A change in one version of the group is immediately visible in all instances. The states can be linked between the different groups. The groups also allow parameterization. Examples of this are the green phase or the definition of phase transition times. The parameters can also include the IP address or a device identification of a CPS on which a group of states is executed. This makes it possible to process parts of a state machine on different CPSs.

In short: By modeling with state machines, control systems can be formally developed and evaluated. The implementation using the 'state design pattern' automatically turns it into a modular algorithm that can be distributed to different CPSs using suitable services of the distribution layer of a middleware and ultimately facilitates the implementation of cooperative control systems. By combining states into parameterizable, individually acting groups, reusability is increased on the one hand, and the control system can be designed flexibly on the other. In this way, parameters such as the duration of the phases or the executing CPS can be defined at development time and adapted to the runtime.

Authors:
Marco Meier is a research associate in the ICT & Automation business unit at ifak Magdeburg;
Dr. Matthias Riedl is head of the ICT & Automation business unit at ifak Magdeburg;
Holger Zipper is a research associate in the ICT & Automation business unit at ifak Magdeburg.