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