Model-Based Design for Embedded Systems- P20 pptx

However, when a state event is generated by the continuous domain, the discrete domain has to detect this event at the same precise time the cause precedes or equals theeffect time and n

implicitly the synchronization This property verifies that after a cycle cuted by each model, both are at the same time stamp (and by consequenceare synchronized)

exe-Definition:Invariantlyboth processes in the Start location (initial state)

imply the time in the continuous domain tc is equal with the time in thediscrete domain td

P 4 Causality principle (liveness property)

The causality can be defined as a cause and effect relationship The ity of two events describes to what extent one event is caused by the other

causal-The causality is already verified by P3 for scheduled events However, when

a state event is generated by the continuous domain, the discrete domain has

to detect this event at the same precise time (the cause precedes or equals theeffect time) and not some other possible event existing at a different time inthe continuous domain

Definition: Invariantly both processes in the StEvDetect location

(detection of state event)implythe time in the continuous tcis equal withthe time in the discrete td

16.6.6 Definition of the Internal Architecture of the

Simulation Interfaces

The overall continuous/discrete simulation interface is formally definedusing the DEVS formalism As shown in Figure 16.4, the interface isdescribed as a set of coupled models: the continuous domain interface(CDI), the discrete domain interface (DDI), and the co-simulation bus.Figure 16.12 shows the atomic modules composing the interface used in ourimplementation

The specific functionalities of the interfaces were presented in tion 16.4.2 In terms of internal architecture, the blocks assuring these fea-tures are

Sec-For the Continuous Model Simulation Interface

• The State Event Indication and Time Sending block (SETS)

• The Signal Conversion and Data Exchange block (SCDE)

• The Event Detection block (DED)

• The Context Switch block (CS)

For the Discrete Model Simulation Interface

• The End of Discrete Simulation Cycle Detection and Time Sending block

(DDTS)

• The Data Exchange block (DE)

• The Event Detection block (DEC)

• The Context Switch block (CS)

These atomic modules are forming the simulation library and the simulation tools enable their parameterization and their assembly in order

co-Continuous/discrete global simulation model Continuous/discrete simulation interface

Data exchange DE

Context switch CS Co-simulation

sending SETS

Event detection DED

End of discrete simulation cycle detection and time sending DDTS

Event detection DEC

Discrete model simulation interface-DDI

FIGURE 16.12

The hierarchical representation of the generic architecture of the simulation model with the elements of the co-simulation library defined.(From Gheorghe, L et al., Formal definition of simulation interfaces in a

co-continuous/discrete co-simulation tool, Proceedings of the 17th IEEE national Workshop on RSP, Chania, Crete, Greece, pp 186–192, 2006 Withpermission.)

Time of state event tse Time of the next scheduled event in the discrete simulator td

State event indication and time sending SETS

Data exchange DE

Context switch CS

Context switch CS

Event detection

DEC

Event detection DED

Signal conversion and data exchange SCDE

Data to/from the discrete

Inter-Figure 16.13 presents the atomic modules interconnection in each domainspecific simulation interface as well as the signals and interactions betweenthe interfaces

The internal architecture is defined as a set of coupled modules thatrespect the coupled modules DEVS formalism as presented in Section 16.6.1:

-Ninterface= (X,Y, D, {M d |d ∈ D}, EIC,EOC,IC )

-X = {(p d , v d )|p d ∈ InPorts, v d ∈ X p d}

-Y = {( p d , v d )|p d ∈ OutPorts, v d ∈ Y p d}

-X p d,Y p d= values for input ports, respectively output ports

-InPorts = Pin,c∪ Pin,d∪ Pin,td∪ Pin,tse∪ Pin,flagwhere

Pin,c– set of ports receiving data from the continuous model; Pin,d– set

of ports receiving data from the discrete model (via the co-simulationbus);

Ptd– port receiving the timestamp of the next discrete event

Pin,flag– port receiving the command for the context switch

- OutPorts = Pout,c∪ Pout,d∪ Pout,td∪ Pout,tse∪ Pout,flag

Pout ,flag,Pout ,c, Pout ,dare defined similarly to Pin ,flag,,Pin ,cand Pin ,d

- D = {“Continuous Domain Interface” (with associated model

N interfaceCDI ), “Discrete Domain Interface” (with associated model

N interfaceDDI ), “co-simulation bus” (with associated model M cosim )}

−M d = (N interfaceCDI , M interfaceDDI , M cosim )

