Safety Assessment of AltaRica models via Symbolic Model Checking

Transcription

1 Safety Assessment of AltaRica models via Symbolic Model Checking Marco Bozzano a, Alessandro Cimatti a, Oleg Lisagor b, Cristian Mattarei a, Sergio Mover a, Marco Roveri a, Stefano Tonetta a a Fondazione Bruno Kessler, Trento, Italy b The University of York, York, United Kingdom Abstract AltaRica is a language used to describe safety critical systems that has become a de-facto European industrial standard for Model-Based Safety Assessment (MBSA). However, even the most mature tool for the support for MBSA of AltaRica models, i.e. Dassault s OCAS, has several limitations. The most important ones are its inability to perform many analyses exhaustively, severe scalability issues, and the lack of model checking techniques for temporal properties. In this paper we present a novel approach for the analysis of AltaRica models, based on a translation into an extended version of the model checker NuSMV. The translation relies on a novel formal characterization of the Dataflow dialect of AltaRica used in OCAS. The translation is formally defined, and its correctness is proved. Based on this formal characterization, a toolset has been developed and integrated within OCAS, thus enabling functional verification and safety assessment with the state of the art techniques of NuSMV. The whole approach is validated by an experimental evaluation on a set of industrial case studies, which demonstrates the advantages of the proposed technique over the currently available tools. Keywords: Model Checking, Safety Assessment, Fault Tree Analysis, Altarica 1. Introduction Safety-critical systems are traditionally subject to a high degree of authority, which mandates the application of suitable techniques for safety assessment (e.g., Fault Tree Analysis (FTA) [1, 2] or Failure Modes and Effects Analysis (FMEA)), to analyze the behavior of the system in presence of faults. Preprint submitted to Science of Computer Programming June 9, 2014

2 The dramatic increase in complexity of computer-based systems has motivated, in recent years, a growing industrial interest in model-based safety assessment (MBSA) methods. In contrast to traditional safety assessment, where each safety-significant event (e.g., a system hazard, or component failure mode) is subject to separate analysis, MBSA methods are based on a single safety model of a system, typically written in a suitable modeling language. Analyses with respect to particular safety-significant events are conducted on the basis of such safety models with a high degree of automation [3]. Many of the MBSA techniques allow the verification of the functional correctness of the system (e.g., with respect to functional safety requirements) as well as to assess system behavior in the presence of faults [4, 5, 6]. In particular, formal verification tools based on model checking have been extended to automate the generation of artifacts such as Fault Trees (FTs) and FMEA tables [7, 8, 9]. AltaRica [10, 11] is a modelling language for MBSA, specifically developed by a consortium of French industrial and academic partners for safety assessment of industrial systems (see, e.g., [12, 13]). AltaRica has been used in several projects by companies and consortia like Airbus, Alenia Aeronautica, Alstom Rail, Dassault Aviation, EADS, France Telecom, Schneider Electric, Thales, Total and Turbomeca, and has become a de-facto European industrial standard over the course of the last decade or so. In fact, to authors knowledge, it is the only MBSA language that has been successfully used for certification of industrial safety-critical systems. AltaRica is the modeling language used in Cecilia OCAS [13] (OCAS for short), a model-based safety assessment platform developed by Dassault Aviation. OCAS provides a graphical modelling environment, which allows us to describe dynamic transition systems and it is well understood and accepted by the engineers. OCAS is also equipped with different model analysis tools, including a trace simulator (able to generate possible evolutions of the system), and a sequence generator that is used to generate minimal cut sets [1, 2]. Interestingly, OCAS is the only MBSA tool that was accepted by regulatory agencies as a basis for certification of safety-critical systems. The tool was qualified to the requirements of DO-178b [14], the industrial standard for software development and assurance in the aviation sector. OCAS demonstrated its usefulness for the architectural safety assessment of avionics systems, for example the OCAS analysis was the basis for the certification of the Flight Control System of Falcon 7x aircraft. However, the size reached by industrial systems constantly increases the labor and costs in certification, and calls for increasingly automated and highly scalable 2

3 techniques and tools. In particular, the analysis tools in OCAS are subject to some important limitations. First, some analyses are not able to perform an exhaustive space examination, and are not complete. For example, reachability analysis is bounded in depth; similarly, the OCAS sequence generator cannot explore nondeterministic instantaneous transitions, potentially leading to incomplete analysis results. Second, the OCAS sequence generator demonstrates limited scalability in presence of industrial-sized systems, hindering the generation of important artifacts such as Fault Trees. Finally, OCAS does not support the representation and analysis of temporal properties of AltaRica models, which makes model validation an extremely hard task. In this paper we propose an approach that overcomes these limitations. The idea is to translate AltaRica models into HyDI [15], one of the input languages of NuSMV [16]. NuSMV is a state-of-the-art symbolic model checker, providing cutting-edge model checking technologies such as Binary Decision Diagrams (BDD)-based [17] and SAT-based Bounded Model Checking (BMC) [18] techniques. NuSMV supports both temporal model checking (CTL and LTL temporal logics), and safety assessment, e.g., Fault Tree Analysis (FTA) and FMEA, through its add-on NuSMV-SA. NuSMV has been used in several industrial contexts, for instance for verification and validation of aerospace systems [9], and is one of the most mature formal verification tools available to date. The translation enables the use of the NuSMV functionalities, thus extending the existing analysis techniques for AltaRica models. Although in principle simple, realizing this flow posed a key challenge: the formal characterization of the AltaRica language defined in [11] lacks a clear link between the concrete syntax of the language and the abstract syntax (and thus its semantics). Our first contribution is to provide a formal characterization of the AltaRica language in the Dataflow formulation used in OCAS. The formalization includes a rich abstract syntax, and the corresponding semantics, taking into account the recursive definition of nodes, input/output flows, and their connections through assertions. Second, we formally define a translation from AltaRica to HyDI, and prove its correctness, showing a one-to-one correspondence in the behaviors of the models. This result is the foundation for the correctness of the overall approach, and it allows us to map artifacts from HyDI (e.g., counterexample traces produced by NuSMV) back to AltaRica, and constitutes a key enabler for a future qualification of the certification process. Based on this result, we developed the NuSMV/OCAS plugin, which extends the OCAS environment with the following functionalities: invariant checking, 3

