ISO 26262 functional safety requirements for automotive HMI software vary significantly depending on what the HMI controls and displays. The instrument cluster display showing vehicle speed has a different safety integrity requirement than the audio system touchscreen. Understanding which HMI functions are safety-relevant, what ASIL level applies to them, and how the GUI software architecture must be structured to support that ASIL level is the foundation of automotive HMI safety compliance. This guide covers the HMI-specific aspects of ISO 26262 compliance — the parts that directly affect embedded GUI development decisions.
ASIL Level Assignment for HMI Functions
Most automotive HMI software is classified at QM (Quality Management — no specific ASIL requirement) or ASIL-A (lowest safety integrity level). Only specific HMI functions that directly contribute to vehicle safety hazards require higher ASIL levels:
- Warning display functions (ASIL-A or B): The function that displays safety-critical warnings (brake failure, airbag fault, ADAS system inhibit) is often ASIL-A or ASIL-B. The rationale: if the warning is not displayed when required, the driver may be unaware of a hazard. The ASIL level is determined by hazard analysis for the specific vehicle platform.
- Speedometer display (ASIL-A): In vehicles where the displayed speed is used by the driver for speed limit compliance, incorrect speed display could contribute to speeding incidents. Typical ASIL assignment: ASIL-A.
- ADAS HMI (ASIL-A to B): HMI for driver assistance systems (lane keeping, adaptive cruise, parking assist). Display functions that indicate system state and limitations may be ASIL-A or B depending on the system.
- Entertainment, navigation, settings (QM): Non-safety-relevant HMI functions. Incorrect behaviour does not create a vehicle safety hazard. No ASIL requirement — standard software quality practices apply.
The ASIL assignment is the output of the vehicle-level hazard analysis and risk assessment (HARA). HMI software engineers receive the ASIL requirements as inputs from the system safety team — they do not perform the HARA themselves.
Freedom from Interference
When a system contains software at different ASIL levels (e.g., ASIL-B warning display + QM entertainment in the same IVI system), ISO 26262 Part 6 requires freedom from interference: the QM software must not be able to corrupt, delay, or disable the ASIL-B software's function. This is one of the most practically challenging requirements in mixed-ASIL HMI systems.
Implementation approaches:
- Hardware separation: Safety-relevant HMI (instrument cluster, warning display) runs on a dedicated MCU or core, physically separate from the QM entertainment HMI. No shared memory, no shared execution context. Freedom from interference is guaranteed by hardware architecture. This is the cleanest approach but adds BOM cost.
- Software partitioning with MPU: ASIL and QM software run on the same MCU but in separate MPU-protected memory regions. The MPU configuration prevents the QM software from writing to the ASIL software's data or code regions. The ASIL software has highest RTOS priority and a dedicated execution budget enforced by the scheduler.
- Hypervisor separation: On MPU-class SoCs (NXP i.MX 8, Renesas R-Car), a hardware hypervisor isolates ASIL and QM software in separate virtual machines. The ASIL VM runs independently of the QM VM — a crash or security breach in the QM VM cannot affect the ASIL VM.
MISRA C in Automotive GUI Software
MISRA C is widely adopted as a coding guideline for safety-relevant automotive software developed in C. Its use can support the software development and verification activities associated with ISO 26262. For the HMI GUI framework specifically:
- The GUI framework source code must be MISRA C compliant if it is part of the ASIL software element — or deviations must be documented and justified in a deviation log
- MISRA C:2023 is the latest edition of the MISRA C guidelines, while MISRA C:2012 and its amendments continue to be widely used in established automotive projects and development toolchains.
- Compliance must be verified by static analysis (PolySpace, PC-lint, Keil MDK MISRA checker) — code review alone is insufficient for ISO 26262 compliance evidence
- For a GUI framework that is treated as a third-party component (SOUP — Software of Unknown Provenance, in IEC 62304 terminology, or a pre-existing software element in ISO 26262), the safety case must include evidence of the component's MISRA C compliance or an argument that its failure modes are contained
Sparklet's source code is MISRA C compliant — a key differentiator for automotive customers compared to open-source alternatives where MISRA C compliance is absent or limited.
Warning and Alert Display Design
Safety-relevant warning displays must meet specific design requirements beyond normal HMI design practices:
- Priority preemption: Safety warnings must preempt any currently displayed content — including ongoing animations, active user interactions, and lower-priority alerts. The warning must be immediately displayed within the specified reaction time (typically 10–100ms from signal detection to first pixel displayed).
- Unambiguous identification: Warning symbols and text must be unambiguous and comply with ISO 2575 (symbols for road vehicles) where applicable. Custom symbols must be validated through usability testing per ISO 26262 Part 6 (software) and IATF 16949 quality requirements.
- Persistence and acknowledgement: Some warnings must remain displayed until the fault condition is cleared, regardless of user navigation actions. The state machine governing warning display must be formally specified and verified.
- Colour compliance: ISO 2575 and UNECE Regulation 48 specify colours for instrument cluster warning lights: red for safety-critical (brake failure, airbag), amber for advisory (tyre pressure, engine management), green for active systems (turn signals). These are regulatory requirements, not design choices.
ISO 26262 Development Process Requirements for HMI Software
For ASIL-A and higher HMI software, ISO 26262 Part 6 imposes development process requirements:
- Software requirements specification (with traceability to system requirements)
- Software architectural design with documented safety mechanisms
- Software unit design and implementation
- Unit testing with ASIL-appropriate coverage (statement coverage for ASIL-A, branch coverage for ASIL-B)
- Integration testing
- Configuration management (version control, change tracking)
- Review and inspection records for key artifacts
The documentation burden is substantial. Tooling that generates compliant artifacts (unit test reports, coverage reports, static analysis reports) from the development process saves significant engineer time.
Sparklet in Automotive HMI Development
Sparklet's MISRA C compliance and software architecture can support the development of automotive HMI functions within ISO 26262 projects targeting ASIL-A and ASIL-B requirements. See the ISO 26262 embedded GUI details, explore automotive HMI demos, or request the evaluation package including the safety documentation package.