−EIC = {((N interface, “inc,1), (N interfaceCDI, “inc,1)); ;

((N interface, “inc,n), (N interfaceCDI, “inc,n));

((N interface, “ind,0), (N interfaceDDI, “ind,0)); ;

((N interface, “ind,m), (N interfaceDDI, “ind,m))}

−EOC = {((N interfaceCDI, “outc,1), (N interface , “outc,1)); ;

((N interfaceCDI, “outc,p), (N interface, “outc,p));

((N interfaceDDI, “outd,1), (N interface, “outd,1)); ;

((N interfaceDDI, “outd,q), (N interface, “outd,q))}

−IC = {((N interfaceCDI , op CDI ), (M cosim , ip cosim ))|N interfaceCDI,

− M cosim ∈ D, op CDI ∈ OutPorts CDI,ip cosim ∈ InPorts cosim}∪

{((N interfaceDDI , op DDI ), (M cosim , ip cosim ))|N interfaceDDI,

M cosim ∈ D, op DDI ∈ OutPorts DDI,ip cosim ∈ InPorts cosim}∪

{((M cosim , op cosim ), (N interfaceCDI , ip CDI ))|N interfaceCDI,

M cosim ∈ D, op cosim ∈ OutPorts cosim,ip CDI ∈ InPorts CDI,}∪

{((M cosim , op cosim ), (N interfaceDDI , ip DDI ))|N interfaceDDI,

− M cosim ∈ D, op cosim ∈ OutPorts cosim,ip DDI ∈ InPorts DDI,}[12]

We show here the atomic module co-simulation bus that can be formally

defined as follows:

- X = {(p d , v d ) |p d ∈ InPorts, v d ∈ Xp d}

- Y = {(p , v ) |p ∈ OutPorts, v ∈ Yp }

- InPorts= Pin,c∪ Pin,d∪ Pin,td∪ rmPin,tse∪ Pin,flag

- OutPorts= Pout,c∪ Pout,d∪ Pout,td∪ Pout,tse∪ Pout,flag

where Pin,c, Pin,dPin,td, Pin,tse, Pin,flagPout,c, Pout,d, Pout,td, Pout,tse, Pout,flag

as well as Xp d , Yp dwere previously defined

States triplet S:(phase * σ * job) where:

phase: (“passive,” “active”)

σ: +0 advance time

job: (“store,” “respond”)

S= {“passive,” “active”} * +0 * {“store”, “respond”}

δext((“passive” * σ * job), e, x))=

(“passive,” σ –e, x), if x= 0

(“active”, σ –e, job), if x!= 0

δint(s ) = (“active”, σ, job)

λ(“active,” σ, job)= {“store”, “respond” }

t a(phase, σ, job) = σ

The architecture of the discrete domain interface and the continuousdomain interface are also formally defined as a set of coupled modules For-mal descriptions for DDI and CDI respect the coupled module DEVS formal-ism Each element of the structure follows the concepts presented in Section16.6.1 and that were applied for the overall continuous/discrete simulationinterface

16.6.7 Analysis of the Simulation Tools for the Integration

in the Co-Simulation Framework

The previous steps that describe the gradual formal definition of the lation interfaces and the required library elements are independent of thedifferent simulation tools and specification languages used generally forthe specification/execution of the continuous and discrete subsystems Afterthe analysis of the existing tools we found that Simulink is an illustra-tive example of a continuous simulator enabling the control functionalitiesthat were presented in Section 16.4.5 These functionalities can be added ingeneric library blocks and a given Simulink model may be prepared for theco-simulation by parameterization and addition of these blocks

simu-Several discrete simulators present the characteristics detailed in Section16.4.5 SystemC is an illustrative example Since it is an open source, SystemCenables the addition of the presented functionalities in an efficient way—thescheduler can be modified and adapted for co-simulation In this way, the co-simulation overhead may be minimized However, the addition of simula-tion interfaces is more difficult than in Simulink because the specifications inSystemC are textual and a code generator is required to facilitate the addition

of simulation interfaces The automatic generation of the co-simulation faces is very suitable, since their design is time consuming and an importantsource of errors The strategy currently used is based on the configuration ofthe components and their assembly These components are selected from aco-simulation library

inter-16.6.8 Implementation of the Library Elements Specific

to Different Simulation Tools

The implementation for the validation of continuous/discrete systems wasrealized using SystemC for the discrete simulation models and Simulink forthe continuous simulation models

