Software Architecture Analyses: Electric Power Steering EPS

September 12nd, 2021, Issue no.30, ISO 26262-6:2018, Development on Software Level

This series is dedicated to the absolute automotive functional safety beginners, system engineers or software engineers or anyone who wants to know about automotive functional safety ISO 26262 standard from ZERO. Disclaimer, this series and only expresses the author view to the ISO 26262 and not to the view of any company, institution or organization.

Electric Power Steering

In this article, we will explain how can we approach a safety analyses for the software architecture. Assume we have Electric Power Steering (EPS) system:

EPS has two angle sensors; the reason for multiple sensors is redundancy, accuracy and diagnostics. Multiple sensors are required since the steering angle is critical for the stability control system, and any discrepancy could mean the difference between making it around a corner or hitting another vehicle.

From this system architecture, the technical safety concept will be developed then software safety requirements will be created to make software architecture afterwards. We need to reach the SAD as early as possible since it is iterative process due to the conducted safety analyses that we will do. Now we have the following sub set of requirements:

TSR01_EPS: EPS shall receive vehicle speed from engine ECU in SPEED_RANGE and steering wheel angle in ANGLE_RANGE from steering angle sensor.

SSRS01_Steering: Safety monitor shall implement a range check for steering angle between 0 and 720 degree and if out of range go to safe state LIMP_HOME ---> ASIL-D

SSRS02_Steering: Safety monitor shall implement a range check for steering angle between 0 and 360 degree if vehicle_speed > 50kmh and if out of range go to safe state LIMP_HOME ---> ASIL-D

So from TSR01 we create the corresponding SSRS01 and from SSRS01 we create the software architecture to realize this requirements, this architecture might include multiple design requirement for this SSRS01. As the above figure, we create:

1. Static & dynamic architecture
2. requirements allocation: the sub-level components
3. safety mechanisms, if applicable
4. SW partitioning, if applicable

So from SW partitioning, we understand that we need to isolate the ASIL software component from non-safety related component. Then, we will create additional requirements from that on software architecture level.

By analyzing the software architecture by FTA or FMEA, we will be able to detect the weakness of the architecture and improve it. Also, we will figure out that there are safety SRS are missing, so we will add them. That being said, this iteration is mandatory to cover all missing safety SRS which might not be captured from converting TSRs of the system to SSRS.

void EPS_Control_System( struct* steering_sensor, uint32 vehicle_speed)
{
?
?status= Range_check(steering_sensor->angle); //if status =0x0A so it is in   range
?status_speed= Range_check(speed);? ? ? ? ? ? //if status_speed =0x0F so it is in range
?status |= (4 <<status_speed);
??
? if(status==0xFA)
? {
? ?Process_EPS_Ctrl( steering_sensor->angle, vehicle_speed);
? }
? else
? {
? ?LOG_DTC(0xEF0D);
? ?SET_ERR(ASIL_ERR);
? }


}        

Therefore, we have implemented safety SRS for the range check of both EPS steering angle (SSRS01) and vehicle speed range (SSRS02).

Dependent Failure Analyses

After we have added the Safety SRSs, now we have software architecture in which we believe it is robust. But we have to make another analyses to verify there is no interference between TSR01_EPS ( the monitored requirement) and the range check of speed and angle SSR01& SSR02 ( the monitoring requirement). That being said, the monitored function(TSR01) won't corrupt the monitor functions (SSR01&SSR02).

Although the dependent failure analyses is performed in another level; we will analyze our software architecture against:

Coexistence: if the software component is compose of safety related and non-safety related sub component elements

Decomposition: if software component is ASIL-D and we want to decompose it into two ASIL-B(D) into the downstream sub components

That being said, we want to analyze if FFI is achieved or not in terms of:

1. Spatial ( memory);
2. Temporal(timing);
3. Communication

In the next article we will talk about dependent failure analyses for software architecture: common cause & cascading failures

References

• ISO 26262-6:2018
• The functional Safety Mirror
• EPS
• Research Gate