Because of Esterel's textual nature (as opposed to graphical) and compositional facilities, it is relatively easy to write compact specifications for systems with very complex state machines. A system with thousands of states can generally be specified by an Esterel program of only a few hundred lines.

Esterel-invented by G. Berry in INRIA, France-belongs to a family of formal specification languages specialized for reactive systems; other members of this family include StateCharts, Lustre, Signal, and SL. More information about Esterel and its history can be found at http://www-sop.inria.fr/meije/esterel/esterel-eng.html. A variety of tools for compilation, code generation, simulation, theorem proving, and automata visualization are also available there.

Reactive systems

A reactive system is one that is in continuous interaction with its environment. Most real-time, embedded systems are reactive. In addition, operating systems, networking protocols, VLSI chips, and even a graphical user interface can be considered partly reactive.

The behavior of a reactive system can be thought of as a black box that continuously receives some input events and reacts by producing some output events (Figure 1). This output may in turn affect the production of later input events by the environment.

The task of specifying the behavior of a reactive system is akin to that of specifying relationships between the input and output events. However, such a task is complicated by the fact that several input events may happen simultaneously and that after the system receives an input event, it may take a finite nonzero amount of time to produce its response in the form of an output event. We can visualize the trace of the life of a reactive system as a series of overlapping reaction intervals; each reaction interval begins when the system receives an input event and ends when it generates the corresponding output event (Figure 2).

Synchrony hypothesis

To simplify the behavioral specifications of reactive systems, Esterel makes an assumption called the synchrony hypothesis. The synchrony hypothesis says that the underlying machine is infinitely fast and, hence, the reaction of the system to an input event is instantaneous. As a consequence, the reaction intervals are reduced to reaction instants; therefore, the reactions do not overlap with each other. This assumption is also called the hypothesis of atomic reactions. The system is then active only at each instant. "In between" the instants, it is idle and awaiting input events.

At first glance, the synchrony hypothesis may seem unrealistic; however, it considerably simplifies the specifications of reactive systems and is suitable for a large number of application areas. In practice, what is needed is that the machine react to an input event before the next input event arrives.

Esterel allows multiple input events to arrive simultaneously. The reaction instant of Esterel is completed only when the system reacts to all of them; that is, the reaction to all the presently available input events constitutes the reaction instant.

Determinism

Esterel also assumes that the systems are deterministic. Informally, a non-deterministic system does not have a unique response to a given input event; instead, it chooses its response to the input event from a set of possible responses and an external observer has no way to consistently predict the response that will be chosen by the system. For example, suppose an elevator is currently at the third floor of a building and people on both the first and fifth floors simultaneously press the request button. If the relevant behavior of the elevator controller is specified nondeterministically, the response of the system will be either UP or DOWN movement without any guaranteed way for the users to predict it. Non-determinism corresponds to unlimited parallelism and not to any stochastic behavior. Automata theory defines non-determinism more rigorously.

All Esterel statements and constructs are guaranteed to be deterministic. There is no way to introduce any nondeterministic behavior in an Esterel program. The Esterel compiler checks the given program and ensures that it is deterministic. This assumption of determinism greatly simplifies the behavioral specifications.

Parallelism

Esterel provides the operator || for a parallel composition of its programs. If P1 and P2 are two Esterel programs then P1 || P2 is also an Esterel program, with the following characteristics:

• All inputs received from the environment are available to both P1 and P2.
• All outputs generated by P1 (or P2) are available in the same instant to P2 (or P1).
• Both P1 and P2 continue execution in parallel and the statement P1 || P2 terminates when both P1 and P2 terminate.
• No data or variables can be shared by P1 and P2.

Modules

A module in Esterel defines a (reusable) unit of behavior. A module is somewhat like a subroutine with its own local data and behavior. However, modules are quite different from subroutines in the manner of their usage. There is no "module call" facility in Esterel. A module is used like a macro in C; using a module simply means an inline substitution of its entire text at the place of "call." There are other significant differences between a module and a subroutine. For example, no global data is shared by modules, recursive module definitions are not possible, and so on.

