Timed Patterns: TCOZ to Timed Automata

. Theintegratedlogic-basedmodelinglanguage,TimedCommunicating Object Z (TCOZ), is well suited for presenting complete and coherent requirement models for complex real-time systems. However, the challenge is how to verify the TCOZ models with tool support, especially for analyzing timing properties. Specialized graph-based modeling technique, Timed Automata (TA), has powerful mechanisms for designing real-time models using multiple clocks and has well developed automatic tool support. One weakness of TA is the lack of high level composable graphical patterns to support systematic designs for complex systems. The investigation of possible links between TCOZ and TA may beneﬁt both techniques. For TCOZ, TA’s tool support can be reused to check timing properties. For TA, a set of composable graphical patterns can be deﬁned based on the semantics of the TCOZ constructs, so that those patterns can be re-used in a generic way. This paper ﬁrstly deﬁnes the composable TA graphical patterns, and then presents sound transformation rules and a tool for projecting TCOZ speciﬁcations into TA. A case study of a railroad crossing system is demonstrated.


Introduction
The specification of complex real-time systems requires powerful mechanisms for modeling state, concurrency and real-time behavior.Integrated formal methods (IFM) are well suited for presenting complete and coherent requirement models for complex systems.An important research agenda in IFM is the combination of Z/Object-Z [6] with CSP/TCSP [13] such as Timed Communicating Object Z (TCOZ) [9], Circus [16] and Object-Z + CSP [14].However, the challenge is how to analyze and verify these models with tool support.We believe one effective approach is to project the integrated requirement models into multiple domains so that existing specialized tools in these corresponding domains can be utilized to perform the checking and analyzing tasks.
TCOZ is an integrated formal specification language which builds on the strengths of the Object-Z and TCSP notations for modeling both the state, process and timing aspects of complex systems.Rather than to develop a single tool support for TCOZ from scratch, we believe a better approach is to reuse existing tools.The specialized graph-based modeling technique, Timed Automata (TA) [1], is powerful in designing real-time models with multiple clocks and has well developed automatic tool support i.e., KRONOS [4] and UPPAAL [2].However, one weakness of TA is the lack of high level composable graphical patterns to support systematic designs for complex real-time systems.The investigation of possible links between TCOZ and TA may be beneficial to both techniques.For TCOZ, TA's tool support can be reused to check real-time constraints.For TA, a set of composable graphical patterns can be defined based on the semantics of the TCOZ constructs so that those patterns can be used as a generic framework for developing complex TA design models.
This paper is organized as follows.Section 2 introduces TCOZ and Timed Automata.Section 3 presents a set of composable TA patterns with their formal definitions (specified in Z).Section 4 presents the transformation rules with their correctness proof and a Java tool for projecting TCOZ (in XML format) to TA (also in XML of UPPAAL).Section 5 conducts a case study of a railroad crossing system.The last section gives the conclusion.

TCOZ
TCOZ is essentially a blending of Object-Z with TCSP, for the most part preserving them as proper sub-languages of the blended notation.The essence of this blending is the identification of Object-Z operation specification schemas with terminating CSP [12] processes.Thus operation schemas and CSP processes occupy the same syntactic and semantic category; operation schema expressions can appear wherever processes appear in CSP and CSP process definitions can appear wherever operation definitions appear in Object-Z.In this section we briefly consider various aspects of TCOZ.A detailed introduction to TCOZ and its TCSP and Object-Z features may be found elsewhere [9].The formal semantics of TCOZ (presented in Z) is also documented [10].

