Section: Scientific Foundations
Scientific Foundations
Embedded systems are not new, but their pervasive introduction in ordinarylife objects (cars, telephone, home appliances) brought a new focus onto design methods for such systems. New development techniques are needed to meet the challenges of productivity in a competitive environment. Synchronous languages rely on the synchronous hypothesis , which lets computations and behaviors be divided into a discrete sequence of computation steps which are equivalently called reactions or execution instants . In itself this assumption is rather common in practical embedded system design.
But the synchronous hypothesis adds to this the fact that, inside each instant , the behavioral propagation is wellbehaved (causal), so that the status of every signal or variable is established and defined prior to being tested or used. This criterion, which may be seen at first as an isolated technical requirement, is in fact the key point of the approach. It ensures strong semantic soundness by allowing universally recognized mathematical models to be used as supporting foundations. In turn, these models give access to a large corpus of efficient optimization, compilation, and formal verification techniques. The synchronous hypothesis also guarantees full equivalence between various levels of representation, thereby avoiding altogether the pitfalls of nonsynthesizability of other similar formalisms. In that sense the synchronous hypothesis is, in our view, a major contribution to the goal of modelbased design of embedded systems.
We shall describe the synchronous hypothesis and its mathematical background, together with a range of design techniques enpowered by the approach. Declarative formalisms implementing the synchronous hypothesis can be cast into a model of computation [9] consisting of a domain of traces or behaviors and of semilattice structure that renders the synchronous hypothesis using a timing equivalence relation: clock equivalence. Asynchrony can be superimposed on this model by considering a flow equivalence relation as well as heterogeneous systems [29] by parameterizing composition with arbitrary timing relations.
A synchronous model of computation
We consider a partiallyordered set of tags t to denote instants seen as symbolic periods in time during which a reaction takes place. The relation t_{1}t_{2} says that t_{1} occurs before t_{2} . Its minimum is noted 0. A totally ordered set of tags C is called a chain and denotes the sampling of a possibly continuous or dense signal over a countable series of causally related tags. Events, signals, behaviors and processes are defined as follows:

an event e is a pair consisting of a value v and a tag t,

a signal s is a function from a chain of tags to a set of values,

a behavior b is a function from a set of names x to signals,

a process p is a set of behaviors that have the same domain.
In the remainder, we write t a g s (s) for the tags of a signal s, v a r s (b) for the domains of b, b_{X} for the projection of a behavior b on a set of names X and b/X for its complementary.
Figure 1 depicts a behavior b over three signals named x, y and z. Two frames depict timing domains formalized by chains of tags. Signals x and y belong to the same timing domain: x is a downsampling of y. Its events are synchronous to odd occurrences of events along y and share the same tags, e.g. t_{1} . Even tags of y, e.g. t_{2} , are ordered along its chain, e.g. t_{1}<t_{2} , but absent from x. Signal z belongs to a different timing domain. Its tags, e.g. t_{3} are not ordered with respect to the chain of y, e.g. t_{1}¬t_{3} and t_{3}¬t_{1} .
Composition
Synchronous composition is noted p   q and defined by the union bc of all behaviors b (from p) and c (from q) which hold the same values at the same tags b_{I} = c_{I} for all signal xI = v a r s (b) v a r s (c) they share. Figure 2 depicts the synchronous composition (Figure 2 , right) of the behaviors b (Figure 2 , left) and the behavior c (Figure 2 , middle). The signal y, shared by b and c, carries the same tags and the same values in both b and c. Hence, bc defines the synchronous composition of b and c.
Scheduling
A scheduling structure is defined to schedule the occurrence of events along signals during an instant t. A scheduling is a preorder relation between dates x_{t} where t represents the time and x the location of the event. Figure 3 depicts such a relation superimposed to the signals x and y of Figure 1 . The relation y_{t1}x_{t1} , for instance, requires y to be calculated before x at the instant t_{1} . Naturally, scheduling is contained in time: if then for any x and b and if then .
Structure
A synchronous structure is defined by a semilattice structure to denote behaviors that have the same timing structure. The intuition behind this relation is depicted in Figure 4 . It is to consider a signal as an elastic with ordered marks on it (tags). If the elastic is stretched, marks remain in the same relative (partial) order but have more space (time) between each other. The same holds for a set of elastics: a behavior. If elastics are equally stretched, the order between marks is unchanged.
In Figure 4 , the time scale of x and y changes but the partial timing and scheduling relations are preserved. Stretching is a partialorder relation which defines clock equivalence. Formally, a behavior c is a stretching of b of same domain, written bc , iff there exists an increasing bijection on tags f that preserves the timing and scheduling relations. If so, c is the image of b by f. Last, the behaviors b and c are said clockequivalent , written , iff there exists a behavior d s.t. db and dc .
A declarative design languages
Signal [5] is a declarative design language expressed within the polychronous model of computation. In Signal, a process P is an infinite loop that consists of the synchronous composition P   Q of simultaneous equations x = yfz over signals named x, y, z . The restriction of a signal name x to a process P is noted P/x .
Equations x = yfz in Signal more generally denote processes that define timing relations between input and output signals. There are four primitive combinators in Signal:

