Closedloop System Modeling Validation and Verication Sebastian Preue HansChristian Lapp and HansMichael Hanisch University of HalleWittenberg Institute of Computer Science Chair of Automation Technol
134K - views

Closedloop System Modeling Validation and Verication Sebastian Preue HansChristian Lapp and HansMichael Hanisch University of HalleWittenberg Institute of Computer Science Chair of Automation Technol

preusse hanschristianlapp hansmichaelhanisch informatikunihallede 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 thi

Download Pdf

Closedloop System Modeling Validation and Verication Sebastian Preue HansChristian Lapp and HansMichael Hanisch University of HalleWittenberg Institute of Computer Science Chair of Automation Technol




Download Pdf - The PPT/PDF document "Closedloop System Modeling Validation an..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.



Presentation on theme: "Closedloop System Modeling Validation and Verication Sebastian Preue HansChristian Lapp and HansMichael Hanisch University of HalleWittenberg Institute of Computer Science Chair of Automation Technol"— Presentation transcript:


Page 1
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 con- cerning safety and correctness of software. Conventional open-loop testing methods have clearly reached their lim- its as the complexity of todays control software is not manually manageable anymore. Nevertheless, they still belong to daily practice due to the lack of integrated so- lutions that do not overcharge users but that are tailored to software engineering demands. This contribution ther- fore approaches this problem and encourages the applica- tion 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 develop- ing a new plant, but it is a real cost factor that accounts for engineering charges. Because of this, it is of high signif- icance to apply systematic approaches that support soft- ware implementation. Originally developed as a guide- line 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 con- trary to the configuration in reality. Nobody would imple- ment 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 contri- bution demonstrates the advantages of systematic model- ing for model-driven controller design, simulation, veri- fication, and finally automatic control code implementa- tion. The application of the Systems Modeling Language (SysML) builds bridges from academic advances in re- search 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 applica- tion of formal methods to develop correct control applica- tions. 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 closed- loop 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 verifica- tion are presented in Sections 5 and 6, respectively. Sec- tion 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, sim- ulation or verification is performed in an open loop, pro- viding meaningful input

information to the controller. This procedure may work for non-functional require- ments, such as safety properties, but limits are quickly re- vealed when considering functional properties, since test cases for production sequences become harder to synthe- size the more complex requirements get. In contrast, con- sidering also a model of the process, which shall be con- trolled, is a pretty elegant way to test for a correct imple- mentation. 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
Page 2
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 func- tionalities are simulated as well and translated to control code, afterwards. This procedure enables step by step testing of the control software and finding possible er- rors 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 de- velop the controller model for newly-added functionali- ties. 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 Siemens 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-in- the-Loop (SiL) Simulation not least because it is vendor- and hardware-independent. The Modelica Modeling Lan- guage provides a huge set of possibilities to describe physical systems in terms of equations, which are dynam- ically 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 Hierarchi- cal 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, perfor- mance 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 Pro- cess Measurement and Control Systems that is focused mainly on the integration of heterogeneous software envi- ronments. In their contribution, the authors use Simulink to model a continuous

process and ISaGRAF Enhanced to implement and execute the corresponding control soft- ware. 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 Siemens website. URL, http://www.industry.siemens.com, April 2012. Modelica Language Specification v3.1. URL, http://www.modelica.org, April 2012. The MathWorks website. URL,

http://www.mathworks.com/, April 2012. ISaGRAF website. URL, http://www.isagraf.com/, January 2012. model continuous and dynamic processes, the presented work is very valuable to validate the corresponding con- trol 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 closed- loop 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 compre- hensive way. The authors of [9] present the MEDEIA Simulation Con- cept . 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 con- trol 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 model- ing errors would propagate. For this, both tasks should be separated to exclude ordinary copy-paste-errors or mis- understandings 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 of- fers essential benefits regarding safety of manufacturing systems. For this, the following sections discuss differ- ent 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 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 systems state space and makes analysis manageable. The design of larger systems out of smaller modules is common to engineers. For this, 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 espe- cially when deriving formal plant models from informal simulation models as described in [5, 21]. Beyond this,

the formal basis of TNCES allows to apply formal
Page 3
[10; ] t1 t2 t3 t4 Extended p1 OFF - Move p2 Retracted p3 cylinder extend ci1 retract ci2 retracted co1 extended co2 retracted eo1 not retracted eo2 extended eo3 not extended eo4 workpiece ei1 [10; ] Figure 1. 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 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 TNCE Module of a cylinder con- taining 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 to and to , 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 Closed-Loop System Modeling Nobody would implement a controller without a phys- ical 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), verifica- tion 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. Ac- cordingly, 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 specifi- cation of the

