Model-Based Design for Embedded Systems- P55 ppt

Nicolescu/Model-Based Design for Embedded Systems 67842_C015 Finals Page 516 2009-10-2
516 Model-Based Design for Embedded Systems
The resulting mathematical model is the basis for a precise behavioral
semantics for the HRC metamodel and provides a precise semantic for com-
ponent composition, an often neglected issue in the design of frameworks for
component-based design.
Acknowledgment
This research has been developed in the framework of the European IP-
SPEEDS project number 033471.
References
1. R. Alur and D. L. Dill. A theory of timed automata. Theoretical Computer
Science, 126(2):183–235, 1994.
2. J P. Aubin and A. Cellina. Differential Inclusions, Set-Valued Maps and
Viability Theory, Grundl. der Math. Wiss., vol. 264, Springer, Berlin/
Heidelberg, 1984.
3. R J. Back and J. von Wright. Refinement Calculus: A systematic Introduc-
tion. Graduate Texts in Computer Science. Springer-Verlag, New York
1998.
4. R J. Back and J. von Wright. Contracts, games, and refinement. Informa-
tion and Computation, 156:25–45, 2000.
5. A. Benveniste, B. Caillaud, A. Ferrari, L. Mangeruca, R. Passerone, and
C. Sofronis. Multiple viewpoint contract-based specification and design.
In Proceedings of the Software Technology Concertation on Formal Methods
for Components and Objects (FMCO07), Revised Lectures, Lecture Notes in
Computer Science, Amsterdam, the Netherlands, October 24–26, 2007.
6. A. Benveniste, B. Caillaud, and R. Passerone. A generic model of
contracts for embedded systems. Rapport de recherche 6214, Institut
National de Recherche en Informatique et en Automatique, June 2007.
7. H. Butz. The Airbus approach to open Integrated Modular Avionics
(IMA): Technology, functions, industrial processes and future develop-
ment road map. In International Workshop on Aircraft System Technologies,

Hamburg, Germany, March 2007.
8. A. Chakrabarti, L. de Alfaro, T. A. Henzinger, and M. Stoelinga. Resource
interfaces. In Proceedings of the Third Annual Conference on Embedded
Nicolescu/Model-Based Design for Embedded Systems 67842_C015 Finals Page 517 2009-10-2
Multi-Viewpoint State Machines 517
Software (EMSOFT03), Lecture Notes in Computer Science, Philadelphia,
PA, 2855:117–133, 2003. Springer, Berlin/Heidelberg.
9. W. Damm. Controlling speculative design processes using rich compo-
nent models. In Fifth International Conference on Application of Concurrency
to System Design (ACSD 2005), St. Malo, France, pp. 118–119, June 6–9,
2005.
10. W. Damm. Embedded system development for automotive applica-
tions: Trends and challenges. In Proceedings of the Sixth ACM & IEEE
International Conference on Embedded Software (EMSOFT06),Seoul,Korea,
October 22–25, 2006.
11. L. de Alfaro and T. A. Henzinger. Interface automata. In Proceedings of the
Ninth Annual Symposium on Foundations of Software Engineering, Vienna,
Austria, pp. 109–120, 2001, ACM Press, New York.
12. E.W. Dijkstra. Guarded commands, nondeterminacy and formal deriva-
tion of programs. Communications of the ACM, 18(8):453–457, August
1975.
13. D. L. Dill. Trace Theory for Automatic Hierarchical Verification of Speed-
Independent Circuits. ACM distinguished dissertations. MIT Press,
Cambridge, MA, 1989.
14. T. A. Henzinger. The theory of hybrid automata. In LICS,New
Brunswick, NJ, p. 278–292, 1996, IEEE Computer Society Press.
15. T. A. Henzinger, R. Jhala, and R. Majumdar. Permissive interfaces. In Pro-
ceedings of the 13th Annual Symposium on Foundations of Software Engineer-
ing (FSE05), Lisbon, Portugal, pp. 31–40, 2005, ACM Press, New York.
16. Lamport, L. Win and sin: Predicate transformers for concurrency. ACM