For Simulink, the interfaces are functional blocks programmed in C++using S-Functions [24] These blocks are manipulated like all other compo-nents of the Simulink library They contain input/output ports compatiblewith all model ports that can be connected directly using Simulink signals.The user starts by dragging the interfaces from the interface componentslibrary into the model’s window, then parameterizes them, and finally con-nects them to the inputs and the outputs of his model

For SystemC, in order to increase the simulation performance, part ofthe synchronization functionality has been implemented at the scheduler’slevel, which is a part of the state event management and the end of the dis-crete cycle detection (detects that there are no more delta cycles at the cur-rent time) For the generation of the co-simulation interfaces for SystemC,the implementation of a code generator was necessary This script has asinput user-defined parameters such as sampling periods, number and type

of ports, and synchronization ports

16.7 Formalization and Verification of the Interfaces

One of the key issues for the automatic generation of co-simulation faces is the rigorous definition of the behavior and architecture of simula-tion interfaces and this can be achieved by their formalization and formalverification in terms of behavior Formal definitions can be used to developeasy-to-verify designs [16] On this mathematical foundation one can definethe criteria that allows for the automatic selection of the components fromthe co-simulation library and the automatic generation of the co-simulationinterfaces This section presents the formalization and the verification of theco-simulation interfaces

inter-16.7.1 Discrete Simulator Interface

This section presents the operational semantics of the discrete simulationinterfaces (DSI) The semantics were defined with respect to the synchroniza-tion model presented in Section 16.6.1, using the DEVS formalism Table 16.2presents a set of rules that show the transitions between states

For all the rules, the semantics of the global variable flag is related to the

context switch between the continuous and discrete simulators When theflag is set to “1,” the discrete simulator is executed When it is “0,” the con-

tinuous simulator is executed The global variable synch is used to impose

TABLE 16.2

Operational Semantics for the DSI

1. synch = 1 ∧ flag = 1 ∧ (x dk , t dk ) = δext((x dk , t dk ), 0, x)

((x dk ,t dk ), ∞) ?DataFromDisc −−−−−−−→ ((x dk , t dk ), 0) !(data,tdk −−−−−−−−−−−−−−−−→ ((x+1((x dk,tdk )));flag:=0 dk , t dk ), t dk+1)

2. synch = 0 ∧ flag = 1 ∧ ¬stateevent ∧ (x dk , t dk ) = δext((x dk , t dk ), 0, x)

((x dk , t dk ), e dk ) ?Event −−→ ((x dk , t dk ), 0) ?data;synch:=1 −−−−−−−→ ((x dk , t dk ), 0) !DataToDisc −−−−−−→ ((x dk+1, t dk+1), e dk+1)

3. synch = 0 ∧ flag = 1 ∧ stateevent ∧ (x dk , t dk ) = δext((x dk , t dk ), 0, x)

((x dk , t dk ), e dk ) ?Event −−→ ((x dk , t dk ), 0)?(data,tse);synch:=1

−−−−−−−−−−→ ((x dk , t dk ), 0) !(DataToDisc,tse)

−−−−−−−−→ ((xse, tse), ese)

the order of the different operations expressed by the rules The first rulecovers arrow 1 in Figure 16.5a and b The second and third rules correspond

to arrows 3 (on the receiving part) and 4 in Figure 16.5a and b

In order to clarify, we present here the first rule in detail The premises of

this rule are: the synch variable has value “1,” the flag variable has value “1,”

and we have an external transition function (δext) for the DSI.

This rule expresses the following actions of the discrete simulator face (DSI):

inter-• Receiving data from the discrete model This is an external transition(δext ) expressed by ?(DataFromDisc).

• Sending data to the continuous simulator interface (CSI) (!DataToCSI).

The data sent to the CSI is the output function λ(x dk ,t dk ) and it is

possible, in accordance with DEVS formalism, only as a consequence

of an internal transition (δint ) In our case, the output is represented

by !(data,t dk+1(x dk ,t dk )) This transition corresponds to arrow 1 in

Fig-ure 16.5a and b

• Switching the simulation context from the discrete to the continuous

domain (action expressed by flag: = 0).

All the other rules presented in this table follow the same format [13]

3 synch = 0 ∧ flag = 0 ∧ stateevent ∧ q k+1= δint(q k )

(x ck , t ck )?−−−−−−−−−−→ (x (DataFromCont) ck , t ck ) !(data,tse);flag:=1