desired control behavior form, e.g., like those proposed in [10]. Fundamental research in this area was done by Ramadge controller plant workpieces controller inputs plant sensors controller outputs plant actuators Figure 2. Closed-loop system model. and Wonham [25]. They introduced the Supervisory Con- trol 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 sin- gle 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 oc- curring events and a compact specification, e.g., as a sys- tem 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 synthe- sis 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 sys- tem liveness. Hence, for the first one the system specifi- cation 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. 4.2 Closing the Loop Controller validation and verification would not be complete if the controller was considered on its own. Be- cause of this and to get a comprehensive assertion about correctness of the control software, the closed-loop sys- tem of the controller and a plant has to be taken into ac- count. 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 infor- mation or any common variables but they transfer digital
Page 4
output

model formal controller model input model actuator model formal plant model formal model of workpiece property sensor model event arc condition arc controller plant Figure 3. Signal concept for the formal closed-loop system model. or analog data. Workpieces represent goods like tins on a pallet, com- ponent 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 ex- ample 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 proper- ties in a separate model. They are processed by plant actu- ators and affect plant sensors that monitor their character- istics. 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 sys- tem model and visualizes the communication interfaces between the components. The two signal types, namely condition and event signals, transfer

state and state transi- tion information, respectively [5]. Plant and controller are interconnected only through condition signals to prevent event loops on the one hand, and to model the communica- tion 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 con- trol software is written without feedback from the plant or its model. Consequently, simulating

means more or less providing input information to the controller and eval- uating 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 men- tion, 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 correct- ness

of control software is to consider both, controller and plant, in a closed loop. Especially according to verification, this procedure deliv- ers a further advantage. The explosion of state space is a well-known issue when performing model checking. Re- garding a controller in an open loop means that all possi- ble input information would have to be considered, regard- less 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 sys- tem 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. 5 Closed-Loop Simulation A plant simulation is suitable to test the physical be- havior of a manufacturing system. One can exclude colli- sions of moving parts or check whether the specified pro- duction scenarios can be executed, according to the phys- ical 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 remark- able 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 three- dimensional 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 in- dependently 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 ex- pense 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

AutomationML group, which standardizes the exchange formats of engineering data between heterogeneous engi- neering tools. A further description language, especially tailored to describe 3D scenes, is provided by the Vir- tual Reality Modeling Language (VRML) [12]. Presently, both description languages as well as other standardized exchange formats are not widely-used so that the auto- matic 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 Automation Markup Language group website. URL, http://www.automationml.org, April 2012.
Page 5
real-time simulation of PROFIBUS I/O devices transfer of actuator values to formal model control of simulated plant State 6361 State 6362 State 6363 State 6420 State 6421 State 6422 State 6423 State 6424 State 6425 State 6426 State 6464 State 6465 State 6466 State 6467 State 6468 State 6469 State 6470 State 6471 State 6517 State 6518 State 6519 State

6520 State 6521 State 6522 State 6523 State 6524 State 6575 State 6576 State 6577 State 6578 State 6579 State 6580 State 6581 State 6582 State 6583 State 6584 State 6651 State 6652 State 6653 State 6654 State 6655 State 6656 State 6657 State 6658 State 6659 State 6660 State 6661 State 6662 State 6709 State 6710 State 6711 State 6712 State 6713 State 6714 State 6715 State 6716 State 6717 State 6718 State 6719 State 6720 State 6775 State 6776 State 6777 State 6778 State 6779 State 6780 State 6781 State 6782 State 6783 State 6784 State 6849 State 6850 State 6851 State 6852 State 6853 State 6854

