Florence Maraninchi

Mode-automata: a new domain-specific construct for the development of safe critical systems

Over the past ten years, the family of synchronous languages (Special Section of the Proc. IEEE 79 (9) (1991)) has been very successful in offering domain-specific, formally defined languages and programming environments for safety-critical systems. Among them, Lustre is well-suited for the development of regulation systems, which are first designed by control engineers, and can then be programmed as block-diagrams. Automatic generation of C code provides the embedded software.The success of Lustre showed that it is a good idea to offer domain-specific languages and constructs to reduce the gap between the first design of a system (for instance a control law) and the program written for it. When the structure of the first design has to be encoded into the available constructs of a general-purpose programming language, the interesting information is likely to be lost somewhere on the way from the original design to the actual implementation. This may have consequences on the efficiency of the code produced, or even on the correctness of the design.Working with the systems Lustre is well-suited for, we observed that they are often specified informally using the notion of running modes. However, there seemed to exist no language in which the mode-structure of a complex system could be expressed directly. Following the approach of domain-specific languages, we proposed to extend Lustre with a new construct, called mode-automaton, devoted to the description of these running modes of regulation systems.In this paper, we define the language of mode-automata and its semantics, give some ideas on the compilation process, illustrate the approach with the example of the production cell, and comment on the benefits of the approach, in general.

Argos: an automaton-based synchronous language

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 definition of Argos, and the main differences with Statecharts and their numerous semantics. We define 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 definition and implementation of Argos (code generation, connection to verification tools, introduction of non-determinism, etc.). This paper also gives a set of guidelines for building an automaton-based, Statechart-like, yet perfectly synchronous, language.

Mode-Automata: About Modes and States for Reactive Systems

In the field of reactive system programming, dataflow synchronous languages like Lustre [BCH+85,CHPP87] or Signal [GBBG85] offer a syntax similar to block-diagrams, and can be efficiently compiled into C code, for instance. Designing a system that clearly exhibits several “independent” running modes is not difficult since the mode structure can be encoded explicitly with the available dataflow constructs. However the mode structure is no longer readable in the resulting program; modifying it is error prone, and it cannot be used to improve the quality of the generated code.

Using controller-synthesis techniques to build property-enforcing layers

In complex systems, like robot plants, applications are built on top of a set of components, or devices. Each of them has particular individual constraints, and there are also logical constraints on their interactions, related to e.g., mechanical characteristics or access to shared resources. Managing these constraints may be separated from the application, and performed by an intermediate layer. n nWe show how to build such property-enforcing layers, in a mixed imperative/ declarative style: 1) the constraints intrinsic to one component are modeled by an automaton; the product of these automata is a first approximation of the set of constraints that should be respected; 2) the constraints that involve several components are expressed as temporal logic properties of this product; 3) we use general controller synthesis techniques and tools in order to combine the set of communicating parallel automata with the global constraint.

Aspect-oriented programming for reactive systems: Larissa, a proposal in the synchronous framework

Aspect-oriented programming (AOP) has emerged recently as a language concept for expressing cross-cutting concerns, mainly in object-oriented software. Since then, the concept has been applied to a wide variety of other contexts. In this paper, we explore some cross-cutting concerns tbr parallel programs of reactive systems: we propose an aspect language, Larissa, and a weaving mechanism, in a core language based on parallel communicating Mealy machines.

42: programmable models of computation for a component-based approach to heterogeneous embedded systems

Every notion of a component for the development of embedded systems has to take heterogeneity into account: components may be hardware or software or OS, synchronous or asynchronous, deterministic or not, detailed w.r.t. time or not, detailed w.r.t. data or not, etc. A lot of approaches, following Ptolemy, propose to define several Models of Computation and Communication (MoCCs) to deal with heterogeneity, and a framework in which they can be combined hierarchically.n This paper presents the very first design of a component model for embedded systems called 42. We aim at expressing fine-grain timing aspects and several types of concurrency as MoCCs, but we require that all the MoCCs be programmed in terms of more basic primitives. 42 is meant to be an abstract description level, intended to be translated into an existing language (e.g., Lustre) for execution and property validation purposes.

