1. Trang chủ
  2. » Công Nghệ Thông Tin

Model-Based Design for Embedded Systems- P19 pptx

30 435 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 30
Dung lượng 771,87 KB

Nội dung

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 [...]... receive 536 Model-Based Design for Embedded Systems clock differences With this transition, the variables are updated by r (reset), which is an action performed on clocks The actions are used for synchronization and are expressed by a (action) [3] A synchronization label is of the form Expression? or Expression! where ! represents the operator send and ? represents the operator receive The semantics for a... specified 16.4.3 Formalization and Verification of the Simulation Interfaces Behavior The formalization and verification of the simulation interfaces behavior stage can be roughly divided in three steps: formalization (that can be the formal specification of the heterogeneous system), the validation by model simulation, and the formal verification The two main techniques that can be used for the formal verification... that is an extension of CTL obtained by subscribing the modalities with time intervals specifying time restrictions on formulas For our formal model, the properties that need to be checked are branching properties that are expressed using CTL or TCTL logics 530 Model-Based Design for Embedded Systems Continuous/discrete global simulation model Continuous/discrete simulation interface Continuous model... the parallel DEVS coupled formalism Each module composing the interface performs a different task according to the synchronization model specified in Section 16.5 535 Generic Methodology for the Design 16.6.2 Timed Automata In this section we briefly introduce timed automata Chapter 14 gives a more detailed presentation of this formalism A timed automaton [1] is the formalism for modeling and verification... section introduces a methodology for the design of continuous/discrete co-simulation tools (as shown in Figure 16.3) To enable the design of co-simulation tools, this methodology presents several steps that are independent of the simulation tools used for the continuous and discrete Generic Methodology for the Design 527 Generic stage Definition of the operational semantics for the synchronization Distribution... ¬stateevent(t) ∧ q = δint (q) (sd , ed ) − − − − − − − − − → (sd , ed ); q − − − − − − − − − − q −−−−−−−−− − − − − − − − − −→ Rule TABLE 16.1 Operational Semantics for the C/D Synchronization Model Generic Methodology for the Design 537 538 Model-Based Design for Embedded Systems domain interface λ(sd ) The semantics of the global variable “flag” is related to the context switch between the continuous and discrete... interface 16.6.5 Formalization and Verification of the Simulation Interfaces Behavior This section presents details of the formalization and the formal verification of the behavior of the simulation interfaces using, as explained in Section 16.4, timed automata and TCTL In order to model, validate, and check our model we used UPPAAL [2] The main advantage of UPPAAL is 540 Model-Based Design for Embedded Systems... 544 Model-Based Design for Embedded Systems TimeOfStEv location is common for both cases, StateEvent=0 or StateEvent=1 This location changes to WaitDataFromDisc The system performs synchronization (DataToBus!) between the continuous interface and the continuous simulator The next location is Start, the continuous time variables is initialized on this channel (tc=tcn) and the cycle restarts 2 Formal... transition 534 Model-Based Design for Embedded Systems λ : S→Y output function ta : S→R+ set of positive reals with 0 and ∞ 0,∞ The system’s state at any time is s There are two possible situations: • Case 1—where we assume that no external events occur In this case the system stays in this state s for the time ta (s) When the elapsed time e equals ta (s) (that is the time allocated for the system... 528 Model-Based Design for Embedded Systems This section focuses on the generic stage and its steps will be detailed in the next subsections A possible implementation stage will be detailed further 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 . 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. 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. 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

Ngày đăng: 02/07/2014, 15:20

TỪ KHÓA LIÊN QUAN