who are familiar with the FB approach to develop the plant model without ... analysis for example to calculate the dynamic graph - i.e., ... Since initially there is only one token, the sum of the ..... tures access to any internal variable of the PLC i.
Closed-loop System Modeling, Validation, and Verification Sebastian Preuße, Hans-Christian Lapp and Hans-Michael Hanisch University of Halle-Wittenberg Institute of Computer Science, Chair of Automation Technology Theodor-Lieser-Straße 5, 06120 Halle (Saale), Germany {sebastian.preusse, hans-christian.lapp, hans-michael.hanisch}@informatik.uni-halle.de
Abstract Control software engineering has become a weighty factor according to implementation expense, especially when developing a new plant or migrating an existing one. Because of this, there are high customer demands concerning safety and correctness of software. Conventional open-loop testing methods have clearly reached their limits as the complexity of today’s control software is not manually manageable anymore. Nevertheless, they still belong to daily practice due to the lack of integrated solutions that do not overcharge users but that are tailored to software engineering demands. This contribution therfore approaches this problem and encourages the application of closed-loop modeling, validation, and verification methods. Beyond this, it proposes complete frameworks to apply this expertise not only in academia but in industrial environment as well.
1
Introduction
Actually, it is not necessary to mention that control software is by no means just a by-product, when developing a new plant, but it is a real cost factor that accounts for engineering charges. Because of this, it is of high significance to apply systematic approaches that support software implementation. Originally developed as a guideline for software development in general, the V-Model, the Spiral Model, or the Waterfall Model are also accepted by the plant engineering domain. Summarized by the term Model Driven Engineering (MDE) [4], they are gradually applied as frameworks to implement control software. Nevertheless, the possibilities of MDE approaches are yet not fully-exhausted because it is daily practice that the controller or its model is considered in an open loop. This view on a system seems to be astonishing, since it is contrary to the configuration in reality. Nobody would implement a controller without a physical process that shall be controlled and for this, it appears to be natural to regard not only the controller logic but also its interaction with the technical process. A comprehensive work concerning the topic of applica-
tion of MDE in a closed loop is published by a former member of the authors’ work group in [10]. The contribution demonstrates the advantages of systematic modeling for model-driven controller design, simulation, verification, and finally automatic control code implementation. The application of the Systems Modeling Language (SysML) builds bridges from academic advances in research and practicability in workaday life of engineers, as this intuitive language is established in many engineering domains. This contribution picks up the idea and shows the application of formal methods to develop correct control applications. The main concern, as already mentioned in the title, is of course the consideration of the closed-loop system. It is therefore structured as follows. Section 2 lists related works concerning closed-loop modeling and analysis and compares them to the approach of this contribution. The modeling formalism, which is applied to perform closedloop verification is introduced in Section 3, subsequently. Section 4 discusses closed-loop modeling and emphasizes the need for considering controller and plant separately. Afterwards, the frameworks for simulation and verification are presented in Sections 5 and 6, respectively. Section 7 lists some practical applications of the presented frameworks and finally, the contribution is concluded in Section 8.
2
Related Work
There are numerous approaches dealing with MDE. However, the majority focuses only on the controller and disregards the plant or its model respectively. Hence, simulation or verification is performed in an open loop, providing “meaningful” input information to the controller. This procedure may work for non-functional requirements, such as safety properties, but limits are quickly revealed when considering functional properties, since test cases for production sequences become harder to synthesize the more complex requirements get. In contrast, considering also a model of the process, which shall be controlled, is a pretty elegant way to test for a correct implementation. The following survey provides an overview of existing approaches according to closed-loop simulation
Copyright: 17th IEEE International Conference on Emerging Technologies and Factory Automation
and verification. The authors of [2] present a Mixed Hardware-in-the-Loop (HiL) Simulation approach, where plant simulation and hardware controller are interconnected. The control code does not need to be complete because the missing functionalities are simulated as well and translated to control code, afterwards. This procedure enables step by step testing of the control software and finding possible errors in smaller code fractions. To do so, the SImulation of Model-Based Automation systems (SIMBA) tool was implemented to model and simulate the plant, and to develop the controller model for newly-added functionalities. Finally, the software translates the controller model to control code so that the complete control software is provided. In [15], the authors propose HiL Synchronous Simulation of hybrid automation systems in the operational phase. For this, the plant is modeled with the Siemens1 Machine Simulator. Simulation and real plant run in parallel and are controlled by a Soft PLC in a HiL Simulation. This procedure allows monitoring the real plant and evaluating data consistency by comparing the estimated plant states to the current ones. The scientific community also deals with Software-inthe-Loop (SiL) Simulation not least because it is vendorand hardware-independent. The Modelica Modeling Language2 provides a huge set of possibilities to describe physical systems in terms of equations, which are dynamically solved during a simulation process. The authors of [27] model the plant with differential equations and the controller with StateGraph [19], which is a description tool based on a library that enables transferring Hierarchical State Machines to Modelica code. The test cases are directly implemented within the controller model. Doing so, the closed-loop model can be analyzed according to desired and forbidden behavior and furthermore, performance consideration can be evaluated. The authors of [17] consider the validation of a controlled continuous process. The work is part of the Model-based Integrated Development Environment for Industrial Process Measurement and Control Systems that is focused mainly on the integration of heterogeneous software environments. In their contribution, the authors use Simulink3 to model a continuous process and ISaGRAF Enhanced4 to implement and execute the corresponding control software. Both software environments are interconnected via the tool COBRA to obtain co-simulation between the PLC programming software and the process simulation tool. COBRA generates test cases automatically and applies them to the simulated industrial control system in a SiL Test. Since Simulink is a widely-used software tool to
model continuous and dynamic processes, the presented work is very valuable to validate the corresponding control software. In [30], the authors apply Simulink as well to model the behavior of Smart Grid systems. The model of such a power distribution system is interconnected to an IEC 61499 Function Block (FB) execution environment via a TCP/IP communication channel to establish a closedloop simulation. The approach is tailored especially to the problems of distributed controllers and their reaction to energy system failures. However, it shows the application of SiL Simulation of automation processes in a comprehensive way. The authors of [9] present the MEDEIA Simulation Concept. They model plant behavior with IEC 61499 FBs and interconnect this model with IEC 61499 controller FBs. The approach extends the application of the IEC 61499 standard, as it has actually been developed to create control applications. It allows control software engineers, who are familiar with the FB approach to develop the plant model without additionally-required knowledge. In [11], plant modeling with FBs has already been presented by another workgroup. However, it turned out that it would be of disadvantage if plant and controller were modeled by the same person with the same tool because modeling errors would propagate. For this, both tasks should be separated to exclude ordinary “copy-paste-errors” or misunderstandings according to the technical specification. The presented approaches apply different procedures to model closed-loop systems. Although most of them have the capability to perform formal verification as well, they are only employed for simulation, due to their focus on industrial applications. Nevertheless, the authors of this contribution want to emphasize that just this point offers essential benefits regarding safety of manufacturing systems. For this, the following sections discuss different frameworks, established to test and verify the correct functionality of control systems by considering the closed loop of a plant and a controller.
3
Modeling Formalism
Discretely-Timed Net Condition/Event Systems (D TNCES ) [5, 18] are applied to model discrete event systems in a hierarchical and component-based way. Considering time as discrete results in a finite system’s state space and makes analysis manageable. The design of larger systems out of smaller modules is common to engineers. For this, D TNCES are a very intuitive modeling formalism, since modules describing basic functionalities are stepwise composed to a whole system model. The modularity enables the development of a library of frequently-used modules that can be used in other system modules again. This is of advantage especially when deriving formal plant models from informal simulation models as described in [5, 21]. Beyond this, the formal basis of D TNCES allows to apply formal
1 Siemens website. URL, http://www.industry.siemens.com, April 2012. 2 Modelica Language Specification v3.1. URL, http://www.modelica.org, April 2012. 3 The MathWorks website. URL, http://www.mathworks.com/, April 2012. 4 ISaGRAF website. URL, http://www.isagraf.com/, January 2012.
2
controller inputs
controller outputs
cylinder extend ci1
extended eo3
workpiece ei1
t1 Extended p1
OFF - Move p2 [10; ∞] t3
controller
not_retracted eo2
t2 [10;∞] Retracted p3
t4
retracted co1
plant sensors
plant actuators
retracted eo1 not_extended eo4
retract ci2
plant extended co2
Figure 1. D TNCE Module of a cylinder. analysis for example to calculate the dynamic graph - i.e., the set of all reachable states and state transitions of a D TNCES - or to predict the behavior of a system under control. Originally, the timing concept and the means for dynamic graph computation were defined for (ordinary) Petri nets [8] and have been successfully applied in order to analyze and optimize different kinds of manufacturing systems. Figure 1 displays a D TNCE Module of a cylinder containing three places and four transitions. The flow arcs (between places and transitions) have the arc weight one. Since initially there is only one token, the sum of the number of tokens on all places is always equal to one. Consequently, the modeled cylinder can be in one of the three states Extended, OFF-Move and Retracted. For the two flow arcs from p2 to t1 and p2 to t4, a time interval is given to delay the firing of the corresponding transitions. Furthermore, condition arcs transfer state information, whereas event arcs transfer state transition information. A more comprehensive survey introducing definitions of syntax and semantics is provided in [5, 18].
4
workpieces
Figure 2. Closed-loop system model.
and Wonham [25]. They introduced the Supervisory Control Theory (SCT) using finite automata (FA) for system and supervisor modeling. The synthesis algorithms need correct models of system and specification, which is not easy to capture in industrial context [7, 26]. Therefore, supervisors are often synthesized on a higher automation level, assuming that there are underlying controllers on shop-floor level that perform the control tasks of the single components. Nevertheless, extensions of SCT were also proposed for the synthesis of controllers [1, 7, 26]. Compared to FA, Petri nets (PN) allow a more compact system model representation, the modeling of parallel occurring events and a compact specification, e.g., as a system of inequalities. Therefore, extensions of SCT with PN were proposed, e.g., [3]. Other approaches take advantage of PN structural properties, e.g., [13, 16]. Control synthesis based on PN and formalisms with extensions of PN as building blocks (like introduced in Section 3) have been proposed in and [18, 29]. Most synthesized controllers and supervisors are intended to avoid undesired system behavior and/or to ensure system “liveness”. Hence, for the first one the system specification is about specific forbidden states concerning safety issues. A more flexible approach additionally specifying desired system behavior was proposed in [31]. After controller or supervisory control functionality was developed, it can be connected to a closed-loop with the system to be controlled.
Closed-Loop System Modeling
Nobody would implement a controller without a physical process that shall be controlled and for this, it appears to be natural to regard the controller logic as well as the process itself. This section provides a closer view onto the topic of closed-loop modeling. 4.1 Controller and Process Modeling The importance of control software and the necessity of formal methods for its development (MDE), verification and validation (HiL, SiL) was emphasized in Sections 1 and 2 of this contribution. Ideally, controller generation grounds on a formal framework and is automated. Accordingly, a formalized control synthesis is proven to be correct and strengthens the safety and security aspect by reducing possible human errors. It could also reduce the costs of validation and verification. Such methodologies rely on an adequate system modeling and a correct specification of the desired control behavior form, e.g., like those proposed in [10]. Fundamental research in this area was done by Ramadge
4.2 Closing the Loop Controller validation and verification would not be complete if the controller was considered on its own. Because of this and to get a comprehensive assertion about correctness of the control software, the closed-loop system of the controller and a plant has to be taken into account. As shown in Figure 2, controller and plant share information through outputs and inputs, and actuators and sensors. They do not exchange their complete state information or any common variables but they transfer digital 3
controller output model
actuator model
plant
formal controller model
input model
formal plant model
sensor model
ers a further advantage. The explosion of state space is a well-known issue when performing model checking. Regarding a controller in an open loop means that all possible input information would have to be considered, regardless whether practically relevant or not. This obviously blows up the state space to be calculated. However, in a closed-loop system, this problem is reduced as the system under control usually produces a smaller state space in practice. But before coming to verification, closed-loop simulation shall be discussed in the next section.
event arc condition arc
formal model of workpiece property
5 Figure 3. Signal concept for the formal closed-loop system model.
Closed-Loop Simulation
A plant simulation is suitable to test the physical behavior of a manufacturing system. One can exclude collisions of moving parts or check whether the specified production scenarios can be executed, according to the physical assembly of the plant. Beyond this, the controller can be connected to the simulated plant to run test cases. In contrast to for example automotive industry, simulation is rarely-used in the manufacturing domain. One remarkable reason is the fact that creating a simulation for just one plant means additional work expense that has to be justified. Consequently, this effort shall be minimized. Typically, a new plant is not constructed from scratch. The different functional units are designed using a threedimensional graphical software, namely a CAD tool. The drawing contains all necessary information to construct the plant. However, it usually is static and does not contain dynamic information. To simulate moving parts, another model has to be established with a simulation software. These two models may diverge if they are developed independently of each other. In addition, two models are required to describe the same plant. To gain consistency of static and dynamic model, and to minimize work expense by just creating one plant model, the CAD data of the plant should be further used to create the simulation. There are numerous commercial software tools available for plant simulation. However, the different environments do usually not support a standardized exchange format to enable the import and export of their models. A lot of work concerning the data exchange is done by the AutomationML5 group, which standardizes the exchange formats of engineering data between heterogeneous engineering tools. A further description language, especially tailored to describe 3D scenes, is provided by the Virtual Reality Modeling Language (VRML) [12]. Presently, both description languages as well as other standardized exchange formats are not widely-used so that the automatic translation of a CAD model to a simulation model is a software-specific task, which needs different parsers that support different formats of different tools. However, simulation and virtual start-up will certainly gain rising importance for the plant engineering domain. For this, it is up to the simulation software vendors to agree upon a
or analog data. Workpieces represent goods like tins on a pallet, component parts or liquids. They belong to the plant but in contrast to the plant, their properties are dynamically changed during the production process, whereas for example a plant part like a gripper may change its state from open to close but its physical configuration remains static. Workpieces enter and leave the closed-loop system and because of this, it is of advantage to describe their properties in a separate model. They are processed by plant actuators and affect plant sensors that monitor their characteristics. This information is transmitted to the controller, which operates the plant in that way that the projected product qualities and quantities are achieved. Figure 3 shows the scheme of the formal closed-loop system model and visualizes the communication interfaces between the components. The two signal types, namely condition and event signals, transfer state and state transition information, respectively [5]. Plant and controller are interconnected only through condition signals to prevent event loops on the one hand, and to model the communication as in a real system on the other hand, because sensor and actuator values represent state but not state transition information. The closed-loop system is obvious to engineers, since it is natural that a controlled process needs a controller as well as a plant. However, it is daily practice that control software is written without feedback from the plant or its model. Consequently, simulating means more or less providing input information to the controller and evaluating the output information according to consistency. Doing so, the software engineers assume that they have considered every possible failure scenario based on their very own knowledge. For this, it is unnecessary to mention, that open-loop testing will cause serious problems if the system complexity exceeds the human imagination for thinking about and running test cases. Consequently, it is the opinion of the authors of this contribution that the only way to do get a comprehensive assertion about the correctness of control software is to consider both, controller and plant, in a closed loop. Especially according to verification, this procedure deliv-
5 Automation Markup Language group http://www.automationml.org, April 2012.
4
website.
URL,
ently. It is linked to the computer, which executes the plant simulation, through an Ethernet interface 2i . To check the controlled process, test cases are applied to the simulation . According to the results, the tests are either successful 3i or not. This configuration would be sufficient in general, since the simulation can execute every possible plant behavior and the controlled process can be fully observed. However, the completeness of simulation cannot be evaluated because no conclusion according to the coverage can be drawn. To solve this problem, analytic methods from computer science shall be included in the simulation process. For this, the simulated plant is coupled to a formal i D TNCES plant model 4 . The development of this formal model is described in [21]. As shown in Figure 4, the controller outputs, i.e., the actuator signals, are transferred to the plant simulation as well as to the formal model. The idea is to compute the state space of the formal model and to evaluate its coverage 5i . Accordingly, the simulation will be complete if there are no more open branches within the dynamic graph. The graph is calculated stepwise, while the starting point is given by the initial internal state of the formal plant model and the state of the plant inputs given by the controller outputs. The state space is calculated until a loop is found or until no further state can be reached. Then, if possible, the controller provides new information and the state space calculation is further processed. The completeness of state space can be evaluated at any time. Of course, this assertion can only be qualitative because the final size is not certain a priori and for this, no percentage of coverage can be given. Nevertheless, the analysis reveals dead states that may result in a deadlock, or open trajectories that still have to be considered. Based on it, the control code can be adapted 6i or additional test cases can be generated 7ito regard the whole state space. The formal analysis provides a tool to support the efficient HiL Simulation based on test cases. The actual simulation is not affected, since the controller outputs are just looped through to the formal model. Consequently, manual userinteraction is necessary to adapt controller code and test cases, and it can take fairly long to gain a complete coverage. However, a conclusion according to the completeness can be drawn so that the quality of simulation can be evaluated. HiL Simulation is especially suitable if the target controller is already available for testing. In general, it is not vendor-dependant and can be performed for every kind of controller with an interface to a computer. A solution for the problem of manual adaption is provided by formal verification and discussed in the subsequent section.
real-time simulation of PROFIBUS I/O devices 1 control 6 code adaption
control of simulated plant
execution of test cases 3 4
gripper_ lower
0
conveyor_ on
0
conveyor_ pos1
0
conveyor_ pos2
0
ev_ lower
ev_ start
ev_ lower
2
1
1
0
1
0
1
0
0
[0,5]
1
[0,5]
1
0
1
1
2
3
transfer of actuator values to formal model
4
5
6
7
8
9
0
10
11
12
13
14
test case adaption
7
State 7092 62-[62] State 7093 312-[305, 312] State 7091 69-[61, 69] 146-[146] State 7017 State 7016 146-[146] 5-[5, 68] 69-[61, 69] State 6938 7-[7, 145, 160] State 6940 5-[5, 68] State 6939 7-[7, 145, 160] 146-[146] 69-[61, 69] State 6856 State 6855
State 7095 62-[62] State 7094 115-[115] State 7096 146-[86, 146] 69-[61, State 69] 7018 69-[61, 69] State 146-[86, 6941 State 146] 7019 5-[5, 68]157, 160] 5-[5, 68] 7-[7, 145,
7-[7, 145, 160] 5-[5, 68]
6943 7-[7, 146-[86, 145,State 157, 146]160] State 6859 State 6942 69-[61, 69] State 6783 7-[7, 145,State 157, 6858 160] 5-[5, 68] State 6857 56-[4, 6, 21, 56] 56-[4, 6, 14, 21, 56] State 6784 312-[305, 312] State 6720
state space calculation
310-[308, 310] State 6662 302-[302] 56-[4, 56] State 6660 27-[27] State 6659 State 6719 154-[26, 31, 154] 56-[4, 56] State 6582 5-[5, 68] State 6661 State 6782 102-[102, 153, 168] 5-[5, 68] State 6522 120-[120] 69-[61, 69] 56-[4, 56] State 6718 State 6854 312-[305, 312] 62-[62] State 6781 310] State310-[308, 6717 State 6581 69-[61, 69] 302-[302] 62-[62] State 6937 62-[62] 5-[5, 68] State 6715 312-[305, 312]63-[63, 70] 27-[27] State 6521 State 6853 State 6714 310-[308, 310] State 7013 State 6658 State 6780 62-[62] 154-[26, 31, 154] 58-[58] 302-[302] 5-[5, 68] 63-[63, 70] 63-[63, 70] State 6657 71-[55, 71] State 6468 State 6936 69-[61, 69] 153, 168] State 6716 102-[102, State 7014 27-[27] 58-[58] State 6580 State 6852 5-[5, 68] State 7015 State 6579 71-[55, 71] 71-[55, 71] State 6778 63-[63, 70] 69-[61, 120-[120] 69] State 7011 71-[55, 71] 154-[26, 31, 154] 58-[58] State 6520 58-[58] 62-[62] State 6713 State 6779 State 6935 State 7012 69-[61, 69] State 6519 102-[102, 153, 168] 71-[55, 71] 121-[121, 166] 58-[58] State 6934 State 7090 58-[58] State 6656 71-[55, 71] 62-[62]120-[120] 58-[58] 312-[305, 312] State 6467 71-[55, 71] 63-[63, 70] State 7010 State 6850 101-[101, 122] 310-[308, 310] 69-[61, 69] State 6578 State 6851 State 6933 62-[62] 121-[121, 166] State 6465 71-[55, 302-[302] 71] State 6712 138-[73, 138] 63-[63, 70] 58-[58] 58-[58] State 6518 State 6423 State 6425 62-[62] State 6932 101-[101, 122] 45-[45, 137] 71-[55, 71] State 6655 69-[61, 69] State 6776 State 6466 63-[63, 70] 58-[58] 27-[27] State 6424 138-[73, 138] State 6777 71-[55, 71] State 6577 71-[55, 71] State 6931 62-[62] State 6470 63-[63, 70] State 6710 58-[58] 71-[55, 71] 154-[26, 31, 154] 45-[45, 137] State 6711 58-[58] 6849 102-[102, 153, 168] State 6426 State 6775 State 71-[55, 71] 58-[58] State 6517 120-[120] State 6654 71-[55, 71] State 6653 State 6709 63-[63, 70] 58-[58] 58-[58] 121-[121, 166] State 6576 71-[55, 71] State 6652 State 657558-[58] State 6471 101-[101, 122] 71-[55, 71] 71-[55, 71] 58-[58] State 6651 State 6524 State 6469 121-[121, 166] 56-[4, 56]
State 6422 101-[101, 122] 56-[4, 56]
State 6420 138-[73, 138] State 6362 56-[4, 56] 45-[45, 137] State 6361
State 6421
5-[5, 68]
5
56-[4, 56]
State 6363
State 6464
5-[5, 68]
State 6523 138-[73, 138] 58-[58] 71] 71-[55, 45-[45,State 137] 6584 State 6583
Figure 4. Closed-loop HiL Simulation. standard. Coming back to closed-loop plant simulation, there are two possibilities, namely SiL and HiL Simulation. Since the control software shall be analyzed running on the target controller, the authors propose to establish a HiL configuration as shown in Figure 4. Nevertheless, SiL Simulation could be performed in the same way. The only difference would be the control software running on a simulated controller - for example a Soft PLC - which would prevent the application of additional hardware. Before going into detail, some boundary conditions shall be discussed that should be considered before application. One of the most important requirements is that the control software must not be modified while simulating because software engineers usually do not trust in automatic code changes, even if they are proven to be correct. For this, the controller has to be connected to the simulation just through its inputs and outputs. Actually, this is a quite complicated point because the simulated signals of plant’s sensors and actuators have to be transmitted to and from the control device. For this, additional hardware might be necessary to interconnect the simulation and the controller periphery. In case of a Siemens PLC, this task can be performed by a simulation unit, namely the Siemens SIMBA PNIO that simulates PROFIBUS input and output devices and is displayed in the upper left corner in Figure 4. A further point is that a lot of applications require real-time capabilities. As this term highly depends on the process demands and the applied control implementation standard, it has to be considered for each case specifically. In principle, there is no standardized procedure to perform HiL Simulation. For this, the results have to be evaluated according to the applied technique; otherwise no assertion regarding the quality can be given. In Figure 4, the hardware controller is connected to the SIMBA PNIO simulation unit 1ithrough its PROFIBUS interface. The SIMBA PNIO device features real-time simulation and emulates the controller periphery transpar-
6
Closed-Loop Verification
The correctness of control software can be evaluated by applying a test case specification to the closed-loop simulation of plant model and controller hardware. As de5
1
consistency at a branching point, the internal variable values have to coincide with the recorded ones. The procedure continues until the state space is complete, i.e., until there are no more open trajectories, or a certain final state is reached. Subsequently, a formal requirement specification is applied to the state space 5i . This specification of behavior is expressed in a temporal logic formula to verify functional and non-functional requirements. More detail on this topic can be found in [22, 23, 24]. In an ideal case, the specification is fulfilled. If not, the model checker produces and visualizes a counter example 6i . With this information, the control software could be adapted 7iand the process starts over again. The SiL Verification approach is slightly different in contrast to the HiL one. The formal plant model is not connected to the hardware controller, but the control software is translated to a formal D TNCES as well, and composed to a closed-loop model in combination with the plant model. Doing so, it is not necessary to consider the internal variable values of the controller separately. The approach is similar to the framework shown in Figure 5 except for steps 2i , 3iand 4i , which are dispensable. The composed plant and controller models are analyzed by the model checking tool, which computes the complete reachable state space. Then, again a formal specification is applied to it and according to the result, the correctness of control software is verified, or a counter example is produced to adapt it. Obviously, the operative point is the automatic translation of PLC code to a formal model. Due to the structure of IEC 61499 function blocks, this task is quite easy performable for controllers following this standard as shown in [14, 20]. Control software following the IEC 61131 is a little more complicated, since the implementation has many degrees of freedom and is extremely tool-specific. However, it is shown in [6, 28] that automatic control code generation is also possible for IEC 61131 conform software.
5 specification
closed-loop model
4
6
model checker
gripper_ lower
0
conveyor_ on
0
conveyor_ pos1
0
conveyor_ pos2
0
ev_ lower
ev_ start
7
ev_ lower
2 3
1
1
0
0
1
1
1
monitoring software
PLC
0
0
[0,5]
1
[0,5]
1
0
1
2
3
4
5
6
7
8
9
0
10
11
12
13
14
error path
Figure 5. Closed-loop HiL Verification. scribed in the previous section, the coverage can be rated with formal methods. However, additional test cases will have to be manually executed if the coverage is not sufficient. To approach this problem, the procedure of state space calculation shall be fully automated by performing formal verification. Doing so, no additional user interaction should be necessary to obtain the whole dynamic graph of the closed-loop system under control. As for simulation, there exists a HiL and a SiL Verification configuration. Figure 5 shows a possible HiL framework. The core is given by an analyzing tool [6] that coordinates the interaction of hardware controller and formal plant model, and that actually performs the formal verification. For this, first of all the formal plant model is imported 1i . Then, the controller in- and outputs are attached through the SIMBA PNIO device 2i . This configuration would be sufficient in principle if the controller was considered as a black box. However, it is not just a combinatory circuit, but it contains timers, memory, or counters. This information has to be considered, when evaluating the state space of the closed loop. For this, the analyzing tool AutoSPy6 is applied. The software features access to any internal variable of the PLC 3iand transfers it to the model-checking tool 4i . The actual calculation of the reachable state space is performed stepwise. The initial state is given by the initial marking of the plant model, the controller output configuration, and the states of the considered internal controller variables. The computation is processed until a sensor in the plant model changes its state. This information is transferred to the controller, which executes the control software and produces a new output configuration. If branching points are found, i.e., states, where different state transitions are possible, the model checker stores the actual closed-loop system state including the internal controller variable values. Then, one branch is calculated until the cycle is closed. Afterwards, the controller is reset, driven to the branching point and the alternative path is considered. To assure 6 AutoSPy
7
Application
This contribution is focused on closed-loop system modeling, validation, and verification. As the quality of simulation more or less depends on the applied software tool, it is up to the simulation software vendors to offer user-friendly tools, which provide corresponding interfaces to hardware controllers. Because of this, presenting a simulation case study at this point would not deliver many scientific benefits. Nevertheless, the interested reader is referred to the OMSIS project7 , where such a case study was performed using the example of a production plant in lab-scale in cooperation with the authors’ work group. Verification based on model checking is a well-explored 7 OMSIS project website. http://www.processanalysis.de/omsis, April 2012.
website. URL, http://www.autospy.de, April 2012.
6
URL,
tions that prevent users from modeling errors and overcharging theory. This procedure is further supported by the application of a systematic design process as for example introduced in [10].
8
The correctness of control software is crucial not only for a correct process control but also for a safe operation of technical processes. However, testing methods have not been much improved in the environment of manufacturing industry in the past years, although many suitable scientific solutions do exist. Usually, a control software implementation is still tested detached from the physical process or its corresponding model. The consequences are incalculable time expenses when starting up the plant because of potential software errors, which have to be corrected. The reasons for this mostly insufficient open-loop testing may be versatile as discussed in this contribution but the main concern is a complex theory that is not appropriate for industrial application. Picking up these two issues, namely antiquated open-loop testing methods as well as overcharging theoretical solutions from computer science, this contribution presented efficient closed-loop modeling, validation, and verification methods and proposed frameworks to integrate these expertise into the workaday life of engineers. In future works, these frameworks shall be further improved. For this, more significant case studies shall be performed and applied formalisms shall be automated to prevent users from complex theory and possible modeling errors.
Figure 6. Festo MPS. topic in academia. However, it has hardly found its way to real industrial application so far. The reasons for this are obvious. Professionals are under considerable strain according to time-to-market and costumer demands. Consequently, they apply approved methods and are skeptically facing formalisms depending on complex theory. Furthermore, building formal models could mean additional work expense that has to be justified. For this, the practicability of verification approaches depends on user-friendly front ends and integrated software solutions that prevent users from formalisms and dull theory on the one hand and adopt already existing information and interfaces on the other hand. The authors of this contribution tackle this problem and present an integrated framework to perform HiL Verification in [21]. In addition to the presentation of application, also limits and open issues are discussed. Nevertheless, it is shown that controller modeling and simulation can effectively be extended by verification. As discussed in Section 6, HiL Verification has some restrictions according to the internal states of the hardware controller. This problem is faced by formalizing the control software as discussed in [6], where a SiL Verification approach is introduced by the authors of this contribution. To evaluate the user-friendliness of formalisms and software prototypes, a test study was performed. For this, six graduate students were asked to model a partial station of the Festo Modular Production System8 in Figure 6, to establish a controller model, and to analyze their closedloop model. It turned out that the modular character of D TNCES offers a very intuitive formalism to build up hierarchical models for plant and controller. According to the configuration in reality, the signal interconnection (see Figure 3) was very logical to the students. Additionally, all of them reported that the tool support is vitally important. This is a crucial point, because the practical acceptance of an approach does not primarily depend on the efficiency of formalisms but on the convenience of application. Especially in industrial environment, formal approaches have to be wrapped in intuitive software solu8 Festo MPS. URL, forschung/testbed, April 2012.
Conclusion
Acknowledgment This work was supported by the Federal Ministry of Economics and Technology (BMWi) under reference 16 IN 0651 on account of a decision of the German Bundestag and by the German Research Foundation (DFG) under reference numbers HA 1886/17-1 and HA 1886/172.
References [1] F. Charbonnier, H. Alla, and R. David. The Supervised Control of Discrete-Event Dynamic Systems. Transactions on Control Systems Technology, 7(2):175 – 187, March 1999. [2] L. Ferrarini and A. Ded`e. A Model-Based Approach for Mixed Hardware In the Loop Simulation of Manufacturing Systems. In 10th IFAC Workshop on Intelligent Manufacturing Systems (IMS), pages 41–46, Lisbon, Portugal, 2010. [3] J. Flochov´a. A Petri net based supervisory control implementation . In IEEE International Conference on Systems, Man and Cybernetics (SMC), volume 2, pages 1039 – 1044, Washington DC, USA, October 2003.
http://aut.informatik.uni-halle.de/
7
˚ en, and I. Dressler. StateGraph-A Mod[19] M. Otter, K.-E. Arz´ elica Library for Hierarchical State Machines. In 4th International Modelica Conference, pages 569–578, Hamburg, Germany, March 2005. [20] C. Pang and V. Vyatkin. Automatic Model Generation of IEC 61499 Function Block Using Net Condition/Event Systems. In 6th IEEE International Conference on Industrial Informatics (INDIN), pages 1133–1138, Seoul, Korea, 2008. [21] S. Preuße, C. Gerber, and H.-M. Hanisch. Virtual Start-Up of Plants using Formal Methods. Int. J. Computer Applications in Technology (IJCAT), 42(2-3):108–126, 2011. [22] S. Preuße and H.-M. Hanisch. Specification and Verification of Technical Plant Behavior with Symbolic Timing Diagrams. In 3rd International Design & Test Workshop (IDT), pages 313–318, Monastir, Tunisia, December 2008. [23] S. Preuße and H.-M. Hanisch. Specification of Technical Plant Behavior with a Safety-Oriented Technical Language. In 7th IEEE International Conference on Industrial Informatics (INDIN), pages 632–637, Cardiff, United Kingdom, June 2009. IEEE. [24] S. Preuße and H.-M. Hanisch. Verifying Functional and Non-Functional Properties of Manufacturing Control Systems. In 3rd International Workshop on Dependable Control of Discrete Systems (DCDS), pages 41–46, Saarbr¨ucken, Germany, June 2011. IEEE. [25] P. Ramadge and W. Wonham. The control of discrete event systems. In Proceedings of the IEEE, volume 77, pages 81–97. IEEE, 1989. [26] J.-M. Roussel and A. Giua. Designing dependable logic controllers using the supervisory control theory. In Proceedings of the 16th IFAC World Congress, page CDROM paper n◦ 04427, Praha, Czech Republic, July 2005. [27] E. Seabra and J. Machado. Using Advanced Simulation Techniques to Improve Industrial Controller’s Dependability. In 9th IEEE International Conference on Industrial Informatics (INDIN), pages 122–127, Caparica, Lisbon, Portugal, July 2011. [28] M. Stieler. Transformation von IEC 61131 konformen Steuerungsprogrammen in formale Steuerungsmodelle. Master’s thesis, Institut f¨ur Informatik, MartinLuther-Universit¨at Halle-Wittenberg, Halle, Germany, April 2012. In German. [29] A. I. Vasiliu, A. Dideban, and H. Alla. Control Synthesis for Manufacturing Systems Using Non-Safe Petri Nets. Journal of Control Engineering and Applied Informatics, 11(2):43–50, June 2009. [30] V. Vyatkin, G. Zhabelova, M. Ulieru, and D. McComas. Toward Digital Ecologies: Intelligent Agent Networks Controlling Interdependent Infrastructures. In 1st IEEE Conference on Smart Grid Communications (SmartGridComm), pages 589 – 594, Gaithensburg, MD, USA, 2010. [31] T. Winkler, H.-C. Lapp, and H.-M. Hanisch. A new Model Structure based Synthesis Approach for Distributed Discrete Process Control. In Proceedings of the 9th IEEE International Conference on Industrial Informatics (INDIN), pages 527–532, Caparica, Lisbon, Portugal, 2011. IEEE IES.
[4] D. Gasevic, D. Djuric, and V. Devedzic. Model Driven Engineering and Ontology Development. Springer-Verlag, 2. edition, 2009. [5] C. Gerber. Implementation and Verification of Distributed Control Systems, volume 7 of Hallenser Schriften zur Automatisierungstechnik. Logos Verlag GmbH, Berlin, Germany, 2011. [6] C. Gerber, S. Preuße, and H.-M. Hanisch. A Complete Framework for Controller Verification in Manufacturing. In 15th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Bilbao, Spain, September 2010. IEEE. Index: MF-001279. [7] D. Gouyon, J.-F. P´etin, and A. Gouin. A pragmatic approach for modular control synthesis and implementation. International Journal of Production Research, 2(14):2839 – 2858, 2004. [8] H.-M. Hanisch and U. Christmann. Modeling and Analysis of a Polymer Production Plant by Means of Arc-Timed Petri Nets. International Journal of Flexible Automation and Integrated Manufacturing, 3(1):33–46, 1995. [9] I. Hegny, M. Wenger, and A. Zoitl. IEC 61499 based Simulation Framework for Model-Driven Production Systems Development. In 15th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Bilbao, Spain, September 2010. Index: MF-003565. [10] M. Hirsch. Systematic Design of Distributed Industrial Manufacturing Control Systems, volume 6 of Hallenser Schriften zur Automatisierungstechnik. Logos Verlag GmbH, Berlin, Germany, 2010. [11] M. Hirsch, V. Vyatkin, and H.-M. Hanisch. IEC 61499 Function Blocks for Distributed Networked Embedded Applications. In 4th IEEE International Conference on Industrial Informatics (INDIN), pages 670–675, Singapore, 2006. [12] ISO/IEC 14772: Information technology – Computer graphics and image processing – The Virtual Reality Modeling Language – Part 1: Functional specification and UTF-8 encoding, December 1997. [13] M. V. Iordache and P. J. Antsaklis. Supervision Based on Place Invariants: A Survey. Discrete Event Dynamic Systems, 16(4):451–492, 2006. [14] I. Ivanova-Vasileva, C. Gerber, and H.-M. Hanisch. Transformation of IEC 61499 control systems to formal models. In International Conference AUTOMATICS AND INFORMATICS (CAI), pages V–5–V–10, Sofia, Bulgaria, 2007. [15] S. Kain, F. Schiller, and T. Frank. Monitoring and Diagnostics of Hybrid Automation Systems based on Synchronous Simulation. In 8th IEEE International Conference on Industrial Informatics (INDIN), pages 260–265, Osaka, Japan, 2010. [16] Z. Li and M. Zhou. Two-stage method for synthesizing liveness-enforcing supervisors for flexible manufacturing systems using petri nets. IEEE Trans. Industrial Informatics, 2(4):313–325, 2006. [17] M. Marcos, E. Est´evez, N. Iriondo, and D. Orive. Analysis and Validation of IEC 61131-3 Applications using a MDE Approach. In 15th IEEE International Conference on Emerging Technologies and Factory Automation (ETFA), Bilbao, Spain, September 2010. Index: MF-001597. [18] D. Missal. Formal Synthesis of Safety Controller Code for Distributed Controllers, volume 8 of Hallenser Schriften zur Automatisierungstechnik. Logos Verlag GmbH, Berlin, Germany, 2012.
8
