Description of the concept of Embedded System
The family of embedded systems is a variant of reactive systems given that they are governed by the same computing rules. However, a peculiarity of embedded systems lies in the fact that they jointly incorporate software (SW) and hardware (HW) parts, which gives them a heterogeneous appearance.
Quote: \An embedded system is an engineering artifact involving computation that is subject to physical constraints. The physical constraints arise through the two ways that computational processes interact with the physical world: reaction to a physical environment and execution on a physical platform » . From a platform point of view, this denition highlights the heterogeneous nature of the EmS dened as interacting HW/SW parts. The heterogeneity is accentuated by the diversity of the types of integrated SW and HW. The software programs are mainly supported by Real Time Operating Systems (RTOS), Middleware, Internet Modules, Graphical User Interfaces (GUI) , and so on; the platforms are mainly composed of Processors, Memories, Mass storages, Sensors, Actuators, etc. However, even being composed of dierent modules, the objective of an embedded system is unique over time. They thus accomplish a repetitive task whenever they are accessed by their environment.
Quote: \An Embedded System (EmS) is an electronic system with dedicated function- ality built into its HW and SW. The HW is microprocessor-based, and uses some memory to keep the SW and data. It provides an interface to the world or system it is part of. In most cases, it is a part of a larger heterogeneous system where it plays a computing, measuring, controlling and monitoring role. »  Nowadays, embedded systems are present in several sectors e.g. avionics/ the automotive industry, mobile telephony, networks, etc. (Figure 2.1). The design of systems in each domain is based on design requirements of the domain (e.g. standards, consumption and space constraints). Each requirement is a realization constraint that may even have an impact on the choice of the HW for its design. Constraints are various i.e. functional, non-functional (HW constraints, performance, power consumption), etc. Based on the business domains, sub-classes of EmS are identied such as Real Time EmS (RTES) and critical EmS . An RTES   imposes functioning or reaction constraints on a xed time basis. Such a system is doubly constrained by the behavior it must achieve and the time of realization of the behavior. For example, the braking system of a car integrates EmS with real time constraints e.g. a braking from environmental action should provoke a reaction taking into account appropriate braking delays (required by the system). A braking action is performed from the environment; accordingly the system must be designed to respond to such a request in real time.
With these strong critical constraints, the description of the design ow of such a system must not neglect any aspect having an impact on the reaction time of the nal system to be implemented. Therefore, the modules produced in the chain must be precise as regards to the functionality they perform and their interaction must be handled throughout the design process. For the critical systems, any misinterpretation of constraints can lead to tragic consequences  (physical damage or serious economic damage). For example the railway signal systems are critical systems.
Evolution of Embedded System
Between the 1960s and the 1990s, the use of embedded systems experienced unprecedented growth. Indeed, we saw the emergence of new electronic components to facilitate the design of systems and master their complexity. For example, in the 1980’s, DSP processors (rst single chip 1980, NEC PD7720 and AT & T DSP1) and FPGAS were designed with component integration capabilities such as microprograms, specialized and recongurable circuits. More broadly, to meet space and portability constraints (while maintaining the capacity of the EmS); we witnessed the emergence of Systemon- Chips (SoCs) . SoCs allow the integration of whole system in a single chip of reduced size. These chips can integrate (DSP, FPGA, Converters Analog/Digital and Digital/Analog, control modules (micro-controllers), etc) otherwise known as Intellectual Property (IP). Figure 2.2 proposes a description of the abstraction of a system on chip SoC based on . As a result, several features are now integrated and designed in the form of a package or IP. This modular component interconnection approach creates interfacing requirements . For interfacing to components, during the last decades, several eorts to standardize HW parts have led to the realization of communication modules such as (VMEBus , PCIbus , Avalon Bus  of Altera) for the boardbased systems. At the time, this enabled more complex systems to be developed. Such evolution was predicted by Moore’s law in 1965 on the possibility of doubling the number of transistors in chips every 18 months in the years to come. The complexity of the system design depends strongly on the diversity and size of the SW and HW. The larger and more heterogeneous the system, the more the technologies required for their design are sophisticated and complex (DSPs, FPGAs, Shared Memory, etc). Other factors such as space restrictions and Energy consumed also have an impact on the design choices.
Embedded System Design and Implementation
With the old development methods HW and SW partitioning was very early in the design process. Each engineer used to work in isolation and independently, and then integrated the various modules in late stages. The use of this same process with the current complex systems is problematic because the addition of new features involves an increasing number of engineering domains. As a consequence, the systems integration phases are tedious and error prone. Searching for errors at this level is very timeconsuming. Quote: \Designing embedded systems requires addressing concurrently dierent engi- neering domains, e.g. mechanics, sensors, actuators, analog/digital electronic hardware, and software. » 
Design Methodologies and Design Flows
To compensate for these dierent breaches, the development processes were improved to allow, the earliest possible, consideration of the issues related to the heterogeneity of the systems as well as their verication and validation.
Improved Methodologies for improved Design Flows
The major trends for harmonized system design advocate raising the abstraction of system models to provide a common reasoning framework for the dierent stakeholders of the development process. This reasoning framework facilitates decision-making after consultation between engineers and the partitioning comes at very late design stages. In fact, several levels of abstraction are dened, allowing successive model renement steps to be included up to the implementation. This process also allows the design of systems that are correct-by-construction with the activities of analysis and validation of models at each level (Figure 2.3).
Raising the level of Abstraction
Higher levels of abstraction are recommended in all communities developing complex systems. They are parts of the techniques to abstract away the bulky properties. Thus, designers have the opportunity not only to focus on specic parts of the system, but also to opt for an incremental approach for design, where models are rened on several levels of abstraction. With abstraction, designers reason, analyze and validate a particular aspect of a system.
Moreover, development on several levels of abstraction greatly improves the \debugging » phases because it allows errors to be located more easily. Unfortunately, one of the main issues is to dene and x the aspects related to the interaction or exchange of data between dierent modules at each abstraction level, which is our motivation in this thesis. To this end, the management of concurrency and communication on dierent levels of abstraction also allows the development of the mechanisms of execution control and synchronization of applications before their synthesis on a highly parallel architecture. In addition, the separation of the computation and communication allows a clearer description of the system modules and their interactions.
Separation of Concerns
The separation of concerns is complementary with the abstraction/renement approach. Separation of concerns is a design principle that promotes the separation of the system into several autonomous entities each addressing a particular problem. The entities (or modules) are given to qualied engineers that implement solutions for each problem. Besides, the integration phase of entities is a mandatory step because it can aect the overall system behavior.
In this approach, at each level of abstraction, designers use virtual models representing architectures and virtual structures for analysis of the models. While abstracting the description of architectures and behaviors, users also separate the communication rules.
Table of contents :
1.1.1 Current EmS Design Trends
1.1.2 Integration Framework Requirements
1.2 Problematic and Motivation
1.2.1 Relationships between Tools from a Semantics Viewpoint
1.3.1 Making MoC explicit for behaviors and semantics preservation between models
1.3.2 Compositionality between Heterogeneous Semantics based on MoC Classication
1.3.3 Dening a formalism to express MoC-Based Execution Control .
1.4 Document Layout
2 Real Time Embedded Systems Design
2.2 Historical study and basic concepts for Embedded Systems
2.2.1 Description of the concept of Embedded System
2.2.2 Evolution of Embedded System
2.3 Embedded System Design and Implementation
2.3.1 Design Methodologies and Design Flows
188.8.131.52 Improved Methodologies for improved Design Flows .
184.108.40.206.a Raising the level of Abstraction
220.127.116.11.b Separation of Concerns
18.104.22.168.c IP Reuse
22.214.171.124.d Analysis, Verication and Validation
126.96.36.199 Well-Known Foundations for Embedded System Design
188.8.131.52.a Electronic System Level
184.108.40.206.b Platform-Based Design
220.127.116.11 Examples of Frameworks for RTES
2.3.2 From Design Automation to building Tool Chains for RTES .
2.3.3 Interoperability and Integration for Embedded System Design .
18.104.22.168 Tool Interoperability in the RTES
22.214.171.124 Tool Interoperability within Tool Integration
126.96.36.199.a Common Design Flow Infrastructure (CDFI)
188.8.131.52.b Levels of Conceptual InteroperabilityModel (LCIM)
2.3.4 Remaining Issues
3 Towards Formal Semantics in MDE
3.2 Model-Driven Engineering
3.2.1 MDE principles and basic concepts
184.108.40.206 Models, Metamodels
220.127.116.11 Relations between Models, Metamodels and Meta-Metamodels
3.2.2 Model Transformation
3.2.3 MDE methodologies and Standards
18.104.22.168 Other Standards
3.3 Semantics in General and Semantics in MDE
3.3.1 The types of Semantics
22.214.171.124 Axiomatic Semantic
126.96.36.199 Denotational Semantics
188.8.131.52 Operational Semantics
3.3.2 Semantic expression in MDE
184.108.40.206 Dening OCL constraints for models
3.4 The MoC Theory
3.4.1 Data-Flow Oriented MoCs
3.4.2 Control-Flow Oriented MoCs
3.4.3 MoC Classication
3.4.4 MoC Composition
3.4.5 Frameworks for System Design based on MoCs
3.5 MoC in the context of MDE
4 The Cometa Concepts, Models and Validation
4.2 Foundations of the Cometa Approach
4.2.1 Semantic Layer Denition
4.2.2 The system’s MoC characterization
4.2.3 Formal Description of the Cometa concepts
220.127.116.11 Structure Description
18.104.22.168.a Cometa StructureLibrary
22.214.171.124.b Cometa StructureContainer
126.96.36.199.c Cometa MoCConnector
188.8.131.52.d Cometa MoCComponent
184.108.40.206.e Cometa BasicComponent
220.127.116.11.f Cometa CompositeComponent
18.104.22.168.g Cometa Part
22.214.171.124.h Cometa MoCPort
126.96.36.199.i Semantic Layer Congurations
188.8.131.52 Execution Control Description
184.108.40.206.a Cometa MoCLibrary
220.127.116.11.b Cometa MoCDomain
18.104.22.168.c Cometa MoCEvent
22.214.171.124.d Cometa Behavior
126.96.36.199 Data Description
188.8.131.52 Relationships between Structure, Execution Control and Data
184.108.40.206.a Between Structure and Behavior
220.127.116.11.b Between Structure and Data
18.104.22.168 Description of the Cometa Interfaces to other DSML
22.214.171.124.a Specication of MoCInterface
126.96.36.199.b Specication of RTInterface
4.2.4 Operational Semantics: FSM-Based Control
188.8.131.52 Operation Semantics of the Block requests
184.108.40.206 Labelled Transition System for Cometa
4.3 Execution Control Mechanisms description
4.3.1 Scheduling in Cometa
220.127.116.11 Centralized scheduling in Cometa
18.104.22.168 Distributed Scheduling in Cometa
4.3.2 Methodology for Applying Semantic Layers
22.214.171.124 Application of semantic layers: from MoC Aware to MoC Unaware tools
126.96.36.199 Rules to Identify MoC relations and Compliance
4.3.3 MoC Semantics Modeling with Cometa: Sender/Receiver with CSP
188.8.131.52 Mathematical validation
184.108.40.206 By Simulation
4.3.4 Time Description: Time-Based Control
220.127.116.11 Cometa TimeModel
18.104.22.168 Cometa TimeStructure
22.214.171.124 Cometa TimeBase
126.96.36.199 Cometa Instant
188.8.131.52 Cometa ClockType
184.108.40.206 Cometa ClockConstraint
220.127.116.11 Cometa ClockRelation
5 Semantics Interoperability and Experimentation
5.2 Integrating Semantic Layers into Design Flows
5.2.1 Overview of the Approach
5.2.2 Dening a Tool Chain for a Radar Streaming Application .
18.104.22.168 Description of the Radar Streaming Application .
22.214.171.124 Focus on The Radar Burst Processing Application .
126.96.36.199 Tool Selection for the Design Flow
188.8.131.52.a Design Process Activities
184.108.40.206.b Tool Description
220.127.116.11.c The envisioned Design Flow
18.104.22.168 Semantic constraints
22.214.171.124.a Explicit Model Semantics
126.96.36.199.b Explicit Tool Semantics
188.8.131.52 Analysis of the Semantic Compliancy between Tools
5.3 A Novel Design Flow connecting: Rhapsody, Spear and ForSyDe .
5.3.1 Capturing Semantic Layers for the Design Flow
5.3.2 Weaving Cometa Models with IBM Rhapsody
5.3.3 Connecting the Tools within the Tool Chain
184.108.40.206 Connecting Rhapsody and ForSyDe-SystemC
220.127.116.11.b Transformation rule patterns: Rhapsody/ ForSydeSystemC
18.104.22.168 Connecting Rhapsody and ForSyDe-Backend
22.214.171.124.b Transformation rule patterns: Rhapsody/ ForSydeBackEnd
126.96.36.199 Connecting Rhapsody and SpearDE
188.8.131.52.b Transformation rule patterns: Rhapsody/ SpearDE
5.3.5 Burst Processing System Design and Analysis
184.108.40.206 Transformation results from Rhapsody to ForSyDe and Spear
220.127.116.11 Generation of NoC architecture for ForSyDe BackEnd .
18.104.22.168 Generation of Spear model of the BurstProcessing module
6 Conclusions and Perspectives
6.2.1 Denition of an Execution Engine
6.2.2 From Denotational semantics to formal MoC model description .
6.2.3 Dierential Equation Description
A.1 Metamodel Excerpts
A.1.1 Spear Excerpt
A.1.2 ForSyDe front-end Metamodel Excerpt
A.1.3 NoC Mapping Metamodel Excerpt
A.1.4 NoC Generator Metamodel Excerpt
A.2 Sample of Models
A.2.1 Sample of Mapping Model for the UseCase . .