Argos: an automaton-based synchronous language

Computer Languages 27 (2001) 61–92 www.elsevier.com/locate/complang

Argos: an automaton-based synchronous language a

Florence Maraninchia;∗ , Yann R*emondb

VERIMAG1 /Institut National Polytechnique de Grenoble (INPG), Centre Equation – 2, Avenue de Vignate, 38610 GIERES, France b VERIMAG/Universit+e Joseph Fourier Grenoble I (UJF), Centre Equation – 2, Avenue de Vignate, 38610 GIERES, France Accepted 27 April 2001

Abstract Argos belongs to the family of synchronous languages, designed for programming reactive systems: (Lustre (Proceedings of the 14th Symposium on Principles of Programming Languages, Munich, 1987; Proc. IEEE 79(9) (1999) 1305), Esterel (Sci. Comput. Programming 19(2) (1992) 87), Signal (Technical Report, IRISA Report 246, IRISA, Rennes, France, 1985). Argos is a set of operators that allow to combine Boolean Mealy machines, in a compositional way. It takes its origin in Statecharts (Sci. Comput. Programming 8 (1987) 231), but with the Argos operators, one can build only a subset of Statecharts, roughly those that do not make use of multi-level arrows. We explain the main motivations for the de:nition of Argos, and the main di;erences with Statecharts and their numerous semantics. We de:ne the set of operators, give them a perfectly synchronous semantics in the sense of Esterel, and prove that it is compositional, with respect to the trace equivalence of Boolean Mealy machines. We give an overview of the work related to the de:nition and implementation of Argos (code generation, connection to veri:cation tools, introduction of non-determinism, etc.). This paper also gives a set of guidelines c 2001 Elsevier Science for building an automaton-based, Statechart-like, yet perfectly synchronous, language.
Ltd. All rights reserved. Keywords: Argos; Synchronous language; Semantics; Compositionality

∗

Corresponding author. Tel.: +33-4-76-63-48-53; fax: +33-4-76-63-48-50. E-mail address: >[email protected] (F. Maraninchi). 1 VERIMAG is a joint laboratory of UJF, CNRS and INPG. c 2001 Elsevier Science Ltd. All rights reserved. 0096-0551/01/$ - see front matter  PII: S 0 0 9 6 - 0 5 5 1 ( 0 1 ) 0 0 0 1 6 - 9

62

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

1. Introduction 1.1. Reactive systems and the synchronous approach The term of reactive system [6] has been widely accepted to talk about computer systems in which the interactions with an environment are the prominent aspect. They are opposed to transformational ones, in which complex data structures and algorithms are involved. The problem of specifying, programming and verifying real-time reactive systems, together with the de:nition of appropriate development environments, is still an important research problem [5 –7], the following being widely accepted. There exist appropriate design methods, programming languages and environments for transformational systems (or, at least, for systems which are mainly transformational, like compilers). This is not yet the case for reactive systems, like real-time process controllers. Moreover, the need for formal veri:cation methods and tools is even more crucial for reactive systems than for transformational ones, because strong reliability requirements are associated with them. The family of synchronous languages [8] and formalisms has been a very important contribution to the domain. The synchronous approach is the mathematical foundation for the Esterel [3], Lustre [1,2], Signal [4] languages, for the algebra ATP [9], for the Concurrent Constraint Programming paradigm [10]. To a certain extent, some of the various semantics that have been proposed so far for Statecharts [5] are also synchronous. Modecharts [11,12] were recently given a synchronous semantics in the spirit of Esterel. Synchronous languages or formalisms are based upon the synchrony hypothesis, which states that the reaction time of the system is zero. From an external point of view, it means that outputs are produced simultaneously with the inputs, which is clearly unimplementable; however, a synchronous system works :ne provided it reacts suJciently fast, w.r.t. the rate imposed by the environment: if relevant changes in the inputs occur at most each second, the system may take one second to react. When we program a reactive system using a synchronous language, we always have to prove that the :nal code can indeed execute one reaction of the system suJciently fast. We would have to do that for any language. Simply, the structure of the typical imperative code produced by compiling a synchronous language is such that one can provide quite accurate upper-approximations of the execution time, looking at the source program. In the general case, computing the so-called worst-case execution time (see for instance [13]) of a program is diJcult, mainly because of recursion and unbounded loops; but these constructs never appear in the code of a synchronous program. The interesting part is the internal point of view on the synchrony hypothesis. The hypothesis states that the reaction time of a particular component, and the communication time between components, are also zero. This makes the semantics of parallel composition very simple. It could be useless if the implementation of the parallel composition in synchronous languages was based on a separate implementation of each component, running in parallel with a kind of dynamic scheduler, because the hypothesis that the communication takes no time would clearly be in contradiction with the reality of the execution. But the synchronous languages are intended to be compiled into centralized sequential code. The parallel composition and the communication mechanism are introduced only for description purposes, at the level of the language; they are compiled into something sequential, hence they do not imply explicit parallelism and

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

63

communication at execution time. (The problem of distributing code is also important, but can be considered orthogonal to the fact that there indeed exists a parallel structure in the source language; see work by Paul Caspi [14,15]). The synchrony hypothesis implies that systems compose very well, and are easier to describe and verify than asynchronous ones. Moreover, synchrony allows to deal with functional and timing correctness of a system separately [7,16]. Finally, synchronous languages are programming languages, not only speci:cation languages. Their programming environments provide eJcient compilers towards various kinds of software or hardware targets. Relying on a formally de:ned semantics also allows the connection of such programming languages to validation tools (formal veri:cation by model-checking or deductive methods, test case generation, debugging, etc.). For Lustre, see for instance [17,18]. 1.2. Argos The :rst de:nition of Argos appeared in [19,20]. Argos is a set of operators for combining Mealy machines in parallel and hierarchic structures; it has a pure synchronous semantics following that of Esterel; it may be given a graphical syntax similar to that of Statecharts (with no multi-level arrows), and is indeed inspired by the very :rst papers on Statecharts [5] and Higraphs [21]. It is listed in [22] as one of the Statecharts semantic variants, but it was not designed for that purpose, and a lot of Statecharts features are missing. We show, however, that some of these features may be described from the primitive set of Argos operators, thanks to the synchronous semantics. We give below the main motivations for the de:nition of Argos. 1.3. No multi-level arrows The main di;erence between Argos and the various semantics of Statecharts in which people have tried to get rid of the multi-level arrows, is that the perfectly synchronous semantics we adopted allows to replace this rather syntactical feature by a completely semantical one: some processes, at two di;erent levels of the hierarchy, do communicate with each other and this ensures a global behavior similar to that of a multi-level arrow. In some sense, this essential modi:cation is similar to what happened when explicit goto’s were replaced by implicit ones, available through the use of semantical structures like WHILE loops. The important point is that one cannot do without something replacing multi-level arrows: they correspond to very usual situations in the reactive system domain (or you are also bound to forget about hierarchy of states!). The choice we made for Argos has big consequences: with no multi-level arrows, a Statechart-like picture may be seen as a particular combination of well-de:ned automata. An automaton is a set of states and transitions connected together, and this is possible only at one level. Then complex pictures are obtained by two simple constructs: put two (possibly composed) objects in parallel; put a (possibly composed) object inside the state of an automaton. This paves the way to a well-de:ned syntax of programs, on which a structural semantics can be based. When a syntax-directed semantics has been obtained, compositionality begins to make sense, and a careful de:nition of the composition operators guarantees it.

64

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

1.4. A compositional semantics What does compositionality mean, in this context? In all programming languages, one can build several syntactically di;erent programs that do the same. When we are in the process of de:ning a formal semantics, this notion may (should) be formalized a little. For Argos, it means the following: the semantics of a program is given in terms of a Boolean Mealy machine, the mathematical model we use for reactive behaviors. There exists an equivalence relation for such machines, that captures the fact that two machines represent the same reactive behavior (something similar to the fact that, in a sequential language, while true do A od and while true do A; A od are the same). Knowing this equivalence relation, we can de:ne the compositionality criterion for the semantics of Argos: if two sub-programs are the same (i.e. the semantics associates with them two equivalent machines), then one should be able to replace one by the other in any program context, without changing the semantics of the global program (formally: the equivalence is a congruence for all the operators of the language). We show that this is true for the semantics of our operators set. To our opinion, compositionality is a key property for the language to be usable: it allows to reason about sub-programs independently. 1.5. A notion of incorrect programs A less prominent (but yet important for programming real systems) di;erence between Argos and all the Statechart semantic variants we know is our notion of incorrect program. We will see in the sequel that the communication mechanism adopted in Statecharts and Argos gives rise to the so-called causality problems, somewhat similar to deadlocks. Imagine a process that waits for signal a for emitting signal b, talking to a process in parallel that waits for b for emitting a: what should the behavior of the whole be? Are the two processes stuck, waiting for each other to start? Or does a kind of spontaneous reaction take place? Let us call the programs in which such problems appear “non-causal”. For Statecharts, people tried to give a meaning to all combinations of objects, in particular non-causal ones. This leads to some choices in the semantics that may have consequences on the compositionality properties, for instance. Huizing [23] has studied the relationships between what he calls responsiveness (obeying the synchrony hypothesis), causality and modularity (a notion related to our compositionality), and proved, in his framework, that no semantics can be responsive, causal and modular. See more details in Section 6.3. In Argos, we followed the path shown by Esterel: there are incorrect compositions, to which we are not bound to give a meaning. As a consequence, we are interested in compositionality properties for the subset of correct programs only. This is much simpler than trying to integrate a notion of compositionality with a way of giving a meaning to non-causal programs; moreover, it is legitimate: this is the point of view of a programming language designer. In all programming languages one can write incorrect programs that are detected at compile-time and rejected: no meaning is given. This can be due to typing, for instance. Of course, we should provide a detection mechanism for non-causal objects. This is a bit more complex than typing in classical languages, however, especially for valued (i.e. not only Boolean) Argos or Esterel. This is because the exact detection of such incorrect programs is undecidable.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

65

For the Boolean subsets of the languages, it is decidable, but may be quite expensive, because it depends on the expanded control structure of the program. In classical languages, the detection of a large class of errors is also undecidable. A few errors only can be detected at compile-time (like X := 1=0; in Ada); otherwise the sources of potential dynamic errors (like get(Y); X := 1=Y;) are clearly identi:ed, and the compiler produces “defensive” code, which may raise exceptions at execution-time. Hence, the static mechanism may accept incorrect programs, but it provides well-de:ned dynamic errors. In the family of synchronous languages, dedicated to the programming of safety-critical reactive systems, we do not accept dynamic errors. Hence we have to adopt the opposite point of view, and to provide conservative approximate detection mechanisms: if a program is accepted by the detection mechanism, then it is guaranteed to be free of non-causal situations (i.e., dynamic errors); if it is rejected, it may contain non-causal situations, or it may be free of these problems too. When such a language is augmented with arrays or other data structures, the same principle applies: we cannot accept an “index out of bounds” error at execution-time, hence we are bound to be quite drastic at compile-time. The quality of the approximate detection mechanism is good if it does not reject correct programs too often. 1.6. A small number of features (or constructs) Finally, we deliberately gave priority to a clean and simple semantics, and did not hesitate to reject some features, if they did not :t well in the simple semantic framework. It appears now that a lot of sophisticated language features (some of them borrowed from Statecharts) can be described as macro-notations, using a very simple core language. We mention some of them in Section 6.1. This is good news for code-generation, connection to analysis tools, etc. 1.7. Outline of the paper The paper is organized as follows: :rst, in Section 2, we present the notion of a Boolean reactive system, for which the basic Argos operator set is designed, we show a simple example that uses the three main operators of Argos, and we explain their semantics intuitively. Section 3 de:nes the set of operators formally. Section 4 de:nes a language based upon this set of operators, and the notion of causally incorrect program. Section 5 discusses code generation issues, and the connection to analysis tools. Section 6 gives a (probably non-exhaustive) list of related work, with detailed comparison. Section 7 is the conclusion. 2. An Argos example with intuitive semantics 2.1. Boolean reactive systems Boolean Mealy machines constitute the basic components of Argos programs. They are appropriate for the description of Boolean reactive systems, i.e. reactive systems in which the inputs and outputs

66

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

Fig. 1. Two equivalent Argos programs for the modulo-8 a-counter.

are pure signals. A digital watch may be seen as a Boolean reactive system: each button of its interface gives one Boolean input signal, and we can use two Boolean outputs on and off for each element of the digital display. It makes a huge set of outputs (the display of a single digit needs 7 elements, hence 14 signals), but there is no loss of information. The digital watch may also be seen as a reactive system with integer outputs, in which case the physical environment is supposed to deal with outputs like 10, in order to control the display. In some sense, this only changes the position of the frontier between what we call the system, to be described in our language, and what we call the environment. This is usually suJcient for event systems, like the digital watch. For describing signal-processing systems, or simply control systems in which the inputs are given by sampling a continuous phenomenon, one needs valued signals, e.g., integers, reals, etc. Although most complex reactive systems have both event-driven and sampled subsystems, the core of Argos deals with pure signals only, encoded into Booleans. Values are introduced in Section 4.5. 2.2. Description of the program Fig. 1(a) is an Argos program using four automata (or Boolean Mealy machines), to describe a modulo-8 a-counter, with initialization and interruption facilities. Rounded-corner boxes are automaton states; arrows are transitions; rectangular boxes are used for unary operators (see below). A set of states and transitions which are connected together constitutes an automaton. The four basic components of the program have the following sets of states: {Counting, Not counting}, {A0,A1}, {B0,B1}, {C0,C1}. In an automaton, transitions are labeled by inputs and outputs. The input part of a transition label is a Boolean formula of the input signals, not necessarily a complete monomial (the end label stands

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

67

for end.stop ∨ end.stop); the output part is a set of output signals. (The input part and the output part are separated by a slash; negation is denoted by over-lining, and conjunction is denoted by a dot: c=end, stop:end. When the output set is empty, it can be omitted). We also omit the transitions from a state to itself, if they do not emit signals. For instance, the states A0 and A1 of the :rst bit T c). (resp. B0 and B1, C0 and C1) should have loops labeled by aT (resp. b; T There is one initial state, designated by an arrow without source. States are named, but names should be considered as comments: they cannot be referred to in other components. An arrow can have several labels—and stand for several transitions, in which case the labels are separated by a comma. The automaton whose states are Counting and Not counting is said to be re@ned, in its Counting state, by a subprogram built with the three other automata. The external box, whose cartridge contains end, is the graphical syntax for a local signal declaration unary operator. The box de:nes the scope in which the signal end is known. This signal is used as input by the re:ned automaton; it is used as output by one of the three other ones: a communication will take place between the two. Another such unary operator is used in the program, in order to limit the scope of signals b, c to the program constituted by the three unre:ned automata. The interface of the global program is de:ned as follows: all signals which appear in a left-hand (resp. right-hand) side of a label, and are not declared to be local to some part of the program are global inputs (resp. global outputs). The shadowed box gives the name of the program (or subprogram), the list of global inputs, and the list of global outputs. Finally, three automata are put in parallel: they are drawn separated by dashed lines.

2.3. Intuitive semantics The behavior is as follows. Initially, the counter is not counting; the global state is Not counting. It may be started by the input start, which puts the system in the global state Counting:A0B0C0, encoding the value 0. The :rst occurrence of the signal a then moves the :rst bit from A0 to A1 and leaves the two other bits unchanged: Counting:A1B0C0 encodes 1. The next occurrence of a moves the :rst bit back to A0; this transition is labeled by a=b, which means that it broadcasts the signal b towards the other components, that may react to it in the same reaction; it moves the second bit from B0 to B1. The third bit is left unchanged: Counting:A0B1C0 encodes 2. The fourth occurrence of a moves the :rst bit from A1 to A0, which emits b; hence it also moves the second bit from B1 to B0, which emits c; hence it moves the third bit from C0 to C1. The global target state is Counting:C1A0B0, encoding 4. The eighth occurrence of the signal a moves the counter from state Counting:A1B1C1 to state Counting:A0B0C0, and emits the signal end, which is an input of the main automaton: the system returns to the global state Not Counting. At any moment, a stop signal stops the counter, and the system returns to the global state Not Counting. The label stop.end is necessary for ensuring the determinism of the main automaton (see details below). However, since the two transitions labeled by stop.end and end do not emit signals, and have the same target state, they could be replaced by a single one, labeled by stop ∨ end.

68

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

Fig. 2. The behavior of the modulo-8 a-counter.

2.4. Equivalent programs The second program (Fig. 1(b)) is equivalent to the :rst one (see formal de:nition below): the parallel composition of the three bits, with the signals b and c being declared local, has been replaced by a >at automaton, having the same behavior. Since the semantics is compositional, replacing a component by an equivalent one leaves the global program behavior unchanged. Fig. 2 is a third equivalent program, made of one single >at automaton. The semantics of the language formally de:nes the translation of the :rst program (Fig. 1(a)) into the >at automaton of Fig. 2. 3. A set of operations on Boolean Mealy machines In this section, we :rst de:ne the objects that serve as basic components in all Argos programs: Boolean Mealy Machines, with additional properties like determinism and reactivity. Then we de:ne a set of operations on these objects that may, or may not, preserve the additional properties. This set of operations is not yet a language. In the language, we add a syntax for programs (composed objects, i.e. expressions made of basic objects and any number of operators), and de:ne the notion of correction of a program. The de:nition of the operations makes them total, but the notion of program correctness may declare that a particular combination of basic objects and operators is illegal, in which case we are not bound to give it a meaning. 3.1. Deterministic and reactive Boolean Mealy machines A simple reactive behavior may be described by a labeled transition system. The transition system has one initial state. Transition labels are made of two parts: the input part I, and the output part O. The complete label is denoted by I= O. Both parts are built upon a set of elementary interactions with the environment, called signals.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

69

The input part is a Boolean condition on signals. It describe a condition to be ful:lled by the environment in order to make the system react. A Boolean condition describes a set of input signal valuations. The output part is the set of signals the system outputs to its environment, when reacting to a given input. One transition is one reaction, and is supposed to be instantaneous, hence the outputs are simultaneous to the inputs that cause them. Time passes in states. Let AA denote the set of signals. In the general case, a basic Argos component is of the following form: De nition 1 (Boolean Mealy machine). A Mealy machine is a tuple (S; s0 ; I; O; T ) where I ⊆ AA; O ⊆ AA are the sets of input and output signals; S is the set of states; s0 is the initial state; T ⊆ S × AB(I ) × 2O × S is the set of transitions. (AB(I ) denotes the set of Boolean formulas with variables in I .) Without loss of generality, we can always consider that the Boolean Mealy machines we deal with have only complete monomials as input labels. If the set of inputs is {a; b}, then the input condition a stands for: a∧b∨a∧@b, and a transition labeled by a=o may be split into two transitions (between the same states) labeled by a ∧ b=o and a ∧ @b=o. De nition 2 (Bisimulation of Boolean Mealy machines). Two machines M1 = (S1 ; s01 ; I; O; T1 ) and M2 = (S2 ; s02 ; I; O; T2 ) are said to be bisimilar, denoted by M1 ≈ M2 , if and only if there exists an equivalence relation AR ⊆ S1 × S2 such that s01 ARs02 and  

    ∃b1 ; : : : ; bm ; r1 ; : : : ; rm such that       bi =o   b=o ∀i ∈ [1; m]; s
→ ri
∧ rARri
→ r ⇒ s   sARs
⇒        bi   ∧b ⇒   i   and conversely: Bisimulation has been :rst introduced by Park and Milner [24,25]. It coincides with trace equivalence for deterministic systems. The machines we consider should be both deterministic and reactive. We give the de:nition only for machines labeled by complete monomials on the set of inputs. De nition 3 (Determinism and reactivity). A machine (S; s0 ; I; O; T ) is reactive i;:   m = true: ∀s ∈ S; ((s; m;o; s
)∈T )

It is deterministic i;: ∀s ∈ S; ∀t1 = (s; m1 =o1 ; s1 ) ∈ T; ∀t2 = (s; m2 =o2 ; s2 ) ∈ T; m1 = m2 ⇒ (o1 = o2 ) ∧ (s1 = s2 ):

70

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

We will denote by AM r ; AM d and AM rd , respectively, the sets of reactive, deterministic, reactive and deterministic Boolean Mealy machines. Determinism is an important issue. In spite of the inherent non-determinism in the description of the environment, the programs should describe deterministic behaviors. In this framework, non-determinism of a reactive behavior is simply the existence of two transitions sourced in the same state, with non-exclusive input parts, and di;erent output parts and=or target states. 3.2. Operations 3.2.1. Cartesian product or parallel composition The formal de:nition of parallel composition is based upon the following product operation. De nition 4 (Synchronous product of Boolean Mealy machines). × : AM × AM → AM (S1 ; s01 ; I1 ; O1 ; T1 ) × (S2 ; s02 ; I2 ; O2 ; T2 ) = (S1 × S2 ; (s01 ; s02 ); I1 ∪ I2 ; O1 ∪ O2 ; T
); where T
is de:ned by ((s1 ; m1 ; o1 ; s1
) ∈ T1 ; (s2 ; m2 ; o2 ; s2
) ∈ T2 ) ⇒ ((s1 ; s2 ); m1 ∧ m2 ; o1 ∪ o2 ; (s1
; s2
)) ∈ T
): The synchronous product of Boolean Mealy machines is both commutative and associative, and it is easy to show that it preserves both determinism and reactivity. Note that the parallel composition does not make any synchronization between components. It is the appropriate construct for the parallel composition of two independent systems. When the systems have to communicate or synchronize with each other, parallel composition should be used together with encapsulation of some dedicated signals; this is explained below. Since all the components are reactive, a transition in the composed process corresponds to exactly one transition in each of its parallel components. Some of them execute loops, and emit no signals, so their reaction is not observable, but they do take a transition, and only one. The machine corresponding to the parallel composition of the two :rst bits of the counter (before applying the unary operator that declares b and c to be local) is given in Fig. 3.