−−−−−−−−−−→ (se, tse)

16.7.2 Continuous Simulator Interface

The operational semantics for the CSI is given by the set of rules presented

in Table 16.3 In these rules, the Data notation refers to the data exchanged

between the DSI and the discrete simulator All the rules presented in Table16.3 can be explained analogously to the one already illustrated in Section16.7.1

16.8 Implementation Stage: CODIS a C/D

Co-Simulation Framework

In Section 16.4, we proposed a generic methodology, in two stages, for theefficient design of C/D co-simulation tools These stages are: a generic stageand an implementation stage The generic stage, divided in four steps, waspresented in detail and applied in Sections 16.4.1 through 16.4.4 and Sections16.6.3 through 16.6.6

This section presents, CODIS [5], a tool for the generation of tion models in more detail This tool can automatically produce the globalsimulation model instances for C/D systems simulation using SystemC andSimulink simulators This is done by generating and providing the interfacesthat implement the simulation model layers and building the co-simulationbus In the development of this framework, the generic steps of the method-ology that we presented in detail in this chapter are “hidden” in differentstages of the simulation flow The “definition of the library elements andthe internal architecture of the co-simulation interfaces” step represents thefoundation for the generation of the co-simulation library and implicitly forthe generation of the co-simulation interfaces The internal architecture ofthe interfaces respects the definition of the operational semantics, the distri-bution of the synchronization functionality, as well as the synchronizationmodel

simula-Figure 16.14 gives an overview of the flow of the instance generation

in the case of CODIS The inputs in the flow are the continuous model inSimulink and the discrete model in SystemC which are schematic and textualmodels, respectively The output of the flow is the global simulation model(co-simulation model) instance

For Simulink, the interfaces can be parameterized starting with their log box The user starts by dragging the interfaces from the interface compo-nents library into the model’s window, then parameterizes them, and finallyconnects them to the inputs and the outputs of the model Before the sim-ulation, the functionalities of these blocks are loaded by Simulink from the.dll libraries The parameters of the interfaces are the number of input andoutput ports, their type, and the number of state events

Parametrized interfaces

Simulation library SystemC model

SystemC model

Co-simulation bus

Simulink model

Simulink model Simulation interface

Simulation interface

Inter-For SystemC, the interface parameters are: the names, the number and thedata type of the discrete model inputs ports and the sampling periods Theinterfaces are automatically generated by a script generator that has as inputthe user-defined parameters The tool also generates the function sc_main (ormodifies the existing sc_main) that connects the interfaces to the user model.The model is compiled and the link editor calls the library from SystemC and

a static library (the simulation library in Figure 16.14)

16.9 Conclusion

This chapter presented a generic methodology for the design of efficientcontinuous/discrete co-simulation tools The methodology can be divided

into two main stages: (1) a generic stage, defining simulation interfacefunctionality in a conceptual framework when formal methods for thespecification and validation are used, and (2) a stage that provides the imple-mentation for the rigorously defined functionality Given the importance

of the simulation interfaces, the methodology concentrates on the simulation interfaces, their behavior, as well as the synchronization theyassure in the global validation of a C/D heterogeneous system

co-We also present here a formal representation of the functionality of eachinterface independent of the other

We illustrate the methodology with CODIS, a tool for C/D systems simulation In the development of CODIS, all the steps of the methodology

co-we proposed in this paper are “hidden” in different stages of the tion flow The “definition of the library elements and the internal architec-ture of the co-simulation interfaces” step represents the foundation for thegeneration of the co-simulation library and implicitly for the co-simulationinterfaces generation The definition of the operational semantics and the dis-tribution of the synchronization functionality as well as their behavior play

simula-an importsimula-ant role at the output flow with the behavior of the co-simulationinterfaces and the synchronization model The “analysis of the simulationtools for the integration in the co-simulation framework” helped choosingthe tools that were used for the modeling of the continuous and the discretesimulators while the “implementation of the library elements specific to dif-ferent simulation tools” constitutes the final implementation of the libraries

References

1 R Alur and D Dill, Automata for modeling real-time systems, in ings of the Seventeenth International Colloquium on Automata , Languages and Programming, Warwick University, England, 1990, Vol 443, pp 322–335

Proceed-2 G Behrmann, A David, and K Larsen, A tutorial on UPPAAL, Real-Time Systems Symposium, Miami, FL, 2005

3 J Bengtsson and W Yi, Timed automata: Semantics, algorithms andtools, Uppsala University, Uppsala, Denmark, 1996