A module has an interface and a body defining the behavior. Following is the Esterel syntax to define a module.

% this is a line comment
module module-name :
declarations and compiler directives
% signals, local variables etc.
body
. % end of module body

Each module can be thought of as an independent Esterel program and Esterel provides several constructs to combine modules to build larger reactive systems. In fact, an Esterel program is typically an interconnected network of modules.

Esterel does not have any notion of global data or global memory shared by all modules. However, each module can define its local data in terms of variables. Each Esterel statement has associated with it a precise definition about its duration in number of instants; for example, emit terminates instantly and await terminates only when the signal waited for becomes available.

A reactive system reacts to its input events by producing output events. In general, a reactive system needs to interact with its environment; component subsystems of a reactive system also interact with each other. Esterel provides a simple logical concept called a signal to model many such events and interactions. A signal is a logical unit of information exchange and interaction; its formal meaning is much like its everyday meaning. Examples include START, STOP, HOUR, ALARM, LIFT_ARRIVED, BUTTON_PRESSED, and so on. Names of signals in Esterel are conventionally written in capital letters. Esterel provides different kinds of signals.

Classification attributes for a signal:

• Visibility: interface signal vs. local signal
• Information contained in a signal: pure signal vs. valued signal
• Accessibility of interface signals: input, output, inputoutput, sensor

Consider an Esterel module M. The module M can exchange information with its external world or it may need to exchange information within its parts (or sub-modules) executing in parallel. A signal that is exchanged between a module M and its external environment is called an interface signal. An interface signal is available for all parts and sub-modules of M due to the instantaneous signal broadcast mechanism in Esterel. For modularity reasons, a module M can use signals that are purely local to M and its parts and sub-modules and are hidden from the external environment of M. Such a signal is called a local signal of module M.

A pure signal does not carry any information within it; only its presence or absence can be detected by the system. Thus a pure signal is typeless. A valued signal is a typed signal and carries a value whenever it is emitted; the type of a valued signal indicates the kinds of values that the signal can carry.

A module needs to declare its interface to the external world in terms of input signals, output signals, inputoutput signals, and sensors; also, each such interface signal can be pure or valued.

An input signal for a module can only be "read" by the module; the module cannot generate (or emit) such a signal. An output signal for a module can be generated by the module; the module cannot "read" such a signal. Clearly, an input signal for a module can be an output signal for another module and vice versa. An inputoutput signal for a module is one that can be both emitted as well as read by the module. Typically, such a signal is used only for those signals which the system receives from the environment and sends back to the environment after some filtering or processing.

A sensor is a special kind of signal that is "read only" and always assumed to be available in every instant; it cannot be waited for nor can it be emitted by any module. A sensor can only be read by accessing its value. Thus a sensor cannot be a part of an occurrence.

An important concept about signals is that of an occurrence. An occurrence simply refers to one or more happenings of a signal. To deal with an occurrence of the form N S, where N is an expression that evaluates to a positive integer and S is an input (or inputoutput) signal, the Esterel system checks for the presence of the signal S in successive instants and increments the internal counter whenever S is present; the occurrence is complete in the instant when the internal counter reaches the value N. Thus an occurrence has a positive duration (in the number of instants).

Occurrences are used in most of the temporal statements in Esterel; for example, the await statement. In later versions of Esterel, the definition of an occurrence is somewhat expanded and made more flexible; for example, logical connectives like and, or, and not allow us to describe logical combinations of signals. For example, the occurrence 3 STOP is complete when the Esterel system counts the presence of three STOP signals (once in each instant). Note that the STOP signals need not be present in consecutive instants. Thus the duration of this occurrence is at least three instants.

An Esterel program can wait for, read, generate, and check for the presence of a signal. In this sense, a signal is like a message; however, these two concepts differ in some significant ways.

A module can wait for an input or inputoutput signal to occur using the await statement. A module can check for the presence (or absence) of an input signal or an inputoutput signal using the present statement. A module can access (or read) the value of a valued input signal, a valued inputoutput signal, or a valued sensor using the ? construct. A module can broadcast an output signal or an inputoutput signal using the emit statement. These operations on signals are explained later.