4 temporal model checking, and fault tree generation. The NuSMV/OCAS plugin was developed within MISSA (More Integrated Systems Safety Assessment), a European Community-sponsored project involving various research centers and industries from the avionics sector [19]. The industrial partners conveyed important insights on the functionalities of interest, and provided some case studies. The NuSMV/OCAS plugin was validated with respect to the behavior shown by the OCAS simulator. We evaluated both behaviors on a set of industrial-size case studies developed in MISSA, and compared it, when possible, with the existing analysis tools of OCAS. The results of the evaluation clearly show that this activity resulted in a significant improvement of OCAS, both in terms of available functionalities, and in terms of performance improvement. The paper is organized as follows. First, in Section 2 we discuss our approach with the existing related works, then in Section 3 we give an overview of the AltaRica Dataflow formulation while in Section 4 we introduce the HyDI language. We present an informal description of our translation in Section 5. In Section 6 we present the newly defined abstract syntax and semantics of AltaRica and its translation to HyDI. In Section 7 we present the integration into OCAS. Finally, in Section 8 we discuss the experimental evaluation and in Section 9 we conclude and discuss future work. 2. Related Work Since early 1990s a large number of MBSA languages and notations became available. The most prominent languages include Failure Propagation and Transformation Notation and Calculus (FPTN and FPTC) [20, 21], Hierarchically Performed Hazard Origin and Propagation Studies (HiP-HOPS) [22], Error Model Annex of Architecture Analysis and Design Language (AADL) [23], and AltaRica language. In the authors experience, only latter three languages have matured beyond the level of research prototypes. The original language of AltaRica, developed by LaBRI, is based on the notion of interfaced constraint automata, and is highly expressive. In this paper, we adopt the restricted dialect of AltaRica, called AltaRica Dataflow, that was later developed to restrict the complexity of the models and, under certain constraints, to permit the synthesis of the fault trees [24, 25]. The reference formal characterization of AltaRica is defined in [11]. Here we provide a richer formal characterization, driven by the need to recursively define a translation towards the HyDI language. In particular, we defined an abstract syntax of AltaRica, and a recursively defined semantics. In particular, our abstract 4

5 syntax differs from the one presented in [11] in that it directly defines concepts like the input and output flows, which are widely used in the concrete language, while it simplifies less useful notions, like the global coordination expressed by observer nodes. There exist several tools for modeling in (various dialects of) AltaRica. Among these, we mention the academic toolset developed and maintained at the University of Bordeaux [10]; SIMFIA [26], a modelling, simulation and RAMS analysis environment developed by EADS APSYS that supports a Dataflow dialect similar to that implemented by OCAS; COMBAVA, developed by ARBoost Technologies, and now obsolete. OCAS is tightly integrated with Cecilia ARBOR - a Fault Tree Analysis software. Quantitative and Qualitative analysis of fault trees performed in both Cecilia ARBOR and SIMFIA Safety modules are based on Aralia [27]. Whilst there also exists a plugin for the synthesis of fault trees (implementing the algorithm of [25]), such functionality is only available for a very restricted subset of AltaRica Dataflow. In practice, AltaRica models in OCAS are analysed by the sequence generator, which analyses the model and, depending on configuration, produces a set of either sequences or sets of events that are sufficient for a particular condition in the model to hold. Informally, if model events represent failures of components and selected condition of interest represents a hazard, the sequence generator produces a close equivalent of FTA s minimal cut sets. There are other model checkers that support AltaRica, in particular MEC 5 [28] and Arc [29]. MEC 5 is a somewhat outdated model checker that is now superseded by Arc. Arc is a more recent, BDD-based model checker based on the AltaRica language, which supports CTL* temporal logics and µ-calculus. Arc is not currently linked to OCAS and the interoperability with a MEC 5 plugin has not been supported in newer versions of OCAS. Moreover, neither Arc nor its predecessor MEC support safety assessment functionalities. AltaRica studio [30] is a prototypical toolset, based on Arc, for model-based formal analyses. To our knowledge, safety assessment functionalities are not available in AltaRica studio, yet. A thorough comparison of the model checking engines is hard because of differences in the dialects (and flavours thereof) of AltaRica supported by the different tools. This work has been focused on AltaRica Dataflow - a more extended comparison will be targeted for future work. 5

