SpeedRegulation

From AadlWiki

Jump to: navigation, search

Contents

Introduction

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.


System Overview

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


Model Overview

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.

Functional Architecture of the Speed Regulation System
Functional Architecture of the Speed Regulation System

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.


Timing Constraints

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
OD Obstacle Detection 100ms
SE Speed Estimate 8ms
PV Position Voter 12ms
ST Speed Threshold 4ms
TOE Time to Obstacle Evaluation 80ms
ED Emergency Detection 4ms
SC Speed Controller 5ms
WA Warning Activation 2ms
BR Brake 2ms
AC Acceleration 2ms
WD Warning Device 500ms

Deployment Alternatives

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


First Architecture Alternative
First Architecture Alternative


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


Second Architecture Alternative
Second Architecture Alternative

AADL model

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)
Overview of the components hierarchy
Overview of the components hierarchy

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.

Instantiating a system instance
Instantiating a system instance

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).

System Instances of the Architecture Alternatives
System Instances of the Architecture Alternatives


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).

Open the Instance Model with the Model Instance Viewer
Open the Instance Model with the Model Instance Viewer

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.

Start the AADL graphical editor
Start the AADL graphical editor


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.

AADL instance model of the first architecture alternative
AADL instance model of the first architecture 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.

AADL instance model of the second architecture alternative
AADL instance model of the second architecture alternative

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.

Resource Analysis for the first architecture alternative
Resource Analysis for the first architecture alternative

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.


Resource Analysis for the second architecture alternative
Resource Analysis for the second architecture alternative

Latency 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.

Definition of the Flow Latency in the AADL specification
Definition of the Flow Latency in the AADL specification

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).


Latency Analysis of the flow f0 in the first architecture alternative
Latency Analysis of the flow f0 in the first architecture alternative

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.

Latency Analysis of the flow f0 in the second architecture alternative
Latency Analysis of the flow f0 in the second architecture alternative

Safety Analysis

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.

Functional Hazard Assessment of the second architecture alternative
Functional Hazard Assessment of the second architecture alternative

Fault Tree Analysis

Fault Impact

Fault Impacts can be analyzed using two methods:

  1. From the Fault Analysis report generated from the model.
  2. 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.

Impact of a fault occurring in ecu1 in the first architecture alternative
Impact of a fault occurring in ecu1 in the first architecture alternative


Impact of a fault occurring in ecu1 in the second architecture alternative
Impact of a fault occurring in ecu1 in the second architecture alternative


Impact of a fault occurring in ecu2 in the second architecture alternative
Impact of a fault occurring in ecu2 in the second architecture alternative

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

Personal tools