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

Here as seen in Fig.19, the operating system has processes,each of which contains a number of threads. TheOperating System is stereotyped according to SRM conceptsas aSwResource, while theProcess concept is typed asaSwSchedulableResource and aMemoryPartition. Thelatter stereotype indicates an address space which will beshared by the different threads associated with a process. Also,theThread is itself typed asSwSchedulableResource. >Op e r a t i n g Sy s t e mproc es s0 ..1* >Pr o c e s s0 ..1thread1 ..* >Th r e a dFigure.19: Detailed software specification of the executionplatform9) Allocating Hardware to Detailed Hardware Specifications:Once the detailed hardware specification has been modeled,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 the Allocated stereotype applied on theallocated source/target concepts is not illustrated in the figure.sys clk:System Clockctrl:Controllerctrl m em :Controller Mem oryim g proc:Im age Process or Secondar Controllerim g m em :Im age Process or Mem oryshared m em :Shared Mem orycan:CANodm :Obstacle Detection Modulehwclk:HardwareClockppc:PowerPChwctrlm em :HW_ControlMemhwim gctrl:HW_Im gControllerhwim gm em :HW_Im gMemhwsharedm em :HW_SharedMemhwchann elbox:HW_Chann elBoxhwodm :HW_ODMbraking sys:Braking Systemair bag:Air bagcam :Cam eraradar:Radaralarm :Alarmbelts:Seat beltsligh-sig sys:Lightning and Signaling Systemdisplay:HUD Displayhwbss :HW_BrakeSyshwairbag:HW_AirBaghwcam :HW_Cam erahwradar:HW_Radarhwalarm :HW_Alarmhwbelts:HW_SeatBeltshwlss :HW_LightSyshwdisplay:HW_Displaythe 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 at softwarespecifications) 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. >Op e r a t i n g Sy s t e m {nature (spatialAllocation), kind (hybrid)}hwctrlm em :HW_ControlMemFigure.22: Allocating the detailed software and hardware specifications12) Schedulability Analysis Specifications: Once the softwareand 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.radarT:Radar Taskcomm 1:RadarODMComm un ication send raw data( d ) {execTim e (10 m s,m ax) , (8m s,m in )}odm T:ODM Task Notify Raw Data( d ) {execTim e (10 m s,m ax) , (8m s,m in )}comm 2:ODMControllerComm un icationctrlT:Controller Taskadd sens:Add itional Sensorshwsens:HW_SensorsFigure.20: Allocating hardware/detailed hardware specifications Perform Calculation( ) {execTim e (3m s,m ax) , (2m s,m in )} send sensor distance( d ) {execTim e (10ms,m ax) , (8m s,m in )} Notify Distance( d ) {execTim e (10 m s,m ax) , (8m s,m in )} >A i r Ba g Ta s k > Co n t r o ll e r Ta s k > Ra d a r Ta s k >Sy s t e m Sc h e d u l e r >Se n s o r Ta s k > I m g Co n t r o ll e r Ta s k >Se a t Be l t s Ta s k > Li g h t Sy s t e m s Ta s kFigure.23: Sequence SendSensorDistanceToContrl forradar/controller communicationRa d a r ODMCo mm un i c a t i o nCo n t r o ll e r Li g h t Sy s Co mm un i c a t i o nCo n t r o ll e r Br a k e Co mm un i c a t i o nODMCo n t r o ll e r Co mm un i c a t i o nCt r l To I m g Ct r l Co mm un i c a t i o nCo n t r o ll e r Se n s o r Co mm un i c a t i o nCo n t r o ll e r Di s p Co mm un i c a t i o nCo n t r o ll e r A l a r m Co mm un i c a t i o nI m g Co n t r o ll e r Ca m Co mm un i c a t i o nCo n t r o ll e r Se a t b e l t Co mm un i c a t i o nCo n t r o ll e r A i r b a g Co mm un i c a t i o n >Op e r a t i n g Sy s t e m >ODM Ta s k >Di s p l a y Re f r e s h Ta s k >A l a r m Ta s k >Br a k e A c t u a t o r Ta s k >Ca m e r a Ta s kFigure.21: Allocating software/detailed software specifications10) Allocation Software to Detailed Software Specifications:Similarly, the software specification is allocated ontoIn Fig.23, the UML sequence diagram illustrates the communicationflows between the different tasks of the executionplatform. TheradarT instance of theRadar Task sends datato theodmT instance of theODM Task by means of a communication:comm1instance 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 appropriateMARTE packages, it is possible to carry out schedulabilityanalysis: such as determination of average and worst caseexecution times for these flows. For example, the SaStep