6 3. The AltaRica language In this section we briefly describe the syntax of the AltaRica language, and in particular, the Dataflow dialect and its semantics - we refer the reader to [10, 11] for additional details. A simple example of an AltaRica model is presented in 1 node main 2 event 3 t o t a l r e s e t ; 4 sub 5 cs : counters ; 6 add : adder ; 7 obs : observer ; 8 sync 9 <t o t a l r e s e t, cs. c1. reset, cs. c2. reset >; 10 assert 11 cs. output1 = add. input1, 12 cs. output2 = add. input2, 13 cs. output1 = obs. input1, 14 cs. output2 = obs. input2, 15 add. value out = obs. inputs ; 16 edon node counters 19 flow 20 output1 : [ 0, 3 ] : out ; 21 output2 : [ 0, 3 ] : out ; 22 sub 23 c1 : counter ; 24 c2 : counter ; 25 assert 26 c1. value out = output1, 27 c2. value out = output2 ; 28 edon node observer 31 flow 32 out ok : bool : out ; 33 input1 : [ 0, 3 ] : i n ; 34 input2 : [ 0, 3 ] : i n ; 35 inputs : [ 1, 6 ] : i n ; 36 assert 37 out ok = ( inputs = ( input1 + input2 ) ) ; 38 edon 39 node counter 40 flow 41 v a l u e o u t : [ 0, 3 ] : out ; 42 state 43 value : [ 0, 3 ] ; 44 event 45 inc, reset ; 46 trans 47 value < 3 inc > value := value + 1; 48 value = 3 reset > value := 0; 49 i n i t 50 value := 0; 51 assert 52 value out = value ; 53 edon node adder 56 flow 57 i n p u t 1 : [ 0, 3 ] : i n ; 58 i n p u t 2 : [ 0, 3 ] : i n ; 59 v a l u e o u t : [ 0, 7 ] : out ; 60 state 61 value : [ 0, 7 ] ; 62 event 63 add, 64 f a u l t a d d ; 65 trans 66 value < 7 add > value := input1 + input2 ; 67 t r u e f a u l t a d d > value := 7; 68 i n i t 69 value := 0; 70 assert 71 value out = value ; 72 edon Figure 1: Adder example in AltaRica Figure 1. The system consists of two modulo 4 counters and an adder. The base component of an AltaRica model is called a node. A node is composed by the following sections: event: used for defining the events that can be fired and, thus, trigger a state transition; state: this section is used to declare the state variables of the (basic) node; the value of these variables may change only upon firing of an event; this implies that their value does not change in between two consecutive event firings (while other components are executing); 6

7 flow: this section declares flow variables, used to describe the connections with the other components; flow variables are linked to state variables by means of assertions; there are two types of flow variables, namely input and output flow variables; init: this section is used to specify the initial value of state variables; trans: this section is used to describe the transitions of the system; each transition consists of a guard, the firing event, and a list of assignments; the assignments specify how the system state changes when the corresponding event is fired; the guard is a precondition that has to be satisfied for the transition to be taken; assert: used to establish links from a flow variable to a state variable or another flow variable; more specifically, it declares a set of equalities either between an output flow variable and an expression over input flow and state variables (internal assert), or between an input flow of a subnode and the output flow of another subnode (in-out assert), or between an input flow of the node and an input flow of a subnode (in-in assert), or between an output flow of the node and an output flow of a subnode (out-out assert); sub: used to describe the hierarchy of the AltaRica nodes; in this section, it is possible to instantiate the subnodes that are the children of the current node; sync: used to define the synchronizations; a synchronization associates an event of the node to the events of the subnodes; there are three types of synchronizations, namely strong sync, weak sync, and Common Cause Failure (CCF) (c.f. end of this section). An AltaRica model is a hierarchical tree composed of nodes. The nodes can communicate through links defined in their common parent nodes. These links can be expressed as equalities over the flow variables (i.e. in the assert section), or via synchronizations. The AltaRica structure is composed of two types of nodes: equipment (main and cs white squares in Figure 2): represents a container for nodes; it may contain declarations of subnodes, synchronizations and flow links between subnodes, but it cannot have state variables; component (gray in Figure 2): represents a single process of the system, it cannot contain definition of subnodes or synchronizations. 7

8 main cs add obs c1 c2 Figure 2: Hierarchical view of adder example as shown in figure 2, the component nodes represent the leaves, whereas the equipment nodes are containers for the components. Moreover, there is a special equipment node called main, which represents the root of the full AltaRica model. The semantics of the AltaRica model is defined in terms of Interfaced Transition Systems (ITSs) (c.f. [11, 31]). Intuitively, the ITS associated with a component is given straightforwardly by the state variables (which define the states), the initial condition, the transitions, the events and flow variables (which define the observations) of the node. The ITS associated to an equipment node is given by the composition of the ITSs associated with the subnodes taking into account synchronizations. The mechanisms for the different synchronizations are illustrated in Figs. 3a, 3b and 3c. Strong Sync. As in the example in Figure 3a, if we have a strong sync between the events e 1 and e 2 (in AltaRica expressed as e 1, e 2 ), the corresponding processes (components) p 1 and p 2 must move synchronously on such events. This means that the transitions of p 1 fired by e 1 and the transitions of p 2 fired by the event e 2 happen atomically, and that e 1 is fired if and only if e 2 is fired; as an example, the system in Figure 1 declares a strong synchronization, called total reset, synchronizing the reset on the two counters. Weak Sync. Figure 3b expresses the behavior of weak sync. This type of synchronization represents a broadcast; participating events happen synchronously as in the strong sync, but only if the corresponding transitions are enabled; this means that if the event e 1 of p 1 is fired and there exists a transition t 2 of p 2 on the event e 2 whose guard is true, then e 2 is fired at the same time as e 1 ; otherwise (if the guard is false) e 1 is fired and p 2 does not change state; similarly, if e 2 is fired and 8

