simulation of heterogeneous components with different execution models.One of the advantages of this technique is the reusability of the modelsalready developed in a well-known language
Trang 1The resulting mathematical model is the basis for a precise behavioralsemantics for the HRC metamodel and provides a precise semantic for com-ponent composition, an often neglected issue in the design of frameworks forcomponent-based design.
Introduc-4 R.-J Back and J von Wright Contracts, games, and refinement tion and Computation, 156:25–45, 2000
Informa-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 ofcontracts for embedded systems Rapport de recherche 6214, InstitutNational 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
Trang 2Software (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 Communicaderiva-tions of the ACM, 18(8):453–457, August
1975
13 D L Dill Trace Theory for Automatic Hierarchical Verification of Independent Circuits ACM distinguished dissertations MIT Press,Cambridge, MA, 1989
Speed-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 ceedings of the 13th Annual Symposium on Foundations of Software Engineer- ing (FSE05), Lisbon, Portugal, pp 31–40, 2005, ACM Press, New York
Pro-16 Lamport, L Win and sin: Predicate transformers for concurrency ACM Transactions on Programming Languages and Systems, 12(3):396–428, July1990
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 puter Science, University Park, PA, 1877, 2000 Springer-Verlag, Berlin/Heidelberg
Com-19 A Sangiovanni-Vincentelli Reasoning about the trends and challenges
of system level design Proceedings of the IEEE, 95(3):467–506, 2007.
Trang 4Generic 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 in Continuous/Discrete Global Execution Models 528
16.4.2 Distribution of the Synchronization Functionality to the Simulation Interfaces 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-Simulation Framework 530
16.4.6 Implementation of the Library Elements Specific to Different Simulation Tools 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 in C/D Global Execution Models 536
16.6.4 Distribution of the Synchronization Functionality to the Simulation Interfaces 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 in the Co-Simulation Framework 549
16.6.8 Implementation of the Library Elements Specific to Different Simulation Tools 550
16.7 Formalization and Verification of the Interfaces 550
16.7.1 Discrete Simulator Interface 550
Trang 516.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 execusimula-tion 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
Trang 6simulation of heterogeneous components with different execution models.One of the advantages of this technique is the reusability of the modelsalready developed in a well-known language and using already existingpowerful 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, thistechnique allows the designer to use the best tool for each domain and toprovide capabilities to validate the overall model This methodology requiresthe elaboration of a global simulation model.
The global validation of continuous/discrete systems requires simulation interfaces providing synchronization models for the accommo-dation of the heterogeneous The interfaces play also an important role in theaccuracy 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
co-is very desirable An efficient tool for the automatic generation of the lation interfaces must rely on the formal representation of the co-simulationinterfaces [29]
simu-This chapter presents a generic methodology, independent of 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
simula-in Section 16.3 Section 16.4 details the methodology while Section 16.5 poses a continuous/discrete synchronization model Section 16.6 exemplifiesthe application of the methodology described in Section 16.4 Section 16.7presents the formalization and the verification of the simulation interfaces
pro-An example of a tool implemented with respect to the presented ogy is shown in Section 16.8 Finally, Section 16.9 gives our conclusions
methodol-16.2 Related Work
The existing work on the validation of continuous/discrete heterogeneoussystems can be classified into a few categories They mostly include twoapproaches: simulation-based approach and formal representation-basedapproach
The simulation-based approaches can be divided into two groups thatuse different techniques to obtain the global execution model:
1 The extension of existing tools and languages Most of the tools ated using this approach started from classical hardware descriptionlanguages (HDLs) and new concepts specific to other domains such
cre-as analog mixed signal (AMS) or synchronous data flow (SDF) nel were added (VHDL-AMS) [15], Verilog-AMS [10], SystemC–AMS
Trang 7ker-[32] or SystemC [27] extended with SDF kernel These extensions areusually designed from scratch and by consequence their libraries arenot 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 byassembling different components [23,28] HyVisual [21] is a systemsmodeler based on Ptolemy [28] that supports the construction of hier-archal systems for continuous-time dynamical systems (see Chapter 15and [21]) However, the different subsystems and components need to
be developed in the same environment in order to be compatible andtherefore they do not solve the problem of IP reuse in system design.Moreover, Ptolemy is based on formal representation, but the formalverification of the simulation models is not considered
In the formal representation-based approaches, the integration is ssed as a composition of models of computation These approaches propose asingle main formalism to represent different models and the main concern isbuilding interfaces between different models of computation (MoC) Theseapproaches bring a deep conceptual understanding of each MoC In otherwork [22], a framework of tagged signal models is proposed for comparison
addre-of various MoCs The framework was used to compare certain features addre-ofvarious MoCs such as dataflow, sequential processes, concurrent, sequentialprocesses with rendezvous, Petri nets, and discrete-event systems The role
of computation in abstracting functionalities of complex heterogeneous tems was presented in [17] In [18] the author proposes the formalization ofthe heterogeneous systems by separating the communication and the com-putation aspects; however the interfaces between domains were not takeninto consideration
sys-In [34], the authors introduce an abstract simulation mechanismthat enables event-based, distributed simulation (discrete event systemspecifications—DEVS), where time advances using a continuous time base.DEVS is a formal approach to build the models, using a hierarchical andmodular approach and more recently it integrates object-oriented program-ming techniques Based on this formalism, [8] has proposed a tool for themodeling and simulation of hybrid systems using Modelica and DEVS Themodels 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 modelsare converted through a conversion protocol into DEVS-compliant models.CD++ is a general toolkit written in C++ that allows the definition of DEVSand Cell-DEVS models DEVS-coupled models and Cell-DEVS models can
be defined using a high-level specification language [35] PythonDEVS is atool for constructing DEVS models and generating Python code A model isdescribed by deriving coupled and/or atomic DEVS descriptive classes fromthis architecture, and arranging them in a hierarchical manner through com-position [4] DEVSim++ is an environment for object-oriented modeling ofdiscrete event systems [19]
Trang 816.3 Execution Models
This section presents the global execution models of continuous/discreteheterogeneous 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 ofthe 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 basicelements 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 tion of different simulators to the co-simulation bus in order to guaranteethe transmission of information between simulators executing the different
adapta-(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
Trang 9components of the heterogeneous systems They also have to provideefficient 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 ferent components of the system It is composed of the above mentioned sim-ulation interfaces and the simulation bus
dif-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 simulatorsand 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 thestate of the system occur at discrete points in the execution time
The discrete system can be described by the state–space equations [6]:
⎧
⎨
⎩
xd(t k+1) = f (xd(t k ), u (t k ), t k ) with x(t0) = x0y(t k ) = g(xd(t k ), u (t k ), t k ) (16.1)
where
f and g are transformations
xdis the discrete state vector
uis the input signal vector
yis the output signal vector
For the linear discrete systems, Equation 16.1 becomes
⎧
⎨
⎩
xd(tk+1) = A d xd(tk) + B d u(t k ) y(t k ) = C d xd(tk) + D d u(t k ) (16.2)where A d , B d , C d , and D dare matrices that can be time varying and describethe 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 Theunprocessed 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 updateevent schema At each simulation cycle, the first event with the smallest timestamp is processed and the processes sensitive to this event are executed [34]
If several processes are sensitive to one or several events (with the sametime 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
Trang 10State Event
t1 t2 t3
Clock = t1, e1 removed and executed
Yes No
t3 t4
Update state variables
Update state variables
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 allelism, where the processes are executed as if the parallelism is real andthe environment does not change while executing all the processes Once allevents with discrete time stamp equal to the current time have been treated,the simulator advances the time to the nearest scheduled discrete event
par-16.3.3 Continuous Execution Model
The continuous time system is described by the state–space equations:
(16.3)
where
x cis the state vector
uis the input signal vector
yis the output signal vector
Ac, Bc, Cc, and Dcare constant matrices that describe the dynamic of thesystem
Trang 11The execution of continuous model, described by differential and algebraicequations, requires solving these equations numerically A widely used class
of algorithms discretizes the continuous time line into an increasing set ofdiscrete time instants, and numerically computes values of state variables atthese ordered time instants The next state of derivative systems cannot bespecified directly but the derivative functions are used to specify the rate ofchange of state variables [34]
The execution of a continuous system raises problems because given a
state q k and a vector x for a time t k, the derivative offers information only
for dq k /dt but not the system’s behavior over time For a nonzero interval [t k , t k+1] the computation has to be realized without knowing the behavior in
the interval (t k , t k+1) This problem can be solved using numerical integration
methods Some of the most commonly used methods are
• Euler method that consists in signal integration:
dq (t)
dt = h→ ∞lim q(t + h) − q(t)
For an h small enough (in order to obtain accurate results), the following
approximation can be used:
q(t + h) = q(t) + h ∗ dq (t)
d(t)
This solution has low efficiency and does not have stability problems forsmall enough h and it is very robust [34]
• Causal methods that are a linear combination of states and derivative
values at time instants with coefficients chosen to minimize errors fromthe computed estimate to the real value [34]
This solution has high efficiency but it has stability and robustnessproblems
• Noncausal methods that use “future” values of states, derivative, and
inputs In order to do that the model is executed past the needed timeand the values that are necessary are stored to estimate the presentvalues [34]
16.4 Methodology
This section introduces a methodology for the design of crete co-simulation tools (as shown in Figure 16.3) To enable the design ofco-simulation tools, this methodology presents several steps that are inde-pendent of the simulation tools used for the continuous and discrete
Trang 12continuous/dis-Generic stage Definition of the operational semantics for the synchronization
Distribution of the synchronization functionality to the interfaces
Formalization and verification of the interfaces behavior
Definition of the internal architecture of the interfaces and the library elements
Simulation tools analysis
Library elements implementation
Implementation validation Implementation
stage
FIGURE 16.3
A generic methodology for the design of C/D co-simulation tools
components of the system During these generic steps, the co-simulationinterfaces are defined in a conceptual framework; their functionality andthe internal structure of simulation interfaces are expressed using exist-ing formalisms and temporal logic After the rigorous definition of therequired functionality for simulation interfaces, the designer will start thesteps related to the implementation
The main steps of the proposed methodology (illustrated in Figure 16.3)can be divided into two stages:
1 A generic stage with the following actions:
• Definition of the operational semantics for the synchronization incontinuous/discrete global execution models
• Distribution of the synchronization functionality to the simulationinterfaces
• Formalization and verification of the simulation interfaces behavior
• Definition of the library elements and the internal architecture of thesimulation interfaces
2 An implementation stage with the following actions:
• The analysis of the simulation tools for the integration in the simulation framework
co-• The implementation of the library elements specific to different ulation tools
Trang 13sim-This section focuses on the generic stage and its steps will be detailed inthe next subsections A possible implementation stage will be detailedfurther in Section 16.8.
16.4.1 Definition of the Operational Semantics for the
Synchronization in Continuous/Discrete Global
Execution Models
The first step of the methodology for co-simulation tools design is the tion of the operational semantics for the synchronization in continuous/dis-crete global execution models An operational semantics gives a detaileddescription of the system’s behavior in mathematical terms This modelserves as a basis for analysis and verification The description provides aclear language independent model that can serve as a reference for differentimplementations
defini-The operational semantics for continuous/discrete systems requires therigorous representation of the relation between the simulators (communica-tion/synchronization and data exchanged between the continuous and thediscrete simulators) as well as their high level and dynamic representations
16.4.2 Distribution of the Synchronization Functionality to the
Simulation Interfaces
Based on the operational semantics, we can now define the synchronizationfunctionality between the continuous and the discrete simulators This func-tionality is insured by the interfaces that are the link between the differentexecution models and the co-simulation bus (see Figure 16.1) They are each
in charge with a part of the synchronization between the two models Toensure system’s flexibility, the synchronization functionality has to be dis-tributed to the simulation interfaces Moreover, each computation step has
• Model checking, where the system descriptions are given as automata,
the specification formulas are given as temporal logic formulas, andthe checking consists of the verification which ensures that all models
of a given system description satisfy a given specification formula It
Trang 14focuses mainly on automatic verification Completeness and termination guaranteeof model checking are some features of this technique, as well
as it enables the tool to guarantee the correctness of a given property,
or produce a counterexample otherwise
• Theorem proving, where the verification plan is manually designed
and the correctness of the steps in the plan is verified using rem provers Completely automatic decision procedures are impos-sible because the input language (the model and the specification) is
theo-of higher order logic and that eliminates the decidability Moreover,everything has to be translated in higher order logic, and, therefore, thestructure of the system may be lost and its representation can becomelarge and difficult to work with
Considering that the system is dynamic, it is necessary to use a ism that allows the expression of dynamic properties (the state of a systemchanges and by consequence the properties of the state also change) Thetemporal logic handles formalization where the properties evolve over timeand in general uses:
formal-• Propositions that describe the states (i.e., elementary formulas and ical connectors)
log-• Temporal operators that allow the expression of the properties of thestates successions (called executions)
The differences between the logics are in terms of temporal operators andobjects on which they are interpreted (such as sequences or state trees) [25].The most commonly used logics are Linear Temporal Logic (LTL), Com-putation Tree Logic (CTL* and CTL, both of them untimed temporal log-ics) and their timed extensions TCTL and Metric Interval Temporal Logic(MITL)
• CTL* allows the use of all temporal and branching operators but theproperty verification is very complex For this reason, most of the toolsactually used allow the verification of fragments of CTL*
• LTL is a fragment of CTL* that excludes the trajectory quantifiers Inthis case only the trajectory predicates are considered LTL does notprovide a means for considering the existence of different possiblebehaviors starting from a given state (sequential) 0
• CTL is also a fragment of CTL* and it is obtained when every rence of a temporal operator is immediately preceded by a branchingoperator In the case of CTL we have state trees
occur-• TCTL is a timed temporal logic that is an extension of CTL obtained bysubscribing the modalities with time intervals specifying time restric-tions on formulas
For our formal model, the properties that need to be checked are branchingproperties that are expressed using CTL or TCTL logics
Trang 15Continuous/discrete global simulation model
Continuous
model
Discrete model
Discrete domain simulation interface-DDI
Continuous/discrete simulation interface
Elements from the co-simulation library
Co-simulation bus
Atomic model CDI
Atomic model CDI
Atomic model CDI
Atomic model CDI
fol-At the top hierarchical level, the global model is composed of the uous and discrete models and of the C/D simulation interface required forthe global simulation [12]
contin-The second hierarchical level of the global simulation model includes thedomain specific simulation interfaces and the co-simulation bus in charge ofthe data transfer between these interfaces
The bottom hierarchical level includes the elements from the simulation library that are the atomic modules of the domain specific sim-ulation interface These atomic components implement basic functionalities
co-of the synchronization model
16.4.5 Analysis of the Simulation Tools for the Integration
in the Co-Simulation Framework
The considerations presented in the previous steps of the methodology showthat specific functionalities are required for the co-simulation of continu-ous and discrete modes Therefore, the integration of a simulation tool in