Functional safety ensures that embedded systems controlling physical processes (motors, valves, brakes, steering) fail in a safe manner when hardware or software faults occur, preventing injury or death. IEC 61508 is the foundational international standard for functional safety of electrical/electronic/programmable electronic systems, defining four Safety Integrity Levels (SIL 1-4) based on the tolerable failure rate of the safety function. ISO 26262 is the automotive-specific adaptation of IEC 61508, defining Automotive Safety Integrity Levels (ASIL A-D) based on severity, probability of exposure, and controllability of hazardous events. A SIL-3 rated system must achieve a probability of dangerous failure per hour (PFH) below 10^-7, while ASIL-D (the most stringent automotive level) requires single-point fault metrics above 99% and latent fault metrics above 90%. For embedded engineers, these standards mandate specific development processes (V-model), analysis methods (FMEA, FTA, HARA), coding standards (MISRA C), hardware architectures (redundancy, diagnostics), and verification activities (MC/DC coverage) that fundamentally shape how safety-critical firmware is designed, implemented, and tested.
How Do SIL and ASIL Levels Map to Real-World Requirements?
IEC 61508 SIL levels define target failure rates: SIL 1 requires PFH < 10^-5 (one dangerous failure per 100,000 hours), SIL 2 < 10^-6, SIL 3 < 10^-7, and SIL 4 < 10^-8. In practice, SIL 1 covers basic industrial monitoring (tank level alarms), SIL 2 covers most industrial control (emergency shutdown valves, burner management), SIL 3 covers high-risk processes (nuclear reactor protection, railway signaling), and SIL 4 is rare outside nuclear applications. ISO 26262 ASIL levels combine severity (S0-S3), exposure probability (E0-E4), and controllability (C0-C3) into a risk matrix: an airbag system (high severity, high exposure, low controllability) is typically ASIL D, while a seat heater controller might be ASIL A or QM (quality management, below ASIL). Decomposition allows splitting a safety requirement between redundant elements: an ASIL-D requirement can be implemented by two independent ASIL-B subsystems.
What Development Process Does Functional Safety Require?
Both standards mandate a structured V-model development lifecycle with specific work products at each phase. The left side of the V covers specification: hazard analysis and risk assessment (HARA), safety goals, functional safety concept, technical safety requirements, hardware and software requirements. The right side covers verification: unit testing, integration testing, hardware-software integration testing, and safety validation. For software, IEC 61508 and ISO 26262 Part 6 require specific methods at each SIL/ASIL level: semi-formal methods for SIL 2/ASIL B and above, defensive programming (assertions, range checks, plausibility checks), MISRA C compliance for C-language firmware, and Modified Condition/Decision Coverage (MC/DC) for unit testing at SIL 3/ASIL D. All work products must be reviewed, configuration managed, and traceable from hazard through requirement to test case.
What Hardware Architectures Support Safety Requirements?
Hardware safety architectures for different SIL/ASIL levels:
- Single-channel with diagnostics (1oo1D): One processing channel with self-test capabilities. Suitable for SIL 1/ASIL A. Diagnostics include CPU self-tests, RAM checks (march tests), ROM CRC verification, watchdog timers, and ADC cross-checks.
- Dual-channel with comparison (1oo2): Two independent processing channels comparing outputs. If they disagree, the system goes to safe state. Achieves SIL 2-3/ASIL B-C. Requires diverse hardware (different MCU families) for common-cause failure resistance.
- Dual-channel with diagnostics (1oo2D): Two channels with comprehensive self-diagnostics covering 90%+ of failure modes. The combination of redundancy and diagnostics achieves SIL 3/ASIL D. Examples: Infineon AURIX TC3xx with lockstep cores (two cores executing the same code with cycle-by-cycle comparison).
- Safety MCUs: Dedicated safety processors like Infineon AURIX TC3xx, TI TMS570, Renesas RH850, and NXP S32K3 include lockstep cores, ECC RAM, flash ECC, clock monitors, voltage monitors, and built-in self-test (BIST) hardware. These achieve ASIL-D single-chip solutions with HW diagnostic coverage above 99%.
/* Safety-critical firmware patterns for IEC 61508 / ISO 26262 */
/* 1. Defensive programming - range checking */
typedef enum { VALVE_CLOSED = 0, VALVE_OPEN = 1 } valve_state_t;
bool set_valve_position(valve_state_t state) {
/* Range check with explicit handling */
if (state != VALVE_CLOSED && state != VALVE_OPEN) {
safety_error_handler(ERR_INVALID_VALVE_STATE);
return false; /* MISRA: single point of exit preferred, */
} /* but safety takes priority */
/* Write with read-back verification */
GPIO_WritePin(VALVE_GPIO, (uint32_t)state);
uint32_t readback = GPIO_ReadPin(VALVE_GPIO);
if (readback != (uint32_t)state) {
safety_error_handler(ERR_VALVE_READBACK_FAIL);
return false;
}
return true;
}
/* 2. Program flow monitoring */
static volatile uint32_t flow_counter = 0;
#define FLOW_CHECKPOINT_INIT 0xA5A5A5A5u
#define FLOW_CHECKPOINT_SENSOR 0x12345678u
#define FLOW_EXPECTED_FINAL 0xB7D9FE1Du
void safety_control_loop(void) {
flow_counter = FLOW_CHECKPOINT_INIT;
read_sensors(); flow_counter ^= FLOW_CHECKPOINT_SENSOR;
run_control_algo(); flow_counter ^= FLOW_CHECKPOINT_ALGO;
set_actuators(); flow_counter ^= FLOW_CHECKPOINT_OUTPUT;
if (flow_counter != FLOW_EXPECTED_FINAL) {
/* Control flow corrupted - enter safe state */
emergency_shutdown();
}
}What Software Testing Is Required for Safety Certification?
Testing requirements escalate with SIL/ASIL level. Unit testing is required at all levels, with branch coverage (C1) recommended for SIL 1/ASIL A, and MC/DC coverage recommended for SIL 3-4/ASIL D. MC/DC (Modified Condition/Decision Coverage) requires demonstrating that each boolean sub-condition independently affects the decision outcome—a significantly stronger criterion than branch coverage. Integration testing must verify interfaces between software modules and between software and hardware. Back-to-back testing compares the behavior of the model (Simulink) against the generated/implemented code. Fault injection testing verifies that the safety mechanisms correctly detect and handle injected faults (memory corruption, sensor failures, communication errors). Static analysis tools (Polyspace, PC-lint, Coverity) are required for coding standard compliance (MISRA C:2012) and detecting runtime errors (division by zero, buffer overflow, null pointer dereference) without executing the code.
Key takeaway: IEC 61508 defines SIL 1-4 based on tolerable dangerous failure rates, while ISO 26262 defines ASIL A-D based on severity, exposure, and controllability. Both mandate V-model development with specific methods at each level: MISRA C compliance, MC/DC test coverage for SIL 3+/ASIL D, hardware architectures with diagnostic coverage above 99% (lockstep cores, ECC RAM), and formal hazard analysis (FMEA, FTA, HARA).
How Did We Achieve ISO 26262 ASIL-B Certification for an Automotive ECU?
At EmbedCrest, we led the functional safety engineering for an ASIL-B electric power steering (EPS) torque sensor interface ECU for an automotive Tier-1 supplier. The ECU processed dual-redundant torque sensor signals (analog voltage from two independent GMR sensors), computed the steering assist torque request, and transmitted it via CAN FD to the EPS motor controller. The hardware used an Infineon AURIX TC375 (dual lockstep Cortex-based TriCore CPUs with built-in safety mechanisms). Software development followed ISO 26262 Part 6 requirements: MISRA C:2012 compliance verified by PC-lint Plus and Polyspace (achieving zero critical, zero required, and 12 justified advisory violations), unit testing with MC/DC coverage measured by LDRA (achieving 98.2% MC/DC on safety-critical modules), and formal HARA (Hazard Analysis and Risk Assessment) identifying 14 safety goals. The safety concept implemented: torque sensor cross-checking (signals must agree within 3% or enter safe state), CAN FD message alive counter and CRC verification (SecOC), program flow monitoring using execution signature checks, and complete hardware diagnostic coverage through AURIX built-in self-tests (BIST) executed every 100 ms. TUV Rheinland assessed the safety case and issued ISO 26262 ASIL-B certification after 6 months of assessment including 3 rounds of documentation review and 2 on-site audits. Total certification effort was 14 person-months of safety engineering plus $180,000 in TUV assessment fees.
What Are the Most Common Functional Safety Mistakes?
The most expensive mistake is treating functional safety as a documentation exercise rather than an engineering discipline. Teams that generate safety documents after development, rather than driving development from safety requirements, invariably discover architectural safety gaps that require costly redesigns. Integrate safety analysis from the concept phase: perform HARA before system architecture, derive safety requirements before software design, and trace every safety requirement to its implementation and test case. Second, insufficient hardware diagnostic coverage is a frequent assessment finding. Achieving ASIL-D requires single-point fault metric above 99% and latent fault metric above 90%. Without lockstep cores, ECC RAM, and comprehensive peripheral self-tests, meeting these metrics requires expensive redundant hardware. Choose safety-certified MCUs (Infineon AURIX, TI TMS570, Renesas RH850) with built-in diagnostics rather than attempting to achieve equivalent coverage through software-only mechanisms on general-purpose MCUs. Third, underestimating the documentation effort is universal. ISO 26262 requires approximately 40 work products per software component, from safety requirements to verification reports. Budget 30-40% of total project effort for safety documentation and assessment activities.
How Do Safety Standards Apply to AI-Based Embedded Systems?
Machine learning models in safety-critical systems create fundamental challenges for traditional functional safety approaches. IEC 61508 and ISO 26262 assume deterministic, fully specified software behavior where every input-output mapping can be verified. ML models are probabilistic by nature, with no guarantee of correct classification for any specific input. The automotive industry is addressing this through ISO 21448 (SOTIF - Safety of the Intended Functionality), which deals with hazards from performance limitations of AI/ML systems. SOTIF requires: validation against a sufficiently comprehensive set of scenarios (including edge cases and adversarial inputs), online monitoring of ML model confidence with safe fallback when confidence drops below thresholds, and systematic identification of triggering conditions that cause ML model failures (e.g., unusual lighting, partially occluded objects, sensor degradation). For industrial applications, IEC TS 63521 provides guidance on using ML in safety-related systems. In practice, production safety-critical systems use ML for perception and advisory functions with a separate, conventionally certified safety monitor that can override ML decisions and bring the system to a safe state. This architectural pattern allows leveraging ML performance while maintaining certifiable safety guarantees.