9 P 2 P 1 e 1 S 1 S 1 P 2 P 1 e 1 S 1 S 1 P 2 P 1 e 1 S 1 S 1 e 1 S 2 e 2 S 1, S 2 S 2 e 2 S 1, S 2 S 1, S 2 S 2 e 2 S 1, S 2, S 2 e 2 S 1 S 2 S 1, S 2 S 2 S 1, S 2 S 1, S 2 S 2 S S 1, S 2 1, S 2 (a) Strong synchronization (b) Weak synchronization (c) CCF synchronization Figure 3: AltaRica synchronizations: in each figure the bottom right corner represents the allowed transitions in the composition of the two systems. Dashed arrows represent a transition where both P 1 and P 2 move (i.e. the fired event in the composition is e 1 /e 2 ), while solid arrows represent a local transition. the guard on e 1 is false, p 1 does not change state. Such kind of synchronization is expressed in the AltaRica language using as e 1 e 2... e n. CCF Sync. The Common Cause Failure (see Figure 3c) synchronization is similar to a weak synchronization, with the difference that individual processes can move on the events independently. This means that either we have a sync involving e 1 and e 2 (with the same rules of the weak sync) or e 1 is fired or e 2 is fired. The motivation for CCF sync is to describe the condition when two components can fail due to an internal error, represented by the e 1 and e 2 events, or by means of a common cause, for instance the engine burst. In this case we can express such condition using CCF (with concrete syntax as e 1?e 2 ), where each failure can be caused by the engine explosion (i.e. the weak sync) or by internal errors. The evolution of an AltaRica system can be further constrained by associating events with a specific priority. This definition is possible by providing a partial order in the event section e.g. the highest priority of event e 1 with respect to e 2 it is expressed with e 1 < e 2. Differently, some AltaRica based tools, support the event priority feature by extending the language with a specific section called extern. In the case of OCAS, the partial ordering of events is provided by labeling them with probability distribution laws e.g. the definition of an event of type Dirac(2) has priority respect to a Dirac(3), but not to a Dirac(0). These laws, considering Dirac(x) as well as Exponential(x), are used to establish interoperability with commercial RAMS (Reliability, Availability, Maintainability and Safety) analysis tools and do not affect the qualitative behaviour of the system. 9

10 4. The HyDI language The HyDI [15] language extends the standard symbolic language SMV, the main input language of the NuSMV model checker, with continuous variables and synchronization aspects. In the following, we disregard the continuous aspects of HyDI, since they are not used in the translation from AltaRica. Compared to SMV, HyDI models asynchronous components, instead of synchronous systems, which communicate through message passing and shared variables. Since NuSMV provides an automatic mapping from HyDI to SMV, HyDI models can be analyzed by the safety-assessment techniques implemented in NuSMV. A direct mapping from an asynchronous language, like AltaRica, to SMV is non-trivial, time-consuming and error prone, since the translation requires to manually encode all the asynchronous aspects of the system. In practice, this amounts to modify the behavior of all the asynchronous processes adding idle transitions, and to enforce the complex synchronization constraints. Thus, the main advantage of HyDI over SMV is to directly model asynchronous systems. A HyDI program is given by a set of modules, a set of processes and a set of synchronization constraints. A HyDI module extends SMV modules allowing one to specify synchronization constraints. A module contains a set of declarations which define: a set of variables (VAR); a set of input variables (IVAR); a set of initial constraints (INIT) defining the initial states; a set of invariant conditions (INVAR) which restricts the valid assignments to the variables; a set of transition constraints (TRANS), defining the state transitions. Moreover, a module defines a set of input parameters. A module can be instantiated in the VAR section of another module. The module instantiation defines the actual parameters passed to the module, thus enabling the sharing of variables among different instances. The main module is the top-level module of a program and cannot be instantiated. The HyDI language allows one to define a network of processes which run asynchronously on private events while they synchronize on shared events. The processes are instantiated in the main module. The network is not hierarchical, since the synchronizations are declared between processes. However, the definition of a single process may be hierarchical, since it can contain the instantiation of sub-modules. The module used to instantiate a process contains the definition of the set of discrete events (EVENT section) used to define its synchronization with other processes. In the HyDI language a synchronization declares that two events of two processes must be fired at the same time. A variant of this type of synchronization, called weak synchronization, allows one to specify a guard which forces the synchronization only if the guard evaluates to true. Finally, the 10

11 order of occurrence of events can be further constrained with a scheduler, modeled in HyDI by variables and constraints in the main module. 5. Translation from AltaRica to HyDI 5.1. Overview In this section we describe the encoding of the AltaRica language into NuSMV. The formal translation [31] has been designed using HyDI [15] as an intermediate language. We refer to [15] for a discussion of the translation from HyDI to NuSMV. In the following we detail the main steps of the translation: Flattening of the hierarchy: unlike AltaRica, HyDI does not support hierarchical process definitions. Hence, we describe a preliminary step of the translation which flattens the structure of the AltaRica program. Translation of flow variables and assertions: these definitions cannot be directly mapped into HyDI; Translation of event priorities: HyDI does not support the definition of event priorities; Synchronizations: AltaRica supports three kinds of synchronizations: strong, weak and CCF, whereas HyDI supports only the first two Flattening of the hierarchy The network of processes defined by AltaRica is hierarchical in that the synchronizations may be specified at the different levels of the AltaRica tree structure. Thus, in order to encode the AltaRica specification into HyDI we perform a flattening of the AltaRica hierarchy as depicted in Figure 4b. Each AltaRica equipment node is split into several new instances in order to create a hierarchy corresponding to the paths from the root to each leaf. This flattening is possible since the instances of the equipment nodes cannot have definition of state variables. For the flattening it is necessary to perform some additional transformations on the resulting structure because of the constraints imposed by the HyDI language. In AltaRica synchronization definitions can be specified at all levels of the hierarchy (i.e., in the equipment nodes). In HyDI they must be in the main module. Thus, we need to move all the synchronization definitions to the top level 11

