Automatic Translation of tock-CSP into Timed Automata
AAutomatic Translation of tock-CSP intoTimed Automata
Abdulrazaq Abba [0000 − − − , Ana Cavalcanti, and Jeremy Jacob University of York, UK
Abstract.
The process algebra tock-CSP provides textual notationsfor modelling discrete-time behaviours, with the support of various toolsfor verification. Similarly, automatic verification of Timed Automata(TA) is supported by the real-time verification toolbox
Uppaal . TA and tock-CSP differ in both modelling and verification approaches. For in-stance, liveness requirements are difficult to specify with the constructsof tock-CSP , but they are easy to verify in
Uppaal . In this work, wetranslate tock-CSP into TA to take advantage of
Uppaal . We have de-veloped a translation technique and tool; our work uses rules for translat-ing tock-CSP into a network of small TA, which address the complexityof capturing the compositionality of tock-CSP . For validation, we usean experimental approach based on finite approximations to trace sets.We plan to use mathematical proof to establish the correctness of therules that will cover an infinite set of traces.
Keywords:
Translation · tock-CSP · Timed Automata
Communicating Sequential Processes (CSP) is an established process algebrathat provides a formal notation for both modelling and verification of concurrentsystems [18, 32, 34]. Use of CSP for verification has been supported by severaltools including powerful model-checkers [14, 32, 35].Interest in using CSP has motivated the introduction of support to model discrete time; tock-CSP provides an additional event tock to record the progressof time. This enables using CSP for modelling time in a format suitable for formalverification. The notation of tock-CSP retains that of CSP, thus, automaticverification is supported by existing tools. As a result, tock-CSP has been usedin the verification of real-time systems such as security protocols [13] and railwayssystems [20]. Recently, tock-CSP has been used for capturing the semantics ofRoboChart, a domain-specific language for modelling robotics system [27].In this work, we add a technique for translating tock-CSP into TA thatenables using
Uppaal [4] in verifying tock-CSP models.
Uppaal is a tool-suite that allows the modelling of continuous time systems using a collection ofTAs and verifying the systems against temporal logic formulae.Both temporal logic and refinement are powerful approaches for model check-ing [25]. The refinement approach models both the system and its specifications a r X i v : . [ c s . L O ] A ug Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob with the same notation [32,34]. Temporal logic enables asking whether a systemis a model for a logical formula of the specification ( system | = f ormula ) [8].Previously, Lowe has investigated the relationship between the refinementapproach (in CSP) and the temporal logic approach [25]. The result shows that,in expressing temporal logic checks using refinement, it is necessary to use theinfinite refusal testing model of CSP. The work highlights that capturing the ex-pressive power of temporal logic in specifying the availability of an event (livenessspecification) is not possible. Also, due to the difficulty of capturing refusal test-ing, automatic support becomes problematic. A previous old version of FDRsupports refusal testing, but not its recent efficient version [14].Lowe’s work [25] proves that simple refinement checks cannot cope with threeoperators: eventually ( (cid:5) p : p will hold in some subsequent state), until ( p U q : p holds in every state until q hold) and negation ( ¬ ( (cid:5) p ): p will never hold in thesubsequent states). All these three operators express behaviour that is capturedby infinite traces. Our translation work, presented here will facilitate using theresources of temporal logic (and Uppaal for automatic support) in checkingspecifications that are difficult to specify using tock-CSP models.
Example 1.
An Automatic Door System (ADS) opens a door, and after at leastone time unit, closes the door in synchronisation with a lighting controller, whichturns off the light. In tock-CSP , its description is as follows. ADS = Controller [|{close}|] Lighting Controller = open -> tock -> close -> Controller Lighting = close -> offLight -> Lighting
ADS has two components,
Controller and
Lighting , which synchronise onthe event close ; this enables
Lighting to turn off the light after closing thedoor. For instance, using tock-CSP , there is no straightforward way of checkingif the system will eventually turn off the light when the environment is ready.However, temporal logic provides a direct construct for specifying these kinds ofrequirements. For instance, in
Uppaal , the requirement is specified as follow. – A<> offLight - -
The system eventually turns off the light, if the environment is ready.
Uppaal uses a query language, a subset of Timed Computational Tree Logic(TCTL), which is based on the notions of path and state [4]. A path formuladescribes a trace or path, whereas a state formula describes either a location orlogical expression. There are five different forms of path formulae that are cat-egorised into, liveness, reachability and safety. Liveness is in the form of either
A<>q (q is eventually satisfied) or p --> q (a state satisfying p leads to statesatisfying q) . In the literature, (cid:5) or F are the commonly used symbols for speci-fying liveness. The reachability formula is in the form of E<>q (a state satisfying q is reachable from the initial state) . Safety is in the form of either A[]q (q holdsin all reachable states) or E[]q (a path where q holds in all states on the path) .In verifying the correctness of the translation technique, we follow a series ofsteps. First, we construct a systematic list of interesting tock-CSP processes, utomatic Translation of tock-CSP into Timed Automata 3 which pair all the constructs of tock-CSP within the scope of this translationwork. Second, we use the developed translation technique and its tool to translatethe formulated processes into TA for
Uppaal . Third, we use another tool wedeveloped in generating and comparing finite traces of the input tock-CSP models and the traces of the translated TA models, with the support of bothFDR and
Uppaal , respectively. This provides evidence that the translated TAcaptures the behaviour of the input tock-CSP models.To describe the translation technique, we use Haskell [19], a functional pro-gramming language. We use it for expressing, implementing and evaluating thetranslation technique. The expressive power of Haskell helps us in providing aprecise description of the translation technique as a list of translation rules.The structure of the paper is as follows. Next, Section 2 provides the back-grounds essential for understanding the translation technique. In Section 3, wegive an overview of the translation technique. In Section 4, we discuss an eval-uation of the translation technique. In Section 5, we highlight relevant relatedworks, and also present a brief comparison with this work. Finally, in Section 6,we highlight future work and also provide a conclusion for the paper.
This section discusses the required background for understanding the translationwork. We begin by discussing the notations of tock-CSP and then discuss thetarget of the translation work, a network of suitable TA for
Uppaal . tock-CSP is an extension of CSP, which provides notations for modelling pro-cesses and their interactions. In CSP , there are constructs for basic processessuch as
SKIP and
STOP . SKIP expresses a successful termination while
STOP expresses a deadlock behaviour. Also, there are operators such as prefix (->) ,which describes an event that leads up to a process. For example, the process move->SKIP describes a system that moves and then terminates.Furthermore, there are additional binary operators such as sequential com-position (;), which combines two processes serially. For instance,
P3 = P1;P2 behaves as process P1 , and then after successful termination of P1 , P3 behavesas P2 . There are other binary operators for composing processes in differentways, such as concurrency, choice and interrupt. Also, CSP provides a specialevent tau ( τ ) that represents invisible actions that are internal to a system,specifically for internal communications of a system that are hidden from theoperating environment. The collection of these operators provides a rich set ofconstructs for modelling untimed systems. Comprehensive full details of CSPconstructs, together with examples, are available in these books [32, 34].Consequently, tock-CSP uses a special event tock [32]. Each event tock specifies a single unit of time. For example, a process Pt= move->tock->tock->turn->SKIP
Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob specifies the behaviour of a system that moves , and then after at least two timeunits, turns and then terminates.We provide a BNF for the notation of tock-CSP we consider in developingour translation technique and its supporting tool. Part of the BNF is presented inDefinition 1 in Haskell. The complete BNF is available in an extended report [1].
Definition 1.
Data definition of
CSPproc data CSPproc = STOP | SKIP | Prefix Event CSPproc| Seq CSPproc CSPproc| GenPar CSPproc CSPproc [Event]| Interleave CSPproc CSPproc| ...
For illustration, this part of the BNF shows the constructs for
STOP (Deadlock),SKIP (successful termination),
Prefix (prefixing),
Seq (Sequential composi-tion), and
GenPar (generalised parallel for concurrency) and
Interleave fordescribing processes that run concurrently without synchronisation.
Timed Automata for Uppaal provides graphical notations for modellinghybrid systems. In
Uppaal , systems are modelled as a network of TA withadditional variables. Mathematically, a TA is defined as a tuple (
L, l , C, A, E, I ),where L is a set of locations such that l is the initial location, C is a set of clocks, A is a set of actions, E is a set of edges that connects the locations L , and I isan invariant that is associated with a location l ∈ L . So, an edge E is definedas E ⊆ ( L × A × B ( C ) × C × L ), which describes an edge from location l ∈ L that is triggered by an action a ∈ A , guarded with a guard B ( C ), and associatedclocks C that are reset on following an edge e ∈ E to a location l ∈ L . Lastly, I is a function that assigns an invariant to a location I : L −→ B ( C ) [4, 6].A system is modelled as a network of TAs that communicate over channelsynchronisations or shared variables. A sending channel is decorated with anexclamation mark ( c !) while the corresponding receiving channel is decoratedwith a question mark c ?. To describe behaviour, a TA performs an action c ! tocommunicate with another TA that performs the corresponding co-action c ?.For expressing urgency, there are urgent channels that do not allow delay.Broadcast channels facilitate communication among multiple TAs, in the formof one-to-many communication (one sender with multiple receivers). In addition,there are urgent and committed types of location. An urgent location does notallow time to pass, whereas a committed location is an urgent location that mustparticipate in the next transition before any other transition. A committed loca-tion is useful in expressing atomicity, specifically a compound action that spansmultiple transitions that must be executed as a unit. There are also invariantsfor specifying and enforcing progress [4].Overall, Uppaal provides graphical notations for modelling a system as anetwork of TAs that model both system components that communicate withone another and the explicit operating environment, also described as a TA. For utomatic Translation of tock-CSP into Timed Automata 5 example, the collection of TAs in Figure 1 describes a system and its operat-ing environment, which is explained later in details. For specifications,
Uppaal uses a subset of TCTL [5] for specifying system properties that can be verifiedautomatically [4, 23, 24].
Our translation technique produces a list of small TAs. The occurrence of each tock-CSP event is captured in a small TA with an UPPALL’s action, whichrecords an occurrence of the translated event. The action has the same name asthe translated event. The technique composes these small TAs into a network ofTA, which captures the behaviour of the input tock-CSP model.For example, a translation of the process ADS, from Example 1, producesthe network of small TA in Figure 1. Details of the translated TA are as follows.Starting from the top-left corner, the first TA captures concurrency by startingthe two concurrent automata corresponding to the processes
Controller and
Lighting in two possible orders, either
Controller then
Lighting or viceversa, depending on the choice of the operating environment. Afterwards, italso waits on state s5 for their termination actions in the two possible orders,either Controller then
Lighting or vice versa, depending on the process thatterminates first. Then, the whole system terminates with the action finishID0 .The second, third and fourth TAs capture the translation of the process
Controller . The second TA captures the occurrence of the event open . Thethird TA captures the occurrence of the event tock? (with a question mark)for synchronising with the environment in recording the progress of time. Thefourth TA captures the occurrence of the event close , which synchronises withthe synchronising controller, the fifth TA.The sixth and seventh TA capture the translation of the process
Lighting .The sixth TA captures the translation of close , which also needs to synchronisewith the synchronisation controller (fifth TA). The seventh TA captures the event offLight . Finally, the last TA is an environment TA that has co-actions for allthe translated events. Also, the environment TA serves the purpose of ‘closing’the overall system as required for the model checker. In the environment TA,we use the variable start to construct a guard start == 0 that blocks theenvironment from restarting the system. This concludes the description of thelist of TA for ADS.An alternative to using a list of small TAs is using a single large TA thatcaptures the behaviour of the translated tock-CSP process. The main reason forusing a list of small TAs is coping with the compositional structure of tock-CSP ,which is not available in TA [11]. For instance, it can be argued that a linearprocess constructed with a series of prefix operators can be translated into alinear TA. However, the compositional structure of tock-CSP is not suitablefor this straightforward translation. A network of small TAs provides enoughflexibility for composing TA in various ways to capture the behaviour of theoriginal tock-CSP process, as explained below.
Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob
Fig. 1: A list of networked TA for the translation of the process ADS. utomatic Translation of tock-CSP into Timed Automata 7
In constructing the network of TA, we use additional coordinating actions that link the small TA into a network. The coordinating actions link the smallTA into a network of TA to establish the flow of the translated tock-CSP process. For instance, the channel startIDADS forms a link that connects theenvironment TA (last TA in Figure 1) with the first TA, on performing theaction startIDADS! and its co-action startIDADS? . A precise definition ofthe coordinating actions is provided below in Definition 2.
Definition 2.
A Coordinating Action is an
Uppaal action that does notcorrespond to a tock-CSP event. There are six types of coordinating actionsas follows:
Flow actions coordinate a link between two TAs for capturing theflow of their behaviour;
Terminating actions record termination information,in addition to coordinating a link between two TAs;
Synchronisation actions coordinate a link between a TA that participate in a synchronisation action anda TA for controlling the multi-synchronisation;
External choice actions co-ordinate an external choice, such that choosing one of the TA that is part of theexternal choice blocks the other alternative choices TAs;
Interrupting actions initiate an interrupting transition that enables a TA to interrupt another; and
Exception actions coordinate a link between a TA that raises an exception anda control TA that handles the exception.
The names of each coordinated action are unique for ensuring the correct flowof the translated TA. In our implementation, the name of the flow actions aregenerated in the form startIDx , where x is either a natural number or the nameof the input tock-CSP process. This can be seen in Example 1; startID00_1 is the flow action that connects the first TA with the second TA.Likewise, the names of the remaining coordinating actions follow the samepattern: keywordIDx , where keyword is a designated word for each of the co-ordinating actions; finish for a terminating action, ext for an external choiceaction, intrp for an interrupting action, and excp for an exception action. Sim-ilarly, the name of a synchronising action is in the form eventName___sync :an event name appended with the keyword ___sync to differentiate a synchro-nising action from other actions, especially for analysis.We use termination actions for cases where a TA needs to communicate asuccessful termination for another TA to proceed. For example, in the case ofthe translation of sequential composition P1;P2 where the process P2 beginsonly after successful termination of the process P1 .For each translated tock-CSP specification, we provide an environment TA,like the last TA in Figure 1. The environment TA has corresponding co-actionsfor all the translated events of the input tock-CSP model. Also, the environmentTA has two coordinating actions that link the environment TA with the networkof the translated TA. First, a flow action links the environment with the first TAin the list of the translated TA. This first flow action is the starting action thatactivates the behaviour of the translated TA. Second, a terminating action linksback the final TA to the environment TA, and records a successful terminationof a process. A precise definition of the structure of environment TA is below. Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob
Definition 3.
An Environment TA models an explicit environment for
Uppaal model. The environment TA has one state and transitions for each co-action ofall the events in the input tock-CSP process, in addition to two transitions forthe first starting flow action and the final termination co-action, as well as theaction tock for indicating the progress of time.
In translating multi-synchronisation, we adopt a centralised approach developedin [30] and implemented using Java in [10]. The approach described uses a sepa-rate centralised controller for controlling multi-synchronisation events. Here, weuse a separate TA with
Uppaal broadcast channel to communicate synchronis-ing information among synchronising TA and a control TA.An example can be seen in Figure 1, where we illustrate the strategy intranslating close , which synchronises the two processes
Controller and
Lighting . In Figure 1, the fifth TA captures the translation of close , whichsynchronises the fourth and sixth TA for those processes. The fifth TA is asynchronising TA; and its uses the broadcast channel close___sync to syn-chronise the fourth and sixth TAs.Each synchronising TA has a guard for ensuring that the TA synchroniseswith the required number of TAs. The guard is a logical expression that combinesvariables from all the TAs that synchronise on the synchronisation action. EachTA updates its variable from 0 to 1 to indicate its readiness for the synchroni-sation. For instance in Figure 1, the fifth TA is a synchronising TA that has aguard expression (g_close00_3 + g_close01_2)==2 , which becomes truewhen the fourth and sixth TA update their respective variables: g_close00_3 and g_close01_2 , from 0 to 1. Then the fifth TA notifies the occurrence ofthe action close and broadcasts the synchronising action close___sync! . Adefinition of synchronisation TA is provided in Definition 4.
Definition 4.
A synchronisation TA coordinates a synchronisation actions.Each synchronisation TA has an initial state and a committed state for eachsynchronisation action, such that each committed state is connected to the initialstate with two transitions. The first transition from the initial state has a guardand an action. The guard is enabled when all the processes are ready for thesynchronisation, which also enables the TA to perform the associated actionthat notifies the environment of its occurrence. In the second transition, the TAbroadcasts the synchronisation action to all the processes that synchronise on thesynchronisation action.
In translating external choice, we provide additional transitions that enablesthe behaviour of the chosen process to block the behaviour of the other processes.Initially, in the translated TA, all the initials of the translated processes areavailable such that choosing one of the processes blocks the other alternative.An example of translating external choice is provided in Figure 2 for theprocess Pe = (left->STOP)[](right->STOP)) , which composes two pro-cesses (left->STOP) and (right->STOP) with the operator of externalchoice. Initials are the first visible events of a process.utomatic Translation of tock-CSP into Timed Automata 9
Fig. 2: A list of TA for the translated behaviour of the process
Pe = (right->STOP)[](left->SKIP)
In Figure 2, starting from the top-left, the first TA is a translation of theoperator external choice. The second and third TAs are translations of the LHSprocess left->SKIP . The fourth and fifth TAs are translations of the RHSprocess (right->SKIP) . The first TA has three transitions labelled with flowactions: startIDp0_6? , startID00_1! and startId01_2! . The TA beginswith the first flow action startIDp0_6? , then starts the TAs for both the leftand right process using startID00_1! and startId01_2! .The second TA is a translation the event left . Initially, the TA synchroniseson the flow action startID00_1 and moves to location s2 where the TA has3 possible transitions labelled with the actions: left_exch? , right_exch! and tock? . With the co-action tock? , the TA records the progress of time andremains on the same location s2 . With the co-action right_exch? , the TAperforms an external choice co-action for blocking the TA of the LHS processwhen the environment chooses the right process, and the TA returns to its initiallocation s1 . Lastly, the TA performs the action left_exch! when the environ-ment chooses the LHS process, and the TA progress to location s3 to performthe chosen action left that leads to location s5 for performing the flow action startID00_2 , which activates the third TA for the subsequent process STOP .This describes the behaviour of the LHS process left->STOP .The fourth TA is a translation of right , similar to the previous translationof left in the second TA. The fifth TA is a translation of the process
STOP .The omitted environment TA is similar to the last TA in Figure 1.
Fig. 3: A list of TA for the translated behaviour of the process
Pi = (open->SKIP)/\(fire->close->SKIP)
Similarly, in tock-CSP , a process can be interrupted by another processwhen they are composed with an interrupting operator ( /\ ). For capturing in-terrupting behaviour in TA, we provide additional transitions for expressing aninterrupting action, which enables a TA to interrupt another one. The translationof an interrupting process resembles the translation of an external choice.An example of translating interrupt is provided in Figure 3, for the pro-cess Pi = (open->SKIP)/\(fire->close->SKIP) . For the process Pi ,the RHS process (fire -> close -> SKIP) can interrupt the behaviour of (open->SKIP) at any stable state. In the translated behaviour of the LHSprocess, we provide additional interrupting actions ( fire_intrpt ) that enablethe translated behaviour of the RHS process to interrupt the LHS process. Theinterrupting actions are provided only for the initials of the RHS process ( fire ). utomatic Translation of tock-CSP into Timed Automata 11 In Figure 3, starting from the top-left, the first TA is a translation of theoperator interrupt. The second and third TAs are the translation of the LHSprocess open->SKIP . The fourth, fifth and sixth TAs are translation of the RHSprocess fire->close->SKIP . The environment TA is also omitted because itis similar to the last TA in Figure 1.The first TA starts the TA for both processes using startID00_1! and startID01_2! , respectively. The second TA synchronises on the flow action startID00_1 and moves to location s2 where the TA has 3 possible transitionsfor the actions: tock? , open! and fire_intrpt? . With the co-action tock? ,the TA records the progress of time and remains on the same location s2 . Withthe co-action fire_intrpt? , the TA is interrupted by the RHS, and it returnsto its initial location s1 . With the action open! , the TA progresses to location s5 to perform the flow action startID00_2 , which activates the third TA forthe subsequent process STOP .The third TA synchronises on the flow action startID00_2 and moves tolocation s2 , where it either performs the action tock? to record the progressof time or is interrupted with the co-action fire_intrpt? , and returns to itsinitial location s1 . This completes the behaviour of the process open->SKIP .The fourth TA is a translation of the event fire . The TA begins with syn-chronising on the flow action startID01_2 , which progress by interrupting theLHS process using the interrupting flow action fire_intrpt , then fire , andproceeds to startID01_3 for starting the fifth TA. The fifth TA synchroniseson the flow action and moves to location s2 , where it either performs the action tock? for the progress of time and remains in the same location or performsthe action close , and proceeds to location s5 then performs the flow action startID01_4 for starting the sixth TA for the translation of STOP (deadlock).Also, in tock-CSP , an event can be renamed or hidden from the environ-ment. In translating renaming, our technique uses a list of renamed events; beforetranslating each event, we check if the event is renamed, and then translate theevent appropriately with the corresponding new name. In the like manner, if anevent is part of the hidden events, using a list of hidden events, the techniqueuses a special name itau in place of the hidden event. The event itau has similarmeaning to tau , which represents a hidden event in CSP. We differentiate thetranslated event itau from tau , for the purpose of analysis.We translate the event tock into a corresponding action tock for recordingthe progress of time in the translated TA using a broadcast channel that enablesthe translated TA to synchronise in recording the progress of time. The action tock is broadcast by the environment TA, which causes all the processes tosynchronise and record the progress of time using their corresponding co-actions tock? (with a question mark). In particular, in Figure 1 the last TA that modelsthe environment, has a transition with an action tock that is guarded with theexpression ck ≤
1, so that the action tock happens every 1 time unit, and resetsthe clock ck = 0 to zero on following the transition.Silent transitions enable a TA to take any of the silent transitions. We trans-late non-deterministic choice into silent transitions, such that the translated TA Rule 1.
Translation of STOP transTA STOP processName bid sid _ usedNames = (([(TA idTA [] [] locs [] (Init loc1) trans)]), [] ) where idTA = "taSTOP__" ++ bid ++ show sid -- Definition of locations in the TA -- = Location ID Name Label LocType loc1 = Location "id1" "s0" EmptyLabel None loc2 = Location "id2" "s1" EmptyLabel None locs = [loc1, loc2] -- Definition of transitions in the TA -- = Transition Source Target [Label] [Edge] tran1 = Transition loc1 loc2 [lab1] [] tran2 = Transition loc2 loc2 [lab2] [] intrp = transIntrpt intrptsInits loc1 loc2 trans = [tran1, tran2] ++ intrp -- Labels of the transitions in the TA lab1 = Sync (VariableID (startEvent processName (bid ++ sid)) []) Ques lab2 = Sync (VariableID "tock" []) Ques -- Get the initial events of an interrupting process (_, _, _, _, _, intrptsInits, _, _) = usedNames follow one of the silent transitions non-deterministically. Nevertheless, divergenceis not part of the construct that we consider in this translation work becausedivergence is a sign of bad behaviour. This completes an overview of the strategywe follow in developing the translation technique.An example of the formalisation of the translation rules in Haskell is pro-vided in Rule 1, which describes the translation of the construct STOP . All theremaining rules can be found in [1]. Rule 1 produces an output TA that is de-picted in Figure 4, which has two locations and two transitions as defined inRule 1, Lines 7–9 and Lines 11–13, respectively. In Figure 4, we map the struc-ture of the TA with the names used in the translation rule. The names are loc1, loc2, tran1, tran2, intrpt .A detailed description of Rule 1 is as follows. Each rule considers one con-struct. Line 1 identifies the definition of our translation function transTA for utomatic Translation of tock-CSP into Timed Automata 13
Fig. 4: A structure of an output TA for the translation of STOP from Rule 1.
STOP , and it takes three extra parameters: processName , bid and sid . Thesymbol underscore represents unused arguments.Line 2 defines the output pairs, a list of output TA and a list of synchronisingactions. The second element is empty ([]) in Rule 1 because there is no synchro-nising action in translating the construct STOP . The first element describes theoutput TA, which has 6 parameters. First, idTA is an identifier for the TA,which is defined subsequently in Line 4, as the concatenation of the keyword "taSTOP__" with the 2nd and 3rd arguments of the function transTA , thatis bid and sid respectively. Additionally, still in Line 2, in the definition ofthe output TA, the 2nd, 3rd and 5th parameters are empty for the output TA.While the 4th parameter locs is a list of locations for the output TA, as definedin Lines 7–9. The 6th parameter (Init loc1) specifies loc1 as the initial lo-cation of the output TA. Last parameter trans describes a list of transitionsthat connect the locations of the TA, as defined in line 12–13. Line 14 definesinterrupting transitions that are generated with the function transIntrpt ,that is in the case where a process is composed with an interrupting process.Lines 17–20 define the labels of the transitions. Lastly, Line 23 extracts the ini-tials of an interrupting process from the parameter usedNames , which collectsinformation such as the names of hidden events and renamed events.The behaviour of the output TA begins with the first flow action (definedin Line 17). After that, the TA performs the action tock (line 18), repeatedly,which allows the progress of time, unless there is an interrupt, which causes theTA to follow the interrupting transition, as defined in Line 14.
Example 2.
An example of translating a process
STOP that produces a list ofTA, which contains two TAs as shown in Figure 5. The LHS TA captures thetranslation of the construct
ST OP , in this case there is no interrupting transitionbecause there is no interrupting process. A translation of interrupt has beenprovided separately. The RHS TA is an environment TA that we provide fortranslating each process, as described in Definition 3. In Haskell, the symbol underscore indicates a position of unused arguments. Forconciseness, we use the underscore to omit unused arguments and provide only therequired arguments for each translation rule.4 Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob transTA(STOP) = [ Fig. 5: A list of TA for the translation of the construct STOP ] A sound translation ensures that properties of the source model are preserved inthe targeted translated models. This is determined by comparing the behavioursof the source model and the translated model [3, 21, 26, 28].
In this work, we use traces to compare the behaviour of the input tock-CSP models and the traces of the translated TA models. We have developed an eval-uation tool, which uses the translation tool to translate tock-CSP model intoTA, and then uses both FDR and
Uppaal as black boxes in generating sets offinite traces. The structure of the evaluation tool is shown in Figure 6.In generating traces, like most model checkers, FDR produces only one trace(counterexample) at a time. So, based on the testing technique in [29], we havedeveloped a trace-generation technique that repeatedly invokes FDR for gener-ating traces until we get all the required traces set of the input tock-CSP . Sim-ilarly, based on another testing technique [24], we have developed another trace-generation technique, which uses
Uppaal in generating finite discrete traces ofthe translated TA models.These two trace-generation techniques are components of our trace analysistool, which has two stages of analysing traces. In the first stage, we generatetraces of the input tock-CSP and its corresponding translated TA, using bothFDR and
Uppaal , respectively. Then, we compare the generated traces, and ifthey do not match, we move to the second stage for further analysis. In FDR,the trace-generation technique is capable of generating and detecting traces withdifferent permutations of events. In contrast,
Uppaal is not capable of detecting utomatic Translation of tock-CSP into Timed Automata 15
Fig. 6: Structure of the trace analysis systemtraces with different permutations because
Uppaal uses a logical formula ingenerating traces [4,24]. Thus, we use the power of FDR to complement
Uppaal in generating and comparing traces of tock-CSP and TA.Basically,
Uppaal was developed for checking if a system satisfies a log-ical formula for a requirement specifications, irrespective of the behaviour ofthe system. For example,
Uppaal does not distinguish between the two traces (cid:104) e , e , e (cid:105) and (cid:104) e , e , e (cid:105) , if both of them satisfy the specification formula. Thetwo traces contain the same three actions, but the action e e Uppaal to check if the traces of FDRare acceptable traces of the translated TA.We use this tool in evaluating the translation technique by translating a listof systematically formulated tock-CSP processes that pair the constructs of tock-CSP , The list contains 111 processes that are not more than five states insize. Archives of the processes and their traces are available in a repository [1].In addition, the translation technique has been tested in various larger ex-amples such as an Automated Barrier to a car park [34], a Thermostat ma-chine for monitoring ambient temperature [34], an Automated Teller Machine(ATM) [33], a Bookshop Payment System [34], and a Railway Crossing Sys-tem [32]. An overview of the processes is provided in Table 1.Trace analysis is an approximation to establishing correctness with a finiteset of traces. Proving correctness for the complete set of traces involves usingmathematical proof. This is achieved using structural induction. An account ofour initial effort to produce a proof is provided next.
Here, we illustrate an early part of the proof using a translation of the construct
ST OP , which is one of the base cases of the structural induction.For this proof, consider
TA1 as the left TA of Figure 5; (from Section 2)mathematically TA1 is defined as the following tuple.
Table 1: An overview of the case studies
T A { s , s } , s , { ck } , { startID , tock } , { ( s , startID, ∅ , ∅ , s , ( s , tock, ck ≤ , ck, s } , {} )A path [2, 6] is a sequence of consecutive transitions that begins from the initialstate; may possibly be empty sequence. A trace [2, 6] (or word in the languageof TA) is a sequence of actions in a given path. There is only one infinite path inTA1; the first transition from location s s s s
1, and repeated infinitely. The traceson the path are as follows. traces (cid:48)
T A ( T A
1) = {(cid:104)(cid:105)} ∪ {(cid:104) startID (cid:105) (cid:95) (cid:104) tock (cid:105) n | n ∈ N } (1)The function trace (cid:48) T A ( T A ) describes the traces of TA1 as follows. The first emptysequence happens at the initial state, before the first transition. The action startID00 happens on the first transition. The action tock happens on thesecond transition, which is repeated infinitely for the infinite traces (cid:104) tock n (cid:105) .Another function trace T A ( T A ) is similar to traces (cid:48)
T A ( T A ) but removes allthe coordinating actions (Definition 2) from the traces. traces
T A ( T A
1) = { t \ CoordinatingActions | t ∈ traces (cid:48) T A ( T A } (2)The function trace (cid:48) T A ( T A ) takes a list of TA and returns set of traces withoutthe coordinating actions. In Equation (3), we use the operator \ for removingthe coordinating actions from the set of traces. For instance, after removing thecoordinating actions the traces of TA1 are as follows. traces T A ( T A
1) = {(cid:104) tock (cid:105) n | n ∈ N } (3)For this proof, our goal is establishing that the traces of tock-CSP models arethe same as those of the translated TA models. Here, transTA is the translationfunction we have formalised (See Section 3 ) for translating tock-CSP modelsinto TA models. Thus, we need to establish that, for each valid tock-CSP process P , within the scope of this work, as follows. utomatic Translation of tock-CSP into Timed Automata 17 traces tock − CSP ( P ) = traces T A ( transT A ( P )) (4)In this case, for each translation rule we need to prove that the translated TAcaptures the behaviour of its translated construct from tock-CSP . Thus, start-ing with the first rule for translating the construct of a basic process STOP : traces tock − CSP ( ST OP ) = traces
T A ( transT A ( ST OP )) (5)For the LHS, in tock-CSP [32], the traces of the constant process
STOP are: traces tock − CSP ( ST OP ) = {(cid:104) startID (cid:105) (cid:95) (cid:104) tock (cid:105) n | n ∈ N } (6)For the RHS, Example 2 produces TA1 that captures the translation of construct ST OP , then the traces of TA1 are as follows. traces (cid:48)
T A ( T A
1) = {(cid:104)(cid:105)} ∪ {(cid:104) startID (cid:105) (cid:95) (cid:104) tock (cid:105) n | n ∈ N } (7)After dropping the flow actions, the traces become: traces T A ( T A
1) = {(cid:104) tock n (cid:105) | n ∈ N } (8)Therefore, from Equations (6) and (8), traces tock − CSP ( ST OP ) = traces
T A ( transT A ( ST OP ))This proves that the traces of the translated TA for
ST OP captures its tracescorrectly. We plan to follow the same pattern in completing the proof.
Timed-CSP [34] is another popular extension of CSP that provides additionalnotations for capturing temporal specifications. Unlike tock-CSP , Timed-CSPrecords the progress of time with a series of positive real numbers, which facili-tates reasoning in a format that is suitable for verifying real-time systems.However, the approach of Timed-CSP can not be used to specify strictprogress of time, neither deadline nor urgency. Additionally, traces of Timed-CSP become infinite, which is problematic for automatic analysis and verifica-tion [32]. Besides, there is no tool support for verifying Timed-CSP models.As a result of that, many researchers explore model transformations in sup-porting Timed-CSP with an automated verification tool. Thus, Timed-CSP hasbeen translated into tock-CSP for using FDR in automatic verification [31].Also, Timed-CSP has been translated into
Uppaal . The work was initiated in[11] and then subsequently improved in [15]. Additionally, Timed-CSP has beentranslated into Constraint Logic Programming (CLP) that facilitates reasoningwith the support of the constraint solver CLP(R) [12].
However, there is less attention in applying the same transformation tech-niques in improving tock-CSP . An attempt for transforming TA into tock-CSP was proposed in [22]. Whereas in this work, we consider the opposite direction.Apart from CSP and TA, model transformations have been used for improv-ing various formal modelling notations. For instance, Circus has been trans-lated into
CSP||B to enable using the tool ProB for automatic verification [36].Additionally, B has been translated into TLA+ for automatic validation withTLC [17]. Also, translating TLA+ to B has been investigated for automatedvalidation of TLA+ with ProB [16], such that both B and TLA+ benefit fromthe resources of each other, specifically their supporting tools ProB and TLC,respectively, for automated verification.Model transformation is an established field, which has been used for manydecades in addressing computational problems. The novelty of this translationwork is traced back to early days of model translation works, such as the transla-tion of the timed variants of LOTOS into TA [7, 9]. There is a recent systematicsurvey of model translation, which provides a rich collection of model transfor-mations techniques and their supporting tools [21].
In this work, we have presented a technique for translating tock-CSP into TAfor
Uppaal , which facilitates using temporal logic and automatic support with
Uppaal in verifying tock-CSP models. This translation provides an easier wayof using TCTL in specifying liveness requirements that are difficult to specify andverify in tock-CSP . Also, the result of this work sheds additional insight intothe complex relationship between tock-CSP and TA, as well as the connectionbetween refinement model and temporal logic model.So far, in this work, we have used trace analysis in justifying the correctnessof the translation work. In the future, we are planning to complete the mathe-matical proof for the total correctness of the translation technique. Secondly, weare planning to explore using the translation technique in translating extensivecase studies that can help us in improving the robustness of our translation work.Currently, we translated the event tock into an action that is controlled bya timed clock in
Uppaal . A recommended next step in this work is relatingthe notion of tock to the notion of time in TA and getting rid of tock as anaction. This additional extension will help us in exploring additional interestingfacilities of
Uppaal for verifying temporal specifications.
References
1. A repository for the translation of tock-CSP into Timed Automata for
Uppaal .Available at: https://github.com/ahagmj/Translation tockCSP TA2. Rajeev Alur and David L. Dill. A theory of timed automata.
Theor. Comput. Sci. ,1994.utomatic Translation of tock-CSP into Timed Automata 193. RJR Back. On correct refinement of programs.
Journal of Computer and SystemSciences , 23(1):49–68, 1981.4. Gerd Behrmann, Alexandre David, Kim G Larsen, John H˚akansson, Paul Petter-son, Yi Wang, and Martijn Hendriks. UPPAAL 4.0.
Third Int. Conf. Quant. Eval.Syst. QEST 2006 , pages 125–126, 2006.5. Patricia Bouyer. Model-checking timed temporal logics.
Electronic Notes in The-oretical Computer Science , 231:323–341, 2009.6. Patricia Bouyer. An introduction to timed automata.
Actes ´Ecole d´et´e ETR05 ,pages 79–94, 2011.7. Howard Bowman, Giorgio Faconti, J-P Katoen, Diego Latella, and Mieke Massink.Automatic verification of a lip-synchronisation protocol using
Uppaal . FormalAspects of Computing , 10(5-6):550–575, 1998.8. Edmund M. Clarke, E Allen Emerson, and A Prasad Sistla. Automatic verifica-tion of finite-state concurrent systems using temporal logic specifications.
ACMTransactions on Programming Languages and Systems (TOPLAS) , 8(2):244–263,1986.9. Conrado Daws, Alfredo Olivero, and Sergio Yovine. Verifying et-lotos programswith kronos. In
Formal Description Techniques VII , pages 227–242. Springer, 1995.10. Angela Figueiredo de Freitas. From Circus to Java: Implementation and verificationof a translation strategy.
Master’s thesis, University of York , 2005.11. Jin Song Dong, Ping Hao, Shengchao Qin, Jun Sun, and Wang Yi. Timed automatapatterns.
IEEE Transactions on Software Engineering , 34(6):844–859, 2008.12. Jin Song Dong, Ping Hao, Jun Sun, and Xian Zhang. A reasoning method fortimed CSP based on constraint solving. In
International Conference on FormalEngineering Methods , pages 342–359. Springer, 2006.13. Neil Evans and Steve Schneider. Analysing time dependent security properties inCSP using pvs. In
European Symposium on Research in Computer Security , pages222–237. Springer, 2000.14. Thomas Gibson-Robinson, Philip Armstrong, Alexandre Boulgakov, and A. W.Roscoe. FDR3: a parallel refinement checker for CSP.
Int. J. Softw. Tools Technol.Transf. , 2016.15. Thomas G¨othel and Sabine Glesner. Automatic validation of infinite real-timesystems. In , pages 57–63. IEEE, 2013.16. Dominik Hansen and Michael Leuschel. Translating TLA+ to B for validationwith ProB. In
International Conference on Integrated Formal Methods , pages 24–38. Springer, 2012.17. Dominik Hansen and Michael Leuschel. Translating B to TLA+ for validationwith TLC. In
International Conference on Abstract State Machines, Alloy, B,TLA, VDM, and Z , pages 40–55. Springer, 2014.18. Charles Antony Richard Hoare. Communicating sequential processes.
Communi-cations of the ACM , 21(8):666–677, 1978.19. Graham Hutton.
Programming in haskell . Cambridge University Press, 2016.20. Yoshinao Isobe, Faron Moller, Hoang Nga Nguyen, and Markus Roggenbach. Safetyand line capacity in railways–an approach in timed CSP. In
International Confer-ence on Integrated Formal Methods , pages 54–68. Springer, 2012.21. Nafiseh Kahani, Mojtaba Bagherzadeh, James R Cordy, Juergen Dingel, andDaniel Varr´o. Survey and classification of model transformation tools.
Software &Systems Modeling , 18(4):2361–2397, 2019.22. Maneesh Khattri. Translating Timed Automata to tock-CSP. In
Proceedings of the10th IASTED International Conference on Software Engineering, SE 2011 , 2011.0 Abdulrazaq Abba , Ana Cavalcanti, and Jeremy Jacob23. Kim G Larsen, Paul Pettersson, and Wang Yi.
Uppaal in a nutshell.
Internationaljournal on software tools for technology transfer , 1(1-2):134–152, 1997.24. Birgitta Lindstrom, Paul Pettersson, and Jeff Offutt. Generating trace-sets formodel-based testing. In
The 18th IEEE International Symposium on SoftwareReliability (ISSRE’07) , pages 171–180. IEEE, 2007.25. Gavin Lowe. Specification of communicating processes: temporal logic versusrefusals-based refinement.
Formal Aspects of Computing , 20(3):277–294, 2008.26. Tom Mens and Pieter Van Gorp. A taxonomy of model transformation.
Electronicnotes in theoretical computer science , 152:125–142, 2006.27. Alvaro Miyazawa, Pedro Ribeiro, Wei Li, Ana Cavalcanti, Jon Timmis, and JimWoodcock. RoboChart: a State-Machine Notation for Modelling and Verificationof Mobile and Autonomous Robots.
Tech. Rep. , pages 1–18, 2016.28. Hanne Riis Nielson and Flemming Nielson.
Semantics with applications: an appe-tizer . Springer Science & Business Media, 2007.29. Sidney Nogueira, Augusto Sampaio, and Alexandre Mota. Guided test generationfrom CSP models. In
International Colloquium on Theoretical Aspects of Comput-ing , pages 258–273. Springer, 2008.30. Marcel Vinicius Medeiros Oliveira.
Formal derivation of state-rich reactive pro-grams using Circus . PhD thesis, University of York, 2005.31. Joel Ouaknine.
Discrete analysis of continuous behaviour in real-time concurrentsystems . PhD thesis, University of Oxford, 2000.32. Andrew William Roscoe.
Understanding Concurrent Systems.
Springer Science &Business Media, 2010.33. AW Roscoe, CAR Hoare, and R Bird. The theory and practice of concurrency.2005.
Revised edition. Only available online , 2005.34. Steve Schneider. Concurrent and real time systems : the CSP approach.
Worldw.Ser. Comput. Sci. , 2010.35. Jun Sun, Yang Liu, Jin Song Dong, and Jun Pang. Pat: Towards flexible verificationunder fairness. In
International Conference on Computer Aided Verification , pages709–714. Springer, 2009.36. Kangfeng Ye and Jim Woodcock. Model checking of state-rich formalism by linkingto