The Hardware-Software Interface (HSI)
10 chapters Master the HSI as a bilateral safety contract: register access semantics, diagnostic allocation across the boundary, FTTI timing budgets, and joint reviews, taught across 10 chapters with 8 interactive visuals and a worked ADAS inertial measurement unit example.
How You Learn
Video and text stay in sync. As you scroll through the chapter, the video jumps to the matching explanation automatically.
Learning Objectives
Author a complete HSI
Produce a specification that covers all mandatory content areas so either side can implement without asking the other team a question.
Allocate diagnostics cleanly
Assign every safety mechanism to hardware, software, or both with no gap and no double-count in the SPFM and LFM calculations.
Budget the FTTI
Decompose the fault-tolerant time interval into hardware detection and software reaction windows and verify both fit under worst-case load.
Specify register semantics
Classify every safety-relevant bit field as RO, RW, W1C, RC, WO, or W1S and document reset values and verification steps.
Chapters
What the HSI Is
The HSI is the formal specification of every interaction point between hardware and software, a bilateral contract both disciplines must honour to integrate correctly and allocate safety requirements without ambiguity.
HSI in the V-Model
ISO 26262 addresses the HSI in three parts, system (Part 4, 6.4.7), hardware (Part 5, 6.4.10), and software (Part 6, 6.4.4), as an iterative document refined and re-reviewed by both sides.
Contents of an HSI Spec
A structured completeness checklist covering resources, operating modes, register and bit-field semantics, diagnostics, error reporting, timing, shared resources, initialisation, memory protection, and traceability to safety requirements.
Allocating Diagnostics
Deciding which safety mechanisms live in hardware versus software, assigning each explicitly so SPFM and LFM calculations avoid coverage gaps and double-counting of the same detection event.
Registers & Memory Map
Register maps, bit-field access taxonomy (RO, RW, W1C, RC, WO, W1S), lock registers, status and error registers, and memory protection, specifying how software shall use each field in the safety context.
Error Handling at the Boundary
How hardware signals faults through status flags, interrupt lines, and dedicated error pins, and how software must react inside the FTTI, which the HSI decomposes into hardware detection and software reaction windows.
Timing & Resources
Interrupt latency, polling intervals, CPU load, and shared peripherals tied to the fault-tolerant time interval, with worst-case values stated in the HSI and confirmed during integration under load.
Worked Example
An ASIL B MEMS inertial measurement unit (IMU) SoC talking SPI to a domain controller MCU, with every HSI item traced from the safety requirement through hardware commitment to software commitment.
HSI Review & Verification
The joint hardware and software review, the only work product both disciplines must examine together, plus consistency checks, integration testing against the HSI, and traceability back to safety requirements.
Pitfalls & Practice
Six recurring HSI failure patterns drawn from real powertrain, chassis, ADAS, and battery projects, with root cause, failure mode, and a concrete automotive example for each, plus the habits that prevent them.
Diagrams & Visuals
HSI Stack Diagram
Layered view of the hardware-software boundary showing where registers, interrupts, and error pins sit between the silicon and the software stack.
V-Model HSI Touchpoints
Where the HSI is created and refined across system, hardware, and software phases and verified during integration.
Diagnostic Allocation Matrix
Maps each safety mechanism to hardware, software, or a combination, exposing coverage gaps and double-counts before the FMEDA relies on them.
Register Map Schematic
Address layout with bit-field access semantics, reset values, and lock registers for safety-relevant peripherals.
Error Propagation Flow
Traces a fault from hardware detection through signalling and software reaction to the safe state.
Timing Budget Visualizer
Breaks the fault-tolerant time interval into hardware detection latency, interrupt service time, and software reaction windows.
ADAS Inertial Measurement Unit to Domain Controller
An ASIL B MEMS inertial measurement unit (IMU) SoC streams 3-axis acceleration and angular rate over SPI to a domain controller MCU running lane-keeping assist, with every HSI item traced from the safety requirement through hardware to software.
- Sample 6-axis motion at 200 Hz with defined accuracy bounds
- SPI configured CPOL=1, CPHA=1, 8 MHz, 16-bit frames, dedicated chip select
- Twelve-byte data frame read atomically, never as partial reads
- Sensor faults detected and reported to lane-keeping within 15 ms
- Each HSI entry traced to a numbered safety requirement (SR-LKA)
IMU to MCU HSI Item Trace
Ready to Master the Hardware-Software Interface?
Work through 10 chapters with 8 interactive visuals, a complete diagnostic allocation matrix, FTTI timing budgets, and a fully traced ADAS inertial measurement unit example.
Start Learning Now