This model illustrates how to capture a speed regulation system for a self-driving car. The model includes several sensors and actuators controlled by different ECUs and inter-connected using a CAN bus. The model is available on our github model repository, you can get the full project on https://github.com/osate/examples/tree/master/speed-regulation .
This model has been used for the SEI webinar on AADL. You can watch the recording of the webinar on https://www.webcaster4.com/Webcast/Page/139/5357
Modeling and Analysis Objectives
The objective of this model is to study two different architectures from different perspectives:
- Performance: by analyzing system latency between the software components of each architecture
- Resources budgets: by analyzing the CPU consumption of each architecture
- Safety: by analyzing the system using safety analysis tools - Fault and Hazard Assessment, Fault-Tree Analysis, etc.
The system aims at controlling a vehicle speed and warns/notifies passengers of any emergency using a special device (visual sign, bell, etc.). To do so, the system uses the following inputs:
- current vehicle speed using two sensors (a wheel sensor and a laser sensor)
- detection of an obstacle using either a radar or a camera
- current position using two redundant GPS (from different manufacturers)
Then, it processes these inputs:
- Speed sensors are processed to estimate the current vehicle speed
- Both Obstacle detections mechanisms (camera, radar) are processed so that a dedicated function infers if there is an obstacle on the way
Finally, it controls the car and warns the driver for potential emergency event:
- Activation of the brake or acceleration using a speed controller
- Activation of the warning device
The model has the following input sensors:
- A camera to detect an obstacle on the road
- A radar that can also detect an obstable with distance information
- A speed wheel sensor
- A laser speed sensor
- Two redundant GPS
For actuators, the systems has a warning device to alert the passengers from an ongoing emergency and the accelerator/brakes to operate the vehicle. For following picture show the sensors, actuators as well as the software functions that use them.
Identification of functions
|Function Identifier||Function Name||Description|
|OC||Obstacle Camera||Camera in front of the car that detect potential obstacle on the road (bikes, stopped cars, etc.)|
|OR||Obstacle Radar||Device that detects obstacles on the road.|
|SWS||Speed Wheel Sensor||Sensor on car wheels to compute the actual speed.|
|SLS||Speed Laser Sensor||Device that spots the ground and compute actual speed.|
|GPS1||GPS1||GPS device that sends the current position of the car. The device should be different from GPS2 (different manufacturer, model, etc.)|
|GPS2||GPS2||GPS device that sends the current position of the car. The device should be different from GPS1 (different manufacturer, etc.)|
|OIA||Obstacle Image Acquisition||Decode the image from the camera|
|ODE||Obstacle Distance Evaluation||Evaluate the distance from the obstacle according to the last data received from the sensor|
|OD||Obstacle Detection||Detect if there is an actual obstacle according to the data received from the camera and the sensor during the last executions.|
|SE||Speed Estimate||Estimate the speed according to the wheel and laser sensors.|
|PV||Position Voter||Get the data from the two redundant GPS and output the actual position of the car. Vote is the position of both GPS is correct: if both are the same, output the value, if one GPS is out, get the data from the other. If both are out, do not ouput anything.|
|ST||Speed Threshold||Compute the actual speed threshold threshold according to the geographical position (altitude, hills), speed limits and actual speed.|
|TOE||Time to Obstacle Evaluation||Compute the actual time to an obstacle if there is any obstacle.|
|ED||Emergency Detection||Detect if there is an emergency. An emergency is defined by a potential obstacle the car might reach within 10 seconds.|
|SC||Speed Controller||Sends command to the brake or acceleration device according to the emergency report, the current position, the speed and the speed threshold.|
|WA||Warning Activation||Activate a warning device to notify passengers for an incoming potential threat.|
|WD||Warning Device||Device that announces an expected emergency event.|
|BD||Brake Device||Activate the car brakes|
|AD||Acceleration Device||Accelerates the car/increase the speed.|
Each function is executed periodically. The Period of each function is reported in the following table.
|Function Identifier||Function Name||Execution Time / MIPS Budget|
|OIA||Obstacle Image Acquisition||50ms|
|ODE||Obstacle Distance Evaluation||10ms|
|TOE||Time to Obstacle Evaluation||80ms|
We deploy this functional architecture on different execution platforms. The first one has only two ECUs that communicates through one bus while the other has three ECUs with two buses. We consider that a ECU has a capacity of 50 MIPS and that a can bus can transport at best 500 kbps. Interested users can refer to resources listed to compute an estimation of the CAN bus bandwidth according to their application needs.
Alternative 1: two ECUs, one fast bus
The first architecture alternative specifies a system deployment policy over 2 ECUs that communicate over a shared bus. Functions allocation policy is the following:
- ecu1 executes the following functions: image_acquisition, radar_acquisition, speed_estimate, position_voter and obstacle_detection
- ecu2 executes the following functions: speed_threshold_calculation, speed_controller, emergency_detection, warning_activation, obstacle_distance_evaluation
A CAN bus then transports all the data that is transfered between functions located on different ECU. We consider the following requirements for the CAN bus:
- Bandwidth capacity of 500000 bps
- Transmission time: 30 ms max to acquire the bus and 10 us max to send a byte
Alternative 2: three ECUs, two buses
The second complete architecture specifies a system deployment policy over 2 ECUs that communicate over a shared bus. Functions allocation policy is the following:
- ecu1 executes the following functions: image_acquisition, radar_acquisition, speed_estimate and obstacle_detection
- ecu2 executes the following functions: position_voter
- ecu3 executes the following functions: speed_threshold_calculation, speed_controller, emergency_detection, warning_activation, obstacle_distance_evaluation
Two RS232 buses connect the different ECUs together. The first ECU (ecu1) is connected to the third (ecu3)through a RS232 bus and the second (ecu2) is connected to the third (ecu3) through another RS232 bus.
A RS232bus then transports all the data that is transfered between functions located on different ECU. We consider the following requirements for the RS232 bus:
- Bandwidth capacity of 5 KBps
- Transmission time: 100 ms max to acquire the bus and 50 us max to send a byte
Each architecture is based on two models:
- A generic model that contains all the model components to realize the system (process, thread, device, etc.), their connections and flows. This generic component is illustrated in the picture below with the name integration.generic.
- An implementation model that extends the generic model, adds the deployment information/components (processor, bus) and specify the deployment policy (processor and connection binding). These two components (one for each deployment alternative is shown in the following picture under the name integration.implementation or integration.implementation2)
Using the Model
Create a System Instance
Once you imported the model from the [repository], you can create the system instance that represents the implementation of the architecture. There are two different architecture alternatives, so, you have to create two system instances (one for each architecture alternative). All the architecture alternatives are in the file integration.aadl. To instantiate the system, open the file integration.aadl and in the outline view (on the right), right click on the system instance and select the menu option Instantiate System.
Once you create a system instance, it appears in the instances directory in your filesystem. The following picture shows the directory after you created both system instances (one for each architecture alternative, implementation1 and implementation2).
Graphical view of the Model Instance
To view the instance model, right click on the file that contains the instance model (the previously generated aaxl file) and select the menu entry OSATE and Graphically view system instance or implementation. This will then open the Instance Model Viewer plugin with your system architecture. The following picture shows how to open the model instance with the Instance Model Viewer (IMV).
Edit the AADL model using the Graphical Editor
To edit the model using the graphical editor, edit the AADL textual model, right click in the text section and select the menu option Open Package Diagram as shown below.
Architecture Alternative 1
The first architecture alternative is defined in the system component integration.implementation1 in the integration.aadl file. It extends the generic system description by adding the processor, buses and the deployment policy for this first alternative.
Architecture Alternative 2
The first architecture alternative is defined in the system component integration.implementation2 in the integration.aadl file. As for the first architecture, it extends the first alternative and defines the execution platform. The main different in this model is the additional processor, the additional bus as well as the difference of bandwidth and speed.
Using Analysis Tools
Resource Allocation Analysis
To generate the resource allocation report for each architecture, select the instance model and select the following menu entry: Analyses, Architecture and Analyze Resource Allocation. This will then produce a new sub-directory into the reports directory called BoundResourceBudgets and will report the resource allocation for each processor or memory.
For the first architecture alternative, the CPU resource capacity is not sufficient for the budgets required by all functions. In fact, tasks bound to the first ECUs require at least 56 MIPS while the processor can provide only 50 MIPS. Several solutions might be considered, such as using a processor with a larger capacity, rework for function and reduce their execution time or use another processor and allocate some tasks to it.
This is the strategy used for the second architecture. This second architecture then use a third processor that executes some of the function initially allocated to the first ecu. In this second architecture alternative, there is no mismatch between the processor capacity and the software requirements: all tasks can be executed on time. The following screenshot shows the report of the resource allocation analysis.
First of all, we specify the latency requirements in the model. To do so, we add the Latency property into the flow specification to describe what is the expected latency on the flow. We add it on the end-to-end flow f0 that model the data flow between the camera and the warning device. We expect a latency between 800 ms and 900 ms. The following picture show the textual AADL notation for adding this requirement.
Then, for each architecture alternative, we generate the latency report. To do so, one has to select the following menu item: Analyses and then Check Flow Latency. The first architecture alternative meets the requirement constraint of the flow: the data flow latency is less than 900 ms (total latency of 896 ms).
On the other hand, the latency analysis of the second architecture alternative shows that this one does not meet the flow latency requirement. Indeed, using this architecture, the flow latency is 966 ms, 70 ms more than with the first architecture. This difference comes the bus latency: the first alternative use a high speed bus which is faster to transmit the data. The second alternative uses a slower bus which incurs more latency when communicating between function located on different processors.
Functional Hazard Assessment
The Functional Hazard Assessment of both architecture will list all the potential faults that can be triggered within the architecture. To generate the FHA, select the instance file and select the menu Analyses, Fault Analyses and "Functional Hazard Assessment". It will then create a sub-directory within the reports directory with a csv file.
This csv file will contain a list of all potential failures. Between the two architecture alternatives, the second one might have more potential errors. This is normal because this architecture contains more components (at least one additional processor and bus) than the first one. On the other hand, having more errors does not mean that the architecture is safer or not. To evaluate the potential reliability of the architecture, engineers must then consider the impact between faults, which is done by other analysis tools.
Fault Tree Analysis
Fault Impacts can be analyzed using two methods:
- From the Fault Analysis report generated from the model.
- In the Instance Model Viewer (IMV) plugin by selecting the component and color components impacted by a fault
To generate the fault impact report, select the instance model (generated aaxl file) and select the menu Analyses, Fault Analyses and "Fault Impact Analysis". The function will then create a new sub-directory (named "FaultImpact") under the "report" directory. It will contain the report under a CSV format. You can open it using any productivity tool.
To view the instance model, select the instance file and right-click on it. Then, select the OSATE menu option and click on "Graphically view instance or implementation". This will then show the model. To view the impact of a fault within a component, select the component and click on the red flag icon. This would then highlight all the impacted components.
The following picture show the fault impact when a fault occurs in the first processor (ecu1). All the components in red are the one that might be impacted by the error.
Comparing architecture alternatives
When comparing the two different architecture, users can analyze the impact on each component. Between both architecture, there is an important difference: the number of components affected by a processor fault. In the first architecture, a failure from the sensor component will affect mostly all the architecture, no matter components criticality. On the second alternative, if the components that controls the GPS fails, it might affect the behavior of the actuators but not as significantly as in the first architecture. In that case, it might just impact GPS-related function and maintain the vehicle in a degraded but functional mode.
Resources and Links
- CAN bus bandwidth estimation: http://www.canopen.us/faq/0143.htm and http://www.esacademy.com/en/library/calculators/can-best-and-worst-case-calculator.html