Timing and Channels:
In TCOZ, all timing information is represented as real valued measurements.TCOZ adopts all TCSP timing operators, for instance, timeout and wait.In order to describe the timing requirements of operations and sequences of operations, a deadline command has been introduced.If OP is an operation specification (defined through any combination of CSP process primitives and Object-Z operation schemas) then OP • DEADLINE t describes the process which has the same effect as OP, but is constrained to terminate no later than t (relative time).If it cannot terminate by time t, it deadlocks.The WAITUNTIL operator is a dual to the deadline operator.The process OP • WAITUNTIL t performs OP, but will not terminate until at least time t.In this paper, when the term TCOZ timing constructs is mentioned, it means TCSP constructs with extensions, i.e., DEADLINE and WAITUNTIL .
CSP channels are given an independent, first class role in TCOZ.In order to support the role of CSP channels, the state schema convention is extended to allow the declaration of communication channels.Contrary to the conventions adopted for internal state attributes, channels are viewed as shared (global) rather than as encapsulated entities.This is an essential consequence of their role as communication interfaces between objects.The introduction of channels to TCOZ reduces the need to reference other classes in class definitions, thereby enhancing the modularity of system specifications.
Active Objects and Semantics: Active objects have their own thread of control, while passive objects are controlled by other objects in a system.In TCOZ, an identifier MAIN (non-terminating process) is used to determine the behavior of active objects of a given class.The MAIN operation is optional in a class definition.It only appears in a class definition when the objects of that class are active objects.Classes for defining passive objects will not have the MAIN definition, but may contain CSP process constructors.If ob 1 and ob 2 are active objects of the class C, then the independent parallel composition behavior of the two objects can be represented as ob 1 ||| ob 2 , which means The details of the blended state/event process model forms the basis for the TCOZ denotational semantics [10].In brief, the semantic approach identifies the notions of operation and process by providing a process interpretation of the Z operation schema construct.Operation schemas are modeled by the collection of those sequences of update events that achieve the state change described by the schema.This means that there is no semantic difference between a Z operation schema and a CSP process.It therefore makes sense to also identify their syntactic classes.
A Railroad Crossing Gate Example: The use of TCOZ is illustrated by a railroad crossing gate class as following (later a case study on this system will be conducted).The essential behaviors of this railroad crossing gate are to open and close itself according to its external commands (events) up and down.A free type GateS is used to capture the status of a gate: The interface of the gate class is defined through channels up and down.The DEADLINE and WAITUNTIL expressions are used here to capture its timing properties, which constrain that the gate takes less than 1 time unit to come down and between 1 and 2 time units to come up.

Timed Automata
Timed Automata [1,3] are finite state machines with clocks.It was introduced as a formal notation to model the behavior of real-time systems.Its definition provides a general way to annotate state-transition graphs with timing constraints using finitely many real-valued clock variables.The set of clock constraints Φ(X) is defined by the following grammar: A timed automaton A is a tuple (S, S 0 , Σ, X, I, E), where S is a finite set of states; S 0 is a set of initial states and a subset of S; Σ is a set of actions/events; X is a finite set of clocks; I is a mapping that labels each location s in S with some clock constraint in Φ(X); E, a subset of S × S × Σ × 2 X × Φ(X), is the set of switches.A switch s, s , a, λ, δ represents a transition from state s to state s on input symbol a.The set λ gives the clocks to be reset with this transition, and δ is a clock constraint over X that specifies when the switch is enabled.For example, the railroad crossing gate can be designed in Figure 1.The gate is open in state Up and closed in state Down.It communicates with its controller through the events up and down.The states ToUp and ToDown denote the opening and the closing of the gate.The gate responds to the event down by closing within 1 time unit, and responds to the event up within 1 to 2 time units.UPPAAL UPPAAL [2] is a tool for modeling, simulation and verification of realtime systems.It consists of three main parts: a system editor, a simulator and a model checker.The system editor provides a graphical interface of the tool, to allow easier maintenance.Its output is an XML representation of time automatons.The simulator is a validation tool which enables examination of possible dynamic executions of a system during early design (or modeling) stages and thus provides an inexpensive mean of fault detection prior to verification by the model checker which covers the exhaustive dynamic behavior of the system.The model checker is to check invariant and bounded liveness properties by exploring the symbolic state space of a system.UPPAAL is appropriate for systems that can be modeled as a collection of non-deterministic processes with finite control structure and real-valued clocks, communicating through channels or shared variables.Typical application areas include real-time controllers and communication protocols in particular, those where timing aspects are critical.

