The Hardware-Software Interface (HSI)
Treat the HSI as a two-sided safety contract: register access semantics, diagnostic allocation across the boundary, fault signalling, timing budgets and the joint review, with a worked IMU to domain controller example.
- Chapters
- 10
- Chapters
- Figures and interactive visuals
- 11
- Figures and interactive visuals
- Worked example
- 1
- Worked example
Quick answers
- What is the hardware-software interface (HSI) in ISO 26262?
- The HSI is the specification of every interaction point between hardware and software in a safety-related system, a contract both disciplines must honor. It goes beyond a pinout or register map: it covers register access semantics, diagnostic allocation, error signaling, timing constraints, operating modes, initialization and safe-state behavior. ISO 26262 starts it at system design in ISO 26262-4, Clause 6.4 and refines it with the hardware safety requirements in Part 5 and the software safety requirements in Part 6.
- What must an HSI specification contain?
- A complete HSI describes the hardware resources software uses, operating modes, register and bit-field behavior, diagnostic capabilities and their allocation, error reporting paths, timing constraints, shared resources, initialization, memory protection and traceability to safety requirements. Register semantics deserve particular care, because an access type misread by software can hide a fault. The level of detail grows with the ASIL. The guide provides a completeness checklist and the gaps auditors find most often.
Why it pays for itself
An HSI both sides can build from
Use a completeness checklist of the mandatory HSI content areas, from registers and diagnostics to timing, initialization and safe state, so hardware and software teams implement from one contract.
Diagnostics with no gaps or double counts
Allocate every safety mechanism explicitly to hardware, software or both, so the hardware metrics avoid the two classic errors: uncovered failure modes and the same detection credited twice.
Timing budgets that close
Split the fault-tolerant time interval into hardware detection, signaling and software reaction, with worst-case latencies stated in the HSI and confirmed under integration load.
What you’ll be able to do
Write a complete HSI
Cover the content areas both teams need so either side can implement from the same contract.
Allocate diagnostics cleanly
Give every safety mechanism a clear owner so coverage is neither missing nor counted twice.
Specify register semantics
Document access behavior, reset values and lock sequences for safety-relevant registers.
Close the timing chain
Combine detection, signaling and reaction times into an argument that fits the FTTI.
Run a joint review
Catch cross-boundary assumption mismatches before integration testing does.
Chapter by chapter
- 01
What the HSI Is
Define the hardware-software interface as a contract and see why a fuzzy HSI is a leading cause of integration failures.
- Defining the HSI
- The HW/SW contract model
- Automotive examples
- 02
HSI in the V-Model
Follow the HSI from system design into hardware and software refinement, including iteration and the SEooC case.
- Three parts, three perspectives
- Placement in the V-model
- HSI for an SEooC
- 03
Contents of an HSI Spec
Learn what makes an HSI specification complete and how the depth of detail grows with the ASIL.
- Completeness checklist
- Detail scales with ASIL
- Common completeness gaps
- 04
Allocating Diagnostics
Assign safety mechanisms to hardware, software or both, and detect gaps and overlaps before the metrics rely on them.
- Typical mechanism allocation
- Windowed watchdog deep dive
- Fault reporting chain
- 05
Registers & Memory Map
Specify register access semantics, configuration locks and the memory map so software uses safety registers correctly.
- Register access taxonomy
- Configuration lock registers
- Memory map and MPU
- 06
Error Handling at the Boundary
Define how hardware signals faults to software, how errors are acknowledged, and how spurious signals are handled.
- Hardware fault signaling
- Reaction time budget
- Error response matrix
- 07
Timing & Resources
Treat interrupt latency, polling intervals, CPU load and shared peripherals as safety constraints in an FTTI argument.
- Interrupt latency budget
- Diagnostic test intervals
- Shared peripherals
- 08
Worked Example
Build the HSI items for an ADAS inertial measurement unit connected to a domain controller and trace one requirement across the boundary.
- IMU to domain controller
- HSI items table
- Integration test focus
- 09
HSI Review & Verification
Run a joint hardware and software review, check consistency with related documents, and verify the HSI by integration testing.
- Joint HW/SW review
- Consistency checks
- Traceability to requirements
- 10
Pitfalls & Practice
Recognize the recurring HSI pitfalls and the practices and team habits that prevent them.
- Six critical pitfalls
- Preventive best practices
- Organizational culture
Read all 10 chapters with Expert.
Start with a free account: the complete Functional Safety Concept guide and 5 practice exams a month, then upgrade when you need this guide.
Expert plan pricingNot just text: the visual toolkit
Write-1-to-clear timeline
How a misread register semantic can silently swallow a second fault.
Diagnostic allocation matrix
Fault classes sorted by hardware, joint and software ownership.
Windowed watchdog service window
Early, valid and late triggers and their consequences.
Timing budget visualizer
The fault-tolerant time interval split across detection and reaction.
Interactive HSI review checklist
Scores an HSI for completeness, testability and configurability.
ADAS inertial measurement unit to domain controller
An ASIL B inertial measurement unit streams motion data over SPI to a domain controller that serves lane keeping and a QM display, and the guide builds the HSI between them.
- The scenario, its safety requirement and the two sides of the boundary
- An HSI items table covering interface, data, diagnostics and timing
- How one safety requirement maps across hardware and software
- What integration testing has to verify against the HSI
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 and RBD simulators, and 5 practice exams per month. The Pro and Expert plans unlock more of the 93-guide library. No credit card required.
Continue with
Where this topic leads next.
- System levelFreedom from Interference (FFI)Learn how to ensure elements of different ASILs do not interfere through temporal, spatial, and data partitioning. Covers MPUs, hypervisors, bus monitoring, multi-core strategies, and evidence generation for assessments.
- System levelSafety Design PatternsLearn proven architectural patterns like redundancy, monitoring, watchdogs, and graceful degradation mapped to ASIL targets. Includes real-world automotive examples from powertrain, chassis, ADAS, and the E-Gas case study.
- HardwareHardware Engineering in ISO 26262Learn the complete hardware development lifecycle per ISO 26262-5 from requirements through design and verification. Covers HSI specification, SPFM/LFM/PMHF achievement, dependent failure analysis, and ASIC/FPGA/PCB considerations.