HAL Id: hal-00784474
https://hal.inria.fr/hal-00784474
Submitted on 4 Feb 2013
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
A Domain-Specic Language for Multitask Systems,
Applying Discrete Controller Synthesis
Gwenaël Delaval, Eric Rutten
To cite this version:
Gwenaël Delaval, Eric Rutten. A Domain-Specic Language for Multitask Systems, Applying Dis-
crete Controller Synthesis. EURASIP Journal on Embedded Systems, SpringerOpen, 2007, 2007 (1),
pp.084192. �hal-00784474�
Hindawi Publishing Corporation
EURASIP Journal on Embedded Systems
Volume 2007, Article ID 84192,
17 pages
doi:10.1155/2007/84192
Research Article
A Domain-Specific Language for Multitask Systems,
Applying Discrete Controller Synthesis
Gwena
¨
el Delaval
1
and
´
Eric Rutten
2
1
INRIA Rh
ˆ
one-Alpes, 38334 Saint Ismier Cedex, France
2
Laboratoire d’Informatique Fondamentale de Lille, INRIA Futurs, 59655 Villeneuve d’Ascq C
´
edex, France
Received 30 June 2006; Revised 15 December 2006; Accepted 3 January 2007
Recommended by S. Ramesh
We propose a simple programming language, called Nemo, specific to the domain of multitask real-time control systems, such
as in robotic, automotive, or avionics systems. It can be used to specify a set of resources with usage constraints, a set of tasks
that consume them according to various modes, and applications sequencing the tasks. We automatically obtain an application-
specific task handler that correctly manages the constraints (if there exists one), through a compilation-like process including
a phase of discrete controller synthesis. This way, this formal technique contributes to the safety of the designed systems, while
being encapsulated in a tool that makes it usable by application experts. Our approach is based on the synchronous modelling
techniques, languages, and tools.
Copyright © 2007 G. Delaval and
´
E. Rutten. This is an open access article distributed under the Creative Commons Attribution
License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly
cited.
1. CONTEXT AND MOTIVATION
1.1. Embedded control systems
Embedded control systems are implementing automatic con-
trol laws or signal processing, such as in robotic, automotive,
or avionics systems, or even more widely available portable
devices processing voice and image signals. These systems
are reactive, working in close interaction with their environ-
ment, including the controlled process which has its own dy-
namics (typically, following the laws of physics), imposing
real-time management. Their global behavior results from
this very interaction.
They are typically designed in terms of continuous mod-
els, and then implemented in a discretized form, as a cyclic
computation upon sensor input data, producing extracted
information, or control values towards actuators. This com-
bination of computations and resource usage (sensors, pro-
cessors, memory, power, actuators) defines a level of abstrac-
tionwhichwecallatask.
For a complex system, with a number of different re-
sources and meant to fulfill a variety of functionalities, sev-
eral control modes or phases can be designed, and the switch-
ing between them has to be handled and controlled properly
[
1]. This can be intricate and the risk of errors is important,
because of the complexity of systems and of requirements,
particularly with respect to constraints on resource usage and
interaction with the environment. Task handlers can be seen
as property-enforcing layers [
2]. Instances of systems struc-
tured this way can be found in robotics, for example, in robot
programming environments like Orccad [3]. Programming
languages for such purposes typically combine data flow and
sequencing [4–7]. The same kind of abstraction level, consid-
ering the control of tasks independently of the encapsulated
computation, is considered in the reactive language Electre
[8].
We address the difficulty of designing such complex con-
trollers safely by proposing a method applying safe design
techniques to the domain of embedded control systems.
1.2. Safety-critical systems
These systems are in interaction with their environment, in
such a way that malfunction can lead to disastrous conse-
quences, be it material, financial, or human. Hence, their de-
sign has to be safe, so that they are fully validated before op-
eration.
Formal methods and verification are a way to design safety-
critical systems with an explicit care for their validation. The
design is based on models of requirements, architectures,
2 EURASIP Journal on Embedded Systems
properties to be satisfied. A common practice consists of
building up a specification, and then using formal verifi-
cation techniques (e.g., model checking of temporal logic
properties on a transition system-based abstraction of the
system) to assess whether given properties are satisfied or
not. In the latter case, when a bug is detected, the verification
technique can give indications or a diagnosis on its origin,
and the designer has to go back to the design and modify it,
and verify again.
Such techniques are considered difficult to use, amongst
other things because of the competence required in formal
techniques. Much effort is devoted to make them more user-
friendly, because they are to be applied by engineers special-
ized in the systems under design. A general notion of invisi-
ble formal methods advocates for fully automated techniques,
integrated into a design process and tools. Approaches exist
in methods for correctness by construction [9], where com-
ponents assembly preserves essential properties like deadlock
freedom.
Some programming languages have compilers integrating
verification, for example, the synchronous languages for re-
active systems [
10–12] check for each program whether static
properties are satisfied, regarding the coherence of event syn-
chronizations. Explorations of dynamical behaviors in the
reachable state space, integrated in the compilation [13, 26]
is applied less currently, for example, for optimization pur-
poses with respect to dead code [
14], or interface computa-
tions [15].
For the control systems that we consider, what has to be
verified is the correctness of the controller handling of tasks
and resources. We propose to use a formal technique, tar-
geted at the level of these controllers, integrated in a user-
friendly design framework.
1.3. Control of reactive multitasks systems
1.3.1. Robotics systems as multitasks systems
A common approach in the design of robotics systems is the
discrete/continuous control approach. This framework divides
a system in two separate layers:
(i) the continuous control layer is a set of purely computa-
tional tasks, each one implementing a specific atomic
action on the system (e.g., control laws for a specific
move);
(ii) the discrete control layer is dedicated to the schedule of
these computational tasks.
The Orccad tool [
3], for instance, implements this ap-
proach. Within this tool, the tasks of the automatic con-
trol layer, named robot tasks, can be described as a dataflow
graph of algorithmic modules, implemented with a general-
purpose programming language. To each task corresponds
a single automaton managing starting, termination, and ex-
ceptions. The discrete control layer is then described ei-
ther by means of the synchronous reactive language Esterel
[
16], either with MaestRo [17], a domain-specific language
designed as a front end for Orccad . MaestRo features
imperative sequencing constructs, applied to the defined ro-
bot tasks. Its compilation generates a controller in Esterel ,
which interacts with the tasks’ automata. The behavior of this
controller is therefore fully defined, and its temporal proper-
ties can be checked by the use of a model-checking tool.
1.3.2. Automated synthesis of task handlers
Discrete controller synthesis [
19] can be defined in the frame-
work of formal languages, or finite state automata or tran-
sition systems. It consists of, given a property as objective,
computing the constraint (i.e., the controller) on transitions,
if there exists one, such that the resulting constrained (i.e.,
controlled) behavior satisfies the property. It can be defined
on algorithmic bases similar to those for model checking. It
differsfromverificationinthatitismoreconstructive,and
proposes a solution.
1
The technique has been studied and
implemented in the synchronous framework [
20].
It has been applied to the modelling and control of multi-
task systems [9, 21–23], where the set of tasks is modelled as a
transition system, and a controller has to be found that han-
dles the preservation of constraints regarding the resources
and sequencing. It can then be seen as the automatic genera-
tion of a property-enforcing layer [2] for a given system, or of
an application-specific scheduler [
24].
Our aim is to adapt these models and applications of dis-
crete controller synthesis to multitask control systems, in a
way such that it is encapsulated into a simple domain-specific
language, and an automatic generation framework.
1.4. Our approach
We propose a domain-specific language, called Nemo , whose
compilation encapsulates controller synthesis for multitask
systems. Its constructs describe domain-specific notions of
resources and their constraints, tasks and their control, par-
ticular ordering constraints to be enforced, and applications
built upon them. It is defined in terms of transition sys-
tems, temporal properties, and synthesis objectives. We pro-
duce, through a compilation-like process including a phase
of discrete controller synthesis (i.e., automatically), a correct
application-specific task handler that satisfies the constraints
(if there exists one). This way, this formal technique con-
tributes to the safety of the designed systems, while being en-
capsulated in a tool that makes it usable by programmers. We
use synchronous languages, modelling techniques and tools,
particularly the Mode Automata language [
6] and the Sigali
synthesis tool [20].
Our contribution is in the proposal of this language, and
the “hidden” use of discrete controller synthesis in its compi-
lation cycle. We used for that only existing discrete controller
synthesis tools, in a fairly basic way. This article shows the
complete definition and implementation of this language,
whose basic principle have been exposed in [25].
In the remainder of this paper,
Section 2 exposes mo-
tivations for the language’s constructs. Section 3 gives an
1
“Verification is autopsy”[18].
G. Delaval and
´
E. Rutten 3
req stop
Application
req stop req stop
Ta sk Ta sk
Control law Control law
Discrete
time
Ta sk
ctrl
Ta sk
ctrl
start end stop start end stop
Control
layer
Computation
layer
Continuous
time
Physical
world
act sens act
Figure 1: Control system composed of computations encapsulated
intotasks,toppedwithanapplication.
informal overview of this language.
Section 4 gives a detailed
description of all the language constructs, with associated
transitions systems and synthesis objectives: preliminary def-
initions are given in
Section 4.1. Section 4.2 describes how
tasks are modelled, followed by resources in Section 4.3.
Section 4.4 describestemporalpropertiesandSection 4.5 de-
scribes applications. In Section 5, the implementation using
synchronous tools is presented, and performance aspects are
discussed. Section 6 illustrates the approach with an exam-
ple. Section 7 concludes.
2. DOMAIN SPECIFICITIES
This section gives motivations for the language constructs in
terms of the targeted class of systems.
2.1. Computations, tasks, applications
We consider control systems composed of two layers, as ex-
posed in
Section 1.3.1.
(i) The computation layer performs data transformation
algorithms, for example, numerical computations, in
an infinite loop. Such computation can be imple-
mented in another general language (e.g., as C code),
and, as shown in the lower part of
Figure 1, has basic
control points:
(a) it can be started, which can involve initializations;
(b) it can notify that it has reached its end, that is, that
it is ready to stop: for example, a control law that
has reached its objective within a given precision
range (it may yet continue controlling the actua-
tor around the objective);
(c) it can be stopped;
(d) it can be suspended, that is, it ceases computation
and interaction, until it is resumed.
(ii) The control layer manages these computations’ starts
and stops, by encapsulating them into tasks,eachpro-
vided with a local controller. As shown in the middle
part of
Figure 1, this controller makes the relation be-
tween requests and starts, and between ends and stops:
as will be discussed below, several variants may make
sense. A task can also involve several modes of activity,
where the computation is different, as well as the re-
sources engaged.
These tasks can then be composed into applications,
using structures such as loops, sequences, or parallel
statements, in order to define a partial control over
execution of tasks. As shown in the upper part of
Figure 1, an application can be requested, and send
in turn, according to its control structure, requests
to underlying tasks. It can also eventually stop. Such
applications correspond to the control layer, defined
with the MaestRo language within Orccad [
17]; but
while a MaestRo program entirely defines the behav-
ior of this control layer, applications in Nemo will de-
fine some control points to be constrained by means of
discrete controller synthesis.
This whole control layer is a discrete event system, we
see it as a synchronous reactive system [
12].
2.2. Resources
Such computations are related to resources:
(i) for their computation: typically processors, memories,
communication links;
(ii) and in the embedded system: typically sensors and ac-
tuators.
These resources involve constraints which are implicit prop-
erties such as:
(i) exclusivity,
(ii) bounds on the number of users,
(iii) bounds on the available capacity,
(iv) the need to be always under control.
Within a task, modes can correspond to several differ-
ent configurations with respect to resource consumption, for
example, with choices between time and memory consump-
tion, degraded modes with lower quality level but also lower
consumption.
The application of discrete controller synthesis defines a
sequence of tasks by constructing a global controller that in-
teracts with the tasks’ local controllers by mean of control-
lable points. This global controller’s aim is to preserve the
properties of the resources.
2.3. The points to be controlled
We will describe here different possible articulations between
ends, stops, requests, and starts, which will motivate the
constructs of the Nemo language presented further. They
correspond to different kinds of computations that can be
seen in applications.
4 EURASIP Journal on Embedded Systems
2.3.1. Controlling the termination of a computation
As we said, the end reports that some termination condition
has been reached, the stop being the actual termination of the
computation. Controlling the termination of a computation
involves relating stops and ends.
Stop coming before end
Some computations may be stopped without having yet
reached their complete termination: for example, anytime
algorithms, characterized by an incremental construction
where each intermediary result can be delivered as a result,
be it of intermediary quality. Such tasks can hence be inter-
rupted before having reached an end: their stop can be trig-
gered.
Stop coming after end
Some computations reach their objective, and they can con-
tinue cyclically in order to maintain it: an example is a con-
trol law, always giving the correction to be applied by actua-
tors in order to near the objective. When the latter is reached,
continuing will just maintain the situation. This can be useful
and even necessary, for example, in Orccad [
3], the “robot
tasks” encapsulating a control law have a “transition phase”
when the task is finished, but the next task is not yet started.
The task executes then a “degraded mode” until the start of
the next task, thus allowing the operation of actuators that
have to be always under control. Such tasks can hence be sus-
tained beyond their end: their end can be rejected, the stop
will occur at a later occurrence of the end, or delayed: the
stop occurs at a later point, even without reoccurrence of the
end.
2.3.2. Controlling the beginning of a computation
As for the termination, controlling the beginning of a com-
putation involves relating requests and starts.
Start coming after request
When a request is made for a task, it might not be started,
typically because of a resource not being available yet. Then,
the request may be memorized for later treatment, or not.
The request can be rejected: the start will occur at a later oc-
currence of the request, or delayed: the start occurs at a later
point, even without occurrence of the request.
Start coming without request
Some computations may be called without an explicit re-
quest, for example, default control tasks for an actuator that
must always be under control: their start can be triggered.
2.3.3. Controlling the modes during a computation
Modes are different ways to achieve the functionality of a
task, which vary in the resources they consume, the time
Declarative part Imperative part
Resolution
Resources
Te m p o r a l
constraints Tasks Applications
Complete controller
Figure 2: Compilation of Nemo .
they take, the quality of service they achieve. For example,
on an architecture composed of two processors P
1
and P
2
,
some tasks can be executed on either P
1
or P
2
.So,wecansay
that this task is composed of two modes, each of them cor-
responding to the execution of the task on a given processor.
Another example is a computation that can be performed by
several algorithms, each of them using different amounts of
the available resources.
Switching modes can have the effect of, for example, re-
lease parts of a bounded resource for other tasks to be able
to begin, to switch to a better quality and more costly mode,
or unlocking a task waiting upon an exclusive resource. The
mode switches are part of the points controllable by the con-
troller to be synthesized.
3. OVERVIEW OF THE LANGUAGE
This section gives an informal overview of the Nemo lan-
guage, taking into account
Section 2.
3.1. Programming multitasks systems with NEMO
The Nemo language is devoted to build control layers. It al-
lows the description of an abstraction of the computation
layer, that is, the resources used, the ways computations can
be controlled, that is, tasks,aswellassomeexplicit tempo-
ral properties between tasks. These declarations are used to
specify applications, in terms of an imperative sequencing of
tasks.
From these elements, two basic parts are derived, as
shown in
Figure 2:
(i) a declarative part, grouping
(a) the constraints corresponding to resources,
(b) the explicit properties to be enforced,
(c) the declared consumptions of tasks;
(ii) an imperative part, grouping
(a) the observers for the explicit properties,
(b) the behaviors of the tasks,
(c) the behaviors of the applications.