Project topics and materials
Get Complete Project Material File(s) Now! »
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 » [76]. 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) [192], 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. » [192] 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 [208]. An RTES [184] [119] 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 [187] (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) [192]. 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 [89]. 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 [192]. 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 [122], PCIbus [28], Avalon Bus [4] 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. » [51]
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 Introduction
1.1 Context
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.2.2 Summary
1.3 Contributions
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.1 Introduction
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
2.3.1.1 Improved Methodologies for improved Design Flows .
2.3.1.1.a Raising the level of Abstraction
2.3.1.1.b Separation of Concerns
2.3.1.1.c IP Reuse
2.3.1.1.d Analysis, Verication and Validation
2.3.1.2 Well-Known Foundations for Embedded System Design
2.3.1.2.a Electronic System Level
2.3.1.2.b Platform-Based Design
2.3.1.3 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 .
2.3.3.1 Tool Interoperability in the RTES
2.3.3.2 Tool Interoperability within Tool Integration
2.3.3.2.a Common Design Flow Infrastructure (CDFI)
2.3.3.2.b Levels of Conceptual InteroperabilityModel (LCIM)
2.3.3.3 Summary
2.3.4 Remaining Issues
2.4 Conclusion
3 Towards Formal Semantics in MDE
3.1 Introduction
3.2 Model-Driven Engineering
3.2.1 MDE principles and basic concepts
3.2.1.1 Models, Metamodels
3.2.1.2 Relations between Models, Metamodels and Meta-Metamodels
3.2.2 Model Transformation
3.2.3 MDE methodologies and Standards
3.2.3.1 MDA
3.2.3.2 Other Standards
3.2.4 Challenges
3.3 Semantics in General and Semantics in MDE
3.3.1 The types of Semantics
3.3.1.1 Axiomatic Semantic
3.3.1.2 Denotational Semantics
3.3.1.3 Operational Semantics
3.3.2 Semantic expression in MDE
3.3.2.1 Dening OCL constraints for models
3.3.2.2 Kermeta
3.3.2.3 fUML
3.3.3 Challenges
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
3.5.1 MARTE
3.5.2 SysML
3.5.3 MoPCoM
3.5.4 Metropilis
3.5.5 Challenges
3.6 Conclusion
4 The Cometa Concepts, Models and Validation
4.1 Introduction
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
4.2.3.1 Structure Description
4.2.3.1.a Cometa StructureLibrary
4.2.3.1.b Cometa StructureContainer
4.2.3.1.c Cometa MoCConnector
4.2.3.1.d Cometa MoCComponent
4.2.3.1.e Cometa BasicComponent
4.2.3.1.f Cometa CompositeComponent
4.2.3.1.g Cometa Part
4.2.3.1.h Cometa MoCPort
4.2.3.1.i Semantic Layer Congurations
4.2.3.2 Execution Control Description
4.2.3.2.a Cometa MoCLibrary
4.2.3.2.b Cometa MoCDomain
4.2.3.2.c Cometa MoCEvent
4.2.3.2.d Cometa Behavior
4.2.3.3 Data Description
4.2.3.4 Relationships between Structure, Execution Control and Data
4.2.3.4.a Between Structure and Behavior
4.2.3.4.b Between Structure and Data
4.2.3.5 Description of the Cometa Interfaces to other DSML
4.2.3.5.a Specication of MoCInterface
4.2.3.5.b Specication of RTInterface
4.2.4 Operational Semantics: FSM-Based Control
4.2.4.1 Operation Semantics of the Block requests
4.2.4.2 Labelled Transition System for Cometa
4.3 Execution Control Mechanisms description
4.3.1 Scheduling in Cometa
4.3.1.1 Centralized scheduling in Cometa
4.3.1.2 Distributed Scheduling in Cometa
4.3.2 Methodology for Applying Semantic Layers
4.3.2.1 Application of semantic layers: from MoC Aware to MoC Unaware tools
4.3.2.2 Rules to Identify MoC relations and Compliance
4.3.3 MoC Semantics Modeling with Cometa: Sender/Receiver with CSP
4.3.3.1 Mathematical validation
4.3.3.2 By Simulation
4.3.4 Time Description: Time-Based Control
4.3.4.1 Cometa TimeModel
4.3.4.2 Cometa TimeStructure
4.3.4.3 Cometa TimeBase
4.3.4.4 Cometa Instant
4.3.4.5 Cometa ClockType
4.3.4.6 Cometa ClockConstraint
4.3.4.7 Cometa ClockRelation
4.4 Conclusion
5 Semantics Interoperability and Experimentation
5.1 Introduction
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 .
5.2.2.1 Description of the Radar Streaming Application .
5.2.2.2 Focus on The Radar Burst Processing Application .
5.2.2.3 Tool Selection for the Design Flow
5.2.2.3.a Design Process Activities
5.2.2.3.b Tool Description
5.2.2.3.c The envisioned Design Flow
5.2.2.4 Semantic constraints
5.2.2.4.a Explicit Model Semantics
5.2.2.4.b Explicit Tool Semantics
5.2.2.5 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
5.3.3.1 Connecting Rhapsody and ForSyDe-SystemC
5.3.3.1.a Overview
5.3.3.1.b Transformation rule patterns: Rhapsody/ ForSydeSystemC
5.3.3.2 Connecting Rhapsody and ForSyDe-Backend
5.3.3.2.a Overview
5.3.3.2.b Transformation rule patterns: Rhapsody/ ForSydeBackEnd
5.3.3.3 Connecting Rhapsody and SpearDE
5.3.3.3.a Overview
5.3.3.3.b Transformation rule patterns: Rhapsody/ SpearDE
5.3.4 Metrics
5.3.5 Burst Processing System Design and Analysis
5.3.5.1 Transformation results from Rhapsody to ForSyDe and Spear
5.3.5.2 Generation of NoC architecture for ForSyDe BackEnd .
5.3.5.3 Generation of Spear model of the BurstProcessing module
5.4 Conclusion
6 Conclusions and Perspectives
6.1 Conclusions
6.2 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
Appendices
A Appendix
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 . .
