Use Case 1: ISO 26262 for Powertrain

Powertrain in Electric Vehicles

In this example, we’ll look at how functional safety applies to the powertrain system of an electric vehicle (EV), providing a practical view of how ISO 26262 can be implemented. In an EV, the High voltage battery pack supplies electrical power to the electric motor when the driver requests movement through the accelerator pedal. As the driver presses the pedal, sensors detect its position and send this information to a centralized computer, which calculates the desired motor torque. The motor then generates the corresponding torque to accelerate the vehicle (see Figure 1).

Unlike older vehicles with a combustion engine, that relied on a direct mechanical link between the accelerator and the throttle, modern cars use electronic systems. Since there’s no throttle in an EV, sensors and software is used to determine the driver intent and control the motion of the vehicle.

Figure 1: Powertrain in an Electric Vehicle

Where and how is Functional Safety applicable

Let’s consider a real-world example to understand how functional safety analysis is applied. Imagine driving on a busy city road in stop-and-go traffic. The driver gently presses the accelerator pedal to move forward, but due to an error in the accelerator pedal sensor, the system incorrectly detects that the pedal has been fully pressed. This results in unintended acceleration, causing the vehicle to surge forward unexpectedly and potentially collide with the vehicle ahead. Whether a collision occurs depends on several factors: the vehicle’s acceleration capability, the distance to the vehicle in front, and the driver’s reaction time. In other words, this situation represents a safety risk that must be evaluated. Safety engineers assess such risks by analyzing various driving scenarios like city driving, highway cruising, or parking maneuvers to understand the severity, exposure, and controllability of potential hazards. This structured evaluation process is known as the Hazard Analysis and Risk Assessment (HARA), which is defined in Part 3 of ISO 26262. Based on the identified risks, Safety Goals are created

Once safety goals are identified, we must design measures to mitigate them, starting with ensuring the accelerator pedal sensor reports correct values. In practice that means detecting when the pedal reading is wrong and using that determination to request motor torque. The same principle applies across the entire powertrain. We must verify that each sensor and component is producing correct, trustworthy data and performing the right calculations before allowing the vehicle to act. This activity of defining checks, diagnostics, redundancy, or fallbacks are required to prevent violations of safety goals is the essence of the functional safety concept under ISO 26262.

We know that we need to detect an error in the accelerator pedal sensor For this, we rely on redundancy and cross-checks. The most common solution is to use a second pedal position sensor for redundancy. In some designs, a pressure sensor may be added instead, depending on hardware capabilities. The centralized computer continuously compares the readings between the 2 sensors and flags discrepancies, allowing the system to decide whether to accept or ignore a driver request. These diagnostic checks, implemented in both hardware (redundant sensors, wiring checks) and software (comparisons, plausibility checks, fault-handling logic) form the technical safety concept i.e. how to technically implement solutions in hardware and software to prevent violation of safety goals.

If we choose a second pedal position sensor, we must specify how it interfaces with the centralized computer (GPIO, SPI, UART, etc.), design the input circuitry (pull-ups/pull-downs, low-pass filtering, protection), and set acceptable failure rates and diagnosability for each element. Determining whether failures in any of these components can be detected and handled is the essence of the hardware safety concept.

The requirement to compare the two sensor values is implemented in software - the software safety concept specifies how often the comparison runs, the plausibility checks and thresholds used, and the exact behavior when a mismatch occurs. It also defines how the software detects faults (timers, watchdogs, redundancy checks), what diagnostic flags are set, and the fault reaction strategy (e.g., ignore the faulty input, degrade performance, request a limp-home mode, or initiate a safe shutdown). Finally, the software safety concept prescribes how to log and report faults, how to escalate them to higher-level controllers in such a way that they meet the systems safety goals.

Once the safety concepts are developed, they must be tested to verify that the implementation matches the design and to validate that the design itself is correct for achieving the intended safety goals. Depending on the level of testing, this process may involve hardware testing, software testing, integration testing, or full vehicle validation. Each step ensures that safety mechanisms work as intended and that the overall system behaves safely under real-world conditions.

Conclusion

Applying functional safety to an electric vehicle’s powertrain involves systematically identifying risks, defining safety concepts, and implementing technical, hardware, and software measures to prevent hazards. Through rigorous testing and validation, engineers ensure that each safety mechanism functions as intended, ultimately delivering a system that operates safely and reliably under all driving conditions.