mINA-DL: A novel description language enabling dynamic reconfiguration in industrial automation

mINA-DL: A Novel Description Language Enabling Dynamic Reconfiguration in Industrial Automation Michael Wienke Fraunhofer IOSB-INA Competence Center Industrial Automation Langenbruch 6, 32657 Lemgo, Germany [email protected]

Sebastian Faltinski inIT - Institut Industrial IT OWL University of Applied Sciences Liebigstr. 87, 32657 Lemgo, Germany [email protected]

Oliver Niggemann Fraunhofer IOSB-INA Competence Center Industrial Automation Langenbruch 6, 32657 Lemgo, Germany [email protected]

J¨urgen Jasperneite inIT - Institut Industrial IT OWL University of Applied Sciences Liebigstr. 87, 32657 Lemgo, Germany [email protected]

Abstract Production facilities have to cope with fast changing market demands—leading to a need for high adaptability of the manufacturing plant. Especially the manual adaption of the automation systems causes high costs and significant downtimes. Here, an approach for an automatic adaption of the automation system is presented. The major challenges for an automatic adaptability of the automation system are (i) dynamically modifiable networks, (ii) a real-time middleware transporting variables within the network independently of the automation topology, and (iii) a semantic-based mechanism that allows one plant module to identify which signals are needed from another module. This paper describes a real-time middleware for industrial automation (mINA). It focuses especially on problem (iii), the mechanism to discover and identify required process signals. The functionality is based on a newly defined description language (mINA-DL), i.e. the middleware can use further semantic information about the signals. The middleware (ii) communicates by means of a real-time publish/subscribe concept and provides OPC UA compliance which also allows an easy integration with the manufacturing execution system (MES). Furthermore, a first prototypical implementation of the middleware is described and assessed using a test environment.

1. Introduction The situation of today’s production facilities is affected by an increase of product variants, a shortening of product life cycles, and an international competitive situation [6]. So the production facilities have to provide a high adaptability to react on fast changing customer demands in a cost efficient way.

At present, modular production facilities are composed of several intelligent Process Modules (PM). A PM represents a mechanical unit and an intelligent control device. Each control device can be connected to I/O-modules via an industrial network or directly to sensors/actuators. A control algorithm, programmed e.g. in an IEC 61131 consistent way, is downloaded to the control device, to control the mechanical unit of the PM. An example of a use case containing three PMs is illustrated in figure 1. The PMs are part of the ”Lemgoer Modellfabrik”, a research plant for handling bulk goods [10]. PM ”Filling” fills bottles with bulk good and transports PM Filling

PM Conveyor Signal exchange

PM Robot Signal exchange

Figure 1. A use case containing three PMs them to PM ”Conveyor”. Subsequently, the bottles are conveyed to the end of the conveyor belt of PM ”Conveyor” and stopped. Then, PM ”Robot” can start the robot to pick up the bottles. Typically the PMs are manufactured by different vendors. To coordinate the holistic production process, individual PMs have to communicate with each other. Referring to the example, PM ”Filling” needs a signal from PM ”Conveyor” that the bottles can be transported to PM ”Conveyor”. But the individual PMs are designed independently which leads to several problems when a plant and its automation system are changed: 1. When PMs are added, changed, or removed, the network configuration must be changed leading to dynamically configurable networks.

3. But with independently developed PMs, one PM’s control device can not know about the variable names used by another PM’s control device. Therefore, a mechanism is needed that allows one control device to identify dynamically all needed signal names in the network.

2

State of the art

In the last years, different middleware projects have been initiated to provide a solution for distributed systems in automation applications. The main differences generally appear in the communication model and in the way the information is represented and exchanged. A good overview can be found in [4]. A number of certain notably TCP/IP- or UDP/IP-based projects are SOCRADES [1], SODA [3] or CORBA [8]. Furthermore, some real-time enabled middleware projects exist like CORBAe [9], OSA+ [11]. In addition, the IEC 61499 [13] describes a standard for distributed industrial control and is adopted in the 4DIAC project [12]. But all mentioned solutions are not designed to enable a dynamical signal identification. The semantic identification using a description language is the key component to enable an automatic reconfiguration process leading to an entire different basis than all mentioned middlewarebased projects consist of. The IEC 61850 Part 6 [5] considered as a concept for an automation system in general defines a Substation Configuration description Language (SCL). But the SCL allows only the exchange of a configuration description.

