Hardware/Software Interface (HSI) in Safety-Critical Systems

The boundary between hardware and software is where systems break in ways that neither the hardware team nor the software team owns. A register bit that behaves differently under load than in simulation. An interrupt that fires 200 nanoseconds earlier than the software assumes. A DMA controller whose behavior during reset the firmware never accounted for because nobody wrote it down.

These are not exotic failure modes. They are the routine consequence of treating hardware and software as two separate design problems that get integrated at the end. In safety-critical applications—avionics, automotive ADAS, medical devices, industrial control—this approach fails certification and, more importantly, it fails in operation.

Hardware/Software Interface (HSI) engineering is the discipline of managing this boundary deliberately. It defines what hardware exposes to software, what software can and cannot assume about hardware, and how both sides verify that the contract holds. In DO-254 and DO-178C regulated programs, HSI is not optional practice. It is explicitly required.

What HSI Actually Means

HSI is the complete specification of every point at which software executes based on hardware state, or hardware behavior depends on software action. This includes:

• Memory maps and register interfaces: Which addresses correspond to which hardware registers, what each bit means, which registers are read-only versus write-clear versus read-modify-write, and what happens if software reads or writes out of sequence.
• Timing relationships: How long after a hardware event software has to respond. How long after a software write the hardware state is guaranteed stable. Setup and hold constraints expressed as software behavioral requirements, not just hardware timing diagrams.
• Interrupt and exception handling: Which hardware conditions generate which interrupts, what the hardware state is at the moment of interrupt entry, what software must do before the hardware event clears, and what happens if the interrupt is masked at the wrong moment.
• Power and reset sequencing: What hardware state exists at power-on, what software can assume at reset exit, and which hardware peripherals are in undefined state until explicitly initialized by software.
• Error and fault propagation: How hardware signals fault conditions to software, what software must do within what time window to prevent escalation, and how hardware behaves if software does not respond.

Each of these is a contract. The failure mode is not that the contract is violated—it is that the contract was never written down, so neither side knows what it agreed to.

DO-254 and DO-178C: Why HSI Has Regulatory Weight

DO-254 (Design Assurance Guidance for Airborne Electronic Hardware) and DO-178C (Software Considerations in Airborne Systems and Equipment Certification) are the primary certification standards for avionics. Both reference HSI, and understanding how they interact explains why HSI management is an engineering discipline, not a documentation task.

DO-254 requires that hardware design assurance includes consideration of the hardware/software interface. For complex programmable hardware—FPGAs, ASICs, programmable analog components—the standard requires that the interface between that hardware and the software controlling or relying on it be analyzed, documented, and verified. The hardware design data package must include or reference the HSI specification.

DO-178C is more specific. It requires that software requirements be complete and verifiable. For any software requirement that involves hardware behavior—reading a sensor register, responding to an interrupt, configuring a DMA channel—the software requirement is only complete if the underlying hardware behavior is specified. A software requirement that says “the system shall read the engine speed sensor within 5 milliseconds of the sensor update” is not verifiable unless the hardware team has specified when and how the sensor update is signaled to software.

The practical consequence: if your HSI is not documented as a distinct artifact, your DO-178C software requirements are incomplete by definition, and your DO-254 hardware data package has a gap. Auditors at DER level have become more precise about this over the past decade. “The hardware team knows what the software needs” is no longer an acceptable answer.

Automotive (ISO 26262), medical devices (IEC 62304 paired with hardware standards), and industrial safety (IEC 61508) have analogous requirements. The specific standard varies; the principle does not.

Where HSI Failures Actually Occur

Understanding the failure taxonomy matters because it shapes how you structure HSI analysis. These are the three categories that appear most consistently in incident investigations and certification findings.

Register Map Drift

The hardware team publishes a register map document. The software team implements drivers against it. The hardware team updates a register address or bit definition in revision 3 of the FPGA design. The document gets updated. The software team’s driver does not, because nobody owns the link between the document revision and the software implementation.

This is not a hypothetical scenario. Register map drift is endemic in programs that manage hardware and software in separate document repositories with manual cross-references. The failure is invisible until integration testing—or until field deployment, if integration testing was done against a simulation that used the old map.

Timing Assumption Gaps

Hardware datasheets express timing in hardware terms: nanoseconds, clock edges, setup and hold times. Software requirements are written in software terms: function calls, interrupt service routines, polling loops. The translation between these two domains is where assumptions accumulate.

A common failure pattern: the hardware designer knows that a certain register read must not occur within 10 clock cycles of a write to a related register. This is documented in the hardware design notes but not in the interface specification. The software team’s driver performs the write and immediately reads. In bench testing, the processor’s instruction pipeline introduces enough latency that the timing is accidentally satisfied. In production silicon, or at a different clock frequency, it is not.

The requirement that was missing: a software behavioral requirement that says “software shall not read register X within N microseconds of writing register Y.” This is an HSI requirement. It belongs to neither the hardware requirements nor the pure software requirements. Without a layer specifically for HSI, it falls through.

Interrupt Handling Gaps

Interrupts are the canonical HSI failure surface. Hardware generates an interrupt based on a condition. Software must respond within a constraint, take specific actions in a specific order, and clear the condition in the way the hardware expects. Every one of those elements is a contract.

Failures occur when: the interrupt latency constraint is specified in the hardware design but not allocated to the software real-time requirements; the required response sequence is documented in a hardware application note that the software team never received; or the condition-clear protocol (edge-triggered versus level-triggered, hardware-clear versus software-clear) is assumed differently by the two teams.

