- Email: [email protected]
Dynamic Software Update of Stateflow Charts using Erlang Runtime System
Proceedings Proceedings of of the the 20th 20th World World Congress Congress Proceedings of the 20th World Congress The Federation of Automatic Proceedings of the 20th World The International International Federation of Congress Automatic Control Control Proceedings of the 20th World Congress The International Federation of Automatic Control Toulouse, France, July 9-14, 2017 Available online at www.sciencedirect.com The International Federation of Control Toulouse, France, July 9-14, 2017 The International Federation of Automatic Automatic Control Toulouse, France, July 9-14, 2017 Toulouse, France, July 9-14, 2017 Toulouse, France, July 9-14, 2017
ScienceDirect
IFAC PapersOnLine 50-1 (2017) 5855–5860
Dynamic Software Update of Stateflow Dynamic Software Update of Dynamic Software Update of Stateflow Stateflow Charts using Erlang Runtime System Charts using Erlang Runtime Charts using Erlang Runtime System System Sebastian Q. Q. Roder, Roder, Julien Julien Provost Provost Sebastian Sebastian Q. Roder, Julien Provost Sebastian Sebastian Q. Q. Roder, Roder, Julien Julien Provost Provost Technical University University of of Munich, Munich, Safe Safe Embedded Embedded Systems, Systems, Technical Technical University of Munich, Safe Embedded Systems, Technical University of Munich, Safe Embedded Systems, 85748 Garching bei M¨ u nchen, Germany Technical85748 University of Munich, Safe Embedded Systems, Garching bei M¨ u nchen, Germany 85748 Garching bei M¨ u nchen, Germany 85748 Garching bei M¨ u nchen, Germany (e-mail: [email protected]; [email protected]) 85748 Garching bei M¨ u nchen, Germany (e-mail: [email protected]; [email protected]) (e-mail: [email protected]; [email protected]) (e-mail: (e-mail: [email protected]; [email protected]; [email protected]) [email protected]) Abstract: Reprogramming the controller of an industrial automation system usually requires Abstract: Reprogramming Reprogramming the the controller controller of of an an industrial industrial automation automation system system usually usually requires requires Abstract: Abstract: the controller an industrial automation system usually requires to halt halt the the Reprogramming system. In In this this paper, paper, a novel novel of method that allows allows reprogramming a controller controller at Abstract: Reprogramming the controller of an industrial automation system usually requires to system. a method that reprogramming a at to halt the system. In this paper, a novel method that allows reprogramming a controller at to halt the system. In this paper, a novel method that allows reprogramming aa controller at runtime is presented. The control behavior is modeled using parallel finite state machines, to halt the system. In this paper, a novel method that allows reprogramming controller at runtime is presented. The control behavior is modeled using parallel finite state machines, runtime isbeing presented. The control behavior is modeled using parallel finite state machines, runtime presented. The is using finite machines, Stateflow used as an example of modeling tool. Automatic translation to Erlang code runtime isbeing presented. The control behavior is modeled modeled using parallel parallel finite state state machines, Stateflowis being used as as an control examplebehavior of modeling modeling tool. Automatic Automatic translation to Erlang Erlang code Stateflow used an example of tool. translation to code Stateflow being used as an example of modeling tool. Automatic translation to Erlang code is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The Stateflow being used as an example of modeling tool. Automatic translation to Erlang code is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The is implemented and Software Update enabled Erlang The is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The presented method is Dynamic applied and and evaluated on aa is case studyusing as aa proof proof of Runtime concept. System. is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The presented method is applied evaluated on case study as of concept. presented method is applied and evaluated on a case study as a proof of concept. presented method is and on case as of presented method is applied applied and evaluated evaluated on aaControl) case study study as aabyproof proof of concept. concept. © 2017, IFAC (International Federation of Automatic Hosting Elsevier Ltd. All rights reserved. Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Keywords: Industrial Automation, Erlang, Keywords: Industrial Automation, Erlang, Dynamic Dynamic Software Software Update, Update, Reprogramming, Reprogramming, Stateflow, Parallel Parallel Finite State Machines Machines Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Stateflow, Finite State Stateflow, Parallel Finite State Machines Stateflow, Parallel Finite State Machines Stateflow, Parallel Finite State Machines 1. 1. INTRODUCTION INTRODUCTION 1. Stateflow Erlang Runtime Runtime System System 1. INTRODUCTION INTRODUCTION Stateflow Erlang 1. INTRODUCTION Stateflow Erlang Runtime System Stateflow Erlang Runtime System Stateflow Erlang Runtime System Often, during during the the life-time life-time of of an an industrial industrial automation automation Often, Often, during the life-time of an industrial automation Often, during the life-time of an industrial automation system there is a need to reprogram the controller. It might Often, duringis aathe life-time of an the industrial automation system there there need to reprogram reprogram the controller. It might might system need controller. It Model Code system there is is acorrect need to toa reprogram the controller. controller. It might might Model Code be necessary to bug, to improve the performance system there is a need to reprogram the It be necessary to correct a bug, to improve the performance Model Code Model Code be necessary to correct a bug, to improve the performance be necessary toor correct a bug, bug, tonew improve the performance performance Model Code of the the system,to orcorrect to adapt adapt it to toto new tasks.the be necessary a improve of system, to it tasks. of the system, or to adapt it to new tasks. Modification of the system, or to adapt it to new tasks. Modification of the system, or to adapt it to new tasks. Modification The usual reprogramming procedure implies to halt and Modification The usual usual reprogramming reprogramming procedure procedure implies implies to to halt halt and and Modification The The usual reprogramming procedure implies halt and restart the reprogramming system, which which also also consistsimplies of ramp rampto down Execution The usual procedure to halt restart the system, consists of down and Execution restart the system, which also consists of down and Execution Model* Code* restart the system, which also consists of ramp ramp down and Execution ramp up phases. In the first place, downtimes and reduced Model* Code* restart the system, which also consists of ramp down and Execution ramp up phases. In the first place, downtimes and reduced Model* Code* ramp up phases. In the first place, downtimes and reduced Model* Code* ramp up phases. In the first place, downtimes and reduced Model* Code* throughput cause losses. Furthermore, companies may not ramp up phases. In the first place, downtimes and reduced throughput cause losses. Furthermore, companies may not throughput cause losses. Furthermore, companies may not throughput cause losses. Furthermore, companies may not apply updates as often as they could, to avoid those losses. throughput cause losses. may not apply updates updates as often often asFurthermore, they could, could, to tocompanies avoid those those losses. apply as as they avoid losses. apply updates as often as they could, to avoid those losses. Dynamic Software In this thisupdates way, plants plants may run longer longer than necessary with Dynamic Software apply as often as they could, to avoid those losses. In way, may run than necessary with Dynamic Software In this way, plants may run longer than necessary with Dynamic Software In this way, plants may run longer than necessary with uncorrected bugs or suboptimal performance. Update Dynamic Software In this way, plants may run longer than necessary with uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update The goal goal of of this this work work is is to to investigate investigate a a novel novel method method that that The The goal of investigate aaatnovel method that The goal reprogramming of this this work work is is to toa investigate novel method that permits controller runtime. DownThe goal of this work is to investigate a novel method that permits reprogramming a controller at runtime. Downpermits reprogramming aa and controller at DownExecution* permits reprogramming controller at runtime. runtime. Downtimes can then be reduced productivity increased. Execution* permits a and controller at runtime. Downtimes can canreprogramming then be be reduced reduced and productivity increased. Execution* times then productivity increased. Execution* times can then be reduced and productivity increased. Execution* times can thenofbe reduced and productivity increased. The workflow this method is depicted in Fig. 1. A MATThe workflow of this method is depicted in Fig. 1. A MATThe workflow of this method is depicted in Fig. 1. A MATThe workflow ofStateflow this method method is depicted depicted in Fig. Fig.Stateflow 1. A A MATMATLAB Simulink state chart, termed in The this is in 1. LABworkflow Simulinkof Stateflow state chart, termed termed Stateflow in LAB Simulink Stateflow state chart, Stateflow in LAB Simulink Stateflow state chart, termed Stateflow in the remainder of the paper, is used to model the controller. Fig. 1. The concept of reprogramming the controller at LAB Simulink Stateflow state chart, termed Stateflow in the remainder of the paper, is used to model the controller. Fig. 1. the the to controller. Fig. runtime. 1. The The concept concept of of reprogramming reprogramming the the controller controller at at the remainder ofautomatically the paper, paper, is is used used to model model the controller. 1. The concept of reprogramming the controller at Theremainder model is is of automatically translated tothe Erlang code Fig. the remainder of the paper, is used to model the controller. The model translated to Erlang code Fig. 1. The concept of reprogramming the controller at runtime. The model is automatically translated to Erlang code runtime. The model is automatically translated to Erlang code runtime. and executed with Erlang Runtime System (ERTS) (see The model is automatically translated to Erlang code and executed with Erlang Runtime System (ERTS) (see runtime. and executed with Erlang System (ERTS) (see and executed with Armstrong Erlang Runtime Runtime System (ERTS) (see (see Armstrong (1996); et al. (2016); Ericsson AB messaging or banking, where the code has to be and executed with Erlang Runtime (ERTS) Armstrong (1996); Armstrong et al. al. System (2016); Ericsson Ericsson AB instant instant messaging or banking, where the code has to be Armstrong (1996); Armstrong et (2016); AB instant messaging or banking, where the code has to be Armstrong (1996); Armstrong et al. (2016); Ericsson AB instant messaging or banking, where the code has to be (2016) for more details). In an update scenario, the original maintained while the system is running. Armstrong (1996); Armstrong et al. (2016); Ericsson AB (2016) for more details). In an update scenario, the original instant messaging or banking, where the code has to be maintained while the system is running. (2016) for more details). In an update scenario, the original maintained while the system is running. (2016) for more details). In an update scenario, the original maintained while while the the system system is is running. running. model is is modified to model*. model*. Then, again, again, thethe model* is maintained (2016) for more details). In an update scenario, original model modified to Then, the model* is Erlang is both a programming language and a runtime model is modified to model*. Then, again, the model* is is both aa programming language and a runtime model is is modified modified to model*. model*. Then, code*. again, The the model* model* is Erlang automatically translated to Erlang final and model to Then, again, the is automatically translated to Erlang Erlang code*. The final and and Erlang is both language and a runtime Erlang is both aa programming programming language and a runtime system that supports Dynamic Software Updating also automatically translated to code*. The final Erlang is both programming language and a runtime system that supports Dynamic Software Updating also automatically translated to Erlang code*. The final and most important step in reprogramming the controller is automatically translated to Erlang code*. The final and most important step in reprogramming the controller is system that supports Dynamic Software Updating also system that supports Dynamic Software Updating also called Hot Code Upgrade. It is wildly used for applications most important step in reprogramming the controller is system that supports Dynamic Software Updating also Hot Code Upgrade. It is wildly used for applications most important step in inprogram reprogramming the controller controller is called to switch switch the running running program to the the updated updated software most important step reprogramming the is to the to software called Hot Code Upgrade. It is wildly used for applications called Hot Code Upgrade. It is wildly used for applications in telecommunication, e-commerce and instant messaging. to switch the running program to the updated software called Hot Code Upgrade. It is wildly used for applications in telecommunication, e-commerce and instant messaging. to switch the running program to the updated software version. to switch the running program to the updated software in version. telecommunication, e-commerce and instant messaging. in telecommunication, e-commerce and messaging. Armstrong et al. (2011) show Erlang’s key features like version. in telecommunication, e-commerce and instant instant messaging. Armstrong et al. (2011) show Erlang’s key features like version. version. Armstrong et al. (2011) show Erlang’s key features like Armstrong et al. (2011) show Erlang’s key features like The concept concept of of modifying modifying a a program program at at runtime runtime is is referred referred concurrency and distribution in large scale applications, The Armstrong et al. (2011) show Erlang’s key features like concurrency and distribution in large scale applications, The concept of modifying a program at runtime is referred concurrency and distribution in large scale applications, The concept of modifying a program at runtime is referred concurrency and distribution in large scale applications, to as asconcept Dynamic Software a Update Update (DSU). Thisis referred field of of concurrency as well well as as soft softand real-time capability and scale robustness. The of modifying program at runtime to Dynamic Software (DSU). This field distribution in large applications, as real-time capability and robustness. to as Dynamic Software Update (DSU). This field of as well well as as soft soft real-time capability capability and and robustness. robustness. to as Dynamic Dynamic Software Update (DSU). This field field of as research is promising and has been investigated widely, to as Software This of research is promising promising and Update has been been(DSU). investigated widely, as wellErlang’s as soft real-time real-time capability and robustness. Using advantages in new areas is attractive, esperesearch is and has investigated widely, Using Erlang’s advantages in new areas is attractive, esperesearch is promising and has been investigated widely, as detailled by Seifzadeh et al. (2013). However, it is research is promising and has been investigated widely, as detailled detailled by Seifzadeh Seifzadeh et al. al. (2013). However, it is is Using Erlang’s advantages in new areas is attractive, espeUsing Erlang’s advantages in new areas is attractive, especially in industrial automation, where fault-tolerant, disas by et (2013). However, it Using Erlang’s advantages in new areas is attractive, especially in industrial automation, where fault-tolerant, disas detailled by Seifzadeh et al. (2013). However, it is notdetailled widespread in industrial industrial automation. Nevertheless, as by Seifzadeh et al. (2013). However, it is not widespread in automation. Nevertheless, cially in industrial automation, where fault-tolerant, discially in industrial automation, where fault-tolerant, distributed, (soft) real-time, and highly available applications not widespread in industrial automation. Nevertheless, cially in industrial automation, where fault-tolerant, distributed, (soft) real-time, and highly available applications not widespread in industrial automation. Nevertheless, DSU is state of the art in many non-stop areas such as not widespread in industrial automation. Nevertheless, DSU is state of the art in many non-stop areas such as tributed, (soft) real-time, and highly available applications tributed, (soft) real-time, and highly available applications are needed too. DSU is state of the art in many non-stop areas such as tributed, (soft) real-time, and highly available applications are needed too. DSU is state of the art in many non-stop areas such as Thisisresearch DSU state of the art in supported many non-stop areas such as are needed too. by are too. This research was was partially partially supported by the the German German Federal Federal are needed needed too.of this work considers controllers, that are This research was partially supported by the German Federal The approach Ministry for Economic Affairs and Energy (BMWi ZIM project This research was partially supported by the German Federal The approach of this work considers controllers, that are Ministry for Economic Affairs and Energy (BMWi ZIM project This research was partially supported by (BMWi the German Federal The approach of this work considers controllers, that are Ministry for Economic Affairs and Energy ZIM project The approach of this work considers controllers, that are modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of Munich. Ministry for Economic Affairs and Energy (BMWi ZIM project The approach of this work considers controllers, that are modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of(BMWi Munich.ZIM project Ministry for Economic Affairs and Energy modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of Munich. modeled as parallel finite state machines. This style ZF4304702BZ6) at the Technical University of Munich. modeled as parallel finite state machines. This style of of ZF4304702BZ6) at the Technical University of Munich. Copyright © 2017, 2017 6035 2405-8963 © IFAC (International Federation of Automatic Control) Copyright 2017 IFAC IFAC 6035Hosting by Elsevier Ltd. All rights reserved. Copyright © 2017 IFAC 6035 Copyright © 2017 IFAC 6035 Peer review under responsibility of International Federation of Automatic Copyright © 2017 IFAC 6035Control. 10.1016/j.ifacol.2017.08.544
Proceedings of the 20th IFAC World Congress 5856 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
modeling is widespread. The method presented in this paper has been applied to Stateflow as an illustration, but could easily be extended to other modeling languages based on finite state machines, e.g. GRAFCET. The method consists of two parts: Firstly, converting the model to code, that is executable in ERTS. And Secondly, to perform a DSU between such Erlang executables.
piston2
[1]/ {p2o=0;p2i=1}
[1]/ {p2o=0;p2i=1}
inwards
out
In the second section of this paper background information is provided. The third section explains the proposed method in detail. This method is then applied in a case study in section four. Finally, in the fifth section this method is evaluated and topics for further research are presented.
[s4==1]/ {p2o=0;p2i=0}
storage idle
2. BACKGROUND
2
initial
1
[s3==1]/ {piston2_free=1}
[s3==1]/ {p2o=0;p2i=0; piston2_free=1}
outwards
in_empty
[piston2_free==0] in_loaded1
[1]/ {p2o=1;p2i=0; start_storing=1}
[start_storing==1]/ {c4=1; start_storing=0}
storing
[after(2500,msec)]/ {c4=0}
2.1 Related Work In the area of distributed systems, reconfigurable designs are an interesting topic. To put it simple, the idea is to ease modifying a system by using modular, distributed software architectures. When reconfiguring the system physically, software components can be reused and changes are only applied locally. A more difficult task is to reconfigure the system at runtime, also referred to as Dynamic Reconfiguration. This is strongly related to Dynamic Software Update (DSU), because it includes changing the code at runtime. Whereas, DSU means even more, like bug-fixing or code optimization at runtime. Brennan et al. (2008) describe different approaches for dynamic reconfiguration and identify basic requirements. Further concepts are presented by Wahler et al. (2009), Wahler and Oriol (2014) and Atmojo et al. (2017). This work makes use of Erlang’s capability for DSU and combines it with a common modeling style, here Stateflow respectively parallel finite state machines. A closely related approach is presented by Prenzel and Provost (2017). They consider IEC 61499 – a industrial standard for process and control systems –, that is used to model distributed systems. Both projects aim to investigate Erlang’s usability for industrial applications in combination with existing modeling styles.
Fig. 2. Detail of a Stateflow model: parallel state machines (dashed outline), containing the sequential substates (solid outline) and transitions labeled with [condition]/{actions}; the execution order is placed in the top right corner of the parallel states.
and multiple abstraction levels. Therefore some Stateflow features are not yet supported. Fig. 2 shows an example of the supported model class as a set of parallel state machines (in the following briefly state machines). These state machines are flat and consist of sequential states (in the following briefly states). Within a state machine, the states are linked with transitions labeled with a condition and an action. The model class has the following characteristics:
2.2 Stateflow Stateflow is an environment for modeling and simulating decision making systems. Finite state machines can be modeled including hierarchy, parallelism and history. Stateflow state charts can be used in combination with MATLAB Simulink models to represent hybrid systems, e.g. a decision making controller interacting with a continuous plant. 2.3 Modeling of State Machines
• The state machines are executed in a given execution order to ensure deterministic behavior. • A state can have several outgoing transitions. Again, a execution order ensures determinism in case of more than one transition being enabled. • Transitions are labeled with a condition and a transition action. • Conditions are boolean expressions and can consist of equality expressions on data variables, e.g. s3 == 1, or temporal expressions referring the moment of entering the state, e.g. after (2500, msec). • Actions are compositions of assignations to data variables, e.g. c4 = 1. • Data variable can be input, output or user defined variables. Input variables can only be accessed for reading, whereas the others can also be written. • Each state machine has an initial state.
As stated above, some features of Stateflow state transition diagrams are not yet supported:
In the process of developing a controller the first step is to model the desired control behavior. The method proposed in this paper supports parallel finite state machines as a control model. Actually, those models are only a subclass of Stateflow charts, which can extend to higher complexity 6036
• • • • • •
Junctions Hierarchy (exceeding the two described levels) History Junctions Events Condition Actions State Actions
Proceedings of the 20th IFAC World Congress Toulouse, France, July 9-14, 2017 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860
state_machine1
Read input
Read input
Execution
Execution
d
1 b
a
2
c
state_machine1 a
Try State Transformation Write output
5857
Write output
Fig. 3. (left) cycle in normal execution mode (right) cycle in update mode: extended with state transformation attempt. 2.4 Dynamic Software Update Erlang code is structured in translation units, called modules. A running Erlang application consists of several modules and also processes, which execute the functions stored in the modules. Under an update scenario, a module is modified, compiled and loaded to ERTS, where a code server holds the old and new software version of the module. There are several ways to perform the update itself regarding when and how the processes switch to the new software version. One way is to stop a process and restart it with the new software version. A more advanced way is to switch the process to the new software version in the sense of DSU. This might be necessary, when the running process contains important data, e.g. values of variables or references to other processes. This information is referred to as the state of the process. According to Seifzadeh et al. (2013), it is very important to transform the state of the process to the new software version. The update might have affected the data structure. 3. METHOD
b
c
e
Fig. 4. The state machine from version 1 (top) and version 2 (bottom) are paired. Matching candidates for a transformation are a, b or c. In d the transformation is not possible. As mentioned before, the execution of the Stateflow model happens in a strictly sequential manner to ensure determinism. Thereby, the cycle time and the memory consumption grow linearly in the worst case with the number of: • • • •
state machines per model outgoing transitions per state components per condition assignations per transition action
Because of the strict sequential execution of Stateflow models, Erlang’s capability for concurrency and distribution cannot be fully utilized. It would indeed be possible (in the sense of the IO and final state determinism) if the subsystems were independent. So far, the code generation was only discussed with respect to the state transition behavior, but data variables are also part of the controller. For time reasons, data variables are not considered for automatic code generation and updating. It is assumed that updating does not affect the variables respectively future version work on the very same set of variables. Therefore a data server is written manually to manage variables and link them to physical connectors. However, it does not seem to be too complex to achieve automatic code generation and DSU of the data server.
3.1 Erlang Code Generation and Execution
3.2 State Transformation of Finite State Machines
As shown in Fig. 1, the model is translated to Erlang code. Therefore, two types of information are extracted from the model. On the one hand, the information to initialize the controller, i.e. the set of all initial states. On the other hand, the information to execute the model, i.e. the state transition information. The state of the controller, respectively the state of the process as introduced in the previous section, is the set of all active states.
In the following, the state transformation of parallel Finite State Machines is presented as well as a condition for when it can be performed.
Before the execution starts, the controller is initialized with the set of initial states. Then the controller starts executing cyclically as shown in Fig. 3 (left). Firstly, the input is read from the plant. Secondly, the controller is executed according to the state transition information. Finally, the output is written to the plant.
Two state machines are said to be paired, if they have the same name. States within these state machines are called matching, again, if they have the same name. It is assumed that matching states represent the same physical state of the plant. Under this assumption, a condition for state transformation can be defined: for all paired state machines, there must exist a state in the new version, that matches the active state in the old version. When this condition is satisfied, the state transformation splits up into three different cases:
6037
Proceedings of the 20th IFAC World Congress 5858 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
• If a state machine exists in both versions, i.e. is paired, the active state is retained, as it has a matching counterpart in the new version. This is reasonable, because it was assumed, that matching states represent an equivalent physical condition. Fig. 4 shows different possible matching candidates for transformation. • If a state machine only exists in the old version, i.e. it was deleted, the active state is also deleted. • If the state machine only exits in the new version, i.e. it was added, it is started in the initial state. The set of retained and initialized states is the state of the controller after the transformation. It has to be mentioned, that designing updates requires some expert knowledge. Careless use might lead to undesired behavior. Especially matching of inappropriate states or deletion of states might cause data inconsistency or data loss.
Fig. 5. Plant for demonstration application. (Source: IKH DIDACTIC SYSTEMS)
3.3 Dynamic Software Update Process In Fig. 1 the Process of DSU is displayed. The controller is executing an old software version. In parallel a new version is loaded to the code server. On a user command, the system switches from normal execution to an update mode, shown in Fig. 3 (right). The normal execution cycle is extended with a state transformation attend.
p1
Thereby, the state transformation condition is evaluated, as defined in the previous section. If the condition holds, the state can be transformed to the new version and the update is successful. The following execution cycle will run with the new software version in normal execution mode. Otherwise, the system stays in update mode and retries state transformation until the update is successful. Thus, the update will not be performed immediately, but is deferred until a transformable state of the controller is reached, i.e. a state where the state transformation condition holds. This might not always be possible. It would be useful to introduce Updateability as a new term to describe a successful update scenario:
c1
l2
m1
m2
c2
c3
l3
l4
Computer
4. APPLICATION
Erlang Runtime System
The previously presented method is applied to an educational plant as a proof-of-concept and to evaluate its performance.
Modbus TCP over Ethernet
4.1 Hardware Setup
fischertechnik – Indexed line with 2 machining stations
c4
Fig. 6. The U-shaped band conveyor in detail: The independent conveyor segments cX transport workpieces. Pistons pX move the workpieces around the corners. At to machining stations mX a processing can be simulated. At some positions the conveyor band is equipped with light sensors lX to detect workpieces.
Further analysis on the Updateability aspect is not in the scope of this work, but will be considered in future work.
1
l5
l1
• A transformable state exists and can be reached • A transformable state will be reached within n cycles
An educational plant 1 , shown in Fig. 5, is used to build a demonstration application. In Fig. 6 the structure of the plant is illustrated in detail. The u-shaped band conveyor transports workpiece blocks. At the corners pistons push the blocks to the next conveyor segments. On two machining stations a processing can be simulated. Some positions on the band conveyor are equipped with light sensors to detect a workpiece.
p2
RIOM
Plant
Fig. 7. Hardware architecture of the demonstration application.
6038
Proceedings of the 20th IFAC World Congress Toulouse, France, July 9-14, 2017 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860
5859
machining
machining
idle
idle
[piston1_free==0]/ {c2=1; piston1_out=1}
[piston1_free==0]/ {c2=1; piston1_out=1}
conveying1
conveying1
[l4==1]/ {c2=0;c3=0; machine2_free=0}
[l3==1]/ {c2=0; m1=1}
machining1
machining1
[after(1000,msec)]/ {m1=0}
[after(1000,msec)]/ {m1=0; c2=1; c3=1}
wait_for_m2
conveying2
[machine2_free==1]/ {c2=1;c3=1}
[l4==1]/ {c2=0, c3=0, m2=1}
[1]
[l3==1]/ {c2=0; m1=1}
conveying2
machining2 [after(3000,msec)]/ {m2=0}
Fig. 9. This state machine controls the line in the area of the first machining station after the update.
wait_for_storage [piston2_free==1]/ {c3=1}
Fig. 8 shows machining in the first software version. Step by step, the workpiece is handled. As soon as the piston pushes a workpiece on the band, it is transported to the first machining station. After the machining it is transported to the second machining station. The workpiece is transported to the storage system, when the second machining is finished and the storage is ready to receive the product.
conveying3 [after(1500,msec)]/ {c3=0; piston2_free=0} delivered
Fig. 8. This state machine controls the main line of the plant including both machining stations before the update. A remote I/O module 2 (RIOM) is connected to the plant’s sensors and actuators. The RIOM and a computer communicate with the Modbus TCP protocol over Ethernet. On the computer ERTS runs the controller software. Fig. 7 illustrates this architecture. 4.2 Case study Machining Process In the first software version four state machines build the controller. The machining process itself is modeled with the state machine machining. It controls the main line of the plant including the machining stations. The three other state machines control the supply conveyor, the storage conveyor and the pistons. 2
PHOENIX CONTACT – ILB ETH 24 DI16 DIO16-2TX
In this case study, the user starts the production system with the first version of the controller. After some time, the user detects that the strictly sequential execution in the machining process could be optimized. In this version, the first machine is idle as long as the controller manages the second station. An upgrade of the Stateflow model will allow the two machines to work concurrently, thus the throughput will be increased. To perform this upgrade, a new controller version is modeled. The three state machines for supply and storage conveyors and pistons are transfered to the new version without modifications. The state machine machining is modified and will only manage the machining process on the first station. Another state machine machining2 is added to control the second machining station. Fig. 9 and Fig. 10 show the new state machines. For the three unmodified state machines and the added state machine the state transformation is possible in any case. The paired state machines machining (represented by Fig. 8 and Fig. 9) share 4 matching states: idle, conveying1, machining1 and conveying2. A matching state and therefore a transformable state of the controller will eventually be reached, because the machining process in the first version is cyclical.
6039
Proceedings of the 20th IFAC World Congress 5860 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
state machines. This seems to be attractive especially for modeling languages, that support independent state machines. The concurrency capability of Erlang could be utilized and the performance of the controller improved.
machining2 initial
For an industrial automation system real-time performance is essential. On the one hand, the hardware architecture presented in Sec. 4.1 has to be improved. Firstly, a real-time fieldbus communication protocol such as EtherCAT should be used instead of Modbus TCP and secondly, the computer system should support real-time applications. On the other hand, the software has to be modified. An important point to remind is that Erlang supports soft real-time but does not guarantee hard realtime. Nicosia (2007) shows how to improve Erlang’s soft real-time performance to hard real-time.
[1]/ {machine2_free=1} idle
[machine2_free==0]/ {m2=1} machining [1]/ {piston2_free=0, machine2_free=1}
[after(3000,msec)]/ {m2=0}
Generally speaking, the focus of further research will be placed in applying the method to large scale systems, to determine scalability and performance of this method under realistic circumstances.
wait_for_storage [piston2_free==1]/ {c3=1}
REFERENCES
conveying [after(1500,msec)]/ {c3=0} delivered
Fig. 10. This state machine controls the line in the area of the second machining station after the update. 4.3 Experimental Results Experiments show, that the plant can be controlled with both software versions. The modeled behavior is executed without any noticeable delays. The update is easy to apply and the production is not affected in any way. Furthermore, the throughput could be increased by the update. 5. CONCLUSION In this paper, a novel method for controlling industrial automation plants was presented, including a conceptional easy way to model a controller and reprogram it in a running system. Furthermore, a possible application of ERTS to industrial automation tasks was given. In a case study the method was applied to a real system with promising results. So far, the data server is written manually and cannot yet be updated as mentioned in Sec. 3.1. It would be interesting to extend the code generation and DSU to the data server. The aspect of Updatability from Sec. 3.3 could be investigated with reachability analysis. It is important to know, if an update will be successful before trying to apply it to a running system.
Armstrong, J., Virding, S., and Williams, M. (2016). Erlang user’s guide and reference manual. Armstrong, J. (1996). Erlang - a survey of the language and its industrial applications. In Proc. INAP, volume 96. Armstrong, J., D¨acker, B., Lindgren, T., and Millroth, H. (2011). Open-source Erlang - white paper. Atmojo, U., Salcic, Z., and Wang, K.K. (2017). Dynamic online reconfiguration in manufacturing systems using SOSJ framework. In IEEE International Conference on Industrial Informatics (INDIN). doi: 10.1109/INDIN.2016.7819249. Brennan, R.W., Vrba, P., Tichy, P., Zoitl, A., S¨ under, C., Strasser, T., and Marik, V. (2008). Developments in dynamic and intelligent reconfiguration of industrial automation. Computers in Industry, 59(6), 533–547. doi:10.1016/j.compind.2008.02.001. Ericsson AB (2016). Erlang/OTP System Documentation, 8.0 edition. Nicosia, V. (2007). Towards hard real-time Erlang. In Proceedings of the 2007 ACM SIGPLAN Workshop on Erlang, 29–36. Prenzel, L. and Provost, J. (2017). Dynamic software updating of IEC 61499 implementation using Erlang runtime system. In 20th IFAC World Congress, 2017. Seifzadeh, H., Abolhassani, H., and Moshkenani, M.S. (2013). A survey of dynamic software updating. Journal of Software: Evolution and Process, 25(5), 535–568. Wahler, M. and Oriol, M. (2014). Disruption-free software updates in automation systems. In 19th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA 2014. doi: 10.1109/ETFA.2014.7005075. Wahler, M., Richter, S., and Oriol, M. (2009). Dynamic Software Updates for Real-Time Systems. Proceedings of the Second International Workshop on Hot Topics in Software Upgrades HotSWUp 09, (October). doi: 10.1145/1656437.1656440.
As mentioned before, the method presented in this paper has been applied to Stateflow as an illustration, but could be extended to other modeling languages based on finite 6040
ScienceDirect
IFAC PapersOnLine 50-1 (2017) 5855–5860
Dynamic Software Update of Stateflow Dynamic Software Update of Dynamic Software Update of Stateflow Stateflow Charts using Erlang Runtime System Charts using Erlang Runtime Charts using Erlang Runtime System System Sebastian Q. Q. Roder, Roder, Julien Julien Provost Provost Sebastian Sebastian Q. Roder, Julien Provost Sebastian Sebastian Q. Q. Roder, Roder, Julien Julien Provost Provost Technical University University of of Munich, Munich, Safe Safe Embedded Embedded Systems, Systems, Technical Technical University of Munich, Safe Embedded Systems, Technical University of Munich, Safe Embedded Systems, 85748 Garching bei M¨ u nchen, Germany Technical85748 University of Munich, Safe Embedded Systems, Garching bei M¨ u nchen, Germany 85748 Garching bei M¨ u nchen, Germany 85748 Garching bei M¨ u nchen, Germany (e-mail: [email protected]; [email protected]) 85748 Garching bei M¨ u nchen, Germany (e-mail: [email protected]; [email protected]) (e-mail: [email protected]; [email protected]) (e-mail: (e-mail: [email protected]; [email protected]; [email protected]) [email protected]) Abstract: Reprogramming the controller of an industrial automation system usually requires Abstract: Reprogramming Reprogramming the the controller controller of of an an industrial industrial automation automation system system usually usually requires requires Abstract: Abstract: the controller an industrial automation system usually requires to halt halt the the Reprogramming system. In In this this paper, paper, a novel novel of method that allows allows reprogramming a controller controller at Abstract: Reprogramming the controller of an industrial automation system usually requires to system. a method that reprogramming a at to halt the system. In this paper, a novel method that allows reprogramming a controller at to halt the system. In this paper, a novel method that allows reprogramming aa controller at runtime is presented. The control behavior is modeled using parallel finite state machines, to halt the system. In this paper, a novel method that allows reprogramming controller at runtime is presented. The control behavior is modeled using parallel finite state machines, runtime isbeing presented. The control behavior is modeled using parallel finite state machines, runtime presented. The is using finite machines, Stateflow used as an example of modeling tool. Automatic translation to Erlang code runtime isbeing presented. The control behavior is modeled modeled using parallel parallel finite state state machines, Stateflowis being used as as an control examplebehavior of modeling modeling tool. Automatic Automatic translation to Erlang Erlang code Stateflow used an example of tool. translation to code Stateflow being used as an example of modeling tool. Automatic translation to Erlang code is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The Stateflow being used as an example of modeling tool. Automatic translation to Erlang code is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The is implemented and Software Update enabled Erlang The is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The presented method is Dynamic applied and and evaluated on aa is case studyusing as aa proof proof of Runtime concept. System. is implemented and Dynamic Software Update is enabled using Erlang Runtime System. The presented method is applied evaluated on case study as of concept. presented method is applied and evaluated on a case study as a proof of concept. presented method is and on case as of presented method is applied applied and evaluated evaluated on aaControl) case study study as aabyproof proof of concept. concept. © 2017, IFAC (International Federation of Automatic Hosting Elsevier Ltd. All rights reserved. Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Keywords: Industrial Automation, Erlang, Keywords: Industrial Automation, Erlang, Dynamic Dynamic Software Software Update, Update, Reprogramming, Reprogramming, Stateflow, Parallel Parallel Finite State Machines Machines Keywords: Industrial Automation, Erlang, Dynamic Software Update, Reprogramming, Stateflow, Finite State Stateflow, Parallel Finite State Machines Stateflow, Parallel Finite State Machines Stateflow, Parallel Finite State Machines 1. 1. INTRODUCTION INTRODUCTION 1. Stateflow Erlang Runtime Runtime System System 1. INTRODUCTION INTRODUCTION Stateflow Erlang 1. INTRODUCTION Stateflow Erlang Runtime System Stateflow Erlang Runtime System Stateflow Erlang Runtime System Often, during during the the life-time life-time of of an an industrial industrial automation automation Often, Often, during the life-time of an industrial automation Often, during the life-time of an industrial automation system there is a need to reprogram the controller. It might Often, duringis aathe life-time of an the industrial automation system there there need to reprogram reprogram the controller. It might might system need controller. It Model Code system there is is acorrect need to toa reprogram the controller. controller. It might might Model Code be necessary to bug, to improve the performance system there is a need to reprogram the It be necessary to correct a bug, to improve the performance Model Code Model Code be necessary to correct a bug, to improve the performance be necessary toor correct a bug, bug, tonew improve the performance performance Model Code of the the system,to orcorrect to adapt adapt it to toto new tasks.the be necessary a improve of system, to it tasks. of the system, or to adapt it to new tasks. Modification of the system, or to adapt it to new tasks. Modification of the system, or to adapt it to new tasks. Modification The usual reprogramming procedure implies to halt and Modification The usual usual reprogramming reprogramming procedure procedure implies implies to to halt halt and and Modification The The usual reprogramming procedure implies halt and restart the reprogramming system, which which also also consistsimplies of ramp rampto down Execution The usual procedure to halt restart the system, consists of down and Execution restart the system, which also consists of down and Execution Model* Code* restart the system, which also consists of ramp ramp down and Execution ramp up phases. In the first place, downtimes and reduced Model* Code* restart the system, which also consists of ramp down and Execution ramp up phases. In the first place, downtimes and reduced Model* Code* ramp up phases. In the first place, downtimes and reduced Model* Code* ramp up phases. In the first place, downtimes and reduced Model* Code* throughput cause losses. Furthermore, companies may not ramp up phases. In the first place, downtimes and reduced throughput cause losses. Furthermore, companies may not throughput cause losses. Furthermore, companies may not throughput cause losses. Furthermore, companies may not apply updates as often as they could, to avoid those losses. throughput cause losses. may not apply updates updates as often often asFurthermore, they could, could, to tocompanies avoid those those losses. apply as as they avoid losses. apply updates as often as they could, to avoid those losses. Dynamic Software In this thisupdates way, plants plants may run longer longer than necessary with Dynamic Software apply as often as they could, to avoid those losses. In way, may run than necessary with Dynamic Software In this way, plants may run longer than necessary with Dynamic Software In this way, plants may run longer than necessary with uncorrected bugs or suboptimal performance. Update Dynamic Software In this way, plants may run longer than necessary with uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update uncorrected bugs or suboptimal performance. Update The goal goal of of this this work work is is to to investigate investigate a a novel novel method method that that The The goal of investigate aaatnovel method that The goal reprogramming of this this work work is is to toa investigate novel method that permits controller runtime. DownThe goal of this work is to investigate a novel method that permits reprogramming a controller at runtime. Downpermits reprogramming aa and controller at DownExecution* permits reprogramming controller at runtime. runtime. Downtimes can then be reduced productivity increased. Execution* permits a and controller at runtime. Downtimes can canreprogramming then be be reduced reduced and productivity increased. Execution* times then productivity increased. Execution* times can then be reduced and productivity increased. Execution* times can thenofbe reduced and productivity increased. The workflow this method is depicted in Fig. 1. A MATThe workflow of this method is depicted in Fig. 1. A MATThe workflow of this method is depicted in Fig. 1. A MATThe workflow ofStateflow this method method is depicted depicted in Fig. Fig.Stateflow 1. A A MATMATLAB Simulink state chart, termed in The this is in 1. LABworkflow Simulinkof Stateflow state chart, termed termed Stateflow in LAB Simulink Stateflow state chart, Stateflow in LAB Simulink Stateflow state chart, termed Stateflow in the remainder of the paper, is used to model the controller. Fig. 1. The concept of reprogramming the controller at LAB Simulink Stateflow state chart, termed Stateflow in the remainder of the paper, is used to model the controller. Fig. 1. the the to controller. Fig. runtime. 1. The The concept concept of of reprogramming reprogramming the the controller controller at at the remainder ofautomatically the paper, paper, is is used used to model model the controller. 1. The concept of reprogramming the controller at Theremainder model is is of automatically translated tothe Erlang code Fig. the remainder of the paper, is used to model the controller. The model translated to Erlang code Fig. 1. The concept of reprogramming the controller at runtime. The model is automatically translated to Erlang code runtime. The model is automatically translated to Erlang code runtime. and executed with Erlang Runtime System (ERTS) (see The model is automatically translated to Erlang code and executed with Erlang Runtime System (ERTS) (see runtime. and executed with Erlang System (ERTS) (see and executed with Armstrong Erlang Runtime Runtime System (ERTS) (see (see Armstrong (1996); et al. (2016); Ericsson AB messaging or banking, where the code has to be and executed with Erlang Runtime (ERTS) Armstrong (1996); Armstrong et al. al. System (2016); Ericsson Ericsson AB instant instant messaging or banking, where the code has to be Armstrong (1996); Armstrong et (2016); AB instant messaging or banking, where the code has to be Armstrong (1996); Armstrong et al. (2016); Ericsson AB instant messaging or banking, where the code has to be (2016) for more details). In an update scenario, the original maintained while the system is running. Armstrong (1996); Armstrong et al. (2016); Ericsson AB (2016) for more details). In an update scenario, the original instant messaging or banking, where the code has to be maintained while the system is running. (2016) for more details). In an update scenario, the original maintained while the system is running. (2016) for more details). In an update scenario, the original maintained while while the the system system is is running. running. model is is modified to model*. model*. Then, again, again, thethe model* is maintained (2016) for more details). In an update scenario, original model modified to Then, the model* is Erlang is both a programming language and a runtime model is modified to model*. Then, again, the model* is is both aa programming language and a runtime model is is modified modified to model*. model*. Then, code*. again, The the model* model* is Erlang automatically translated to Erlang final and model to Then, again, the is automatically translated to Erlang Erlang code*. The final and and Erlang is both language and a runtime Erlang is both aa programming programming language and a runtime system that supports Dynamic Software Updating also automatically translated to code*. The final Erlang is both programming language and a runtime system that supports Dynamic Software Updating also automatically translated to Erlang code*. The final and most important step in reprogramming the controller is automatically translated to Erlang code*. The final and most important step in reprogramming the controller is system that supports Dynamic Software Updating also system that supports Dynamic Software Updating also called Hot Code Upgrade. It is wildly used for applications most important step in reprogramming the controller is system that supports Dynamic Software Updating also Hot Code Upgrade. It is wildly used for applications most important step in inprogram reprogramming the controller controller is called to switch switch the running running program to the the updated updated software most important step reprogramming the is to the to software called Hot Code Upgrade. It is wildly used for applications called Hot Code Upgrade. It is wildly used for applications in telecommunication, e-commerce and instant messaging. to switch the running program to the updated software called Hot Code Upgrade. It is wildly used for applications in telecommunication, e-commerce and instant messaging. to switch the running program to the updated software version. to switch the running program to the updated software in version. telecommunication, e-commerce and instant messaging. in telecommunication, e-commerce and messaging. Armstrong et al. (2011) show Erlang’s key features like version. in telecommunication, e-commerce and instant instant messaging. Armstrong et al. (2011) show Erlang’s key features like version. version. Armstrong et al. (2011) show Erlang’s key features like Armstrong et al. (2011) show Erlang’s key features like The concept concept of of modifying modifying a a program program at at runtime runtime is is referred referred concurrency and distribution in large scale applications, The Armstrong et al. (2011) show Erlang’s key features like concurrency and distribution in large scale applications, The concept of modifying a program at runtime is referred concurrency and distribution in large scale applications, The concept of modifying a program at runtime is referred concurrency and distribution in large scale applications, to as asconcept Dynamic Software a Update Update (DSU). Thisis referred field of of concurrency as well well as as soft softand real-time capability and scale robustness. The of modifying program at runtime to Dynamic Software (DSU). This field distribution in large applications, as real-time capability and robustness. to as Dynamic Software Update (DSU). This field of as well well as as soft soft real-time capability capability and and robustness. robustness. to as Dynamic Dynamic Software Update (DSU). This field field of as research is promising and has been investigated widely, to as Software This of research is promising promising and Update has been been(DSU). investigated widely, as wellErlang’s as soft real-time real-time capability and robustness. Using advantages in new areas is attractive, esperesearch is and has investigated widely, Using Erlang’s advantages in new areas is attractive, esperesearch is promising and has been investigated widely, as detailled by Seifzadeh et al. (2013). However, it is research is promising and has been investigated widely, as detailled detailled by Seifzadeh Seifzadeh et al. al. (2013). However, it is is Using Erlang’s advantages in new areas is attractive, espeUsing Erlang’s advantages in new areas is attractive, especially in industrial automation, where fault-tolerant, disas by et (2013). However, it Using Erlang’s advantages in new areas is attractive, especially in industrial automation, where fault-tolerant, disas detailled by Seifzadeh et al. (2013). However, it is notdetailled widespread in industrial industrial automation. Nevertheless, as by Seifzadeh et al. (2013). However, it is not widespread in automation. Nevertheless, cially in industrial automation, where fault-tolerant, discially in industrial automation, where fault-tolerant, distributed, (soft) real-time, and highly available applications not widespread in industrial automation. Nevertheless, cially in industrial automation, where fault-tolerant, distributed, (soft) real-time, and highly available applications not widespread in industrial automation. Nevertheless, DSU is state of the art in many non-stop areas such as not widespread in industrial automation. Nevertheless, DSU is state of the art in many non-stop areas such as tributed, (soft) real-time, and highly available applications tributed, (soft) real-time, and highly available applications are needed too. DSU is state of the art in many non-stop areas such as tributed, (soft) real-time, and highly available applications are needed too. DSU is state of the art in many non-stop areas such as Thisisresearch DSU state of the art in supported many non-stop areas such as are needed too. by are too. This research was was partially partially supported by the the German German Federal Federal are needed needed too.of this work considers controllers, that are This research was partially supported by the German Federal The approach Ministry for Economic Affairs and Energy (BMWi ZIM project This research was partially supported by the German Federal The approach of this work considers controllers, that are Ministry for Economic Affairs and Energy (BMWi ZIM project This research was partially supported by (BMWi the German Federal The approach of this work considers controllers, that are Ministry for Economic Affairs and Energy ZIM project The approach of this work considers controllers, that are modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of Munich. Ministry for Economic Affairs and Energy (BMWi ZIM project The approach of this work considers controllers, that are modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of(BMWi Munich.ZIM project Ministry for Economic Affairs and Energy modeled as parallel finite state machines. This style of ZF4304702BZ6) at the Technical University of Munich. modeled as parallel finite state machines. This style ZF4304702BZ6) at the Technical University of Munich. modeled as parallel finite state machines. This style of of ZF4304702BZ6) at the Technical University of Munich. Copyright © 2017, 2017 6035 2405-8963 © IFAC (International Federation of Automatic Control) Copyright 2017 IFAC IFAC 6035Hosting by Elsevier Ltd. All rights reserved. Copyright © 2017 IFAC 6035 Copyright © 2017 IFAC 6035 Peer review under responsibility of International Federation of Automatic Copyright © 2017 IFAC 6035Control. 10.1016/j.ifacol.2017.08.544
Proceedings of the 20th IFAC World Congress 5856 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
modeling is widespread. The method presented in this paper has been applied to Stateflow as an illustration, but could easily be extended to other modeling languages based on finite state machines, e.g. GRAFCET. The method consists of two parts: Firstly, converting the model to code, that is executable in ERTS. And Secondly, to perform a DSU between such Erlang executables.
piston2
[1]/ {p2o=0;p2i=1}
[1]/ {p2o=0;p2i=1}
inwards
out
In the second section of this paper background information is provided. The third section explains the proposed method in detail. This method is then applied in a case study in section four. Finally, in the fifth section this method is evaluated and topics for further research are presented.
[s4==1]/ {p2o=0;p2i=0}
storage idle
2. BACKGROUND
2
initial
1
[s3==1]/ {piston2_free=1}
[s3==1]/ {p2o=0;p2i=0; piston2_free=1}
outwards
in_empty
[piston2_free==0] in_loaded1
[1]/ {p2o=1;p2i=0; start_storing=1}
[start_storing==1]/ {c4=1; start_storing=0}
storing
[after(2500,msec)]/ {c4=0}
2.1 Related Work In the area of distributed systems, reconfigurable designs are an interesting topic. To put it simple, the idea is to ease modifying a system by using modular, distributed software architectures. When reconfiguring the system physically, software components can be reused and changes are only applied locally. A more difficult task is to reconfigure the system at runtime, also referred to as Dynamic Reconfiguration. This is strongly related to Dynamic Software Update (DSU), because it includes changing the code at runtime. Whereas, DSU means even more, like bug-fixing or code optimization at runtime. Brennan et al. (2008) describe different approaches for dynamic reconfiguration and identify basic requirements. Further concepts are presented by Wahler et al. (2009), Wahler and Oriol (2014) and Atmojo et al. (2017). This work makes use of Erlang’s capability for DSU and combines it with a common modeling style, here Stateflow respectively parallel finite state machines. A closely related approach is presented by Prenzel and Provost (2017). They consider IEC 61499 – a industrial standard for process and control systems –, that is used to model distributed systems. Both projects aim to investigate Erlang’s usability for industrial applications in combination with existing modeling styles.
Fig. 2. Detail of a Stateflow model: parallel state machines (dashed outline), containing the sequential substates (solid outline) and transitions labeled with [condition]/{actions}; the execution order is placed in the top right corner of the parallel states.
and multiple abstraction levels. Therefore some Stateflow features are not yet supported. Fig. 2 shows an example of the supported model class as a set of parallel state machines (in the following briefly state machines). These state machines are flat and consist of sequential states (in the following briefly states). Within a state machine, the states are linked with transitions labeled with a condition and an action. The model class has the following characteristics:
2.2 Stateflow Stateflow is an environment for modeling and simulating decision making systems. Finite state machines can be modeled including hierarchy, parallelism and history. Stateflow state charts can be used in combination with MATLAB Simulink models to represent hybrid systems, e.g. a decision making controller interacting with a continuous plant. 2.3 Modeling of State Machines
• The state machines are executed in a given execution order to ensure deterministic behavior. • A state can have several outgoing transitions. Again, a execution order ensures determinism in case of more than one transition being enabled. • Transitions are labeled with a condition and a transition action. • Conditions are boolean expressions and can consist of equality expressions on data variables, e.g. s3 == 1, or temporal expressions referring the moment of entering the state, e.g. after (2500, msec). • Actions are compositions of assignations to data variables, e.g. c4 = 1. • Data variable can be input, output or user defined variables. Input variables can only be accessed for reading, whereas the others can also be written. • Each state machine has an initial state.
As stated above, some features of Stateflow state transition diagrams are not yet supported:
In the process of developing a controller the first step is to model the desired control behavior. The method proposed in this paper supports parallel finite state machines as a control model. Actually, those models are only a subclass of Stateflow charts, which can extend to higher complexity 6036
• • • • • •
Junctions Hierarchy (exceeding the two described levels) History Junctions Events Condition Actions State Actions
Proceedings of the 20th IFAC World Congress Toulouse, France, July 9-14, 2017 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860
state_machine1
Read input
Read input
Execution
Execution
d
1 b
a
2
c
state_machine1 a
Try State Transformation Write output
5857
Write output
Fig. 3. (left) cycle in normal execution mode (right) cycle in update mode: extended with state transformation attempt. 2.4 Dynamic Software Update Erlang code is structured in translation units, called modules. A running Erlang application consists of several modules and also processes, which execute the functions stored in the modules. Under an update scenario, a module is modified, compiled and loaded to ERTS, where a code server holds the old and new software version of the module. There are several ways to perform the update itself regarding when and how the processes switch to the new software version. One way is to stop a process and restart it with the new software version. A more advanced way is to switch the process to the new software version in the sense of DSU. This might be necessary, when the running process contains important data, e.g. values of variables or references to other processes. This information is referred to as the state of the process. According to Seifzadeh et al. (2013), it is very important to transform the state of the process to the new software version. The update might have affected the data structure. 3. METHOD
b
c
e
Fig. 4. The state machine from version 1 (top) and version 2 (bottom) are paired. Matching candidates for a transformation are a, b or c. In d the transformation is not possible. As mentioned before, the execution of the Stateflow model happens in a strictly sequential manner to ensure determinism. Thereby, the cycle time and the memory consumption grow linearly in the worst case with the number of: • • • •
state machines per model outgoing transitions per state components per condition assignations per transition action
Because of the strict sequential execution of Stateflow models, Erlang’s capability for concurrency and distribution cannot be fully utilized. It would indeed be possible (in the sense of the IO and final state determinism) if the subsystems were independent. So far, the code generation was only discussed with respect to the state transition behavior, but data variables are also part of the controller. For time reasons, data variables are not considered for automatic code generation and updating. It is assumed that updating does not affect the variables respectively future version work on the very same set of variables. Therefore a data server is written manually to manage variables and link them to physical connectors. However, it does not seem to be too complex to achieve automatic code generation and DSU of the data server.
3.1 Erlang Code Generation and Execution
3.2 State Transformation of Finite State Machines
As shown in Fig. 1, the model is translated to Erlang code. Therefore, two types of information are extracted from the model. On the one hand, the information to initialize the controller, i.e. the set of all initial states. On the other hand, the information to execute the model, i.e. the state transition information. The state of the controller, respectively the state of the process as introduced in the previous section, is the set of all active states.
In the following, the state transformation of parallel Finite State Machines is presented as well as a condition for when it can be performed.
Before the execution starts, the controller is initialized with the set of initial states. Then the controller starts executing cyclically as shown in Fig. 3 (left). Firstly, the input is read from the plant. Secondly, the controller is executed according to the state transition information. Finally, the output is written to the plant.
Two state machines are said to be paired, if they have the same name. States within these state machines are called matching, again, if they have the same name. It is assumed that matching states represent the same physical state of the plant. Under this assumption, a condition for state transformation can be defined: for all paired state machines, there must exist a state in the new version, that matches the active state in the old version. When this condition is satisfied, the state transformation splits up into three different cases:
6037
Proceedings of the 20th IFAC World Congress 5858 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
• If a state machine exists in both versions, i.e. is paired, the active state is retained, as it has a matching counterpart in the new version. This is reasonable, because it was assumed, that matching states represent an equivalent physical condition. Fig. 4 shows different possible matching candidates for transformation. • If a state machine only exists in the old version, i.e. it was deleted, the active state is also deleted. • If the state machine only exits in the new version, i.e. it was added, it is started in the initial state. The set of retained and initialized states is the state of the controller after the transformation. It has to be mentioned, that designing updates requires some expert knowledge. Careless use might lead to undesired behavior. Especially matching of inappropriate states or deletion of states might cause data inconsistency or data loss.
Fig. 5. Plant for demonstration application. (Source: IKH DIDACTIC SYSTEMS)
3.3 Dynamic Software Update Process In Fig. 1 the Process of DSU is displayed. The controller is executing an old software version. In parallel a new version is loaded to the code server. On a user command, the system switches from normal execution to an update mode, shown in Fig. 3 (right). The normal execution cycle is extended with a state transformation attend.
p1
Thereby, the state transformation condition is evaluated, as defined in the previous section. If the condition holds, the state can be transformed to the new version and the update is successful. The following execution cycle will run with the new software version in normal execution mode. Otherwise, the system stays in update mode and retries state transformation until the update is successful. Thus, the update will not be performed immediately, but is deferred until a transformable state of the controller is reached, i.e. a state where the state transformation condition holds. This might not always be possible. It would be useful to introduce Updateability as a new term to describe a successful update scenario:
c1
l2
m1
m2
c2
c3
l3
l4
Computer
4. APPLICATION
Erlang Runtime System
The previously presented method is applied to an educational plant as a proof-of-concept and to evaluate its performance.
Modbus TCP over Ethernet
4.1 Hardware Setup
fischertechnik – Indexed line with 2 machining stations
c4
Fig. 6. The U-shaped band conveyor in detail: The independent conveyor segments cX transport workpieces. Pistons pX move the workpieces around the corners. At to machining stations mX a processing can be simulated. At some positions the conveyor band is equipped with light sensors lX to detect workpieces.
Further analysis on the Updateability aspect is not in the scope of this work, but will be considered in future work.
1
l5
l1
• A transformable state exists and can be reached • A transformable state will be reached within n cycles
An educational plant 1 , shown in Fig. 5, is used to build a demonstration application. In Fig. 6 the structure of the plant is illustrated in detail. The u-shaped band conveyor transports workpiece blocks. At the corners pistons push the blocks to the next conveyor segments. On two machining stations a processing can be simulated. Some positions on the band conveyor are equipped with light sensors to detect a workpiece.
p2
RIOM
Plant
Fig. 7. Hardware architecture of the demonstration application.
6038
Proceedings of the 20th IFAC World Congress Toulouse, France, July 9-14, 2017 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860
5859
machining
machining
idle
idle
[piston1_free==0]/ {c2=1; piston1_out=1}
[piston1_free==0]/ {c2=1; piston1_out=1}
conveying1
conveying1
[l4==1]/ {c2=0;c3=0; machine2_free=0}
[l3==1]/ {c2=0; m1=1}
machining1
machining1
[after(1000,msec)]/ {m1=0}
[after(1000,msec)]/ {m1=0; c2=1; c3=1}
wait_for_m2
conveying2
[machine2_free==1]/ {c2=1;c3=1}
[l4==1]/ {c2=0, c3=0, m2=1}
[1]
[l3==1]/ {c2=0; m1=1}
conveying2
machining2 [after(3000,msec)]/ {m2=0}
Fig. 9. This state machine controls the line in the area of the first machining station after the update.
wait_for_storage [piston2_free==1]/ {c3=1}
Fig. 8 shows machining in the first software version. Step by step, the workpiece is handled. As soon as the piston pushes a workpiece on the band, it is transported to the first machining station. After the machining it is transported to the second machining station. The workpiece is transported to the storage system, when the second machining is finished and the storage is ready to receive the product.
conveying3 [after(1500,msec)]/ {c3=0; piston2_free=0} delivered
Fig. 8. This state machine controls the main line of the plant including both machining stations before the update. A remote I/O module 2 (RIOM) is connected to the plant’s sensors and actuators. The RIOM and a computer communicate with the Modbus TCP protocol over Ethernet. On the computer ERTS runs the controller software. Fig. 7 illustrates this architecture. 4.2 Case study Machining Process In the first software version four state machines build the controller. The machining process itself is modeled with the state machine machining. It controls the main line of the plant including the machining stations. The three other state machines control the supply conveyor, the storage conveyor and the pistons. 2
PHOENIX CONTACT – ILB ETH 24 DI16 DIO16-2TX
In this case study, the user starts the production system with the first version of the controller. After some time, the user detects that the strictly sequential execution in the machining process could be optimized. In this version, the first machine is idle as long as the controller manages the second station. An upgrade of the Stateflow model will allow the two machines to work concurrently, thus the throughput will be increased. To perform this upgrade, a new controller version is modeled. The three state machines for supply and storage conveyors and pistons are transfered to the new version without modifications. The state machine machining is modified and will only manage the machining process on the first station. Another state machine machining2 is added to control the second machining station. Fig. 9 and Fig. 10 show the new state machines. For the three unmodified state machines and the added state machine the state transformation is possible in any case. The paired state machines machining (represented by Fig. 8 and Fig. 9) share 4 matching states: idle, conveying1, machining1 and conveying2. A matching state and therefore a transformable state of the controller will eventually be reached, because the machining process in the first version is cyclical.
6039
Proceedings of the 20th IFAC World Congress 5860 Sebastian Q. Roder et al. / IFAC PapersOnLine 50-1 (2017) 5855–5860 Toulouse, France, July 9-14, 2017
state machines. This seems to be attractive especially for modeling languages, that support independent state machines. The concurrency capability of Erlang could be utilized and the performance of the controller improved.
machining2 initial
For an industrial automation system real-time performance is essential. On the one hand, the hardware architecture presented in Sec. 4.1 has to be improved. Firstly, a real-time fieldbus communication protocol such as EtherCAT should be used instead of Modbus TCP and secondly, the computer system should support real-time applications. On the other hand, the software has to be modified. An important point to remind is that Erlang supports soft real-time but does not guarantee hard realtime. Nicosia (2007) shows how to improve Erlang’s soft real-time performance to hard real-time.
[1]/ {machine2_free=1} idle
[machine2_free==0]/ {m2=1} machining [1]/ {piston2_free=0, machine2_free=1}
[after(3000,msec)]/ {m2=0}
Generally speaking, the focus of further research will be placed in applying the method to large scale systems, to determine scalability and performance of this method under realistic circumstances.
wait_for_storage [piston2_free==1]/ {c3=1}
REFERENCES
conveying [after(1500,msec)]/ {c3=0} delivered
Fig. 10. This state machine controls the line in the area of the second machining station after the update. 4.3 Experimental Results Experiments show, that the plant can be controlled with both software versions. The modeled behavior is executed without any noticeable delays. The update is easy to apply and the production is not affected in any way. Furthermore, the throughput could be increased by the update. 5. CONCLUSION In this paper, a novel method for controlling industrial automation plants was presented, including a conceptional easy way to model a controller and reprogram it in a running system. Furthermore, a possible application of ERTS to industrial automation tasks was given. In a case study the method was applied to a real system with promising results. So far, the data server is written manually and cannot yet be updated as mentioned in Sec. 3.1. It would be interesting to extend the code generation and DSU to the data server. The aspect of Updatability from Sec. 3.3 could be investigated with reachability analysis. It is important to know, if an update will be successful before trying to apply it to a running system.
Armstrong, J., Virding, S., and Williams, M. (2016). Erlang user’s guide and reference manual. Armstrong, J. (1996). Erlang - a survey of the language and its industrial applications. In Proc. INAP, volume 96. Armstrong, J., D¨acker, B., Lindgren, T., and Millroth, H. (2011). Open-source Erlang - white paper. Atmojo, U., Salcic, Z., and Wang, K.K. (2017). Dynamic online reconfiguration in manufacturing systems using SOSJ framework. In IEEE International Conference on Industrial Informatics (INDIN). doi: 10.1109/INDIN.2016.7819249. Brennan, R.W., Vrba, P., Tichy, P., Zoitl, A., S¨ under, C., Strasser, T., and Marik, V. (2008). Developments in dynamic and intelligent reconfiguration of industrial automation. Computers in Industry, 59(6), 533–547. doi:10.1016/j.compind.2008.02.001. Ericsson AB (2016). Erlang/OTP System Documentation, 8.0 edition. Nicosia, V. (2007). Towards hard real-time Erlang. In Proceedings of the 2007 ACM SIGPLAN Workshop on Erlang, 29–36. Prenzel, L. and Provost, J. (2017). Dynamic software updating of IEC 61499 implementation using Erlang runtime system. In 20th IFAC World Congress, 2017. Seifzadeh, H., Abolhassani, H., and Moshkenani, M.S. (2013). A survey of dynamic software updating. Journal of Software: Evolution and Process, 25(5), 535–568. Wahler, M. and Oriol, M. (2014). Disruption-free software updates in automation systems. In 19th IEEE International Conference on Emerging Technologies and Factory Automation, ETFA 2014. doi: 10.1109/ETFA.2014.7005075. Wahler, M., Richter, S., and Oriol, M. (2009). Dynamic Software Updates for Real-Time Systems. Proceedings of the Second International Workshop on Hot Topics in Software Upgrades HotSWUp 09, (October). doi: 10.1145/1656437.1656440.
As mentioned before, the method presented in this paper has been applied to Stateflow as an illustration, but could be extended to other modeling languages based on finite 6040