Model checking [CGP00, BK08] is an automated formal verification procedure that gives a mathematical proof whether a software model fulfills a given set of formal re- quirements. Thus, it may guarantee the absence of errors in a model, in contrast to testing, which may only show the presence of errors. Timed model checking [ACD93, HNSY94] additionally considers the real-time characteristics that apply to a model of a mechatronic system’s software. In this thesis, we use (timed) model checking as an an- alytical method for showing the correctness of functional and reconfiguration behavior of a self-adaptive mechatronic system.
Timed model checking uses timed automata as introduced in Section 2.2.1 as a be- havioral model. Therefore, timed automata provide the formal basis for specifying state-based real-time behavior in MECHATRONICUML (cf. Section 2.4). The timed
computation tree logic as introduced in Section 2.2.2 enables the specification of for- mal requirements. These formal requirements express the safety and liveness properties that the timed automata need to fulfill. We require knowledge about such formal re- quirements for defining our refinement approach in Chapter 5. Finally, a timed model checking algorithm decides whether the timed automata fulfill the formal requirements given based on the timed computation tree logic (cf. Section 2.2.3).
2.2.1 Timed Automata
A timed automaton [AD94, BY04] is a state-based model for specifying real-time be- havior. Timed automata extend finite automata [Mea55] by a set of real-valued variables called clocks and constraints over these clocks. Clocks measure the progress of time in a system. Time progresses constantly and uniformly in all clocks. In literature, there exist many variants of timed automata (see Waez et al. [WDR11] for a recent survey). In this thesis, we will use timed safety automata [HNSY94] as they are defined for the UPPAAL model checker by Bengtsson and Wang [BY04]. For the remainder of this thesis, we will refer to timed safety automata simply as timed automata.
Like finite automata, timed automata have a set of inputs, a set of outputs, and a set of integer variables. Each transition may consume an input and produce an output. Integer variables may be used for guard conditions of the transitions and may be changed using assignments while the transition fires.
In addition, timed automata support three modeling elements based on clocks. These are invariants, time guards, and resets. An invariant is assigned to a location. The timed automaton may only rest in a location as long as the invariant is true for the current clock values. A time guard restricts the firing of a transition to a time interval. A reset sets a clock back to zero while a transition fires.
Timed automata can be composed to networks of timed automata (NTA). In an NTA, the single automata interact via their inputs and outputs using so-called channels. Then, they use the channels as inputs (marked with ?) and outputs (marked with !).
Figure 2.4 shows an NTA consisting of two timed automata that specify a simple convoy behavior. The member automaton in Figure 2.4b requests to start a convoy. The coordi- nator automaton in Figure 2.4a either starts the convoy or declines the request. Finally, the member automaton may choose to leave the convoy and the coordinator automaton confirms. possible = i, c1 = 0 c1 ≥ 25 && possible == true Idle start! Request Convoy MemberLeaves c1 ≤ 50 request? decline! confirm! leave? i: int[0,1] possible == false (a) Coordinator c2 = 0 c2 ≥ 25 Idle start? c2 ≤ 20 Wait Convoy WaitLeave c2 ≤ 50 request! decline? confirm? leave! c2 = 0 (b) Member
Figure 2.4: Network of Timed Automata Specifying a Simple Convoy Behavior
The two timed automata use five channels namedrequest,start,decline,leave, andconfirm
for realizing the convoy behavior. Each of the timed automata has four locations and five transitions. As an example, the coordinator automaton in Figure 2.4a has locations
Idle,Request,Convoy, andMemberLeaves. The transition fromIdletoRequestspecifies a reset on clockc1, i.e., the coordinator automaton resetsc1any time it receives a request from the member automaton. The locationRequesthas an invariant c1 ≤ 50, i.e., the coordinator automaton needs to send an answer to the member automaton whilec1is less or equal50. However, the transition fromRequesttoConvoymay only fire ifc1is greater of equal to25 as specified by the time guard. Thus, the coordinator automaton may only start the convoy25 time units after receiving the request.
Timed automata may be nondeterministic. In particular, they may select a value non- deterministically from a given range using selections [BDL06a]. This value may be assigned to a variable. In our example, the coordinator automaton in Figure 2.4a uses a selection at the transition fromIdletoRequest. It selects the value ofifrom an integer range from0 to 1. The value ofiis then assigned to the variablepossiblethat defines whether it is possible to start the convoy.
The state of an NTA is defined by the discrete locations of all timed automata including the values of their variables and their clocks. Since clocks are real-valued and time in- creases continually, timed automata always have an infinite number of states. Therefore, the semantics of an NTA is usually defined by means of symbolic states based on clock zones [Alu99, BY04]. Clock zones store intervals of clock values and enable to repre- sent the state space of an NTA using a finite zone graph. The rules for computing the zone graph define the semantics of NTAs. We refer to paths of the zone graph as traces. Figure 2.5 shows the zone graph of the NTA in Figure 2.4.
request δ request request request decline δ decline δ request ... ... δ start S1
States: Coordinator.Idle, Member.Idle Vars: possible = false
Clocks: c1 = 0, c2 = 0
S2
States: Coordinator.Idle, Member.Idle Vars: possible = false
Clocks: c1 ≥ 0, c2 ≥ 0
S3
States: Coordinator.Request, Member.Wait Vars: possible = false
Clocks: c1 = 0, c2 = 0
S4
States: Coordinator.Request, Member.Wait Vars: possible = true
Clocks: c1 = 0, c2 = 0
S5
States: Coordinator.Request, Member.Wait Vars: possible = false
Clocks: c1 ≤ 50, c2 ≤ 50
S6
States: Coordinator.Idle, Member.Idle Vars: possible = false
Clocks: c1 ≤ 50, c2 ≤ 50
Figure 2.5: Excerpt of a Zone Graph of the NTA in Figure 2.4
The execution of an NTA starts in the initial states of all timed automata (Idlein both automata in Figure 2.4) with all clocks being zero and all variables set to their initial values. The corresponding symbolic stateS1is the initial state of the zone graph in Figure 2.5. Further symbolic states and transitions in the zone graph are inferred by the following rules:
1. Delay
An NTA may delay, i.e., the values of all clocks increase, but neither the active locations nor the values of the integer variables change. The values of the clocks may increase as long as no invariant of an active location restricts them. In the zone graph, these transitions are labeled with δ. As an example, consider the transition fromS1to S2. InS2, all clocks have an unbounded value greater or equal to0 because theIdlelocations do not define invariants.
2. Single Transition
A timed automaton in an NTA may fire a transition that does not use a channel. In this case, the active location and, potentially, the values of the integer variables change. The active locations of all other timed automata remain unchanged. Fur- thermore, firing transitions in an NTA takes no time and, thus, the values of the clocks do not change except for resets that are performed by the transition. In the zone graph, the corresponding transitions are labeled with τ .
3. Synchronized Transitions
Two timed automata in an NTA may synchronize over a channel and synchronously fire one transition each. The synchronization is defined by the CCS parallel com- position operator [Mil82]. As a result, synchronization is realized by hand-shake synchronization, i.e., the two timed automata move to the target locations of their transitions synchronously. For synchronizing transitions, the assignments and re- sets of the transition with the output (!) are executed prior to the assignments and resets of the transition with the input (?). In the zone graph, the corresponding transitions are labeled with the name of the channel. As an example, consider the transition fromS2toS3that corresponds to a synchronization via the channelre- quest. As a consequence, both timed automata change their active locations and, due to the resets, both clocks are set back to0.
Transitions of a timed automaton do not need to fire if they are enabled unless they are forced to. If a location specifies an invariant, the timed automaton is forced to fire before the invariant expires. In addition, timed automata provide urgent channels as well as urgent locations for forcing immediate progress in an NTA. If two transitions that synchronize over an urgent channel are enabled, they need to fire instantly without delay. In urgent locations, no delay is allowed as well. In the timed automaton in Figure 2.4a,
MemberLeavesis an urgent location.
2.2.2 Timed Computation Tree Logic
The timed computation tree logic (TCTL, [ACD93]) is a timed temporal logic for real- time systems. It enables to specify formal safety and liveness properties [Lam77] for a given real-time behavior model as, e.g., an NTA. "A safety property is one which states that something will not happen" [Lam77], e.g., that it may never happen that one RailCab assumes to be a member of a convoy after the coordinator has declined the request. "A liveness property is one which states that something must happen" [Lam77], e.g., that a RailCab always answers to a proposal on building a convoy. For specifying timing properties, TCTL extends the computation tree logic (CTL, [CES86, HR04]) that was developed for finite-state models by quantitative timing constraints. While CTL may only specify that some condition will be true at some point in the future, TCTL may define a quantitative time bound by defining, for example, that the condition must be fulfilled within 5 ms.
TCTL uses a textual syntax. We may define the syntax of a TCTL formula φ inductively via a Backus Naur form
φ::=true|false| p |¬φ | φ1∨ φ2| φ1∧ φ2| φ1→ φ2|AG∼cφ|EG∼cφ|
AF∼cφ|EF∼cφ|A(φ1U∼cφ2) |E(φ1U∼cφ2)
where p is an element of a set AP of atomic formulas, c∈N, and ∼ represents one of the binary relations <,≤, =, ≥, > (cf. [HR04, ACD93]).
The set AP of atomic propositions refers to facts of an NTA that may be evaluated to true or false for any (symbolic) state of the NTA. Considering the NTA shown in Figure 2.4, we use the atomic propositionCoordinator.Requestto express the fact that the state
Requestof the coordinator automaton is active.
The temporal connectivesAG,EG,AF,EF,AU, andEUdefine which atomic propositions need to hold in the future. As its name indicates, TCTL is a branching time logic where formulas are evaluated based on a computation tree. That means, TCTL acknowledges the fact that computations of an NTA may branch. Therefore, the temporal connectives always consist of a path quantifier (AorE) and a temporal operator (one ofG,F,U). Using the path quantifiers, the developer may express that a formula shall hold either for all paths of a computation tree (A) or for at least one path (E). For an NTA, the computation tree is given by its zone graph where all loops are unrolled. The temporal operatorGdefines that the subformula φ must hold for any (symbolic) state of a given path. The temporal operatorFdefines that φ needs to eventually hold for a (symbolic) state in the future. The binary temporal operatorUdefines that φ1needs to hold for any (symbolic) state on a path until eventually φ2becomes true.
In TCTL, the temporal connectives may be restricted with a time bound∼ c. Based on the NTA in Figure 2.4, we may specify, for example, the following formula:
ϕ1 = AG(Coordinator.Request → AF≤50 (Member.Idle or Member.Convoy)))
It specifies that on all execution paths it globally holds that whenever the coordinator au- tomaton is in stateRequest, then on all execution paths the member automaton reaches either theIdlestate or theConvoystate within50 time units. In the above formula, we omitted the time bound≥ 0 ofAGin the concrete syntax because it does not restrict the temporal connective. In this case, the temporal connectives of TCTL become semanti- cally equivalent to the temporal connectives of CTL [ACD93]. Thus, any TCTL formula that only uses the time bound≥ 0 is a valid CTL formula.
In accordance to UPPAAL [BDL04], we use a dedicated atomic propositiondeadlock
that refers to a deadlock state. A deadlock state is a state that does not have any suc- cessors. Using this atomic proposition, we may express that an NTA is free of deadlocks:
ϕ2 = AG ¬deadlock
In addition to the regular temporal connectives of TCTL introduced above, we use the weak-until connective (AWandEW) as part of our example in Chapter 5. Weak-until is a variation of the until connectivesAUandEU. In contrast to until, weak-until does not require that ψ holds eventually, i.e., φ may hold globally. A weak-until, however, may be expressed in terms of the regular temporal connectives of TCTL [BK08, p. 327].
An alternative for specifying safety and liveness properties is given by linear-time tem-
poral logic (LTL, [Pnu77, HR04]). LTL uses a linear time model based on paths that do
not consider branching. Therefore, the temporal connectives of LTL only use a temporal operator but no path quantifier. We discuss preservation of LTL formulas for our refine- ment check, but do not use LTL for specifying safety and liveness properties as part of this thesis because timed variants of LTL like the metric temporal logic (MTL, [Koy90]) are not decidable for the dense time model used by NTAs presented above [AH92] and, thus, no model checkers exist.
2.2.3 Model Checking Procedure
A timed model checking procedure decides whether a given timed automata or NTA ful- fills a given TCTL property [HNSY94, BDM+98, BY04]. Therefore, the model check- ing procedure computes a zone graph for the timed automaton or the NTA. Then, it successively labels the resulting states with the atomic propositions and the subformulas that hold for a given state. The timed automaton or the NTA fulfills the TCTL property if and only if the formula is true for the initial state of the zone graph. If the TCTL property is not fulfilled, the model checker returns a counterexample. A counterexample is a trace of the zone graph that caused that the TCTL property is not fulfilled. In the course of this thesis, we use the model checker UPPAAL [LPY95, BDL+06b] for verifying TCTL properties for NTAs.