HMI & Display Safety
Treat the driver as a safety mechanism and the pixels as its wiring: controllability credit, warning timing inside the FTTI, tell-tale integrity, and honest digital displays.
- Chapters
- 12
- Chapters
- Controllability Classes
- 4
- Controllability Classes
- Display Classes
- 2
- Display Classes
- Tell-Tale Mini-Spec
- 1
- Tell-Tale Mini-Spec
Quick answers
- What is HMI and display safety in ISO 26262?
- HMI and display safety treats the human-machine interface as a safety surface. In many fault reactions the driver is part of the safety mechanism: a warning appears, the driver responds, and the hazard is controlled. That chain gives the warning path real safety requirements - the tell-tale must appear when needed, must not appear falsely, and must do so within the fault tolerant time interval. On modern vehicles those warnings are pixels rendered by software, so display integrity mechanisms, mixed-criticality architectures and human-factors design all become part of the ISO 26262 argument, with ISO 15008 covering legibility of in-vehicle displays.
- Can a warning really change the ASIL of a hazard?
- Indirectly, yes. Controllability is one of the three HARA parameters, and a well-designed warning can support a lower C class by giving the driver the information and time needed to control the situation - which can lower the resulting ASIL. But the credit has limits: the warning cannot fix an uncontrollable dynamic event, the reaction time must genuinely fit, and the claim needs validation evidence with real drivers. The course dedicates a chapter to what controllability claims can and cannot do.
Why it pays for itself
Controllability credit that holds
A warning can move the C parameter and change an ASIL - if the claim is engineered and validated. Learn what warnings can and cannot change in the HARA and the evidence a reviewer will demand.
Pixels treated as safety wiring
When the cluster renders the tell-tale, the rendering pipeline inherits the safety requirement. The mechanism toolbox - frame heartbeats, region CRC checks, freshness monitoring - keeps digital displays honest.
Architectures for the real cluster
Safety content shares silicon with infotainment. Overlay planes, safety islands, hypervisor partitioning, external monitors and dual-source fallbacks give you concrete patterns to route ASIL pixels around untrusted software.
What you’ll be able to do
Claim Controllability Credit Defensibly
Know what a warning can and cannot change about the C parameter in the HARA, and what validation evidence a controllability claim needs.
Specify the Warning and Degradation Concept
Write the Part 3 work product that defines warnings, degraded operation and driver-involving safe states, with fail-safe vs fail-degraded chosen deliberately.
Budget Warning Timing Inside the FTTI
Fit detection, presentation and a realistic human reaction into the fault tolerant time interval, and recognize when the driver cannot be the fallback.
Engineer Tell-Tale Integrity
Combine the UNECE R121 legal baseline with ASIL inheritance, cover both failure directions, and specify a tell-tale using the generic mini-spec pattern.
Protect the Rendering Pipeline
Deploy frame heartbeats, region CRC checking, E2E freshness and link monitoring, and prove coverage with a mechanism-to-failure-mode matrix.
Choose a Mixed-Criticality Display Architecture
Select among overlay planes, safety islands, hypervisor partitioning, external monitors and dual-source fallbacks to route safety content around untrusted software.
Chapter by chapter
- 01
The Last Line of Defense
Why the human-machine interface is a safety surface: the driver as part of the fault reaction, and the pixels as the wiring that makes that reaction work.
- HMI as safety surface
- Driver in the loop
- Pixels as wiring
- 02
Controllability & the C Parameter
How warnings influence the C classification in the HARA, what they can and cannot change, and what evidence a controllability claim needs to survive review.
- C0-C3 classes
- What warnings change
- Evidence for claims
- 03
The Warning & Degradation Concept
The Part 3 work product where driver warnings, degraded operation and driver-involving safe states are specified, including fail-safe vs fail-degraded thinking and takeover requests.
- Part 3 work product
- Fail-safe vs fail-degraded
- Takeover requests
- 04
Designing the Warning Itself
Channels, escalation, prioritization and the human-factors traps: how a warning is built so that it works on real drivers, with ISO 15008 legibility as the baseline.
- Channels & escalation
- Prioritization
- Human-factors traps
- 05
Warning Timing & the FTTI Budget
Fitting detection, warning presentation and a human reaction into the fault tolerant time interval, and deciding when the driver cannot be part of the fault reaction at all.
- FTTI budget
- Human reaction time
- When drivers cannot help
- 06
Tell-Tales: Regulation Meets ASIL
The most regulated pixel in the vehicle: the UNECE R121 legal baseline, the two failure directions, how a tell-tale inherits an ASIL, and a generic mini-spec.
- UNECE R121 baseline
- Two failure directions
- ASIL inheritance
- 07
From Bulbs to Pixels: The Digital Cluster
Anatomy of the modern rendering pipeline, its mixed-criticality reality where safety content shares silicon with infotainment, and the catalog of ways rendered content fails.
- Rendering pipeline
- Mixed criticality
- Failure catalog
- 08
Detecting Wrong Pixels: Rendering Integrity
The mechanism toolbox: frame heartbeats, region CRC checking against golden references, E2E freshness, link and backlight monitoring, and the coverage matrix tying mechanisms to failure modes.
- Frame heartbeats
- Region CRC checks
- Coverage matrix
- 09
Architectures for Mixed-Criticality Displays
Routing safety content around the untrusted middle: overlay planes, safety islands, hypervisor partitioning, external monitors, dual-source fallbacks and the minimal critical set.
- Overlay planes
- Safety islands
- Hypervisor partitioning
- 10
Head-Up Displays & Camera Monitors
The two display classes that change the relationship between driver and road: overlaying the world with a HUD and replacing the view of it with camera monitor systems.
- HUD failure modes
- Camera monitor systems
- Mirror replacement stakes
- 11
Verifying the Human Side & the Pixel Side
Controllability validation with real drivers, timing measurement against the FTTI, and fault injection into the rendering path: turning HMI safety claims into evidence.
- Driver validation
- Timing measurement
- Rendering fault injection
- 12
Pitfalls & Field Checklist
The recurring failure patterns of HMI and display safety programs, and a practitioner checklist spanning the concept, design and verification phases.
- Failure patterns
- Practitioner checklist
- Concept to verification
Not just text: the visual toolkit
Rendering Pipeline Anatomy
The stages of a modern cluster rendering pipeline and where each failure mode of the failure catalog strikes.
Mechanism Coverage Matrix
Rendering-integrity mechanisms - heartbeats, region CRC, freshness, link monitoring - mapped against the display failure modes they cover.
FTTI Warning Budget
Detection, warning presentation and human reaction stacked inside the fault tolerant time interval.
Who this guide is for
- Cluster and cockpit engineers whose display just inherited an ASIL
- Safety engineers writing the warning and degradation concept for a Part 3 item
- HARA practitioners deciding whether a warning justifies a lower C class
- Architects partitioning mixed-criticality display platforms, HUDs or camera monitor systems
Frequently Asked Questions
Common questions about HMI & Display Safety
Start the course today
A free account unlocks one full concept guide, 3 work product templates, 1 guided process, the Markov simulator, and 5 practice exams per month. The Pro and Expert plans unlock more of the 78-guide library. No credit card required.