PUC - Campinas - SP, Brazil                    May 21 - 25, 2012     II BrazilianConference on Critical Embedded SystemsPr...
II Critical Embedded Systems School (CES-School)    II Brazilian Conference on Critical Embedded Systems (CBSEC 2012)Prefa...
Table of ContentsTutorialInteraction Control for Contact Robotics        Neville Hogan (MIT-USA)Invited CoursesThe “Why” a...
Interaction Control for Contact RoboticsNeville HoganSun Jae Professor of Mechanical EngineeringProfessor of Brain and Cog...
Model-Driven Engineering of Complex               Embedded Systems: Concepts and Tools                   Fl´ vio Rech Wagn...
representation can take advantage of the concept of transfor-         The method proposed in our MDE approach overcomesmat...
Fig. 3.   MDE context: principles, standards and tools                                                                    ...
•   The Computation Independent Model (CIM) focuses on          line that provides a production facility for the product f...
2) Concrete Syntax: A concrete syntax for a DSML (Do-             to engineer not only software, but entire systems, which...
mon metamodel. Following the platform-based approach [27],the Metropolis infrastructure captures application, architecture...
Fig. 5.   Application Model: UML Class Diagram                                                                            ...
Fig. 6.   UML Sequence Diagrams identified as: a) SD1; b) SD2; c) SD3                                                      ...
Fig. 12.   Mapping metamodel                                                                  queries on the leftSide dete...
Fig. 13.   Design Space Exploration metamodelThis implementation could be improved, but it is important toevaluate factors...
Fig. 15.   UML to IAM transformation                                                                            Fig. 16.  ...
3) Code Generation: Our Implementation Manager gen-                                                                       ...
DesignSpace specificTaskMapping (                                                        algorithms, to improve the optimi...
2) Verifying Properties: At this point, the designer canspecify logical properties using CTL formulae and use UP-PAAL to v...
LTATransitions, corresponding to the IGEdges labeled                                                                      ...
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
 Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios
Upcoming SlideShare
Loading in …5
×

Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios

2,841 views
2,782 views

Published on

