A SysML/MARTE high level methodology for real-time - Embedded ...

More documents

Recommendations

Info

figure illustrates some basic scenarios, such as the car beingstarted, stopped or being driven. The Avoid 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, MADES High Level BlockSpecification or High Level Internal Block Specification diagramsare 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 finallytheCar 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. >A i r Co n d i t i o n e r Sy s t e m >El e c t r i c Su pp l y Sy s t e m >A u d i o / Vi d e o Mu l t i m e d i a De v i c e s >Ch a r g i n g Sy s t e m >Ga u g e s a n d Me t e r s >I g n i t i o n Sy s t e m >Sw i t c h e s >St a r t i n g Sy s t e m >Doo r s12 ..*110 ..10 ..10 ..10 ..10 ..11 ..*0 ..110 ..11 0 ..10 ..1 0 ..10 ..1 0 ..10 ..10 ..10 ..10 ..11111 >W i n d o w s >Ca r >10 ..1110 ..10 ..1 1En g i n e Coo li n g Sy s t e mW h ee l a n d Ti r e Pa r t s1111 > >En g i n e Co m p o n e n t Pa r t s >Ca r Co lli s i o n A v o i d a n c e Mo d u l e >W i r i n g Ha r n e ss e sSu s p e n s i o n a n d St ee r i n g Sy s t e m > >Tr a n s m i ss i o n Sy s t e m >Ex h a u s t Sy s t e m > >Fu e l Su pp l y Sy s t e mEn g i n e Oil Sy s t e mFigure.6: High level specification using SysML block conceptsGl o b a l Co lli s i o n A v o i d a n c e St r a t e g yDetect Colli sion by m eans of theinstalled radar detection or by theim age track ing sy stem . Switchingbetwee n radar and im age track ingdepending upon user requirem ents andweather conditions. Tak e app ropriateactions to av oid colli sions and notifythe driv erA v o i d Co lli s i o n sspecification 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 specificationof 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 CCASOnce the initial design descriptions have been specified, it ispossible 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 the High Level Specification Diagramcorrespond to an equivalent concept at the Refined HighLevel Specification Diagram. Since we are only interested intheCar 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 compositionsare present at the high level specifications forCarCollision 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 c e Mo d u l eI mm i n e n t Co lli s i o n St r a t e g yA dd i t i o n a l Ti m i n g r e q u i r e m e n t s Ne a r Co lli s i o n A v o i d a n c e St r a t e g yCh a n g i n g La n e s St r a t e g yFigure.8: Refined high level specification of the CCASWhen ex ternal obj ect is less than 2m eters away , the driv er should benotified by an alarm and HUD, andsy stem should switch to a criticalwarning state. I f the sy stem rem ains incritical warning state f or m ore than 300m s and distance f rom obj ect is still lessthan 2 m eters then the engine should bestopp ed, brak es should be app lied,seatbelts should be tensioned and airbag should be deploy ed. The brak esshould be app lied f or 100 m sThe radar or the im age track ingm odule should send the data to theController ev ery 100 m s v ia thesy stem bus and the comm un icationshould tak e 20 m s, during whichthe bus should be busy . I n case ofimm inent colli sion, the controllershould send the brak e comm andwhich should tak e no m ore than 20m sWhen ex ternal obj ect is less than 3m eters away , the controller shouldswi tch to a warning state. I f the sy stemrem ains in this state f or 300 m s, thenthe driv er should b e notified v ia analarm and HUD, norm al b rak es shouldbe app lied for 10 m s f or reducing carspee d. Hazard warning lights should beactiv ated in the HUD.When the driv er is about tochange lanes or if the cardev iates f rom the curr entlane intentionally , the driv ershould b e notified v ia theHUD. I f the driv er is chaninglanes him self, the car turnsignal should be on >Ca r Co lli s i o n A v o i d a n c e Mo d u l e {kind (hybrid), nature (spatialAllocation)} >Ca r Co lli s i o n A v o i d a n c e Mo d u l eFigure.7: Completing the functional specifications of theCCAS >RH_ Ca r Co lli s i o n A v o i d a n c e Mo d u l eFigure.9: Allocation between high level/refined high levelspecifications4) Completing the Requirement Specifications: Once wehave finished the use case scenarios and functional block2) Allocating High Level and Refined High Level Specifications:Afterwards, an allocation using the MADES Allocation
Diagram is used to map the high level specification conceptsto the refined high level specification concepts. This aspectis represented in Fig.9. Using the MARTE allocation mechanism,we express that the allocation is hybrid (both structuraland behavioral aspects are thus related from source to target)and spatial 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 theHardware andSystem clock types. All the clockstypes are discrete in nature using the MARTE Time package.hardware components. Here, the hardware specification alsocontains a clocksysclk of the typeSystemClock specifiedearlier in Fig.10. Here using the MARTE Time 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:receivingDataSystemClock CCAS Time Domain >I d e a l Cl o c k { n a t u r e ( d i s c r e t e ) , i s Lo g i c a l } >Ha r d w a r e Cl o c k { n a t u r e ( d i s c r e t e ) , r e s o l A tt r ( 10 ) }Figure.12: Behavior of the radar module present in the CCAS >Sy s t e m Cl o c k { n a t u r e ( d i s c r e t e ) , r e s o l A tt r ( 10 ) }Figure.10: Specification of clock types related to CCASWe first define time domain to contain the clock typesrelated to the system. For this, a packageCCAS Time Domainstereotyped asTimedDomain is created, respecting the timingnotions 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.notifyDistanceEnd [distance < 3 meters]warningnotifyDistanceEnd [distance > 3 meters]notifyDistanceEnd [distance < 3 meters && @warning.exit - @warning.enter < 300 ms]^breakInterrputnoActionnotifyDistanceEnd [distance < 2 meters && @criticalwarning.exit - @criticalwarning.enter < 300 ms]^breakInterrputnotifyDistanceEnd [distance >= 3 meters]criticalwarningnotifyDistanceEnd [distance > 2 meters]notifyDistanceEnd [distance < 2 meters]Figure.13: Behavior of the primary controller of the CCASnotifyNormalBrakeEndnormalBrakingidle [@normalBraking.exit - @normalBraking.enter = 10 ms]C ons traintnotifyEmergencyBrakeEnd{T heSys temC loc khas a rate 10times fas ter thanthe I dealC loc k}emergencyBraking[@emergencyBraking.exit - @emergencyBraking.enter = 100 ms]sys clk:System Clockshared m em :Shared Mem oryctrl:Controllerctrl m em :Controller Mem oryim g proc:Im age Process or Secondar ControllerFigure.14: Internal behavior of the braking systemodm :Obstacle Detection Moduleradar:Radaralarm :Alarmadd sens:Add itional Sensorsligh-sig sys:Lightning and Signaling Systembraking sys:Braking Systemcan:CANim g m em :Im age Process or Mem orycam :Cam eradisplay:HUD Displaybelts:Seat beltsair bag:Air bagFigure.11: Abstract hardware specification of CCAS4) 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 additionalhardware resources (radar and camera modules, brakingsystem, etc.); all of which communicate via a CAN bus. TheMARTE GRM package stereotypes are applied onto the differenthardware resources: for exampleComputingResourcefor the primary and secondary controllers,StorageResourcefor the local and shared memories,CommunicationMedia fortheCAN bus, whileDeviceResource is used for the otherIn Fig.12, we describe the internal behavior of theRadar component by means of a state machine diagram.TheRadarBehavior state machine is stereotyped asTimedProcessing (not shown in the Figure). This permitsto 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 andcriticalwarning. 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 orcriticalwarning 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.
Page 1 and 2: MADES: A SysML/MARTE high levelmeth
Page 8 and 9: 1Ct r l To I m g Ct r l Co mm un i
Page 10: stereotype helps to express worst a

A SysML/MARTE high level methodology for real-time - Embedded ...

Create successful ePaper yourself

Delete template?

Save as template?