State 6855 State 6856 State 6857 State 6858 State 6859 State 6931 State 6932 State 6933 State 6934 State 6935 State 6936 State 6937 State 6938 State 6939 State 6940 State 6941 State 6942 State 6943 State 7010 State 7011 State 7012 State 7013 State 7014 State 7015 State 7016 State 7017 State 7018 State 7019 State 7090 State 7091 State 7092 State 7093 State 7094 State 7095 State 7096 45-[45, 137] 56-[4, 56] 138-[73, 138] 56-[4, 56] 101-[101, 122] 5-[5, 68] 69-[61, 69] 45-[45, 137] 62-[62] 5-[5, 68] 69-[61, 69] 62-[62] 101-[101, 122] 56-[4, 56] 121-[121, 166] 138-[73, 138] 45-[45, 137] 63-[63,

70] 63-[63, 70] 101-[101, 122] 62-[62] 121-[121, 166] 5-[5, 68] 69-[61, 69] 56-[4, 56] 120-[120] 138-[73, 138] 58-[58] 71-[55, 71] 58-[58] 71-[55, 71] 63-[63, 70] 121-[121, 166] 62-[62] 120-[120] 5-[5, 68] 69-[61, 69] 56-[4, 56] 102-[102, 153, 168] 71-[55, 71] 45-[45, 137] 58-[58] 71-[55, 71] 101-[101, 122] 58-[58] 58-[58] 71-[55, 71] 63-[63, 70] 120-[120] 62-[62] 102-[102, 153, 168] 5-[5, 68] 69-[61, 69] 154-[26, 31, 154] 27-[27] 56-[4, 56] 302-[302] 138-[73, 138] 121-[121, 166] 71-[55, 71] 58-[58] 58-[58] 71-[55, 71] 63-[63, 70] 102-[102, 153, 168] 154-[26, 31, 154] 27-[27] 62-[62] 302-[302]

5-[5, 68] 69-[61, 69] 56-[4, 56] 310-[308, 310] 120-[120] 71-[55, 71] 58-[58] 58-[58] 71-[55, 71] 154-[26, 31, 154] 27-[27] 63-[63, 70] 302-[302] 62-[62] 310-[308, 310] 5-[5, 68] 69-[61, 69] 56-[4, 6, 21, 56] 312-[305, 312] 102-[102, 153, 168] 71-[55, 71] 58-[58] 58-[58] 71-[55, 71] 63-[63, 70] 310-[308, 310] 62-[62] 312-[305, 312] 5-[5, 68] 7-[7, 145, 160] 56-[4, 6, 14, 21, 56] 5-[5, 68] 7-[7, 145, 157, 160] 154-[26, 31, 154] 27-[27] 302-[302] 71-[55, 71] 58-[58] 58-[58] 71-[55, 71] 63-[63, 70] 312-[305, 312] 62-[62] 7-[7, 145, 160] 69-[61, 69] 5-[5, 68] 146-[146] 7-[7, 145, 157, 160] 69-[61,

69] 5-[5, 68] 146-[86, 146] 310-[308, 310] 71-[55, 71] 58-[58] 58-[58] 71-[55, 71] 63-[63, 70] 58-[58] 71-[55, 71] 69-[61, 69] 146-[146] 7-[7, 145, 160] 5-[5, 68] 69-[61, 69] 146-[86, 146] 7-[7, 145, 157, 160] 5-[5, 68] 312-[305, 312] 71-[55, 71] 58-[58] 71-[55, 71] 58-[58] 146-[146] 62-[62] 312-[305, 312] 69-[61, 69] 146-[86, 146] 62-[62] 115-[115] 69-[61, 69] state space calculation control code adaption ev start_ ev lower_ ev lower_ 10 11 12 13 14 gripper lower_ conveyor on_ conveyor pos1_ conveyor pos2_ [0,5] [0,5] execution of test cases test case adaption 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 tar- get controller, the authors propose to establish a HiL con- figuration as shown in Figure 4. Nevertheless, SiL Sim- ulation 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. Be- fore 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 plants 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 con- troller 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 Fig- ure 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 through its PROFIBUS interface. The SIMBA PNIO device features real-time simulation and emulates the controller periphery transpar- ently. It is linked to the computer, which executes the plant simulation, through an Ethernet interface . To check the controlled process, test cases are applied to the simulation . According to the results, the tests are either successful or not. This configuration

would be sufficient in general, since the simulation can execute every possible plant be- havior and the controlled process can be fully observed. However, the completeness of simulation cannot be evalu- ated 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 pro- cess. For this, the simulated plant is coupled to a formal TNCES plant model . The development of this formal model is described in [21]. As shown in Figure 4, the con- troller 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 . Accordingly, the simula- tion will be complete if there are no more open branches within the dynamic graph. The graph is calculated step- wise, 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 eval- uated 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. Never- theless, the analysis reveals dead states that may result in a deadlock, or open trajectories that still have to be con- sidered. Based on it, the control code can be adapted or additional test cases can be generated to 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 user- interaction is necessary to adapt controller code and test cases, and it can take fairly long to gain a complete cover- age. However, a conclusion according to the completeness can be drawn so that the quality of simulation can be eval- uated. 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 so- lution for the problem of manual adaption is provided by formal verification and discussed in the subsequent sec- tion. 6 Closed-Loop Verification The correctness of control software can be evaluated by applying a test case specification to the closed-loop sim- ulation of plant model and controller hardware. As de-
Page 6
ev start_ ev lower_ ev lower_ 10 11 12 13 14 gripper lower_ conveyor on_ conveyor pos1_ conveyor pos2_ [0,5] [0,5] closed-loop model specification monitoring software PLC error path