4 J.-S Bolduc and H Vangheluwe, The modelling and simulation age PythonDEVS for classical hierarchical DEVS MSDL technical reportMSDL-TR-2001-01, McGill University, Montreal, Quebec, Canada, June2001

pack-5 F Bouchhima, G Nicolescu, M Aboulhamid, and M Abid, Genericdiscrete–continuous simulation model for accurate validation in hetero-

geneous systems design, Microelectronics Journal, 38, 2007, 805–815.

6 C G Cassandras, Discrete Event Systems: Modeling and Performance ysis, Richard Irwin, New York, 1993.

Anal-7 F E Cellier, Combined continuous/discrete system simulation

languages—usefulness, experiences and future development, ogy in Systems Modelling and Simulation North-Holland, Amsterdam, theNetherlands, 1979, pp 201–220

Methodol-8 M D’Abreu and G Wainer, M/CD++: Modeling continuous systems

using Modelica and DEVS, in Proceedings of the IEEE International posium of MASCOTS’05, Atlanta, GA, 2005, pp 229–238

Sym-9 S Edwards, L Lavagno, E Lee, and A L Sangiovanni-Vincentelli,Design of embedded systems: Formal models, validation, and synthesis,

Proceedings of the IEEE, 85, 1997, 366–390

10 P Frey and D O’Riordan, Verilog-AMS: Mixed-signal simulation and

cross domain connect modules, in Proceedings BMAS International shop, Orlando, FL, 2000, pp 103–108

Work-11 H R Ghasemi and Z Navabi, An effective VHDL-AMS simulation

algo-rithm with event, in International Conference on VLSI Design, Kolkata,

13 L Gheorghe, F Bouchhima, G Nicolescu, and H Boucheneb, Semantics

for model-based validation of continuous/discrete systems, in ings of the DATE, Munich, Germany, 2008, pp 498–503

Proceed-14 N Giambiasi, J.-L Paillet, and F Chane, From timed automata to DEVS,

in Proceedings of the 2003 Winter Simulation Conference, New Orleans, LA,

17 A Jantsch and I Sander, Models of computation and languages for

embedded system design, IEE Proceedings Computers and Digital niques, 152, 2005,114–129

Tech-18 A Jantsch, Modeling Embedded Systems and SoCs—Concurrency and Time in Models of Computation Systems on Silicon Morgan Kaufmann Publishers,

San Francisco, CA, June 2003

19 T G Kim, DEVSim++ User’s Manual, SMSLab, Dept of EECS, KAIST,

Taejon, Korea, 1994, http://smslab.kaist.ac.kr

20 Y J Kim, J H Kim, and T G Kim, Heterogeneous simulation framework

using DEVS-BUS, in Simulation, the Society for Modeling and Simulation International, 79, 2003, 3–18

21 E A Lee and H Zheng, Operational semantics of hybrid systems,

in Hybrid Systems: Computation and Control: 8th International Workshop, HSCC, Zurich, Switzerland, 2005, pp 25–53

22 E A Lee and A L Sangiovanni-Vincentelli, Comparing models of

com-putation, in IEEE Proceedings of the International Conference on Aided Design (ICCAD), San Jose, CA, 1996, pp 234–241

Computer-23 S Levitan, J Martinez, T Kurzveg, P Marchand, and D Chiarulli, Multi

technology system-level simulation, Analog Integrated Circuits and Signal Processing, 29, 2001, 127–149

24 MATLAB-Simulink [Online] Available at: www.mathworks.com

25 J.-F Monin, Understanding Formal Methods, Springer, Berlin, 2003.

26 G Nicolescu et al., Validation in a component-based design flow for

mul-ticore SoCs, in Proceedings of ISSS, Kyoto, Japan, 2002, pp 162–167.

27 D H Patel and S K Shukla, SystemC Kernel—Extensions for Heterogeneous System Modeling, Kluwer Academic Publishers, Dordrecht, the Nether-lands, 2004

28 Ptolemy project [Online] Available at: http://ptolemy.eecs.berkeley.edu/

29 S Romitti, C Santoni, and P François, A design methodology and a

pro-totyping tool dedicated to adaptive interface generation, in Proceedings

of the 3rd ERCIM Workshop on “User Interfaces for All”, Obernai, France,1997

30 SystemC LRM [Online] Available at: www.systemc.org

31 SystemVerilog [Online] Available at: www.systemverilog.org