12 main main cs add obs cs cs add obs c1 c2 c1 c2 (a) AltaRica structure (b) HyDI structure Figure 4: Hierarchy translation HyDI main module. Another difference between HyDI and AltaRica concerns the definition of discrete events used in the synchronizations. In HyDI the declaration of discrete events is done in the module definition of each instance and, thus, new events cannot be declared in a submodule. AltaRica, on the other hand, requires them to be specified within the leafs (i.e., in the component nodes). Our solution restructures the AltaRica hierarchy in such a way that all the events present in the original AltaRica structure are declared in the definition of an instance in HyDI, and passed as parameters to the submodules. The drawback of this encoding consists in the possible growth in terms of resulting model size. However, this solution does not increase the complexity and also greatly simplifies the translation from AltaRica to HyDI. Finally, the translation of the leaf nodes is straightforward. Each leaf node maps to an SMV module. Each state variable is encoded into an SMV state variable of the same type. The AltaRica init and trans sections directly translate into SMV INIT and TRANS formulas, respectively Translation of variables and assertions constraints AltaRica allows one to define two types of variables: state variables (which represent the internal state of the system) and flow variables (used to expose the internal state and to link the different components). The translation of the state variables is straightforward, as they also become state variables in HyDI. The translation of the flow variables is carried out as follows: Internal assert: the link between output flow and state variables is expressed 12

13 N1 N2 N3 N4 (a) Case In-Out (b) Case In-In and Out-Out Figure 5: Flow translation cases by an assertion. In this case the flow variable is represented as a NuSMV define on the state variable; In-Out (Figure 5a): in this case we have a link connecting an input flow of one component with an output flow of another component. In this case the direction is explicitly expressed by the flow labels. This is translated by passing the state variable referred to by the output flow as a parameter to the module translating the component with the input flow; In-In (Figure 5b red links): this situation is represented by the direct forwarding of an input flow to a subcomponent. In this case the solution is analogous to the previous case, with the difference that the external component plays the writer role; Out-Out (Figure 5b blue links): this case is similar to the previous one with the difference that the subcomponent plays the role of writer Translation of priorities and synchronization constraints In AltaRica it is possible to define priorities that induce a partial order among events. This feature is encoded into HyDI by defining an explicit scheduler that imposes such priority constraints over the events. The AltaRica language permits the definition of three possible kinds of synchronizations between events: strong, weak, and CCF (see Figure 3 and Section 6.2). HyDI has native support for the weak and strong synchronizations, while there is no support for the CCF synchronization. We encode the CCF synchronization taking into account its semantics: a CCF involving two events e 1 13

14 and e 2 is either a weak synchronization among e 1 and e 2, or simply event e 1 or event e 2 in isolation. Thus, we duplicate events e 1 and e 2 in e 1 and e 2, respectively, to enable for the two events to occur in isolation, and we add a new weak synchronization between e 1 and e Formal Properties of the Translation This section provides a formal definition of the translation from AltaRica to HyDI. We first provide the formal semantics of the AltaRica and the HyDI languages, and then we formally define the translation from AltaRica to HyDI, proving the correctness of the overall approach. The semantics of AltaRica and HyDI has been formalized using a standard model-theoretic approach to the definition of the semantics of formal languages. In particular, AltaRica and HyDI programs are interpreted with a variant of transition systems, as usual in model checking. This was preferred to other approaches to formal semantics, such as for example Structural Operational Semantics [32], that are well established for programming languages Background In this section we define some background notions used to define the semantics of the AltaRica language. We will define the semantics of AltaRica using an extension of a labeled transition system, called Interface transition system [11] (ITS). Definition 6.1 (Interfaced Transition System [11]). An Interfaced Transition System (ITS) is a tuple A = E, O, C, I, π, T where: E is set of events, ε E; O is a set of observations; C is a set of configurations (i.e. states of the systems); I C is the set of initial configurations; π : C O is a function mapping each configuration c C to an observation π(c) O; T C E C is a set of transitions, such that c, ε, c for each c C. 14

