The Hardware-Software Interface (HSI)
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.
- Chapters
- 10
- Chapters
- Diagrams & Visuals
- 8
- Diagrams & Visuals
- Worked Example
- 1
- Worked Example
- ISO 26262 Parts
- 4
- ISO 26262 Parts
Why it pays for itself
An HSI both sides can build from
A completeness checklist of twelve mandatory content areas - registers, diagnostics, timing, initialisation, safe state - so hardware and software teams implement from one contract without cross-team guesswork.
Diagnostics with no gaps or double-counts
Allocate every safety mechanism explicitly to hardware, software, or both, so SPFM and LFM calculations avoid the two classic failure modes: uncovered fault modes and the same detection credited twice.
FTTI budgets that close
Decompose the fault-tolerant time interval into hardware detection and software reaction windows, with worst-case interrupt latency and polling behaviour stated in the HSI and confirmed under integration load.
What you’ll be able to do
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.
Run a joint review
Lead a combined hardware and software review that catches cross-boundary assumption mismatches and traces each entry to a safety requirement.
Prevent boundary pitfalls
Recognise undocumented side effects, ambiguous ownership, and timing misalignment early enough to design them out.
Chapter by chapter
- 01
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.
- Interface-control document beyond pinout or register map
- Mismatched register semantics cause silent missed faults
- HW and SW obligations across resources, diagnostics, timing, safe state
- 02
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.
- Initiated at system design, refined at HW and SW levels
- Every entry is a two-sided handshake under change control
- SEooC turns the HSI into documented interface assumptions
- 03
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.
- Twelve mandatory content areas mapped to ISO clauses
- Depth of detail scales from ASIL A/B prose to ASIL D sign-off
- Audits repeatedly find the same completeness gaps
- 04
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.
- Every mechanism credited to SPFM or LFM stated explicitly
- Avoid both the gap and the double-count failure modes
- HSI names the other side role for every mechanism
- 05
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.
- Write-1-to-clear and read-to-clear are the most misread semantics
- HSI goes beyond the datasheet to safety-context usage rules
- Reset values, lock sequences, and read-back verification documented
- 06
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.
- Three signalling paths with distinct latency and certainty
- T_detect plus T_react must fit within the FTTI
- Clearing and acknowledgment rules prevent latched or lost faults
- 07
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.
- Interrupt latency accumulates across HW, NVIC, OS, and critical sections
- Poll faster than minimum conversion time and readings break
- Deterministic HW versus non-deterministic SW timing reconciled
- 08
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.
- Detect and report sensor faults to lane-keeping within 15 ms
- SPI framing, data scaling, and atomic frame reads specified
- Each entry traces to a numbered safety requirement
- 09
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.
- Each side verifies its half of the bilateral contract
- Separate HW reviewer and SW reviewer checklists
- Integration test cases derived directly from HSI entries
- 10
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.
- Undocumented register side effects clear safety flags silently
- Ambiguous error ownership leaves a fault mode at zero coverage
- Recognising the pattern is the first step to prevention
Not just text: the visual toolkit
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)
Unlock in course
Who this guide is for
- Embedded software engineers integrating a safety-relevant sensor or SoC
- Hardware engineers writing the interface commitments software will depend on
- System engineers who own the HSI document and its joint review
- Teams burned once by a write-1-to-clear register read as read-write
Frequently Asked Questions
Common questions about The Hardware-Software Interface (HSI)
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.