Fig. 3. Semantics of the parallel composition.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

71

3.2.2. Encapsulation 3.2.2.1. Basic ideas. Encapsulation is a unary operator parameterized by a set of signal names. It is used to restrict the scope of signals, and to force synchronization between parallel or hierarchic components. Typically, if a signal s is used as the output of a component P and as the input of a component Q, it may serve as a synchronization signal. This is the case for signals b, c and end of the counter in Section 2. The synchronization and communication mechanism is the synchronous broadcast (the same as in Esterel): the sender can always send, and it need not know whether 0, 1 or several other components are listening this signal. Sending is non-blocking. The main reason why we express the semantics of the synchronous broadcast only in the encapsulation operator is the following: it may serve for synchronizing parallel components, but also hierarchical components. If we partly integrate it in the semantics of the parallel composition, then we need to repeat it in the semantics of the hierarchic composition. 3.2.2.2. Observation of the example. The intuitive semantics of the example shows that the bit in which b is an input should react to this signal only if it comes from the previous bit. On the other hand, the signal b is emitted by the :rst bit in order to synchronize with the second one, and should not be visible elsewhere. In such a case, the scope of b can be restricted to the parallel composition of the :rst and second bits. In the example, it is in fact extended to the parallel composition of the three bits, but it does not appear in the third one, and it is simpler to use only one encapsulation operator for the two signals b and c. De:ning the scope of a signal by encapsulating a subprogram P, allows to simplify the transitions of P: encapsulation forces the synchronization between the components of P by removing some transitions of their product, like the restriction in CCS [26]. It is a bit more complex because of the input=output structure of the labels, and the Boolean structure of the inputs, but it is essentially the same idea. 3.2.2.3. Formal de@nition. De nition 5 (Encapsulation). \ : AM × 2AA → AM (S; s0 ; I; O; T ) \  = (S; s0 ; I \ ; O \ ; T
); where T
is de:ned by (s; m; o; s
) ∈ T ∧ m+ ∩  ⊆ o ∧ m− ∩  ∩ o = ∅ ⇒ (s; ∃:m; o \ ; s
) ∈ T
: m+ is the set of variables that appear as positive elements in the monomial m (i.e. m+ = {x ∈ AA | (x ∧ m) = m}). m− is the set of variables that appear as negative elements in the monomial m (i.e. m− = {x ∈ AA | (@x ∧ m) = m}). Intuitively, a transition (s; m; o; s
) ∈ T is still present in the result of the encapsulation operation if its label satis:es the local criterion: m+ ∩  ⊆ o, which means that a local signal which is supposed to be present has to be emitted in the same reaction; and m− ∩  ∩ o = ∅, which means that a local signal that is supposed to be absent should not be emitted in the same reaction.