Transactions on Programming Languages and Systems, 12(3):396–428, July
1990.
17. B. Meyer. Applying “design by contract.” IEEE Computer, 25(10):40–51,
October 1992.
18. R. Negulescu. Process spaces. In CONCUR, Lecture Notes in Com-
puter Science, University Park, PA, 1877, 2000. Springer-Verlag, Berlin/
Heidelberg.
19. A. Sangiovanni-Vincentelli. Reasoning about the trends and challenges
of system level design. Proceedings of the IEEE, 95(3):467–506, 2007.
Nicolescu/Model-Based Design for Embedded Systems 67842_C015 Finals Page 518 2009-10-2
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 519 2009-10-2
16
Generic Methodology for the Design of
Continuous/Discrete Co-Simulation Tools
Luiza Gheorghe, Gabriela Nicolescu, and Hanifa Boucheneb
CONTENTS
16.1 Introduction 520
16.2 Related Work 521
16.3 Execution Models 523
16.3.1 Global Execution Model 523
16.3.2 Discrete Execution Model 524
16.3.3 Continuous Execution Model 525
16.4 Methodology 526
16.4.1 Definition of the Operational Semantics for the Synchronization
inContinuous/DiscreteGlobalExecutionModels 528
16.4.2 Distribution of the Synchronization Functionality to the
SimulationInterfaces 528
16.4.3 Formalization and Verification of the Simulation Interfaces
Behavior 528
16.4.4 Definition of the Internal Architecture of the Simulation

Interfaces 530
16.4.5 Analysis of the Simulation Tools for the Integration in the
Co-SimulationFramework 530
16.4.6 Implementation of the Library Elements Specific to
DifferentSimulationTools 531
16.5 Continuous/Discrete Synchronization Model . 531
16.6 Application of the Methodology 533
16.6.1 Discrete Event System Specifications 533
16.6.2 Timed Automata 535
16.6.3 Definition of the Operational Semantics for the Synchronization
inC/DGlobalExecutionModels 536
16.6.4 Distribution of the Synchronization Functionality to the
SimulationInterfaces 538
16.6.5 Formalization and Verification of the Simulation Interfaces
Behavior 539
16.6.6 Definition of the Internal Architecture of the Simulation
Interfaces 546
16.6.7 Analysis of the Simulation Tools for the Integration
intheCo-SimulationFramework 549
16.6.8 Implementation of the Library Elements Specific
toDifferentSimulationTools 550
16.7 Formalization and Verification of the Interfaces 550
16.7.1 Discrete Simulator Interface . 550
519
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 520 2009-10-2
520 Model-Based Design for Embedded Systems
16.7.2 Continuous Simulator Interface 552
16.8 Implementation Stage: CODIS a C/D Co-Simulation Framework 552
16.9 Conclusion . 553
References 554

16.1 Introduction
The past decade witnessed the shrinking of the chips’ size simultaneously
with the expansion of a number of components, heterogeneous architec-
tures, and systems specific to different application domains, for example,
electronic, mechanics, optics, and radio frequency (RF) integrated on the
same chip [16]. These heterogeneous systems enable cost-efficient solutions,
an advantageous time-to-market, and high productivity. However, one will
notice the increase of the variability of design related parameters. Given their
application in various domains such as defense, medical, communication,
and automotive, the continuous/discrete (C/D) systems emerge as impor-
tant heterogeneous systems. This chapter focuses on these systems, their
modeling and simulation.
Because of the complexity of these systems, their global design specifi-
cation and validation are extremely challenging. The heterogeneity of these
systems makes the elaboration of an executable model for the overall simula-
tion more difficult. Such a model is very complex; it includes the execution of
different components, the interpretation of interconnects, as well as the adap-
tation of the components. Their design requires tools with different models
of computation and paradigms. The most important concepts manipulated
by the discrete and the continuous components are
• In discrete models, time represents a global notion for the overall sys-
tem and advances discretely when passing by time stamps of events,
while in continuous models, the time is a global variable involved in
data computation and it advances by integration steps that may be
variable.
• In discrete models, processes are sensitive to events while in continuous
models processes are executed at each integration step [12].
• Each model has to be able to detect, locate in time, and react to events
sent by the other model.
The International Technology Roadmap for Semiconductors (ITRS) empha-

sizes that “a more structured approach to verification demands an effort
towards the formalization of a design specification” and that “in the long
term, formal techniques will be needed to verify the issues at the boundary
of analog and digital, treating them as hybrid systems” [16].
Generally, in the design of embedded systems, the technique favored for
the systems validation is co-simulation. Co-simulation allows for the joint
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 521 2009-10-2
Generic Methodology for the Design 521
simulation of heterogeneous components with different execution models.
One of the advantages of this technique is the reusability of the models
already developed in a well-known language and using already existing
powerful tools (i.e., Simulink
R

[24] for the continuous domain and VHDL
[33], Verilog [31], or SystemC [30] for the discrete domain). Thus, the devel-
opment time, the time-to-market, and the cost are reduced. Moreover, this
technique allows the designer to use the best tool for each domain and to
provide capabilities to validate the overall model. This methodology requires
the elaboration of a global simulation model.
The global validation of continuous/discrete systems requires co-
simulation interfaces providing synchronization models for the accommo-
dation of the heterogeneous. The interfaces play also an important role in the
accuracy and the performance of the global simulation. This implies a com-
plex behavior for the simulation interfaces, their design being time consum-
ing and an important source of error. Therefore, their automatic generation
is very desirable. An efficient tool for the automatic generation of the simu-
lation interfaces must rely on the formal representation of the co-simulation
interfaces [29].
This chapter presents a generic methodology, independent of simula-

