Why Cyber-physical Production Systems Need a Descriptive Engineering Approach – A Case Study in Plug & Produce

(1)

Procedia Technology 15 ( 2014 ) 295 – 302

Peer-review under responsibility of the Organizing Committee of SysInt 2014. doi: 10.1016/j.protcy.2014.09.083

ScienceDirect

2nd International Conference on System-Integrated Intelligence: Challenges for Product and

Production Engineering

Why cyber-physical production systems need a descriptive

engineering approach – a case study in plug & produce

Jens Otto

a

*, Steffen Henning

b

, Oliver Niggemann

a,b

a_{Fraunhofer IOSB-INA, Lemgo, Germany} b_{Institute Industrial IT inIT, Lemgo, Germany}

Abstract

Cyber-physical production systems' main feature is adaptability, i.e. they adapt automatically to new situations without impairing the system's goals. An example is a smart factory that can adapt to new product variants or production systems, as a result of which, it guarantees a minimum energy consumption in any production scenario. At the heart of this is the capability to generate the automation software based on new requirements, i.e. based on the product description.

Currently, two main solution philosophies exist to implement such an automatic software synthesis: 1. Compositional approaches generate the software by sticking predefined software components together.

2. Synthesis approaches generate the software from scratch based on models of the product and the production resources. We will outline and compare both solutions in-detail. Furthermore, the necessary models are described in this paper. Using examples from the field of manufacturing systems and from industrial automation, we will argue that only the second approach is suited to fulfil the promises of cyber-physical production systems.

Peer-review under responsibility of the Organizing Committee of SysInt 2014.

Keywords: cyber-physical production systems; descriptive engineering; synthesis

* Corresponding author. Tel.: +49 5261 9429034; fax: +49 5261/702-5969. E-mail address: [email protected]

(2)

1. Introduction

Plug & produce is a major use case for cyber-physical production systems (CPPS). Such systems and their automation systems adapt automatically to new scenarios such as new product variants or to new production modules. To implement such a plug & produce capability, a different engineering chain is needed: Automation engineers will specify production goals, i.e. products, instead of automation algorithms. But this solution methodology requires that the automation software is generated automatically based on these requirements – and that the software is not programmed manually any longer.

Figure 1 contrasts the two main solution approaches to generate this automation software: On the left-hand side, the compositional approach is outlined (cf. [1, 2, 3]). The software is generated by plugging predefined software components together. Such components could e.g. correspond to subsystems of the plant. On the right-hand side the alternative software synthesis approach, which is the focus of this paper, is outlined. In this approach, the software is generated from scratch by analysing the production goal. Both approaches also need knowledge about the production resources such as plant modules and available automation devices. In the case of our synthesis approach, the production resources are part of the semantic knowledge.

Product model Orchestration Product graph Software synthesis Software component Software component Software component Ressource description Semantic knowledge

Compositional approach Synthesis approach

Software component Software component Software component Automation software Automation software Control code

Fig. 1. Compositional versus synthesis approach.

In general, compositional approaches are better analysed and easier to implement. Their main application area so-far has been business software and large-scale software systems [2, 3]. In the last few years, these approaches have also been applied to industrial automation as discussed in [4, 5, 6, 7]. In these projects the orchestration has been done mainly by experts using manual engineering steps. The research question in this paper is not whether compositional software approaches can be applied to industrial automation systems, but whether it is possible to orchestrate them automatically.

The problem domain, CPPS, must fulfil some basic requisites for an automatic orchestration of software components that are described below:

No-Function-in-Structure: This principle goes back to de Kleer [8]. It states that the overall system behaviour can

be deduced from the behaviour of its parts. However, this is not possible in most cases. For example a pneumatic cylinder can be used in many different ways, although the behaviour of the cylinder is always the same, e.g. as selector, lift, tool positioning, fastener and more. To understand why this criterion must be fulfilled for the compositional approach, we have to make assumptions about the content of our software components. In most cases, such components correspond to subsystems and plant modules [4, 5, 6, 7] and the software components contain the corresponding automation and diagnosis algorithms. But in many CPPS cases, such subsystems are highly

(3)

inter-dependent. An example is the cycle time of subsystems that must be attuned or another example is the liquid pressure in process industry, which often propagates through the overall plant. This suggests that the software components must be modified to incorporate knowledge from the overall system behaviour. So-far, corresponding automatic software modification methods are not known, i.e. for most complex production systems this requisite is not fulfilled.