System-level modeling of energy in TLM for early validation of power and thermal management

Modern systems-on-a-chip are equipped with power architectures, allowing to control the consumption of individual components or subsystems. These mechanisms are controlled by a power-management policy often implemented in the embedded software, with hardware support. Todays circuits have an important static power consumption, whose low-power design require techniques like DVFS or power-gating. A correct and efficient management of these mechanisms is therefore becoming non-trivial. Validating the effect of the power management policy needs to be done very early in the design cycle, as part of the architecture exploration activity. High-level models of the hardware must be annotated with consumption information. Temperature must also be taken into account since leakage current increases exponentially with it. Existing annotation techniques applied to loosely-timed or temporally-decoupled models would create bad simulation artifacts on the temperature profile (e.g. unrealistic peaks). This paper addresses the instrumentation of a timed transaction-level model of the hardware with information on the power consumption of the individual components. It can cope not only with power-state models, but also with Joule-per-bit traffic models, and avoids simulation artifacts when used in a functional/power/temperature co-simulation.

Full simulation coverage for SystemC transaction-level models of systems-on-a-chip

Transaction-Level Models (TLM) are used for the early validation of embedded software. Axa0TL model is a virtual prototype of the hardware part of a System-on-a-Chip (SoC). When using SystemC for transaction level modeling, the main parallel entities of the hardware platform (processors, DMAs, bus arbiters, etc.) are modeled by asynchronous processes, which are scheduled at simulation time. The specification of this scheduling mechanism is non-deterministic; the set of all possible schedulings of the parallel activities represents the physical parallelism faithfully. Moreover TL models may contain loose timing annotations (intervals for instance), and the set of all possible values of time in these intervals is also meant to represent the hardware behaviors faithfully.However, any simulation engine is built on a deterministic scheduler, and at runtime will use specific values in the time intervals. This means that only a very small subset of all the possible schedulings and timings are exhibited during simulation. Some bugs may be missed if they are due to some behaviors of the hardware that are represented by other schedulings or timings.For a given finite test scenario, the set of valid schedulings and timings of a model is finite, but far too large to be explored fully. We present a solution to cover the set of schedulings and timings efficiently. Our solution is based on dynamic partial order reduction and constraint solving techniques. It gives a complete scheduling and timing set, which guarantees the detection of all local errors and deadlocks for a fixed test scenario.

SystemC/TLM semantics for heterogeneous system-on-chip validation

SystemC has become a de facto standard for the system-level description of systems-on-a-chip. SystemC/TLM is a library dedicated to transaction level modeling. It allows to define a virtual prototype of a hardware platform, on which the embedded software can be tested. Applying formal validation techniques to SystemC descriptions of SoCs requires that the semantics of the language be formalized. The model of time and concurrency underlying the SystemC definition is intermediate between pure synchrony and pure asynchrony. We list the available solutions for the semantics of SystemC/TLM, and explain how to connect SystemC to existing formal validation tools.

Contract-Based Coordination of Hardware Components for the Development of Embedded Software

Embedded software is intrinsically concurrent, because an embedded system has several computing units. The way the software pieces communicate and synchronize depends on the hardware architecture. If the architecture is regular and fixed, there often exists a programming model that allows software developers to use it. If the architecture is ad hoc, heterogeneous, or changing, such a programming model does not exist, and the software developer has to be provided with a sufficient view of the hardware behavior. We propose a notion of contract associated with a component-based description framework, to help defining such views. The contracts are used to describe and simulate the potentially complex behaviors of the hardware execution platform, but only the situations the embedded software should be aware of. In some sense, the semantics of concurrency between the software pieces is given by the structure of the hardware platform, the interface it exposes to the software, and its contract behavior.