CAR Collision Avoidance System (CCAS)¶
This second example models a complex car collision avoidance system. This system is installed in the car and contains a radar as well as camera, both of which provide input data to detect incoming collisions.
This example uses the MARTE Library and the concepts of the following MARTE profiles: GCM, GRM, SRM, HLAM, HRM, Time, Alloc, RSM, VSL, GQAM, SAM.
The Class, Sequence, State machine, Activity, and Deployment UML diagrams have been used in this example.
The vehicle collision avoidance system, or CCAS for short, allows to detect the position of the vehicle on which the system is installed on, to other objects such as cars and pedestrians. The CCAS contains two types of detection modules. One is radar based which sends a wave which when collides with an object is reflected and received by the radar itself. The radar sends this data to an obstacle detection module which carries out a detection algorithm to remove the noise from the incoming signal along with other tasks such as a correlation algorithm. The result of this data is sent to the controller.
Also a camera based module is present in the car, which also allows to determine the distance of the car from an object by means of image computation. The camera takes pictures of incoming objects and executes a distance algorithm, if it finds that the result of the computation means that the object is nearer to the car then the specified default value that means a collision can occur. The result of this data is also sent to the controller. The controller when receives the data, acts accordingly. In case of an imminent collision, it can carry out some emergency actions, such as stopping the engine, applying emergency brakes; otherwise if the collision is not imminent, it can decrease the speed of the car and can apply normal brakes.
We first illustrate the global structure of the Car Collision Platform Structure as illustrated in Car Collision Platform Structure figure. Using a deployment diagram, we represent the internal structure of the CCAS. We avoided the usage of MARTE HRM stereotypes here as the system is basically not traditionally hardware in the sense as it consists of electronic, electric and automotive components. Thus only GRM stereotypes are sufficient here.
In the figure, the following nodes are present:
DeviceResource, ComputingResource IMPCAR+Camera Module. It has two stereotypes as it contains a camera and a micro-controller,
Figure 14 Car Collision Platform Structure¶
All the nodes are interconnected via the CAN bus. As seen from the diagram, via the GRM stereotypes, it is possible to specify several attribute values such as speedfactor and capacity value for the CAN bus. Here, the capacity is set to 1024Mb/sec.
In the figure Radar structure and behavior, we first illustrate the internal block structure and behavior of the Radar module. While in the deployment diagram, the Radar module ports are not illustrated, this is due to the fact that in UML, different views can represent different details of the same component. Here in the figure, we first illustrate the external interface of the Radar which consists of an input InData port and an output OutData port. The input port is stereotypes as a ClientServer port of the type signal ReceiveSignal, while the OutData port is stereotyped as a FlowPort. All these concepts are present in the MARTE GCM package. The behavior of the Radar is illustrated via the Radar Behavior state machine which is appropriately stereotyped as TimeProcessing.
Basically, here the Radar remains in a single state receivingSamples and when it receives incoming signals via its input ClientServer port, it sends the data via its output port to the obstacle detection unit. When the radar does not receive a signal for about 1 min, it stops its execution and the system halts the obstacle detection procedure. This aspect can be shown via the transition to the final state having a TimedEvent stereotype with a value equal to 1 minute, expressed via VSL.
Figure 15 Radar structure and behavior¶
Finally, the RefreshData activity is expressed via an activity diagram. This activity is owned by the Radar component. In the activity, the UML CallOperationAction invokes the getSignal operation of the Radar, afterwards, the signal is transmitted via a UML SendObjectAction to the output port OutData.
Figure 16 Car Collision Application¶
We now look at the application part of the CCAS. It should be mentioned here that the CCAS contains several tasks. As seen from Car Collision Application, the Car Collision Application contains the following tasks with MARTE HLAM stereotypes:
RTUnit Controller Task: the main principle task. The isMain attribute is set to true to specify that this is the main. The behavior of the main is set to TaskBehavior (which is not specified in the example) that basically acts as a scheduler task. This behavior can be specified by an activity, interaction, sequence or state machine diagram. The task contains several sub tasks such as ComputeCameraTask, AirBagLaunch etc. Basically these operations showcase the different actions of the controller when it receives some input. For example, if the IMPCAR+Camera module sends it the information that a collision is about to happen, it computes some algorithm and takes necessary action, such as launching air bags, applying emergency brakes. It basically sends commands to the other tasks such as AirBag Task which carries out the necessary action.
RTUnit Image Processing Task: the task gets images from the camera, calculates image and sends the data to the controller.
RTUnit Radar Task: It acquires data and sends it to the obstacle detection task.
RTUnit Obstacle Detection: it gets data from the radar and removes noise from data and executes some correlation, Hough transform or any other detection algorithm. It then sends the data back to the controller.
Communication Task: it sends/receives data and commands from the other tasks.
RtUnit Brake: it gets commands and either applies normal or emergency brakes.
RtUnit Engine Commands: it gets commands and executes a number of operations. It can either decrease/increase speed, start/stop the engine and other operations.
RtUnit Air Bag Task: it launches the air bags when it receives an appropriate command.
RtUnit Display Update: It receives command and then communicates to the display task to update the screen in the car.
PpUnit Display: It writes data to the screen.
Figure 17 RTOS¶
The CCAS also contains an RTOS which is implemented using POSIX Threads, which is executed onto the Controller Task. This RTOS is modeled in the figure RTOS. While it is possible to really go into detail regarding the modeling, we have decided to adapt a simplified approach. This RTOS modeling is inspired from MARTE examples themselves, and is extended.
As per POSIX specifications (http://en.wikipedia.org/wiki/POSIX), a Process contains a number of Pthreads. Process and Pthreads can be halted or interrupted by Signals or Events. Each event has a Timer that specifies the duration of that event. The Process is stereotyped as MemoryPartition and SwSchedulableResource using the MARTE SRM package, as it is an address space that executes one or more threads. A Pthread contains a priority attribute of the type Priority Type. It is also stereotyped as a SwSchedulableResource. An Event is typed as a NotificationResource and has an eventValue attribute. Similarly the Timer is typed as a SwTimerResource and contains an attribute timingattribute of the DataType TimeType. Finally a scheduler is present with the appropriate Scheduler stereotype (from the GRM package) and contains a policy attribute of the type SchedPolicyKind (found in the MARTE library).
Figure 18 RTOS Instantiation¶
In the RTOS Instantiation figure, we illustrate a specific model of the RTOS by instantiation. Here we illustrate that one operation of the Controller Task is executed by a ComputeImageDecision Pthread, with appropriate event and timer values. The EntryPoint stereotype as present in the MARTE SRM package, supplies the operation executed in the context of a software resource.
Figure 19 Scenario examples¶
Subsequently, Scenario examples figure illustrates the different scenario possible using the GQAM and SAM MARTE packages. Here, as specified earlier in the document, the system contains two methods of collision detection: one by a camera and the other by a radar. Thus both of the scenarios are modeled here. The two partitions of the activity diagram are stereotyped as SaEndtoEndFlow and are appropriately named according to the two critical decision operations of the Controller Task, namely: ComputeObstacleTask and ComputeCameraTask. The events RadarEvent and CameraEvent are stereotyped as GaWorkloadEvent, while the RadarScenario and CameraDistanceCalculation are stereotyped as GaScenario(s).
Figure 20 Radar scenario¶
Each MARTE end to end flow consists of a GaWorkloadEvent that triggers a gaScenario, as illustrated in the previous figure. Here, in figure Radar scenario, we only look at the first scenario related to the Radar module.
The Radar Task receives some data, and sends it to the Obstacle detection Task via the Communication Task. Upon receiving the data, the Obstacle detection Task carries out some computation performsCalculation and transmits it to the Controller Task via the Communication Task. When Controller Task receives the data, it takes a decision depending upon its internal operations and the incoming data. If the collision is imminent then it takes either Decision1 or Decision2. This decision is then transmitted to the CAN via the Communication Task which conveys it to the appropriate modules. The Display Task when receives either decision, updates its display. The Engine Commands Task depending upon the decision either stops the engine or decreases speed along with some other parallel operations. Similarly, when the Brake Task gets the decision, it either applies emergency or normal brakes. Finally the AirBag Task either launches the air bag in case of a collision or does nothing at all.
Here, only some SAM stereotypes such as SaStep and SaCommStep have been showcased to give a general meaning. For example, the SaCommStep stereotype is applied on the communication between some of the tasks. This allows us to specify the message size of the communication for future analysis. Similarly, the SaStep is applied between some actions to determine the specific execution time.
Figure 21 Car Collision Platform System¶
Finally the Car Collision Platform System diagram illustrates the overall resource platform model for the application and the architecture for determining the analysis context. First, as shown in the Car Collision Platform System, the architecture modules and application tasks are instantiated. The execution platform resources such as Controller, CAN are given appropriate stereotypes such as SaExecHost and SaCommHost from the MARTE SAM package, respectively. Respectively, the application tasks such as Display and Communication Task are also stereotyped accordingly: SchedulableResource and GaCommChannel respectively. Here it should be mentioned that a schedulable resource needs a scheduler which is present in the form of the Controller Task.
The Controller Task basically acts as a scheduler for the other tasks, performs the global actions and is allocated onto the Controller. Similarly, the instantiations dy (Display) are allocated also to the Controller in the form of a temporalScheduling allocation. The other tasks are allocated to their respected hardware modules in a spatialDistribution fashion. The scheduler task can be considered as the principle task that permits to call the other tasks and permits their scheduled execution. While it is possible to have secondary sub scheduler tasks, this step has not been carried out in the modeling.
Finally, it is possible to carry out an analysis of this figure in combination with the figure Radar scenario. However this step has currently not been carried out, but is entirely possible if the need arises for its modelling.