Fire-and-Forget: This criterion denotes the fact that the compositional approach assumes that the orchestration

can be computed directly and that the resulting solution does not need to be verified. Please note that any such solution can only be verified by executing it in the context of the overall plant (or in the context of a precise plant simulation). This is not realistic for most practical cases, since the necessary efforts are too high. Without such a verification, users will probably not trust the generated software, i.e. for most complex production systems, this requisite is not fulfilled either.

2. State of the art

In [9], several requirements towards CPPS are identified, as they will have a fundamental impact on our infrastructure. According to the author, CPPS must be able to handle unexpected conditions while remaining predictable. When using abstraction to ease the handling, specific user requirements such as timing still have to be assignable.

Classical engineering in automation is time consuming and error-prone. Also, it is not easily adaptable to changes. Several new approaches have tried to apply architectural patterns developed in software engineering, such as object oriented design [10, 11] or model-based engineering [12, 13].

A major trend are compositional approaches that rely on service orchestration. In [14], the granularity of such reusable components is investigated. The authors state that granularity depends on multiple aspects, such as conflicting requirements, differing disciplines and the type of engineering. Finer modelled components are tedious to search and broader ones may not be applicable in a specific context. Apart from components, [15] identifies connectors as a main aspect of a compositional approach. While components are the functional entities that have a corresponding hardware and software part, connectors define and control the communication between the components. In [16] mechatronic UML is presented. It focuses on a very extensive system modelling. These models can then be used for process orchestration. However, the primary application area of this approach are large systems because there is a notable overhead required to model the system. In [17], a semantic knowledge-base is used to guide the orchestration process. The authors assume a smart product that stores its processing steps. The service discovery and selection then looks for appropriate process steps and orchestrates them ad-hoc with respect to the product’s demands. While these approaches have advantages over the classical engineering, they still face some drawbacks. All of them require software blocks that can already perform the required action. If a new request is generated that cannot be mapped onto an existing process step, then these approaches cannot be used.

Another approach that uses self-organizing multi-agent systems is described in [18]. While this approach increases reliability due to distributed control, it still faces problems regarding real-time requirements.

The semantic approach is a promising candidate for modern automation engineering [17, 19]. However, a major problem of semantic approaches is the knowledge modelling. There is yet no feasible solution to model human expert or even general knowledge into a machine readable form. Although the resource description framework [20] and the web ontology language [21] concepts exist, there are still many open questions such as those concerning computational complexity and appropriate reasoning formalisms.

For above mentioned reasons, the automatic generation of compositional architectures is not a satisfying solution, at least for complex plants. Therefore, the following sections of this paper focus on the alternative synthesis approach.

In our descriptive approach, the engineer no longer has to deal with manual writing of the control code but instead just specifies “what” the system has to do. The “how” is then inferred by the system. Also, the knowledge modelling is reduced to an absolute minimum, describing only process relevant dependencies.

(4)

3. Plug & produce scenario

In general, the synthesis for control programs is only one of several tasks necessary for a plug & produce approach:

1. If modules are arranged in a new topology, real-time network channels must be established between them. This can either be done via a middleware for example Object Linking and Embedding for Process Control Unified Architecture (OPC UA) or by means of a dynamic configuration of real-time network systems [22].

2. Aggregation of all semantic module descriptions from modules.

3. Synthesis of control code. This step is the focus of this paper and is described in detail in the section descriptive engineering.

At this point it is useful to introduce a simple filling process, which is shown in Figure 2, to explain the concept of software synthesis for control programs (see section descriptive engineering). The goal of this filling process is to fill water into bottles. The water must be heated to 70 degree Celsius to kill the bacteria before it can be filled. The filling process is realised by three independent hardware modules: M1: heater, M2: filler and M3: transporter. It consists of four actuators (A1– A4) and four sensors (S1– S4), which are connected by three IO-devices to a central programmable logic controller (PLC). A1is a heating element, S1measures the temperature of the water, A2and A3 are valves, S2and S3are filling level sensors and A4is a transport with a light barrier S4. The used field bus is PROFINET. The three hardware modules can be substituted with other modules with the same or similar capabilities. The modular structure enables an easy modification of the system representing the general plug & produce idea. The demonstrator is developed in the “it's OWL IV” leading-edge cluster project (intelligent networking cluster project) promoted by the BMBF to demonstrate plug & produce capability.