Composable TA Patterns
High level real-time system requirements often need to state the system timing constraints in terms of deadline, timeout, waituntil and etc which can be regarded as common timing constraint patterns.For example, "task A must complete within t time period" is a typical one (deadline).TCOZ is a good candidate for specifying the requirements of complex real-time systems because it has the composable language constructs that directly capture those common timing patterns.On the other hand, if TA is considered to be used to capture real-time requirements, then one often need to manually cast those timing patterns into a set of clock variables with carefully calculated clock constraints, which is a process that is very much towards design rather than specification.One interesting question is the following: Can we build a set of TA patterns that correspond to the TCOZ timing constructs?If such a set of TA patterns can be formulated, then not only the transformation from TCOZ to TA can be readily achieved (one objective of this paper), but also TA can sysmatically capture high level requirements by utilizing those composable TA patterns.
Since the current semantics of TCOZ [10] is specified in Z, we define a set of composable TA patterns also in the same meta notation Z.First of all, we give the definition of TA in Z as follows.
[T, State, Event, Clock] There are four basic types, i.e., T, State, Event, and Clock, in which T is the set of positive real numbers; Φ defines the types of clock constraints, in which a true type is added to represent the empty clock constraints; Label models transition conditions, in which P Event is a set of enabling events, and P Clock gives a set of clocks to be reset, and Φ specifies clock constraints.S TA defines a timed automaton, in which i and e represent its initial states and terminal states respectively; I defines local clock invariants on states; and T models transitions.Some TA patterns together with their formal definitions in Z are presented in Figure 2 -Figure 5, the rest can be found in the technical report [5].In these graphical TA patterns, an automaton A is abstracted as a triangle, the left vertex of this triangle or a circle attached to the left vertex represents the initial state of A, and the right edge represents the terminal state of A. For example, Figure 2 demonstrates how two sequential timed automatons A 1 , A 2 can be composed together.By linking the terminal state of A 1 with the initial state of A 2 , the resultant automaton passes control from A 1 to A 2 when A 1 goes to its terminal state.Figure 3 shows one of the common timing constraint patternsdeadline.There is a single clock x.When the system switches to the automaton A, the clock x gets reset to 0. The local invariant x <= t covers each state of the timed automaton A and specifies the requirement that a switch must occur before t time unit for every state of A. Thus the timing constraint expressed by this automaton is that A should terminate no later than t time units.These timed composable patterns can be seen as a reusable high level library that may facilitate a systematic engineering process when TA is used to design the timed systems.Furthermore, these patterns provide an interchange media for transforming TCOZ specifications into TA designs.

Composing TA Patterns
New patterns can be composed from the existing ones.For example, given a specification "Task A is repeated every t 0 time units provided that A is guaranteed to terminate According to the definition of deadline, waituntil and recursion patterns, the resultant automaton can be derived as follows:

Transformation Rules, Correctness & Tool
In this section, we will define a set of rules for mapping TCOZ to Timed Automata and provide the correctness proof for this transformation.A Java tool to automate the transformation process is implemented and illustrated.

Mapping TCOZ Processes into TA Patterns
Since the timed composable patterns are defined according to TCOZ process constructs, the transformation rules are straightforward: Definition 1.We define the mapping function A from TCOZ processes to TA as follows. -

then A(P) = recursion(A(P(N)), N) -If P = P1; P2, then A(P) = seqcom(A(P1), A(P2)) -If P = P1 P2, then A(P) = intchoice(A(P1), A(P2)) -If P = P1 P P2, then A(P) = extchoice(A(P1), A(P2)) -If P = P1 |[X]| P2, then A(P) = A(P1) A(P2)
In these mapping rules, channels, events and guards in a TCOZ model are viewed as triggers which cause the state transitions.They match the definition of actions and timed constraints in Timed Automata, thus, they are directly projected as transition conditions.Note that UPPAAL also adopts channels as its synchronization mechanism for the interaction between automatons, which is equivalent to the approach taken in TCOZ.Clock variables will be generated in the target automaton to guard its transition if the process of TCOZ to be translated has any timing constraints such as the DEADLINE.For example, the translation rule on the DEADLINE primitive, P 0 • DEADLINE t describes the process which has the same effect as P 0 , but is constrained to terminate no later than t.
The above rules apply to all the TCOZ time primitives and its basic composition of events, guards and processes, through which all the important dynamic information with time constraints in TCOZ specification can be completely translated into timed automata.The following provides the transformation rules for TCOZ classes/objects: -In UPPAAL, every object is represented by an automaton.To fully represent behaviors of all the instances of a class, every instance (object) of a TCOZ class is projected as a timed automaton.-The INIT schema in TCOZ class is used to appoint one of those identified states to be an initial state.It will not be projected as a new state because it does not trigger any transition.-Each operation schema in a TCOZ class is projected as an atomic state in its associated automaton instead of a triangle.