32 A Vachoux, C Grimm, and K Einwich, Analog and mixed signal

model-ing with SystemC-AMS, in Proceedmodel-ings International on Symposium Circuits System, Bangkok, Thailand, 2003, pp 914–917

33 VHDL [Online] Available at: www.vhdl.org

34 B P Zeigler, H Praehofer, and T G Kim, Modeling and Simulation— Integrating Discrete Event and Continuous Complex Dynamic Systems, Aca-demic Press, San Diego, CA, 2000

35 G Wainer, Modeling and simulation of complex systems with cell-DEVS,

in Winter Simulation Conference, Washington, DC, 2004, pp 49–60.

36 F Wang, Formal verification of times systems: A survey and perspective,

Proceedings of the IEEE, 92, 2004, 1283–1305

Modeling and Simulation of Mixed

Continuous and Discrete Systems

Edward A Lee and Haiyang Zheng

CONTENTS

17.1 Introduction 559

17.2 Related Work 560

17.3 Actor-Oriented Models 561

17.4 Actor Abstract Semantics 563

17.5 Synchronous/Reactive Models 566

17.6 Discrete-Event Models 568

17.7 Continuous-Time Models 573

17.8 Software Implementation 576

17.9 Conclusions 578

Acknowledgments 578

References 579

17.1 Introduction

An embedded system mixes digital controllers realized in hardware and soft-ware with the continuous dynamics of physical systems [30] Such systems are semantically heterogeneous, combining continuous dynamics, periodic timed actions, and asynchronous event reactions Modeling and design of such heterogeneous systems is challenging A number of researchers have

defined concurrent models of computation (MoCs) that support modeling,

specification, and design of such systems [11,22,26,28,34]

A variety of approaches have been tried for dealing with the intrin-sic heterogeneity of embedded systems This chapter describes a particu-larly useful combination of semantics, providing a disciplined and rigorous mixture of synchronous/reactive (SR) systems [4], discrete-event (DE) sys-tems [13,19,29,49], and continuous-time (CT) dynamics [20,35,42,46] Our approach embraces heterogeneity, in that subsystems can be modeled using any of the three semantics, and these subsystem models can be combined

hierarchically to form a whole system We leverage the idea of an actor

abstract semantics [33] to provide a coherent and rigorous meaning for

the heterogeneous system Our approach also provides improvements toconventional DE and CT semantics by leveraging the principles of SR lan-guages These improvements facilitate the heterogeneous combination of thethree distinct modeling styles.

mod-domain-specific ways, and also introduced quantity managers that provide

a unified approach to resource management in heterogeneous systems.Our approach in this chapter is closest in spirit to SML-Sys [41], whichbuilds on Standard ML to provide for mixtures of MoCs SML-Sys combinesasynchronous models (dataflow models) with synchronous models (whichthe authors call “timed”) Our approach, in contrast, combines only timedmodels, including both DE and CT dynamics

A particular form of heterogeneous systems, hybrid systems provide forjoint modeling of continuous and discrete dynamics A few software toolshave been built to provide simulation of hybrid systems, including Charon[2], Hysdel [47], HyVisual [10], ModelicaTM[46], Scicos [16], Shift [15], andSimulink R/StateflowTM(from The MathWorks) An excellent analysis andcomparison of these tools is given by Carloni et al [12] We have previ-ously extensively studied the semantics of hybrid systems as heterogenouscombinations of finite state machines (FSM) and continuous dynamics [35].Our approach in this chapter extends this to include SR and DE models Wefocus here on the interactions between SR, DE, and CT, because the interactionsbetweenFSMandSR,DE,andCThavealreadybeenextensivelystudied[21,35].Several authors advocate unified MoCs as a binding agent for hetero-geneous models [3,9,23] Heterogeneous designs are expressed in terms of

a common semantics Some software systems, such as Simulink from TheMathWorks, take the approach of supporting a general MoC (CT systems

in the case of Simulink) within which more specialized behaviors (like odic discrete-time) can be simulated The specialized behaviors amount to

peri-a design style or design pperi-attern within peri-a single unified semperi-antics

Con-formance to design styles within this unified semantics can result in els from which effective embedded software can be synthesized, using, forexample, Real-Time WorkshopTMor TargetLinkTMfrom dSpace

For Simulink,... interfaces and this can be achieved by their formalization and formalverification in terms of behavior Formal definitions can be used to developeasy-to-verify designs [16] On this mathematical foundation