Composing Families of Timed Automata

. Featured Timed Automata (FTA) is a formalism that enables the veriﬁcation of an entire Software Product Line (SPL), by capturing its behavior in a single model instead of product-by-product. However, it disregards compositional aspects inherent to SPL development. This paper introduces Interface FTA (IFTA), which extends FTA with variable interfaces that restrict the way automata can be composed, and with support for transitions with atomic multiple actions, simplifying the design. To support modular composition, a set of Reo connectors are modelled as IFTA. This separation of concerns increases reusability of functionality across products, and simpliﬁes modelling, maintainability, and extension of SPLs. We show how IFTA can be easily translated into FTA and into networks of Timed Automata supported by UPPAAL. We illustrate this with a case study from the electronic government domain.


Introduction
Software product lines (SPLs) enable the definition of families of systems where all members share a high percentage of common features while they di↵er in others.Among several formalisms developed to support SPLs, Featured Timed Automata (FTA) [5] model families of real-time systems in a single model.This enables the verification of the entire SPL instead of product-by-product.However, FTA still need more modular and compositional techniques well suited to SPL-based development.
To address this issue, this paper proposes Interface FTA (IFTA), a mechanism enriching FTA with (1) interfaces that restrict the way multiple automata interact, and (2) transitions labelled with multiple actions that simplify the design.Interfaces are synchronisation actions that can be linked with interfaces from other automata when composing automata in parallel.IFTA can be composed by combining their feature models and linking interfaces, imposing new restrictions over them.The resulting IFTA can be exported to the UPPAAL real-time model checker to verify temporal properties, using either a network of parallel automata in UPPAAL, or by flattening the composed automata into a single one.The latter is better suited for IFTA with many multiple actions.
We illustrate the applicability of IFTA with a case study from the electronic government (e-government) domain, in particular, a family of licensing services.This services are present in most local governments, who are responsible for assessing requests and issuing licenses of various types.E.g., for providing public transport services, driving, construction, etc.Such services comprise a number of common functionality while they di↵er in a number of features, mostly due to specific local regulations.
The rest of this paper is structured as follows.Section 2 presents some background on FTA.Section 3 introduces IFTA.Section 4 presents a set of Reo connectors modeled as IFTA.Section 5 discusses a prototype tool to specify and manipulate IFTA.Section 6 presents the case study.Section 7 discusses related work, and Section 8 concludes.