Correctness
This subsection is devoted to the soundness proofs for our mapping rules from TCOZ processes to structuralized Timed Automata.We shall prove that any source process in TCOZ and its corresponding target Timed Automaton preserve the same semantics under a bisimulation equivalence relation.The operational semantics for TCOZ processes is captured by the labelled transition system (LTS) where C = P × T is the set of configurations.A configuration c = P, t comprising process P and time t denotes a state in the transition system.Σ τ is the set of possible communication events including the silent event τ .While −→1⊆ (C × (Σ τ ∪ T) × C) is the set of transitions.The operational rules are given in our technical report [5].
In order to derive observable behaviors of TCOZ processes, we define a new abstract transition system as follows: Note that the set of configurations remains the same as that in TS 1 TCOZ , but the transition relation abstracts away from internal actions.That is, for any states c, c , where the relation Now we construct an abstract transition system for our target formalism, Timed Automata.A "normal" transition system associated with timed automata ( [1,3]) can be Notice that S = S × V denotes all possible states of the transition system.Each state is composed of a state of the timed automaton and a clock valuation (interpretation).The initial state s0 = i, v0 comprises the initial state i and a zero valuation v0.While the set −→2 ⊆ S × (Σ τ ∪ T) × S comprises two kinds of transitions: a time passing move or an action move (Please refer to [5] for more details).
Based on TS 1 TA , a new abstract transition system is defined as follows.
The only difference from TS 1 TA lies in the transition relation =⇒2⊆ S × (Σ ∪ T) × S, which abstracts away from all internal (τ ) actions.That is, for states s, s , Now we define a bisimular relation between TS 2 TCOZ and TS 2 TA as below:

Definition 2 (Bisimulation). The relation ≈ ⊆ C × S between states of TS 2
TCOZ and states of TS 2  TA is defined as follows, for any c ∈ C and s ∈ S, c ≈ s if and only if the following conditions hold: (1) c The following theorem shows that our mapping rules preserve the bisimulation relation between the source and target transition systems.Since the two transition systems employ the same set of observable actions (events), the theorem thus demonstrates that each source TCOZ process and its corresponding target timed automaton are semantically equivalent under the bisimulation relation.

Theorem 1 (Correctness).
For any TCOZ process P and its corresponding timed automaton A(P), P, t ≈ i, v 0 for some t, where i is the initial state of A(P), v 0 is the zero valuation.
Proof By structural induction on process P.
-P = SKIP, or P = STOP.The proof is trivial.
-P = WAIT t 0 .We know A(P) = wait(t 0 ).We show the condition (1) holds in Definition 2. The condition (2) can be demonstrated similarly.The process P can perform a time passing move (δ).The automaton wait(t 0 ) can also advance a corresponding δ-step.

Implementation
The translation process can be automated by employing XML/XSL technology.In our previous work [15], the syntax of Z family languages, i.e., Z/Object-Z/TCOZ, has been defined using XML Schema and supported by the ZML tool.As the UPPAAL tool can read an XML representation of Timed Automata, the automatic projection of the TCOZ model (in ZML) to TA model (in UPPAAL XML) can be developed as a tool in Java.
The tool takes in a TCOZ specification represented in XML, and outputs an XML representation of a Timed Automata specification which has its own defined style file DTD by UPPAAL.The transformation is achieved firstly by implementing a ZML parser, which will take in a ZML specification and build a virtual model of the system in the memory.A TA interface is then built according to the UPPAAL document structure, e.g. each TA document contains multiple templates and each template contains some states, their transitions and transition conditions.A transformation module is built to get information from the ZML parser, apply the right transformation rule and feed the outcome of the transformation to the TA interface.Note that TCOZ process expression can be defined recursively, i.e, a process expression may contain one or more other process expressions, our transformation modules are built to take care of all valid TCOZ specifications and the transformation rules are applied recursively.The outcome of our transformation tool is UPPAAL's XML representation of TA, which is ready to be taken as input for verification and simulation.

Case Study : Railroad Crossing System
In this section, we will use a Railroad Crossing System (RCS) specified in TCOZ as a driving example to illustrate our approach to model-checking TCOZ models of realtime systems.The concept of the Railroad Crossing Problem was primarily evolved by Heitmeyer [7] and used as a case study in many formal systems.It is a system which operates a gate at a railroad crossing safely.Based on the above features, we define some assumptions and constraints as follows: 1.The train sends a signal to the controller at least 3 time units before it enters the crossing, stays there no more than 2 time units and sends another signal to the controller upon exiting the crossing.2. The controller commands the gate to lower exactly 1 time unit after it has received the approaching signal from the train and commands the gate to rise again no more than 1 time unit after receiving the exiting signal.3. The gate takes less than 1 time unit to come down and between 1 and 2 time units to come up.

