Implementing a PLC-Service bus with IEC 61499

Implementing a PLC-Service bus with IEC 61499 Virendra Ashiwal∗, Antonio M. Gutierrez†, Alois Zoitl∗†,Member, IEEE †CDL VaSiCS ∗LIT CPS Lab, Johannes Kepler University Linz Linz, Austria {virendra.ashiwal, antonio.gutierrez, alois.zoitl}@jku.at Abstract—With an increased demand for customization, a better quality of products, and available variability in machines, enforcing machine developers to rethink how PLC-software is structured and developed. It demands the PLC-software to be adaptable, flexible, and modular. Current PLC-software uses global variables for interaction between its program organization units (POUs). Global variables increase tight coupling and reduce adaptability, flexibility, and modularity. A new architectural concept, the PLC-Service bus, was suggested to address this issue. To reduce coupling, POUs and software components of the PLC communicate via a service bus. This concept leads to two problems. There are no standard models to describe these interactions clearly, and there is no implementation of the PLC-Service bus to develop PLC-software based on message interaction patterns (MIPs). This paper uses the capping station from the VDMA R+A OPC UA Demonstrator as a running example. With an Event-driven process chain model (EPC), we describe the interactions between various software components of the capping station to identify MIPs. Based on these MIPs, we implement the PLC-software of the capping station with IEC 61499. Index Terms—PLC-Service Bus, PLC-software, Software components, Interaction pattern, POU, Middleware, Factory Automation, Control software I. INTRODUCTION Programmable logic controllers (PLCs) and their software (PLC-software) are primary drivers for the production systems in the industrial automation domain. Therefore, its development makes a significant share in the overall cost of a production system [1]. From the first PLC in 1969 to the present, market demands have led to the advancement of PLC-software. The evolution of communication technology, the increasing processing power of PLCs, and market expectations have brought more intelligent control systems with many functions and more customization capabilities. The PLC-software for such systems needs to be modular, flexible, and adaptable to improve quality and reduce development costs and time to market [2]. The IEC 61131-3 standard dominates current PLC-software. IEC 61131-3 [3] was proposed in 1993 to define a standard programming interface and a software concept for PLCs [4]. It comprises many software components, so-called program organization units (POUs). POUs are programmed to provide certain machine functionality. The overall machine functionality depends on interactions between these POUs. Global variables in IEC 61131 software concept play a vital role in POU to POU communication. At the same time, they introduce tight coupling and hidden dependencies. Therefore, the resulting PLC-software is less flexible, less adaptable, and requires higher maintenance costs. A new architecture concept, the PLC-Service bus, was proposed to address these problems [2]. The PLC-Service bus architecture is inspired by the Enterprise Service Bus (ESB) architecture. Software components in this architecture communicate via PLC-Service bus thus are loosely coupled, and the integration logic is broken up [5]. Therefore, the PLC-software can be organized as atomic software components that can easily adapt and customize. The authors identified requirements of this architecture, which are necessary to be accepted in the automation domain [2]. Based on the requirements, we identified messaging interaction patterns (MIPs) for the PLC-Service bus architecture [6], which is basis of this paper. Despite having requirements and MIPs, a proper way to implement PLC-software based on the PLC-Service bus architecture is not addressed yet. First, there are no standard approaches or methods to show the interaction between software components. Having an approach or method to show these interactions would help an automation engineer to understand flow of the overall data exchange between software components w.r.t. the PLC-Service bus architecture. An engineer can easily identify MIPs from the machine, which would be helpful to implement later on. To address this challenge, this paper uses an event-driven process chain (EPC) to describe the interaction between software components and identify the MIPs. EPC is an ordered graph of events and functions, wellknown in the business process domain [7]. After identifying the MIPs, we provide an implementation of the PLC-Service bus architecture for a capping station as a running example. The rest of this paper is organized as follows. In the next section we describe our approach to address the implementation of the PLC-Service bus. In Section III. We introduce the capping station from the VDMA R+A OPC UA Demonstrator [8] as running example for our proposal. The suitability of IEC 61499 for PLC-Service bus architecture is discussed in Section IV. Based on the PLC-Service bus architectural concept, a list of interaction patterns will be identified from the capping station in Section V. These patterns will be mapped with available default patterns from IEC 61499. Others, which are not available by default in IEC 61499, will be implemented in Section VI. In Section VII we discuss the scope of this implementation and its potential limitations. Finally, the conclusion and future work is mentioned in Section VIII. II. OUR APPROACH For the implementation of the PLC-Service bus, we conduct the following methodology, which is shown in Fig. 1. VDMA1R+A OPC UA Demonstrator [8], presented in Munich in 2018, is a production cell to produce a fidget spinner as a final product. We analyze the system’s behavior to understand the involved actors and their interactions. Specifically, we focus on station 3 of this system, the capping station. Then, we formalize such behavior into an eventdriven process chain (EPC). EPC is a well-known modeling technique for business processes, used in some of the leading business modeling products, e.g., SAP R/3 (ERP/WFM) and ARIS (BPR). The semantics of EPC have been formalized and validated using different analysis techniques, such as Petri-nets [9]. With the formalized EPC model, we describe (i) all the existing event interactions, (ii) the publishers and consumers of the events, (iii) the required data inputs and outputs in the system operation. By taking reference from MIPs of the PLC-Service bus [6], we list the MIPs from the EPC model of the capping station. Then, we implement the list of MIPs with the standard IEC 61499. For this implementation, we first identify which MIPs can be directly executed with the existing implementations of IEC 61499. If some MIPs are not available by default, we implement them as function blocks for this standard. As a result of this process, we get an implementation of the PLC-Service bus architecture for the capping station with IEC 61499. List of MIP MIP Catalogue from PLC Service bus Identification of MIP from VDMA Capping Station Catalogue of MIP PLC-Service bus implementation of VDMA Capping Station with IEC 61499 Implementation of MIP in IEC 61499 EPC of Capping Station VDMA Capping Station Patterns implemented in paper Default Available Patterns IEC 61499 Fig. 1. Overall process for implementing VDMA capping station based on the MIP of PLC-Service bus with IEC 61499 III. RUNNING EXAMPLE The VDMA R+A OPC UA Demonstrator is a production cell with a hierarchical structure with stations, substations, and components to produce a fidget spinner as the final product [8]. As we stated, we consider station 3, the capping station, as a running example for this paper. This station is responsible for placing two caps on each side of the spinner. A. Capping Station of the VDMA R+A OPC UA Demonstrator In the capping station, we differentiate seven components: (i) a Bunker which provides the caps (without a precise position), (ii) a Vibrator to enforce that desired cap is in reachable position with the proper orientation, (iii) a Camera which evaluates if at least one available caps at the Vibrator matches the required color by the spinner and within reachable 1Mechanical Engineering Industry Association position by the Axis, (iv) a Vacuum Gripper which grabs and presses the caps on the spinner, (v) an Axis which moves a cap from Vibrator to spinner, (vi) a Gripper to hold the spinner while it is capped and to rotate it with 180° so that the same process of placing cap can be performed on the other side of the spinner, (vii) a Lifter for vertically ascending and descending the spinner to the position of the Gripper. B. Capping Station with the PLC-Service Bus Architecture With our PLC-Service bus architecture, we can drive the capping workflow with business events. Thus, the point-to- point integration between devices is eliminated. Each software component is only responsible for sending its events to the bus and subscribing to the events it is interested in. The bus is responsible for making the event delivery. In this way, specific implementation details of the software component are hidden, and the communication between components does not require custom integration between software components in the same PLC-Service bus environment. Fig. 2 reflects an overview of the PLC-Service bus with the listed components in the capping station and the basic operations performed by each component. Find Object Camera PLC Service bus Fill Caps Bunker Product Flip Vibrator Seperate Open Gripper Close FlipGo Top Lifter Go Home Open Vaccume Gripper Close GoToPos Axis Fig. 2. Capping Station with PLC Service bus C. EPC Model of the Capping Station To identify the message interactions that are required in the capping station, we model the capping process using the EPC notation [7]. The main elements in an EPC model are (i) Events, represented with a hexagon, to describe the results and triggering of a function or process, (ii) Functions, depicted with a rounded rectangle, to model the tasks or activities within the process, (iii) Information, represented with a rectangle, to portray the information or resources that can be input or output data of functions. The flow of elements is connected with an arrow, and this flow can be split or merged with logical operators (and, or, etc.). A fragment of the complete process for the capping station2is shown in Fig. 3, depicting the cap provision. We represent the responsible units for each Function and Event with vertical lanes in the diagram, i.e. the Camera, the Vibrator and Bunker. Note that for the sake of simplicity, we do not consider error handling in this model. The process for the capping station starts when the spinner 2https://github.com/ashiwalv/PLC-ServiceBus Patterns with IEC61499/ blob/main/10 EIP model/CompleteProcessAlternative.pdf, is in the position to be capped. This process is triggered with the event CAP REQUIRED, published by the previous station. This event provides the information about which Cap color is needed and the Spinner position. The Camera is triggered with this event to evaluate if there are caps available at the Vibrator with the required color and position. On the one side, if there are no caps with the required color, the Camera publishes a DESIRED COLOR CAP NOT AVAILABLE event, which is listened by the Bunker in order to provide more caps. When the Bunker has provided additional caps, sends an event MORE CAPS AVAILABLE, which triggers the Camera to re-evaluate the available caps. On the other side, if the Camera checks that there are caps available, but they are not in the right orientation or position to be gripped sends an event WRONG CAP ORIENTATION or an event CAP NOT REACHABLE, respectively. Both events trigger the Vibrator, which vibrates the platform to position the caps correctly. Then, the Vibrator sends an event CAPS FLIPPED, which triggers the Camera to make a new evaluation of the available caps. When there is at least one cap available with the required color in a reachable position, the Camera sends a CAPS REACHABLE event with the information about the available Cap position to trigger the capping of the spinner in a later process, Place Cap. Fig. 3. Event-driven process for the provision of the caps. IV. WHY IEC 61499 IEC 61131 and IEC 61499 are two industrial automation standards that define how PLC software should be written and structured. IEC 61131 is widely adopted by industrial automation and control applications. It is mainly used for the centralized control system and not suitable for modular, distributed, reusable, and flexible industrial automation applications [4], [10]. On the other hand, IEC 61499 was developed to bring these properties [4], [11], [12] in PLC-software. A. Suitability of IEC 61499 The IEC 61499 is designed to develop distributed control applications. Current market requirements for production systems are batch size one production, the customized product in minimum time, and reduced overall production cost. PLC- software must be flexible, modular, and adaptive to new market requirements to fulfill these demands. The smallest software component of IEC 61499 is a function block (FB). An IEC 61499 control application is a network of these FBs providing desired machine functionality. Providing FBs as encapsulated software components without any global variable makes them atomic modular software components essential for the PLC-Service bus. FBs are reusable as they do not have any hidden dependencies. IEC 61499 uses eventbased execution for interaction between software components (FBs), which is also suitable for PLC-Service bus architecture and its asynchronous message interaction patterns [6]. Event, and Event With Data from IEC 61499 are similar to Event Message, and Document Message patterns from PLC-Service bus. Publish-Subscribe pattern is a message transporting channel available for the PLC-Service bus, which is also available in IEC 61499 for transporting messages between distributed control applications. B. Communication Patterns in IEC 61499 Client-Server and Publish-Subscribe are the two communication patterns available in IEC 61499 as the backbone of distributed control applications. The FBs these patterns are comprised of are capable of transferring messages (Event or Event With Data) from one device to another device [13]. The idea behind the PLC-Service bus is to bring loosely coupled software components at PLC-software. Therefore, the Publish-Subscribe pattern provides better scalability and loose coupling than the Client-Server pattern [14]. Fig. 4 shows the Publish-Subscribe FBs providing this pattern. Publish-Subscribe is a unidirectional interaction without any initialization order. The originator needs no knowledge on the receiver and vice versa [16]. A Publisher can send messages to multiple Subscribers and also a Subscriber can receive message from multiple Publishers [13], [14], [16]. It supports the multi-cast method of communication [17]. The Publish- Subscribe FBs define only the interface of the communication and an abstract interaction via service sequences but do not define a concrete implementations or require a specific protocol [13]. Fig. 4. Communication patterns in IEC 61499: Publish and Subscribe [15] One main drawback of these FBs is the lack of feedback if the data has been received correctly. Still, these additional communication means (e.g., handshake mechanisms, timeout monitoring) may need to be implemented at the application level [16]. V. MAPPING In this section, we first identify MIPs from the EPC diagram of the capping station. Based on that we are going to map them to patterns available in IEC 61499. A. Identified Messaging Interaction Patterns Through the EPC diagram2of the running example, we could see the overall process to place the cap on both sides of the spinner. It starts with the event CAP REQUIRED and ends with the last event SPINNER CAPPED. The event messages from every software component are published at the PLC-Service bus and are subscribed by the interested software components; this pattern is called Publish-Subscribe Pattern. All the interactions are based on event messages. Therefore, they all use Event Message pattern. Out of all these events, only two events require additional data. Event CAP REQUIRED will be delivered with the Cap Color and event CAP REACHABLE will be delivered with the Cap position. The Cap position is essential for the Axis to pick the cap from the Vibrator. This way of sending data along with event is called Event Message with Data pattern. The Camera subscribes to Cap Color from the message published by the Product struct. Here Camera uses the Filter Pattern to subscribe to one single attribute of Product struct,Cap Color. With the Filter Pattern, one can reduce the burden of handling additional data that is not required at the moment. We listed the types of these identified MIPs in Table I along with the suitable equivalent pattern from the PLC- Service bus [6]. Here we can see that Event Message and Publish-Subscribe patterns are available at the PLC-Service bus with the same name. Event Message with Data pattern is available as Document Message, and Filter Pattern is available as Content Filter patterns. B. Mapping of Identified MIPs to IEC 61499 From Table I, we get the list of the MIPs which we need in order to implement the capping station with IEC 61499. In this subsection, we are going to map these MIPs to the available TABLE I MIPS FROM THE CAPPING STATION WITH THEIR SUITABLE ONE FROM THE PLC-SERVICE BUS S.No. Patterns from running example Patterns available in the PLC-Service Bus [6] 1 Event Message Event Message 2 Event Message with Data Document Message 3 Publish-Subscribe pattern Publish-Subscribe pattern 4 Filter pattern Content Filter MIPs in IEC 61499. We are using Eclipse 4diac IDE [15] as a programming tool for IEC 61499 implementation. The first pattern from Table I is Event Message. IEC 61499 is an event-based execution standard. Therefore an event is the main backbone of its interaction. With the need to send additional data along with the event, there is a possibility to attach data with the WITH attribute along with the event. This way of sending data along with Event Message is similar to the Document Message of the PLC-Service bus [6], the second pattern in Table I. The third one, the Publish-Subscribe Pattern, is available as the main pattern to transport messages between different resources in a distributed control system. The forth one, the Content Filter Pattern, is not available in the IEC 61499 and we implement it as a FB of IEC 61499 in 4diac IDE (details in Section VI). The implemented FBs are used together with the patterns available in IEC 61499 to develop the PLC-software of the running example. In Table II, equivalent MIPs from IEC 61499 are listed out along with required patterns from the PLC-Service bus. TABLE II INTERACTION PATTERNS FROM PLC-SERVICE BUS AVAILABLE IN IEC 61499 S.No. Patterns available in the PLC-Service Bus [6] Patterns available in IEC 61499 1 Event Message Event Message 2 Document Message Event With Data 3 Publish-Subscribe pattern Publish-Subscribe pattern 4 Content Filter NOT Available VI. IMPLEMENTATION In this section we are going to discuss the implementation of the missing pattern from Table II as well as the overall implementation of the capping station with IEC 61499. A. Implementation of the Identified MIPs in IEC 61499 In Table II, we can see that MIP Content Filter is not available in IEC 61499. Content Filter is a pattern to avoid an unnecessary flood of messages. At the capping station the Product publishes a message structure containing members like ID, name, current position, operating time, and color. The camera’s software component is not interested in all of these member variables. Therefore, with the Content Filter pattern it just subscribes to its color member variable. In the 4diac IDE the GET STRUCT VALUE FB is available to get a selected member value from any structure. The ideal solution would be to get the value of color member from the structure only when it differs from its previous value. This has been achieved by using the FB Detect VarChange FB with E SWITCH FBs. We used these two FBs to implement the Content Filter pattern as Composite Function Block (CFB) in 4diac IDE. The implementation of this FB is shown in Fig. 5. With Content Filter, we have all the required patterns available to implement the capping station based on the PLC-Service bus architecture. Fig. 5. Implementation of Content Filter Pattern as a Composite Function block in 4diac IDE B. Implementation of the Capping Station This subsection shows how each identified pattern is implemented with IEC 61499 using 4diac IDE. Note that due to the rules of IEC 61499, event names cannot contain spaces and the underscore symbol is used. 1) Event Message: The smallest unit of IEC 61499 is a FB. A FB interacts with another one via its interface. An event is the main interface element of a FB in IEC 61499. In Fig. 6, we can see events as the interface of the camera component written in uppercase. We consider the camera part in the EPC diagram2to identify events and implement them at the camera FB. "WITH" connection Fig. 6. Event and Document Message in 4diac IDE 2) Document Message: In IEC 61499, the data interface of an FB serves to transfer data along with events. According to the EPC diagram2, there are two document messages in our capping station at the camera. The first one is the color of the cap, which is attached with event CAP REQUIRED. The second message includes the coordinates of the cap, which needs to be picked up by the axis. These coordinates data Pick Pos X,Pick Pos Y, and Pick Pos Z are attached with the event CAP REACHABLE. Both of these document messages are seen in the camera FB in Fig. 6. A straight line denoting ”WITH” connects the event to the matching data interface at the FB’s input and output. Fig. 7. Pub-Sub Pattern in 4diac IDE 3) Publish-Subscribe Pattern: Fig. 7 shows implementation of Publish-Subscribe pattern for the event DESIRED COLOR CAP NOT AVAILABLE. The camera publishes this event via the PUBLISH FB. It is subscribed by bunker via the SUBSCRIBE FB. Similarly, all other events identified by the EPC diagram2are published and subscribed. 4) Content Filter: The Camera is interested in subscribing only to the color member of the Product Struct. Here it uses Content Filter FB to the Product Struct FB with Filter Name as color. Here color is a data element attached with the event CAP REQUIRED as a Document Message. PLC-Service Bus Fig. 8. Content Filter Pattern in IEC 61499 application as FB in 4diac IDE 5) Overall Application: The above-mentioned pattern implementation in IEC 61499 serves as guidance for the overall implementation of the capping station. First, we created seven FBs as software components corresponding to seven main mechatronics components from the capping station. While creating these software components, we took reference from the EPC diagram2to get input and output interfaces (Event and Document Messages) of these FBs. We used PUBLISH FB and SUBSCRIBE FB to create interaction between software components as described above. With that, we have implemented the capping station in IEC 61499 based on MIPs of the PLC- Service bus. Only a part of the full3implemented IEC 61499 application is shown in Fig. 9. Camera Bunker Vibrator PLC-Service Bus Fig. 9. IEC 61499 application of checking cap part of the capping station in 4diac IDE VII. DISCUSSION The PLC-Service bus architectural concept eliminates hidden dependencies and tight coupling between software com- 3https://github.com/ashiwalv/PLC-ServiceBus Patterns with IEC61499/ blob/main/20 4diac application/4diac full application.pdf, ponents of a PLC-software. The requirements of this concept and a catalogue of MIPs for its software components are already proposed and published [2], [6]. A guideline to identify these MIPs from a machine and its processes and later use them to implement a PLC-software had not been addressed yet. To identify MIPs from a machine, automation engineers need to understand interactions between software components. Therefore, there is a need to visualize these interactions. This paper proposes using an EPC model, first to visualize interactions so that automation engineers can understand the overall process of the capping station. EPC models also help to identify MIPs for implementing a PLC-software based on the PLC-Service bus architecture. EPC modelling technique is commonly used in the enterprise domain to show business processes. The reason for using the EPC model is its capability to show event-based interactions. In this work, we implement the identified MIPs with IEC 61499. IEC 61499 supports event-based execution and does not use global variables for interaction between software components. The FBs of IEC 61499 support encapsulation and reusability without any hidden dependencies. For our running example, 3 out of 4 MIPs were already available in IEC 61499. The missing pattern Content Filter was implemented using existing standard FBs at IEC 61499. Therefore, IEC 61499 is suitable for implementing PLC-software based on the PLC- Service bus architecture. Software components in our proposal are loosely coupled. Our implementation gives freedom to test and deploy components independently, e.g., to adapt any new requirements if needed, and the implementation details are hidden behind the interface of the software component. MIPs are grouped in five categories [6], (i) Message Construction, (ii) Message Channel, (iii) Message Endpoints, (iv) Message Routing, (v) Message Translation. From our identified MIPs for the capping station, the first two are from Message Construction, the third is from Message Channel, and the last is from the Message Translation. There are 35 MIPs distributed among these groups. Therefore, it is quite impossible to have all of them in one single machine. The presence of MIPs is highly dependent on the individual machine and its processes. However, the approach presented in this paper could be used as a guideline to identify and implement MIPs in any PLC-software. MIPs of the PLC-Service bus are inspired by existing interaction patterns available in the enterprise domain. Therefore, if a MIP cannot be implemented in IEC 61499, we could identify a state of art middleware solution from the enterprise domain that supports it. The identified middleware solution needs to be evaluated with respect to the PLC-Service bus architecture requirements and, if successful, implemented via Service Interface Function Blocks (SIFBs). SIFB is a special FB in IEC 61499 that supports external events in IEC 61499’s PLC-software. For SIFBs, only the interface is defined; the internal implementation of a SIFB should be manually written in C++, the language in which 4diac FORTE is built. In this paper, we consider a static subscription model for the implementation, which means that all the required events are subscribed before the start of the process at the capping station. This subscription model could result in a performance bottleneck for a PLC handling a large machine application. A dynamic subscription model, which means subscribing when needed and unsubscribing when the interaction is over, can improve the system performance. Our implementation is described considering that the process works as expected without errors. However, two situations can lead to inconsistent status. First, when the events dispatched by the software components in a specific order do not arrive in the expected order (e.g. because latency or performance issues). Another inconsistent situation would be, when an event does not arrive at the receiver side or does not get published at all. We need to handle these situations to have an industrial acceptable solution based on the PLC- Service bus architecture. A separate monitoring component or facility at the PLC-Service bus would be helpful to identify the aforementioned situations. In the case of more complex event flows (event sequences, filters, etc.), the support for complex event processing should be implemented. The granularity of the software components can be reviewed depending on the interaction patterns, performance, etc. More research is needed in order to address the limitations addressed above. Once the PLC-Service bus architecture addresses these limitations, it would improve the overall flexibility, modularity, and adaptability of PLC-software. VIII. CONCLUSIONS AND FUTURE WORK The PLC-Service bus architecture enables flexible and adaptable production systems by utilizing decoupled interaction between software components of PLC-software. A straightforward way of displaying these interactions has not been addressed until now. Therefore, there are not guidelines to implement this concept in reality. With this paper we are addressing these issues. We use EPC, a well-known modelling technique used in the business process, to show interactions between software components. We used the capping station from the VDMA R+A OPC UA Demonstrator as a running example. We show the interaction between various software components of the capping station as an EPC model. With that model, we identified MIPs by referring to available MIPs from the PLC-Service bus. We match these identified MIPs to the available patterns in IEC 61499. This paper used 4diac IDE from Eclipse 4diac project as a programming tool for IEC 61499. Missing patterns that are not available in IEC 61499 are implemented with 4diac IDE. After that, the overall IEC 61499 application of the capping station based on MIPs of the PLC-Service bus architecture was implemented. Future work should evaluate available message brokers and middlewares and bring the learning to have more MIPs available in IEC 61499. Future research on dynamic registration of a software component could provide benefits to add or remove software components on-fly. Dynamic subscription of an event is also on our list of future work. REFERENCES [1] P. Gsellmann, M. Melik-Merkumians, A. Zoitl, and G. Schitter, “A novel approach for integrating iec 61131-3 engineering and execution into iec 61499,” IEEE Transactions on Industrial Informatics, vol. 17, no. 8, pp. 5411–5418, 2021. [2] V. Ashiwal, A. Zoitl, and M. Konnerth, “A service bus concept for modular and adaptable plc-software,” in 2020 25th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), vol. 1, 2020, pp. 22–29. [3] “Programmable controllers-part 3: Programming languages,” International Electrotechnical Commission, Standard IEC 61131-3:2013. [4] A. Zoitl, T. Strasser, C. Sunder, and T. Baier, “Is iec 61499 in harmony with iec 61131-3?” IEEE Industrial Electronics Magazine, vol. 3, no. 4, pp. 49–55, 2009. [5] M. Papazoglou and W. van den Heuvel, “Service oriented architectures: Approaches, technologies and research issues,” Very Large Database Journal, vol. 16, no. 3, pp. 389–415, 2007. [6] V. Ashiwal and A. Zoitl, “Messaging interaction patterns for a service bus concept of plc-software,” in 2021 26th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA ), 2021, pp. 1–8. [7] A.-W. Scheer, O. Thomas, and O. Adam, Process Modeling using Event-Driven Process Chains. John Wiley & Sons, Ltd, 2005, ch. 6, pp. 119–145. [Online]. Available: https://onlinelibrary.wiley.com/doi/ abs/10.1002/0471741442.ch6 [8] P. Zimmermann, E. Axmann, B. Brandenbourger, K. Dorofeev, A. Mankowski, and P. Zanini, “Skill-based engineering and control on field-device-level with opc ua,” in 2019 24th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), 2019, pp. 1101–1108. [9] W. van der Aalst, “Formalization and verification of event-driven process chains,” Information and Software Technology, vol. 41, no. 10, pp. 639–650, 1999. [Online]. Available: https://www.sciencedirect.com/ science/article/pii/S0950584999000166 [10] W. Dai and V. Vyatkin, “Redesign distributed iec 61131-3 plc system in iec 61499 function blocks,” in 2010 IEEE 15th Conference on Emerging Technologies Factory Automation (ETFA 2010), 2010, pp. 1–8. [11] W. W. Dai and V. Vyatkin, “A case study on migration from iec 61131 plc to iec 61499 function block control,” in 2009 7th IEEE International Conference on Industrial Informatics, 2009, pp. 79–84. [12] M. Wenger and A. Zoitl, “Re-use of iec 61131-3 structured text for iec 61499,” in 2012 IEEE International Conference on Industrial Technology, 2012, pp. 78–83. [13] M. Hofmann, M. Rooker, and A. Zoitl, “Improved communication model for an iec 61499 runtime environment,” in ETFA2011, 2011, pp. 1–7. [14] W. Huang, W. Dai, P. Wang, and V. Vyatkin, “Real-time data acquisition support for iec 61499 based industrial cyber-physical systems,” in IECON 2017 - 43rd Annual Conference of the IEEE Industrial Electronics Society, 2017, pp. 6689–6694. [15] “4diac documentation.” [Online]. Available: https://www.eclipse.org/ 4diac/en dow.php [16] F. Andr´ en, T. Strasser, A. Zoitl, and I. Hegny, “A reconfigurable communication gateway for distributed embedded control systems,” in IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics Society, 2012, pp. 3720–3726. [17] F. Weehuizen and A. Zoitl, “Using the cip protocol with iec 61499 communication function blocks,” in 2007 5th IEEE International Conference on Industrial Informatics, vol. 1, 2007, pp. 261–265.