Featured Timed Automata
This work builds on top of Featured Timed Automata (FTA) an extension to Timed Automata, introduced by Cordy et al. [5] to verify real-time systems parameterised by a variability model.This section provides an overview of FTA and their semantics, based on Cordy et al..
Informally, a Featured Timed Automaton is an automaton whose edges are enriched with clocks, clock constraints (CC), synchronisation actions, and feature expressions (FE).A clock c 2 C is a logical entity that captures the (continuous and dense) time that has passed since it was last reset.When a timed automaton evolves over time, all clocks are incremented simultaneously.A clock constraint is a logic condition over the value of a clock.A synchronisation action a 2 A is used to coordinate automata in parallel; an edge with an action a can only be taken when its dual action in a neighbor automaton is also on an edge that can be taken simultaneously.Finally, a feature expression (FE) is a logical constraint over a set of features.Each of these features denotes a unit of variability; by selecting a desired combination of features one can map an FTA into a Timed Automaton.
Figure 1 exemplifies a simple FTA with 2 locations, `0 and `1, with a clock c and 2 features cf and mk , standing for the support for brewing co↵ee and for including milk in the co↵ee.Initially the automaton is in location `0, and it can evolve either by waiting for time to pass (growing the clock c) or by taking one of its 2 transitions to `1.The top transition, for example, is labelled by the action co↵ee and is only active when the feature cf is present.Taking this transition triggers the reset of the clock c back to 0, evolving to the state `1.Here it can again wait for the time to pass, but for at most 5 time units, determined by the Fig. 1: Example of a Featured Timed Automata over the features cf and mk .
invariant c  5 in `1.The transition labelled with brew has a di↵erent guard: a clock constraint c 2 that allows this transition to be taken only when the clock c is greater than 2. Finally, the lower expression [ fm = mk !cf ] defines the feature model.I.e., how the features relate to each other.In this case the mk feature can only be selected when the cf feature is also selected.
We now formalize clock constraints, feature expressions, and the definition of FTA and its semantics.
Definition 1 (Clock Constraints (CC), valuation, and satisfaction).A clock constraint over a set of clocks C, written g 2 CC(C) is defined as follows where c 2 C, and n 2 N.
A clock valuation ⌘ for a set of clocks C is a function ⌘ : C ! R 0 that assigns each clock c 2 C to its current value ⌘c.We use R C to refer to the set of all clock valuations over a set of clocks C. Let ⌘ 0 (c) = 0 for all c 2 C be the initial clock valuation that sets to 0 all clocks in C. We use ⌘ + d, d 2 R 0 , to denote the clock assignment that maps all c 2 C to ⌘(c) + d, and let [r 7 !0]⌘, r ✓ C, be the clock assignment that maps all clocks in r to 0 and agrees with ⌘ for all other clocks in C \ r.
The satisfaction of a clock constraint g by a clock valuation ⌘, written ⌘ |= g, is defined as follows Definition 2 (Feature Expressions (FE) and satisfaction).A feature expression ' over a set of features F , written ' 2 F E(F ), is defined as follows where f 2 F is a feature.The other logical connectives can be encoded as usual: Given a feature selection FS 2 F over a set of features F , and a feature expression ' 2 F E(F ), F S satisfies ', noted F S |= ', is defined as follows: where } 2 {^, _}.
Definition 3 (Featured Timed Automata (FTA) [5]).An FTA is a tuple A = (L, L 0 , A, C, F, E, Inv, fm, ) where L is a finite set of locations, L 0 ✓ L is the set of initial locations, A is a finite set of synchronisation actions, C is a finite set of clocks, F is a finite set of features, E is a finite set of edges, Notation: We write A.L, A.L 0 , A.A, etc., to denote the locations, initial locations, actions, etc., of an FTA A, respectively.We write `1 cc,a,c !`2 to denote that (`1, cc, a, c, `2) 2 A.E, whenever automaton A is clear from the context.
The semantics of FTA is given in terms of Featured Transition Systems (FTSs) [4].An FTS extends Labelled Transition Systems with a set of features F , a feature model fm, and a total function that assigns FE to transitions.Definition 4 (Semantics of FTA).Let A = (L, L 0 , A, C, F, E, Inv , fm, ) be an FTA.The semantics of A is defined as an FTS hS, S 0 , A, T, F, fm, 0 i, where S ✓ L ⇥ R C is the set of states, S 0 = {h`0, ⌘ 0 i | `0 2 L 0 } is the set of initial states, T ✓ S ⇥ (A [ R 0 ) ⇥ S is the transition relation, with (s 1 , ↵, s 2 ) 2 T sometimes noted s 1 ↵ !s 2 , and 0 : T !F E(F ) is a total function that assigns feature expressions to transitions.The transition relation is defined as follows.
where for each of the rules above, the associated featured expression is defined as

Interface Featured Timed Automata
Multiple FTAs can be composed and executed in parallel, using synchronising actions to synchronise edges from di↵erent parallel automata.This section introduces interfaces to FTA that: (1) makes this implicit notion of communication Fig. 2: Representation of 3 IFTA, depicting their interfaces (blue) and associated feature expressions.
more explicit, and (2) allows multiple actions to be executed atomically in a transition.Synchronisation actions are lifted to so-called ports, which correspond to actions that can be linked with actions from other automata.Hence composition of IFTA is made by linking ports and by combining their variability models.
Definition 5 (Interface Featured Timed Automata).An IFTA is a tuple A = (L, l 0 , A, C, F, E, Inv , fm, , I, O) where L, A, C, F, Inv , fm, are defined as in Featured Timed Automata, there exists only one initial location l 0 , edges in E contain sets of actions instead of single actions Given a port p 2 P we write p? and p! to denote that p is an input or output port, respectively, following the same conventions as UPPAAL for actions, and write p instead of {p} when clear from context.The lifting of actions into sets of actions will be relevant for the composition of automata.We call interface of an IFTA A the set A.I [ A.O of all input and output ports of an automaton, and assign to each of these ports a feature expression based on the feature expressions of the edges as follows.Notation: we use i, i 1 , etc., and o, o 1 , etc. to refer specifically to input and output ports of an IFTA, respectively.Definition 6 (Feature Expression of an Action).Given an IFTA A, the feature expression of any action a is the disjunction of the feature expressions of all of its associated edges.More precisely, it is given by A (a), defined below.Figure 2 depicts the interfaces of 3 di↵erent IFTA.The leftmost is a payment machine that receives actions representing coins and publishes actions confirming the payment, whose actions are dependent on a feature called pay.The rightmost is the co↵ee machine from Figure 1.Finally, the middle one depicts a connector Router that could be used to combine the payment and the co↵ee machines.This notion of combining IFTA is the core contribution of this work: how to reason about the modular composition of timed systems with variable interfaces.
The semantics of IFTA is given in terms of FTSs, similarly to the semantics of FTA with the di↵erence that transitions are now labelled with sets of actions.We formalize this as follows.
Definition 7 (Semantics of IFTA).Let A be an IFTA, its semantics is an FTS F = (S, s 0 , A, T, F, fm, ), where S, A, F , fm, and are defined as in Definition 4, s 0 = h`0, ⌘ 0 i is now the only initial state, and T ✓ S⇥(2 A [R 0 )⇥S now supports transitions labelled with sets of actions.
We now introduce two operations: product and synchronisation, which are used to define the composition of IFTA.The product operation for IFTA, unlike the classical product of timed automata, is defined over IFTA with disjoint sets of actions and clocks, performing their transitions in an interleaving fashion.
Definition 8 (Product of IFTA).Let A 1 and A 2 , be two di↵erent IFTA with disjoint actions and clocks, the product of A 1 and A 2 , denoted where E, Inv, and are defined as follows -E is defined by the rules below, for any -The associated feature expression of the 3 rules above, is defined as follows.
(h`1, `2i The synchronisation operation over an IFTA A connects and synchronises two actions a and b from A.A. The resulting automaton has transitions without neither a and b, nor both a and b.The latter become internal transitions. Definition 9 (synchronisation).Given an IFTA A = (L, `0, A, C, F, E, Inv , fm, , I, O) and two actions a, b 2 A, the synchronisation of a and b is given by a,b (A) = (L, `0, A\{a, b}, C, F, E 0 , Inv , fm 0 , , I\{a, b}, O\{a, b}) where E 0 and fm 0 are defined as follows Together, the product and the synchronisation can be used to obtain in a compositional way, a complex IFTA modelling SPLs built out of primitive IFTA.
Definition 10 (Composition of IFTA).Given two disjoint IFTA, A 1 and A 2 , with possible shared features, and a set of bindings {(a 1 , b 1 ), . . ., (a Figure 3 exemplifies the composition of the co↵ee machine (CM) and Router IFTA from Figure 2. The resulting IFTA combines the feature models of the CM and Router, imposing additional restrictions given by the binded ports, E.g., the binding (o 1 , co↵ee) imposes that o 1 will be present, if and only if, co↵ee is present (which depends on the feature expressions of each port), I.e., (f i ^fo1 ) $ cf .In the composed IFTA, transitions with binded actions transition together, E.g., transition (`2, `0) i !(`2, `1) with feature expression f i ^fo1 ^cf represents the joint transitions `0 i,o1 !`0 and `0 co↵ee !`1.The transitions from CM and Router labelled with non-binded actions (i and brew) can transition independently or together../To study properties of IFTA operations, we define the notion of IFTA equivalence in terms of bisimulation over their underlying FTSs.We formally introduce the notion of timed bisimulation adapted to FTSs.
Definition 11 (Timed Bisimulation).Given two FTSs F 1 and F 2 , we say R ✓ F 1 .S⇥F 2 .S is a bisimulation, if and only if, for all possible feature selections F S 2 2 F1.F [F2.F , F S |= F 1 .fm, F S |= F 2 .fmand for all (s 1 , s 2 ) 2 R we have: Two states s 1 2 S 1 and s 2 2 S 2 are bisimilar, written s 1 ⇠ s 2 , if there exists a bisimulation relation containing the pair (s 1 , s 2 ).Given two IFTA A 1 and A 2 , we say they are bisimilar, written A 1 ⇠ A 2 , if there exists a bisimulation relation containing the initial states of their corresponding FTSs.
Proposition 1 (Product is commutative and associative).Given two IFTA A 1 and A 2 with disjoint set of actions and clocks, Proof.Follows trivially by definition of product and FTSs, and because [, ⇥, and ^are associative and commutative.
The synchronisation operation is commutative, and it interacts well with product.
The following proposition captures these properties.
Proposition 2 (synchronisation commutativity).Given two IFTA A 1 and A 2 , the following properties hold: A and A 1 .A \ A 2 .A = ;.Proof.Property 1 follows trivially from the definition of synchronisation.
For property 2, for simplicity, let us assume , and A 12 = A 1 ⇥ A 2 , and let F 1 and F 2 be the underlying FTSs of A and A 0 .It is easy to see that both resulting automata, A and A 0 , share the same set of edges, and their feature models are not the same but are equivalent.We have that, A.fm = A 1 .fm^A2 .fm ^( A1 (a) $ A1 (b)) and A 0 .fm= A 1 .fm^A2 .fm ^( A12 (a) $ ( A12 (b)).Without loss of generality we consider only action a and show that A1 (a) is logically equivalent to A12 (a).By definition of A1 we have Similarly, by definition of A12 we have

Reo connectors as IFTA
Reo is a channel-based exogenous coordination language where complex coordinators, called connectors, are compositionally built out of simpler ones, called channels [2].Exogenous coordination facilitates anonymous communication of components.Each connector has a set of input and output ports, and a formal semantics of how data flows from the inputs to the outputs.We abstract from the notion of data and rather concentrate on how execution of actions associated to input ports enables execution of actions associated to output ports.Table 1 shows examples of basic Reo connectors and their corresponding IFTA.For example, Merger (i 1 , i 2 , o) synchronises each input port, separately, with the output port, and FIFO1 (i, o) introduces the notion of delay by executing its input while transitions to a state where time can pass, enabling the execution of its output without time restrictions.
Modelling Reo connectors as IFTA enables them with variable behavior based on the presence of ports connected through synchronisation to their ports.We associate a feature f a to each port a of a connector and define its behavior in terms of these features.Table 1 shows Reo basic connectors as IFTA with variable behavior.Bold edges represent the standard behavior of the corresponding Reo connector, and thinner edges model variable behavior.For example, the Merger connector supports the standard behavior, indicated by the transitions `0 {i k ,o} !`0, k = 1, 2 and the corresponding feature expression f k ^fo ; and a variable behavior, in which both inputs can execute independently at any time if o is not present, indicated by transitions `0 {i k } !`0, k = 1, 2 and the corresponding feature expression f k ^¬f o .
The Sync connector behaves as the identity when composed with other automata.The following proposition captures this property.

Proposition 3 (Sync behaves as identity). Given an IFTA A and a
Proof.First for simplicity, let A S = (A ⇥ Sync(i, o)), and A 0 = i,a (A S ).Lets note that the set of edges in A 0 is defined as follows Table 1: Examples of basic Reo connectors and their corresponding IFTA.
fi fo where `0 is the initial and only location of Sync.Let F 1 and F 2 be the underlying FTS of A 0 and A[o/a], and note that R = {(h(`1, `0), ⌘i, h`1, ⌘i) | `1 2 A[o/a].S} is a bisimulation between states of F 1 and F 2 .Let (h(`1, `0), ⌘i, h`1, ⌘i) 2 R. The proof for delay transitions follows trivially from the fact that Inv (`1, `0) = Inv (`1) for all `1 2 A[o/a].S.

Lets consider any action transition
In both cases, we have We developed a prototype tool in Scala1 consisting of a small Domain Specific Language (DSL) to specify (networks of) (N)IFTA and manipulate them.Although we do not provide the formal definitions and semantics due to space constraints, informally, a network of any kind of automata is a set of automata parallel composed (||) and synchronised over a set of shared actions.Main features supported by the DSL include: 1) specification of (N)IFTA, 2) composition, product and synchronisation over IFTA, 3) conversion of NIFTA to networks of FTA (NFTA) with committed states (CS), and 4) conversion of NFTA to UPPAAL networks of TA (NTA) with features.Listing 1.1 shows how the router connector from Table 1 can be specified using the DSL.A comprehensive list of functionality and more examples, including the case study from Section 6 can be found in the tool's repository 1 .
A NIFTA can be converted into a NFTA with committed states, which in turn can be converted into a network of UPPAAL TA, through a stepwise conversion, as follows.NIFTA to NFTA.Informally, this is achieved by converting each transition with set of actions into to a set of transitions with single actions.All transitions in this set must execute atomically (committed states between them) and support all combinations of execution of the actions.NFTA to UP-PAAL NTA.First, the NFTA obtained in the previous step is translated into a network of UPPAAL TA, where features are encoded as Boolean variables, and transition's feature expressions as logical guards over Boolean variables.Second, the feature model of the network is solved using a SAT solver to find the set of valid feature selections.This set is encoded as a TA with an initial committed location and outgoing transitions to new locations for each element in the set.Each transition initializes the set of variables of a valid feature selection.The initial committed state ensures a feature selection is made before any other transition is taken.
When translating IFTA to FTA with committed states, the complexity of the model grows quickly.For example, the IFTA of a simple replicator with 3 output ports consists of a location and 8 transitions, while its corresponding FTA consists of 23 locations and 38 transitions.Without any support for composing variable connectors, modelling all possible cases is error prone and it quickly becomes unmanageable.This simplicity in design achieved through multi-action transitions leads to a more e cient approach to translate IFTA to UPPAAL TA, in particular by using the composition of IFTA.The IFTA resulting from composing a network of IFTA, can be simply converted to an FTA by flattening the set of actions in to a single action, and later into an UPPAAL TA.

Case Study: Licensing Services in e-government
This section presents a case study of using IFTA to model a family of public licensing services.All services in the family support submissions and assessment of licensing requests.Some services, in addition, require a fee before submitting (pa), others allow appeals on rejected requests (apl ), or both.Furthermore, services that require a fee can support credit card (cc) or PayPal payments (pp), or both.Functionality is divided in components and provided as follows.Each component can be visualized in Figure 4. We omit the explicit illustration of interfaces and rather use the notation ?,! to indicate whether an action corresponds to an input or output, respectively.In addition, we use the same action name in two di↵erent automata to indicate pairs of actions to be linked.The feature model, also omitted, is initially > for each of these IFTA.
App -Models licenses requests.An applicant must submit the required documents (subdocs), and pay a fee (payapp) if pa is present, before submitting (submit).If the request is accepted (accept) or considered incomplete (incomplete), the request is closed.If it is rejected (reject) and it is not possible to appeal (¬apl ), the request is closed, otherwise a clock (tapl ) is reseted to track the appeal window time.The applicant has 31 days to appeal (App.Inv (`5 )), otherwise the request is canceled (cancelapp) and closed.If an appeal is submitted (appeal), it can be rejected or accepted, and the request is closed.
CC and PP -Handle payments through credit cards and PayPal, respectively.If a user requests to pay by credit card (paycc) or PayPal (paypp), a clock is reset to track payment elapsed time (tocc and topp).The user has 1 day (CC .Inv (`1 ) and PP .Inv (`1 )) to proceed with the payment which can result in success (paidcc and paidpp) or cancellation (cancelcc and cancelpp).
Appeal -Handles appeal requests.When an appeal is received (appeal), a clock is reseted to track the appeal submission elapsed time (tas).Authorities have 20 days (Appeal .Inv (`1 )) to start assessing the request (assessapl).
Preassess -Checks if a request contains all required documents.When a request is received (submit), a clock is reseted to track the submission elapsed time (ts).Authorities have 20 days (Preasses.Inv (`1 )) to check the completeness of the documents and notify whether it is incomplete (incomplete) or ready to assessed (assessapp).
Assess -Analyzes requests.When a request is ready to be assessed (assess), a clock is reseted to track the processing elapsed time (tp).Authorities have 90 days to make a decision of weather accept it (accept) or reject it (reject).
We use a set of Reo connectors to integrate these IFTA.The final integrated model can be seen in Figure 5.For simplicity, we omit the feature expressions associated to ports and the resulting feature model.Broadly, we can identify two new components in this figure: Payment -(right of App) Orchestrates payment requests based on the presence of payment methods.It is composed by componets CC, PP, and a set of connectors.A router synchronises payment requests (payapp) with payment by CC or PayPal (paypp or paycc).A merger synchronises the successful response (paidpp or paidcc), while other merger synchronises the cancellation response (cancelpp or cancelcc) from either CC or PP.
On top of the composed feature model, we add the restriction pa $ cc _ pp to ensure payment is supported, if and only if, Credit card or PayPal are supported; and Processing -(left of App) Orchestrates the processing of licenses requests and appeals (if apl is present).It is composed by Appeal, Preassess, Assess, a set of trivial sync connectors and a merger that synchronises assessment requests from either Appeal or Preassess (assessapl or assessapp) with Assess (assess).
By using IFTA, connectors are reused and it is simple to create complex connectors out of simple ones.If in the future a new payment methods is supported, the model can be updated by simple using a three output replicator and two three inputs mergers.By composing the future model and inferring new restrictions based on how interfaces are connected, it is possible to reason about the variability of the entire network, E.g., we can check if the resulting feature model satisfies variability requirements or if the interaction of automata is consistent with the presence of features.In addition, by using the DSL we can translate this components to UPPAAL to verify properties such as: Deadlock free -A[] not deadlock; Liveness -a submission and an appeal will eventually result in an answer (App.`4--> App.`0 and App.`6 --> App.`0, respectively); Safetya submission must be processed within 110 days (A[] App.`4 imply App.tsub <=110).Compositionality and modularity of SPLs.An extension to Petri Nets, Feature Nets (FNs) [11] enables specifying the behavior of an SPL in a single model, and supports composition of FNs by applying deltas FNs to core FNs.An extension to CCS process calculus consisting on a modular approach to modelling and verifying variability of SPLs based on DeltaCCS [9].resulting in models of features that can be reused easily.A compositional approach for verification of software product lines [10] where new features and variability may be added incrementally, specified as finite state machines with variability information.
Interfaces and compositionality of automata.Interface automata [1] use input interfaces to support incremental design and independent implementability of components, allowing compatibility checking of interfaces for partial system descriptions, without knowing the interfaces of all components, and separate refinement of compatible interfaces, respectively.[6] presents a specification theory for I/O TA supporting refinement, consistency checking, logical and structural composition, and quotient of specifications.In [8] Modal I/O automata are used to construct a behavioral variability theory for SPL development and can serve to verify if certain requirements can be satisfied from a set of existing assets.[7] proposes a formal integration model based on Hierarchical TA for real time systems, with di↵erent component composition techniques.[3] presents a compositional specification theory to reason about components that interact by synchronisation of I/O actions.

Conclusions
This paper introduced IFTA, a formalism for modelling SPL in a modular and compositional manner, which extends FTA with variable interfaces to restrict the way automata can be composed, and with multi-action transitions that simplify the design.A set of Reo connectors were modeled as IFTA and used to orchestrate the way various automata connect.We discussed a prototype tool to specify and manipulate IFTA, which takes advantage of IFTA composition to translate them into TA that can be verified using the UPPAAL model checker.
Delegating coordination aspects to connectors enables separation of concerns.Each automata can be designed to be modular and cohesive, facilitating the maintenance, adaptability, and extension of an SPL.In particular, facilitates the replacement of components and enables changes in the way they interact without a↵ecting their internal definition.Using bare FTA for designing variable connectors, can be error prone and it quickly becomes unmanageable.IFTA simplifies this design by enabling the modeling of automata in isolation and composing them by explicitly linking interfaces and combining their feature models.
Future work includes studying further properties of IFTA and the impact of integrating this notion of composition and variability with well known specification and refinement theories for I/O automata.
is the invariant, a partial function that assigns CCs to locations, fm 2 FE (F ) is a feature model defined as a Boolean formula over features in F , and : E !FE (F ) is a total function that assigns feature expressions to edges.