S4 100 ml 1l S1 A2 S2 A3 A1 M3: transport er M2: filler M1: heater S3 Concept IO-Device 1 IO-Device 2 IO-Device 3 A4 PLC Synthesis SD1 SD2 SD3 Implementation

Fig. 2. Water filling demonstrator (left side concept, right side physical implementation).

Each module has a semantic module description (SD1-SD3). It uses the resource description framework to state the relations between subjects and objects. Each triple of subject, predicate and object represents one fact. For example, it is a fact that module M1can handle fluid products and that M1has a sensor S1and an actuator A1. S1 measures the effect of A1. S1has a bus address BA1and S2has a bus address BA2.

Moreover each module has a pre-learned hybrid timed automaton that describes the time behaviour. Figure 3 illustrates the learned hybrid timed automaton of the heating module M1. In [23], hybrid timed automata are identified as a crucial class of models for technical systems such as production plants. It also introduced an algorithm called HyBUTLA that can be used to learn a hybrid timed automaton from observations automatically. However, when combining multiple modules, the corresponding timing behaviours of the single modules may not be the same in the combined system as mentioned in the introduction (cf. no-function-in-structure). Therefore, it is mandatory to check for possible timing changes in the combined system.

(5)

1 A1=0; 2 (208, 220)

A1=1; (1,1)

Hybrid timed automaton

A1=1

Fig. 3. Hybrid timed automaton of the heating module. 4. Descriptive engineering

This section introduces the concept of software synthesis for our approach. The goal of this approach is to describe only the required intermediate products (what should be produced) in order to make the human-machine interface more natural to the user. The engineer no longer has to specify a step-by-step procedure requiring not only a high procedural but also a very sophisticated programming knowledge. The control code is synthesised by stating the goals of the automation system. This moves the engineering focus back to pure process knowledge and frees time and effort for optimisation of the process.

Next, the required steps to synthesise a control program for the above explained plug & produce scenario will be presented. Followed by a detailed description of each step, which is shown in Figure 4 (right side). The following steps are needed to synthesise control programs:

1. Inference engine infers a sequence model with the aid of semantic process knowledge and the product graph. 2. Predictor predicts synchronised signals.

3. Learner learns an initial predicted hybrid timed automaton of the overall system. 4. Execution executes the predicted hybrid timed automaton.

5. Learner learns a new hybrid timed automaton from the observed data.

1. Product graph T1 T2 B1 P1: Water 1 litre 20 degree Celsius P2: Water 1 litre 70 degree Celsius P4: Water 100 ml 70 degree Celsius P3: Bottle 120 ml Step 4: Execution Step 2: Predictor Step 1: Inference engine Sequence model Step 3/5: Learner Synchronised signals

Synchronised signals Hybrid timed automaton

2. Synthesis

(6)

In our approach, the goal description is a product graph. A product graph consists of intermediate products P, a set of transitions T and a set of bindings B. Furthermore, intermediate products consist of physical properties like the amount, temperature et cetera. A transition connects intermediate products logically and represents property changes. A binding describes changes that are not expressible by property changes. Figure 4 (left side) illustrates the product graph to describe the exemplary filling process.

Step 1: The inference engine requires semantic process knowledge, the product graph, and the set of available

module descriptions. An excerpt of the semantic process knowledge is depicted in Table 1. Combined with the product graph, the inference engine can now infer the required process steps that result in a sequence model. For example, the product graph states that it starts with one litre of water that has a temperature of 20 degree Celsius. This product somehow has to be transformed into 1 litre of water with a temperature of 70 degree Celsius. The inference engine concludes that the property temperature has to change and looks for module descriptions, which are able to perform this task. The module description of the heating module states that it can increase the temperature of a liquid and thus the inference engine can infer that it has to select this module to transform the product accordingly.

Table 1: Excerpt of semantic process knowledge subject predicate object

water is liquid liquid has temperature

…

Following this procedure, the engine further infers all other steps that are required. Finally it will produce the sequence: heater, filler, transporter, which corresponds to the sequence model: (A1, A2, A3, A4). The sequence model

is then forwarded to the process predictor. The inference engine is also able to infer state transition conditions from the product graph, e.g. stop heating when the temperature reaches 70 degree Celsius.