delay , initially defines the signal x by the value v and then by the previous value of the signal y. The signal y and its delayed copy are synchronous: they share the same set of tags . Initially, at t_{1} , the signal x takes the declared value v and then, at tag t_{n} , the value of y at tag t_{n1} .

sampling x = ywhenz , defines x by y when z is true (and both y and z are present); x is present with the value v_{2} at t_{2} only if y is present with v_{2} at t_{2} and if z is present at t_{2} with the value true. When this is the case, one needs to schedule the calculation of y and z before x, as depicted by .

merge x = ydefaultz , defines x by y when y is present and by z otherwise. If y is absent and z present with v_{1} at t_{1} then x holds (t_{1}, v_{1}) . If y is present (at t_{2} or t_{3} ) then x holds its value whether z is present (at t_{2} ) or not (at t_{3} ).
The structuring element of a Signal specification is a process. A process accepts input signals originating from possibly different clock domains to produce output signals when needed. This allows, for instance, to specify a counter where the inputs tick and reset and the output value have independent clocks. The body of counter consists of one equation that defines the output signal value . Upon the event reset , it sets the count to 0. Otherwise, upon a tick event, it increments the count by referring to the previous value of value and adding 1 to it. Otherwise, if the count is solicited in the context of the counter process (meaning that its clock is active), the counter just returns the previous count without having to obtain a value from the tick and reset signals.
process counter = (? event tick, reset ! integer value)
( value := (0 when reset)
default ((value$ init 0 + 1) when tick)
default (value$ init 0)
);
A Signal process is a structuring element akin to a hierarchical block diagram. A process may structurally contain subprocesses. A process is a generic structuring element that can be specialized to the timing context of its call. For instance, the definition of a synchronized counter starting from the previous specification consists of its refinement with synchronization. The input tick and reset clocks expected by the process counter are sampled from the boolean input signals tick and reset by using the when tick and when reset expressions. The count is then synchronized to the inputs by the equation reset ^= tick ^= count .
process synccounter = (? boolean tick, reset ! integer value)
( value := counter (when tick, when reset)
 reset ^= tick ^= value
);
Compilation of Signal
Sequential code generation starting from a Signal specification starts with an analysis of its implicit synchronization and scheduling relations. This analysis yields the control and data flow graphs that define the class of sequentially executable specifications and allow to generate code.
Synchronization and scheduling specifications
In Signal, the clock of a signal x denotes the set of instants at which the signal x is present. It is represented by a signal that is true when x is present and that is absent otherwise. Clock expressions represent control. The clock whenx (resp. notx ) represents the time tags at which a boolean signal x is present and true (resp. false).
The empty clock is written 0 and clocks expressions e combined using conjunction, disjunction and symmetric difference. Clocks equations E are Signal processes: the equation synchronizes the clocks e and while specifies the containment of e in . Explicit scheduling relations xywhene allow to schedule the calculation of signals (e.g. x after y at the clock e).
Synchronization and scheduling analysis
A Signal process P corresponds to a system of clock and scheduling relations E that denotes its timing structure. It can be defined by induction on the structure of P using the inference system P:E of Figure 5 .
Hierarchization
The clock and scheduling relations E of a process P define the controlflow and dataflow graphs that hold all necessary information to compile a Signal specification upon satisfaction of the property of endochrony . A process is said endochronous iff, given a set of input signals and flowequivalent input behaviors, it has the capability to reconstruct a unique synchronous behavior up to clockequivalence: the input and output signals are ordered in clockequivalent ways.
To determine the order in which signals are processed during the period of a reaction, clock relations E play an essential role. The process of determining this order is called hierarchization and consists of an insertion algorithm which hooks elementary control flow graphs (in the form of ifthenelse structures) one to the others. Figure 6 , right, let h3 be a clock computed using h1 and h2. Let h be the head of a tree from which h1 and h2 are computed (an ifthenelse), h3 is computed after h1 and h2 and placed under h.
Example
The implications of hierarchization for code generation can be outlined by considering the specification of a oneplace buffer in Signal. Process buffer implements two functionalities. One is the process alternate which desynchronizes the signals i and o by synchronizing them to the true and false values of an alternating boolean signal b .
process buffer = (? i ! o)
( alternate (i, o)
 o := current (i)
)
where
process alternate = (? i, o ! )
( zb := b$1 init true
 b := not zb
 o ^= when not b
 i ^= when b
) / b, zb;
process current = (? i ! o)
( zo := i cell ^o init false
 o := zo when ^o
) / zo;
end;
The other functionality is the process current . It defines a cell in which values are stored at the input clock ^i and loaded at the output clock ^o . cell is a predefined Signal operation defined by:
Clock inference applies the clock inference system of Figure 5 to the process buffer to determine three synchronization classes. We observe that b, c_b, zb, zo are synchronous and define the master clock synchronization class of buffer .
( c_b ^= b
 b ^= zb
 zb ^= zo
 c_i := when b
 c_i ^= i
 c_o := when not b
 c_o ^= o
 i > zo when ^i
 zb > b
 zo > o when ^o
) / zb, zo, c_b, c_o, c_i, b;
There are two other synchronization classes, c_i and c_o , that corresponds to the true and false values of the boolean flipflop variable b , respectively:
This defines three nodes in the controlflow graph of the generated code. At the main clock c_b , b and c_o are calculated from zb . At the subclock b , the input signal i is read. At the subclock c_o the output signal o is written. Finally, zb is determined. Notice that the sequence of instructions follows the scheduling relations determined during clock inference.
buffer_iterate () {
b = !zb;
c_o = !b;
if (b) {
if (!r_buffer_i(&i))
return FALSE;
};
if (c_o) {
o = i;
w_buffer_o(o);
};
zb = b;
return TRUE;
}
Whereas Signal uses a hierarchization algorithm to find a sequential execution path starting from a system of clock relations, Lustre leaves this task to engineers, which must provide a wellsynchronized program: wellsynchronized Lustre programs correspond to hierarchized Signal specifications.
Certification
The simplicity of the singleclocked model of Lustre eases program analysis and code generation and its commercial implementation, Scade by Esterel Technologies, provides a certified C code generator. Its combination to Sildex, the commercial implementation of Signal by TNIValiosys, as a frontend for architecture mapping and early requirement specification is the methodology advocated in the IST project Safeair (URL: http://www.safeair.org ). The formal validation and certification of synchronous program properties has been the subject of numerous studies. In [40] , a coinductive axiomatization of Signal in the proof assistant Coq [35] , based on the calculus of constructions [46] , is proposed.
The application of this model is twofolds. It allows, first of all, for the exhaustive verification of formal properties of infinitestate systems. Two case studies have been developed. In [37] , a faithful model of the steamboiler problem was given in Signal and its properties proved with Signal's Coq model. It is applied to proving the correctness of realtime properties of a protocol for loosely timetriggered architectures, extending previous work proving the correctness of its finitestate approximation [36] .
Another and important application of modeling Signal in the proof assistant Coq is being explored and consists of developing a reference compiler translating Signal programs into Coq assertion. This translation allows to represent model transformations performed by the Signal compiler as correctness preserving transformations of Coq assertions, yielding a costly yet correctbyconstruction synthesis of target code.
Other approaches to the certification of generated code have been investigated. In [41] , validation is achieved by checking a model of the C code generated by the Signal compiler in the theorem prover PVS with respect to a model of its source specification: translation validation.