15 An ITS extends a labeled transition system with a set of observations O and the mapping function π. Intuitively, π defines a mapping from each state of the system, also called configuration, to an observation in O. O is defined generically, and represents a set of states observable by another ITS. The observation are used to expose the internal state of a component to its parent, in a hierarchical composition of ITSs. Note that AltaRica features this hierarchical structure. Also, the label ε is used to denote the stuttering event. Intuitively, ε labels the transition c, ε, c that does not change the configuration of the ITS. This transition is used to synchronize with other ITS, with the implicit meaning the ITS is not changing its configuration, thus modeling asynchronous behaviors in a synchronous setting. Given an ITS A and an ordering relation < E over the events of A, we define the priority resolution operation. The operation defines a new ITS A <E, which differ from A only for the transition relation. The transition relation of A <E contains only the transitions with higher priority (according to < E ). Formally: Definition 6.2 (Priority resolution). Given an Interfaced Transition System A = E, O, C, I, π, T and an ordering < E over E, we define the priority resolved ITS A <E = E, O, C, I, π, T < E, where T < E = { c, e, c T c, e, c T, e < E e}. Both AltaRica and HyDI feature a symbolic representation of the system, where set of states and relations are represented by formulas. Given a set of variables V, we use V to denote the set of next state variables {v } v V, where v represents the next value of v. Given a set of variables V = {v 1,..., v n } and a prefix p, we will denote with p.v the set of variables p.v = {p.v 1,..., p.v n }, obtained by renaming all the variables by adding the prefix p.. In the following, we use the standard notation for propositional logic s = φ(v ), to express that s is a model of the formula φ(v ). A state of the system becomes an assignment to the variables V. A set of states is represented by a formula α(v ) over the variables V : a state s belongs to the set if s, as an assignment, makes the formula true (namely, s = α(v )) We will often use an evaluation function σ, which returns the set of all the possible assignments to the variables in the set V. If V is the set of variables of a system, then σ(v ) returns the set of all the states of the system. Definition 6.3 (Evaluation function). Given a set of variables S = {s 1,..., s n } the evaluation function σ is defined as: σ(s) = {(s 1 = v 1,..., s n = v n ) v i Dom(s i )}. 15

16 6.2. The semantics of AltaRica Syntax In Definition 6.4 we provide a variant of the abstract syntax of the AltaRica language described in [11]. The motivation for introducing a different definition of the AltaRica syntax is to have an abstract syntax that is closer to the concrete one and that clarifies the definition given in the original presentation. In particular, we define a relational function between flow variables that differs from the original one that is expressed by means of a controller node. Then, for clarity we explicitly split the mapping between state and flow variables and the invariants over flow variables, which are merged in the concrete syntax (section assert ). Moreover, we need to avoid the possibility of constraining input flow variables due to the fact they are read-only ports. This limitation is guaranteed by the fact that output flows are defined over input flows and state variables. However, we need also to impose a single assertion for each output flow in order to avoid indirect and transitive constraints e.g., if we have output = input and output = 1, it implicitly defines that input = 1. Moreover, we allow for a hierarchy definition by permitting composition of AltaRica nodes, and this permits us to provide a clear separation between abstract syntax and semantics, which is expressed via the Interfaced Transition System. Finally, our definition of the AltaRica structure is based on a symbolic representation. Definition 6.4 (AltaRica Node). An AltaRica node is a tuple N = E, < E, S, F, I, T, P, N 1,..., N n, A, V, with n 0, where: E is a set of events partially ordered by < E. S is the set of state variables; F = F I F O is the set of flow variables, split into input and output flows, with F I F O = I(S) is the initial formula; T (S, F I, Γ E, S ) is the transition formula; P : F O Expr(S) is a function mapping output flow variables to expressions over state variables; i = 1,..., n N i = E i, < Ei, S i, F i, I i, T i, P i, N i1,..., N im, A i, V i, with m 0, is an AltaRica node, called sub-node; 16

17 A(F, N 1.F 1,..., N n.f n ) is an invariant formula over the flow variables representing the assert section (N i.f i is the set of flow variables of the subnode N i ); thus, A is in the form of a conjunction of equalities v = e, one for every variable v in F O 1 i n N i.f ii, where e is an expression over S F I 1 i n N i.f io ; V E? E? 1... E? n is the set of synchronization vectors defined over the extended sets of events E? i = E i {e? e E i {ε}} (i.e., E i? contains also a copy of the events marked with the? symbols). If n > 0, V always contains the vector ε = ε,..., ε. With the symbol Γ E we denote a variable with Dom(Γ E ) = E that is used to represent the current event of the system. For example, the transition constraint (Γ E = e 1 ) counter = counter + 1 describe a transition where the counter variable is incremented by 1 if the event is e 1 (i.e., the label of the transition is e 1 ). An AltaRica program is hierarchically defined as a tree of AltaRica nodes, where only the leaves contain state variables and define a transition relation, while the other nodes define the interaction among their children. We indenty the AltaRica program with the root node of the tree. We define two kinds of nodes, the internal nodes, of type equipment, and the leaf node, of type component. Definition 6.5 (Types of AltaRica node). An AltaRica node N = E, < E, S, F, I, T, P, N 1,..., N n, A, V can be of two different types: Equipment type: if S =, I = T rue, T = T rue, and P is such that P (f) = T rue for each f F O. Component type: if n = 0, A = T rue, and V =. The interaction between an AltaRica node and its sub-nodes is defined by the relation over flow variables and the synchronization vectors. The flow variables represent the configuration a component that are visible by the other components. In particular, the function P associates an expression over the state variables S to a specific flow variable f F 0. They directly map to an internal assert in the concrete syntax. Moreover, the interaction between the flow variables of a component and of its subnodes can be constrained by the invariant section A. The invariant section A represents the in-out assert, the in-in assert and the out-out assert of the concrete AltaRica syntax. The synchronization vectors model a message-passing style of communication, allowing complex patterns like broadcasting messages. For instance, it is 17

