The Development Interface Agreement: Who Owns What in ISO 26262

In most vehicle programs, nobody develops the whole item. The vehicle maker owns the function, a supplier builds the controller, a semiconductor company supplies the chip that carries the safety mechanisms, and somewhere in between a software house writes part of the code. Functional safety still has to hold across all of them. The document that keeps it together is the Development Interface Agreement, or DIA, defined in ISO 26262-8:2018, Clause 5.

A DIA does one thing: it states who does which safety activity, who is responsible for what, and what crosses the interface between them. Each party keeps its own safety plan, and the DIA is what makes those plans fit together.

Where a DIA is needed, and where it is not

Take a battery management system for an electric vehicle. The vehicle maker defines the item and the safety goals. A tier 1 supplier develops the BMS. That supplier buys a cell-monitor chip off the shelf, and subcontracts part of the BMS software to a smaller company.

The vehicle maker and the BMS supplier need a DIA. So do the BMS supplier and the software house, because the requirement applies at every level of the supply chain, and internal suppliers can be handled the same way. The cell-monitor chip is different. It is not built to order, and if it was developed as a safety element out of context, no DIA is required. A chip without that route only qualifies for the exemption if it is both qualified to an established component standard and evaluated as Part 8 describes. What replaces it is the chip's safety manual and its assumptions of use, which the BMS supplier has to check against the real application.

A DIA is also not needed for a purchase that puts no safety responsibility on the supplier at all, such as a standard connector.

It starts before the contract

The interface begins with the request for quotation. The standard expects it to ask for compliance with ISO 26262, define the scope of supply, and pass on the safety goals or safety requirements with their ASIL. If the ASIL is not known yet, a conservative assumption is acceptable. Where they are already available, the hardware target values for failure rates and diagnostic coverage go in too. Supplier selection should also look at whether the supplier has delivered comparable complexity at a comparable ASIL before.

A supplier who quotes against "ISO 26262 compliant, ASIL to be defined" is quoting against nothing. The cost of the safety work depends on the ASIL, and both sides know it.

What goes into the agreement

The clause lists the content item by item, and it is long. It is easier to hold in your head as four questions the agreement has to answer.

Who is accountable on each side, and who checks the supplier's work? What does each party do? What crosses the interface, in both directions? And what happens when something goes wrong, from an anomaly at a subcontractor to a requirement the supplier cannot meet?

One rule in there surprises people: if the supplier performs the hazard analysis, the customer still verifies and approves it. The safety goals stay the vehicle maker's responsibility.

Signed is not the same as working

Most DIAs that fail do not fail on content. They fail because the agreement was negotiated by purchasing as a contract annex, and the engineers who should work to it have never opened it. A responsibility matrix that marks both parties responsible for half the activities, or an anomaly rule that says nothing about timing, reads fine at signature and breaks the first time something goes wrong.

The Development Interface Agreement concept page covers each part of the agreement and what it means in practice, how to build a responsibility matrix that holds up, anomaly handling across tiers, the assessment and the handover to production, worked examples and a full creation checklist.