Interrupt handling gaps are particularly dangerous in safety-critical systems because they can create latch-up conditions—hardware stays in a fault state because software never sent the right clear sequence—that look like hardware failures in post-incident analysis.

How HSI Requirements Are Allocated, Traced, and Verified

HSI requirements are architecturally different from pure hardware or pure software requirements, and they must be managed differently.

Allocation for an HSI requirement is bidirectional. A single HSI requirement—for example, “the flight control computer shall respond to the position sensor interrupt within 500 microseconds of assertion”—allocates downward to a hardware requirement (the interrupt must be asserted with sufficient setup time relative to the processor’s interrupt controller), a software requirement (the interrupt service routine must complete within 500 microseconds), and potentially a system-level timing budget requirement. Neither the hardware team nor the software team owns this requirement exclusively. Both implement against it, and both verify against it.

Traceability for HSI requirements must link upward to the system requirement that drove them, sideways to the hardware design elements that implement the hardware side of the interface, and sideways to the software requirements that implement the software side. In a document-based system, this is modeled with a bidirectional traceability matrix. The problem with the matrix approach is that it is maintained manually, it goes stale at the same rate as the documents it connects, and it cannot be queried efficiently when a hardware change propagates. Knowing that a register map change affects seventeen software requirements, two test procedures, and one certification finding requires either an automated tool or an engineer spending a week tracing.

Verification for HSI requirements requires integration testing—testing that exercises the actual hardware and actual software together, in timing-accurate conditions. HSI requirements cannot be fully verified by hardware simulation alone (the software side is absent) or by software unit testing alone (the hardware behavior is mocked). This seems obvious stated plainly, but programs under schedule pressure routinely close HSI requirements against hardware simulation and software unit test evidence, deferring integration. The result is a pile of open findings at system integration test.

How Modern Tools Manage HSI as a Linked Layer

The structural problem with HSI management is that most requirements tools are built around a linear hierarchy: system requirements decompose to hardware requirements or software requirements. HSI requirements do not fit this model. They exist at the interface, with bidirectional relationships to both sides.

Document-based tools like IBM DOORS or Jama Connect can model HSI through link structures and module hierarchies, and experienced teams do build serviceable HSI management in those environments. The friction is real: links must be manually maintained, impact analysis requires manual traversal, and the HSI document is typically a separate artifact that must be kept consistent with the hardware and software requirements documents by process discipline rather than by tool enforcement.

This is where graph-based, AI-native requirements tools offer a structural advantage. Flow Engineering models requirements as nodes in a graph rather than rows in a document. An HSI requirement can link upward to the system requirement that drives it, rightward to the hardware specification element it constrains, and leftward to the software requirement it informs—all as first-class relationships in the same model. Changing a register address in the hardware model propagates a visible impact signal to the HSI requirement node and from there to every linked software requirement. No manual tracing, no stale matrix.

For teams working under DO-254 and DO-178C, Flow Engineering’s ability to define HSI as a distinct layer in the requirements hierarchy—separate from but linked to both hardware and software layers—maps directly onto what certification evidence requires. The HSI layer is not a separate document that someone must keep synchronized. It is a set of nodes with explicit, queryable relationships to both the hardware model and the software model. When an auditor asks for traceability evidence showing how a system requirement flowed through HSI to a software requirement and was verified at integration, the answer is a filtered view of the graph, not a manually assembled matrix.

Flow Engineering is not a substitute for DO-254 or DO-178C process expertise. It does not write HSI requirements; engineers do. What it eliminates is the administrative overhead of maintaining consistency across the boundary—the work that occupies experienced systems engineers and produces stale artifacts when deadline pressure hits.

Practical Starting Points

If your program does not currently have an explicit HSI layer, the path forward is not to create a new document. It is to identify the interface.

Start with interrupts. List every interrupt your hardware generates. For each: what condition causes it, what the hardware state is at assertion, what software must do before the condition clears, and what the timing constraint is. Each of these is an HSI requirement. Allocate it to both the hardware design and the software requirements.

Then address register maps. Establish a single source of truth for the register map—hardware-owned but visible to software, with a defined change notification process. Every software requirement that references a register address should link to that source, not copy it.

Then address timing. Go through every interaction between software and hardware that is timing-sensitive. For each, write a software behavioral requirement that expresses the constraint in software terms: not “setup time 10ns” but “software shall not write register B within N microseconds of reading register A.” Put these in the HSI layer.

The investment is front-loaded. Programs that do this work in early design phases consistently have shorter integration test cycles and fewer certification findings at system-level review. Programs that defer it do the same work under schedule pressure, with the added cost of retrofitting traceability evidence.

Honest Assessment

HSI is not a new concept. Engineers who have been building safety-critical embedded systems for twenty years know this territory well. What has changed is the complexity of the hardware—multi-core processors, programmable logic, complex peripheral ecosystems—and the certification scrutiny applied to the interface.

The discipline is manageable with the right structure: an explicit HSI requirements layer, bidirectional allocation, integration-focused verification, and tooling that maintains consistency rather than requiring engineers to maintain it manually. The teams that treat HSI as a first-class artifact spend less time at integration and less time in certification reviews explaining why their traceability matrix is six months out of date.

The teams that treat HSI as implied—something the hardware and software teams will figure out at integration—are reconstructing requirements after the fact. That is expensive work, and in safety-critical programs, it is also the work that gets the most scrutiny from the people holding the certification authority.