72

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

If the label of a transition satis:es this criterion, then the names of the encapsulated signals are hidden, both in the input part and in the output part. This is expressed by ∃:m for the input part, and by o \  for the output part. The encapsulation operator can only remove some transitions in a complex object obtained, for instance, as the result of a parallel composition. Hence it is always true that each basic automaton component in a program participates in a global reaction by executing exactly one transition. The synchronization based on broadcasting signals does not give rise to in:nite behaviors, or lack of stability, etc. The synchrony hypothesis, stating that communication takes no time, is illustrated here: if we consider two programs P and Q, communicating with a signal a which is made local to their parallel composition, one transition in P that emits a, and one transition in Q that reacts to the presence a, make a single transition in the result. The parallel composition is completely compiled, and there is nothing like a communication at execution time. 3.2.2.4. Determinism and reactivity of an encapsulated process. The encapsulation operation does not preserve determinism nor reactivity. Intuitively, this is because the criterion used for ruling out some transitions of the encapsulated process, depending on their labels, is applied locally. Take a component P with two states A1 and A2 and four transitions (A1 ; i ∧ a=b; A2 ), (A1 ; iT ∧ a; A1 ), (A1 ; iT ∧ a; T A1 ), (A1 ; i ∧ a; T A1 ), and a component Q with two states B1 and B2 and four transitions T B1 ), (B1 ; iT ∧ b; T B1 ). (B1 ; i ∧ b=a; B2 ), (B1 ; iT ∧ b; B1 ), (B1 ; i ∧ b; Put these two components in parallel and make the signals a and b local to the result. For input i, from the composed state A1 B1 , there will be two distinct transitions left when applying the above criterion: (A1 B1 ; i; A2 B2 ) and (A1 B1 ; i; A1 B1 ). The :rst one is made of: the transition (A1 ; i ∧ a=b; A2 ) in P, and the transition (B1 ; i ∧ b=a; B2 ) in Q, which gives (A1 B1 ; i ∧ a ∧ b=a; b; A2 B2 ) in the product, before encapsulation; it passes the local criterion and then gives (A1 B1 ; i; A2 B2 ) when hiding a and T B1 ) in b. The second one is made of the transition (A1 ; i ∧ a; T A1 ) in P and the transition (B1 ; i ∧ b; T Q, which gives (A1 B1 ; i ∧ aT ∧ b=∅; A1 B1 ) in the product, before encapsulation. It also passes the local criterion, and then gives (A1 B1 ; i; A1 B1 ) when hiding a and b. The result is no longer deterministic, because of these two transitions. There are no other transitions left in the encapsulated program. Now, take the same component P, and a component Q with two states B1 and B2 and four T B2 ), (B1 ; i ∧ b; B1 ), (B1 ; iT ∧ b; B1 ), (B1 ; iT ∧ b; T B1 ). transitions (B1 ; i ∧ b=a; Put them in parallel and encapsulate the result with local signals a and b: in the resulting process, there is no transition sourced in A1 B1 for input i: the result is no longer reactive. These are the typical cases where non-determinism and non-reactivity appear. It may seem strange to write such pathological communications directly, in such simple systems. But this kind of situation may appear in very complex compositions of components, with any number of participants. 3.2.2.5. Alternative view of the semantics. Another way of expressing the semantics of the encapsulation operator is by giving a system of equations, of which the values of the encapsulated signals are a solution. This view gives some new hints for understanding why determinism and reactivity are not preserved. The idea is the following: for each state q of the process P, and each con:guration I of the inputs, there should be exactly one status of the encapsulated signals, i.e. one valuation of these

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

73

Fig. 4. Semantics of the encapsulation operation: we :rst apply the criterion of the encapsulation operation to the system obtained from the parallel composition in Fig. 3, and then we hide the local signal b.

signals, seen as Boolean variables. Knowing a con:guration of the inputs, and a status of the local signals, it is easy to determine the reaction of the system, by observing what transitions can indeed be taken. The status of the local signals is the solution of a set of equations that can be built as follows. For each local signal s, take the set of transitions sourced in q and emitting s (i.e. with a label of  the form: ci =S with s ∈ S) and build the equation: s = ci . In other words, s is true (emitted) if and only if at least one of the transitions of P that emits it can be :red. This expresses the fact that a local signal cannot come from outside P: it is present in a reaction of P only if P itself emits it. The important point is that the local signals may appear in the conditions ci . Hence the system of equations obtained by writing such an equation for each local signal is of the general form; in particular, it may contain cycles of dependencies, like a = b; b = a. When the system of equations has exactly one solution, it means that the reaction of the system to input I is unique. If this is the case for each state of P, then the encapsulated system is both deterministic and reactive. If, for a state q, the system of equations has more than one solution (resp. no solution at all) then the encapsulated process is no longer deterministic (resp. reactive). This is the case for processes that exhibit equations of the form a = b; b = a (several solutions) or a = b; b = aT (no solutions). The typical examples presented above give this kind of system: a = i ∧ b; b = i ∧ a, or a = i ∧ T b = i ∧ a. Since we are interested in the reaction of the system to input i, we replace i by true b; in these equations, and obtain the typical cases. 3.2.2.6. The two-bit example. Fig. 4 shows how to apply the encapsulation operator, for signal b, to the system we obtained in Fig. 3. 3.2.2.7. An example: the instantaneous dialogue. Observe the example of Figs. 5 and 6. It shows an instantaneous dialogue between the two parallel components. The intuitive behavior is the following: when in state A, the :rst component P1 needs to query the state of the second component P2 in order to choose its reaction to input i; if P2 is in state C, then P1 goes to B, otherwise it stays in A. (In Statecharts, this would be described by a condition of the form “i and in(C)” appearing in P1 . We explain in Section 4.4 below why we chose not to introduce such a construct in Argos.) In Argos, P1 reacts to I by emitting Q, which is a question to P2 . P2 reacts to this question by saying yes (Y ) if it is indeed in state C, and nothing if it is in another state, say D, or E. The answer and the question are simultaneous, thanks to the synchronous broadcast. Hence the

74

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

Fig. 5. The instantaneous dialogue in Esterel.

Fig. 6. The instantaneous dialogue with a parallel composition.

behavior of P1 , from state A, is described by: if I and Y , then emit the question Q and take the transition to B; if I and not Y , then emit the question Q and stay in A. This may seem strange, because there is no visible sequencing between the question and the answer, but the behavior of the global process, where both the question Q and the answer Y are local signals, is exactly what we want. This is because the status of Q and Y , when the system is in the global state AC, is given by the equations: Q = i ∧ Y ∨ i ∧ @Y ; Y = Q, which simpli:es to Q = Y = i. Hence for input i, both Q and Y are present, the global system takes the transition from A to B and the loop on C. Notice that, in Esterel, from which this example is borrowed, the notion of sequence inside a reaction allows a natural writing of the dialogue. The program in Fig. 5 is made of two parallel components. The :rst one emits the question Q when the cause I occurs. Then it checks whether the answer Y is present, for emitting the output S (we need something observable, like changing state in the Argos program). The second parallel component always answers Y when it receives the question Q (the answer could depend on some internal state, of course, as in the Argos example). await tick, meaning “wait until next instant” is necessary because the component every Q do emit Y does not emit Y if Q is present in the very :rst instant, but only after that. The parallel composition does nothing in the :rst instant, and then behaves as expected.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

75

In Section 3.2.4 below, we give another version of this program by using the Argos re:nement operator, which is more natural. In Esterel, there is even a third solution, in which P2 emits Y continuously, when in the appropriate state, not only when it receives the question Q. In this case P1 needs only test Y , without asking Q. 3.2.3. Inhibiting operator The inhibiting operator is useful for building some of the Statecharts or Esterel constructs from the set of Argos operators, in a structural way (see Section 3.3 below). P whennot a behaves as P, but only when a is not present. The interface of P whennot a has one more input signal. De nition 6 (Inhibition of a Boolean Mealy machine). whennot : AM × AA → AM ; (S; s0 ; I; O; T ) whennot a is de:ned i; a ∈ I and (S; s0 ; I; O; T ) whennot a = (S; s0 ; I ∪ {a}; O; T
); where T
is de:ned by (s; m; o; s
) ∈ T;

⇒ (s; m:a; T o; s
) ∈ T
∧ (s; m:a; ∅; s) ∈ T
:

3.2.4. Hierarchical composition The intuitive behavior of a re:ned process is the following: a transition that enters a re:ned state starts the re:ning process, in its initial state. A transition that leaves a re:ned state kills the re:ning process, and all information about the state it had reached is lost (this, in particular, forbids the “entry by history” of Statecharts). An important point is the following: the automaton that is re:ned is always active; when it is in state A, the process re:ning state A is also active. They behave as if they were put in parallel, as far as the communication between them is concerned. But, of course, a transition of the re:ned automaton may kill a re:ning process and start another one, which is not the case for parallel composition. Note that the encapsulation operator can be applied to the result of a hierarchic composition too, for synchronizing a controller with its re:ning processes. Finally, a re:ning process is alive during the reaction that kills it (leaving a re:ned state is a non-preemptive interrupt). Hence it may communicate (or synchronize) with the re:ned automaton. In particular, the transition of the automaton that leaves the state may be triggered by a signal emitted by the re:ning process itself. In this case, we say that the re:ning process commits suicide. We will see that this particular feature of Argos allows to encode outgoing multi-level arrows in an elegant and compositional way. This is the case in the introductory example for the signal end, which is emitted by the three-bit counter, and kills it. Conversely, in the example, the signal stop acts as an external interrupt, whatever the state of the three-bit counter is. On the contrary, the process that re:nes the target state of a transition occurring in the re:ned automaton is not alive during this reaction: it does not participate in the reaction that starts it. This forbids a number of interesting behaviors (choosing the actual initial state by an initial transition triggered by external signals, : : :) and the symmetrical encoding of ingoing multi-level arrows. We could modify the semantics of the re:nement operator in order to make it more symmetrical. However, the basic version we present here is simpler, because it does not give rise to the schizophrenia

76

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

problem of Esterel (see [27] for details). Roughly speaking, schizophrenia would occur for a loop on a re:ned state: the re:ning process is both killed and restarted in its initial state. In fact, two instances of it would be alive during the reaction, not necessarily in the same state. If the re:ning process contains local signals, they all have two instances during one reaction. With our asymmetrical semantics, schizophrenia cannot occur. The formal de:nition is based upon the operation denoted by ., that takes a machine for the controller and n machines for re:ning the n states of the controller. The machine that serves as the controller is not necessarily reactive. De nition 7 (Re@nement). . : AM × 2AM → AM : Let M denote (S; s0 ; I; O; T ), where S = {s0 ; s1 ; : : : ; sn }. Consider also a set {Mj }j=0:::n of machines, to be used as re:nements of the states of M , where Mj = (S j ; s0j ; I j ; Oj ; T j ), and S j = {s0j ; s1j ; : : : ; snjj }. The composed machine, in which each Mj re:nes the state sj , is of the form:

  M . {Mj }j=0:::n = S . {S j }J ; s0 . s00 ; I ∪ I j ; O ∪ O j ; T
: Its set of states is of the form j

S . {S }J =

n  j=0

{sj . skj ; k ∈ [0 : : : nj ]}

and its transitions T
are given by the following two rules: (1) A transition from sa to sb in the controller, together with a transition from ska to ska
in the machine that re:nes the current state. The outputs are gathered. In the global target state, the machine that re:nes state sb is started in its initial state, and the machine that re:nes state sa has been killed. Its internal state is no longer relevant: (sa ; m; o; sb ) ∈ T ∧ (ska ; m
; o
; ska
) ∈ T a ⇒ (sa . ska ; m ∧ m
; o ∪ o
; sb . s0b ) ∈ T
: (2) A transition of the machine that re:nes the current state, from ska to ska
, while no transition sourced in state sa is activated in the controller:      (ska ; m
; o
; ska
) ∈ T a ⇒ sa . ska ; m
∧  @m ; o
; sa . ska
 ∈ T
: (sa ; m;−;−)∈T

Fig. 7 illustrates the semantics of the hierarchical composition (or “re:nement”). Fig. 8 is a version of the instantaneous dialogue using re:nement. The transitions labeled by i=Q and by Y in the :rst component may be taken together, if the other component is in state C and indeed answers Y to the question Q. When the system is in state AX , the status of the local signals Q and Y is given by the equations: Q = i; Y = Q, which gives Q = Y = i as in the parallel version of Fig. 6, without the need for Boolean simpli:cation.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

77

Fig. 7. Re:nement: a simple example.

Fig. 8. Instantaneous dialogue, described with a re:nement.

3.3. Some useful combinations of operators 3.3.1. Temporized states The ability to attach delays to states was proposed in an early unpublished paper about Statecharts. In ARGOS, it is very easy to introduce such a construct and to give it a clear semantics; indeed, it can be introduced as a macro-notation. Following synchronous languages (Lustre, Esterel, Signal), ARGOS deals with multiform time. Any external input event can be used as a clock for the system, which may count meters as well as seconds. Fig. 9(a) shows a temporized state Tempo. The notation [d a] means that a delay d is associated with the state. d is a positive integer, and a is the name of an input signal, which gives the unit of time. The behavior of the system is as follows: when the system enters state Tempo, it can stay in this state at most until d occurrences of signal a have been counted; if it has not left the state when the last occurrence happens, the special transition denoted by a box (the time-out transition) is taken. Fig. 9(b) shows how the macro-notation is expanded: states are added to count the occurrences of a.

78

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

Fig. 9. Macro-notation for temporized states.

Fig. 10. The macro-notation for inhibiting transitions. The box with ' is the concrete syntax of the inhibiting operator.

All transitions that enter the temporized state output the starting signal start; all transitions that leave the state output the killing signal kill; the box transition is triggered by the time-out signal. The main point is the priority we choose between the killing transitions and the counting ones. In the expansion we give, an outgoing transition can be taken even if the last occurrence of a occurs at the same time (time-out is output only if kill does not occur). If we add variables to Argos (i.e. objects that exist “in parallel” with the Argos program, and that may be tested and assigned to during a reaction), the counter is described by a variable, which avoids explicit states. However, as far as veri:cation is concerned, we have to expand these variables into explicit states, for using model-checkers, if we want to verify properties in which time is involved. In [28] we showed how to translate Argos programs with temporized-states directly into timed-graphs [29] (without expanding the macro-notation into explicit states), in order to use the veri:cation tool Kronos [30]. Some examples using the Argos compiler connected to Kronos are described in [31,32]. 3.3.2. Inhibiting transitions When the automaton which controls a re:nement operation takes a transition, the subprogram which re:nes the source state always reacts at the instant when it is killed. When preemptive interruptions have to be described, one uses inhibiting transitions, which stand for inhibiting operators (see Fig. 10). The transition sourced in State 1 (Fig. 10(a)) outputs the signal which inhibits the re:ning subprogram P: it is a preemptive interruption; the macro-notation avoids the introduction of ' and uses a small black circle (Fig. 10(b)).

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

79

4. The Argos language and its semantics 4.1. Syntax From the set of operators described in the previous sections, we de:ne the core of the Argos language. AE is the set of programs: E : := EE Parallel composition | E

Encapsulation  ⊆ AA

| RM (R1 ; : : : ; Rn ) re:nement of M by the Ri | E  ( R : := E | NIL

Inhibition ( ∈ AA re:ning objects

The NIL notation is introduced to identify leaf states, i.e. the states that are not further re:ned. 4.2. Causality and incorrect compositions The term “causality” has been widely accepted, following the authors of Esterel, to talk about those situations when the strict interpretation of the synchrony hypothesis leads to apparent paradoxes. When a process that waits for signal a for emitting signal b, is talking to a process in parallel that waits for b for emitting a, the global behavior is not de:ned. This typical example, written in Argos, is given in Section 3.2.2 above. In Argos, we decide to characterize a causally incorrect composition of components (or program) by the fact that there exists an occurrence of an encapsulation operator which is applied to a reactive and deterministic component and yet yields a system which is either non-deterministic or non-reactive. These are the cases when non-determinism (or non-reactivity) appears, due to the application of the encapsulation semantics, based on the de:nition of the synchronous broadcast mechanism. Hence our notion of correction is the following: all basic components should be both deterministic and reactive, and all operators should be applied in such a way that they preserve these properties. We are convinced that the programs that will be rejected by our criterion indeed constitute programming errors. This notion of program correction is, in some sense, minimal, with respect to the synchronous broadcast mechanism; it is also called logical correctness. See Section 6.3 for comparisons with similar notions in other synchronous languages and Statecharts. Under these constraints, we can easily associate a >at Boolean Mealy machine to any Argos program, and this is indeed what we describe in the semantics below. Then this machine can easily be implemented by translation into any imperative programming language like C, Ada, Java, etc. Any other choice, i.e. accepting to take non-deterministic or non-reactive Boolean Mealy machines as the semantics of Argos programs, would be unimplementable. For non-reactivity, consider a state X , from which the transition for input i is missing: there is no consistent implementation. Notice that an implementation of the system that does nothing for input i when in state X is in fact an implementation of the system that does have a loop on state X , with input i, and no emitted signal. (In Section 3.2.2 above, we showed that it may be the case that even the loop does not exist.)

80

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

For non-determinism, there is no implementation, unless we consider that >ipping a coin at execution time, for choosing a transition, is an appropriate solution. However, we could :nd non-determinism useful, in a speci@cation language, especially for the partial description of the environment. In this case, we would allow the basic components to exhibit some explicit non-determinism (several transitions with non-exclusive input conditions, and distinct emitted signals and=or target states), but still require that the composition of two such components do not introduce non-determinism. This is what we argue in [33]. All these remarks lead to the notion of incorrect program in Argos. Incorrect programs should be detected, of course, by a compiler. In [34] we proposed an exact detection mechanism for causality errors, for Argos with pure signals; it gives a reasonable cost compilation algorithm. 4.3. Semantics Since there exist incorrect programs, the semantic function should be partial on AE. We make it total by adding the special value ⊥ to the codomain. The semantic function AS : AE → AM rd ∪ {⊥} is de:ned recursively by:  ⊥ if AS(E1 ) = ⊥ or AS(E2 ) = ⊥ AS(E1 E2 ) = AS(E1 ) × AS(E2 ) otherwise  ⊥ if ∃i ∈ [1; n] s:t: AS(Ri ) = ⊥ AS(RM d (R1 ; : : : ; Rn )) = M d . (AS(R1 ); : : : ; AS(Rn )) otherwise  ⊥ if AS(E) = ⊥  AS(E ) = otherwise : let X = AS(E) \  in if X ∈ AM rd then X else ⊥  ⊥ if AS(E) = ⊥  (  AS(E ) = AS(E) whennot ( otherwise AS(NIL) = ({NIL}; NIL; ∅; ∅; {(NIL; true; ∅; NIL)}) A program P is said to be incorrect if and only if AS(P) = ⊥. The errors are due to encapsulations that do not preserve reactivity or determinism. The ⊥ value is absorbant. 4.4. Compositionality From the de:nition of the equivalence for Boolean Mealy machines, we de:ne an equivalence of Argos programs, denoted by ≡. The main point here is that we are interested in compositionality for correct programs only. De nition 8 (Equivalence of Argos programs).  AS(P1 ) = ⊥ ∧ AS(P2 ) = ⊥ ∧ AS(P1 ) ≈ AS(P2 )∨ P1 ≡ P2 ⇔ AS(P1 ) = AS(P2 ) = ⊥: The semantics is compositional, which means that the equivalence of Argos programs is a congruence for the operators (parallel and hierarchic compositions, inhibition, encapsulation): ∀P; Q ∈ AP; ∀AC context

P ≡ Q ⇒ AC[P] ≡ AC[Q]:

It is easy to prove, by induction on the structure of processes (see [20]).

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

81

4.4.1. Remark Since we require the equivalence of Boolean Mealy machines to be a congruence for our operators, and since this equivalence does not take state information into account, we cannot use state information in the semantics of our constructs. Let us take an example: the equivalence de:ned above is in fact a kind of trace equivalence, which may identify two machines with di;erent sets of states, provided they have the same paths. For instance, the machine with two states A and B, and four transitions (A; a=x; B); (A; a; T A); (B; a=x; A); (B; a; T B) is equivalent to a machine with only one state C and two transitions (C; a=x; C); (C; a; T C). With our semantics, the :rst machine may be replaced by the second one (or the other way round) in any context, without changing the behavior of the global program in which that occurs. This forbids, in particular, to give a direct semantics to the Statechart feature in which one may write “a and in (A)” as a condition for a transition to be taken, where A is the name of a state, somewhere in a component of the program. Indeed, the component with state A could be replaced by an equivalent one with no state A. However, it is relatively easy to replace the syntactic feature “in(A)” by a communication based on exchanging a dedicated signal.

4.5. Introducing variables The Boolean core of Argos is now completely de:ned. We mentioned the need for variables or valued signals previously. Variables could serve as counters for avoiding explicit states, for instance in the encoding of temporized states. Valued signals are needed for representing the inputs and outputs of regulation systems, in which the computer samples continuous data, like the temperature. We never implemented a complete Argos with variables, but the ideas for introducing are quite simple, and we explain them brie>y here. 4.5.1. Boolean Mealy machines with variables In Argos, we can introduce variables by upgrading Boolean Mealy machines to general interpreted automata. We still have a set AA of pure signals, i.e. Booleans. An Argos component with variables is now of the following form: De nition 9 (Boolean Mealy machine with variables). A Mealy machine with variables is a tuple (S; s0 ; I; O; V; T ) where I ⊆ AA; O ⊆ AA are the sets of input and output signals; AV is the set of (potentially typed) variables used in this machine, taking their values in a domain AD; S is the set of states; s0 is the initial state; T ⊆ S × cond(V ) × AB(I ) × 2O × Assign(V ) × S is the set of transitions. As before, AB(I ) denotes the set of Boolean formulas with variables in I . cond(V ) is the set of Boolean conditions on V . For instance, if V contains an integer x and a Boolean b, “x ¡ 0 ∧ @b” is a possible condition.

82

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

Assign(V ) is the set of assignments to variables in V . For instance, with the same hypothesis as before, “{x := 2:7; b := false}” is a possible assignment. The elementary assignments are considered to be in parallel: there should not be two assignments to the same variable in the same set, but there is no order. The intuitive idea is that a transition (q; c; m; o; a; q
), where c is the condition on variables, m is a condition on Boolean inputs, o is the set of emitted signals, and a is an assignment, is taken if: the automaton is in q; m is true of the external inputs; and c is true in the current valuation + : V → AD of the variables. The automaton goes to state q
, emitting the signals in o, and the variables are updated according to + and a. This gives a new valuation +
. A lot of things become undecidable when variables are introduced (especially integers, with the power of full arithmetics. In fact, interpreted automata have the power of Turing machines: it is quite easy to convince oneself that they can be used as a target language for any high level programming language). For instance, it becomes impossible to check the determinism of the basic components, in the general case. There are several ways the problem can be solved: we can introduce a syntactic feature that allows to specify priorities between the transitions sourced in the same state. From the semantic point of view, this is like requiring the exclusivity of the conditions to be statically checkable, i.e. to have the following form: c1 ; c2 ∧ @C1 ; c3 ∧ @(c1 ∨ c2 ), etc. Similarly, reactivity is not checkable but, on each state A of the basic components, we can add a loop that emits nothing and leaves the variables unchanged, labeled by @ ∨ ci , where the ci are the conditions of all the explicitly given transitions sourced in A. If the automaton is already reactive, this condition reduces to false, and has no in>uence on the behavior. 4.5.2. Compositions of Boolean Mealy machines with variables We can rewrite the semantic rules, taking the valuations of variables into account. In the parallel composition, a combined transition is labeled by: the conjunction of the Boolean conditions on inputs (as before), the conjunction of the conditions on variables, the union of the emitted signals (as before), the union of the assignments. We declare an error if this results in assigning to a variable twice. Hence, if a variable is shared by n parallel components, one should be the producer (the one allowed to assign values to the variables) and all the others should be only consumers (allowed to read the variable). When we introduce variables, we should also introduce a unary operator to de:ne their scope. Such an operator may be parameterized by: the name of the variable, its type, and an initial value. If a variable is declared local to a process that re:nes the state A of an automaton, it is reinitialized each time state A is entered. 4.5.3. Extending the notion of incorrect program The main problem concerns the detection of so-called causality errors. Indeed, the mechanism we presented is based upon the existence of transitions for a given input, in the result of an encapsulation. When variables are introduced, it might be the case that a transition that remains in the result of an encapsulation is in fact not :rable, because of its condition on variables. Take, for instance, a component P with a transition labeled by (x ¡ 0) a=b and a component Q with a transition

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

83

labeled by (x ¿ 0) b. If we put them in parallel and encapsulate the signal b, we obtain a transition labeled by (x ¡ 0)∧(x ¿ 0) a, which is clearly non-:rable. Should we decide that there is no transition for input a, in the result of the encapsulation and, consequently, declare a case of non-reactivity? Let us call intrinsic correctness the notion of correctness based upon the existence of transitions, with the interpretation of conditions being taken into account. Even if we chose this new de:nition of correct programs for Argos with variables, we could not implement it: the problem is undecidable. We cannot compute statically the set of transitions that are indeed :rable. The general problem is even more complex because it may depend on the dynamics of the system: think of a transition labeled by X ¡ 0, sourced in a state that cannot be entered unless X ¿ 0. Since an exact detection mechanism cannot be de:ned, we should be able to de:ne an approximate one. There is a way of providing a conservative detection mechanism for both determinism and reactivity: we consider each condition on variables as a new Boolean input. A transition label of the form: C(x) m=o, where C(x) is an arbitrary Boolean condition on the variable x, is treated as '∧ m=o, where ' is a fresh signal name (not used elsewhere in the program). We can do that on all transitions of the basic components of a program. Of course, we lose a lot of information: x ¡ 0 and x ¿ 0 will be replaced by two independent Boolean variables (or signals). Then, we apply our static criterion to this new program. The criterion requires that there exist exactly one possible transition for each con:guration of the inputs (including the ones introduced for encoding the conditions). We may reject intrinsically correct programs, of course, because the detection mechanism may complain about non-determinism or non-reactivity appearing for a given input ' ∧ - ∧ : : :, where ' and - are new names introduced as explained before for representing conditions c1 and c2 , and c1 ∧ c2 is in fact not satis:able. But we cannot accept intrinsically incorrect programs. Hence we have a conservative detection mechanism. Moreover, we are convinced that it does not reject “too many” correct programs. This is a rather informal statement, but it means the following: the programs that are rejected, while being intrinsically correct, are those in which the correctness relies on some intricate mixing of Boolean Signals with other variables. Writing such programs is a questionnable practise, because the slightest modi:cation may transform an intrinsically correct program into an incorrect one, or conversely. 4.5.4. Valued signals If variables are available, a valued signal is simply a pair made of a pure signal that represents the presence of the signal, and a variable that contains its value. This is the approach of Esterel, which is particularly well suited for event systems. In Lustre, there is no notion of a pure signal: all inputs have values, of type int, or real, or bool. One can then o;er a speci:c syntax for designating the presence of a signal and its value. In Esterel, we would write x for the presence (hence present x then ... is correct) and x? for the associated value. (However, in Esterel, be careful not to confuse valued signals with variables).

84

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

5. Code generation and connection to analysis tools Argos programs may be compiled into a lot of automaton formats, used as input by veri:cation tools. For producing explicit automata, a compiler that mimics the de:nition of the operators would be far too expensive. Indeed, the intermediate objects obtained when expanding parallel compositions are likely to be far bigger than the :nal system obtained by applying encapsulation operators for all local signals. We use a top-down method, with BDDs [35] for solving the equations obtained for the encapsulation operations. This is described in [36]. The Argonaute environment based upon Argos (a graphical editor and simulator, plus a compiler) has been successfully connected to various veri:cation tools, among which: Aldebaran [37], Mec [38], Kronos [30 –32], Polka [39,40]. It is easy to obtain executable code from an explicit >at automaton corresponding to an Argos program; the typical form of such a sequential program is an in:nite loop: initialize the state while true get inputs (the values of the input signals) compute outputs, according to the values of the inputs and the current state emit outputs update the state Each pass in the loop corresponds to one transition of the global Mealy machine obtained by expanding the Argos program, hence it also corresponds to one reaction of this program. A reaction usually involves several components. For the synchrony hypothesis to be a usable approximation of the real world, the execution time of one pass in the loop should be less than the minimal amount of time between two relevant changes of the program environment. However, the compilation into an explicit automata is not always a good idea, since it produces code whose size is exponential in the size of the program (the parallel composition, in particular, produces an explosion of the number of states). For generating good sequential code, Argos is compiled into data->ow equations with activation conditions, using the DC format [41], also used as an intermediate form in the compilers of Lustre, Signal and Esterel [42]. DC can then be compiled into C. We also obtain a program with an in:nite loop like the one above, but the set of states is not given in extension. Rather, the state is the con:guration of a set of Boolean variables, which may be assigned to separately.

6. General comments and comparison with related work First, we summarize how to provide some of the missing Statecharts features as macro-notations in Argos. Then we compare Argos with three classes of Statecharts semantics. The way communication, synchronization and the associated “causality” problems are treated is somewhat independent of these three classes. We review the main choices in a separate section.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

85

Fig. 11. Suspension of P.

6.1. From Argos to Statecharts Outgoing multi-level arrows can be done thanks to an explicit communication between the re:ning process P and the automaton A it re:nes, since P participates in a reaction in which the state A is left. Ingoing multi-level arrows can be done with a similar mechanism if we modify the de:nition of re:nement in such a way that the process that re:nes a state participates in a reaction in which this state is entered. We did not present this extended version of the re:nement here, because it gives rise to schizophrenia problems. See [43] for an example of use. Special events like "entered(A)" can be implemented as macro-notations, with pre-processing: we introduce a new signal name, and add it to the set of emitted signals of all transitions that enter A. This has to be done carefully, because A may be the initial state in a re:ning process, and there is no explicitly drawn transition that enters it. But then the signal can be added to the set of emitted signals of the transition that starts this process. Similar things can be done for the special events "exit(A)" and "in(A)". Adding variables and valued signals has been described in Section 4.5. Entry by history cannot be done, at least as a simple macro-notation, because the de:nition of the re:nement is entirely based upon the fact that all information about a process re:ning a state is lost when we exit the state. However, if we look at systems in which entry by history is used, we understand that what we really need is a suspension mechanism. Suspension may be built in Argos with a simple combination of parallelism, inhibition and communication, as it is shown in Fig. 11. The interface signals are suspendP and resumeP. We may decide whether suspension has an immediate e;ect (i.e., P does not participate in the reaction that suspends it). In the :gure, this is the case, since the transition labeled by suspendP does indeed emit the signal ' which inhibits P. We should also take care of the simultaneous occurrence of suspendP and resumeP. This construction is quite satisfactory because, if we need entry by history in a process P, it means we need P to stay alive, until we need the information about its internal state again. Also, if it is still alive, it is intrinsically in parallel with another part of the program. In Argos, we use re:nement only when we need to start and kill processes, depending on a sequential structure described by an explicit automaton. In all situations where we need to keep some information on a process, even if it does not participate in the reactions for a while, we use the parallel composition.

86

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

6.2. Comparison with other Statecharts semantics As far as we know, the semantics that have been proposed so far for Statecharts or Statecharts variants 2 fall into three main categories. This classi:cation is somewhat biased, since we are mainly interested in the use of Statecharts as a programming language; the existence of a notion of equivalence—or congruence—is an important criterion. The set of references is by no means exhaustive: a quick world-wide-web search gives at least 150 references on Statecharts, and a thorough comparison of all the variants is not the subject of this article. In order to compare Argos and Statecharts, the following three classes are adequate: • Global semantics • Denotational and fully abstract semantics • Process Algebraic semantics, with equivalences or congruences They are detailed below. None of the variants we know of has been especially tailored for pure programming purposes, and this is a major di;erence with Argos. All of them are presented as speci@cation languages, that can be used in a veri:cation framework. Sometimes, an algorithm for generating code is provided but, in all cases, generating code implies taking a decision about the non-deterministic elements of the language. 6.2.1. Global semantics of Statecharts In this class, a Statechart is de:ned as an And=Or tree, with additional constraints on the structure of the tree. The semantics is described in terms of a large number of tree-manipulation functions, like the closest common ancestor of two nodes, etc. [44 – 46] and a lot of others fall into this category. There is no way to view a program as a composition of sub-programs, and there is no real “syntax”—or grammar, on which a syntax-directed semantics could be based. Therefore, a Statechart is viewed as a monolithic object, not as the composition of simpler objects, and compositionality makes no sense. Another consequence is that none of these semantics propose a notion of equivalence for Statecharts. The operationally-de:ned semantics like that of [47], which describes the algorithm of the interpreter, also falls into this class. 6.2.2. Denotational fully abstract semantics of Statecharts In this class, the language is given a syntax, and a syntax-directed semantics. When the full set of features of Statecharts is indeed taken into account (like the multi-level arrows in [48]), the combinators are quite complex, and sometimes far from “semantical” combinations. One need to build programs by composing basic objects that can be sets of states with dangling incoming or outgoing transitions, and it is hard to attach a meaning to these objects, in terms of reactive behaviors. In this class of semantics, the notion of compositionality relies on the full abstraction criterion. 2

We :nd semantics of Statecharts in a wide variety of papers, since the formalism has been used intensively in a number of very di;erent contexts. As soon as a translation of Statecharts into some formally de:ned language is provided, we can consider that a semantics of Statecharts is given.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

87

6.2.3. Process algebraic semantics of Statecharts In this class, the language is also given a syntax, in the spirit of process algebras: the classical non-deterministic choice (the “+” of CCS [26]) and the parallel operator are used [49 –51] and many others fall into this class. These semantics also need a notion of model for Statecharts, i.e. the mathematical de:nition of a reactive system behavior (usually a labeled transition system, or LTS). Giving an operational and process-algebraic semantics to Statecharts means providing a structural translation of Statecharts into a LTS. The main di;erences with Argos are the following. First, the construction of programs starts with the pre:x operator. Basic automata are built with the pre:x operator, the non-deterministic choice, and the recursion. Then, automata may be composed using the parallel operator, for instance. Multi-level transitions are often forbidden, for the same reasons as in Argos, but without explaining clearly how a similar behavior can be obtained with the features of the language. In fact, since the underlying semantics is not purely synchronous, there is no solution with a macro-notation, i.e. independent of the context in which it is needed. With this granularity in the de:nition of the basic components, these semantic frameworks also need to require well-guardedness (see the de:nition of this notion in CCS [26]) for avoiding in:nite branching. In Argos, we consider automata as the primitive objects, because it is easier to de:ne the determinism and reactivity criteria in such a framework. Hence we need no recursion operator. Second, Argos is a subset of Statecharts features, except on one point: we decided, from the very beginning, to de:ne an encapsulation operator, that allows to restrict the scope of signals. This has well-known renaming e;ects, which are necessary when describing large systems (think of a version of C without local variables, in which a team of 50 developers would have to decide who is allowed to use i as a loop index!). But this has also some advantages concerning the de:nition of the language itself: the encapsulation operator is the one that corresponds to the synchronization. As already mentioned, it is the same idea as in CCS. 6.3. Communication, synchronization and causality 6.3.1. Causality in other synchronous languages As we illustrated with the de:nition of encapsulation, the synchrony hypothesis means that the status of local signals, used for internal synchronization, should be uniquely determined in a global transition: it is given as the solution of a system of equations. The intrinsic paradoxes are related to the fact that the system of equations may have 0 or several solutions. This is called logical correctness. In Esterel, the notion of causally correct program is much stronger, because we do not only require that the system have a unique solution, but also that this solution be constructive (see [16] for a synthetic presentation of this idea: the system of equations has to be solved using constructive logic, i.e. without using a ∨ @a = 1). In Lustre, the data->ow declarative style of the language means that “programs” are similar to the set of equations we showed in Section 3.2.2 for explaining encapsulation. The static criterion used for ruling out non-causal programs is even stronger than in Esterel: the system of equations should be cycle-free. A cyclic system of equations, even if it has a unique solution, is rejected. It

88

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

may seem too strong a criterion, but there are very few cases in which we would like the criterion to be a little weaker (see examples, taken from circuit design, in [34,52]). 6.3.2. Notions related to causality in Statecharts To our knowledge, none of the semantics that have been proposed so far for Statecharts is purely synchronous, in the sense that: they are based upon the synchrony hypothesis, and there is a notion of incorrect program for ruling out the programs that rise the causality paradoxes intrinsic to the strict application of this hypothesis. By strict application of the synchrony hypothesis, we mean that a component that contains a transition labeled by a=b, in parallel with a component that contains a transition labeled by b, gives a single transition as a result, whatever the notion of “result” is. For process-algebraic semantics, this is the same notion as in Argos, since they are based on operations over LTS. For global semantics, this is also quite similar, because the operational semantics describes the possible global transitions of a Statechart. Another point of view on the same fact is the following: a=b in parallel with b giving a single transition in the parallel process means that the internal communication between the two components is atomic, with respect to what happens in the environment. This global transition is computed knowing the status of local signals used for internal synchronization, which should be uniquely determined. In Statecharts, there is no real notion of incorrect program: non-determinism is not considered harmful, and if a transition is missing (non-reactivity), the system simply does nothing. In general, there is no notion of local signal either, for which we could require a unique status. Hence the notions of causality are quite di;erent from the corresponding notions in synchronous languages. The very :rst semantics of Statecharts ([45] for instance) introduced the notion of “micro-step”, to talk about what happens inside a Statechart when it reacts to an external stimulus. There is a complementary notion of macro-step, intended to represent an atomic reaction of the system to its environment; a micro-step is usually a maximal sequence of micro-steps, in the sense that it cannot be extended: none of the currently active components can react to the signals that were present in the original external stimulus, or that were emitted by the already executed micro-steps. This raises new problems, because a maximal sequence does not necessarily exist in all cases; in general, it is not possible to determine statically whether all reactions to external inputs give :nite sequences of internal micro-steps. Moreover, in some of the so-called micro-step semantics, it is possible to take one micro-step assuming that a signal is absent and, later, to take another micro-step that emits the signal. This kind of problem led to a number of criteria like global consistency, for talking about those macro-steps that are logically correct, when observed globally. A good summary can be found in [23], where it is shown that no micro-step semantics can be responsive, causal, and modular. Responsiveness means that the outputs are simultaneous with the inputs (the synchrony hypothesis); modularity means that a component may be used in an overall context knowing its macro-step semantics only and forgetting about the details of its micro-steps (this is related to our compositionality criterion, with a notion of equivalence de:ned as having the same macro-steps); causality means that a macro-step cannot generate its own trigger (this is one half of our de:nition: it rules out programs of the form: a=b in parallel with b=a). The semantics of Statecharts entitled “what is in a step?” [44,53] is suJciently close to ours for the comparison to be meaningful: we did it in [54], where we proposed a general framework for

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

89

comparing synchronous communication mechanisms; the di;erences lie in the interpretation of the synchronous broadcast. For instance, the parallel version of the instantaneous dialogue (Fig. 6) would be correct in this version of Statecharts, but would give no behavior. The re:nement version of the dialogue works :ne, though. In our semantics, where these two programs are indeed equivalent, there cannot be such a semantical di;erence between them. 7. Conclusions We presented a set of operators for building a synchronous language based on explicit automata, with a syntax similar to that of Statecharts. The semantics is purely synchronous; it may be viewed as a simpli:cation of the Esterel semantics, adapted to a programming style where automata are given explicitly (in Esterel, the control structure of a program is made of loops, watchdogs, etc.). As it is, the set of operators we presented is not a language, because it lacks a lot of features of real programming languages, for instance valued (i.e. not only Boolean) signals, explicit variables of any type that can be tested and assigned during a reaction, etc. Moreover, the other synchronous languages allow to use calls to a host language like C, in which complex data structures may be de:ned. This should be the case for Argos too. In order to provide such features in a simple way, and also because we are convinced that complex systems cannot be described using only automata, we worked a lot on the combination of Argos with other synchronous languages (mainly Lustre and Esterel, which have quite distinct programming styles: Lustre is data->ow, while Esterel is imperative with control structures). See for instance [55]. We also worked on the Argos–Esterel combined language, but Charles Andr*e and his team (University of Nice, France) have de:ned the SyncCharts [56] formalism, which seems to be the way things should be done: the language inherits various preemption primitives from Esterel, the hierarchic program structure from Argos, and other interesting primitives from Grafcet [57], which may be given a readable and concise graphical semantics. More recently, Argos has given birth to Mode-Automata [58], a promising mixed-style language for the description of regulation systems and their running modes, that can be completely implemented on top of the Lustre both academic and commercial programming environments. A basic mode-automaton is an automaton with data->ow programs attached to states. The language re-uses the parallel and hierarchic constructs of Argos, although the basic objects are more similar to Moore machines than to Mealy machines. As in Argos, there are no multi-level arrows in the hierarchic composition, and the components at several levels of hierarchy may communicate with each other in order to achieve the multi-level transition behavior. Acknowledgements The authors wish to thank G. Berry, for numerous discussions and guidance during the de:nition of Argos; N. Halbwachs for the Lustre point of view; M. Jourdan for all her work on Argos (part of the compiler, the connection to Kronos, and the multi-language approach); and Ph. Schaar for his work on the graphical interface.

90

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

References [1] Caspi P, Halbwachs N, Pilaud D, Plaice J. LUSTRE, a declarative language for programming synchronous systems. Proceedings of the 14th Symposium on Principles of Programming Languages, Munich, 1987. [2] Halbwachs N, Caspi P, Raymond P, Pilaud D. The synchronous data>ow programming language lustre. Proceedings of the IEEE 1991;79(9):1305–20. [3] Berry G, Gonthier G. The Esterel synchronous programming language: design, semantics, implementation. Science Of Computer Programming 1992;19(2):87–152. [4] Guernic PL, Benveniste A, Bournai P, Gauthier T. Signal: a data >ow oriented language for signal processing. Technical Report, IRISA Report 246, IRISA, Rennes, France, 1985. [5] Harel D. Statecharts: a visual approach to complex systems. Science of Computer Programming 1987;8:231–75. [6] Harel D, Pnueli A. On the development of reactive systems. In: Logic and models of concurrent systems, NATO advanced study institute on logics and models for veri:cation and speci:cation of concurrent systems, vol. 13, NATO ASI Series F. Berlin: Springer, 1988. [7] Benveniste A, Berry G. Another look at real-time programming. Special Section of the Proceedings of the IEEE 79 (9). [8] Halbwachs N. Synchronous programming of reactive systems. Dordrecht: Kluwer Academic Publishers, 1993. [9] Nicollin X, Richier J, Sifakis J, Voiron J. ATP: an algebra for timed processes. IFIP Working Conference on Programming Concepts and Methods, Sea of Gallilee, Israel, 1990. [10] Saraswat VA. Concurrent constraint programming. ACM Doctoral Dissertation Awards: Logic Programming. Cambridge, MA: The MIT Press, 1993. [11] Jahanian F, Mok A. Modechart, a speci:cation language for real time systems. IEEE Transactions on Software Engineering 1994;20(12):933–47. [12] Puchol C, Mok AK, Stuart DA. Compiling modechart speci:cations. Technical Report CS-TR-95-38, University of Texas, Austin, October 1, 1995. URL ftp:==ftp.cs.utexas.edu=pub=techreports=tr95-38.ps.Z. [13] Shaw AC. Reasoning about time in higher-level language software, IEEE Transactions on Software Engineering 1989;15(7):875 –89. [14] Girault A, Caspi P. An algorithm for distributing a :nite transition system on a shared=distributed memory system. Proceedings of the PARLE’92, Paris, 1992. [15] Caspi P, Mazuet C, Salem R, Weber D. Formal design of distributed control systems with lustre. Proceedings of the Safecomp’99, 1999. [16] Berry G. The foundations of esterel. In: Plotkin G, Stirling C, Tofte M, editors. Proof, language and interaction: essays in Honour of Robin Milner, MIT Press, 2000. [17] Halbwachs N, Lagnier F, Ratel C. Programming and verifying critical systems by means of the synchronous data->ow programming language LUSTRE. IEEE Transactions on Software Engineering (Special Issue on the Speci:cation and Analysis of Real-Time Systems) 1992;18(9):785–93. [18] Raymond P, Weber D, Nicollin X, Halbwachs N. Automatic testing of reactive systems. Proceedings of the 19th IEEE Real-Time Systems Symposium, Madrid, Spain, 1998. [19] Maraninchi F. The argos language: graphical representation of automata and description of reactive systems. IEEE Workshop on Visual Languages, Kobe, Japan, 1991. [20] Maraninchi F. Operational and compositional semantics of synchronous automaton compositions. Proceedings of the CONCUR. Lecture Notes in Computer Science, vol. 630. Berlin: Springer, 1992. [21] Harel D. On visual formalisms. Proceedings of the CACM 31. [22] Beeck Michael von der. A comparison of statecharts variants. In: Langmaack H, de Roever WP, Vytopil J, editors. Formal techniques in real-time and fault-tolerant systems (FTRTFT), LXubeck, Germany, Lecture Notes in Computer Science, vol. 863. Berlin: Springer, 1994. p. 128– 48. [23] Huizing C. Semantics of reactive systems: comparison and full abstraction. Ph.D. thesis, Eindhoven University, 1991. [24] Park D. Concurrency and automata on in:nite sequences. In: Theoretical Computer Science, Proceedings of the Fifth GI-Conference, Karlsruhe, Lecture Notes in Computer Science, vol. 104. Berlin: Springer, 1981. p. 167–83. [25] Milner R. Communication and concurrency. In: International series in computer science. Englewood Cli;s, NJ: Prentice-Hall, 1989.

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

91

[26] Milner R. A calculus of communication systems. Lecture Notes in Computer Science, vol. 92. Berlin: Springer, 1980. [27] Berry G. The constructive semantics of Esterel. Draft book, current version 3.0, July 2, 1999, 2000. URL ftp:==ftp.esterel.org=esterel=pub=papers=constructiveness3.ps. [28] Jourdan M, Maraninchi F, Olivero A. Verifying quantitative real-time properties of synchronous programs. In: International Conference on Computer-Aided Veri:cation, Elounda. Lecture Notes in Computer Science, vol. 697. Berlin: Springer, 1993. [29] Alur R, Dill D. Automata for modeling real-time systems. In: Paterson M. editor. Proceedings of ICALP 90. Berlin: Springer, 1990. p. 322–35. [30] Daws C, Olivero A, Tripakis S, Yovine S. The tool KRONOS. In: Hybrid systems III, veri:cation and control, Lecture Notes in Computer Science, vol. 1066. Springer, 1996. p. 208–19. [31] Simon D, Kapellos K, Espiau B, Jourdan M. Formal veri:cation of robotic missions and tasks. European Workshop on Hybrid Systems, Grenoble, 1995. [32] Jourdan M. Integrating formal veri:cation methods of quantitative real-time properties into a development environment for robot controllers. AMAST Workshop on Real-time Systems, 1996. [33] Maraninchi F, Halbwachs N. Compositional semantics of non-deterministic synchronous languages. In: European Symposium On Programming, Linkoping, Sweden, Lecture Notes in Computer Science, vol. 1058. Berlin: Springer, 1996. [34] Halbwachs N, Maraninchi F. On the symbolic analysis of combinational loops in circuits and synchronous programs. EUROMICRO, Como, Italy, 1995. [35] Bryant RE. Graph-based algorithms for boolean function manipulation. IEEE Transactions on Computers 1986; C-35(8):677–91. [36] Maraninchi F, Vachon M. An experience in compiling a mixed imperative=declarative language for reactive systems. In: International Workshop on Compiler Construction (poster session), Lecture Notes in Computer Science, vol. 641. Berlin: Springer, 1992. [37] Fernandez J-C. An implementation of an eJcient algorithm for bisimulation equivalence. Science of Computer Programming, 1990;13(2–3):219–36. [38] Arnold A, B*egay D, Crubill*e P. Construction and analysis of transition systems with MEC. Singapore: World Scienti:c Publishing, 1994. [39] Halbwachs N, Proy Y, Roumano; P. Veri:cation of real-time systems using linear relation analysis. Formal Methods in System Design 1997;11(2):157–85. [40] Halbwachs N, Maraninchi F, Proy YE. The railroad crossing problem, modeling with hybrid argos—analysis with polka. Second European Workshop on Real-Time and Hybrid Systems, Grenoble, France, 1995. [41] C2A-SYNCHRON, The common format of synchronous languages—the declarative code DC version 1.0. Technical Report, SYNCHRON Project, October 1995. [42] Maraninchi F, Halbwachs N. Compiling ARGOS into boolean equations. In: Formal techniques for real-time and fault tolerance (FTRTFT), Uppsala, Sweden, Lecture Notes in Computer Science, vol. 1135. Berlin: Springer, 1996. [43] Jourdan M, Maraninchi F. A modular state=transition approach for programming real-time systems. ACM Sigplan Workshop on Language, Compiler and Tool Support for Real-Time Systems, ACM Sigplan Notices, Orlando, FL, 1994. [44] Pnueli A, Shalev M. What is in a step: on the semantics of statecharts. In: Symposium on Theoretical Aspects of Computer Software (STACS), Lecture Notes in Computer Science, vol. 526. Berlin: Springer, 1991. [45] Harel D, Pnueli A, Schmidt J, Sherman R. On the formal semantics of statecharts. In: Symposium on Logic in Computer Science, Lecture Notes in Control and Information Science. Berlin: Springer, 1986. p. 54 – 64. [46] Maggiolo-Schettini A, Tini S. Projectable semantics for statecharts. Proceedings of the MFCS Workshop on Concurrency, Electronic Notes in Theoretical Computer Science 18, 1998. [47] Harel D, Naamad A. The STATEMATE semantics of statecharts. ACM Transactions on Software Engineering and Methodology 1996;5 (4):293–333. URL http:==www.acm.org=pubs=articles=journals=tosem= 1996-5-4=p293-harel=p293-harel.pdf. [48] Huizing C, Gerth R, deRoever WP. Modeling statecharts behavior in a fully abstract way. In: Proceedings on the Colloquium on Trees in Algebra and Programming, Lecture Notes in Computer Science, vol. 299. Berlin: Springer, 1988. p. 271–94.

92

F. Maraninchi, Y. R+emond / Computer Languages 27 (2001) 61–92

[49] Uselton A, Smolka S. A process algebraic semantics for statecharts via state re:nement. IFIP Working Conference on Programming Concepts, Methods and Calculi. San Miniato, Italy: Elsevier Science Publishers, 1994. [50] Uselton AC, Smolka SA. A compositional semantics for statecharts using labeled transition systems. In: Jonsson B, Parrow J. editors. CONCUR ’94: Concurrency Theory, Proceedings of the Fifth International Conference, Uppsala, Sweden. Lecture Notes in Computer Science, vol. 836. Berlin: Springer. 1994. p. 2–17. [51] Maggiolo-Schettini A, Peron A, Tini S. Equivalences of statecharts. In: Montanari U, Sassone V. editors. CONCUR ’96: Concurrency Theory, Proceedings of the Seventh International Conference, Pisa, Italy. Lecture Notes in Computer Science, vol. 1119. Berlin: Springer, 1996. p. 687–702. [52] Shiple T, Berry G, Touati H. Constructive analysis of cyclic circuits. International Design and Testing Conference IDTC’96, Paris, France, 1996. [53] Pnueli A, Shalev M. What is in a step. Tech. rep., Dept. of Applied Mathematics and Computer Science. The Weizmann Institute of Science, Israel, May 1988. [54] Jourdan M, Maraninchi F. Studying synchronous communication mechanisms by abstractions, IFIP Working Conference on Programming Concepts, Methods and Calculi. San Miniato, Italy: Elsevier Science Publishers, 1994. [55] Jourdan M, Lagnier F, Maraninchi F, Raymond P. A multiparadigm language for reactive systems, In Fifth IEEE International Conference on Computer Languages. Toulouse: IEEE Computer Society Press, 1994. [56] Andr*e C. Representation and analysis of reactive behaviors: a synchronous approach. IEEE-SMC’96, Computational Engineering in Systems Applications, Lille, France, 1996. [57] Blanchard M. Comprendre, Maitriser et Appliquer le Grafcet, Toulouse, Cepadues Editions, France: 1979. [58] Maraninchi F, R*emond Y. Mode-automata: about modes and states for reactive systems. In: European Symposium On Programming, Lisbon, Portugal, Lecture Notes in Computer Science, vol. 1381. Berlin: Springer, 1998. Florence Maraninchi is a graduate of the University Joseph Fourier, Grenoble I, in Computer Science (1987). She received a PhD in Computer Science in 1990, and an “habilitation aY diriger des recherches” in 1997, from the same University. She has been an assistant professor (Maˆ[tre de conf*erences) at the University Joseph Fourier from 1990 to 1999. She is now a Professor at the Institut National Polytechnique de Grenoble (INPG=ENSIMAG). Her research interests are mainly in the design, programming and validation of real-time embedded software, using domain-speci:c languages. She teaches algorithmics and programming languages, compilation techniques, formal veri:cation, synchronous languages, object-oriented modeling and analysis, low-level software and circuit design, database, etc. Yann R.emond is a graduate of the University Joseph Fourier, Grenoble I, in Computer Science (1988). He is now working on a PhD in Computer Science, entitled: “Mode-Automata: a Proposal for Describing Running-Modes of Real-Time Systems in a Data>ow Language”.