3

Concept

This section describes the design of our real-time middleware-based concept for industrial automation. As a precondition to the new concept, the PM topology has to be known. PM topology means the physical assembly of PMs in a production line. This information can be considered as a graph, where every PM is aware of its neighbors. The neighboring information has to be provided manually, e.g. by a tool. The middleware provides the ability for a dynamical reconfiguration. In this case reconfiguration means adding, removing or exchanging PMs leading to a different PM topology. The new PM topology has to be updated with the tool and afterwards the dynamic signal identification can take place. A schematic overview of the concept is presented in figure 2. Each control application of a PM Engineering Tool

Engineering Tool

Control Application

Control Application

Download Runtime Environment Process Module 1

Additionally, all PMs have to be integrated vertically within the production facility to be accessible from higher level IT-systems such as manufacturing execution systems (MES). This paper introduces a novel concept for a real-time middleware to support automatic reconfiguration in the field of industrial automation. The main challenges is the ability to automatically integrate new, not pre-planned PMs in the holistic production process using a newly defined description language mINA-DL. Section 2 presents the state of the art followed by the middleware concept in section 3. Afterwards, the new description language mINA-DL is introduced and first prototypical implementations are illustrated in section 5. Thereafter, a conclusion and an outlook is given in section 6.

A good overview about agent-based control and holonic manufacturing systems (HMS) can be found in [6]. But the combination of a dynamic network configuration, name-based signal exchange of different control applications in IEC 61131 and an automatic signal identification based on a special description language does not exist to the best of our knowledge.

Export

Export

PM Description

PM Description

Management Agent

Download Runtime Environment

Management Agent

Publish Agent

Discovery / Subscription Agent

Publish Agent

Discovery / Subscription Agent

OPC UA Server

OPC UA Client

OPC UA Server

OPC UA Client

Process Module 2

2. Control applications (e.g. in IEC 61131) refer to specific statically assigned signals—usually network signals—for communicating with other control or I/O-devices. But with changing network configurations, this approach is not possible anymore. Instead, control applications should refer to variables defined by network-independent symbolic names, e.g. ”following module ready”. A real-time middleware could take care of the transport of these variables between the control devices.

Signal Identification Name-based Real-Time Publish/Subscribe Middleware Communication with MES- or ERP-level

Figure 2. Overview of the new concept is programmed using an engineering tool and downloaded to the runtime environment. This procedure is sufficient for a single PM. But within a production line containing more than one PM, the different PMs have to communicate with each other via an inter-PLC communication. So all additional information needed for an automatic signal identification within the network is modeled as a PM description file. The basis for the signal identification is a newly defined description language which is presented more precisely in section 4 (solution to problem 3). The description file itself contains the information in a XMLbased format. E.g. a new PM is added to the network, the management agent reads the PM description and separates the net-

work signals in two categories. 1. Signals provided for other PMs 2. Signals required from other PMs Afterwards, the management agent forwards the signals provided for other PMs to a publish agent. The publish agent starts a server using the OPC UA [2] information model and the signals can be accessed by other PMs in the network. Correspondingly, the management agent forwards the signals required from other PMs to a discovery/subscription agent. The agent initializes an OPC UA compliant client and starts a discovery to firstly find other servers in the network (solution to problem 1) and secondly establish a name-based subscription to the required signals (solution to problem 2) after the signal identification has finished. The signal exchange is realized using a real-time publish/subscribe mechanism.

4

Description Language