model checker 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 suf- ficient. To approach this problem, the procedure of state space calculation shall be fully automated by performing formal verification. Doing so, no additional user inter- action 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 Verifica- tion

configuration. Figure 5 shows a possible HiL frame- work. The core is given by an analyzing tool [6] that co- ordinates the interaction of hardware controller and for- mal plant model, and that actually performs the formal verification. For this, first of all the formal plant model is imported . Then, the controller in- and outputs are attached through the SIMBA PNIO device . This con- figuration 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 AutoSPy is applied. The software fea- tures access to any internal variable of the PLC and transfers it to the model-checking tool . The actual cal- culation of the reachable state space is performed step- wise. 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 pro- duces a new output configuration. If branching points are found, i.e., states, where different state transitions are pos- sible, the model checker stores the actual closed-loop sys- tem 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 branch- ing point and the alternative path is considered. To assure AutoSPy website. URL, http://www.autospy.de, April 2012. consistency at a

branching point, the internal variable val- ues have to coincide with the recorded ones. The proce- dure 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 specifica- tion is applied to the state space . 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 pro- duces and visualizes a counter example . With this in- formation, the control software could be adapted and the process starts over again. The SiL Verification approach is slightly different in con- trast to the HiL one. The formal plant model is not con- nected to the hardware controller, but the control software is translated to a formal TNCES as well, and com- posed 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 and , which are dispensable. The composed plant and controller models are analyzed by the model checking tool, which computes the complete reach- able state space. Then, again a formal specification is ap- plied to it and according to the result, the correctness of control software is verified, or a counter example is pro- duced 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 per- formable 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 soft- ware. 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 of- fer user-friendly tools, which provide

corresponding in- terfaces to hardware controllers. Because of this, present- ing a simulation case study at this point would not de- liver many scientific benefits. Nevertheless, the interested reader is referred to the OMSIS project , where such a case study was performed using the example of a pro- duction plant in lab-scale in cooperation with the authors work group. Verification based on model checking is a well-explored OMSIS project website. URL, http://www.processanalysis.de/omsis, April 2012.
Page 7
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 ac- cording to time-to-market and costumer demands. Conse- quently, they apply approved methods and are skeptically facing formalisms depending on complex theory. Further- more, building formal models could mean additional work expense that has to be justified. For this, the practica- bility 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 per- form HiL Verification in [21]. In addition to the presen- tation of application, also limits and open issues are dis- cussed. Nevertheless, it is shown that controller modeling and simulation can effectively be extended by verification. As discussed in Section 6, HiL Verification has some re- strictions according to the internal states of the hardware controller. This problem is faced by formalizing

the con- trol 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 soft- ware prototypes, a test study was performed. For this, six graduate students were asked to model a partial station of the Festo Modular Production System in Figure 6, to establish a controller model, and to analyze their closed- loop model. It turned out that the modular character of TNCES offers a very intuitive formalism to build up hi- erarchical 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 impor- tant. This is a crucial point, because the practical accep- tance of an approach does not primarily depend on the efficiency of formalisms but on the convenience of appli- cation. Especially in industrial environment, formal ap- proaches have to be wrapped in intuitive software solu- Festo MPS. URL, http://aut.informatik.uni-halle.de/ forschung/testbed, April 2012. tions that prevent users from modeling

errors and over- charging theory. This procedure is further supported by the application of a systematic design process as for ex- ample introduced in [10]. 8 Conclusion 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 manufac- turing 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 cor- rected. 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 ap- propriate for industrial application. Picking up these two issues, namely antiquated open-loop testing methods as well as overcharging theoretical solu- tions from computer science, this contribution presented efficient closed-loop modeling, validation, and

verifica- tion methods and proposed frameworks to integrate these expertise into the workaday life of engineers. In future works, these frameworks shall be further im- proved. 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. 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 Bun- destag and by the German Research Foundation (DFG) under reference numbers