tion language, for the design of continuous/discrete co-simulation tools.
This chapter is organized in nine sections. Section 16.2 gives several previ-
ous approaches to the modeling of continuous/discrete systems. The exe-
cution models for the continuous and the discrete domains are presented
in Section 16.3. Section 16.4 details the methodology while Section 16.5 pro-
poses a continuous/discrete synchronization model. Section 16.6 exemplifies
the application of the methodology described in Section 16.4. Section 16.7
presents the formalization and the verification of the simulation interfaces.
An example of a tool implemented with respect to the presented methodol-
ogy is shown in Section 16.8. Finally, Section 16.9 gives our conclusions.
16.2 Related Work
The existing work on the validation of continuous/discrete heterogeneous
systems can be classified into a few categories. They mostly include two
approaches: simulation-based approach and formal representation-based
approach.
The simulation-based approaches can be divided into two groups that
use different techniques to obtain the global execution model:
1. The extension of existing tools and languages. Most of the tools cre-
ated using this approach started from classical hardware description
languages (HDLs) and new concepts specific to other domains such
as analog mixed signal (AMS) or synchronous data flow (SDF) ker-
nel were added (VHDL-AMS) [15], Verilog-AMS [10], SystemC–AMS
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 522 2009-10-2
522 Model-Based Design for Embedded Systems
[32] or SystemC [27] extended with SDF kernel. These extensions are
usually designed from scratch and by consequence their libraries are
not as strong as the well established tools for this field (i.e., Simulink).
2. The definition of new models and tools. The systems are designed by
assembling different components [23,28]. HyVisual [21] is a systems
modeler based on Ptolemy [28] that supports the construction of hier-

archal systems for continuous-time dynamical systems (see Chapter 15
and [21]). However, the different subsystems and components need to
be developed in the same environment in order to be compatible and
therefore they do not solve the problem of IP reuse in system design.
Moreover, Ptolemy is based on formal representation, but the formal
verification of the simulation models is not considered.
In the formal representation-based approaches, the integration is addre-
ssed as a composition of models of computation. These approaches propose a
single main formalism to represent different models and the main concern is
building interfaces between different models of computation (MoC). These
approaches bring a deep conceptual understanding of each MoC. In other
work [22], a framework of tagged signal models is proposed for comparison
of various MoCs. The framework was used to compare certain features of
various MoCs such as dataflow, sequential processes, concurrent, sequential
processes with rendezvous, Petri nets, and discrete-event systems. The role
of computation in abstracting functionalities of complex heterogeneous sys-
tems was presented in [17]. In [18] the author proposes the formalization of
the heterogeneous systems by separating the communication and the com-
putation aspects; however the interfaces between domains were not taken
into consideration.
In [34], the authors introduce an abstract simulation mechanism
that enables event-based, distributed simulation (discrete event system
specifications—DEVS), where time advances using a continuous time base.
DEVS is a formal approach to build the models, using a hierarchical and
modular approach and more recently it integrates object-oriented program-
ming techniques. Based on this formalism, [8] has proposed a tool for the
modeling and simulation of hybrid systems using Modelica and DEVS. The
models are “created using Modelica standard notation and a translator con-
verts them into DEVS models” [8]. In [20] the authors propose a heteroge-
neous simulation framework using DEVS BUS. NonDEVS-compliant models

