Section: New Results

Formal Semantics of Behavior Specifications in the Architecture Analysis and Design Language Standard

Participants : Loïc Besnard, Thierry Gautier, Jean-Pierre Talpin.

The Architecture Analysis and Design Language (AADL) is a standard proposed by SAE to express architecture specifications and share knowledge between the different stakeholders about the system being designed. To support unambiguous reasoning, formal verification, high-fidelity simulation of architecture specifications in a model-based AADL design workflow, we have defined formal semantics for the behavior specification of the AADL. These semantics rely on the structure of automata present in the standard already, yet provide tagged, trace semantics framework to establish formal relations between (synchronous, timed, asynchronous) usages or interpretations of behavior [17]. We define the model of computation and communication of a behavior specification by the synchronous, timed or asynchronous traces of automata with variables. These constrained automata are derived from polychronous automata defined within the polychronous model of computation and communication [11].

States of a behavior annex transition system can be either observable from the outside (initial, final or complete states), that is states in which the execution of the component is paused or stopped and its outputs are available; or non observable execution states, that is internal states. We thus define two kinds of steps in the transition system: small steps, that is non-observable steps from or to an internal state; and big steps, that is observable steps from a complete state to another, through a number of small steps). The semantics of the AADL considers the observable states of the automaton. The set of states $S_A$ of automaton $A$ (used to interpret the behavior annex) thus only contains states corresponding to these observable states and the set of transitions $T_A$ big-step transitions from an observable state to another (by opposition with small-step transitions from or to an execution state). The action language of the behavior annex defines actions performed during transitions. Actions associated with transitions are action blocks that are built from basic actions and a minimal set of control structures (sequences, sets, conditionals and loops). Typically, a behavior action sequence is represented by concatenating the transition systems of its elements; a behavior action set is represented by composing the transition systems of its elements.

The polychronous model of computation had been used previously as semantic model for systems described in the core AADL standard. This translation of AADL specifications into the polychronous model now takes into account the behavior specifications. The import of AADL behavior annexes (AADL-BA) to the polychronous model relies on polychronous automata and on small steps/big steps semantics. Small steps may be viewed as an implicit oversampling of the big steps. To express such implicit upsampling, a model of Signal-thread has been introduced in Polychrony (refer to Section “New trends and developments in Polychrony”). In that context, the translation of a behavior annex associated with an AADL thread consists mainly in the production of the corresponding Signal automaton, which is declared as a Signal-thread, and the definition of the environment required for this Signal-thread. In particular, the signal complete-thread is defined so that it will occur when the next state of the automaton is a complete state (the control will return to the scheduler): in other words, it specifies the end of a sequence of small steps.

A specific difficulty in the translation of AADL-BA is the translation of the action language, which is related to the general problem of the translation of a sequential language to a dataflow one. First, in AADL-BA actions, a given variable may be assigned several times in a sequence (for example, $x=a+b;x=x+a$). Thus an AADL-BA action has to be transformed into a SSA (static single assignment) form ($x_0=a+b;x=x_0+a$ in the previous example). Another possible problem is the translation of AADL-BA loop structures (for, while, do until). In our case, this is solved, again, by considering them as Signal-threads: the dispatch-thread event is defined by the upperbound of the clocks of the inputs of the loop and the complete-thread event defines the termination of the loop.