Functional Safety

How we develop automotive software that can cope with hardware and software malfunctions.

Background

Modern cars contain 100+ ECUs, 300+ actuators, and up to 250+ different sensors. They are part of a complex and interconnected computer system in which even the smallest faults and malfunctions may affect the functionality and thus the safety of the entire car. The challenge is to develop software that guarantees the driver's safety even in the case of errors that will inevitably occur.

Responsibility

As in civil or mechanical engineering, functional safety is a fundamental part of a responsible and sustainable software development process for E/E systems.

Glossary

Process

1

Hazard analysis

Before we can design measures against software and hardware malfunctions, we look at the system and every subsystem in detail. Each component is assigned an Automotive Safety Integrity Level that describes the risk of a potential malfunction. ASIL levels range from A (lowest) to D (highest), depending on the severity, controllability, and probability of a malfunction. Hazards that are not dangerous to the system/driver are labelled “QM”. Those require different mechanisms that are not labelled safety.

2

Functional safety concept

Once we have an understanding of the potential malfunctions, we can outline system architectures and measures to prevent them from causing problems. A functional safety concept describes how a defect will be detected, how a malfunctioning system can be transitioned into a safe state, and when to alert the driver. Below is a simplified version of a functional safety concept for a front windshield wiper:

Normal condition

ECU

WIPER LEVER

WIPER SIGNAL

MAIN μC

ALIVE SIGNAL

WIPE

ERROR
ACTIVATION

SAFETY μC

The wiper lever sends signals indicating its current state

The main controller controls the wiper, sends alive signals to the safety microcontroller

WIPER

The safety controller does nothing

Fault condition

ECU

WIPER LEVER

WIPER SIGNAL

MAIN μC

ALIVE SIGNAL

WIPE

ERROR
ACTIVATION

SAFETY μC

The wiper lever sends signals indicating its current state

The main microcontroller is broken and does nothing

WIPER

The safety microcontroller detects this and keeps the wiper running

3

Technical safety concept

A functional safety concept is the high-level plan on a functional level, and the technical safety concept is the realisation of the functional concept on a system level. It describes in greater detail how a safety measure is to be designed, developed, and implemented. It functions like a granular description for software engineers to write code. A technical safety concept defines for example:

4

Development

With all requirements defined, our software engineers now start to write code. Software development is often an iterative process during which engineers and safety experts have to rethink software designs. Each iteration increases the risk for human error. To minimize the risk of error, functional requirements and changes need to be correctly traced, covered, and documented. To support this, we developed a requirement management tool that creates company wide transparency about the state of the software. It focuses on four key elements to improve functional safety compliant software development:

5

Testing

To make sure that all developed software will work correctly inside the vehicle, we test it on the type of ECU it will later be installed on. We purposefully cause malfunctions through “fault-injection tests”.

The ECU (1) is plugged into a test bench which also holds the Lauterbach Debugger (2) – the device we use to execute those tests. The automated system then installs the software on the ECU, initiates the tests, and runs them overnight. The software engineer is provided with test results the next morning so she does not have to context switch in her work. If those tests are performed without automation, this process would take days if not weeks. More information on testing at ESR Labs.

6

Operations and maintenance

Once development and testing is complete, software is rolled out to production. That means that the software is installed in vehicles. However, that doesn’t mean that vehicles are now 100% free of malfunctions. Even with good functional safety practices, there’s always a residual risk. To make sure that occurring faults are caught and analyzed, we develop and implement tracing modules which save device trouble codes (DTC) when the car is on the road. Trouble codes help us to find out where the problem comes from so we can fix it. Using over-the-air updates, we are then able to send new and improved software to the vehicle without the need to see a car mechanic.

Conclusion

As vehicle software becomes increasingly complex, we continue to innovate in two main areas: test automation and workflow optimization. Currently, we are looking for both experienced test engineers and safety engineers with a strong interest in documentation. Check out our vacancies.