## Section: New Results

Keywords : Mode automata, Generic Modeling Environment, SIGNAL, Model transformation.

### Multi-clocked mode automata

Participants : Jean-Pierre Talpin, Thierry Gautier, Christian Brunette.

Gathering advantages of declarative and imperative approaches, mode automata were originally proposed by Maraninchi et al. [39] to extend the functionality-oriented data-flow paradigm with the capability to model transition systems easily and provide an additional imperative flavor. Similar variants and extensions of the same approach to mix multiple programming paradigms or heterogeneous models of computation [32] have been proposed until recently, the latest advance being the combination of stream functions with automata in [33] . Nowadays, commercial toolsets such as the Esterel Studio's Scade or Matlab/Simulink's Stateflow are largely inspired from similar concepts.

While the introduction of preemption mechanism in the multi-clocked data-flow formalism Signal was previously studied by Rutten et al. in [42] , no attempt has been made to extend mode automata with the capability to model multi-clocked systems and multi-rate systems. In [23] , we extend Signal-Meta with an inherited metamodel of multi-clocked mode automata. A salient feature is the simplicity incurred by the separation of concerns between data-flow (that expresses structure) and control-flow (that expresses a timing model) that is characteristic to the design methodology of SIGNAL.

While the specification of mode automata in related works requires a primary address on the semantics and on compilation of control, the use of SIGNAL as a foundation allows to waive this specific issue to its analysis and code generation engine Polychrony and clearly expose the semantics and transformation of mode automata in a much simpler way by making use of clearly separated concerns expressed by guarded commands (data-flow relations) and by clock equations (control-flow relations).

#### Example of a switch

To illustrate our modeling techniques, we consider the example of a simple crossbar switch (see Figure 16 ). The switch is a typical example of specification where an imperative automata-like structure superimposed to a native data-flow structure gives a shorter and more intuitive description of the system's behavior. The mode automata of the switch consists of two states flip and flop, in which routing is performed from y_{1, 2} to either x_{1, 2} or x_{2, 1} depending on the current mode of the automaton. The mode toggles from flip to flop, or converse, upon an occurrence of the event r (see Figure 16 ).

The left of Figure 17 represents the switch process in which `y1` , `y2` , and `r` are declared as input signals, `x1` and `x2` as output signals, and `SwitchAtm` as the mode automaton. `DATA_TYPE` is a parameter only used to define a generic type for input and output signals. The `SwitchAtm` object is a container in which all its states are specified (see right of Figure 17 ). The `SwitchAtm` automaton contains two terminal states (`flip` and `flop` ). *StrongTransitions* are guarded by the event `r` , as labeled on the middle of transitions. The 0 indicates the priority of the transition, which has been added to guarantee the determinism of a mode automata if there are more than one outgoing transition on a state. The left of Figure 17 also represents the synchronization of the `SwitchAtm` clock with the union of the clock of `y1` , `y2` , and `r` . Because output signals are partially defined in states (see the content of state `flip` (resp. `flop` ) at the left (resp. right) of Figure 17 ), their clocks have to be specified explicitly. Therefore, the *MinClock* operator is used to define them as the union of clocks of their partial definitions.

#### Model Transformation

The transformation consists in interpreting the graphical formalism as a SIGNAL specification. Therefore, we have extended the Signal-Meta interpreter to support the mode automata extension. The code below corresponds to the application of the interpreter on the switch example specified in Figure 17 .

`process Switch =`

` { type DATA_TYPE; }`

` ( ? DATA_TYPE y1,y2; event r; ! DATA_TYPE x1, x2; )`

` (| min_clock(x2) | min_clock(x1)`

` | %Atm%(| __ST_0_flop_To_flip := when (r) when (_Atm_0_zNextState = #flop)`

` | __ST_1_flip_To_flop := when (r) when (_Atm_0_zNextState = #flip)`

` | _Atm_0_currentState ^= (y1 ^+ y2 ^+ r)`

` | _Atm_0_nextState := _Atm_0_currentState`

` | _Atm_0_currentState := #flip when __ST_0_flop_To_flip`

` default #flop when __ST_1_flip_To_flop`

` default _Atm_0_zNextState`

` | _Atm_0_previousState := _Atm_0_currentState$ init #flip`

` | _Atm_0_zNextState := _Atm_0_nextState$ init #flip`

` | case _Atm_0_currentState in`

` {#flop}: (| x2 ::= y1 | x1 ::= y2 |)`

` {#flip}: (| x2 ::= y2 | x1 ::= y1 |)`

` end`

` |)`

` where`

` event __ST_0_flop_To_flip, __ST_1_flip_To_flop;`

` type _Atm_0_type = enum(flop, flip);`

` _Atm_0_type _Atm_0_currentState, _Atm_0_previousState;`

` _Atm_0_type _Atm_0_nextState, _Atm_0_zNextState;`

` end`

` |); % process Switch`