Instantaneous broadcast

Esterel incorporates an instantaneous broadcast mechanism for signal reception and transmission. This means that a signal cannot have any destination specified; all signals are broadcast and any module may listen to and read an emitted signal. Also, signals do not have any unique identifier.

In Esterel, signals are emitted and used much like bus signals in a hardware interconnection bus (Figure 3). Any signal emitted makes a "wire" for that signal come alive with the information contained in that signal. Any module (including the module that emitted the signal) can tap this wire and read the emitted signal. Thus, no copies are made of an emitted signal. After the current reaction instant is over, the "bus" is "reset" (that is, cleared of all previous signals) and waits for any further input signals to be put on the wire by the environment. That is, the signals are available only in the current instant. The system's reaction to those input signals starts the next reaction instant.

The bus analogy is useful to illustrate another important fact about Esterel signals. A signal S emitted by a module M at a reaction instant t is made available to all other modules in the same reaction instant t. The emission of signal S constitutes part of the input event at t and the reaction instant t is not completed until some module reacts to the presently available signal S. Thus an input event at an instant consists of all input signals received from the environment as well as all signals emitted by the system as a part of its reaction at that current instant. Such a composite mixture of input and output signals available at any instant is called an event in Esterel. The input signals within an event constitute an input event. The output signals within an event constitute an output event; thus, an event is a composite of an input and output event.

In summary, all input signals received from the environment (as well as all signals generated by the system as part of its behavior) are available to all modules in the same reaction instant.

Esterel does not have facilities to directly refer to the past or future occurrences of signals. An Esterel program is memory-less in this sense; however, variables can be used to store historical information. Also, Esterel has no facility to refer to any of the past or future instants.

A simple vending machine

We shall begin our exploration of the world of reactive programming with the celebrated example of a vending machine. We shall start with a very simplified version of a vending machine. The vending machine can serve either tea or coffee. The user has to insert a coin and then press either the TEA or COFFEE button, after which the system delivers the requested drink. Listing 1 depicts a specification of VM1.

Listing 1: A simple vending machine

module VM1 :
input            COIN, TEA, COFFEE;
output            SERVE_TEA, SERVE_COFFEE;
relation            COIN # TEA # COFFEE;
loop
        await COIN;
        await
            case TEA do emit SERVE_TEA;
            case COFFEE do emit SERVE_COFFEE;
        end await;
end loop;

The code consists of only one module called VM1. The interface of this module consists of three input signals (COIN, TEA, and COFFEE) and two output signals (SERVE_TEA and SERVE_COFFEE). The presence of the input signal COIN signifies the insertion of a coin in the slot. The presence of the input signal TEA (or COFFEE) signifies the pressing of the TEA (or COFFEE) button. The machine indicates its readiness to serve tea (or coffee) by emitting to the environment the output signal SERVE_TEA (or SERVE_COFFEE). Notice that we are not interested (at this level of abstraction) in a number of details of the machine's operations, for example, the actual mechanism of the delivery of tea or coffee. All our input and output signals are then purely logical signals, intended to represent the behavior of the environment or the system, and as such, do not have anything to do with the technology of switches, sensors, and such used to receive and generate them.

The relation directive is used to describe restrictions on the possible combinations of the input signals present in an instant. The relation directive has the form:

relation Master-signal-name => Slave-signal-name;

and indicates that in any instant where the input signal having the name Master-signal-name is present, the input signal having the name Slave-signal-name should also be present.

Esterel has another kind of relation directive, which is used to declare signals that are pair-wise incompatible. This directive has the form:

relation Signal-name₁ # Signal-name₂ # ... # Signal-name_n;

and states that in any instant, at most one of the n input signals Signal-name₁, Signal-name₂, ... , Signal-namen may be present; that is, no two or more of these n input signals can be simultaneously present in any instant. Use of the relation directive reduces the size of the automaton generated from an Esterel specification. The relation directive in Listing 1 indicates that in any instant, at most one of the three input signals COIN, TEA, and COFFEE may be present.