This section describes the newly defined description language mINA-DL that enables an automatic signal identification. The main difficulty exists in establishing a relationship between signals of different PMs which are not known at production time of the PMs. In later use cases, a PM shall be assembled in different production lines without the need of manually integrating the signals of a PM into the automation system. The signal integration shall be done automatically through the description language and a signal identification process. Each signal, that has to be exchanged between different PMs in the network, has to be described with the description language. An extract is illustrated in table 1. The additional information is classified in functionalities, Functionality Attribute Signal Type Sensor, Actor, N/A Measuring Position, Temperature, Velocity, Acceleration, Current, Voltage, ... Controlling Motor, Cylinder, Valve, Heater, Linear Axis, ... Neighbor Preceding Module, Following Information Module Signal Ready, Emergency Stop Description Product Length, Width, Height, Weight, VeDescription locity, Volume, In-End-Position, ... Operating Activate-Preceding-Module, Characteristic Activate-Following-Module, Set-To-Preceding-Module, Set-To-Following-Module Module Following-Module-Necessary, Information Preceding-Module-Necessary, ... Table 1. Description Language mINA-DL whereas each functionality contains different attributes. E.g. the functionality ”Signal Type” determines whether

the signal represents a sensor, an actor or the functionality is not applicable (N/A). If the signal represents a sensor, than the functionality ”Measuring” can be used to specify more precisely what property is measured, e.g. a position, a temperature, etc. If the signal represents an actor, the functionality ”Controlling” is utilized to determine what kind of device the signal controls, e.g. a motor, a valve, etc. The functionality ”Neighbor Information” describes whether a signal is part of a preceding or a following module. This information is especially important for the identification process, because the attribute indicates where the matching algorithm has to look for the certain signal. The functionality ”Signal Description” is used for general signal information, e.g. a ready or an emergency stop signal. ”Product Description” describes properties of the produced good, e.g. physical properties or the location of the product. The functionality ”Operating Characteristic” defines properties that are important in respect to the production flow, e.g. if one signal shall have the ability to start a following module. Functionality ”Module Information” defines attributes for a whole module, e.g. whether a following module is mandatorily needed or not. Considering the use case of section 1, the transition between PM ”Filling” and PM ”Conveyor” shall be presented as an example. If the conveyor belt of PM ”Conveyor” is switched on, PM ”Filling” can start filling and transporting bottles. The corresponding parts of the module description are illustrated for PM ”Filling” in listing 1 and for PM ”Conveyor” in listing 2. PM_Filling varName1 Neighbor_Information Following_Module Signal_Description Ready

Listing 1. Description PM ”Filling” PM_Conveyor varName2 Signal_Description Ready

Listing 2. Description PM ”Conveyor” The description has to be assigned to the variables exchanged in the network during each PM’s design phase. The trigger for the signal identification is the XML-tag . The tag indicates that PM ”Filling” needs to find a signal in the network. The other tags of PM ”Filling” denote that the signal is part of the following module and that it represents a ready signal. So PM ”Conveyor” has to provide a signal which has the functionality ”Signal Description” with the attribute ”Ready”. The identification mechanism itself is based on a theorem prover. After finding the match, the variable varName1

of PM ”Filling” establishes a subscription with variable varName2 of PM ”Conveyor”. So every time the value of varName2 changes, the value of varName1 is overwritten with the current value of varName2 and the control application of PM ”Filling” uses the variable varName1 determining whether PM ”Conveyor” is ready or not. In general it is possible that a PM has more than one preceding or following PM. But in a first step, only line topologies are considered.

5

Prototypical Implementation

A mINA prototype has been implemented using an embedded runtime environment on two separated Industrial PCs. Each runtime executes a control application of a PM. Both devices establish a connection dynamically and exchange signals by using a name-based publish/subscribe mechanism (problem 2). Failures of the data exchange, e.g. disconnecting the devices, leads to a cyclic retry of re-establishing the connection. The WinPcap 4.1.2 library has been used to bypass socket communication and send/receive raw Ethernet frames. The focus of this paper is on the description language and the automatic identification of signals. The test environment was the ”Lemgoer Modellfabrik” [10]. The production line consists of two storage silos, a storage silo including a scale, a filling module, a conveyor belt, a pick’n’place robot and a production module. So far, it was possible to identify all 16 signals in the network. The signals were described with the introduced description language mINA-DL expressed in first-order predicate logic. The unification was calculated using a python script to start theorem prover prover9 [7]. By using predicate logic and a theorem prover, we use a sophisticated tool for an identification process. As a result, prover9 delivered the variable names of the desired signals, that can be used in a second step to establish a subscription. Each identification process took 91 ms on a 2.67 GHz CPU. An overview of the number of identified signals between adjacent PMs is illustrated in table 2.

