Interface agreement responsibility matrix

How it works

A development interface agreement (DIA) says, for a functional safety project shared between a customer and a supplier, who does which safety activity, who approves it, which work products pass between them and by when. This worksheet builds that list, proposes the usual activities for your ASIL and kind of element, checks that every row has exactly one Responsible party and an Approver, and counts what each side carries.

1. Describe the agreement. Name the two parties, the item or element, the target ASIL and the kind of element (hardware built for this customer, software, or a chip or IP built without a known customer). A start date turns the proposed timings into due dates.
2. Propose the activities. The proposal is a Hub template of the activities and work products that safety agreements between a customer and a supplier usually list: contacts and plans, the item's safety goals and the requirements allocated to the element, safety mechanisms and interfaces, safety analyses, hardware metrics, dependent failure analysis, verification, confirmation measures, safety case contributions, configuration and change management, and production and field monitoring. ASIL and element kind decide which rows appear: a QM element keeps only the quality items, and the metric, FMEDA, audit and assessment rows start at ASIL B. Every row stays editable.
3. Assign roles in RASI form. Each row gives each party one role: Responsible (does the work), Approver (accepts the result), Supports, Informed, or none. A party that both does the work and approves it is shown as R and A. The result is a clear owner for every activity.a clear row has exactly one Responsible party and at least one Approver
4. Check the matrix. Rows are flagged when nobody is assigned, when both parties are Responsible, when neither is, and when no one approves. The sheet also looks for topics that no row mentions (for example a safety plan, dependent failure analysis or field monitoring) and counts the roles each party carries, which shows whether the work is balanced.rows with a problem = unassigned + both Responsible + no Responsible + no Approver
5. Track it. Each row has a phase, a due date and a status (not started, in progress, delivered, accepted). Rows past their due date and not delivered are counted. Export the sheet as CSV or JSON to attach to the contract or the safety plan.

Sources

The methods and default figures rest on these public sources. The wording here is our own; read the source for its full text.

• ISO 26262-8:2018, Road vehicles, Functional safety, Part 8: Supporting processes, clause 5, Interfaces within distributed developments, International Organization for Standardization, second edition, 2018. The requirement to agree responsibilities between customer and supplier. Cited by name, part and clause only; the method here is written in our own words.
• ISO 26262-2:2018, Road vehicles, Functional safety, Part 2: Management of functional safety, International Organization for Standardization, second edition, 2018. Safety management, the safety plan and confirmation measures (confirmation review, audit and assessment). Cited by name and part only.
• ISO 26262, Functional safety (knowledge centre entry) (opens in a new tab), Semiconductor Engineering, undated page, checked October 2026. A public glossary definition of the development interface agreement and its place in ISO 26262-8.
• Distributed Development of IP and SoC in Compliance with Automotive ISO 26262 (white paper) (opens in a new tab), Synopsys, undated page, checked October 2026. A public overview of how agreements define roles, responsibilities and work products between suppliers and integrators of IP and SoCs.