Este curso tem como principal objetivo apresentar aos ouvintes conceitos sobre redes de sensores sem fio (RSSF), protocolos de comunicação para RSSF e conceitos de computação autonômica. Além disso, aplicações focadas nas áreas de monitoramento ambiental, agricultura de precisão, segurança e defesa também serão apresentados.

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,841
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Redes de sensores sem fio autonômicas: abordagens, aplicações e desafios

  1. 1. PUC - Campinas - SP, Brazil May 21 - 25, 2012 II BrazilianConference on Critical Embedded SystemsPromoted by: Support:Organized by: Sponsors: Published by:
  2. 2. II Critical Embedded Systems School (CES-School) II Brazilian Conference on Critical Embedded Systems (CBSEC 2012)PrefaceThe II Brazilian Conference on Critical Embedded Systems (CBSEC 2012) aims to joinacademy and industry to discuss major technical and practical issues in the developmentof critical embedded systems. The first edition took place in May, 2011, in São Carlos(Brazil).In this second edition, the emphasis is on aerial and terrestrial autonomous vehicles. Themain objective is to boost the capabilities of the academy and industry in teaching,training, researching and development in the area through papers presentation, shortcourses, tutorials, a student workshop and an exhibition. A comprehensive display ofrelevant scientific and technological tools, applications and methodologies with socialand economic impact in strategic areas such as agriculture, security and defense,automotive, aviation, satellite and environment protection will be put together anddiscussed from 20th to 25th of May, 2012, in Campinas (Brazil).The II Critical Embedded Systems School (CES-School) is a joint event of the CBSEC.In this edition, we received 12 short courses proposals from which four were selected forpresentation. In addition, two advanced courses and one international tutorial wereinvited. All of them explore themes of interest for academics and professionals involvedwith the development of critical embedded systems.We thank the Pontifícia Universidade Católica de Campinas for hosting the secondedition of CES-School into CBSEC. Finally, we welcome the speakers and participants ofCES-School 2012. We wish everyone a great conference! Ellen Francine Barbosa (ICMC/USP) Itana Maria de Souza Gimenes (DIN/UEM) CES-School 2012 Chairs
  3. 3. Table of ContentsTutorialInteraction Control for Contact Robotics Neville Hogan (MIT-USA)Invited CoursesThe “Why” and “How” of Software Safety Analysis in a Cross-Domain Review Sören Kemmann (Fraunhofer/IESE)Model-Driven Engineering of Complex Embedded Systems: Concepts and Tools Flávio R. Wagner, Francisco A. M. Nascimento, Marcio F. S. Oliveira (UFRGS / University of Paderborn)Short CoursesIntrodução ao Desenvolvimento de Software Embarcado Alexandra C. P. Aguiar, Sérgio J. Filho, Felipe G Magalhães, Fabiano P. Hessel (PUC-RS)Introdução a Sistemas Embarcados e Projeto baseado em Plataformas Marcio S. Oyamada, Alexandre A. Giron, João A. Martini (UEM, UNIOESTE)Introdução aos Sistemas Embarcados utilizando FPGAs Edilson R. R. Kato, Emerson C. Pedrino (UFSCar)Redes de Sensores sem Fio Autonômicas: Abordagens, Aplicações e Desafios Alex S. R. Pinto, Gustavo M. Araújo, José M. Machado, Adriano Cansian, Carlos Montez (UNESP - Rio Preto)
  4. 4. Interaction Control for Contact RoboticsNeville HoganSun Jae Professor of Mechanical EngineeringProfessor of Brain and Cognitive SciencesMassachusetts Institute of TechnologyAbstractContact robotics—close physical contact and cooperation between robots and humans—requires reliable, robust control of interaction. I will review some of the interesting andperhaps unique challenges of interaction control. Most control theory is permeated by a“signals” perspective: each system component is described as a mathematical operatorthat unilaterally determines its output (signals) as a function of its input (signals)—butnot vice-versa. Composition of operators is straightforward and the result is modularity:behavior of a component is essentially unaffected by its assembly into a system, therebydramatically simplifying design of complex machines. Unfortunately, the interactions dueto physical contact are usually bi-lateral—each system affects the other. The “controlledsystem” blends the robot dynamics with those of the contacted object, which may bepoorly or incompletely unknown. As a result the “signals” perspective doesn’t work well.I will review the mechanical physics of interaction, define what is meant by a “port” andshow its usefulness for establishing impedance or admittance control. Drawing heavily onconcepts from physical systems, I will review how a port-based perspective yields simplesolutions for stabilizing contact, coping with (and taking advantage) of redundancy andselecting optimal behavior for different tasks.Background papersHogan, N. and S. P. Buerger (2004). Impedance and Interaction Control. Robotics and Automation Handbook. T. R. Kurfess, CRC Press: 19-1 to 19-24.Fasse, E. D. and N. Hogan (1995). Control of physical contact and dynamic interaction. 7th International Symposium on Robotics Research. Germany.Mussa-Ivaldi, F. A. and N. Hogan (1991). "Integrable Solutions of Kinematic Redundancy Via Impedance Control." International Journal Of Robotics Research 10(5): 481-491.Hogan, N. (1988). "On The Stability of Manipulators Performing Contact Tasks." IEEE Journal of Robotics and Automation 4(6): 677-686.Hogan, N. (1985). "Impedance Control: An Approach to Manipulation." ASME Journal of Dynamic Systems, Measurement and Control 107: 1-24.
  5. 5. Model-Driven Engineering of Complex Embedded Systems: Concepts and Tools Fl´ vio Rech Wagner∗ , Francisco A. M. Nascimento∗ and Marcio F. S. Oliveira∗† a ∗ Instituteof Informatics , Federal University of Rio Grande do Sul (UFRGS), Porto Alegre, Brazil ∗† Cooperative Computing and Communication Laboratory(C-LAB), University of Paderborn, Paderborn, Germany Abstract—This paper starts presenting a brief history of engi- In order to overcome the difficulty in rising the abstractionneering methods till Model-Driven Engineering (MDE). Then, it level and to improve the automation of the design from theintroduces the basic principles of MDE, including the concepts initial specification until the final system, research efforts lookof models, meta-models, transformation between models, anddomain specific languages (DSLs). One can identify two classes for modeling methods, formalisms, and suitable abstractionsof tools. The first one is the framework required to support to specify, analyze, verify, and synthesize embedded systemsMDE of any kind. It supports different operations and common in a fast and precise way.tasks, independently from development domain, and strongly rely The main motivation to use models in the design ofon standards. As such, some MDE standard approaches, as for embedded systems is abstraction. Abstraction helps us toexample MDA (Model Driven Architecture), Software Factories,and MIC (Model Integrated Computing), are explained, and we understand a complex system, hiding irrelevant informationprovide a short survey on different technologies supporting MDE to solve a specific problem. However, abstraction alone does- MOF and Ecore for metamodeling, UML and DSLs for model- not improve the development. Accuracy is required, so thating, QVT, ATL, Xtend, and Xpand as transformations languages. models truly represent a specific system view. A model mustA second class of tools adopts an MDE framework to provide clearly communicate its intent and must be easy to understandDomain Specific Engineering Tools (DSET), which aggregatedomain specific knowledge to define relations between models and to develop, in order to be effective [2].and how these models can be refined. Focusing on Complex A prominent effort that attempted to use models in orderEmbedded Systems, some DSETs for the development of these to rise abstraction and automate development tasks originatedsystems are described. The paper shows in detail a DSET, which the Computer Aided Software Engineering (CASE) tools.uses an MDE framework based on the Eclipse Modeling Project CASE tools provide graphical representations for fundamentaland OMG standards. Finally, the paper presents the applicationof a DSET for Embedded Systems in a complete development programming concepts and automatically generate implemen-flow. For this, we start defining a sample embedded system and tation code from them. The main purpose of these tools was toshow how the system requirement specification can be refined reduce the effort of manually coding, debugging and portingthrough different development phases using an MDE approach. programs. However, due to the limited platforms existing atThe development process relies on different tools, which support that time, the code to be generated was too complex formultiple semi-automatic or automatic development tasks. the available technology. Moreover, the graphical represen- tations were too generic and poorly customizable, and thus I. I NTRODUCTION they could not support many application domains. Nowadays, Nowadays we are surrounded by devices containing hard- these limitations have been drastically reduced, due to object-ware and software components. These devices support many oriented languages and development frameworks, which makedifferent domains, such as telecommunication, avionics, au- easier the reuse of software components. However, thesetomobile, space, military, medical care, and others. They development frameworks and platforms are extremely complexare inserted into our dayly lives, in cell phones, in cars as and evolve quickly, causing a fragmented view due to multiplecontrollers for multiple subsystems (e.g., ABS, EPS, etc), in tool integrations required for developing new applications [3].the electronic toys, in the blood pressure measurement systems Although models are used in any engineering domain, onlyand so on. In short, they are found anywhere, and so they are recently models start playing a central role in the develop-called Embedded Systems, as they are information processing ment process of software and embedded systems [2]. Model-systems embedded into products, where the processing system Driven Engineering (MDE) [4] has been proposed in order tois not the main goal or functionality of the product [1]. improve the complexity management and also the reusability The ever growing complexity in modern embedded sys- of previously developed/specified artifacts. The MDE methodtems require the utilization of more hardware and software raises the design abstraction level and provides mechanisms tocomponents to implement the functions incorporated into a improve the portability, interoperability, maintainability, andsingle system. Such increasing functionality leads to a growing reusability of models.design complexity, which must be managed properly, because, In our MDE approach, we use only MOF concepts (Metabesides stringent requirements regarding power, performance Object Facility, a standard representation for meta-modelsand cost, also time-to-market hinders the design of embedded and models proposed by OMG [5]) to define our internalsystems. representation. Thus, as our metamodels conform to MOF, the
  6. 6. representation can take advantage of the concept of transfor- The method proposed in our MDE approach overcomesmations between models to implement DSE (Design Space those restrictions by defining a design space abstraction,Exploration), formal verification and co-synthesis tasks. using a categorical graph product [9]. Besides the automatic Our MDE approach defines internal models conforming to construction of the design space, performed by the productMOF-based metamodels proposed to represent applications, of graphs, this abstraction provides a common representationcapturing functionality by means of processes communicat- for multiple design activities. Moreover, the specification ofing by ports and channels; platforms, indicating available a metamodel using a well-adopted technology allows us tohardware/software resources; mappings from applications into exploit the MDE approach, such that model-to-model trans-platforms; and implementations, oriented to code generation formation rules are used to implement any user constraints,and hardware synthesis. Additional metamodels and transfor- improving the flexibility of the DSE method.mations extend this infrastructure to perform design specific The remaining of the text is organized as follows. Sectiontasks such as DSE and verification. II provides the background on MDE. Section III presents We support a formal verification methodology. By using the technologies developed to support MDE, such as modelingMDE approach, we generate a MOF-based representation of a languages, transformation languages, and engines. Sectionnetwork of timed automata [6] from UML Class and Sequence IV presents an overview on MDE approaches for embeddeddiagrams. We use the network of timed automata as input to systems design. Sections V and VI present the MDEthe UPPAAL model checking tool [7], which can validate the framework for embedded systems design, in development atdesired functional and temporal properties of the embedded UFRGS. Section VII present a case study, which illustrates thesystem specification. Since the network of timed automata is methodology described inthe previous secion. Section VIII,automatically generated from UML models, the methodology finally, discusses future trends and gives final remarks.is very useful for the designers, making easier the debugging II. M ODEL -D RIVEN E NGINEERING BACKGROUNDand formal validation of the system specification. Moreover, we offer an MDE methodology for the co- The MDE approach was proposed to overcome the lim-synthesis problem [8], which is integrated with the formal itation of the object technology to rise the abstraction andverification approach. This way, after the formal validation deal with the increasingly more complex and rapidly evolvingof the desired properties, the validated system specification is systems we are developing today. Proposing that ”Everythingused as input to our MDE co-synthesis tool. Therefore, this is a model”, MDE promotes the paradigm shift required to themethodology exploits the MDE approach to automatically gen- necessary evolution [10]. Although the central concept of thiserate a correct-by-construction implementation for a specific proposal still has multiple definitions, a consensual definitionplatform. of model and modeling is presented in [11]: Other approaches do not consider the influence of the ”Modeling, in the broadest sense, is the cost-structural features of the UML model in the communication effective use of something in place of something elsebehavior of a specified application. Our internal design repre- for some cognitive purpose. It allow us to use some-sentation, in turn, also captures the hierarchy and communica- thing simpler, safer or cheaper than reality instead oftion structure of the UML model in the form of a graph. This reality by some purpose. A model represents realityway, we represent the control and data flow dependencies in for the given purpose; the model is an abstractiona convenient way for the co-synthesis algorithms. of reality in the sense that it cannot represent all During the development of complex embedded systems, a aspects of reality. This allows us to deal with thewide range of design alternatives arises from different design world in a simpler manner, avoiding the complexity,activities. The combination of alternative designs and stringent danger and irreversibility of reality.” [11]requirements unveils a complex design space, which the design Since the main principle of MDE is that ”Everything is ateam must evaluate under reduced time-to-market. Design model”, models play a central role in the development process,Space Exploration (DSE) consists in systematically searching thus defining the scope of MDE proposed in [4]. The basicfor different design candidates, by mapping an application into concepts to support the MDE principle are system, model,an architectural platform. Each different candidate corresponds metamodel, and the relations between them, so that a modelto a trade-off regarding design requirements and constraints. represents a system and conforms to a metamodel [10]. Such Concerning the DSE process, all methods discussed in the concepts were organized in 3+1 layers [10], and are illustratedfollowing Section IV restrict the design space, according to in Figure 1.the activity to be performed. Moreover, the generation of Formally, a model in MDE is a graph composed of elementscandidate designs is internally implemented, usually as a (vertices and edges), where each element corresponds to afunction that is programmed directly in the tool. As a result, concept in a reference graph (metamodel) as defined below:no extension mechanisms are provided, requiring multiple Definition 1: A directed graph G = NG , EG , ΓG consiststools to support each design activity. Moreover, for most of a set of distinct nodes NG ; a set of edges EG ; and aapproaches either the constraints set is restricted to previous mapping function ΓG : EG → NG × NG .constraints implemented by the tool or the method supports Definition 2: A model M = G, ω, µ is a tuple wherelimited constraints constructs. G = NG , EG , ΓG is a directed graph; ω is itself a model,
  7. 7. Fig. 3. MDE context: principles, standards and tools • Model refactoring Fig. 1. Basic concepts and layered organization • Reverse engineering • Verification, etc. Based on the posible applications of model transformations, they can be classified in: • Model-to-Model, when the source and target of the trans- formation are models, e.g. transformation from UML to a relational Data Base (RDB) schema or from a Platform Independent Model (PIM) to a Platform Specific Model (PSM); • Model-to-System, characterizing a generation from model to system, which can include program code or any other artifact, e.g. UML to Java or Simulink to C++; • System-to-Model, meaning a reverse engineering, such as Fig. 2. Model transformation in the context of MDE from Java code to a UML model or from Java code to a business model. A more detailed survey on model transformation approachesnamed reference model of M , associated to a graph Gω = is presented in [13]. Nω , Eω , Γω ; and µ : NG ∪ EG → Nω is a functionassociating elements (nodes and edges) of G to nodes of Gω III. T ECHNOLOGICAL F RAMEWORKS(metamodel). A metamodel is a model, which is a reference model for Technological frameworks [14] are tools to support differentother models, so that it defines classes of models that can be operations and common tasks for MDE independently fromproduced conforming to it. It is an abstraction, which collects the application domain. Such tools rely on standards, such asconcepts of a certain domain and the relations between these MDA, MIC, and Software Factories, in order to generalizeconcepts. the manipulation of models, providing facilities such as per- MDE models are operated through transformations, aiming sistence, repository management, copy, etc. Figure 3 illustratesat the automation of some development activity. Such trans- the relationship between the principles, presented in Section II,formations define clear relationships between models [10] and standards and tools.usually are specified in a specialized language to operate on An overview on some standards and tools are presented in(graph) models. Following the description in [12], a model the next subsections.transformation means converting one or more source modelsto a target model, where all models must conform to some A. MDE Standardsmetamodel, including the model transformation itself, which 1) Model-Driven Architecture: Model-Driven Architectureis also a model. Figure 2 illustrates the concept of model (MDA) is a standard proposed by OMG for software de-transformation in the MDE context. velopment. The main purpose of MDA is the abstraction Model transformation plays a key role in MDE and has of platforms, so that the business models can be reused asmany applications, as enumerated in [13]: the technological platform evolves. MDA integrates different • Generating low-level models from high-level ones OMG standards, such as MOF for metamodeling, UML for • Generating development artifacts (e.g. configuration files system modeling, SPEM for process modeling, and QVT for and source code) model transformation. In order to separate business and appli- • Mapping and synchronizing models cation models from the underlying platform, MDA advocates • Creating query-based views of a system three modeling dimensions (view points):
  8. 8. • The Computation Independent Model (CIM) focuses on line that provides a production facility for the product family the required features of the system and on the environ- by configuring extensible tools using a software template based ment where it must operate; on a software schema” 1 • Platform Independent Model (PIM) focuses on business A Software Factory Schema describes the artifacts that functionality and behavior, which are unlikely to change comprise a software product. It is represented by a graph, from one platform to another; where vertices are viewpoints and edges are relationships be- • Platform Specific Model (PSM) describes platform spe- tween viewpoints (mapping). Each viewpoint defines the tools cific details integrated with elements of PIM. and materials required by a concern in a specific abstraction The relationship between PIM and PSM in MDA can level. Attached to a viewpoint, a micro process is definedbe established by automatic or semi-automatic mechanisms, for producing the artifacts described in the viewpoint. Suchspecifying a mapping between these models. MDA suggests process is constrained by preconditions, postconditions andthat this mapping can be specified by using QVT, so that invariants that must hold when the view is stabilized.a transformation engine can generate the automatic transfor- A Software Factory Template is the collection of DSL’s,mation from PIM to PSM. The languages used to express patterns, frameworks and tools described in the Softwarethese models are defined by means of metamodels using MOF, Factory Schema, which is made available to developers, inwhich are able to represent abstract and concrete syntaxes, as order to create a specific software product.well as the operational semantics of the modeling language.Originally, MDA was proposed for enterprise architectures B. MDE Toolsthat use platforms, such as Java2EE, CORBA, VisiBroker,and WebSphere. However, as using the MDA approach the The MDE approach has a practical relevance only if it candevelopment of systems can be focused on aspects that do produce and transform models bringing considerably morenot involve implementation details, many other domains start benefits than the current practices. Therefore, to enhance theconsidering the MDA approach, such as real-time and embed- value of models, they must become tangible artifacts, whichded systems. Therefore, MDA and the experience with OMG can be simulated, verified, transformed, and so on, and thestandards are in the origins of MDE. burden for maintaining these models in synchronization with 2) Model Integrated Computing: Model Integrated Com- the produced system must be reduced [4].puting (MIC) [15] is an initiative from Vanderbilt University. Supporting tools are essential to provide all benefits ofIn this approach, models representing different views capture MDE. This section describes some MDE tools, focusing onthe designer’s understanding of the computer-based system, tools supported by the Eclipse Modeling Project (EMP)2 . EMPincluding information process, physical architecture, and oper- provides a unified set of modeling frameworks, tooling, andating environment. A formal specification of the dependences standards implementations.and constraints among these models allows the generation of 1) Metamodeling/Abstract Syntax: As the model is thetools to solve an entire class of problems. MIC proposes a most important artifact in MDE, defining the class of modelstwo step development process. In the first step, a domain- an MDE process must work on is one of the first steps. Thisindependent abstraction is used to formally define a domain is done by metamodeling, which defines the structured dataspecific environment and the required models, languages and types used to represent a system (abstract syntax). In EMP,tools. In the second step, three typical components delivered metamodels are defined conforming to ECORE, a metameta-from the previous phase are used for system engineering: model (layer 3 in Figure 1) defined by the Eclipse Modeling Framework (EMF). EMF is a projection of ECORE, and of • A graphical model builder is used to specify domain the models conforming to it, into Java API. It provides code specific models. Constraints explicitly defined at meta- generation facilities and tools to building model editors and to level allow model testing. compare, query, persist and validate models. As most tools in • A model database stores domain specific multiview mod- EMP are based on ECORE and EMF, and many other projects els using a multigraph architecture. make use of EMF, ECORE is a de fato standard. • Model Interpreters are used to synthesize executable programs from the domain specific models and generate Besides Ecore metametamodels and EMF, other metamod- data structures for the tools. eling tools are found. Kermeta 3 is based on the OMG standard Essential MOF (EMOF), which was originated from ECORE MIC has a strong influence on the principles of MDE as it and KM3, a metametamodel proposed in [17]. MetaGME ishas a wider basis on engineering of systems than MDA. More- a metamodeling tool, which implements the metamodelingover, the two step process advocated by MIC is close to the concepts for MIC. Originally, its metametamodel was calledidea of Technological Frameworks as a basis of development Multigraph Architecture. Newest versions use UML classfor Domain Specific Engineering Tools present in the MDE diagrams notation and OCL for metamodeling.approach. 3) Microsoft Software Factories: The main idea behind the 1 http://msdn.microsoft.com/en-us/library/ms954811.aspxSoftware Factories [16] is to introduce patterns of industrial- 2 http://www.eclipse.org/modeling/ization in the software development. It is ”a software product 3 http://www.kermeta.org/
  9. 9. 2) Concrete Syntax: A concrete syntax for a DSML (Do- to engineer not only software, but entire systems, which maymain Specific Modeling Language) can be defined using the be also composed of hardware, electrical, and mechanicaltools from the Eclipse Graphical Modeling Project. It provides parts. This section present some DSMDETs for embeddedtools, such as GMF Notation and Graphiti, to specify the system development.concrete syntax and to generate an editor to express models The adoption of platform-independent design and exe-graphically. cutable UML has been vastly investigated. For example, The definition of the concrete syntax of languages expressed xtUML [19] defines an executable and translatable UML sub-as text is also possible by using tools such as Xtext. It provides set for embedded real-time systems, allowing the simulation ofa simple EBNF language, which is used to define grammars, UML models and C code generation oriented to different mi-and a generator to create a parser, an AST-metamodel (im- crocontroller platforms. The Model Execution Platform (MEP)plemented in EMF), and a Eclipse text editor for the defined [20] is another approach based on MDA, oriented to codelanguage. generation and model execution, as well as the Framework 3) Model Development: For common general purpose and for UML Model Behavior Simulation (FUMBeS) [21].domain specific languages, there is no need to build new Other approaches improve the integration of the designeditors as good tools can be found, such as Magic Draw, En- tools into an MDE environment, by defining meta-models, andterprise Architecture and Rhapsody for modeling with UML. the transformations on them include some refinement. ThisSimulink and Scade are DSML’s commonly used for control approach includes the DaRT (Data Parallelism to Real Time)engineering and signal processing and specialized tools for that project [22], [23], whose evolution produced the Gaspard2are also provided. Eclipse Model Development tools provide framework. It proposes an MDA-based approach that hasmodel editors for some standards such as UML, XML, and many similarities with our approach in terms of meta-modelingOCL. concepts. DaRT defines MOF-based metamodels to specify ap- 4) Model Transformation: Since model transformation is plication, architecture, and software/hardware associations andthe key operation for MDE, many transformation engines and uses transformations between models to refine an associationlanguages were proposed. However, after the experience with model. In the Gaspard2 framework [24] UML/MARTE modelsfirst languages, a discussion on classification [13] and quality are used as input and transformation to other tools, providingmetrics [18] is starting to take place in the research agenda, support for co-synthesis, simulation and formal verification,so that a standard with high adoption may rise. by translating its model into synchronous reactive languages. EMP had many model-to-model transformation languages, However, no automated DSE (Design Space Exploration)but now the efforts concentrate on ATL and in a reference im- strategy based on these transformations is implemented, andplementation of QVT, the QVT Operational. Other languages the main focus is code generation for simulation at TLMare provided as Eclipse projects or Eclipse plug-ins, such as (Transaction Level Model) and RT (Register Transfer) levels.VITRAII and GReAT. In this approach, each candidate solution is simulated at a Model-to-text (Model-to-System) transformation is pro- different abstraction level, thus guiding the designer in thevided by EMF through three different template-based lan- DSE activities.guages: Java Emitter Template (JET); Acceleo, which is a The Aspect-oriented Model-Driven Engineering for Real-implementation of an OMG standard, named MOF to Text Time systems (AMoERT) methodology [25] proposes anLanguage; and Xpand, which was initially an openArchitec- automated integration of design phases for distributed em-turalware component. bedded real-time systems, focusing on automation systems. The proposed approach uses MDE techniques together with IV. M ODEL D RIVEN E NGINEERING OF C OMPLEX Aspect-Oriented Design (AOD) and previously developed (or E MBEDDED S YSTEMS third party) hardware and software platforms to design the In [14] two classes of MDE tools are identified. The first components of distributed embedded real-time systems. AODclass is called MDE Technology Framework, which support concepts allow a separate handling of functional and non-the MDE process by providing tools for different operations functional requirements, improving the modularization of theand common tasks, independently from development domain, produced artifacts. In addition, the mehodology is supportedsuch as metamodeling, transformation engines and languages, by GenERTiCA code generation tool [25], which uses map-debugger, tracing, and other facilities. These tools rely strongly ping rules for the automatic transformation of UML modelson standards. Some of them where presented in the previous into source code for software and hardware components,section, such as the tools provided by the Eclipse Modeling which can be compiled or synthesized by other tools, thusProject. The second type of tools adopts an MDE framework to obtaining the realization/implementation of the distributedprovide Domain Specific Application Development Environ- embedded real-time system. During the generation process,ments (DSAEs), which aggregate domain specific knowledge the tool includes the required implementation code to handlefor defining relations between models and how these models the specified aspects for non-functional requirements (modelcould be refined. Generalizing this concept, we assume that weaving).Domain Specific Model-Driven Engineering Tools (DSMDET) Metropolis [26] is an infrastructure for electronic system de-are those tools which rely on an MDE technology framework sign, in which tools are integrated through an API and a com-
  10. 10. mon metamodel. Following the platform-based approach [27],the Metropolis infrastructure captures application, architectureand mapping using a proposed UML-platform profile [28].Furthermore, its infrastructure is general enough to supportdifferent Models of Computation and to accommodate newones. Non automatic support for Design Space Exploration isprovided by Metropolis, which proposes an infrastructure tointegrate different tools. Nevertheless, the current simulationand verification tools integrated into Metropolis and the pro-posed refinement process can be used to manually performsome architectural explorations (task mapping, scheduling,hardware/software partitioning) and component configuration.Moreover, the refinement process allows the explicit explo-ration of application algorithms, which implement a higherlevel specification. Koski [29] is a UML-based framework to support MPSoC(Multi-Processor System-on-Chip) design. It is a library-basedmethod, which implements a platform-based design. Koskiprovides tools for UML system specification, estimation, ver-ification, and system implementation on FPGA. The Koski Fig. 4. MODES Development Flowdesign flow starts with a requirement analysis, which spec-ifies the application or architecture requirements and designconstraints. Following the design flow, the application, ar- engineer specifies the application independently from the plat-chitecture and the initial mapping are specified as UML 2.0 form using UML as modeling language. MoDES provides themodels. A UML interface handles these models and generates components System Designer and Application, Platform andan internal representation, which is used for architectural Implementation Managers, which transform the UML modelsexploration. The architectural exploration is performed in two into internal models conforming to metamodels proposed tosteps; the first one is static, fast and less accurate; the second represent applications, capturing functionality by means ofone is dynamic. At the end of the design flow, the UML models processes communicating by ports and channels; platforms,are used to generate code and the selected components from indicating available hardware/software resources; mappingsthe platform are linked to build the system. from applications into platforms; and implementations, ori- Other complete environment for design space exploration ented to code generation and hardware synthesis. Additionalis the MILAN [30] framework, with two exploration tools metamodels and transformations extend this infrastructure tocalled DESERT [31] and HiPerE [32]. The focus of MILAN perform design specific tasks such as DSE (Design Spaceis the integrated simulation of embedded systems, so that Exploration) and verification. Figure 4 illustrates the MoDESit evaluates pre-selected candidate solutions. The hierarchi- infrastructure including the models, according to metamodelscal simulation provided by MILAN allows a designer to with the same names, and the flow of transformation be-explore the design space at several abstraction levels, by tween tools, which provides support to DSE (H-SPEX) [34],using the DESERT and HiPerE tools. First, the DESERT estimation (SPEU) [35], formal verification (UPPAAL) [7],tool uses models of aggregated system sub-components and and co-synthesis (System Designer, Application, Platform andconstraints to automatically compose the embedded system Implementation Managers).through Ordered Binary Decision Diagrams (OBDD), based We implemented the MODES framework using the open-on a complete pre-characterization of components. Moreover, source Eclipse Modeling Framework (EMF) to define ourthe DESERT tool performs design space pruning, reducing Ecore conformant metamodels, while openArchitectureWarethe number of candidate solutions. After that, HiPerE can be is used to define transformations and workflow between tools.used for accurate system-level estimation, exploring the pruned The UML models can be specified in any editor that providesdesign space. Finally, by using integrated simulation at lower an XMI compatibility with EMF tools such as Eclipse UML2.abstraction levels, the designer can explore the reminder of A. System Modelingthe design space, performing then also platform tuning. The proposed system development methodology adopts V. MODES: A N MDE F RAMEWORK FOR E MBEDDED UML and the MARTE profile together with modeling guide- S YSTEMS D ESIGN lines to specify application, architecture, and mapping. As an example, consider a real-time embedded system dedicated to Our MDE approach to embedded systems design automa- the automation and control of an intelligent wheelchair. Thetion is supported by the Model-based Design for Embedded application structural model is specified using Class Diagrams.System (MoDES) Framework [33]. In this approach, the Figure 5 shows a partial class diagram for the movement
  11. 11. Fig. 5. Application Model: UML Class Diagram Fig. 8. Internal Application Metamodel a ModuleBody. ModuleDeclarations are used to spec- ify typed Channels, Ports, Signals, and Variables. These concepts come from hardware description languages, such as VHDL. Channels are used by Processes to send or receive messages. Ports interconnect the Modules. Fig. 7. Architecture Models: Composite Diagram Signals are used to specify shared memories for processes. Variables correspond to the local memories for processes.control of the automated wheelchair. A ModuleBody consists of Interconnections with The behavioral model is defined using Interaction Diagrams, other Modules and a ModuleBehavior, as well as sub-containing loop and conditional execution, interaction between modules. The ModuleBehavior is captured in terms of a setobjects, and dependencies between execution scenarios. An of Processes, and each Process has a set of Actions,Interaction Overview Diagram identifies and link the scenarios which represent the occurrence of UML events in the scenariosused to evaluate the system during the estimation process. (UML sequence diagrams), as will be shown in the following.For our example, an Interaction Overview Diagram specifies a The behaviors of the processes are associated to a Modelparallel composition of three UML sequence diagrams, which of Computation (MoC). This association allows the translationare illustrated in Figures 6 (a), (b), and (c). from an abstract behavior description to a specific MoC The allocated architectural components, such as processing and the execution of algorithms to automate design tasks.units, memories and communication busses, are defined in Currently, two MoC’s are supported and their metamodelsComposite Diagrams. The Composite Diagram can also be extend the IAMM as described in subsections V-C and V-D.used to define the mapping from application to architecture, C. Interaction Graph Metamodelfor example to specify in which processing unit a software el- The control and data flow graph (CDFG) [8] of an applica-ement must execute, as illustrated in Figure 7. The Component tion model is defined conforming to the metamodel presentedDiagrams are considered as constraints during the automatic in Figure 9.DSE process. Figure 9 represents an InteractionGraph, which con- Alternatively, a Domain Specific Language (DSL), defined sists of a set of IGNodes and IGEdges. Each IGNode canto specify models for application, platform, and implementa- represent different kinds of control flow:tion, can be used instead of UML. To this purpose we use theXtext feature of openArchitectureWare, which automatically • IGInitialNode and IGFinalNode indicate the be-generates the parser and a text editor for these DSLs as Eclipse gin and end of an InteractionGraph, respectively;plug-ins from an Extended BackusNaur Form (EBNF) [36] • IGForkNode and IGJoinNode represent parallel ex-specification. ecution; and • IGDecisionNode and IGMergeNode represent con-B. Internal Application Metamodel ditionals and loops. Representing an application in a standard way, the model There are also two kinds of executable nodes, which are sub-captured from UML is translated into a common applica- classes of the IGMessageNode class: IGCallNode cap-tion model defined by our Internal Application Metamodel tures the sending of messages and IGReplyNode represents(IAMM), partly depicted in Figure 8. the reply messages in the UML sequence diagram. Conforming to this metamodel a system specification cap- For each UML sequence diagram SDm there is antures the functionality of the application in terms of a set of InteractionGraph IGSDm = V, E, K, L , which is aModules. Each Module has ModuleDeclarations and CDFG, where:
  12. 12. Fig. 6. UML Sequence Diagrams identified as: a) SD1; b) SD2; c) SD3 Fig. 10. Labeled Timed Automata metamodel [6], conforming to the LTA metamodel illustrated in Figure 10. Fig. 9. Interaction Graph metamodel The LTA metamodel captures all concepts introduced by the UPPAAL model checking tool [7]. According to this metamodel, a system consists of LTADeclarations, which • V is the set of nodes, representing the actions in the are used to declare variables, functions, and channels, and behavioral modeling; LTAProcesses, which are instances of LTATemplates. • E is the set of edges, representing the data and control Each LTATemplate corresponds to a timed automaton, flow between the actions; which can also have LTADeclarations of local variables • K : V → {Initial; F inal; F ork; Join; M erge; and functions. Each timed automaton is represented by a set Decision; Call; Reply} is a function that indicates the of LTALocations, corresponding to states of the automa- type of each node; and ton, and LTATransitions, corresponding to transitions • L : V → {IGSDi } is a relation that associates an between states, thus having source and target locations. IGCallNode to another InteractionGraph and Each transition may have attributes such as: allows the capture of the behavioral hierarchy of the application. • LTASelections, which non-deterministically bind a given identifier to a value in a given range when a An Interaction Overview Diagram links multiple Se- transition is taken;quence Diagrams, and from this diagram is generated an • LTAGuards - the transition is enabled in a state if andInteractionGraph IGapp = V, E, K, L , representing only if the guard evaluates to true;the CDFG for the entire application. • LTASyncronizations - transitions labeled with com- Therefore, our IAMM captures structural aspects of an ap-plication model by using a hierarchy of modules and processes, plementary synchronization actions (send and receive)as well as behavioral aspects by means of the actions of over a common channel; and • LTAUpdates - when the transition is taken, its updatesending and replying messages, where a message may executesome method in the corresponding object. expression is evaluated and the side effect of this expres- sion changes the state of the system.D. Labeled Timed Automata Metamodel The LTA model is used in the UPPAAL model checker Additionally, the functional behavior of a UML model is to perform formal verification of specified properties of thetranslated into a network of Labeled Timed Automata (LTA) system. This feature is very useful for the designer, since
  13. 13. Fig. 12. Mapping metamodel queries on the leftSide determine the source metamodel el- Fig. 11. Internal Platform metamodel ements, which will be manipulated by the Action of the rule side, and the specified action is applied only when the specified Condition evaluates to true. Thus, a transformation rulethe LTA model is automatically generated and can help the may also change the elements of the source metamodel.designer to debug and validate the specification. Similarly, the queries on the rightSide determine the target metamodel elements, which will be manipulated byE. Internal Platform Metamodel the Action of the rule side, and the specified action is applied only when the specified Condition evaluates to In a platform-based design context, a large number of true. Instead of defining our own transformation language ashardware and software components are provided and can be a concrete syntax for the Mapping Metamodel, we use thereused in the system development. Such reusable components Xtend transformation language. Therefore, transformations inmust be pre-characterized such that their Quality of Service Xtend are considered instances of the Mapping Metamodel.values, such as performance, energy, memory footprint, and The source models are IAM and IPM, and the target is theothers, are acquired. This pre-characterized library dramati- Implementation Model. A Mapping model defines also thecally reduces the design phases and the uncertainty about the rules, which guide the DSE process and prune the designsystem properties, thus improving the design productivity. The space. By means of model-to-model transformations, the rulessoftware component characterization is performed after the on the Mapping model manipulate instances of the DSEcomponent code is compiled for the target architecture, since Metamodel, to generate candidate designs during the DSEat this time a simulation/estimation tool can capture archi- process. The Mapping model provides flexibility to specifytectural information with high accuracy. The characterization constraints that directly handle the concepts of the design, suchof hardware components must be performed from adequate as processors, tasks, slots, voltage level, and others.synthesized descriptions, to obtain values that are independentof technology and frequency, such as execution cycles and gate G. Design Space Exploration Metamodelswitchings per cycle (a measure for power consumption). In The DSE Metamodel defines the relevant concepts to per-our methodology, the available hardware/software components form automated DSE. Figure 13 shows this metamodel.and the characterization information are stored in a platform The root container in this metamodel is DSEDomain, whichrepository. Figure 11 shows our Internal Platform Metamodel is a container for all elements related to DSE. It inherits(IPMM). properties from DSEModelElement as all other elements In our IPMM, a Platform contains different in this metamodel. The generalization was omitted to keepComponents, which offer Services for the application. the diagram clear. DSEDomain contains DSEProblema,These Services must be pre-characterized in terms of which define a DSE scenario. DSEProblem contains a listQuality of Service (QoS), and this information is reused of DesignGraphs extracted from Application and Platformduring system development. Our approach uses performance, Models.energy, data memory, and program memory as QoS metrics. A DesignGraph contains vertices and edges, where ver-However, other metrics could also be used, thus extending tices are ExplorableElements and Edge represents thethe QoS concept. dependences between vertices. ExplorableElement is a reference to a design element from which the DesignGraphF. Mapping Metamodel is generated. This reference is important to hook the The Mapping Metamodel is responsible for describing the ExplorableElements to the design model and allowsrules used to transform instances of IAMM and IPMM into the metamodel to be attached to multiple models, such asan instance of the Implementation Metamodel. Conforming UML, Simulink, and others. Currently, this reference is im-to the Mapping Metamodel, presented in Figure 12, a Map- plemented by holding the name of the design element as aping model consists of a set of Transformations, whose field of ExplorableElement and using queries to findRules are specified by leftSides and rightSides. The the instance of the design element in the design repository.
  14. 14. Fig. 13. Design Space Exploration metamodelThis implementation could be improved, but it is important toevaluate factors such as performance, increase of dependencebetween metamodels, and traceability of design elements. DSEProblem also contains a list of Objectives, whichare the values to be optimized, defined by their name andunit. We represent a DesignSpace as a categorical graphproduct, as we propose in [37]. DesignDecisions repre-sent vertices in the design space graph, and Alternativeslink the allowed DesignDecisions. DesignDecision Fig. 14. Implementation metamodelis a tuple of n vertices from the DesignGraphs. It con-tains a GraphToExplorableMap, which contains an in-stance of DesignGraph as a key and an instance of and scripts. An instance of this metamodel is obtained byExplorableElement as a value, so that it can map a the application of mapping rules, which are selected from thedesign decision to the ExplorableElements represented mapping model by means of our DSE approach.in the DesignGraphs. DSESolution is a sub-graph of the design space VI. D ESIGN AUTOMATION TASKSand represents candidate designs. A DSESolution has A. Co-Synthesis Tasksits costs defined in the ObjectiveToCostMap, ac- A co-synthesis design process, from a specification of thequired from an estimation/simulation process. DSESolution system functionality, produces an efficient implementation ofalso contains a list of decisions, which identifies the the embedded system in terms of: a set of software modules toDesignDecisions selected from DesignSpace and be executed by hardware components from a given platform;maps it to an ObjectiveTo-CostMap. a set of hardware modules, which are specifically designed Our H-SPEX DSE tool invokes the engine that executes for the application, in the form of ASICs or FPGAs, withthe transformations defined by ExplorationRules, which minimum latency and costs; and a set of interface modules tois an instance of the Mapping model required to generate perform the communication between all the elements of theDSESolutions conforming to the DSE Metamodel. implementation. Thus, the co-synthesis process must include design tasks for the specification of the system functionalityH. Implementation Metamodel and its translation to a representation. This representation The Implementation Metamodel, presented in Figure 14, must be adequate for the execution of tasks such as hard-represents a model that can implement a system. An ware/software partitioning, scheduling, allocation and binding,Implementation is a list of Resources, which are the during the design space exploration, and code generation, forHardware, Software and Communication components obtaining the final implementation of the specified system.required to implement the system. The following sections present the co-synthesis tasks of our The metamodel also represents the association between approach.Hardware and Software and the Communication 1) Capturing Application: Our Application Managerbetween these resources. Each Resource may have adopts an MDE approach to generate the Internal Applica-ImplementationLinks, which are references to artifacts tion Model (IAM) conforming to our IAMM. It does so byrequired for its final implementation, such as source code files performing model transformations on the UML application
  15. 15. Fig. 15. UML to IAM transformation Fig. 16. InteractionGraph: CDFG for applicationmodel, which are implemented using the Xtend language fromthe openArchitectureWare framework. To give an idea of the respectively.kind of model transformations we define, Figure 15 illustrates The InteractionGraph for the entire applicationpart of our model transformations. is shown in Figure 16-B, where we have three IGExecutableNodes cn-ig1, cn-ig2, and cn-ig3,UML structural constructs which are associated by relation L to the corresponding The main transformation is performed in lines 6-10 of InteractionGraphs of the sequence diagrams SD1,Figure 15, where each Package in the UML model is traversed SD2, and SD3, respectively. The IGForkNode fk-m1(line 7). After that, the sub-modules are identified (line 8), and the IGJoinNode jn-m1 indicate that the threethe processes are built from the sequence diagrams (line 9), InteractionGraphs are composed in parallel.and, finally, the InteractionGraphs are built from the 2) Capturing the Platform: Our Platform Manager gener-sequence diagrams (line 10). ates the Internal Platform Model (IPM) from a specification As seen in lines 12-14, which show the function of the platform resources. The platform specification is givenhandlePackage(), each Package in the UML model using a textual DSL (Domain Specific Language) for the IPM.is traversed recursively (see line 14), and each existing A parser and an editor for the textual IPM’s DSL were au-UML Class in a package is transformed into a Module tomatically generated using the Xtext feature of openArchitec-class by calling the function mapModule() (line 13). Each tureWare. From an EBNF specification, openArchitectureWareUML Attribute of each UML class is transformed into a automatically produces Eclipse plug-ins, which implement theModuleDeclaration class, as shown in lines 17-18. parser and editor for a DSL. Listing 1 shows part of the EBNF The associations between the UML classes determine the for the IPM’s DSL.sub-modules of each module. Each UML Class, which is Listing 2 presents an example of IPM given in the textualpart of an aggregation or composition of another UML Class, DSL defined by the EBNF of Listing 1.is transformed into a sub-module, by calling the function In the IPM example of Listing 2 we have two platformputSubModule() (lines 23-25). components. The component Comp1 consists of a processor with memory (component HwComp1) and an interface compo-UML behavioral constructs nent InterfComp1, which can implement hardware to hard- In Figure 16, we have the Interaction Graph for the sequence ware and software to software communications. The specifieddiagram SD1 from Figure 6-C. The IGExecutableNodes processor has a functional unit fu1, which can implementare shown as circles, the IGControlFlow edges as arrows, operations calcspeed and calcangle with latencies 2and the IGControlNodes as rounded boxes. and 1, respectively (as indicated by the qos attributes). The IGCallNodes cn-m1 and cn-m2 in Figure 16-A rep- component Comp2 defines a software component (SwComp1),resent the message calls for calcAngle() and move() in which consists of an API with methods that also can im-the SD1 of Figure 16-C, respectively. The IGReplyNodes plement the operations calcspeed and calcangle. Thisrn-m1 and rn-m2 represent the corresponding reply mes- platform information is read by the Platform Manager andsages for calcAngle() and move() in the same SD1, passed to the System Designer during the co-synthesis process.
  16. 16. 3) Code Generation: Our Implementation Manager gen- erates the design artifacts for the final implementation de-P l a t f o r m : ’ p l a t f o r m ’ name=ID termined by the System Designer. The code generation in ’ { ’ ( c o m p o n e n t s +=Component ) ∗ ’ } ’ ; the Implementation Manager is implemented using the XpandComponent : ’ p l a t c o m p o n e n t ’ name=ID ’{ ’ language of openArchitectureWare. ( h a r d w a r e c o m p s += HardwareComp ) ∗ By using Xpand templates, the Implementation Manager ( s o f w a r e c o m p s += SoftwareComp ) ∗ ( i n t e r f a c e c o m p s += I n t e r f a c e C o m p ) ∗ produces HDL descriptions for the application parts mapped ( c o m p s e r v i c e s += C o m p o n e n t S e r v i c e ) ∗ ’} ’ ; to hardware and programs for the application parts mapped toHardwareComp : ’ p l a t h a r d w a r e ’ name=ID ’{ ’ software. ( memories += MemoryComp ) ∗ ( p r o c e s s o r s += P r o c e s s o r C o m p ) ∗ ’} ’ ; B. Design Space ExplorationMemoryComp : ’ platmemory ’ name=ID ’{ ’ 1) Design Space Abstraction: Similarly to most DSE ap- ( a t t r i b u t e s += A t t r i b u t e ) ∗ ’} ’ ; proaches we explicitly define the design space as a mappingAttribute : name=ID ’= ’ V a l u e ’ ; ’ ; of graphs. However, differently from the usual approach,V a l u e : v a l u e =STRING | v a l u e =INT | v a l u e =ID ; as presented in [38], which is a manual mapping between semantically defined graphs, our approach uses the categoricalP r o c e s s o r C o m p : ’ p l a t p r o c e s s o r ’ name=ID ’{ ’ ( a t t r i b u t e s += A t t r i b u t e ) ∗ ’} ’ ; graph product, automatically generating the mapping between graphs. These graphs are free of any specific semantics fromSoftwareComp : ’ p l a t s o f w a r e ’ name=ID ’{ ’ ( Oss += OSComp ) ∗ ( APIs += APIComp ) ∗ ’} ’ ; the view of the H-SPEX tool. In the following, we formalize the design space abstraction, which is represented in the DSEOSComp : ’ p l a t O S ’ name=ID ’ { ’ ( s y s c a l l s += S y s c a l l ) ∗ ’ } ’ ; Metamodel presented in Subsection V-G. Listing 1. Xtext grammar for the Platform DSL Consider G = V, E, ∂0 , ∂1 as a graph, where V is the set of all vertices of G; E is the set of all edges of G; ∂0 : E → V is the source function of an edge; and ∂1 : E → V is the target function of an edge. Let S be the set of graphs, where Gi = Ei , Ti , ∂0i , ∂1i ⊂ S, i = {1 . . . n} and n is the number of graphs in S. This set is formed of graphs, such as a task graph, an architectural graph, and the communication structurep l a t f o r m TTA1 { of buses, extracted from instances our internal metamodels. p l a t c o m p o n e n t Comp1 { p l a t h a r d w a r e HwComp1 { The specific semantics of each graph is not considered during p l a t m e m o r y MemComp1{ S i z e = 4 0 9 5 ; Width =32;} the generation of the design space, for the purpose of design p l a t p r o c e s s o r Processor1 { v e r s i o n =1; FU f u 1 { space abstraction. The specific semantics of these graphs is s e r v i c e c a l c s p e e d { q o s D e l a y { V a l u e =2;}} considered in the exploration rules defined in a Mapping s e r v i c e c a l c a n g l e { q o s D e l a y { V a l u e =1;}} } model. The design space is a graph D resulting from the RF r f 1 { categorical graph product of the sequence of terms, which are s e r v i c e move { q o s D e l a y { V a l u e =1;}} } ... all graphs in S. In this fashion, D = Gi × Gi+1 . . . × . . . } / / Processor1 Gn = (Vi × Vi+1 . . . × . . . Vn , Ei × Ei+1 . . . × . . . En , ∂0i × p l a t i n t e r f a c e InterfComp1 { plathwhw HwHwInterf1 { Width = 3 2 ; ∂0i+1 . . . × . . . ∂0n , ∂1i × ∂1i+1 . . . × . . . ∂1n ) represents the s e r v i c e r e a d { q o s D e l a y { V a l u e =1;}} graph product between Gi , Gi+1 . . . and Gn , where {∂ki × } p l a t s w s w S w S w I n t e r f 1 {Width = 3 2 ; ∂ki+1 . . . × . . . ∂kn |k ∈ {0, 1}} are unambiguously induced by s e r v i c e r e a d { q o s D e l a y { V a l u e =1;}} the dot product between vertices and edges, considering that } } / / InterfComp1 any two vertices (ui , ui+1 , . . . , un ) and (vi , vi+1 , . . . , vn ) are } / / HwComp1 adjacent in D, if and only if ui is adjacent with vi in Gi , ui+1 p l a t c o m p o n e n t Comp2 { p l a t s o f w a r e SwComp1 { is adjacent with vi+1 in Gi+1 . . . and un is adjacent with vn p l a t A P I APIComp1 { in Gn , i = 1 . . . n − 1, where n is the number of graphs in S. method c a l S p e e d { i n 1 = 0 ; i n 2 = 0 ; o u t = 0 ; s e r v i c e c a l c s p e e d { q o s D e l a y { V a l u e =3;}} Each product of the sequence Gi × Gi+1 . . . × . . . Gn } that constitutes D represents a design activity, such as task method c a l A n g l e { i n 1 = 0 ; i n 2 = 0 ; o u t = 0 ; s e r v i c e c a l c a n g l e { q o s D e l a y { V a l u e =2;}}} mapping, processor selection, processor allocation, voltage method move{ i n = 0 ; o u t = 0 ; scaling selection, etc., such that vertices in D are design s e r v i c e move{ q o s D e l a y { V a l u e =1;}}} } / ∗ APIComp1 ∗ / decisions and edges in D are design alternatives available at a } / ∗ SwComp1 ∗ / . . . } specific vertex of D. The projection function pi = pVi , pEi :} / / TTA1 Gi × Gi+1 → Gi is defined and returns the graph Gi involved Listing 2. Platform Model for the case study in the product. Using this abstraction, a graph G is a sub-graph of D and represents a candidate design. Using the categorical graph product as abstraction, DSE is performed for multiple design activities simultaneously, as
  17. 17. DesignSpace specificTaskMapping ( algorithms, to improve the optimization step during candidate D e s i g n D e c i s i o n v1 , D e s i g n D e c i s i o n v2 , DesignSpace inDesignSpace , generation: Crowding Population-based Ant Colony Optimiza- tion for Multi-Objective (CPACO-MO) [40] and Random. String task , String processor ) : l e t t 2 = v2 . g e t ( ’ ’TASK’ ’ ) : Actually, H-SPEX is not limited to these algorithms, and l e t p2 = v2 . g e t ( ’ ’ PROCESSOR ’ ’ ) we are planning to integrate this tool to some optimization ( ( t 2 == g e t T a s k ( t a s k ) ) && ( p2 ! = g e t P r o c e s s o r ( p r o c e s s o r ) ) ? framework to improve the optimization support with analysis i n D e s i g n S p a c e . removeEdge ( v1 , v2 ) : n u l l − t h i s ; > and graphical features. The optimization is observed as a Listing 3. Sample of exploration rules black-box transformation, which uses an API to communicate information between the transformation engine and the op- timization algorithm. In order to evaluate candidate designs, we use an extended version of SPEU [35], a static analysiseach product represents a design activity. Specific properties tool, which provides a very fast evaluation step, which is theof this product, such as a restriction on the adjacencies, reduce bottleneck of the DSE process. However, any other evaluationthe number of available alternatives, as the navigation on the tool could be used, since the evaluation tool and H-PSEX aredesign space is performed through the edges. Moreover, this integrated by assigning the costs for a DSESolution in therepresentation overcomes the interdependence between design DSE model. The DSESolution is then obtained by meansactivities, as one vertex in the design space represents multiple of model-to-model transformations or using the API generateddesign decisions at the same time. This abstraction also by the EMF tool from the DSE Metamodel.exposes the communication (dependencies) between elementsand is well suited to combine the communication in multiple C. Formal Verification Based on LTAhierarchies, such as classes, task, processors, and systems. One of the important aspects in the design of embedded 2) Design Space Exploration Rules: In our approach, ex- systems is to ensure that a given system really does what itploration rules are model-to-model transformation rules, which is intended to do. Nowadays, with the growing complexity offollow the Mapping Metamodel and are specified using the embedded systems, an exhaustive test of all possible systemXtend language. These rules receive an instance of a uncon- executions, or of at least a set of representative ones, is anstrained DesignSpace as input and generate a constrained impractical or even impossible approach. An alternative toDesignSpace instance as output. They are constraints to testing is mathematically proving correctness, by specifyingguide and prune the available design space, to reduce the precise models of the embedded system and formally verifyingexploration time, and to ensure the feasibility of a candidate logical properties over these models.solution. The user of our DSE method is expected to define An LTA is an extension of the classic finite-state automatasome rules, which apply to his/her specific DSEProblem. concept [6] and captures the behavior of a system by means ofHowever, to alleviate the user effort, a set of typical rules states and transitions between states, where timing constraintswas implemented and is provided as a library to the user. can be associated to the transitions.As example, a rule named specificTaskMapping is illustrated In our approach, by means of model transformations, wein the Listing 3 and is applied when a Composite diagram generate an LTA from each InteractionGraph and asuch as the one in Figure 7 is specified. Other examples of set of InteractionGraphs will produce a network ofimplemented rules are: intercommunicating LTAs. By using model to code transfor- • Multiple Assignments of a Task: Avoids assigning the mations, we generate a textual representation for a network same task to different processors. of LTAs, which is submitted to the UPPAAL model checking • Lower / Upper Performance / Power/ Memory / Com- tool. UPPAAL is able to check for invariant properties, for munication Value: Defines the lower or upper values for example if a given formula is valid at all reachable states performance, power, memory, or communication amount of the LTAs, and reachability properties, as if given states for a task. are reachable or not during the execution of the network of • Task Deadline Violation: Removes the candidate from the LTAs. The generated network of LTAs can also be simulated population if there is a deadline violation. by UPPAAL, allowing one to visualize specific sequence of • Specific Processor Selection: Defines the processor type state transitions of the specified system and thus to debug that must be selected to implement the candidate design. possible specification errors. • Specific Task Execution Frequency: Defines the fre- 1) Generating LTA from UML: From the quency at which a processor must execute for a specific InteractionGraph in Figure 16, we obtain a network task. of timed automata, where we have a ltaProcess • Specific Task Mapping: Defines that a task must execute PWheelchair for the entire application and a in a specific processor. ltaProcess for each sequence diagram. By using 3) Design Space Exploration Tool: The DSE method pre- the Xpand language of the openArchitectureWare framework,sented in this work extends the H-SPEX tool [39], by im- we implemented model-to-code transformations that generate,plementing the design space abstraction method described in from the LTA model, the textual input for the UPPAALsubsection VI-B1. We also implement other two optimization model checker.
  18. 18. 2) Verifying Properties: At this point, the designer canspecify logical properties using CTL formulae and use UP-PAAL to verify them. As examples, we may specify propertiesto check if the application model is deadlock-free (using theUPPAAL macro A[] not deadlock) and if eventually allprocesses corresponding to the sequence diagrams will beexecuted in parallel (using the CTL formula E<> startsd1and startsd2 and startsd3). VII. C ASE S TUDY Ilustrating our approach, this section presents a develop-ment scenario for a real-time embedded system dedicated tothe automation and control of an intelligent wheelchair thathelps people with special needs. This wheelchair has severalfunctions, such as movement control, collision avoidance,navigation, target pursuit, battery control, system supervision,task scheduling, and automatic movement. Our flow starts by modeling the wheelchair system as Fig. 17. Normalized DSE results with five objectives: performance (+), powerprescribed in Section V-A. The UML model describes the ( . ), total memory (x), energy (*), and communication (o).wheelchair movement control, collision avoidance, and nav-igation Use Cases, which are essential to the system andincorporate critical hard real-time constraints. It also consists • mapping of the active objects to selected processors (upof a Class model, 18 interaction diagrams, and one composite to 6 processors);diagram. Some of the models were presented in the Section • allocation of the selected processors into a hierarchicalV-A. bus with two segments; The UML model is used as input to our design flow. The • processor voltage scaling with four distinct voltage levels.Application Manager transforms the UML model into our IM. Exploring all these activities simultaneously, H-SPEX wasNo user-defined Mapping is required, so we use only rules configured to optimize the system in terms of performancefrom our exploration rule library, described in Section VI-B2. (cycles), power (Watt), energy (Joules), total memory (bytes), The platform library provides software and hardware com- and communication volume (bytes transmitted on the bus).ponents to be reused during the implementation of an ap- The candidate population was found after 5,000 evaluationsplication. The components include mathematical functions to and represents the non-dominated set of candidate designs.solve control equations, algorithms for image filtering, a real- Figure 17 illustrates these results. The best overall candidatetime communication API, and RTOS components. The library must be selected after a trade-off analysis between the obtainedalso provides different architectures of a Java microcontroller, estimations and based on some criteria, such as weights forcommunication busses and hardware implementation of algo- the optimized objectives, or any other design feature.rithms. All components are previously characterized. Software The design space in this case study contains 2,064 alterna-components are simulated in the different microcontroller tive design decisions (vertices) and 334,080 edges, from whichmicroarchitectures, in order to define their QoS. This platform a set containing up to 17 (maximum active task distribution)was previously defined using the Eclipse Editor generated for vertices must be selected to define a candidate design solutionour Platform DSL, generating an instance of IPMM. (subgraph). The unveiled design space presents more than The System Designer coordinates the design automation 5.89 × 1041 alternative designs, considering an unrestrictedtools, invoking the HSPEX tool to perform DSE. The model design space (fully connected graph). However, in this pro-for the selected candidate is used for the transformation, which posal, edges guide the available alternatives, and constraints,generates the LTA Model as input for the UPPAAL tool for specified as model-to-model transformation rules, are locallyformal verification. After verification, the verified Implemen- applied between the current vertex and its neighbors, thustation Model is ready to be synthesized by the Implementation pruning the design space and speeding up the DSE process.Manager. Examples for DSE, formal verification, and synthesis Let a task drawn from the wheelchair case study beare provided in the next subsections. identified as T15, which implements a stereovision function (in Figure 18, T15 corresponds to the Correlation-based +A. A Design Space Exploration Median Filters vertex), presenting heavy image processing In the automatic DSE process performed in this scenario, algorithms. Figure 7 shows a composite diagram specifyingH-SPEX was configured to perform the following design tasks: that H-SPEX must map Task 15 into the DSP processor P0, • definition of which objects are active or passive benefiting from the DSP processor architecture. The resulting (runnables), among the 17 behaviors defined in the In- exploration rule from the Mapping model is presented in teraction Graphs; Listing 3.
  19. 19. LTATransitions, corresponding to the IGEdges labeled e1, e2, e3, e4, and e5. We also have an LTAProcess PWheelchair for the entire application. Thus, the diagram for the LTA model is very similar to the one for the InteractionGraphs model presented in Figure 16. By using the Xpand language of the openArchitectureWare framework, we implemented model-to-text transformations that generate, from the LTA model, the textual input for the UPPAAL model checker. Fig. 18. Task dependency graph for the wheelchair system. At this point, the designer can specify logical properties using CTL formulae and use UPPAAL to verify them. We have specified properties to check: if the application model is deadlock-free (using the UPPAAL macro A[] not deadlock); and if eventually all processes corresponding to the sequence diagrams will be executed in parallel (using the CTL formula E<> startsd1 and startsd2 and startsd3). C. Code Generation and Synthesis In our approach, the code generation strategy is based on templates. The generation tool uses the EMF API to obtain information from the Implementation Model and to complete these templates, which are specified using the Xpand language Fig. 19. Effect of constraints: Sample of a partial design space graph from openArchitectureWare. The code generator uses different templates, according to the specified resource in the Implementation Model. In this Let us consider a vertex from the design space graph be the way, communicating tasks allocated to different processorstuple T 13, P 1, C1, V 2 , which specifies that task T13 must imply the generation of specific communication directivesbe mapped to processor P1, while P1 must be allocated to and/or interconnection components. Likewise, the allocationcommunication bus C1 and execute T13 with voltage level V2. of various active tasks to the same processor implies theThere are 48 alternatives at this vertex. Figure 19 illustrates generation of scheduler services, as well as of real-timea partial graph, representing the design space at this vertex, directives on each active task to specify its activation pattern.which is located at the center. The shadowed vertices around Listing 4 shows part of the software source code that ourthe vertex T 13, P 1, C1, V 2 in the centre are pruned nodes, tool generates for the MovementController class, whichand the white nodes are the alternative designs that satisfy all includes objects responsible for controlling the wheelchairconstraints. movement. Applying the structural constraints and the sample design The software source code contains two important methodsconstraint here defined, the pruning process has reduced the for a RealtimeThread subclass: mainTask() (lines 18-design space by 83% on the specific vertex, avoiding wasting 23) and exceptionTask() (lines 24-26). The former rep-time with unnecessary evaluations and unfeasible designs, thus resents the task body, i.e. the code executed when the taskfocusing the search for an adequate solution on the most is activated. This is a periodic task, for which the periodicrelevant design points. activation is implemented as a loop with execution frequency being controlled by calling the waitForNextPeriod()B. Functional Verification method. This method uses the task release parameters to inter- After the selection of the candidate design after the DSE act with the scheduler and to control the correct execution ofprocess, the System Designer performs the transformation the method. The exceptionTask() method represents thefrom the InteractionGraphs in the Application Internal exception handling code that is triggered if the mainTask()model into the LTA model, according to the partition defined in method does not finish until the established deadline. We usethe Implementation model. As example, consider the Sequence the Java API for real-time specification described in [41].diagrams presented in Figure 6. From them we obtain the Besides the software source code generation, the design flownetwork of timed automata shown in Figure 20. is also automated by a set of generated scripts, which configure For the sequence diagram SD1, we have: an LTAProcess and execute compilers, synthesis tools, and simulators for thePSD1 with 6 LTALocations, corresponding to generated and assembled components of the Implementationthe IGNodes labeled Start-IG-SD1, cn-m1, Model. Thus, to perform the entire design flow, a designer cancn-m2, rn-m1, rn-m2, and end-IG-SD1; and 5 execute a script, such that all design process phases, including

×