【正文】 2011 Elsevier . All rights reservedKEY WORDS: Modeling, Model transformations, Embedded control systems design, Realtime systems1. IntroductionEmbedded control systems (ECSs) are ubiquitous nowadays. They are used in a broad spectrum of applications, from simple temperature control in household appliances to plex and safety–critical automotive brake systems or aircraft flight control systems. Different applications have different demands with regards to the realtime execution, control performance, energy consumption, price, etc., of the ECS being used. Modern technologies for hardware (HW) and software (SW) design provide a variety of possibilities for designing ECSs (., distributed and networked HW, multiprocessor systems, a variety of SW control algorithms and realtime operating systems (RTOSs), etc.) [1]. It is monly acknowledged that the designing and verifying of reliable and efficient ECSs for a particular application are challenging tasks.. Traditional controlsystem designThe aim of designing an ECS is to build a puting system that is able to control the behavior of a physical system, ., a plant. Such a plant is made up of interconnected mechanical, electrical and/or chemical elements. A typical ECS consists of electronic sensors for data acquisition from the plant, a puting system for processing the control algorithm, and electronic actuators to drive the plant.The ECS design process involves different actors and areas of expertise (control theory, signal processing, realtime SW and HW engineers). Each of these engineers is familiar with their own modeling languages, models, design tools, etc. This heterogeneity introduces cuts in the design process. Model transformations are needed between each design step。 this raises the embeddedsystem design process from a classical codeoriented development to a modeldriven development with automatic code generation. The tool relies on a proposed metamodel able to capture the three facet descriptions by defining a unified terminology and semantics to share the information without having to duplicate it. Thus, it ensures consistency between the models used in each design step by carrying out model transformations and reconciliation between the facets: each change in the facet description is automatically relayed to another one.The tool provides facilities for scheduling analysis and simulation as well as code generation for multiple targets. It includes an RT behavioranalysis module to check the scheduling feasibility (Rate Monotonic (RM), Deadline Monotonic (DM), Earliest Deadline First (EDF), etc.). It is also able to simulate and display, as a chronogram chart, the execution of tasks. The codegeneration and profiling module, which generates the source codes for the multiple RT kernels (RTAI [32], DSPBios [33] and realtime Java) and captures a real temporal execution trace, has also been implemented. The MoDEST tool also provides a timingmeasure module that performs latency, delay and jitter measurements on task execution. This temporal information can be used in hybrid simulations in order to estimate the loss of control performance. of the MoDEST implementation facetThe bridge between the MoDEST and ASyMod tools is based on rules defining the transformations between a subset of the MoDEST Metamodel (Implementation Facet part) and the ASyMod Metamodel. Since the goal of the paper is to describe the bridge, we will not present details of the whole MoDEST Metamodel but only of the subset relevant to the implementation facet. For the sake of simplicity, we shall term it the MoDEST Metamodel. A snippet of the metamodel is presented in Fig. 2.To define the metamodel, we use a graph notation. A dataflow graph (DFG) is a directed graph that represents the data dependencies between the numbers ofedges represent the data paths. The MultiPeriod DataFlow Graph (MPDFG) is a DFG extended with information about the RT execution constraints of the data operations. An MPDFG is a type of directed acyclic graph (DAG). In the MoDEST tool, a MPDFG M(IC, C, TM, R) is used to represent the implementation facet of embedded systems, where IC = {IComp1, ICompN} is a set of implementation ponents (IComps), C = {c1, cM} is a set of munications between the implementation ponents, TM = {tM1, tMO} is a set of tasks and R defines the task scheduler. IComps represent the nodes in the MPDFG and munication represents the edges between the nodes.IComp is a mathematical function that putes the outputs from the inputs. IComp can be presented as a tuple ICompn({ok, . . . ,ol}, {io,. . . , ip}), where {ok,. . . ,ol} is a list of all its outputs and {io,. . . , ip} is a list of all its inputs. The sets IM and OM are the sets of all the inputs and all the outputs of all the IComps in the model M.The shared variables are represented as munication. Communication is a data transfer between the output and the input of two distinct IComps. A munication is noted as (ok, il, type), where ok ? OM is the producer of the data, il ? IM is the consumer of the data and type defines the data type. Each munication can transfer only one data type, which can be chosen from a set of predefined types (char, integer, float, double).The tasks add RT execution constraints for periodicity, deadlines and priorities to a set of IComps. The execution of tasks in MoDEST is timetriggered, with each task defining a partition of IComps ? IC. Task can be expressed as the quintuple tMn (PMn, t0Mn, DMn, LMn, SeqMn ), where PMn is the task period, t0Mn is the starttime offset, DMn is the task deadline, LMn is the task priority and SeqMn={ICompq, . . . , ICompr} is an ordered sequence that defines the execution sequence of IComps that should be executed when the task is called at a runtime. The task scheduler is defined with the pair R={SchM, PreM}, where SchM defines the scheduling algorithm type from a predefined set of algorithms {RM,DM,EDF} and the bo