HA 1886/17-1 and HA 1886/17- 2. References [1] F. Charbonnier, H. Alla, and R. David. The Supervised Control of Discrete-Event Dynamic Systems. Transac- tions 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 Manufactur- ing Systems. In 10th IFAC Workshop on Intelligent Man- ufacturing Systems (IMS) , pages 4146, Lisbon, Portugal, 2010. [3] J. Flochov a. A Petri net based supervisory control im- plementation . In IEEE International Conference on Sys- tems, Man and Cybernetics (SMC) ,

volume 2, pages 1039 1044, Washington DC, USA, October 2003.
Page 8
[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 Au- tomatisierungstechnik . Logos Verlag GmbH, Berlin, Ger- many, 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 Tech- nologies and

Factory Automation (ETFA) , Bilbao, Spain, September 2010. IEEE. Index: MF-001279. [7] D. Gouyon, J.-F. P etin, and A. Gouin. A pragmatic ap- proach 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 Analy- sis of a Polymer Production Plant by Means of Arc-Timed Petri Nets. International Journal of Flexible Automation and Integrated Manufacturing , 3(1):3346, 1995. [9] I. Hegny, M. Wenger, and A. Zoitl. IEC 61499 based Sim- ulation 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 Indus- trial Manufacturing Control Systems , volume 6 of Hal- lenser Schriften zur Automatisierungstechnik . Logos Ver- lag 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 In- dustrial Informatics (INDIN) , pages 670675, Singapore, 2006. [12]

ISO/IEC 14772: Information technology Computer graphics and image processing The Virtual Reality Mod- eling 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 Sys- tems , 16(4):451492, 2006. [14] I. Ivanova-Vasileva, C. Gerber, and H.-M. Hanisch. Trans- formation of IEC 61499 control systems to formal models. In International Conference AUTOMATICS AND INFOR- MATICS (CAI) , pages V5V10, Sofia, Bulgaria, 2007. [15] S. Kain, F. Schiller,

and T. Frank. Monitoring and Di- agnostics of Hybrid Automation Systems based on Syn- chronous Simulation. In 8th IEEE International Confer- ence on Industrial Informatics (INDIN) , pages 260265, 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 Informat- ics , 2(4):313325, 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. [19] M. Otter, K.-E. Arz en, and I. Dressler. StateGraph-A Mod- elica Library for Hierarchical State Machines. In 4th Inter- national Modelica Conference , pages 569578, 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 Indus- trial Informatics (INDIN) , pages 11331138, Seoul, Ko- rea, 2008. [21] S. Preue, C. Gerber, and H.-M. Hanisch. Virtual Start-Up of Plants using Formal Methods. Int. J. Computer Appli- cations in Technology (IJCAT) , 42(2-3):108126, 2011. [22] S. Preue and H.-M. Hanisch. Specification and Verifi- cation of Technical Plant Behavior with Symbolic Timing Diagrams. In 3rd International Design & Test Workshop (IDT) , pages 313318, Monastir, Tunisia, December 2008. [23] S. Preue and H.-M.

Hanisch. Specification of Techni- cal Plant Behavior with a Safety-Oriented Technical Lan- guage. In 7th IEEE International Conference on Indus- trial Informatics (INDIN) , pages 632637, 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 Depend- able Control of Discrete Systems (DCDS) , pages 4146, 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 8197. IEEE, 1989. [26] J.-M. Roussel and A. Giua. Designing dependable logic controllers using the supervisory control theory. In Pro- ceedings 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 Controllers Dependabil- ity. In 9th IEEE International Conference on Industrial Informatics (INDIN) , pages 122127, Caparica, Lisbon, Portugal, July 2011. [28] M. Stieler. Transformation von IEC 61131 konfor- men Steuerungsprogrammen in formale

Steuerungsmod- elle. Masters thesis, Institut f ur Informatik, Martin- Luther-Universit at Halle-Wittenberg, Halle, Germany, April 2012. In German. [29] A. I. Vasiliu, A. Dideban, and H. Alla. Control Synthe- sis for Manufacturing Systems Using Non-Safe Petri Nets. Journal of Control Engineering and Applied Informatics 11(2):4350, 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 (SmartGrid- Comm) , 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 Dis- crete Process Control. In Proceedings of the 9th IEEE In- ternational Conference on Industrial Informatics (INDIN) pages 527532, Caparica, Lisbon, Portugal, 2011. IEEE IES.