Hirsch · Claudia Priesterjahn · Wilhelm Schäfer ... T. Eckardt, C. Heinzemann, C. Priesterjahn, W. Schäfer .... pens that the front role breaks without notifying the.
Noname manuscript No. (will be inserted by the editor)
Modeling and Verifying Dynamic Communication Structures based on Graph Transformations Tobias Eckardt · Christian Heinzemann · Stefan Henkler · Martin Hirsch · Claudia Priesterjahn · Wilhelm Sch¨ afer
Received: date / Accepted: date
Abstract Current and especially future software systems increasingly exhibit so-called self-* properties (e.g., self-healing or self-optimization). In essence, this means that software in such systems needs to be reconfigurable at run-time to remedy a detected failure or to adjust to a changing environment. Reconfiguration includes adding or deleting (software) components as well as adding or deleting component interaction. As a consequence, the state space of self-* systems becomes so complex, that current verification approaches like model checking or theorem proving usually do not scale. Our approach addresses this problem by firstly defining a system architecture with clearly defined components and their interfaces (ports including the definition of signatures of all events and methods which the port may receive and the component may execute) and so-called coordination patterns. These coordination patterns specify communication protocols based on the definition of the ports only for those component interactions which are defined in the (static) architecture specification by a corresponding connection. Secondly, the reconfiguration of architectures is precisely defined by giving a formal definition of all change operations, e.g., T. Eckardt, C. Heinzemann, C. Priesterjahn, W. Sch¨ afer Heinz Nixdorf Institute and Department of Computer Science Software Engineering Group University of Paderborn, D-33098 Paderborn, Germany E-mail: [tobie|c.heinzemann|cpr|wilhelm]@uni-paderborn.de S. Henkler now with: OFFIS Escherweg 2, D-26121 Oldenburg, Germany E-mail: [stefan.henkler]@offis.de M. Hirsch now with: Fachbereich Informatik, Fachhochschule Dortmund Emil-Figge-Straße 42, D-44227 Dortmund, Germany E-mail: [martin.hirsch]@fh-dortmund.de
adding or deleting components and component connections. By exploiting this formal definition, it becomes provable that an architecture includes only component connections which correspond to the defined coordination patterns. Then, the verification of safety and liveness properties has to be carried out only for each individual coordination pattern rather than for the system as a whole. Keywords Self-* · Statecharts · Model Checking · Graph Transformations · Real-Time
1 Introduction Current and especially future software systems increasingly exhibit so-called self-* properties (e.g., self-healing or self-optimization). In essence, this means that software parts in such systems need to be replaceable at run-time to remedy a detected failure or to adjust to a changing environment. Replacing parts which we call reconfiguration includes adding or deleting well-defined component instances as well as adding or deleting component connections. This increases the complexity of the software significantly because the reconfiguration process also has to be controlled by software and it has to function correctly, i.e., a reconfiguration should not result in a system failure. In general, high quality software is absolutely necessary, as many of these systems are used in a safety-critical environment (like mechatronic systems [Sch¨afer and Wehrheim(2007)]). The software, in particular, must satisfy safety and liveness properties. A common approach (at least in research and advanced industrial projects) to address these challenges is to verify as many constraints as possible at the model-level, i.e., the software model is analyzed formally and then
2
code is automatically generated from the model which itself is correct by construction. However, the state space of self-* systems may become so complex that current verification approaches like model checking or theorem proving, which usually explore the whole state space, do not scale [Alur(2008)]. Even when using a compositional approach to verification and applying symbolic techniques, it is hardly possible to track all possible reachable system states because the possible dependencies between different, usually highly concurrent component interactions in a complex and ever changing network of component instances are by far too many. Our approach addresses this problem by firstly defining a system architecture with clearly defined components and their interfaces (ports including the definition of signatures of all events and methods which the port may receive and the component may execute) and so-called coordination patterns. These coordination patterns specify communication protocols based on the definition of the ports only for those component interactions which are defined in the architecture specification by a corresponding connection. These protocol specifications take into account that components may be executed concurrently and thus specify especially asynchronous and synchronous event-based communication. Secondly, the reconfiguration of architectures is precisely defined by giving a formal definition of all change operations, e.g., adding or deleting components and component connections. By exploiting this formal definition, it becomes provable that an architecture includes only component connections which correspond to the defined coordination patterns. Then, the verification of safety and liveness properties has to be carried out only for each individual coordination pattern rather than for the system as a whole. In this paper, we extend our approach called MechatronicUML [Giese et al(2008)]. It was restricted to the specification of bilateral communication using (extended) timed automata called real-time statecharts and it neglects architectural reconfiguration at run-time. We define the reconfiguration of component architectures formally, i.e., all possible change operations by graph transformation rules. This extension of the approach provides for the formal analysis of certain properties of the reconfiguration operations, in particular the property that only connections are created which correspond to (pre-)defined coordination patterns. This in turn guarantees that checking safety and liveness properties of the whole system by only checking individual coordination patterns is still ensured.
The key contribution of this paper, is thus a particular modeling and verification approach based on a combination of graph transformation rules and extended timed automata. It addresses the challenge of scalability of verification of large systems, even in cases where a system does not only exhibit an arbitrarily large finite number of states but an infinite number of states. A concrete example for a complex self-* system with the need to coordinate a varying large number of component instances is the RailCab project1 . The vision of the RailCab project is a mechatronic rail system where autonomous vehicles called RailCabs apply the linear drive technology, as used by the Transrapid system, but travel on the existing passive track system of a standard railway system. This system is currently under construction and a first version of the controlling software of the physically existing system has been built using the approach of [Henke et al(2008)]. One particular problem, which we use as the running example of this paper, is the coordination of RailCabs. RailCabs drive in a convoy in order to reduce energy consumption caused by air resistance and to achieve a higher system throughput. Such convoys are established on-demand and require small distances between the RailCabs. These required small distances make the coordination and consequently the corresponding coordination pattern between the RailCabs a very safety-critical operation. In addition, a complex coordination is required when the convoy consists of more than two RailCabs. Since RailCabs may join or leave a convoy during run-time, a flexible structure for the specification of the coordination is needed. The paper is structured as follows: We first review the original MechatronicUML approach in Section 2. Section 3 covers the concepts for modeling parameterized coordination patterns with a flexible number of participants. In Section 4 we define the formalism to specify reconfigurable system architectures based on timed graph transformations. Then, we introduce a formalism in Section 5 as a common semantic basis for real-time statecharts and timed graph transformation. This semantic basis is used in the verification approach that is described in Section 6. We present an evaluation of a cutout of the RailCab example in Section 7. Finally, we discuss related work in Section 8. The last section summarizes the paper and gives an outlook on future work.
1
http://www-nbp.upb.de
3
2 Modeling Bilateral Communications In our approach, the architecture is given by components, their ports and the connections between ports (which are just identified by links). This model is described formally by an extension of the UML 2.0 component model. Among other aspects, the extension especially covers the definition of restrictions on how ports have to be connected such that communication via different ports of the same component is guaranteed to be free from side effects. That means, the behaviors of the ports do not interfere with each other. AG rear.convoy implies front.convoy
Station
...
Registry
DistanceControl
RailCab1
RailCab2
...
front rear
Fig. 1 Excerpt from the Architecture Description
Figure 1 shows the concrete syntax of our extensions. We extend UML 2.0 component diagrams by dashed ellipses that represent coordination patterns. A coordination pattern is used to model the communication protocol between communicating components [Giese et al(2003)]. The communicating components are represented by roles. Thus, a coordination pattern consists of two roles and a connector linking the roles. The role behavior is implemented by ports, that build the interfaces of our components. In Figure 1, we only show an excerpt from a larger architecture diagram that consists of many more components and coordination patterns than we present in this paper. Within dashed rectangles, we define safety properties that have to hold for the coordination pattern. Safety properties are defined in ATCTL [Alur et al(1993)] which makes them processable by existing model checkers. In our example, the coordination between two RailCabs is modeled by the DistanceControl pattern (cf. Figure 1). It consists of two roles, the front role and the rear role, and one connector that models the link between the two RailCabs. The coordination pattern specifies the protocol to coordinate two RailCabs following each other. A safety requirement of this coordination pattern is that the two RailCabs do not collide with each other. When driving in a convoy, a possible reason for a collision is that the front RailCab breaks without notifying the rear RailCab that it must break, too. The property describes the front role to be in convoy mode whenever
the rear role is in convoy mode. This way, it never happens that the front role breaks without notifying the rear role to break, as the notification is associated with the convoy state, i.e., a notification event is raised when a shuttle is in convoy state and has to break. The behavior of roles and ports is specified by realtime statecharts [Giese et al(2003)]. Real-time statecharts (RTSC) are an extension of UML state machines which support more powerful concepts for the specification of real-time behavior. They contain clocks and constraints over these clocks. Especially, RTSCs allow that time passes during the execution of a transition, which is modeled by so-called deadlines – time intervals that define the minimum and maximum duration of the execution of the transition. Events are defined by ports and occur as trigger or raised events which are attached to the transitions of an RTSC. A trigger event is placed in front of a ”/”, a raised event is placed behind it. Formally, RTSCs are an extension of timed automata. We defined a mapping from RTSCs to timed automata such that RTSCs are verified using the model checker UPPAAL2 which takes ATCTL formula as property specifications. rear noConvoy
front.convoyProposalRejected/ /front.convoyProposal
default
front.leaveConvoy/
wait
front.startConvoy/
convoy /front.leaveConvoyProposal
wait
default
front.leaveConvoyProposalRejected/ front noConvoy default
/rear.convoyProposalRejected rear.convoyProposal/ {t0}
wait
1 < t0 < 1000
answer
/rear.startConvoy convoy
rear.leaveConvoyProposal /rear.leaveConvoy
default rear.leaveConvoyProposal /rear.leaveConvoyProposalRejected
Fig. 2 Real-Time Coordination Pattern for a RailCab Convoy
Figure 2 shows the RTSCs for the front role and rear role of the DistanceControl coordination pattern. Initially, both roles are in state noConvoy::default, which means that they are not running in a convoy. When the rear role decides to propose building a convoy, an event convoyProposal is sent to the other RailCab or more precisely is raised in the RTSC representing the behavior of its front 2
www.uppaal.com
4
role. The front role decides to reject or to accept the proposal after a maximum of 1000 units of time. In the first case, both roles revert to the noConvoy::default state. In the second case, both roles switch to the convoy::default state. Eventually, the rear RailCab decides to leave the convoy and sends a corresponding proposal to the front RailCab, i.e., raises a corresponding event. The front RailCab decides to reject or accept that proposal. In the first case, both RailCabs remain in convoy mode. In the second case, the front RailCab replies by an approval event, and both roles switch into their respective noConvoy::default states.
3 Modeling Multilateral Communication We now extend coordination patterns to parameterized coordination patterns. Parameterized coordination patterns support modeling multilateral communication with an arbitrary but fixed number of communicating components. We classify the roles of a parameterized coordination pattern into multi-roles and simple roles that have been introduced as roles in Section 2. A simple role is communicating with either another simple role, as described in Section 2, or with a multi-role, as described in the following. Basically, a multi-role defines the behavior of a role which communicates with several simple roles (cf. Figure 3). All simple roles have the same behavior. A multirole is a parallel composition of a set of sub-roles each communicating asynchronously with a simple role. Subroles communicate synchronously with each other. An adaptation statechart initializes the multi-role and also initiates the communication between sub-roles and creates each sub-role. The creation of sub-roles will be explained in Section 4.
adaptation RTSC
multi-role
...
sub-role1 RTSC
simple role RTSC
sub-rolek RTSC
simple role RTSC
... sub-rolen RTSC
simple role RTSC
Fig. 3 Schematic Structure of a Parameterized Coordination Pattern
The behavior of a multi-role is specified by parameterized RTSCs that define the behavior of each sub-role as well as of the adaptation statechart. Parameterized RTSCs are semantically based on parameterized timed
automata, which are timed automata extended by parameterized synchronization (for a formal definition cf. Section 6.2). We implement parameterized synchronization by using integers as index of synchronizations of the form si with s being the synchronization’s name and i the index. Only synchronizations with the same index correspond. Using parameterized synchronizations, the adaptation statechart triggers the communication of the first sub-role. Each sub-role triggers the next subrole and the last sub-role again triggers the adaptation statechart and so forth. As an example consider the ConvoyCoordination pattern (cf. Figure 4). It introduces the multi-role coordinator which communicates with all RailCabs of a convoy. AG member.statorFailure implies coordinator.statorFailure
ConvoyCoordination
member
coordinator
RailCab1
RailCab2 DistanceControl
member
RailCab3 DistanceControl
Fig. 4 Extended Convoy Example
Before we can explain the example in further detail, we extend the concrete syntax of RTSCs of Section 2. This is needed for modeling the communication inside the multi-role. Besides events, transitions of an RTSC may carry synchronizations and side effects. Events model asynchronous communication between RTSCs. Synchronizations model synchronous communication between RTSCs of the same multi-role. They are defined analogously to UPPAAL synchronizations (cf. [Bengtsson and Yi(2003)]), i.e., they are marked with ”?” or ”!” for received or initiated synchronizations, respectively. Side effects are methods being executed by the corresponding component when the transition fires. The parameterized RTSC of the coordinator role is depicted in Figure 5. Initially, the coordinator role is in state idle waiting for a synchronization. If it synchronizes using nextk ! through the parameterized synchronization next, the role switches to state sendUpdate. Initially, nextk is initiated by the adaptation statechart as depicted in Figure 6 while in all following operations nextk is initiated by the previous role with index k − 1. The communication with the member role is started. First, an update event including current profile data, the reference velocity as well as the reference position of the RailCab, is sent. Thereafter, the role waits in state awaitAck for the
5
confirming trigger event ack by the member role. When this event is received, the role switches back to state idle and initiates the synchronization nextk+1 ! to activate the next sub-role. At an arbitrary point in time, the coordinator role might receive a publishStatorFailure event from the member role. In this case, the RTSC switches to the state statorFailure. Please note that this is only an excerpt as, e.g., further error handling mechanisms are omitted in this example. rtsc : CoordRoleSC | Clocks: c1
publishStatorFailure() /
idle nextk?
statorFailure
[1;1] ack(..) / nextk+1!
{c1} sendUpdate / update(..) awaitAck c1 ≤ 10 [30;30] c1 ≤ 49
Fig. 5 The Behavior of a coordinator Sub-Role k
The adaptation statechart of the coordinator multirole shown in Figure 6 is initially in state noConvoy. If the RailCab is chosen to coordinate the convoy by the coordinate synchronization, the RTSC switches to state addMember. The decision about the leader of a convoy is assumed to be made in a separate component not included in this example. After the expiration of the invariant, the RTSC switches to state convoy. The invariant c3 ≤ 500 ensures that the state is left after 500 units of time elapsed. Then, the adaptation statechart triggers the first coordinator role to initiate the sending of the profile updates as described above. The last subrole triggers the transition from sendUpdates to convoy using the synchronization nextn+1 ? where n denotes the total number of coordinator sub-roles (the counterpart is the nextk+1 ! synchronization from the rolek RTSC depicted in Figure 5). Using the transition from convoy to addMember, new convoy members are added. Again, the behavior dealing with the recognition and decision to add new convoy members is assumed to be specified in another RTSC not included in this example. createPort() is a typical example of a side effect which defines an architectural reconfiguration. In this case, it creates a sub-port of the coordinator multi-port. Such operations are defined formally by graph transformations as will be explained in the following section. The RTSC of the role member is depicted in Figure 7. Initially, the role is in state waitUpdate. Whenever 500 units of time elapsed, the role has to receive an update event from the role coordinator. This event includes the current profile, reference position and reference velocity. The role confirms the receipt of the event by the
rtsc : AdaptationSC | Clocks: c3
nextn+1?
noConvoy
convoy c3 ≤ 500
coordinate? createPort(1)
0 ≤ c3 ≤ 489 newFollower? createPort(n + 1) [10;10] addMember
next1! {c3} sendUpdates c3 == 500 c3 ≤ 499
[1;1]
[10;10] c3 ≤ 499
Fig. 6 The Adaptation Statechart of the coordinator Multi-Role
raised event ack including the current position and current velocity. In case no update event is triggered (e.g., network failure), the role switches to the networkFailure state after 500 units of time elapsed. The state statorFailure will be reached if the RailCab detects a stator failure. Again, this example only represents an excerpt of the real behavior. rtsc : MemberRoleSC | Clocks: c2
c2 > 500
waitUpdate
[1;1] /ack(..)
sendAck c2 ≤ 1
c2 ≤ 500 update(..) /
[1;1]
{c2}
/ publishStatorFailure() networkFailure
statorFailure
Fig. 7 The Behavior of a RailCab Role member
One necessary safety property requires the member role to be in state statorFailure while the coordinator role is also in state statorFailure (AG member.statorFailure implies coordinator.statorFailure).
4 Modeling Architectural Reconfigurations As seen above, the side effects attached to transitions in RTSCs specify operations which reconfigure the architecture at runtime, e.g., create or delete components or connections between components. They have to be defined formally, as well, in order to verify that they do not invalidate the verification performed on the RTSCs. In fact, if a verification of side effects is not possible, as it is usually the case with other statechart notations, the definition of side effects could include arbitrary state changes and corresponding failure traces which are not caught by model checking. That is the reason why we employ a formal notation to specify side effects, namely graph transformation rules. As we will see later, graph transformation rules are a formalism which enables model checking, as well.
6
We use graph transformation rules as a formalism because we have to specify possibly complex structural changes of the underlying architecture. This architecture basically corresponds to a graph of nodes representing components or coordination patterns and edges which represent connections or the association of coordination patterns with connections (cf. Section 2). 4.1 Applying Graph Transformations A graph transformation rule consists of a left hand side and a right hand side. The left hand side defines the particular graph where the rule is applicable, i.e., the graph contains an isomorphic image of the left hand side as a subgraph; the right hand side defines the result of the application, i.e., the changes to be made to the graph or in other words the creation of a new subgraph which is an isomorphic image of the right hand side. For a short hand notation, left and right hand side are depicted in one single graph using the notation or for edges (and nodes) which are created or deleted during rule application. This short hand notation is called story pattern [Fischer et al(2000)]. In many cases, the execution of a side effect of a transition of an RTSC cannot be specified within one story pattern, because it may include complex operations. Therefore, we use story diagrams [Fischer et al(2000)] which are UML Activity Diagrams [UML(2009)] that embed story patterns in the activities. Figure 8(a) shows a simple story diagram that corresponds to the side effect createPort() of the adaptation statechart of Figure 6. It defines the creation of one subrole of the multi-role coordinator and its corresponding connector and simple role. It further generates a new coordinator role statechart. (Note that a complete statechart is nothing else as a graph in this sense.) By the stereotype we specify that a new RailCab will join the convoy at the last position only. For the edge between rc1 and rc2, the stereotype is deleted because rc2 is no longer the last RailCab of the convoy. A graph transformation system consists of finitely many story diagrams and a start graph. In our case, a start graph defines an initial architecture and the set of story diagrams defines all allowed changes to this architecture. For a more detailed discussion of graph transformation systems see [Rozenberg(1997)], for a formal definition see Section 6. The challenge for model checking such a graph transformation system is to guarantee that no graphs are generated which contain so-called forbidden graphs. Forbidden graphs are subgraphs which, e.g., include a connection which does not correspond to a (pre-) defined coordination pattern. This could be a connection
rc1 : RailCab :P
: VelocityControl
:P Role instance >
:P
:P
> :P
rc3 : RailCab
c:Clock Instance
rc2 : RailCab :P
:P
: VelocityControl
: VelocityControl :P
:P {c < 20}
(a) Simple Story Diagram for the Side Effect createPort() : RailCab :Pj
:Pi + 1
Role instance
:Pi + 2
Node operator
(b) Forbidden Graph Fig. 8 Story Diagram Specifying the Extension of a Convoy and a Forbidden Configuration
between a registry component and a station component (cf. Figure 1) or a connection between the first and the third RailCab component in a convoy, if a coordination pattern is only defined for communication between RailCabs directly following each other. Such forbidden graphs basically correspond to the safety properties specified by ATCTL (cf. Section 2) when dealing with RTSCs only and considering no side effects. In the case of graph transformation systems, safety properties are naturally specified by graphs, as well. As an example, take Figure 8(b). Assuming that sub-roles of a multi-role are ordered by an ascending key, the forbidden graph specifies the property that no two sub-role components communicate with each other, if they are not direct neighbors according to their keys. As there may exist infinitely many of these forbidden graphs (the chain between two non-neighboring sub-roles could be arbitrarily long), the edges in such a forbidden graph specification could in fact express a path of arbitrary length. Such an edge is called a node operator. Based on the definition in [Engels et al(1992)], a node operator specifies the set of all nodes which can be reached from a source node by following the path expressed by the operator by enumerating the corresponding edge labels and using some
7
composition operators. We omit details here because they are not relevant for understanding the verification of parameterized coordination patterns which is the focus of this paper. The reader, not familiar with node operators, should just consider forbidden graphs as graphs of nodes and edges and assume that more complex properties could be specified, if the edges are extended to node operators. In any case, as will be explained in Section 6, automated model checking, whether a given graph transformation system may or may not generate a forbidden graph, becomes possible. 4.2 Timed Graph Transformation Systems The reconfiguration of an embedded or mechatronic system architecture, here defined by story diagrams, is often time critical. Especially, the creation or deletion of a port or component might involve complex operations. Verification of time constraints for reconfiguration operations should consequently be verifiable on the model level, as well. Therefore, we enhance our specification approach by adding clocks and time constraints over these clocks to a story diagram to specify the time which is needed for the corresponding reconfiguration operation. Time is measured by clocks as in RTSCs. In RTSCs, a clock applies to one RTSC instance, i.e., each RTSC instance of each sub-role has its own clock. Accordingly, in timed graph transformations a clock is valid for a certain subgraph of a graph. Such a subgraph may occur more than once in a graph and all of its occurrences might be created at different times. Therefore, the clock has to be added to the same graph several times (once for each subgraph it applies to). As all these instances of the clock may have different values, we use the term clock instance to refer to the clocks being added to the graphs. The clock serves as a type for the clock instances. By adding clock instances to the graph, we obtain a timed graph. Consequently, we extend story patterns to timed story patterns by adding clock instances to the story patterns as well as conditions over these clock instances. By embedding timed story patterns into the activities of story diagrams, we obtain timed story diagrams which we will use to specify our common formalism in Section 5. A timed story pattern may carry a time guard that restricts the execution of this timed story pattern to a certain time interval. Additionally, clock instances may be reset to zero. In contrast to normal story patterns, we need two more kinds of story patterns. These are clock instance story patterns and invariant story patterns which we need for our common formalism. For
each clock instance, there exists one clock instance story pattern matching the subgraph that this clock instance applies to. Whenever the subgraph occurs in the graph, a clock instance is added to this subgraph if it does not yet exist. Invariant story patterns have similar semantics as state invariants of RTSCs (cf. Section 3). They specify a left hand side containing a clock instance and a condition on this clock instance. Whenever the left hand side occurs in the graph, the condition must evaluate to true. Otherwise, a time stopping deadlock occurs. In our example in Figure 8(a), we use a clock instance c. The time guard c < 20 specifies that the creation of a link between two RailCabs may only be executed 20 units of time after the last reset of c. Thereby, we guarantee that the creation of the link is finished in the desired time interval. A formal definition of timed graph transformation systems will be given in Section 6.2.2. 5 A Common Formalism for Defining Semantics Parameterized coordination patterns are used to define multilateral communication and its corresponding architectural reconfiguration. They are given by a syntactic and semantic combination of parameterized RTSCs (cf. Section 3) and timed story diagrams which specify complex side effects corresponding to architectural reconfigurations (cf. Section 4.1). For instance, the adaptation statechart in Figure 6 has a side effect createPort() that is formalized by the timed story diagram depicted in Figure 8(a). The verification of parameterized coordination patterns with respect to safety properties requires to consider both parts of parameterized coordination patterns, namely RTSCs and the specification of side effects by timed story diagrams, in order to achieve valid verification results. A formal semantic definition of these patterns is needed as a basis for model checking and as an input to a corresponding model checker. Again, we employ graph transformation systems but with a different goal and purpose than in Section 4. In this case, a graph transformation system defines the formal semantics of a parameterized coordination pattern just as a timed automaton defines the formal semantics of a non-parameterized coordination pattern (cf. Section 2). It is a definition which is not to be seen by the user of a model checker who specifies a parameterized coordination pattern and a property. By using the formal semantic definition based on timed story diagrams as explained in the following, the input of a model checker is automatically generated, i.e., the parameterized coordination pattern is translated into a form which is processable by a model checker.
8
Note that graph transformation systems play a double role in our approach. On the one hand, they are used to specify side effects formally (to be done by the user) and on the other hand, they are used to define an underlying semantics. These are two separate activities not to be mixed with each other. The basic idea for generating model checker input from a parameterized coordination pattern or rather its defining parameterized RTSC is the translation of the RTSC into a timed graph and a set of timed story diagrams (cf. Section 4.2). The timed graph encodes the states of the RTSC as well as the active state. The transitions of the RTSC are defined by timed story diagrams. Figure 9 shows an example of a timed graph representing the adaptation statechart (cf. Figure 6) using the concrete syntax of UML Object Diagrams [UML(2009)]. There exists one node for the RTSC and one node for each of the four states of the adaptation statechart carrying the name of the state as an attribute. The statechart has an event queue storing the received events as well as an active state. In the example, the statechart is in the convoy state that offers a synchronization next1 . The clock instance, typed over the clock c3, references all nodes belonging to the adaptation statechart.
concrete parameter k of that instance is encoded as an attribute parameter in the ActiveState node pointing to the current state of instance k. Possibly parameterized synchronizations as used in Figure 5, for example, are mapped to Synchronization objects. They contain the name of the synchronization as well as the parameter in case of a parameterized synchronization as attributes. Additionally, the node has edges to the states in which the synchronization is available. Object
1
1
value
Parameter name : String
1 EventQueue parameter : int enqueue(Event e) 1 dequeue()
ClockInstance type : Clock value : real
Statechart name : String
1
next
in
1..*
ActiveState parameter : int 0..*
in
0..1
1..*
1
active 1
State name : String 0..*
0..1
0..1
recvSrc
hasNode
eq:EventQueue parameter = 1 hasNode
has
in
s1:State name = „noConvoy“ hasNode
in
0..*
Fig. 10 Type System of the Formalism
in
as:ActiveState parameter = 1 active
s4:State name = „convoy“
s2:State s3:State name = „addMember“ name = „sendUpdates“ hasNode
0..*
Synchronization parameter : int name : String
hasNode
in in
0..*
hasNode
hasNode
sc:Statechart name = „AdaptationSC“
has
hasNode
0..1
0..1
1
1..*
ComplexState
0..1
1
subStatechart
deleteSyncChannels()
1
Event name : String
tail
1
has
0..1
sendSrc ci:ClockInstance a a type = c3 a a value = 500.0
0..* {ordered}
has head
sendSrc
sy1:Synchronization name = „next“ parameter = 1
Fig. 9 Excerpt of a Timed Graph of the Adaptation Statechart
The timed graphs being created for the RTSCs are typed over the model shown in Figure 10 given as a UML Class Diagram. The class Statechart represents the RTSC which contains a set of States and might be contained as a sub-statechart in a ComplexState. Considering parameterized RTSCs, all instances have the same structure. We exploit this fact by generating the nodes for the states only once for all statechart instances. Then, we only need to create one additional ActiveState node when creating a new statechart instance. The
The asynchronous communication between the roles is supported by the EventQueue mechanism. An RTSC may receive Events by reading them from the queue and sends events by inserting them to the EventQueue of another RTSC. Each event may have an ordered set of Parameters, which may carry arbitrary objects as values. The class ClockInstance represents the clock instances being added to a timed graph. The ClockInstance nodes may have hasNode edges to all elements of the RTSC. Thus, the class ClockInstance has an association hasNode to all other classes being depicted in Figure 10. These are omitted for better readability of the figure. The attribute type refers to the clock over which the clock instance is typed. The transitions of an RTSC are transformed into timed story diagrams. There exists one story diagram for each transition that executes the transition by changing the active edge of the ActiveState node to the target state of the transition. It also performs all side effects of the transition that are also specified by timed story diagrams (cf. Section 4.2). Figure 11 shows an example of a transition, namely the transition from con-
9
to addMember in the adaptation statechart. Since the transition specifies a deadline, time passes during the execution of the transition. Time is not allowed to pass on transitions in timed automata (cf. [Alur(1999)]), i.e., the values of the clock instances must not be increased. Therefore, time is not allowed to pass during a story diagram either. Consequently, our common formalism switches to an intermediate state in which time may pass, as it has been defined for the mapping of RTSCs to timed automata in [Giese and Burmester(2003)]. voy
CoordRoleSC::convoy_intermediate1()
createPort(n+1)
rc1 : RailCab
this in
in
in
s1 : State name = „convoy“
active as : ActiveState active
s2 : State name = „intermediate1“
hasNode hasNode
ci : ClockInstance type = c3
hasNode
{ ci≤489 }
Fig. 11 Timed Story Diagram Executing a Transition
The timed story diagram of Figure 11 states that the RTSC must be in state convoy. It also contains the time guard {ci ≤ 489} of the transition as a condition on the clock instance ci. The side effect createPort(n+1) of the transition is mapped to a call on the RailCab node that the RTSC belongs to. The side effect createPort is again specified by a timed story diagram. In case of synchronizations, both transitions have to be executed synchronously. A joint timed story diagram is specified executing both transitions. In order to obtain correct results for a reachability analysis (cf. Section 6.2.2), such joint transitions have to be created for all pairs of transitions that may possibly synchronize (cf. [Behrmann et al(2004)]). Considering the RTSCs in Figures 5 and 6, multiple transitions synchronizing over the next synchronization exist. It cannot be determined from the model description which transitions may synchronize during run-time. Therefore, timed story diagrams for all possible pairs of such transitions have to be created to obtain the full reachable behavior. Figure 12 shows an example for such a joint timed story diagram considering the transitions from idle to sendUpdate and from convoy to sendUpdates. The first activity specifies the precondition for firing the transition. The RTSCs have to be in the source states of the transitions and the synchronization next1
has to be associated with both source states s1 and s2. It also specifies a guard in curly brackets restricting the sub-role indices to the parameter of the synchronization. As before, the time guard of the transition is contained in the precondition. If the precondition has been matched successfully, the synchronization is deleted and the execution proceeds with the second activity. Otherwise, the execution stops using the failure transition to the final state. The second activity removes the edge to the newFollower synchronization for the state convoy (cf. Figure 6). As the state convoy is left, the synchronizations for other outgoing transitions of this state are no longer available. The deleteUnboundSynchronization function removes all synchronizations not being connected to a state any more. Thereafter, the clock resets of the transitions are executed. The state sendUpdates has an outgoing transition with a synchronization nextn+1 which becomes available when the state is entered. The next three activities add the reference of the synchronization to the state sendUpdates. First, it is checked whether the synchronization node already exists. If it exists, the second activity just adds the recvSrc edge to this node. If it does not exist, the third activity creates a new Synchronization node and the corresponding edges. The final activity changes the active states of both RTSCs to the respective target states of the transitions. State invariants are mapped to invariant story patterns (cf. Definition 12 on page 15). The invariant story pattern matches the subgraph where the state that the invariant belongs to is active and specifies the time condition that must be fulfilled. An example of an invariant story pattern for the convoy state of the adaptation statechart is shown in Figure 13. The invariant story pattern matches the RTSC represented by the this node and the convoy state which must be the active state. Additionally, the clock instance referring to all these nodes is matched as the specified time condition has to hold for this clock instance. 6 Verification Model checking RTSCs which define coordination patterns for only bilateral communication as explained in Section 2, is basically simple by mapping them to timed automata and using the model checker UPPAAL. Model checking parameterized RTSCs which define parameterized coordination patterns might span a much larger state space, because reachability analysis has to be performed on the timed graph transformation system which defines its semantics (cf. Section 5). However, we will see that many safety properties can be checked without applying reachability analysis on a given timed graph transformation system. In addition,
10 RailCabSC::transition_IdleSendUpdate_ConvoySendUpdates()
Check applicability of the rule this
subStatechart cs:ComplexState subStatechart cSc:Statechart name = „CoordRoleSC“
in
in
s4:State name = „sendUpdates“
aSc:Statechart name = „AdaptationSC“
in
has hasNode hasNode
ci1:ClockInstance type = c1
as1:ActiveState
hasNode hasNode
in
in
s1:State name = „idle“
active
hasNode
ci2:ClockInstance type = c3
s2:State name = „convoy“
as2:ActiveState
active
sy1:Synchronization name = „next“ recvSrc parameter = 1 sendSrc { as1.getParameter() == sy1.getParameter() ∧as2.getParameter() == sy1.getParameter() } { ci2 == 300 }
[success]
[failure]
Delete synchronizations of outgoing transitions
recvSr
s2 cs
Execute clock resets
sy2:Synchronization name = „newFollower“
deleteUnboundSynchronization()
ci1
reset
ci2
reset
Check for existing synchronization object sy3:Synchronization name = „next“ parameter = aSc.getN() + 1
has
cs
[failure]
[success] Create synchronization and bind it to the state
Bind state to sychronization
recvSrc
s4
s4
sy3
recvSrc
sy3:Synchronization name = „next“ parameter = aSc.getN() + 1
Enter target states cSc
in
s3:State name = „sendUpdate“
in
aSc
s1
active
active
as1
s4
s2
active
Fig. 12 Timed Story Diagram for a Transition with Synchronization
active
as2
has
hasNode
cs
11 aSc : Statechart
as : ActiveState
in
name = „AdaptationSC“ hasNode
hasNode
ci : ClockInstance type = c3
active
hasNode State name = „convoy“
in { ci≤500 }
Fig. 13 Invariant Story Pattern for the State convoy
the empirical evaluation in Section 7 shows that even in the latter case, verification is still possible. Figure 14 gives the different possibilities of the verification process of (parameterized) coordination patterns.
Paremeterized Coordination Pattern Non-synchronized Sub-roles
Synchronized Sub-roles Pairwise Synchronized
Verification of One Pair of a Sub-role and a Simple Role
Verification of One Pair of a Sub-role and a Simple Role + Verification of One Pair of Sub-roles
Arbitrarily Synchronized
Verification of a Complete Parameterized Coordination Pattern
Fig. 14 Possibilities of the Verification Process of Parameterized Coordination Patterns
6.1 Basic Approach To check properties like ”If the coordinator sub-role k sends an update event, it will eventually receive an acknowledgment from the simple role within 20ms” for a fixed sub-role k, it is only necessary to verify bilateral communication, namely one pair of roles consisting of a sub-role and a simple role. Input to the model checker UPPAAL are the RTSCs defining the sub-role and the simple role and a property like the one which was just mentioned. This check only works, if no side effect creates any additional component or connection and there is no synchronization between the involved sub-role and another sub-role. The latter two constraints are guaranteed by syntactic checks of the involved RTSCs. If properties like ”If role k sends an update, role k+1 will eventually send an update” have to be checked, this requires to verify the parallel execution of one pair
of sub-roles, i.e., their corresponding RTSCs, with respect to the mentioned property. As a prerequisite, it must be guaranteed that the side effects of the involved RTSCs do not create a communication structure where more than the two sub-roles communicate. Consequently, verification of all side effects of the involved RTSCs needs to check whether no corresponding forbidden graph (which specifies additional communication links) is generated. In more detail, verification of one pair of sub-roles includes the following three steps which are: Verification Steps: 1. Verify whether the communication between each of the two involved sub-roles and its corresponding simple roles does not interfere with the communication between the two sub-roles. This means, verify for each pair of sub-role and simple role whether the parallel execution of the sub-role and its corresponding simple role has no deadlock (using UPPAAL). 2. Using the specification of a non-allowed architectural reconfiguration, i.e., non-pairwise communication structure in this case, by a forbidden graph, verify that no side effect of any of the two sub-roles might create such a graph. (As an example for such a graph see again Figure 8(b)). Below, we will explain in more detail how this verification step works. 3. If the first two steps were successful, i.e., no deadlock and no forbidden graph might be created, verify the parallel execution of the two RTSCs defining the two sub-roles with respect to the given property (using UPPAAL). In case of properties like ”When a RailCab enters the convoy, all sub-roles must be in state idle” or ”If the RailCab enters the state convoy, a convoy coordination pattern must be instantiated within 20ms.”, it is unavoidable to check the parameterized coordination pattern as a whole, i.e., take the timed graph transformation system as defined in the last section and apply reachability analysis. This means to formulate a property like the just mentioned ones as a graph and then verify whether the timed graph transformation system defining the particular coordination pattern’s semantics is able to generate such a graph. This means to perform the following three steps which are: Verification Steps: 1. Take the parameterized coordination pattern to be verified and construct the timed graph transformation system using the common formalism described in Section 5. 2. Define the safety property to be checked as a graph.
12
3. Apply reachability analysis to check whether the timed graph transformation system is able to generate the graph as defined in the previous step.
6.2 Formal and Algorithmic Details The above described approach to verification still includes two steps which require some further explanation. First, the verification of the parallel execution of two RTSCs means to consider not only simple timed automata anymore (as UPPAAL input) but parameterized timed automata which have been introduced informally to define the synchronization of sub-roles (cf. Section 3). We still have to show that parameterized timed automata can also be handled by UPPAAL. In addition, the algorithm for reachability analysis of timed graph transformation systems and, even more, the recognition of a forbidden graph (which cannot be achieved by simple reachability analysis) have to explained, as well. As it can be seen from the above given steps, these algorithms build a core part of our approach. 6.2.1 Parameterized Timed Automata Non-parameterized RTSCs are mapped to timed automata [Alur(1999), Bengtsson and Yi(2003)] as described in [Giese and Burmester(2003)] and are thus semantically defined by timed automata. The same mapping is used to map parameterized RTSCs which are used to define sub-roles of a multi-role, to parameterized timed automata. The definition of a parameterized timed automaton below shows that it is nothing else than a special type of a non-parameterized timed automaton and is verified using UPPAAL, as well. As a prerequisite, we have to define clock constraints as given in [Bengtsson and Yi(2003)]. Definition 1 (Clock Constraint) Let C be a set of clocks, ci , cj ∈ C. A clock constraint is a conjunctive formula of atomic constraints of the form ci ∼ n or ci − cj ∼ n with ∼∈ {} and n ∈ N. Clock constraints that are used as invariants have to be restricted as in Definition 2 in order to enable processing by UPPAAL. Definition 2 (Invariant Clock Constraint) Clock constraints being used as invariants are restricted to conjunctions of downward closed atomic clock constraints of the form c ∼ n where ∼∈ {
