MADES: A SysML/MARTE high level methodology for real-time and embedded systems Imran Rafiq Quadri * , Andrey Sadovykh * * Softeam, 21 Avenue Victor Hugo, 75016 Paris, France Email:{Firstname.Lastname}@softeam.fr Leandro Soares Indrusiak † † University of York, York, United Kingdom Email:[email protected]Abstract—Rapid evolution of real-time and embedded systems (RTES) is continuing at an increasing rate, and new method- ologies and design tools are needed to reduce design complexity while decreasing development costs and integrating aspects such as verification and validation. Model-Driven Engineering offers an interesting solution to the above mentioned challenges and is being widely used in various industrial and academic research projects. This paper presents the EU funded MADES project which aims to develop novel model-driven techniques to improve existing practices in development of RTES for avionics and surveillance embedded systems industries. MADES proposes a subset of existing UML profiles for embedded systems modeling: namely MARTE and SysML, and is developing new tools and technologies that support design, validation, simulation and eventual automatic code generation, while integrating aspects such as component re-use. In this paper, we first introduce the MADES language, which enables rapid system design and specification that can be then taken by underlying MADES tools for goals such as simulation or code generation. Finally, we illustrate the various concepts present in the MADES language by means of a car collision avoidance system case study. Index Terms—Real-Time and Embedded Systems, Model- Driven Engineering, SysML, MARTE, MADES language I. I NTRODUCTION Embedded systems have become an essential aspect of our professional and personal lives. From avionics, transport, defense, medical and telecommunication systems to general commercial appliances such as smart phones, gaming con- soles; these systems with real time constraints: Real-Time and Embedded Systems (RTES) are now omnipresent, and it is difficult to find a domain where these miniaturized sys- tems have not made their mark. The important characteristics of RTES include: low power consumption, reduced thermal dissipation and radiation emissions, among others; offering advantages and new opportunities to integrate more powerful, energy efficient processors, peripherals and related resources into the system. A. Motivations However, as computing power increases, more function- alities are expected to be realized and integrated into an embedded system. Unfortunately, the fallout of this complexity is that the system design (particularly software design) does not evolve at the same pace as that of hardware due to issues such as development budget limitations, reduction of product life cycles and design time augmentation. Additionally, de- velopment costs and time to market shoot up proportionally. Without the usage of effective design tools and methodologies, large complex RTES are becoming increasingly difficult to manage, resulting in critical issues and what has finally led to the famous productivity gap. The design space, representing all technical decisions that need to be elaborated by the design team is therefore, becoming difficult to explore. Similarly, manipulation of these systems at low implementation levels such as Register Transfer Level (RTL) can be hindered by human interventions and the subsequent errors. Thus effective design methodologies are needed to decrease the productivity gap, while resolving issues such as related to system complexity, verification and validation, etc. Among several possibilities, elevation of design abstraction levels seems the most promising one. High abstraction level based system design approaches have been developed in this context, such as Model-Driven Engineering (MDE) [1] that specify the system using the UML (Unified Modeling Language) graphical language. B. Elevating design abstraction levels MDE enables high level system modeling of both software and hardware, with the possibility of integrating heteroge- neous components into the system. It allows system level (application/architecture) modeling at a high specification level permitting several abstraction stages, each with a specific view point. This Separation of Views (SoV) enables a designer to focus on a domain aspect related to an abstraction stage thus permitting a transition from solution space to problem space. Using UML for system description increases the system comprehensibility as it enables designers to provide high- level descriptions of the system, that easily illustrate the internal concepts (data dependencies, hierarchy, etc.). These specifications can be reused, modified or extended due to their graphical nature. Thus, MDE offers an interesting solution to the above mentioned challenges and is being widely used in various industrial and academic research projects. It is supported by different technologies and tools such UML and related profiles for high level system specifications. Moreover, Model transformations [2] can then automatically generate executable models or code from these abstract high level design models.
Transcript
MADES: A SysML/MARTE high levelmethodology for real-time and embedded systems
Imran Rafiq Quadri∗, Andrey Sadovykh∗∗Softeam, 21 Avenue Victor Hugo,
Abstract—Rapid evolution of real-time and embedded systems(RTES) is continuing at an increasing rate, and new method-ologies and design tools are needed to reduce design complexitywhile decreasing development costs and integrating aspects suchas verification and validation. Model-Driven Engineering offersan interesting solution to the above mentioned challenges and isbeing widely used in various industrial and academic researchprojects. This paper presents the EU funded MADES projectwhich aims to develop novel model-driven techniques to improveexisting practices in development of RTES for avionics andsurveillance embedded systems industries. MADES proposes asubset of existing UML profiles for embedded systems modeling:namely MARTE and SysML, and is developing new tools andtechnologies that support design, validation, simulation andeventual automatic code generation, while integrating aspectssuch as component re-use. In this paper, we first introducethe MADES language, which enables rapid system design andspecification that can be then taken by underlying MADES toolsfor goals such as simulation or code generation. Finally, weillustrate the various concepts present in the MADES languageby means of a car collision avoidance system case study.
Index Terms—Real-Time and Embedded Systems, Model-Driven Engineering, SysML, MARTE, MADES language
I. I NTRODUCTION
Embedded systems have become an essential aspect ofour professional and personal lives. From avionics, transport,defense, medical and telecommunication systems to generalcommercial appliances such as smart phones, gaming con-soles; these systems with real time constraints:Real-Timeand Embedded Systems(RTES) are now omnipresent, and itis difficult to find a domain where these miniaturized sys-tems have not made their mark. The important characteristicsof RTES include: low power consumption, reduced thermaldissipation and radiation emissions, among others; offeringadvantages and new opportunities to integrate more powerful,energy efficient processors, peripherals and related resourcesinto the system.
A. Motivations
However, as computing power increases, more function-alities are expected to be realized and integrated into anembedded system. Unfortunately, the fallout of this complexityis that the system design (particularly software design) doesnot evolve at the same pace as that of hardware due to issuessuch as development budget limitations, reduction of product
life cycles and design time augmentation. Additionally, de-velopment costs and time to market shoot up proportionally.Without the usage of effective design tools and methodologies,large complex RTES are becoming increasingly difficult tomanage, resulting in critical issues and what has finally ledtothe famousproductivity gap. The design space, representingall technical decisions that need to be elaborated by the designteam is therefore, becoming difficult to explore. Similarly,manipulation of these systems at low implementation levelssuch asRegister Transfer Level(RTL) can be hindered byhuman interventions and the subsequent errors.
Thus effective design methodologies are needed to decreasethe productivity gap, while resolving issues such as relatedto system complexity, verification and validation, etc. Amongseveral possibilities, elevation of design abstraction levelsseems the most promising one. High abstraction level basedsystem design approaches have been developed in this context,such asModel-Driven Engineering(MDE) [1] that specifythe system using the UML (Unified Modeling Language)graphical language.
B. Elevating design abstraction levels
MDE enables high level system modeling of both softwareand hardware, with the possibility of integrating heteroge-neous components into the system. It allows system level(application/architecture) modeling at a high specification levelpermitting several abstraction stages, each with a specificviewpoint. This Separation of Views(SoV) enables a designerto focus on a domain aspect related to an abstraction stagethus permitting a transition from solution space to problemspace. Using UML for system description increases the systemcomprehensibility as it enables designers to provide high-level descriptions of the system, that easily illustrate theinternal concepts (data dependencies, hierarchy, etc.). Thesespecifications can be reused, modified or extended due to theirgraphical nature. Thus, MDE offers an interesting solutionto the above mentioned challenges and is being widely usedin various industrial and academic research projects. It issupported by different technologies and tools such UML andrelatedprofilesfor high level system specifications. Moreover,Model transformations[2] can then automatically generateexecutable models or code from these abstract high leveldesign models.
C. Our contributions
Here, we first provide an overview of the MADES projectfollowed by our contributions. MADES [3], [4] is an EUfunded FP7 project which aims to develop novel model-driven techniques to improve existing practices in develop-ment of real-time and embedded systems for avionics andsurveillance embedded systems industries. MADES proposesan effective subset of existing UML profiles for embeddedsystems modeling: namely SysML [5] and MARTE [6], andis developing new tools and technologies that support design,validation, simulation and eventual automatic code generation,while integrating aspects such as component re-use.
The contributions of this paper relate to presenting a com-plete methodology for the design of RTES using a combinationof both SysML and MARTE, while avoiding incompatibilitiesresulting from simultaneous usage of both profiles. While alarge number of works deal with embedded systems specifica-tions using only either SysML or MARTE, we aim to presenta combined approach and illustrate the advantages of using thetwo profiles. This contribution is significant in nature as whileboth these profiles provide numerous concepts and supportingtools, they are in turn difficult to be mastered by systemdesigner. For this purpose, we present the MADES language,which associated with the namesake project focuses on aneffective subset of SysML and MARTE profiles and proposesa specific set of unique diagrams for expressing differentaspects related to a system. In the paper, an overview of theMADES language and the associated diagrams is presented,that enables rapid design and progressive composition ofsystem specifications. The resulting models then can be takenby underlying MADES tools for goals such as simulation orautomatic code generation.
Finally, we illustrate the various concepts present in theMADES language by means of an effective real life embeddedsystems case study: acar collision avoidance systemthatintegrates the MADES language and illustrates the differentphases of our developed design methodology.
The rest of this paper is organized as follows: section IIillustrates some related works, while section III gives a briefoverview of the MADES project, followed by a summarizeddescription of the MADES language in section IV. Afterwards,section V presents our case study followed by a conclusion insection VI.
II. RELATED WORKS
While a large number of researches exist that make use ofeither SysML or MARTE for high level modeling of embeddedsystems, due to space limitations, it is not possible here togivean exhaustive description and we only provide a brief summaryon some of the works that make use of SysML or MARTEbased high abstraction levels and Model-Driven Engineering,for RTES design and implementation.
The MoPCoM project [7] uses MARTE profile to targetmodeling and code generation of reconfigurable embeddedsystems. While the project inspires from SysML concepts suchas requirements and blocks, they are not fully integrated in
the design flow. The project uses the IBM Harmony1 processcoupled with Rhapsody2 UML modeling tool. Additionally,MoPCoM proposes two distinct flows for system modeling andschedulability analysis that increase design efforts. Similarly,eDIANA [8] is an ARTEMIS project that uses MARTE profilefor RTES specification and validation. However, detailed spec-ification of software and hardware aspects are not illustratedin the project. While TOPCASED [9] differs from MADES,as it focuses primarily on IDE infrastructure for embeddedsystems and not on particular implementations.
Project SATURN is [10] is another EU FP7 project that aimsto use high level co-modeling approach for RTES simulationand synthesis goals. However, the project only takes SysMLinto account and proposes a number of UML profiles forco-simulation, synthesis and code generation purposes. Thegoal is to use carry out hardware/software modeling via theseprofiles and generate SystemC for eventual VHDL translationand FPGA implementation. Unfortunately, the project does notutilizes the MARTE profile for hardware/software co-designmodeling. In [11], the authors provide a mixed modelingapproach based on SysML and the MARTE profiles to addressdesign space exploration strategies. However, the shortcomingsof this approach is that they only provide implementationresults by means of mathematical expressions and no actualexperimental results were illustrated.
The OMEGA European project [12] is also dedicated tothe development of critical real-time systems. However it usespure UML specifications for system modeling and proposes aUML profile [13], which is a subset of the earlier UML profilefor Scheduling, Performance and Time (SPT), that has beenintegrated in MARTE. The MARTES project emphasizes oncombined usage of UML and SystemC for systematic model-based development of RTES. The results from this project inturn, have contributed to the creation of the MARTE profile.While INTERESTED [14] proposes a merged SysML/MARTEmethodology where SysML is used for requirement specifica-tions and MARTE for timing aspects, it does not proposesrules on combined usage of both profiles.
The MADES project aims to resolve this issue and thusdifferentiates from the above mentioned related works, asit focuses on an effective language subset combining bothSysML and MARTE profiles for rapid design and specificationof RTES. The two profiles have been chosen as they are bothwidely used in embedded systems design, and are complimen-tary in nature [15]. MADES proposes automatic generationof hardware descriptions and embedded software from highlevel models, and integrates verification of functional andnon-functional properties, as illustrated in the following section.
III. MADES: GOALS AND METHODOLOGY
In this section, we provide a brief overview of the MADESdesign methodology, as illustrated in Fig.1. Initially, the highlevel system design models are carried out using the MADES
language and associated diagrams, which are represented lateron in section IV. After specification of the design modelsthat include user requirements, related hardware/software as-pects and their eventual allocation along with schedulabilityanalysis; underlying model transformations (model-to-modeland model-to-text transformations) are used to bridge thegap between these abstract design models and subsequentdesign phases, such as verification, hardware descriptionsof modeled targeted architecture and generation of platformspecific embedded software from architecturally neutral soft-ware specifications. For implementing model transformations,MADES uses the Epsilon platform [16], that enables modeltransformations, code generation, model comparison, merging,refactoring and validation [17].
MADES Language
Design Models
Pla orm-
agnos c
code Hardware
architecture
descrip on
Hardware/
so ware
mappings
Compile-Time Virtualiza on
Pla orm-speci c code
Embedded software generation
Veri�cation
Veri ca on
scriptsUser input
Simula on
scripts
Zot veri ca on
MHS descrip on
VHDL
Hardware description
generation
Figure.1: An overview of the global MADES methodology
Verification activities in MADES comprise of verificationof key properties of designed concepts (such as meetingdeadlines, etc.) and that of model transformations integratedin the design flow [18], [19]. For verification and simulationpurposes, MADES uses the Zot tool [20], that permits veri-fication of aspects, such as meeting critical deadlines, amongothers. While closed-loop simulation on design models enablefunctional testing and early validation.
Additionally, MADES employs the technique ofCompile-Time Virtualization(CTV) [21], for targeting of non-standardhardware architectures, without requiring development ofnewlanguages or compilers. Thus a programmer can write architec-turally neutral code which is automatically distributed byCTVover a complex target architecture. Finally, code generation(either in C/C++ or VHDL) can be carried out that can beeventually implemented on modern state of the art FPGAs.Currently MADES targets Xilinx FPGAs, however it is alsopossible to adapt to FPGAs provided by other vendors suchas Altera or Atmel. Detailed description regarding the globalMADES methodology can be found in [22].
IV. MADES LANGUAGE: SYSML/MARTE SUBSET
Fig.2 gives an overview of the MADES language inherentlypresent in the design flow for the initial design models. The
MADES language focuses on a subset of SysML and MARTEprofiles and proposes a specific set of diagrams for specifyingdifferent aspects related to a system: such as requirements,hardware/software concepts, etc. Along with these specificunique diagrams, MADES also uses classic UML diagramssuch asStateandActivity diagrams to model internal behaviorof system components, along withSequenceand InteractionOverview diagrams to model interactions and cooperationbetween different system elements. Softeam’s UML Modeliotool [23] enables full development of MADES diagramsand associated language, while a partial integration has beencurrently carried out for a MADES open source modeler, thatis an extension of the Papyrus UML modeler [24]. We nowprovide a brief description of the MADES language and itsrelated diagrams.
Figure.2: Overview of MADES language design flow
In the initial specification phase, a designer needs to carryout system design at high abstraction levels. This design phaseconsists of the following steps:
• System Requirements: The user initially specifies therequirements related to the system. For this purpose, aMADES Requirements Diagram is utilized that inte-grates SysML requirements concepts.
• Use case Scenarios: Afterwards, the system requirementsare converted into use cases, described using MADESUse Case Diagram that encapsulate SysML use caseconcepts. This design phase is strongly related to thefunctional high level specification described subsequently.
• High Level Specification: Each use case is convertedinto a SysML block by means of MADESHighLevel Block (or Internal Block) SpecificationDiagram, that contains SysML Block (or internal block)concepts respectively. This functionality is independentofany underlying execution platform and software details.It thus determineswhat is to be implemented, instead ofhow it is to be carried out.
• Refined High Level Specification: The Refined HighLevel Specification Diagram models MARTEcomponents, each corresponding to a SysML block.Here, MARTE’s High level Application Modelingpackage is used to differentiate between active andpassive components of the system.
The refined high level specification permits to link SysMLand MARTE concepts while avoiding conflicts arising due
to parallel usage of both profiles [15]. The conflicts relatedto the two profiles are avoided as we do not mix SysMLand MARTE concepts in the same diagram, but instead focuson a refinement scheme. Thus SysML is used for initialrequirements and functional description, while MARTE isutilized for the enriched modeling of the global functionalityand execution platform/software modeling.
Thus, once the refined functional description is completed,the designer can move onto the partitioning of the system inquestion: depending upon the requirements and resources inhand, he or she can determine which part of the system needsto be implemented in hardware or software. We now describethe different steps related to each design level by means ofMARTE concepts.
Related to the MARTE modeling, an allocation betweenhigh level and refined high level specifications is carried outusing a MADESAllocation Diagram. Afterwards, a co-design approach [25] is used to model the hardware andsoftware aspects of the system. The modeling is combinedwith MARTE Non Functional PropertiesandTimed Modelingpackage to express aspects such as throughput, temporalconstraints, etc. We now describe the hardware and softwaremodeling, which are as follows:
• Hardware Specification: The MADES Hardware
Specification Diagram in combination withMARTE’s Generic Resource Modelingpackage enablesmodeling of abstract hardware concepts such ascomputing, communication and storage resources. Thedesign level enables a designer to describe the physicalsystem albeit at a abstraction level higher than thedetailed hardware specification level. By making useof MARTE GRM concepts, a designer can describe aphysical system such as a car, a transport system, flightmanagement system, among others.
• Detailed Hardware Specification: Using theDetailedHardware Specification Diagram with MARTE’sHardware Resource Modelingpackage allows extensionand enrichment of concepts modeled at the hardwarespecification level. It also permits to model systemssuch as FPGA based System-on-Chips (SoCs), ASICsetc. A one-to-one correspondence usually follows here:for example, a computing resource typed as MARTEComputingResource is converted into a hardware pro-cessor, such as a PowerPC or MicroBlaze [26], effectivelystereotyped as MARTEHwProcessor. Once the detailedmodeling is completed, an allocation diagram is thenutilized to map the modeled hardware concepts to detailedhardware ones.
• Software Specification: The MADES Software
Specification Diagram along with MARTE’sGeneric Resource Modelingpackage permits modelingof software aspects of an execution platform such asschedulers and tasks; as well as their attributes andpolicies (e.g. priorities, possibility of preemption).
• Detailed Software Specification: The MADESDetailedSoftware Specification Diagram and related
MARTE’s Software Resource Modelingare used toexpress aspects of the underlyingOperating System(OS). Once this model is completed, an allocationdiagram is used to map the modeled software conceptsto detailed software ones: for example, allocation oftasks onto OS processes and threads. This level canexpress standardized or designer based RTOS APIs.Thus multi-tasking libraries and multi-tasking frameworkAPIs can be described here.
Iteratively, several allocations can be carried out in ourdesign methodology: a software to hardware allocation permitsto associate schedulers and schedulable resources to relatedcomputing resources in the execution platform, once theinitial abstract hardware/software models are completed.Sub-sequently this initial allocation could lead to further enrichedallocation between the detailed software and hardware models(an allocation of OS to a hardware memory, for example).An allocation can also specify if the execution of a softwareresource onto a hardware module is carried out in a sequentialor parallel manner. It should be noted that MARTEGenericComponent Modelingpackage is used throughout the MADESdiagrams dealing with MARTE stereotypes for describingthe modeled concepts in a modular manner. Each MADESdiagrams only contains commands related to that particulardesign phase, thus avoiding ambiguities of utilization of thevarious concepts present in both SysML and MARTE.
Additionally, MARTE enables analysis based on schedula-bility and performance criteria. Once a complete system isspecified and eventually allocated; UML behavioral diagramscan be used in association with MARTESchedulability Anal-ysis Modelingpackage for describing the behavior of systemcomponents or the system itself. The schedulability analysishelps to determine aspects such as worst case execution times,missed deadlines etc; which can be expressed by the high levelmodels and in turn used as input for a schedulability analysistool, providing results that enableDesign Space Explorationaspects by modifying in turn the high level design models.
Once the modeling aspects are completed, the high levelmodels can be utilized by model transformations to produceintermediate or executable enriched models as well as codefor eventual implementation. Afterwards, simulation can becarried out using third party tools to verify the correctnessand functionality of the generated code before moving ontosynthesis which enables to create actual implementation ofa RTES, for example a prototype in case of an FPGA. ForMADES, all these aspects related to verification, automaticcode generation and hardware implementation have been de-tailed in [27]. We now present our case study that illustratesour combined SysML and MARTE design methodology.
V. CAR COLLISION AVOIDANCE SYSTEM CASE STUDY
We now provide the car collision avoidance system (CCAS)case study that is modeled in Modelio using the MADESlanguage and underlying methodology. Verification aspects,automatic code generation and hardware implementation re-
lated to the CCAS have been illustrated in [27], and are notthe scope of this paper.
The car collision avoidance system or CCAS for short, wheninstalled in a vehicle, permits to detect and prevent collisionswith incoming objects such as cars and pedestrians. The CCASas shown in Fig.3 contains two types of detection modules.The first one is a radar detection module that emits continuouswaves. A transmitted wave when collides with an incomingobject, is reflected and received by the radar itself. The radarsends this data to an obstacle detection module, which inturn removes the noise from the incoming signal along withother tasks such as a correlation algorithm. The distance ofthe incoming object is then calculated and sent to a primarycontroller for appropriate actions.
Figure.3: The CCAS installed on a car to avoid collisions withincoming objects
The image tracking module is the second detection moduleinstalled in the CCAS. It permits to determine the distance ofthe car from an object by means of image computation. Thecamera takes pictures of incoming objects and sends the datatoa secondary controller, which executes a distance algorithm. Ifthe results of the computation indicate that the object is closerto the car then a specified default value that means a collisioncan occur. The result of this data is then sent to the primarycontroller of the CCAS.
The primary controller when receives the data, acts accord-ingly to the situation at hand. In case of an imminent collision,it can carry out some emergency actions, such as stopping theengine, applying emergency brakes; otherwise if the collisionis not imminent, it can decrease the speed of the car and canapply normal brakes. We now describe the CCAS system indetail subsequently.
A. SysML based modeling of CCAS
The CCAS design specifications start with SysML basedmodeling, which involves the initial design decisions suchassystem requirements and functionality description.
1) Requirement Specifications:We first move on to thesystem requirements that basically describe the overall needs,constraints and limitations of the system. Using the SysMLinspired MADES Requirements Diagram, it is possible todescribe the system requirements at the initial phase of systemconception. In Fig.4, we illustrate the different requirementsof the CCAS system. It should be mentioned that only thefunctionalrequirements of a system are described at this level.
Here, the different requirements for the CCAS aredescribed: theGlobal Collision Avoidance Strategydetermines the global requirement for the system which isto detect incoming objects by means of either the radar orthe image tracking system. Additional requirements can bederived from this global requirement, such as theImminentCollision Strategy, Near Collision Avoidance
Strategy, Additional Timing requirements andChanging Lanes Strategy. It should be noted that thisrequirement specification is not complete in nature andhas a strong relation with other MADES diagrams. Morespecifically, these specifications rely on use case scenarios andthe functional blocks, described in turn inHigh level BlockSpecification Diagramfor their completion, as illustratedlater on. We thus will revisit this requirement diagram oncewe specify these other aspects.
Initially, the user describes the system requirements whichstate that if the distance from an object is less than 3 metersthan the CCAS should enter in a warning state. If it remainsin that state for 300 ms and distance is still less than 3 meters,then the CCAS should decrease car speed and alert the driverby means of an alarm and a Heads-up-display (HUD). If thedistance falls to 2 meters, the CCAS should enter in a criticalwarning state. If it remains in that state for 300 ms and distanceis still less than 2 meters, then CCAS should apply emergencybrakes, deploy airbags and alert the driver as well.
The radar or the im age track ing
m odule should send the data to the
Controller every 100 m s v ia the
system bus and the comm un ication
should take 20 m s, dur ing which
the bus should be busy . I n case of
imm inent colli sion, the controller
should send the brake comm and
which should take no m ore than 20
m s
A dd i t i o n a l T i m i n g r e q u i r e m e n t s
When the dr iver is about to
change lanes or if the car
dev iates f rom the curr ent
lane intentionally , the dr iver
should b e notif ied v ia the
HUD. I f the dr iver is chaning
lanes him self, the car turn
signal should be on
Ch a n g i n g La n e s St r a t e g y
When ex ternal obj ect is less than 3
m eters away , the controller should
swi tch to a warning state. I f the system
rem ains in this state f or 300 m s, then
the dr iver should b e notif ied v ia an
alarm and HUD, norm al b rakes should
be app lied for 10 m s f or reducing car
spee d. Hazard warning lights should be
activated in the HUD.
Ne a r Co lli s i o n A v o i d a n ce St r a t e g y
When ex ternal obj ect is less than 2
m eters away , the dr iver should be
notif ied by an alarm and HUD, and
system should switch to a cr it ical
warning state. I f the system rem ains in
cr it ical warning state f or m ore than 300
m s and distance f rom obj ect is st ill less
than 2 m eters then the engine should be
stopp ed, brakes should be app lied,
seatbelts should be tensioned and air
bag should be deployed. The brakes
should be app lied f or 100 m s
I mm i n e n t Co lli s i o n St r a t e g y
Detect Colli sion by m eans of the
installed radar detection or by the
im age track ing system . Switching
betwee n radar and im age track ing
depending upon user requirem ents and
weather condit ions. Take app ropr iate
actions to avoid colli sions and notify
the dr iver
Gl o b a l Co lli s i o n A v o i d a n ce St r a t e g y
<<derive>>
<<derive>> <<derive>>
<<derive>>
Figure.4: Initial requirements specifications for the CCAS
Driver
Car Usecase Scenarios
No t i f i ca t i o n s t o o t h e r ca r s a n d p e d e s t r i a n s
A v o i d Co lli s i o n s
A pp l y Br a k e s
De c r e a se Sp ee d
Re v e r se Ca r
St o p Ca r
Dr i v e Ca r
St a r t Ca r
<<extend>>
<<extend>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Figure.5: The different case scenarios related to the CCAS
2) Use case scenarios:Once the requirement phase ispartially completed, we move onto describing the use case sce-narios associated with our system via the MADESUse CaseDiagram. Here in Fig.5, we describe the different scenariosassociated with the car on which the CCAS is installed. The
figure illustrates some basic scenarios, such as the car beingstarted, stopped or being driven. TheAvoid Collisionsscenario makes use of other specified scenarios and is theone that is related to the system requirements described in thesection.V-A1.
3) High Level Specification:Once the requirements anduse case scenarios of our system are specified; we moveonto the functional block description of the CCAS systemas described in Fig.6. For this, MADESHigh Level BlockSpecificationor High Level Internal Block Specificationdia-grams are used. This conception phase enables a designer todescribe the system functionality without going into detailshow the functionality is to be eventually implemented. Herethe functional specification is described using SysML blockdefinition diagram concepts. The functional description canbe specified by means of UML concepts such as aggregation,inheritance, composition etc. Equally, hierarchical compositionof functional blocks can be specified by means of internalblocks, ports and connectors. Here we use these conceptsfor describing the global composition of the CCAS. TheCar block is composed of some system blocks such as aIgnition System, Charging System, Starting System,Engine Component Parts, Transmission System and fi-nally theCar Collision Avoidance Module which is themain component related to our case study. Each functionalblocks can be composed of internal blocks, however, this stephas not been illustrated in the paper.
0..1
1..*
0 ..1
2 ..*
0 ..1
1
0..11
0..1
1
0..1
1
0..11
0..1
1
0..1
1
0..1
1
0..1
1
0..1
1
0..1
1
0..1
1
0..1
1 0..1
1
0..1
1
0..1
1
0..1
1
0..1
1
Ca r
<< Bl o ck > >
En g i n e Coo li n g Sy s t e m
<< Bl o ck > >
En g i n e Oil Sy s t e m
<< Bl o ck > >
Ex h a u s t Sy s t e m
<< Bl o ck > >
Tr a n sm i ss i o n Sy s t e m
<< Bl o ck > >
Su sp e n s i o n a n d St ee r i n g Sy s t e m
<< Bl o ck > >
Fu e l Su pp l y Sy s t e m
<< Bl o ck > >
W i r i n g Ha r n e ss e s
<< Bl o ck > >
Ca r Co lli s i o n A v o i d a n ce Mo d u l e
<< Bl o ck , Re q u i r e m e n t Re l a t e d , A ll o ca t e d > >
W h ee l a n d T i r e Pa r t s
<< Bl o ck > >
W i n d o w s
<< Bl o ck > >
Doo r s
<< Bl o ck > >
Ch a r g i n g Sy s t e m
<< Bl o ck > >
A u d i o / Vi d e o Mu l t i m e d i a De v i ce s
<< Bl o ck > >
El e c t r i c Su pp l y Sy s t e m
<< Bl o ck > >
A i r Co n d i t i o n e r Sy s t e m
<< Bl o ck > >
Ga u g e s a n d Me t e r s
<< Bl o ck > >
I g n i t i o n Sy s t e m
<< Bl o ck > >
Sw i t ch e s
<< Bl o ck > >
St a r t i n g Sy s t e m
<< Bl o ck > >
En g i n e Co m p o n e n t Pa r t s
<< Bl o ck > >
Figure.6: High level specification using SysML block concepts
A v o i d Co lli s i o n s
The radar or the im age track ing
m odule should send the data to the
Controller every 100 m s v ia the
system bus and the comm un ication
should take 20 m s, dur ing which
the bus should be busy . I n case of
imm inent colli sion, the controller
should send the brake comm and
which should take no m ore than 20
m s
A dd i t i o n a l T i m i n g r e q u i r e m e n t s
When the dr iver is about to
change lanes or if the car
dev iates f rom the curr ent
lane intentionally , the dr iver
should b e notif ied v ia the
HUD. I f the dr iver is chaning
lanes him self, the car turn
signal should be on
Ch a n g i n g La n e s St r a t e g y
When ex ternal obj ect is less than 3
m eters away , the controller should
swi tch to a warning state. I f the system
rem ains in this state f or 300 m s, then
the dr iver should b e notif ied v ia an
alarm and HUD, norm al b rakes should
be app lied for 10 m s f or reducing car
spee d. Hazard warning lights should be
activated in the HUD.
Ne a r Co lli s i o n A v o i d a n ce St r a t e g y
When ex ternal obj ect is less than 2
m eters away , the dr iver should be
notif ied by an alarm and HUD, and
system should switch to a cr it ical
warning state. I f the system rem ains in
cr it ical warning state f or m ore than 300
m s and distance f rom obj ect is st ill less
than 2 m eters then the engine should be
stopp ed, brakes should be app lied,
seatbelts should be tensioned and air
bag should be deployed. The brakes
should be app lied f or 100 m s
I mm i n e n t Co lli s i o n St r a t e g y
Detect Colli sion by m eans of the
installed radar detection or by the
im age track ing system . Switching
betwee n radar and im age track ing
depending upon user requirem ents and
weather condit ions. Take app ropr iate
actions to avoid colli sions and notify
the dr iver
Gl o b a l Co lli s i o n A v o i d a n ce St r a t e g y
<<satisfy>>
<<satisfy>>
<<satisfy>> <<satisfy>>
<<satisfy>>
<<refine>>
<<derive>>
<<derive>> <<derive>>
<<derive>>
Ca r Co lli s i o n A v o i d a n ce Mo d u l e
<< Bl o ck , Re q u i r e m e n t Re l a t e d , A ll o ca t e d > >
Figure.7: Completing the functional specifications of theCCAS
4) Completing the Requirement Specifications:Once wehave finished the use case scenarios and functional block
specification of our system, it is possible for us to completethe requirement specifications, as described in Fig.7.
As seen here, a related use case scenario and a functionalblock has been added to the figure, which helps to completeand satisfy the high level system requirements. It should benoted here, that as seen in Fig.7, only theCar CollisionAvoidance Module block specified in the diagram is utilizedto satisfy the global system requirements. Thus, these systemrequirements can be refined once an initial functional speci-fication of system is completed. Since we are only interestedin the Car Collision Avoidance Module and not otherfunctional blocks of the car, it is this module that is the focusof the subsequent design phases.
B. MARTE based modeling of CCAS
Once the initial design descriptions have been specified, itispossible to partition and enrich the high level functionalities.For this, MARTE concepts are used to determine whichparts of the system are implemented in software or hardwarealong with their eventual allocation. Additionally, MARTEprofile enables to express non-functional properties relatedto a system, such as throughput, worst case execution times,etc. We now describe the MARTE based design phases in thesubsequent sections.
1) Refined High Level Specification:We now turn towardsthe MARTE based modeling of the CCAS. All necessaryconcepts present at theHigh Level Specification Diagramcorrespond to an equivalent concept at theRefined HighLevel Specification Diagram. Since we are only interested inthe Car Collision Avoidance Module at the higher levelspecifications, an equivalent MARTE component is created.TheRH Car Collision Avoidance Module is stereotypedas a MARTERtUnit that determines the active nature of thecomponent. Fig.8 shows the related modeling of this concept.TheRtUnit modeling element is the basic building block thatpermits to handle concurrency in RTES applications [6]. Itshould be mentioned that component structure and hierarchyshould be preserved between the two high level specificationdiagrams. As in this particular example, no hierarchical com-positions are present at the high level specifications forCar
Collision Avoidance Module, they are equally not presentin the underlying refined high level specifications.
RH_ Ca r Co lli s i o n A v o i d a n ce Mo d u l e
<< Rt Un i t > >
Figure.8: Refined high level specification of the CCAS
<< Bl o ck , Re q u i r e m e n t Re l a t e d , A ll o ca t e d > >
RH_ Ca r Co lli s i o n A v o i d a n ce Mo d u l e
<< Rt Un i t , A ll o ca t e d > >
Figure.9: Allocation between high level/refined high levelspecifications
2) Allocating High Level and Refined High Level Specifica-tions: Afterwards, an allocation using the MADESAllocation
Diagram is used to map the high level specification conceptsto the refined high level specification concepts. This aspectis represented in Fig.9. Using the MARTEallocation mecha-nism, we express that the allocation ishybrid (both structuraland behavioral aspects are thus related from source to target)andspatial in nature.
3) Clock Specification:Once the initial specification hasbeen carried out, modeling of hardware and software aspectsof the required functionality is possible in a parallel manner.For that purpose, we first model the different clock types whichare used by the execution platform of the CCAS, as illustratedin Fig.10. Here, an initial ideal clock type serves as the basisfor the Hardware and System clock types. All the clockstypes are discrete in nature using the MARTETimepackage.
<<TimedDomain>> CCAS Time Domain
I d e a l Cl o ck { n a t u r e ( d i sc r e t e ) , i sLo g i ca l }
<< Cl o ck Ty p e > >
Sy s t e m Cl o ck { n a t u r e ( d i sc r e t e ) , r e so l A tt r ( 10 ) }
<< Cl o ck Ty p e > >
Ha r d w a r e Cl o ck { n a t u r e ( d i sc r e t e ) , r e so l A tt r ( 10 ) }
<< Cl o ck Ty p e > >
Figure.10: Specification of clock types related to CCAS
We first define time domain to contain the clock typesrelated to the system. For this, a packageCCAS Time Domainstereotyped asTimedDomain is created, respecting the tim-ing notions in MARTE. Afterwards, we specify the clocktypes present in our system as illustrated in the figure. Wespecify three clock types:IdealClock, SystemClock andHardwareClock; all appropriately stereotyped asClockType.TheIdealClock is the basic clock type present in the systemreferencing a certain frequency, while the other two referencethis basic clock and run at much higher frequencies.
sys clk:SystemClock
<<Clock, ClockRe source>>
air bag:Air bag
<<DeviceRe source>>
belts:Seat belts
<<DeviceRe source>>
display:HUD Display
<<DeviceRe source>>
cam:Camera
<<DeviceRe source>>
img mem:Image Processor Memory
<<StorageRe source>>
img proc:Image Processor Secondar Controller
<<ComputingRe source>>
ctrl mem:Controller Memory
<<StorageRe source>>
ctrl:Controller
<<ComputingRe source>>
can:CAN
<<Comm unicationMedia>>
shared mem:Shared Memory
<<StorageRe source>>
odm:Obstacle Detection Module
<<DeviceRe source>>
radar:Radar
<<DeviceRe source>>
alarm:Alarm
<<DeviceRe source>>
add sens:Add itional Sensors
<<DeviceRe source>>
ligh-sig sys:Lightning and Signaling System
<<DeviceRe source>>
braking sys:Braking System
<<DeviceRe source>>
{The
Sys temC lock
has a rate 10
times fas ter than
the IdealC lock}
C onstraint
Figure.11: Abstract hardware specification of CCAS
4) Hardware Specification:At the hardware specificationlevel, we first model the abstract hardware concepts of theexecution platform in Fig.11. The abstract hardware modelingof the execution platform of the CCAS contains primary andsecondary controllers for radar/image tracking modules, theirrespective local and shared memories, system clock and addi-tional hardware resources (radar and camera modules, brakingsystem, etc.); all of which communicate via a CAN bus. TheMARTE GRM package stereotypes are applied onto the dif-ferent hardware resources: for exampleComputingResourcefor the primary and secondary controllers,StorageResourcefor the local and shared memories,CommunicationMedia forthe CAN bus, while DeviceResource is used for the other
hardware components. Here, the hardware specification alsocontains a clocksysclk of the typeSystemClock specifiedearlier in Fig.10. Here using the MARTETime package, weadd a clock constraint onto the clock, specifying that this clock(and related clock type) runs at a rate 10 times faster than thatof the ideal clock.
The hardware specification contains different hardwarecomponents which themselves are either further composedof sub components, or have internal behaviors, expressed bymeans of classic UML behavioral diagrams. We now describethe internal behavior of three hardware components:
SystemClock
receivingData
Figure.12: Behavior of the radar module present in the CCAS
Figure.14: Internal behavior of the braking system
In Fig.12, we describe the internal behavior of theRadar component by means of a state machine dia-gram. TheRadarBehavior state machine is stereotyped asTimedProcessing (not shown in the Figure). This per-mits to bind the processing of this behavior to time bymeans of a clock. Here the Radar remains in a singlereceivingData state and continues to send data to theprimary controller at each tick of theSystemClock, every100 ms. While Fig.13 illustrates the internal behavior ofthe primary controller. The controller contains three states,noAction, warning and criticalwarning. The controllerinitially remains in thenoAction state when distance fromincoming objects is greater than 3 meters. If the distancedecreases to less than 3 meters, the controller switches toeitherwarning or criticalwarning state (depending uponthe the related condition) and sends a braking commandto the Braking System. Fig.14 illustrates behavior of theBraking System. It switches to either thenormalBrakingor theemergencyBraking state, depending upon receiving aparticular command from the primary controller.
1
brake A c tuator Task
1c trlToImgC trlC ommunication
1
oDMC ontroll erC ommunication
1
camera Task
1imgC ontroll erC amC ommunication
1c trlToImgC trlC ommunication
1
alarm Task
1
sensor Task
1
light Sys tems Task
1
display Refresh Task
1
seat Belts Task
1
air Bag Task
1
controll erA larmC ommunication
1
controll erSensorC ommunication
1
controll erLightSysC ommunication
1
controll erDispC ommunication
1
controll erSeatbeltC ommunication
1
controll erA irbagC ommunication
1
controll erBrakeC ommunication
1
oDMC ontroll erC ommunication
1
radarO DMC ommunication
1
radarO DMC ommunication
sys tem Scheduler
0 ..1
Ct r l To I m g Ct r l Co mm un i ca t i o n
Co n t r o ll e r Di sp Co mm un i ca t i o n
Co n t r o ll e r Se a t b e l t Co mm un i ca t i o n
Co n t r o ll e r Li g h t Sy sCo mm un i ca t i o n
Co n t r o ll e r Se n so r Co mm un i ca t i o n
Co n t r o ll e r A l a r m Co mm un i ca t i o n
Co n t r o ll e r A i r b a g Co mm un i ca t i o n
Co n t r o ll e r Br a k e Co mm un i ca t i o n
I m g Co n t r o ll e r Ca m Co mm un i ca t i o n
Ra d a r ODMCo mm un i ca t i o n ODMCo n t r o ll e r Co mm un i ca t i o n
Sch e d u l e r T i m e r
<< Ti m e r Re so u rc e > >
Sy s t e m Sch e d u l e r
<< Sch e d u l e r > >
A l a r m Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Li g h t Sy s t e m s Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Se n so r Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Ca m e r a Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Di sp l a y Re f r e sh Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Se a t Be l t s Ta sk
<< Sch e d u l a b l e Re so u r ce > >
A i r Ba g Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Br a k e A c t u a t o r Ta sk
<< Sch e d u l a b l e Re so u r ce > >
ODM Ta sk
<< Sch e d u l a b l e Re so u r ce > >
I m g Co n t r o ll e r Ta sk
<< Sch e d u l a b l e Re so u r ce > >
Co n t r o ll e r Ta sk
<< Sch e d u l a b l e Re so u rc e > >
Ra d a r Ta sk
<< Sch e d u l a b l e Re so u r ce > >
send switch comm and()
send display refresh comm and()
send seat belt comm and()
send lightning system comm and()
send sensor swee p comm and()
send alarm notification comm and()
send air bag comm and()
send brake comm and()
send image comm and()
send raw data(in data : integer)send sensor distance(in distance : integer)
Perform Scheduling()
Sound Alarm()
Notify Alarm Comm and()
Indicator Signal()
Notify Light Sys Comm and()
Perform Weather temperature sensor swee p()
Notify Sensor Task()
Take Picture()
Re fresh Display()
Notify Display Comm and()
Tighten Seat Belts()
Notify Seat Belts Comm and()
Deploy Air Bag()
Notify Air Bag Comm and()
Normal Brakes()
Emergency Brakes()
Notify Brake()
Perform Calculation()
Notify Raw Data(in raw data : integer)
SwitchtoRadar()
Notify Image()
SwitchtoImage()
Sensor Operation()
Display Update()
Alarm Operation()
Lighting Control Operation()
Seat Belt Operation()
Air Bag Operation()
Brake Operation()
Notify Distance(in distance : integer)getData(in data : integer)
Figure.15: Software specification of the CCAS
1
alarmT
1
lightT
1
brakeT
1
sbeltT
1
abagT
1
dispT
1
sensorT
1
comm71
comm51
comm91
comm41
comm81
comm3
1comm6
1
camT
1
comm11
1
imgctrlT
1
comm10
1 ctrlT
1comm2
1comm1
1comm1
comm 11:ImgControllerCamComm unication
comm 10:CtrlToImgCtrlComm unication
comm 9:ControllerBrakeComm unication
comm 8:ControllerAirbagComm unication
comm 7:ControllerAlarmComm unication
comm 6:ControllerSensorComm unication
comm 5:ControllerLightSysComm unication
comm 4:ControllerSeatbeltComm unication
comm 3:ControllerDispComm unication
comm 2:ODMControllerComm unication
schTimer:Scheduler Timer
<<TimerRe source>>
scheduler:System Scheduler
<<Scheduler>>
alarmT:Alarm Task
<<SchedulableRe source>>
lightT:Light Systems Task
<<SchedulableRe source>>
sensorT:Sensor Task
<<SchedulableRe source>>
camT:Camera Task
<<SchedulableRe source>>
dispT:Display Re fresh Task
<<SchedulableRe source>>
sbeltT:Seat Belts Task
<<SchedulableRe source>>
abagT:Air Bag Task
<<SchedulableRe source>>
brakeT:Brake Actuator Task
<<SchedulableRe source>>
odmT:ODM Task
<<SchedulableRe source>>
imgctrlT:Img Controller Task
<<SchedulableRe source>>
ctrlT:Controller Task
<<SchedulableRe source>>
comm 1:RadarODMComm unication
radarT:Radar Task
<<SchedulableRe source>>
Figure.16: Software specification of the CCAS (Instance level)
5) Software Specification:We now turn towards modelingof the software specification of the execution platform ofthe CCAS, as displayed in Fig.15. Here, schedulable tasksrelated to the hardware modules are modeled along with theircommunications. A scheduler is also present that manages theoverall scheduling based on a fixed priority algorithm. Thedifferent tasks are stereotyped asSchedulableResource,indicating that they are scheduled by means of aSystemScheduler, itself appropriately stereotyped as aScheduler.Each task contains a number of operations, indicating thefunctionality related to that particular task.
The software specification is also modeled at the instancelevel as illustrated in Fig.16, for an eventual allocation betweenthe software/hardware specifications, and also for schedula-bility analysis modeling using UML sequence diagrams, asillustrated later on in section V-B12.
6) Allocating Software to Hardware:Once the hardwareand software specifications have been carried out, we carry outan allocation between the two using the MADESAllocationDiagram. Here in Fig.17, the majority of the tasks (suchas Brake Actuator Task, Air Bag Task) are allocated tothe primary controller by means of atemporal allocation.Similarly, the Radar and ODM tasks are allocated to theirrespective hardware modules by means ofspatial allocations.While tasks related to the secondary controller such asCamera
Task are mapped on to it by means of atemporalallocation.Finally, all the communications are allocated to theCAN bus.It should be noted that while theAllocatedstereotype on thesoftware and hardware concepts has been applied similarly tothe concepts illustrated in Fig.9, they have not been displayedhere for a better visualization.
<<Allocate>>
<<Allocate>> <<Allocate>>
<<Allocate>>
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (spatialAllocation)}
<<Allocate>> {nature (spatialAllocation)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>> {nature (timeScheduling)}
<<Allocate>>
<<Allocate>>
<<Allocate>> <<Allocate>>
<<Allocate>>
<<Allocate>>
<<Allocate>>
comm 11:ImgControllerCamComm unication
comm 10:CtrlToImgCtrlComm unication
comm 9:ControllerBrakeComm unication
comm 8:ControllerAirbagComm unication
comm 7:ControllerAlarmComm unication
comm 6:ControllerSensorComm unication
comm 5:ControllerLightSysComm unication
comm 4:ControllerSeatbeltComm unication
comm 3:ControllerDispComm unication
comm 2:ODMControllerComm unication
scheduler:System Scheduler
<<Scheduler>>
alarmT:Alarm Task
<<SchedulableRe source>>
lightT:Light Systems Task
<<SchedulableRe source>>
sensorT:Sensor Task
<<SchedulableRe source>>
camT:Camera Task
<<SchedulableRe source>>
dispT:Display Re fresh Task
<<SchedulableRe source>>
sbeltT:Seat Belts Task
<<SchedulableRe source>>
abagT:Air Bag Task
<<SchedulableRe source>>
brakeT:Brake Actuator Task
<<SchedulableRe source>>
odmT:ODM Task
<<SchedulableRe source>>
imgctrlT:Img Controller Task
<<SchedulableRe source>>
ctrlT:Controller Task
<<SchedulableRe source>>
comm 1:RadarODMComm unication
radarT:Radar Task
<<SchedulableRe source>>
air bag:Air bag
<<DeviceRe source>>
belts:Seat belts
<<DeviceRe source>>
display:HUD Display
<<DeviceRe source>>
cam:Camera
<<DeviceRe source>>
img mem:Image Processor Memory
<<StorageRe source>>
img proc:Image Processor Secondar Controller
<<ComputingRe source>>
ctrl mem:Controller Memory
<<StorageRe source>>
ctrl:Controller
<<ComputingRe source>>
can:CAN
<<Comm unicationMedia>>
shared mem:Shared Memory
<<StorageRe source>>
odm:Obstacle Detection Module
<<DeviceRe source>>
radar:Radar
<<DeviceRe source>>
alarm:Alarm
<<DeviceRe source>>
add sens:Add itional Sensors
<<DeviceRe source>>
ligh-sig sys:Lightning and Signaling System
<<DeviceRe source>>
braking sys:Braking System
<<DeviceRe source>>
Figure.17: Mapping software resources to the hardware mod-ules of CCAS
7) Detailed Hardware Specification:Once the initial ab-stract hardware specification has been modeled, the designercan move on to modeling of the detailed hardware specificationwhich corresponds more closely to the actual implementa-tion details of the execution platform. The structure of thedetailed hardware specifications corresponds to the abstractspecifications specified in Fig.11, but have been enriched withadditional details: such as operating frequencies of the primaryand secondary controllers, for example. All these aspects havebeen represented in Fig.18. Here, the modeled computingresources are stereotyped asHwProcessor, while memoriesare typed asHwRAM. The sensors, radar and display modulesas typed asHwI O, while remaining hardware concepts arestereotyped asHwDevice. Additionally the communicationmodule, theHW ChannelBox has been typed as aHwMedia.Finally, the execution platform also contains ahwclk clock oftype HardwareClock with a related clock constraint.
hwclk:HardwareClock
<<HwClock>>
hwairbag:HW_AirBag
<<HwDevice>>
hwbelts:HW_SeatBelts
<<HwDevice>>
hwdisplay:HW_Display
<<HwI_O>>
hwcam:HW_Camera
<<HwI_O>>
hwimgmem:HW_ImgMem
<<HwRAM>>
hwimgctrl:HW_ImgController
<<HwProcessor>>
hwctrlmem:HW_ControlMem
<<HwRAM>>
ppc:PowerPC {op_Frequencies (300MHz)}
<<HwProcessor>>
hwchannelbox:HW_ChannelBox
<<HwMedia>>
hwsharedmem:HW_SharedMem
<<HwRAM>>
hwodm:HW_ODM
<<HwDevice>>
hwradar:HW_Radar
<<HwI_O>>
hwalarm:HW_Alarm
<<HwTimingRe source>>
hwsens:HW_Sensors
<<HwI_O>>
hwlss :HW_LightSys
<<HwDevice>>
hwbss :HW_BrakeSys
<<HwDevice>>
{The
HardwareC lock
has the same
rate as the
Sys temC lock}
C onstraint
Figure.18: Detailed hardware specification of the executionplatform
8) Detailed Software Specification:In parallel, a designercan model the detailed software specification, which basicallycorrespond to expressing the concepts related to the underlyingoperating system of the CCAS. While it is possible to carryout detailed modeling of the operating system using MARTESRMconcepts, by adding relevant details such as semaphores,deadlocks, memory brokers etc; we chose to only illustratesome basic concepts related to a generic operating system.
Here as seen in Fig.19, the operating system has pro-cesses, each of which contains a number of threads. TheOperating System is stereotyped according toSRM con-cepts as aSwResource, while theProcess concept is typed asa SwSchedulableResource and aMemoryPartition. Thelatter stereotype indicates an address space which will beshared by the different threads associated with a process. Also,the Thread is itself typed asSwSchedulableResource.
1 ..*0..1
thread
*
0..1
process
Th r e a d
<< Sw Sch e d u l a b l e Re so u r ce > >
Pr o ce ss
<< Sw Sch e d u l a b l e Re so u r ce , Me m o r y Pa r t i t i o n > >
Op e r a t i n g Sy s t e m
<< Sw Re so u r ce > >
Figure.19: Detailed software specification of the executionplatform
9) Allocating Hardware to Detailed Hardware Specifica-tions: Once the detailed hardware specification has been mod-eled, we can carry out an allocation linking hardware to thedetailed hardware specifications. This allocation correspondsto a one to one mapping between the two specifications,and thus determines the refinement of the execution platform.Thus, it enables to move from abstract classifications to detailscorresponding closely to RTL implementation. For example aController (and its related instance) is mapped to aPowerPCprocessor (and its instance), as shown in Fig.20. It shouldbe mentioned that theAllocated stereotype applied on theallocated source/target concepts is not illustrated in thefigure.
10) Allocation Software to Detailed Software Specifica-tions: Similarly, the software specification is allocated onto
the detailed software specification (the operating system inthis case), in Fig.21. All the tasks and communications areallocated onto the operating system. While it is also possibleto model the detailed software modeling in a detailed manner(different threads corresponding to the different tasks atsoft-ware specifications) and then carry a one to one allocation,this aspect has not been carried out in the paper.
11) Allocating Detailed Software to Detailed HardwareSpecifications: Finally, once all the detailed specificationsrelated to the software and hardware aspects of the executionplatform have been modeled, it is possible to carry out a finalallocation from the detailed software to the detailed hardwarespecifications. Here, as seen in Fig.22, the operating systemis allocated onto the local memory of the primary controller,by means of a spatial allocation.
Figure.22: Allocating the detailed software and hardware spec-ifications
12) Schedulability Analysis Specifications:Once the soft-ware and hardware modeling have been carried out, using theMADES language, it is possible to carry out schedulabilityanalysis at the high level models. Here, in the followingfigures, we illustrate schedulability analysis aspects related tosome modules of the execution platform. However, it is equallypossible to analysis the whole system in question.
Figure.23: SequenceSendSensorDistanceToContrl forradar/controller communication
In Fig.23, the UML sequence diagram illustrates the com-munication flows between the different tasks of the executionplatform. TheradarT instance of theRadar Task sends datato theodmT instance of theODM Task by means of a commu-nication: comm1 instance ofRadarODMCommunication. Theinstance of theODM Task after carrying out a noise reductionalgorithm, sends the distance to the instancectrlT of theController Task by means of thecomm2 communicationinstance ofODMControllerCommunication. Using appropri-ate MARTE packages, it is possible to carry out schedulabilityanalysis: such as determination of average and worst caseexecution times for these flows. For example, theSaStep
stereotype helps to express worst and best case executiontimes, whileSaCommStep can additionally express the size ofthe message transmitted or received during the communicationflow. Here, the sequenceSendSensorDistanceToContrl isitself stereotyped as aGaScenario (not shown in the figure),indicating it is one of the possible scenarios related to thesystem.
Finally, an interaction overview diagram as shown in Fig.24,illustrates the overall behavior related to two possible sce-narios. The second scenarioSendBrakeCommand has notillustrated due to space limitations. While it is possible toinclude other possible scenarios related to the CCAS (suchas switching to camera based mode, applying normal brakes)and carry out a schedulability analysis of the whole CCASexecution platform, here only a partial analysis has beenshown for clarification purposes. Here the figure indicatesthat once the CCAS system starts, it enters into a loop. Itremains in the first scenario while keeps getting clock ticksat regular time intervals, as displayed by theClockEventtyped asGaWorkloadEvent. It keeps executing the first se-quence until abrakeInterrupt event occurs, causing thesystem to execute the sequence related to the second scenarioconcurrently. As the system does not stop its execution,no final node has been represented in the figure. Finallythe interactionCCAS InteractionOverview is stereotypedas aGaWorkloadBehavior (not shown in the figure). Thisstereotype is used to specify a set of related system-leveloperations, each associated with its respective behavior andexecuted on the basis of associated (workload) events.
VI. CONCLUSIONS
This article aims to present a complete methodology in-tegrated in the EU MADES project, for the design anddevelopment of real-time and embedded systems using aneffective subset of UML profiles: SysML and MARTE. Thepaper presents its contributions by proposing an effectivesubset of the two profiles, forming the basis of MADESlanguage and proposes unique set of diagrams to increasedesign productivity, decrease production cycles and promotesynergy between the different designers/teams working atdifferent domain aspects of the global system in consideration.Our MADES methodology could inspire future revisions ofthe SysML and MARTE profiles and may eventually aid intheir evolution. Finally, the different language conceptsandassociated diagrams in the methodology have been illustratedin a case study related to a car collision avoidance system.
VII. A CKNOWLEDGEMENTS
This research presented in this paper is funded by the Euro-pean Community’s Seventh Framework Program (FP7/2007-2013) under grant agreement no. 248864 (MADES).
REFERENCES
[1] OMG, “Portal of the Model Driven Engineering Community,” 2007,http://www.planetmde.org.
[2] S. Sendall and W. Kozaczynski, “Model Transformation: The Heart andSoul of Model-Driven Software Development,”IEEE Software, vol. 20,no. 5, pp. 42–45, 2003.
[3] A. Bagnato et al, “MADES: Embedded systems engineering approachin the avionics domain,” inFirst Workshop on Hands-on Platforms andtools for model-based engineering of Embedded Systems (HoPES), 2010.
cation,” mai 2006, http://www.omg.org/cgi-bin/doc?ptc/06-0504.[6] OMG, “Modeling and Analysis of Real-time and Embedded systems
(MARTE),” 2010, http://www.omg.org/spec/MARTE/1.0/PDF.[7] A. Koudri et al, “Using MARTE in the MOPCOM SoC/SoPC Co-
Methodology,” inMARTE Workshop at DATE’08, 2008.[8] EDIANA, “ARTEMIS project,” 2011, http://www.artemis-ediana.eu/.[9] TOPCASED, “The Open Source Toolkit for Critical Systems,” 2010,
http://www.topcased.org/.[10] W. Mueller et al., “The SATURN Approach to SysML-based HW/SW
Codesign,” in IEEE Computer Society Annual Symposium on VLSI(ISVLSI), 2010.
[11] M. Mura et al, “Model-based Design Space Exploration for RTESwith SysML and MARTE,” inForum on Specification, Verification andDesign Languages (FDL 2008), 2008, pp. 203–208.
[12] Information Society Technologies, “OMEGA: Correct Development ofReal-Time Embedded Systems ,” 2009, http://www-omega.imag.fr/.
[13] L. Ober et al., “Projet Omega : Un profil UML et un outil pourlamodelisation et la validation de systemes temps reel,” 2005, pp. 73:33–38.
[15] H. Espinoza et al, “Challenges in Combining SysML and MARTEfor Model-Based Design of Embedded Systems,” inECMDA-FA’09.Springer-Verlag, 2009, pp. 98–113.
[16] D.S. Kolovos et al, “Eclipse development tools for Epsilon,” in EclipseSummit Europe, Eclipse Modeling Symposium, 2006.
[17] N. Matragkas et al., “D4.1: Model Transformation and Code GenerationTools Specification,” Tech. Rep., 2010, http://www.mades-project.org/.
[18] L. Baresi et al., “D3.1: Domain-specific and User-centred Verification,”Tech. Rep., 2010, http://www.mades-project.org/.
[19] ——, “D3.3: Formal Dynamic Semantics of the Modelling Notation,”Tech. Rep., 2010, http://www.mades-project.org/.
[20] M. Pradella et al, “The Symmetry of the Past and of the Future: Bi-infinite Time in the Verification of Temporal Properties,” inESEC-FSE’07. New York, NY, USA: ACM, 2007, pp. 312–320.
[21] I. Gray and N. Audsley, “Exposing non-standard architectures to em-bedded software using compile-time virtualisation,” inInternationalconference on Compilers, architecture, and synthesis for embeddedsystems (CASES’09), 2009.
[22] Ian Gray et al., “Model-based hardware generation and programming- the MADES approach,” in14th International Symposium on Objectand Component-Oriented Real-Time Distributed Computing Workshops,2011.
![Logical time and temporal logics: Comparing UML MARTE… · gicLoal time and temporal logics: Comparing UML MARTE/CCSL and PSL 3 1 Introduction TheUMLPro leforModelingandAnalysisofReal-TimeandEmbeddedsystems(MARTE[8])](https://static.documents.pub/doc/80x56/5c01d5cb09d3f20a538d488b/logical-time-and-temporal-logics-comparing-uml-marte-gicloal-time-and-temporal.jpg)
![Programming Massively Parallel Architectures using MARTE ... · C. MARTE in Gaspard2 Context MARTE (Modeling and Analysis of Real-Time and Em-bedded systems) [1] is a standard proposal](https://static.documents.pub/doc/80x56/5f31441aa9459147ed7a2078/programming-massively-parallel-architectures-using-marte-c-marte-in-gaspard2.jpg)