are converted through a conversion protocol into DEVS-compliant models.
CD++ is a general toolkit written in C++ that allows the definition of DEVS
and Cell-DEVS models. DEVS-coupled models and Cell-DEVS models can
be defined using a high-level specification language [35]. PythonDEVS is a
tool for constructing DEVS models and generating Python code. A model is
described by deriving coupled and/or atomic DEVS descriptive classes from
this architecture, and arranging them in a hierarchical manner through com-
position [4]. DEVSim++ is an environment for object-oriented modeling of
discrete event systems [19].
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 523 2009-10-2
Generic Methodology for the Design 523
16.3 Execution Models
This section presents the global execution models of continuous/discrete
heterogeneous systems. The execution model can be viewed as the interpre-
tation of a computation model. Discrete and continuous systems are charac-
terized by different physical properties and modeling paradigms.
16.3.1 Global Execution Model
The global execution model of a heterogeneous system is the realization of
the system’s functionality. A C/D system and its corresponding global exe-
cution model are illustrated in Figure 16.1. There are three types of basic
elements that compose the model [26]:
• The execution models of the different components constituting the het-
erogeneous system (corresponding to Component 1 and Component 2
in Figure 16.1)
• The co-simulation bus
• The co-simulation interfaces
The co-simulation bus is in charge of interpreting the interconnections
between the different components of the system.
The co-simulation interfaces enable the communication of different
components through the simulation bus. They are in charge of the adapta-

tion of different simulators to the co-simulation bus in order to guarantee
the transmission of information between simulators executing the different
(a)
Discrete
component
Continuous
component
(b)
Discrete component
execution model
Co-simulation
interface
Co-simulation bus
Co-simulation
interface
Co-simulation backplane
Continuous component
execution model
FIGURE 16.1
Continuous/discrete (a) heterogeneous system and its corresponding
(b) execution model.
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 524 2009-10-2
524 Model-Based Design for Embedded Systems
components of the heterogeneous systems. They also have to provide
efficient synchronization models for the modules adaptation.
The co-simulation backplane is the element of the global execution model
that guarantees the synchronization and the communication between the dif-
ferent components of the system. It is composed of the above mentioned sim-
ulation interfaces and the simulation bus.
The implementation and the simulation of an execution model in a given

context is called co-simulation instance. Several instances may correspond to
the same execution model and these instances may use different simulators
and may present different characteristics (e.g., accuracy and performances).
16.3.2 Discrete Execution Model
The execution model for a discrete system is a model where changes in the
state of the system occur at discrete points in the execution time.
The discrete system can be described by the state–space equations [6]:
⎧
⎨
⎩
x
d
(t
k+1
) = f(x
d
(t
k
), u(t
k
), t
k
) with x(t
0
) = x
0
y(t
k
) = g(x
d

(t
k
), u(t
k
), t
k
)
(16.1)
where
f and g are transformations
x
d
is the discrete state vector
u is the input signal vector
y is the output signal vector
For the linear discrete systems, Equation 16.1 becomes
⎧
⎨
⎩
x
d
(t
k+1
) = A
d
x
d
(t
k
) + B

d
u(t
k
)
y(t
k
) = C
d
x
d
(t
k
) + D
d
u(t
k
)
(16.2)
where A
d
, B
d
, C
d
,andD
d
are matrices that can be time varying and describe
the dynamics of the system [6].
A discrete event system execution concentrates on processing events,
each event having assigned a time stamp. Each event computation can mod-

ify the state variables, schedule new events or retract existing events. The
unprocessed events are stored in a pending events list. The events are pro-
cessed in the order of their time stamp. Figure 16.2 shows a possible update
event schema. At each simulation cycle, the first event with the smallest time
stamp is processed and the processes sensitive to this event are executed [34].
If several processes are sensitive to one or several events (with the same
time occurrence) then these processes have to be executed in parallel. Execu-
tions often occur on sequential machines that can only execute one instruc-
tion at a time (therefore, one process). The consequence is that this execution
Nicolescu/Model-Based Design for Embedded Systems 67842_C016 Finals Page 525 2009-10-2
Generic Methodology for the Design 525
Start
State
Event
t1
t2
t3
Clock = t1, e1 removed and executed
Yes
No
e2
t2
t3
t4
Update state
variables
Update state
variables
Stop Stop
e3

e4
e'2
t'2
t'3
t'4
e'3
e'4
Is queue
re-ordered?
Scheduled
time
e1
e2
e3
State1
State2
State3
FIGURE 16.2
Event update schema.
cannot parallelize the processes. The solution consists in emulating the par-
allelism, where the processes are executed as if the parallelism is real and
the environment does not change while executing all the processes. Once all
events with discrete time stamp equal to the current time have been treated,
the simulator advances the time to the nearest scheduled discrete event.
16.3.3 Continuous Execution Model
The continuous time system is described by the state–space equations:
⎧
⎨
⎩
•

x
c
(t) = A
c
x
c
(t) + B
c
u(t)
y(t) = C
c
x
c
(t) + D
c
u(t)
(16.3)
where
x
c
is the state vector
u is the input signal vector
y is the output signal vector
A
c
, B
c
, C
c
,andD

c
are constant matrices that describe the dynamic of the
system