Step 2: The predictor predicts synchronised signals of the given sequence model. For each actuator inside the

sequence model, the time is predicted by a pre-learned hybrid timed automaton of each module. The output for our system is shown in Table 2.

Table 2: Synchronised signals

Time A1 A2 A3 A4 Module Condition 0 1 0 0 0 heater S4== true

208 0 1 0 0 filler S1>= 70

310 0 0 1 0 filler S2== true

320 0 0 0 1 transporter S3== true

Step 3: The learner uses the input from step 2 to learn an initial hybrid timed automaton. The learning is done

with the HyBUTLA algorithm. The basic idea behind HyBUTLA is to gather several automation system cycles with their corresponding timing information, which are provided by the synchronised signals. Then, a non-cyclic graph is constructed and a state merging is performed to match identical and to some extent similar states together. This learned hybrid timed automaton is the input for step 4.

Step 4: Before execution, the hybrid timed automaton is transformed into control code. Each transition has a

sensor condition. If the condition is true then the state will be changed, and the actuators will be enabled or disabled. The sequence starts with an enabled heater. If sensor S1reaches the expected 70 degree Celsius, the heater will be

disabled and the valve A2opens. Valve A2will be closed if sensor S2is activated. Valve A3will be opened and then

closed again if S3detects the empty filling state. At the end, the transport band positions a new bottle under the

valve. Then the sequence starts again. This cycle produces new synchronised signals, which are the input for step 5.

Step 5: The generated synchronised signals are used to generate a new hybrid timed automaton. The newly

generated hybrid timed automaton reflects the real time behaviour of the filling process. Figure 5 shows the result of this step. The hybrid part of this automaton is not shown in the figure. It is contained within each state representing the physical properties of the actuator of each state. For example, the heating progress of a specific amount of water for the heater.

This hybrid timed automaton represents the control sequence of the production system. The actual code is generated from this automaton. In contrast to the compositional approach, which combines already existing software

(7)

blocks, the synthesised code does not need to be verified. Just like in compiler construction, where only the compiler is verified and not each compiled program.

The timing information of the automaton can further be used for optimisation and to check for anomalies in a running process. Since the default behaviour is specified in the automaton, therefore anomalies are deviations from this behaviour. 1 2 3 4 S1 >= 70 A1=0; A2=1; (208,220) S2 == true A2=0; A3=1 (2,3) S3 == true A3=0; A4=1 (2,3) S4 == true A4=0; A1=1; (1,1)

Hybrid timed automaton

Fig. 5. Resulting hybrid timed automaton. 5. Summary and future work

This paper has presented a novel approach for automation system engineering. It applies a descriptive view rather than the well-known classical imperative or the compositional view. The classical view, i.e. manual coding of control programs is still wide spread but error-prone and time consuming. Although the compositional approaches promote reusability and a decrease in integration time, however they require an extensive software block library that still has to be programmed manually at some point.

Our approach does not need these software blocks. The synthesis approach only requires a semantic knowledge base and a product model to create a hybrid timed automaton of the system, which can then be transformed to software code automatically. Code synthesis for timed automata is handled, for example in [24]. Additionally, the automaton can be used for a continuous verification and automatic process control during run-time. The modelling process is also simplified, since only the normal behaviour has to be specified. Any anomaly will be automatically detected as exception with the use of an automaton describing the normal behaviour and the HyBUTLA algorithm. These exceptions can be prevented either using safety measures or a default reaction can be specified for them.

The development of our descriptive engineering approach has just started and some challenges still remain. The approach was initially constructed for a water filling station but as a next step it will be transferred to the Lemgo Model Factory (LMF) [25], which is a more complex system. The LMF is closer to a real production system, consisting of a complex supply chain and three processing modules. Also, the error handling is still an open point that will be dealt with. Although this approach still has to be verified for larger systems, but the results suggest that it is suitable for such scenarios.

Acknowledgements

