Increased Vehicle Complexities Boost Need for Functional Safety

Today's cars are safer than ever thanks to advanced technologies such as forward-collision warning systems, automatic emergency braking and intelligent speed adaptation. But behind a vehicle's modern safety features lies a complex machine, made up of an estimated 100 million lines of code, 30,000 parts, 100 electronic control units (ECU) and as many as 50 different computers.

"Many things in a car seem simple because the technology is familiar to most drivers, but underneath, it's a challenge of massive complexity," said Bill Taylor, managing director at kVA by UL. "With well-functioning onboard computers, sensors and networks, cars have transformed from a mechanical machine into an electronically controlled system, and the number of ECUs within a car continues to increase within the industry."

As a car's complexity evolves, however, so does the need for functional safety, a specialized engineering discipline focused on a product's ability to function safely, reliably and consistently every time.

According to Taylor, functional safety, which applies to electrical, electronic or programmable systems, has become a fundamental requirement for the automotive industry. Design engineers need to view the individual components and systems holistically so that all the applications work together.

Two functional safety standards: one objective

Functional safety experts rely heavily on safety standards such as ISO 26262, Road Vehicles, Functional Safety, and ISO 21448, Road Vehicles, Safety of the Intended Functionality. Each standard is filled with processes and specifies recommendations to establish functional safety throughout the product development cycle — system, hardware and software levels.

"Vehicle safety is a huge challenge for the industry. Many things can go wrong, and each potential failure needs to be taken into account during the product development cycle," Taylor said. "That's why these [functional safety] standards are so important. The standards define the processes to evaluate the risk, analyze the risk, write good requirements to mitigate the risk and to make sure engineers test for the requirements."

It's a process-oriented world

Functional safety experts, such as Taylor, map out each process to identify electrical and electronic malfunctions and the actions and techniques needed to mitigate risks and damages in case of software or hardware failures. The methods take a design team through discrete scenarios to help build out the system's functional safety.

For example, functional safety experts run through a list of "what-if" problems and formulate actions and responses to counter the situational faults.

"What if a network cable breaks or if a pin is bent and the connection is lost? What should the receiving computer do?" Taylor said. "We have to write requirements for thousands of hypothetical situations, and then test and verify each requirement."

What Taylor described above falls under what's called traditional functional safety. Traditional functional safety develops processes that avert potential faults such a bent pin, a broken wire or a burnt-out component. Software glitches would also fall under traditional functional safety.

But, what about the unknowns, the things that are difficult to map out. How does functional safety address these things?

Called the standard for the safety of the intended function (SOTIF), SOTIF complements traditional functional safety and is an important add-on for autonomous and semi-autonomous vehicles. SOTIF means that even if the software or hardware is bug, glitch and error-free, it still has to be safe enough.

"That's a weird thing to wrap your head around; of course, it has to be safe. But, it's a tricky area," Taylor said. "What if we want to make sure a car never crosses over a lane line? Except, sometimes, a car has to cross over the lane line if a person is in the way. And what if it's not really a person? What happens then?"

The need to anticipate a wide range of possible interactions between a vehicle and its environment is one of the biggest challenges in developing safety for autonomous and semi-autonomous vehicles. Engineers must anticipate what can go wrong when a car interacts with its environment and envision a safety-related system that detects a hazardous situation and reacts to that situation in a safe, predetermined way.

"One way we think of it is after you've tested for everything that you can anticipate, you may run the vehicle in the world for a while, just to make sure there's nothing out there that you didn't anticipate," Taylor said. "The question always is, how many miles would you run? One-thousand miles? One million? Where’s the cut-off?"

There's some complexity to figuring it out, but ultimately it will tell us how much real-world validation we need to do before we feel like we've done enough."