6

Conclusion

We introduced a middleware for industrial automation (mINA). The main objective is the avoidance of costintensive manual adaption of process modules after a reconfiguration. The presented concept provides the following solutions: The middleware uses a mechanism that allows one PM to identify which signals are needed from other PMs. This is implemented using a newly defined description language mINA-DL. The network structure is designed to transport network variables independently of the automation topology and OPC UA compliant. On device level, a publish/subscribe communication model is used. First results are presented by implementing a prototype and presenting the applicability on a research plant. A name-based publish/subscribe communication was implemented and the results illustrate, that a dynamical identi-

Identified Signals Transition Silo 1 - Silo 2 3 Silo 2 - Silo 3 3 Silo 3 - Filling 3 Filling - Conveyor 2 Conveyor - Pick’n’Place Robot 2 Pick’n’Place Robot - Popcorn 3 Table 2. Signals between adjacent PMs fication of signals of different PMs was possible. Based on the results, further implementation steps will be introduced soon.

References [1] A. Cannata, M. Gerosa, and M. Taisch. Socrades: a framework for developing intelligent systems in manufacturing. In IEEE International Conference on Industrial Engineering and Engineering Management, pages 1904 – 1908, 2008. [2] M. Damm, S.Leitner, and W. Mahnke. OPC Unified Architecture. Springer-Verlag Berlin Heidelberg, 2009. [3] S. Deugd, R. Carroll, K. Kelly, B. Millett, and J. Ricker. Soda: Service-oriented device architecture. In Pervasive Computing, IEEE, pages 94–96, 2006. [4] W. Emmerich, M. Aoyama, and J. Sventek. The Impact of Research on the Development of Middleware Technology. ACM Transactions on Software Engineering and Methodology, 17(4):19:1–19:48, 2008. [5] International Electrotechnical Commission (IEC). IEC 61850-6 Communication networks and systems in substations Part 6: Configuration description language for communication in electrical substations related to IEDs, 2004. [6] P. Leitao. Agent-based distributed manufacturing control: A state-of-the-art survey. Engineering Applications of Artificial Intelligence, 22:979–991, 2009. [7] W. McCune. Prover9 and Mace4. http://www.cs.unm.edu/ ∼mccune/prover9/ (July 5, 2011). [8] Object Management Group (OMG). Common Object Request Broker Architecture (CORBA) Specification Version 3.1. http://www.omg.org/spec/CORBA/, 2008. [9] Object Management Group (OMG). Common Object Request Broker Architecture embedded (CORBA/e) Specification Version 1.0. http://www.omg.org/spec/CORBAe/, 2008. [10] OWL University of Applied Science, Lemgoer Modellfabrik. http://www.hs-owl.de/init/en/research/lemgoermodellfabrik.html (July 5, 2011). [11] F. Picioroaga, A. Bechina, U. Brinkschulte, and E. Schneider. Osa+ real-time middleware, results and perspectives. In 7th IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, 2004. [12] T. Strasser, M. Rooker, G. Ebenhofer, A. Zoitl, C. Sunder, A. Valentini, and A. Martel. Framework for Distributed Industrial Automation and Control (4DIAC). In 6th IEEE International Conference on Industrial Informatics, INDIN, 2008. [13] A. Zoitl, T. Strasser, K. Hall, R. Staron, C. S¨under, and B. Favre-Bulle. The Past, Present, and Future of IEC 61499. Holonic and Multi-Agent Systems for Manufacturing, 4659:1–14, 2007.