This research and development project is funded by the German Federal Ministry of Education and Research (BMBF) within the leading-edge cluster “Intelligent Technical Systems Ostwestfalen-Lippe” (it's OWL) and managed by the Project Management Agency Karlsruhe (PTKA). The author is responsible for the contents of this publication.

References

[1] Niggemann O, Stroop J. Models for model's Sake: why explicit system models are also an end to themselves. In: ICSE 2008; 561-570. [2] Rossi D, Turrini E. Using a process modeling language for the design and implementation of process-driven applications. In: ICSEA 2007; 55. [3] Strosnider JK, Nandi P, Kumaran S, Ghosh SP, Arsnajani A. Model-driven synthesis of SOA solutions. IBM Systems Journal 2008;

47(3):415-432.

(8)

[5] Dürkop L, Imtiaz J, Trsek H, Wisniewski L, Jasperneite J. Using OPC-UA for the autoconfiguration of real-time Ethernet Systems. In: INDIN 2013; 248-253.

[6] Loskyll M. Entwicklung einer Methodik zur dynamischen kontextbasierten Orchestrierung semantischer Feldgerätefunktionalitäten. Kaiserslautern: Universität Kaiserslautern; 2013.

[7] Legat C, Schütz D, Feldmann S, Lamparter S, Seitz C, Vogel-Heuser B. Wandlungsfähige Automation auf Knopfdruck - Assistenz für die modellbasierte Softwareentwicklung. atp edition 2013;5:30-39.

[8] de Kleer J, Brown JS. A framework for qualitative physics. In: Proceedings of the Sixth Annual Conference of the Cognitive Science Society 1984;11-18.

[9] Lee EA. Cyber Physical Systems: Design Challenges. In: ISORC 2008; 363-369.

[10] Thramboulidis K. IEC 61131 as Enabler of OO and MDD in industrial automation. In: INDIN 2012; 425-430.

[11] Secchi C, Bonfé M, Fantuzzi C, Borsari R, Borghi D. Object-Oriented Modeling of Complex Mechatronic Components for the Manufacturing Industry. IEEE/ASME Transactions on Mechatronics 2007;12(6):696-702.

[12] Thieme J, Hanisch HM. Model-based Generation of Modular PLC Code using IEC 61131 Function Blocks. In: ISIE 2002; 1:199-204. [13] Thramboulidis K, Frey G. Towards a Model-Driven IEC 61131-Based Development Process in Industrial Automation. JSEA 2011;

4(4):217-226.

[14] Maga C, Jazdi N, Göhner P. Reusable Models in Industrial Automation: Experiences in Defining Appropriate Levels of Granularity. In:

IFAC 2011; 9145-9150.

[15] Estévez E, Marcos M, Orive D. Automatic generation of PLC automation projects from component-based models. International Journal of Advanced Manufacturing Technology 2007;35:527-540.

[16] Becker S, Dziwok S, Gewering T, Heinzemann C, Pohlmann U, Priesterjahn C, Schäfer W, Sudmann O, Tichy M. MechatronicUML -Syntax and Semantics. Paderborn: University of Paderborn; 2011.

[17] Loskyll M, Heck I, Schlick J, Schwarz M. Context-Based Orchestration for Control of Resource-Efficient Manufacturing Processes. Future Internet 2012; 4(3):737-761.

[18] Folmer J, Schütz D, Schraufstetter M, Vogel-Heuser B. Konzept zur Erhöhung der Flexibilität von Produktionsanlagen durch Einsatz von rekonfigurierbaren Anlagenkomponenten und echtzeitfähigen Softwareagenten. Echtzeit 2011; DOI: 10.1007/978-3-642-24658-6_14. [19] Malec J, Nilsson A, Nilsson K, Nowaczyk S. Knowledge-Based Reconfiguration of Automation Systems. In: CASE 2007; 170-175. [20] W3C. Resource Description Framework (RDF). Web source: “http://www.w3.org/RDF/”; 2004; last accessed: February 2014. [21] W3C. Web Ontology Language (OWL). Web source: “http://www.w3.org/2001/sw/wiki/OWL”; 2012; last accessed: February 2014. [22] Dürkop L, Trsek H, Jasperneite J, Wisniewski L. Towards Autoconfiguration of Industrial Automation Systems: A Case Study Using

PROFINET IO. In: ETFA 2012; 1-8.

[23] Niggemann O, Stein B, Vodencarevic A, Maier A, Kleine Büning H. Learning Behavior Models for Hybrid Timed Systems. AAAI 2012; 2:1083-1090.

[24] Amnell T, Fersman E, Pettersson P, Yi W, Sun H. Code synthesis for timed automata. Nordic Journal of Computing 2002;9(4):269-300. [25] University of Applied Sciences OWL. Lemgoer Modellfabrik. Web source: