Functional Safety (ISO 26262): Designing Systems Where Failure is Not an Option

Srihari Maddula
1 day ago
3 min read

Author: Srihari Maddula

Reading Time: 25 mins

Topic: Safety-Critical Engineering & ISO 26262

In a safety-critical world, the cost of failure is measured in lives, not logs. Photo via Unsplash.

Imagine you are driving at 100 km/h and you step on the brake. In a modern vehicle, that pedal might not be connected to a hydraulic cylinder—it's connected to a sensor, an MCU, and a motor. Now imagine that MCU has a "Null Pointer Exception" or a "Bit Flip" caused by a cosmic ray. The code crashes. The motor stops. You have no brakes.

In a consumer gadget, a crash is an annoyance. In an autonomous vehicle, a medical ventilator, or an industrial robot, a crash is a catastrophe. Software is never "perfect," so we must design it to be "Safe" even when it fails. This is the world of Functional Safety (FuSa) and the ISO 26262 standard.

Senior Secret Safety engineering isn't about writing bug-free code—that's impossible. It's about building architectures that detect, isolate, and mitigate failures before they cause harm.

1. Technical Pillar 1: Understanding ASIL (The Risk Matrix)

In the ISO 26262 standard, every function is assigned an ASIL (Automotive Safety Integrity Level) from A to D. These levels dictate the rigour required in the development process.

Level	Risk Severity	Requirement
ASIL A	Low	Standard Coding Practices
ASIL B/C	Medium/High	Hardware Diagnostics (RAM/Flash checks)
ASIL D	Life-Critical	Safety-Lockstep CPUs & Redundancy

Production Rule For ASIL D systems, you cannot use a standard MCU. You must use a "Safety-Lockstep" processor where two cores run the exact same code and compare results every clock cycle.

2. Technical Pillar 2: Freedom from Interference (The MPU)

How do you ensure that a bug in your "Bluetooth Music" task doesn't overwrite the memory of your "Motor Control" task? In a professional FuSa design, we use the Memory Protection Unit (MPU) to create "Islands of Trust."

The Hardware Shield

The MPU defines specific regions of RAM and Flash that a task can access. If a non-critical task tries to touch safety-critical registers, the hardware triggers a Usage Fault and halts the rogue task instantly.

Architecture Logic This is why we use certified RTOSs like SafeRTOS or FreeRTOS-Plus-SIL. They are pre-certified to ensure that task switching and resource allocation never violate these safety boundaries.

3. Technical Pillar 3: Detecting the Invisible (Diagnostic Coverage)

Silicon isn't perfect. Heat, aging, and radiation can cause "Random Hardware Failures." Your firmware must spend a significant portion of its time checking the hardware's health through a Diagnostic Pipeline.

RAM Self-Test: Periodically writing and reading patterns to every byte of RAM to ensure no bits are "stuck."
Flash Checksums: Running background CRCs on your code to ensure no bit-flips have occurred in the instructions.
External Windowed Watchdogs: If the firmware kicks the watchdog too early or too late, the watchdog cuts the power. It assumes the CPU is "Insane."

Constant diagnostics are the foundation of hardware integrity. Photo via Unsplash.

4. Technical Pillar 4: The "Safe State" Mindset

In FuSa, the goal is not "Availability" (staying on); the goal is "Safety." You must design for the moment the system detects a failure.

Fail-Safe: If a fault is detected, the system shuts down (e.g., a microwave).
Fail-Operational: If a fault is detected, the system must keep running at a reduced level (e.g., an airplane or autonomous car on a highway).

Summary: The Safety Roadmap

Define Your ASIL: Know the consequences of failure before you write the first line of code.
Lock Down the Memory: Use the MPU from day one. Do not wait for a memory corruption bug to find you.
Implement Hardware Checks: RAM tests, Flash CRCs, and register read-backs are mandatory.
Go External: Use an external windowed watchdog to monitor your MCU's sanity.
Design the Safe State: Have a clear plan for what happens when a failure is detected.

Engineering at EurthTech

At EurthTech, we build systems for a world where failure is not an option. We understand that reliability is more than a metric—it is a responsibility to the users who trust our engineering with their lives.

Ready to scale your next production-grade embedded project? Let’s get deep.