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 y1, 2 to either x1, 2 or x2, 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