TCOZ Model of RCS
According to the requirement description, an RCS consists of three components: a central controller, a train, and a gate to control the traffic.The basic types for the status of the train and controller are defined as follows: The TCOZ specification of Gate class has been presented in Section 2, the following provides the formal specification of Train and Controller class.
Train: The basic behavior of the train component is to communicate with controller with its passing information.
The attribute status keeps the records of the train's passing information in the system.When the train sends an in signal, the status of the controller changes from TrOut to TrIn.When the train has passed the crossing and sent an out signal to the controller, the status of the controller changes from TrIn to TrOut.The main processes of the controller are receiving the train passing information and manipulating the gate operations at the same time.If the gate is open then instructions on closing the gate will be sent to the Gate.On the other hand, when the train has passed the gate, the controller will open the gate.
RCS Configuration: After specifying individual components, the next step is to compose them into a whole system.The overall system is a composition of all the communicating components.Two essential properties of RCS are: first, the gate is never closed at a stretch for more than a stipulated time range (suppose 10 time units); second, the gate should be down whenever a train is crossing.These properties can be formally expressed as: RCSystem • (g.status = ToDn → ♦ ≤10 g.status = Up) RCSystem • t.status = In ⇒ g.status = Down

Translation
In this section, we show how the given translation rules can be applied to map TCOZ specification into Timed automatons.First of all, for the whole RCS system, three automatons can be identified in the Timed Automata model, i.e., gate, train and controller.
We use the gate class as an example to show the identification of the states, transitions, guards and synchronization mentioned above.According to the translation rules for TCOZ classes/objects, four states can be identified through the static view of Gate class, it has four operation schema, each one is mapped into a state, namely, Up, ToDown, Down, and ToUp as shown in Figure 1, among which Up is the initial state as indicated by the INIT schema in the Gate class.Synchronization and clock conditions on the transitions are constructed by transforming the Open and Close process of Gate class according to the translation rules on DEADLINE and WAITUNTIL primitives.A clock is generated to guard the atomic process Lower to be finished no later than 1 time unit, then it is reused to guard Raise and Up process to meet their timing constraints by resetting its value to 0. The initial and terminal states generated for every non-atomic process due to those translation rules, if they are linked by a transition with a τ event, are incorporated into one state to simplified the resultant automaton.
This gate automaton can be automatically generated by our translation tool and visualized in UPPAAL as "process gate" in Figure 7.In the same way, we can get the train and controller automatons as "process train" and "process controller".

Model-checking RCS
Now we can use the UPPAAL tool to simulate the system as well as to model-check some invariants and real-time properties.In UPPAAL correctness criteria can be specified as formulas of the timed temporal logic TCTL [8], for which UPPAAL implements model-checking algorithms.
From a safety critical perspective, the key point of the RCS is to provide guaranteed safety and efficient services.These properties can be formally interpreted from our model as: safety properties -The properties state that whenever the train is in, the gate is down.It can be translated into the TCTL formula in UPPAAL as follows: A[] train.s2imply gate.s102efficient service properties -the gate is never closed at a stretch for more than 10 time units.To verify this property, we add a clock x to record the time the gate takes to reopen itself: gate.s101 --> (gate.s100and gate.x<=10) UPPAAL verified that these properties actually hold for this given model.

Conclusion
TCOZ and TA lie at each end of the spectrum of formal modeling techniques.TCOZ is good at structurally specifying high level requirements for complex systems, while TA is good at designing timed models in simple clock constraints but with highly automatic tools support.The investigation on the strengths and links between those two modeling techniques leads us to an interesting research result, i.e., timed composable patterns (reminiscence of 'design patterns' in object-oriented modeling).In this paper, these patterns are formally defined in Z and the process algebra-like compositional nature are preserved in the graphical representations.These timed composable patterns not only provide a proficient interchange media for transforming TCOZ specifications into TA designs but also provide a generic reusable framework for designing real-time systems in TA alone.
One possible future work would be to encode those timed patterns as icons in the model checker tool, such as UPPAAL, so that the complex timed models can be built systematically in UPPAAL.
Since TCOZ is a superset of TCSP, one consequence of this work is that a semantic link and a practical translation tool from TCSP to TA has been achieved so that TA tools i.e.UPPAAL can also be used to check TCSP timing properties.In this context, this work complements the recent pure theoretical investigation [11] on the expressiveness of TCSP and closed timed automata.
Trainin = in → (Approach • WAITUNTIL 3; Pass) • DEADLINE 5 Trainout = out → Exit MAIN = µ T • Trainin; Trainout; TCentral Controller: The central controller is the crucial part of the system, actively communicating with the train, light and gate.The Controller class is modeled as follows:Controller status : ControllerS up, down, in, out :

RCSystemt:
Train; g : Gate; c : Controller MAIN = (t in,out c up,down g)