18 possible to model the response to a failure in the system. Suppose that, in response to a failure, a controller broadcasts to all the engines the message turn off. The communication must be non-blocking to model also the failure of the engines (i.e. when the engine cannot be turned off). Suppose the system is composed by 4 components, a controller, an observer and two engines. Then, the synchronization vector failure sync, failure, ε, turn off?, turn off? represents a set of several synchronization instances: { failure sync, failure, ε, turn off, turn off, failure sync, failure, ε, ε, turn off, failure sync, failure, ε, turn off, ε, failure sync, failure, ε, ε, ε } (recall that the first event in the tuple is the event of the parent ITS node). The set represents all the possible actions performed by the system. The question mark appended to an event in the synchronization vector specifies that the event is non-blocking, thus allowing different instances of synchronization (e.g., the question mark models the fact that an event can happen, but this is not mandatory). In the following, we use the notation Inst(v) to denote all the instances of a synchronization vector v. The synchronization vector can represent the three types of synchronization of the concrete syntax of AltaRica. For example, the synchronization vector { failure sync, failure, ε, turn off, turn off represent a strong synchronization on the event failure sync of the parent ITS (in the synchronization the first component moves on failure, the second moves on stutter, the third and the fourth move on turn off). A weak synchronization is expressed appending the question mark? to an event. For example f ailure sync, f ailure, ε, turn of f?, turn of f? is a weak synchronization. Finally, a CCF synchronization can be represented with several synchronization vectors. One vector defines a weak synchronization (i.e. if one of its instances fire, it means that a synchronization happened), while the other vectors describe the movement of single components with their own event (i.e. it means that no synchronization happened). For example, the following vectors represent a CCF synchronization: { f ailure sync, f ailure?, ε, turn off?, turn off? and { failure, failure, ε, ε, ε, turn off, ε, ε, turn off, ε, turn off, ε, ε, ε, turn off }. Definition 6.6 (Instances of a synchronization vector). Given a synchronization vector v = e 0,..., e n of an AltaRica node A, u = u 0,..., u n Inst(V ) if for all 1 i n it holds that: (i) if e i E i, then u i = e i ; (ii) if e i = b?, b E i \ {ε}, then u i {b, ε} Semantics The semantics of an AltaRica program is obtained by applying recursively the definition of the semantics for each subnode of the tree, starting from the root. 18

19 Thus, we provide the semantics for the two types of AltaRica nodes. Given an AltaRica node N = E, < E, S, F, I, T, P, N 1,..., N n, A, V, let IT S N = E, O, C, I, π, T be the ITS that defines the semantics of N. We define the IT S N of the root node A by recursively defining the ITS of all its subcomponents in the tree (e.g., similarly to a post-order visit). ITS of a component node. If N is of type component then IT S N is defined as: E = E; O = σ(f ); C = {c = s, f s σ(s), f σ(f O ), s = P (f)}; I = {c C c = I(S)}; π : C O is such that c C, c = s, f, π (s) = f; T = T < E, where T = { c, e, c C E C c, e, c = T }; The IT S N has the same events of the AltaRica node. Its configurations are all the possible assignments to the state and output flow variables of N that satisfy the function P (i.e. which intuitively define the value of each flow variable as a set of values of S). The observations are defined by all the possible assignments to the flow variables F, and the initial states by all the configurations that satisfy I. Then, the mapping from a configuration c to an observable is the projection of each configuration c = s, f on S. Finally, the transition relation T is represented by the set of tuples composed of a source configuration, an event, and a destination configuration that satisfy T, and later restricted according to the priorities < e. ITS of an equipment node. If N is of type equipment, we define the IT S N as follows. First, 1 i n, N i is an AltaRica node and IT S i = E i, O i, C i, I i, π i, T i is its associated ITS. We define IT S N as follows: E = E; O = σ(f ); C = {(o, c 1,..., c n ) O C 1... C n (o, c 1,..., c n ) = A}; I = {(o, i 1,..., i n ) O I 1... I n}; 19

20 π : C O is such that π (o, c 1,..., c n ) = o; T = T ; In the case of an equipment node, the set of configurations C is constructed by the product of its observables and the configurations of its subcomponents. Similarly, this happens for the set of initial states. The mapping π for a configuration c = o, c 1,..., c n is simply o. Instead, the definition of the transition relation T is more convoluted and it is defined in a constructive fashion as follows. 1. This step defines the set T C, which contains all the transitions obtained considering all the instances of synchronization vectors V. Let V local = {v v = n, i [1, n], e i E i, j [1, n], j i, e j = ε} be the set of the local events of a component. Let W = v V V local Inst(v) {v} be the set of pairs composed by an instance of a synchronization vector v (either from V or V local ) and the synchronization vector v. Then T c C W C contains all the elements (c 1,..., c n ), e, e 1,..., e n, v, (c 1,..., c n) such that: for all i = 1,..., n, c i, e i, c i T i. for all c C, c, (ε,..., ε, ε), c T c. 2. This step defines the set T B, that restricts T C considering only the transitions that maximize the number of components that synchronize. Let u = e, e 0,..., e n, u = u = e, e 0,..., e n. We say that u u iff the number of events different from ε in u is greater than u (i.e. in u more components move). We define the partial order < W on transition instances u, v, u, v W : (u, v) < W (u, v ) if and only if v = v and u u. Then, we restrict T C considering only the transitions that have a maximal number of components that synchronize. Formally, T B = T C < W. 3. We define T A C E C, the transition relation restricted to the events E of IT S N. c, e, c T A either if: there exists w = (e, e 1,..., e n, v) W such that e E and c, w, c T B. c, e, c = c, ε, c, for some c C. 20

21 4. Finally, we apply the ordering < E to T A, i.e. T = T A < E The semantics of HyDI In this section, we introduce the HyDI language, its syntax 1 and semantics Syntax A HyDI network is composed of a set of processes, a set of synchronizations and a set of global constraints over the variables of the processes. Each process M is described with a set VAR of state variables. Each process contains an enumerated type variable EVENT, which is used as guard for the transitions of the process. A specific value S in the domain of EVENT is used to represent the stuttering of the process, while other processes are asynchronously active. When a process performs the action S, its state does not change. The synchronizations and global constraints can range over the variables EVENT of a process, thus forcing stuttering and synchronizations. Formally, an HyDI process M is a tuple PARAM, VAR, IVAR, INIT, TRANS, INVAR where: PARAM is the set of parameters; VAR is the set of state variables; IVAR is the set of input variables; INIT is the initial formula over the variables PARAM VAR; TRANS is the transition formula over the variables VAR PARAM IVAR VAR (note that the parameters can only be read by the process); INVAR is the invariant formula over the variables PARAM VAR. An HyDI network H is a tuple M, VAR, IVAR, INIT, INVAR, TRANS, SYNC H, WEAKSYNC H, MAP where: 1 In order to ease the presentation and the description of the translation, we give an abstract version of HyDI without considering modules and their instantiation. The reader may refer to [15] for a complete description of the language. 21

22 M is a set of processes where, for all M M, M = PARAM M, VAR M, IVAR M, INIT M, TRANS M, INVAR M is a process where EVENT M IVAR M (we denote with E M the domain of EVENT M ), VAR is a set of variables (we identify the set of all the variables of a network with VAR H = VAR M M M.VAR M); IVAR is a set of input variables (we identify the set of all the input variables of a network with IVAR H = IVAR M M M.IVAR M); INIT is an initial condition over VAR H ; INVAR is the invariant formula over VAR H. TRANS is a transition condition over VAR H IVAR H VAR H ; SYNC H is a set of strong synchronizations, which contains tuples of the form { i, j, a i, a j, where i, j M, a i E i and a j E j ; WEAKSYNC H is a set of weak synchronizations, which contains tuples of the form i, j, a i, a j, φ i, φ j, where i, j M, a i E i, a j E j and φ i, φ j are formulas over VAR i IVAR i and VAR j IVAR j respectively. φ i and φ j are called guards of the synchronization; MAP is a binding function that maps every p PARAM M of every M M into an expression MAP(p) over VAR H. Given a formula φ, MAPSUBS(φ) denotes the formula obtained by replacing every occurrence of p in φ with MAP(p), for all p PARAM M of every M M. HyDI features two different types of synchronizations. A strong synchronization { i, j, a i, a j enforces two processes i and j to perform a transition labeled with the event a i and a j at the same time. A weak synchronization i, j, a i, a j, φ i, φ j forces the processes i and j to perform a transition labeled with a i and a j at the same time if both φ i and φ j hold. Otherwise, in the case φ i holds and φ j does not hold, i may move on the event a i, while j stutters. A similar behavior happens by inverting the roles of i and j. Intuitively, when both the transitions labeled with a i and a j are enabled, i and j must synchronize. In the case one of the two processes cannot move on the synchronization event, because its guard is false, the other is not blocked and can move on the synchronization event. More general synchronization policies between the processes can be specified by means of the global constraint TRANS, since it can range over the variables EVENT of the 22

23 processes. For example, this feature may be used to encode priorities constraints among the synchronization of the network. Note that we also allow the modeling of shared variables between different instances, with the restriction that only the process which declares a variable can write its value, while the other processes can only read the value of the variable. The restriction is expressed in the fact that the formula TRANS M of each process M can only change its next state variables VAR but not the parameters PARAM. We remark that in the scope of this paper, the sets VAR and IVAR of the network are always empty and that the set IVAR M of every process M always contains only EVENT M Semantics We define the semantics of a HyDI network H = M, VAR, IVAR, INIT, TRANS, INVAR, MAP, where every M M is such that M = PARAM M, VAR M, IVAR M, INIT M, TRANS M, INVAR M. First, for every M M, we define the formula TRANSM S as TRANS M (EVENT M = S v VAR M v = v) (i.e., the frame conditions are added for the stuttering event). Then, we define the semantics of the synchronization constraints SYNC H and WEAKSYNC H. Each strong synchronization { i, j, a i, a j SYNC H is encoded as follows: SYNC i,j,ai,a j = ((i.event = a i ) (j.event = a j )). Then, each weak synchronization i, j, a i, a j, φ i, φ j is encoded with the following formula: WEAKSYNC i,j,ai,a j,φ i,φ j =((i.event = a i φ j) j.event = a j ) ((j.event = a j φ i) i.event = a i ) ((i.event = a i φ j) j.event = S) ((j.event = a j φ i) i.event = S) where φ i (φ j) are obtained from φ i (φ j ) by renaming each variable v with i.v (j.v) and substituting each parameter p of M i (M j ) with MAP(p). Since the synchronization constraints are declared between pairs of processes, we define the transitive synchronization relation SYNC from SYNC and WEAKSYNC. A tuple i, j, a i, a j is in SYNC if i, j, a i, a j SYNC or i, j, a i, a j, φ i, φ j 23