Distributed Real-Time Automation and Control - Reactive Control Layer for Industrial Agents
Thomas Strasser1; Alois Zoitl2 1 AIT Austrian Institute of Technology GmbH, Vienna, Austria
2 Fortiss GmbH, Munich, Germany
Abstract
Agent-based systems in general are not designed, and partly because of their collaborating negotiation behavior, are not capable of directly performing the real-time constrained control of machinery. It has been shown that a two-layered architecture with a multi-agent system on a higher level fulfilling strategic, planning, and supervisory tasks and a reactive lower-level, real-time layer handling the control task is beneficial. This chapter provides a brief overview of such a real-time control layer supporting agent-based systems, especially industrial agents. The main focus is on the discussion of potential approaches using international standards from the domain of Industrial Process Measurement and Control Systems (IPMCSs).
5.1 Introduction/Motivation
Industrial automation in manufacturing systems—in the power and energy domain, as well as the logistics sector—has become more complex today. Usually, a huge amount of actuators and sensors in such systems work together as a network of different devices. The latest trend in research and development shows that these devices are becoming intelligent, which means they can perform tasks autonomously. In order to master the complexity of such highly interconnected and collaborative devices, advanced methods and concepts along the whole life cycle (planning/engineering, operation, etc.) are necessary.
Promising and well-known approaches from artificial intelligence, called multi-agent systems (MASs) (Wooldridge, 2002), cover the above-described flexibility. This paradigm offers the possibility to design large-scale distributed control systems by using autonomous and cooperative agents. They offer modularity, flexibility, and robustness and exhibit the capability to execute monitoring, control, and diagnostics algorithms, as well other types, in a distributed manner. Each agent has its own knowledge skills, as well as autonomous proactive behavior, and they cooperate with each other to solve certain problems (Leitão, 2009).
MASs in industrial automation systems often need to interact with real hardware (e.g., production equipment-like machines, conveyor belts, or power system components like generators and transformers). Depending on the task of the MAS, this interaction ranges from simply gathering data and providing supervisory control to directly manipulating the equipment. The latter, especially, requires real-time constrained execution of control tasks.
Agent-based systems in general are not designed, and partly because of their collaborating negotiation behavior are not capable of directly performing the real-time constrained control of machinery. It has been shown that a two-layered architecture with MAS on a higher level, fulfilling strategic, planning, and supervisory tasks and a reactive lower-level real-time layer handling the real-time constrained control task is beneficial (Christensen, 2003).
The main aim of this chapter is to provide a brief overview of such a real-time control layer supporting agent-based systems, especially industrial agents. A major focus is put on using international standards and describing potential approaches in the domain of industrial process measurement and control systems (IPMCS), as well as discussing their advantages and disadvantages.
The remaining part of this chapter is organized as follows: Section 5.2 gives a brief introduction about the idea of using a reactive control layer (RCL) for industrial agents and discusses the most important requirements for it. In Section 5.3, the standard-based realization of this control layer applying two important automation standards defined by the International Electrotechnical Commission (IEC)—IEC 61131–3 and IEC 61499—is introduced. A discussion of the advantages and disadvantages of both approaches is provided in Section 5.5. Finally, the main conclusions of this chapter are given in Section 5.6.
5.2 RCLs for Industrial Agents
Introducing a two-layered architecture consisting of an agent system and a RCL expands the potential application domains of a MAS and at the same time adds the required flexibility to IPMCS (Christensen, 2003; Leitão, 2009). In this two-layered architecture, both layers can focus on the tasks they are suited to best. The MAS is in charge of the higher-level strategic control tasks, which consist of the execution planning, cooperating and negotiating with other subsystems, and the particular supervisory control of the associated IPMCS part. Figure 5.1 shows such an agent architecture for industrial control applications. To denote the application domain, agents in such architectures are often named industrial agents. This approach represents the two-layer structure, introduced earlier, with an agent control layer and the corresponding RCL.
The RCL, as its name implies, is in charge of providing the real-time control operation for the IPMCS part. Typically, the RCL’s control programs are executed in small embedded control devices located in the IPMCS. These control devices are connected to sensors for acquiring the IPMCS state and actuators for influencing it. The core tasks of the RCL are the reading of sensor values from input signals, the preprocessing of these values (depending on current states and the execution mode calculating control laws), and generating appropriate values for actuators connected to the outputs of the control devices.
A key aspect in such a two-layer architecture is the interaction interface between the MAS and RCL. From here, the MAS needs to be able to request services from the RCL (e.g., perform certain machining operations) and get feedback from the RCL on the execution status of the services (e.g., remaining time, finished quality). Furthermore, the MAS needs to be allowed to change the parameters of the RCL (e.g., adjust the RCL to the execution modes or products being produced). Finally, the MAS requires status feedback from the RCL. This status feedback needs to be initiated by the RCL and reports on the general status of the controlled IPMCS part (e.g., the depletion of supplies) and especially on critical conditions (e.g., a stuck palette).
These general interaction needs are typical requirements for any supervisory control in the domain of IPCMS. They would be sufficient also for the MAS-RCL interaction if the RCL controls a static and unchangeable part of the IPCMS. However, as identified by the Iacocca Institute (1991), for achieving the adaptability and flexibility of IPCMS, pure parameterization is not enough. Also, an adaptation in the control application structure might be necessary. Therefore, the RCL has to provide services that allow the MAS to reconfigure and change the RCL’s control program according to the current needs of the MAS’s plans.
When designing such two-layered systems, several requirements and guarding conditions have to be considered for the interaction interface, as well as for selecting an appropriate technology for the RCL. Typically, only a single agent will directly interact with the RCL, as this agent represents the IPMCS control part in the MAS. The interaction between MAS and RCL does not disturb the RCL in such a way that the RCL cannot fulfill its real-time constraints anymore and therefore not provide a safe control of the associated IPMCS part. Generally, the MAS and RCL should be loosely coupled, such that the RCL can also operate without an agent system.
For implementing the MAS-RCL interface, the typical design considerations usually suggested for supervisory control in the domain of IPMCS can be applied (Christensen, 2003; Leitão, 2009). Especially for the just discussed interaction requirements (i.e., service requests, parameters adaptation, and status feedback), the existing supervisory control interaction possibilities provided by RCL implementation can be used. For the reconfiguration interface, other services and functions have to be developed.
Summarizing, in industrial systems and environments, the RCL provides for the agent system the necessary real-time constrained execution of control applications. The RCL accepts commands and parameters from the MAS and sends status information back to it. A key functionality for fully flexible and adaptive systems is that the RCL provides services and functions that allow the MAS to reconfigure the control applications in the RCL.
There are a number of ways to realize the RCL. Several, often proprietary, approaches are reported in the literature (Christensen, 2003; Leitão, 2009; Vrba et al., 2011), but in order to achieve interoperability a standardized way of information exchange between both layers would be necessary. Moreover, a standardized way of invoking these services and functions, as well as their implementation, might be necessary. In the following section, two possible standard-compliant approaches will be introduced and discussed.
5.3 Standard-Based Realization
In the domain of IMPCS, standardization is an important prerequisite for control architectures. Promising candidates for real-time control in this area have already been specified by the IEC with the corresponding approaches defined in the IEC 61131 for programmable logic controllers (PLCs) (International Electrotechnical Commission, 2012a), as well as in the IEC 61499 for distributed automation (International Electrotechnical Commission, 2012b). In the following sections, a brief introduction of the basic control modeling principles, as well as their corresponding execution models in respect to real-time execution, is given. Furthermore, according to the requirements for RCL-MAS interaction (identified in the last section), the available means for information and data exchange, as well as services for adapting parameters and the program structure, are analyzed.
5.3.1 PLC-Based Control with IEC 61131–3
In the domain of industrial automation, the most commonly used method for programming control systems is the IEC 61131 standard, especially Part 3. This standard was originally developed with the goal of harmonizing PLC programming languages. The first version of IEC 61131–3 was issued in 1993; the third edition is currently available.
5.3.1.1 Basic principles
IEC 61131–3 mainly targets PLC systems consisting of one or more tightly coupled controllers (e.g., CPU cards). In the context of IEC 61131–3, tightly coupled means that data shared between the controller devices is replicated by an underlying service fast enough that applications running in the controller devices cannot distinguish between remote and local data. This architecture is reflected in the IEC 61131–3 software model, as depicted in Figure 5.2 (International Electrotechnical Commission, 2012a). The main element is the configuration. A configuration consists of several control devices, named resources by the standard. Resources share a set of global and directly represented variables, which are the physical I/Os of the control device and special internal memory regions. In addition, access paths provide a special form of global variables. They offer global access to the internal data of the control applications within the resources (e.g., make an internal variable of a program globally visible).
Resources contain one or more tasks and programs. Tasks are in charge of executing the control applications, as described next. Programs are the highest level of structuring control applications in IEC 61131–3. The other structuring means are function blocks (FBs) and functions. All three are summarized with the term program organization unit (POU). Functions are at the lowest level of the POU hierarchy and provide a stateless encapsulation of reusable functionalities. That means that functions do not have internal storage and always return the same result for the same input parameters. A function can only call other functions, not FBs.
FBs encapsulate state-full functionality. That means that FBs can have internal variables that are retained during different FB invocations. Within FBs, it is possible to invoke other FBs and functions. In the third edition of IEC 61131–3, the FB concept has been extended with object-oriented aspects. Today, FBs can use several methods, can inherit from base FBs, or implement interfaces. These object-oriented extensions have been introduced in such a way that old (pre-third edition) IEC 61131–3 POUs are still valid in the third edition (similar to C and C++, where C functions are valid functions in C++).
For programming the different POUs, IEC 61131–3 defines four programming languages, two graphical and two textual, covering different aspects of programming PLCs (International Electrotechnical Commission, 2012a). Furthermore, it defines the structuring language of sequential function charts (SFCs). SFCs allow describing phases of the IPMCs in a state machine form. They can be used in both a graphical and textual form, and are very well-suited for activating and deactivating different POUs for the different phases of IPMCS.
The graphical languages are the ladder diagram and the FB diagram. The ladder diagram represents the wiring diagrams used for describing relay logic, something employed in IPMCs before PLCs were introduced. It is well-suited for smaller control tasks and for specifying interlocks. FB diagrams allow users to graphically place and connect FBs. They resemble the logic diagrams used in digital logic design. Both graphical languages have the advantage of being suitable for non-programmers, allowing them to get a quick overview of the control application. This is especially of interest to plant maintenance personnel.
The textual languages are the instruction list and structured text. An instruction list is an assembler-like language that lets users specify control tasks at a very low level. Structured text is a high-level imperative language with a syntax similar to Pascal or Ada. It is suited for programming more complex algorithms such as closed-loop control algorithms.
5.3.1.2 The execution model
The core execution elements in IEC 61131–3 are the tasks. They provide an independent execution context for the POUs assigned to them (see Figure 5.2). Task activation can be either free running, cyclical, or event-triggered. Free running means that as soon as the execution within a task finishes, it is started again. In cyclical execution, the execution of a task is started using a given cycle time (e.g., every 2 ms). Event-triggered tasks are activated when an assigned event condition is fulfilled (e.g., a system error occurred, a rising edge of a Boolean variable). Furthermore, tasks may have priorities.
Within a task, the execution model is a purely sequential one. This means that the assigned POUs are executed one after another in the order they are assigned to the task. Also, the contents within the POUs are executed sequentially. For textual languages, that means the execution of each statement, from top to bottom, one statement after each other. For graphical languages, an execution order is determined based on the structure of the respective languages. For example, POUs using a ladder diagram are executed from top to bottom. The execution order of FB diagrams is more complicated. Here, the rules define that before a FB can be executed its inputs need to be available (i.e., produced by previous FBs). In the case of feedback loops, this can typically, but not always, be achieved automatically. Vendors solve this in different ways, leading to different execution orders.
5.3.1.3 Communication interfaces
Communication support of IEC 61131–3-based control devices can be grouped into three main categories: (i) network variables, (ii) communication FBs, and (iii) interaction with higher-level systems.
Network variables, which are not explicitly defined in IEC 61131–3, are a logical, vendor-specific extension of the tightly coupled configuration model (Figure 5.2) across the network, forming more loosely coupled configurations. That means that a set of the global variables, the so-called network variables, are replicated via the network on all involved resources. When one program in a device writes on one of the variables, the communication infrastructure updates this variable on all other devices. As several programs may write at the same time, different access guards (i.e., write, read/write, read-only, write-only) are introduced, helping ensure consistency. Currently, there exists no common standard or approach for network variables. The main purpose of network variables is the horizontal communication between control devices. Therefore, this communication means is not suited for the RCL and MAS interaction.
The second communication means provided is FBs, which allow control applications to actively participate in the communication (i.e., trigger send, act on data received). A set of such FBs is defined in IEC 61131–5 (International Electrotechnical Commission, 2000). In this, only the FB interface and the general behavior are standardized. The implementation for a specific communication system is left out. Many vendors provide implementations for these FBs. However, they often can only be used to communicate with devices from the same vendor.
Several of the defined FBs provide mechanisms suitable for the RCL/MAS interaction identified in the last section. Certain FBs can request the status of remote devices. This functionality can be used by the MAS to check the health state of its RCL. Notify and alarm blocks allow control applications to actively report status information and critical situations to other (e.g., higher-level) systems. For bidirectional interaction, Send/Recv FBs are offered. These resemble the well-known Client/Server interaction pattern, where the Send FB corresponds to the Client, and the Recv FB to the Server. The interaction is as follows: It starts with the Send FB sending data to the Recv FB. The Recv FB notifies the control application, which processes the data and provides an appropriate response to the Recv FB, which then sends it back to the Send FB.
For the RCL/MAS interaction on the RCL side, Recv blocks can be used to define command interfaces for the MAS. This allows the MAS to send requests to the RCL, which processes them and sends back the appropriate response. Finally, IEC 61131–5 defines FBs, which allow control applications to remotely read or write values in remote devices. This functionality is of less interest in the context of RCL/MAS interaction.
The third communication mechanism typically available in IEC 61131–3-based control systems is communication with higher-level systems like supervisory control and data acquisition (SCADA). This interaction is normally achieved by providing these higher-level systems access to all, or only a subset, of the global variables in a control device. Thus, in most cases, the control device is a passive member in the communication and the higher-level system is performing write and read operations on the variables. Vendor-specific, as well as vendor-neutral, access mechanisms exist for performing this task. The new communication standard OPC-UA, especially, has gained great interest as a vendor neutral access mechanism (Mahnke et al., 2009). Such a communication between the MAS and the RCL is provided in Figure 5.3 according to Vrba et al. (2011). It uses the data table provided by a PLC for interacting with higher-level systems like SCADA. For information and data exchange with a PLC data table, the MAS provides a corresponding control interface.
In respect to this investigation, this kind of interface has a great advantage in that it offers the highest flexibility and is available in some form in nearly all control devices. However, this flexibility is also a great drawback: Because it is a purely data-driven interface, the overall semantics behind it are lost. No clear interaction patterns are defined and no clear reaction in the control application can be defined at this level.
5.3.1.4 (Re-)configuration services
IEC 61131–3 does not consider the configuration or reconfiguration of control devices in its specification. Therefore, each vendor has its own approach to performing the control application download to the devices and its configuration. The typical case is that a full system configuration with its tasks and precompiled programs is downloaded to the device in one big hunk and then started on the device. Some vendors also support hot swapping between resource configurations, and especially between an existing and a newly downloaded one. Hot swapping means that an active resource configuration is replaced by another one without the need to stop the plant and the control device. Furthermore, the current control values of the old resource configuration are transferred to the new one.
Such hot-swapping functionalities would in principle allow MAS to change the control application. However, providing and maintaining full-resource configurations can be elaborate and error-prone tasks because the full integrity of the whole configuration must be maintained. Furthermore, during the switching process no resource configuration is active, which can lead to disturbances in the plant. Therefore, in general it can be said that support for the configuration and reconfiguration of IEC 61113–3-based control systems, as identified in the previous section, is rather poor.
5.3.2 Distributed Control with IEC 61499
In the beginning of the 1990s, the IEC started with the development of a reference model for distributed IPMCS based on FBs. One of the main goals of the resulting IEC 61499 specification—called “function blocks”—was the possibility to obtain a vendor-independent system architecture for industrial automation and control. In addition, the fulfillment of the flexibility and reconfigurability needs of holonic and industrial agent-based systems (Koestler, 1969), as discussed in Section 5.2, were additional inputs for the development of this standard. In the following paragraphs, a more detailed overview of this distributed automation model is provided.
5.3.2.1 Basic principles
IEC 61499 especially addresses the easy exchange of control applications and library elements between different software tools (i.e., portability), as well as the ability to configure control devices by multiple software environments (i.e., configurability). Moreover, the standardized information and data exchange between control devices is also targeted (i.e., interoperability). This is achieved by the provision of several reference models in the IEC 61499 specification, which was released in its first edition in 2005 and in its second edition in 2012.
The core elements of this automation standard are FBs, which allow the encapsulation of control software and algorithms in a modular way, as depicted in Figure 5.4.
FBs are an established concept for industrial applications to define robust and reusable software components. They can store the software solution for various problems and they have a defined set of input and output parameters, which can be used to connect them to form automation applications. The FB definition of IEC 61499 is based on the IEC 61131, but it is extended with an event interface for execution control. Three main FB types are defined: (i) the basic FB for algorithm encapsulation, (ii) the composite FB for functional aggregation, and (iii) the service interface function block (SIFB) as an interface to the communication network, the controlled process/machine, and the device management. In addition to these FB types, an interface concept called Adapter Interface is also defined in the standard.
In contrast to IEC 61131–3, this standard also defines a hardware model to describe the control devices, as well as the communication network in a distributed configuration. Therefore, IEC 61499 defines a system configuration (see Figure 5.5b), which is composed of several devices and resources, the communication network, and mapped applications. The device (see Figure 5.5b) represents a physical entity that is able to execute control functions (e.g., embedded controller, PLC) containing one or more independent functional units called resources (see Figure 5.5c).
Moreover, each device is responsible for the whole life cycle of the mapped applications (see Figure 5.5b). Devices, as well as resources, interact with the physical process/machine and with the communication network through interfaces noted as special FBs: the SIFBs (see Figure 5.5c). IEC 61499 applications (i.e., an interconnected network of FBs; also denoted as the FB Network (FBN), as shown in Figure 5.5a) are usually distributed to the devices and resources. Figure 5.5 summarizes the most important elements of the IEC 61499 reference model for distributed IPMCS.
From an engineering point of view, IEC 61499 follows an application-centered modeling approach. Different than the IEC 61131 device-centered programming of automation functions and control algorithms in IEC 61499, the automation application is defined independently of the underlying hardware configuration. In a second step, the FBN is then distributed to different devices and resources, as depicted in Figure 5.5b. In order to get a better overview of complex applications, IEC 61499 defines subapplications as a structuring means for grouping parts of applications. A subapplication can contain, in addition to FBs, other subapplications. They are represented in the containing (sub)applications in the form of FBs very similar to composite FBs. However, different from composite FBs, subapplications can be distributed to devices or resources.
5.3.2.2 The execution model
A big difference between the IEC 61131 PLC-based approach and IEC 61499, besides the direct support for distribution, is the execution model. Instead of the cyclic execution of FBs, IEC 61499 applies an event-based invocation using the event interface of FBs, as shown in Figure 5.4. It therefore supports the asynchronous execution of FBs and FBNs through the usage of special event FBs. The synchronous concept is also supported.
In general, the IEC 61499 standard defines a simple execution model for FBs, which is presented in Figure 5.6. As mentioned earlier, the execution of FBs is triggered by an event after the input data are available. Afterward, the execution control function is evaluated, and the underlying scheduling function (provided by the resource as shown in Figure 5.5c) is made responsible for the scheduling of the corresponding algorithm. After the execution is finished, the output data are updated on the FB output interface and an event output is generated that usually triggers the execution of a connected FB. The resulting timing behavior of IEC 61499 FBs is given in Figure 5.6b.
The IEC 61499 reference model mainly provides the FB execution model, but doesn’t provide much information regarding the scheduling of applications and subapplications, nor much information on devices and resources. This provides space for interpretation of the implementation of the IEC 61499 solution. Several concepts have been analyzed so far that show different execution behavior (Cengic and Akesson, 2010; Ferrarini and Veber, 2004; Strasser et al., 2011; Vyatkin, 2011). Moreover, the real-time execution of IEC 61499 FBNs is not directly covered in the standard, but some potential realizations have already been reported in the literature (Zoitl, 2009).
Summarizing, compared with IEC 61131–3, a more detailed execution model has been defined in the IEC 61499 specification, but it still gives the freedom of different interpretations and implementations, resulting in partly different execution behaviors for FBs and FBNs.
5.3.2.3 Communication interfaces
The communication network (as well as the used protocols) is not directly covered by the IEC 61499 specification. Only specific interfaces for data and information exchange between devices and resources are specified that are represented as SIFBs. In the standard, two different high-level communication patterns are suggested: (i) the Publish/Subscribe and (ii) the Client/Server model. The first one is mainly used for unidirectional communication according to the producer/consumer concept, whereas the second is dedicated to bidirectional communication, as indicated in Figure 5.7.
This interface specification, especially the Client/Server pattern, is generally suitable for MAS/RCL communication since it provides a clearly defined interface. However, a standardized protocol, including a semantic specification, has still been missing up to now.
For example, Christensen (2003) introduces a communication interface based on IEC 61499 FBs that uses agent communication language (ACL) for the data exchange between agents and the RCL layer, according to the concept shown in Figure 5.1. The whole solution is encapsulated into a composite FB called HMS_KERNEL containing the three FBs: HMS_CDI, HMS_CM, and DEV_MGR. The first two provide corresponding interfaces to the agent system, whereas the last one represents the IEC 61499 management interface to the control device (details are provided in the next section). Figure 5.8 shows the corresponding FB setup.
Moreover, the IEC 61499 standard provides the possibility to define profiles for different application domains, which also includes the communication interface. Therefore, some compliance profiles have already been defined that cover the communication specification in more detail. Currently, the most important one, the IEC 61499 Compliance Profile for Feasibility Demonstrations, which was developed by the Holonic Manufacturing Systems (HMS) consortium, specifies its usage based on Ethernet (Christensen, 2013). Nevertheless, other communication networks and field buses can be easily integrated in an IEC 61499 solution using the Compliance Profile specification and the SIFB concept (Weehuizen and Zoitl, 2007).
5.3.2.4 (Re-)configuration services—IEC 61499 device management
In order to manage the life cycle of FBs, and therefore those of whole applications, the IEC 61499 standard devises the so-called “device management,” as shown in Figure 5.5b. It provides a very useful and standardized interface to configure devices and resources by calling the corresponding management commands. The following commands are defined within the standard (International Electrotechnical Commission, 2012b; Vyatkin, 2011; Zoitl, 2009):
• Initiating the execution of elements (i.e., START, RESET),
• Stopping the execution of elements (i.e., STOP, KILL),
• Creating FB instances, as well as event/data connections (i.e., CREATE),
• Deleting FB instances and connections (i.e., DELETE),
• Parameterizing elements (i.e., WRITE, READ), and
• Providing status data about devices, resources, and FBs (i.e., QUERY).
In order to access the defined commands just mentioned, the standard provides a special SIFB (i.e., Manager FB) but leaves the protocol for accessing it open. In the feasibility demonstration compliance profile, an XML-based specification is suggested, as shown in Figure 5.9 (Christensen, 2013).
Summarizing, the IEC 61499 device management with its management commands provides an interface to other tools (e.g., engineering environment, agent), which can be used to reconfigure the control applications during execution (Lepuschitz et al., 2011). Therefore, it basically fulfills the requirements as defined in Section 5.2.
5.4 Example
In order to show how the proposed concepts are applied, an illustrative example from the power systems domain has been selected. In the following sections, the corresponding use case and automation scenario is introduced and the interface between the agent layer and the control layer using IEC 61131 and IEC 61499 is sketched.
5.4.1 Selected Use Case
The selected automation scenario represents a distributed voltage control application realized using a MAS, as shown in Figure 5.10a. The main goal of this use case is to keep the voltage in a low-voltage power distribution network in defined boundaries. Due to a high penetration of distributed generators in the power grids, voltage violations can be increasingly observed. The voltage control can be realized in general by the use of on-load tap changing transformers together with active and reactive power management provided by inverter-based distributed energy resources (DERs). In the selected example, photovoltaic (PV) systems are used as DERs.
The automation application is represented as an agent control application where each power system component (i.e., tap changer, DER) is represented by an agent. The tasks of the agents are to process local information from the RCL—voltages (V), currents (I), etc.—and optimize the voltages in the different feeders of the power grid using the tap changer functionality and active/reactive power management of the DER (i.e., local Volt/VAR control).
Figure 5.10b shows the architecture of the industrial agents according to the concept proposed in Figure 5.1. The local optimization of the components is carried out by the agent control layer together with the RCL (i.e., intelligent electronic device—IED) where real-time control actions are performed. The following data are exchanged between the two layers: Voltage (U), Current (I), Active Power (P), Reactive Power (Q), and Tap Changer Position (n).
The representation of the communication interface between the RCL and the agent layer is prototypically shown in the following using the IEC 61131 and IEC 61499 approaches.
5.4.2 IEC 61131–3 Interface
For this example, the global data table approach, as described in Figure 5.3, is applied. The data table used for interacting with the agent is defined in the VAR_GLOBAL section of the PLC program (see Figure 5.11) and consists of two parts. The first is the data points used for receiving commands from the agent; the second is the data delivered to the agent. For the latter, the inputs of the control application are simply made available to the agent. These are as described earlier—U, I, P, Q—and the current tap changer position is n_act. The agent can read these as desired. The control value given by the agent is the desired voltage (ctlV). In order to inform the RCL application, the agent needs to trigger a rising edge on the flag newAgentData. In order to inform the agent that the command data has been received by the RCL, the agentDataAck flag is used. The RCL itself is implemented in the program TapCtrl.
VAR_GLOBAL (*Command data from Agent*) ctlV: REAL; newAgentData: BOOL; (*Flag set by agent*) agentDataAck: BOOL; (*Acknowledgement of data by RCL*) (*Input data*) UAT %ID#: REAL; IAT %ID#: REAL; PAT %ID#: REAL; QAT %ID#: REAL; n_act AT %IW#: WORD; (*Output data*) n_des AT %QW#: WORD; END_VAR PROGRAM TapCtrl (*RCL Control algorithm for tap changer*) … END_PROGRAM
5.4.3 IEC 61499 Interface
For this example, the Client/Server pattern, as introduced in Section 5.3.2, is applied for the data exchange between the two layers. Figure 5.12 provides an overview of this interface, as well as the corresponding RCL control application. It is composed of three main IEC 61499 FBs: (i) Server SIFB (Comm), (ii) Tap Changer Control FB (TapCtrl), and (iii) Process I/O SIFB (TapHW). The Server SIFB is responsible for communicating the U, I, P, Q, and n_act to the agent layer via TCP/IP and making sure it is receiving the desired voltage level.
5.5 Discussion
Both approaches, IEC 61131 as well as IEC 61499, provide basic services that are essential for the definition of an interface between the agent-control and the real-time control layer, as discussed earlier and also in the literature (Frank et al., 2011; Maturana et al., 2006; Merdan et al., 2009; Hegny et al., 2008; Lepuschitz et al., 2009; Tichy et al., 2006; Wannagat and Vogel-Heuser, 2008).
The following Table 5.1 summarizes the most important services and features of IEC 61131 and IEC 61499 for the implementation of a RCL layer, as described in Section 5.2. Moreover, it gives an indication of the suitability based on the previously described concepts and features of both standards.
Table 5.1
Overview of IEC 61131 and IEC 61499 Possibilities for the RCL Layer
| Service/Feature | IEC 61131 | Suitability for Ind. Agents | IEC 61499 | Suitability for Ind. Agents |
| Real-time execution of control tasks | Simple but well understood; cyclic-based but also offers support for asynchronous execution | Well suited due to the support for synchronous and asynchronous execution; vendor solutions mainly address cyclic execution | Event-triggered execution allows asynchronous and synchronous execution | Well suited due to the support for synchronous and asynchronous execution |
| Distribution of applications | Device-centered application modeling | Partly supported due to communication possibilities; not covered by the software model | Application-centered modeling | Direct support for distribution |
| Standardized communication interface | Three different approaches have been identified, but only IEC 61131–5 provides a standardized interface | Partly with the provision of IEC 61131–5 communication services | Provision of two high-level communication patterns for uni- and bidirectional communication | In principle, well suited, but the provision of a standardized protocol is still open |
| Parameter adaptation | Mainly due to proprietary vendor solutions | Partly, since no standardized interface and protocol is defined | Standardized management interface available | Well suited but the provision of a standardized protocol is still open |
| Control application reconfiguration | Mainly due to proprietary vendor solutions, and mostly the exchange of whole applications is supported | Partly, since no standardized interface and protocol is defined | Standardized management interface available | Well suited but the provision of a standardized protocol is still open |
Summarizing, both approaches are, in general, possible for the implementation of an RCL layer in industrial agent-based systems, but the IEC 61499 is more suitable due to the previously described functions and services.
Lessons learned from several implementations investigated in the literature are that a separation in an agent control layer and the RCL helps ease the system configuration and setup (Christensen, 2003; Leitão, 2009). It brings, on the one hand, more determinism and real-time control capabilities to the MAS, and on the other hand, adaptivity/reconfigurability and flexibility to classical controlled systems (i.e., PLCs).
However, a major open point is the missing standardized interface specification (control commands and services, protocols) between both control layers. The investigation of developments done within this chapter shows that mainly project/use case-specific and partly proprietary approaches are being applied. In this respect, further standardization and harmonization activities are needed to make it easier to develop such integrated automation solutions in the near future. Interesting and promising technologies can be the new emerging communication and interface description standard IEC 62541 (i.e., OPC-UA) (IEC, 2010), Machine-to-Machine (M2M)/Internet of Things (IoT) approaches like MQTT (MQTT, 2010), and service-oriented architecture (SoA) (Erl, 2008). These would allow the user to cover many requirements independently from the technology used on both layers, resulting in a higher decoupling of system elements and higher reuse between them.
5.6 Conclusions
Extending the MAS layer with a flexible and reconfigurable real-time control infrastructure would help fulfill the needs for industrial agents. In this chapter, the main corresponding requirements have been analyzed, and a two-layer structure with an agent and a reactive control part has been suggested. The MAS layer brings the high-level of flexibility and adaptability, whereas the RCL adds deterministic real-time execution and the reconfiguration of control applications and functions.
In order to have a defined and standardized interaction between the agent and the RCL, as well as the standardized invocation of services, two standards from the automation and control domain—the IEC 61131 and the IEC 61499—have been analyzed in respect to their execution behavior, their communication, and their reconfiguration possibilities. It has been shown that the IEC 61131–3 has a clear and easily understandable deterministic execution behavior, and therefore supports the necessary real-time execution requirement. On the other hand, it is lacking in standardized communication interfaces and reconfiguration services. Instead, the IEC 61499 distributed reference model has especially been defined to interact with agent-based systems and therefore provide basic services for reconfiguration and the possibilities to define standardized communication interfaces, but a corresponding compliance profile is missing up to now.
Summarizing, both automation standards provide some functions and services that are necessary for the RCL, and they have already been used for industrial agent systems. However, these implementations were performed from scratch and tailored for the specific use case. Clear and standardized interfaces, as well as the corresponding services and functions, are still missing up to now. Furthermore, on these standardized interfaces and services, typical interaction patterns should be defined. They can define the active element in interactions (i.e., MAS or RCL), as well as which general interaction channels are needed and how to represent them. In addition to these patterns, standard messages for certain domains (e.g., Smart Grids, machining, assembly) also could be defined. This would greatly reduce the development effort for the MAS-RCL interaction. However, there will still be RCL-specific message content since this often strongly depends on the controlled process(es) and machine(s).