Title: The Hardware-Software Interface (HSI) | ISO 26262 Academy URL: https://iso26262.academy/features/concepts/hardware-software-interface Description: The HSI is the bilateral contract where ISO 26262 hardware and software meet. --- Concept guide · ISO 26262-4 §6 · 10 chapters # 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. 10 Chapters 11 Figures and interactive visuals 1 Worked example Included in [Expert](https://iso26262.academy/pricing#plan-advanced) [Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fhardware-software-interface&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) See the chapters Inside the course 1. 01 **What the HSI Is** 2. 02 **HSI in the V-Model** 3. 03 **Contents of an HSI Spec** 4. 04 **Allocating Diagnostics** 5. 05 **Registers & Memory Map** The short version ## 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. Keep going, free - [Demo exam · no account Test yourself with 7 exam-style questions](https://iso26262.academy/demo-exam) Why this course · ISO 26262, Part 4 ## 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. After the course ## 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. The curriculum · 10 chapters ## Chapter by chapter 1. 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 2. 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 3. 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 4. 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 5. 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 6. 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 7. 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 8. 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 9. 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. 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](https://iso26262.academy/pricing#plan-advanced) [Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fhardware-software-interface&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [Try the 7-question demo exam](https://iso26262.academy/demo-exam) Diagrams & visuals ## Not 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. Worked example ## 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 HSI items table SPI interface: hardware frame format and software peripheral configuration Unlock in course Built for ## 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) Every safety mechanism credited in the hardware metrics must be assigned explicitly: implemented in hardware, in software, or split across both, with the HSI naming the role of the other side. Two errors recur. In a gap, each side assumes the other covers a failure mode and nobody does. In a double count, the same detection is credited twice. An allocation matrix in the HSI exposes both before the FMEDA relies on the numbers. The fault-tolerant time interval is met jointly: hardware detection, signaling latency and software reaction must together fit inside it. The HSI is where that split is written down: which flags, interrupt lines or error pins signal the fault, their worst-case latencies, the software polling or interrupt budget, and the rules for clearing and acknowledging errors so faults are neither latched forever nor lost. Integration testing then confirms the stated values under load. The guide has 10 chapters: what the HSI is, its place in the V-model, contents of an HSI specification, allocating diagnostics, registers and memory map, error handling at the boundary, timing and resources, a worked example, HSI review and verification, and pitfalls and practice. It includes 11 figures and interactive visuals and a worked ASIL B inertial measurement unit example on SPI. A free account starts you off, and the Pro and Expert plans unlock more of the library. ## Stuck on this in your project? Send one question to a functional safety engineer. You get a written answer with the clause references. From **$290** with a written quote before any charge [See how we can help](https://iso26262.academy/features/consulting?service=question#sample) ## 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. [Preview free](https://iso26262.academy/register?plan=free&from=%2Fconcepts%2Fhardware-software-interface&utm_source=website&utm_medium=cta&utm_campaign=features_concepts) [View Pricing Plans](https://iso26262.academy/pricing) Continue with ## Where this topic leads next. [Browse all 93 guides](https://iso26262.academy/features/concepts#library) - System level [Freedom from Interference (FFI)](https://iso26262.academy/features/concepts/freedom-from-interference) 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. [Expert](https://iso26262.academy/pricing#plan-advanced) 10 chapters - System level [Safety Design Patterns](https://iso26262.academy/features/concepts/safety-design-patterns) Learn 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. [Pro](https://iso26262.academy/pricing#plan-basic) [Expert](https://iso26262.academy/pricing#plan-advanced) 16 chapters - Hardware [Hardware Engineering in ISO 26262](https://iso26262.academy/features/concepts/hardware-engineering-iso26262) Learn 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. [Expert](https://iso26262.academy/pricing#plan-advanced) 9 chapters