Development Interface Agreement
Really not just a list of work products
2025-09-09 16 min Season 1 Episode 5
Description & Show Notes
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists.
The DIA, or Development Interface Agreement, is often used as a document whose sole purpose is to allocate responsibility for FuSa work products between customer and supplier. Who is supposed to develop what, and in what form – if any – should the results be exchanged. That’s it.
That’s it? Does that really meet the requirements of ISO 26262? Or do those requirements perhaps go beyond that? Let’s take a closer look.
Transcript
Hello and welcome to a new episode of “Applied FuSa,” a podcast for FuSa pragmatists. The DIA, or Development Interface Agreement, is often used as a document whose sole purpose is to allocate responsibility for FuSa work products between customer and supplier. Who is supposed to develop what, and in what form – if any – should the results be exchanged. That’s it. That’s it? Does that really meet the requirements of ISO 26262? Or do those requirements perhaps go beyond that? Let’s take a closer look.
D I A stands for Development Interface Agreement and resembles a contractual document between business partners. Surprisingly often, the DIA consists merely of a simple table listing all the work products of ISO 26262. Various columns add information to each work product, primarily aiming to define responsibilities and supply chains. This approach has become established since the release of the first version of ISO 26262, but in some aspects, it does not comply with the standard’s requirements for a DIA. So let’s forget everything we’ve seen or used as a DIA so far, and go back to the beginning… to the requirements.
The requirements for the DIA can be found in Part 8, Chapter 5.4.3 of ISO 26262. The chapter is titled “Initiation and planning of distributed development,” which already indicates the core topic. Safety-relevant systems can be a joint project, and in such cases, it is particularly important to define the interfaces very precisely. Interface issues can ultimately lead not only to very high, unforeseen costs but, in the worst case, can turn the product into a serious risk for road users. The first sentence in the ISO states: “The customer and the supplier shall specify a DIA including the following.” End of quote. This sentence seems to limit the DIA to a document between exactly two parties — namely, a customer and their supplier. However, it can be beneficial to establish a DIA that defines the division of work not only between a customer and multiple suppliers but also among the suppliers themselves. It is not always necessary to create a separate DIA for each pair of partners. What ultimately matters is that the interfaces between all parties involved are clearly defined so that no unnecessary risk to product safety arises.
This sentence is followed by a total of 11 requirements regarding the content of the DIA. Requirement 1: “the appointment of the customer’s and the supplier’s safety managers.” End of quote. The safety managers are to be named explicitly.
Requirement 2: “the joint tailoring of the safety activities in accordance with ISO 26262, Part 2, Clause 6.4.5.” End of quote. What does “tailoring of the safety activities” mean? Well, not all activities or work products defined in ISO 26262 are always required. A simple and clear example is when a project involves developing only a software application. In such a case, Part 5 (Hardware) usually does not apply. Therefore, all requirements can be tailored. However, tailoring can also mean that an activity is not carried out exactly as specified by the ISO. This constitutes a deviation from the standard, which can affect compliance. Compliance issues can be avoided, however, if the referenced requirements are still fulfilled. Under the reference—Part 2, Clause 6.4.5—you’ll find all the requirements for the tailoring of safety activities.
Tailoring is a key topic in functional safety, because the ISO, through its requirements on tailoring, ultimately allows a great deal of flexibility in how safety activities are executed. Put simply: anything is allowed, as long as it can be justified that the safety of the product is not compromised. For more on this topic, we recommend listening to the dedicated podcast episode. Now, the requirement also refers to “joint tailoring.” The word “joint” emphasizes the need for a coordinated agreement on the planned tailoring. This is important for two reasons. First, tailoring one’s own activities may affect how a business partner is able to work with the outcome. If that happens, the interface would not be clearly defined—and in the worst case, the work product may be completely unusable. Second, as mentioned, tailoring must be well justified. It’s entirely possible that the partner may not agree with the reasoning. It’s best to clarify this right at the beginning of the project, which is typically when the DIA is created.
Requirement 3: “the activities of the safety lifecycle to be performed by the customer and the activities of the safety lifecycle to be performed by the supplier.” End of quote. The term “activities of the safety lifecycle” refers to all tasks necessary to develop the work products defined in ISO 26262. These activities do not necessarily have to be described in detail—or even mentioned—by the ISO itself. The DIA should provide a transparent explanation of how a work product is actually developed. This applies to all parties that sign the DIA—not just the supplier. It is important to note that what is expected here is not merely a list of work products assigned to the customer or the supplier. The standard explicitly refers to “activities,” not “work products.” However, the widely used table format typically only lists the work products and not the corresponding activities. At this point, I recommend referencing the existing Product Development Process (PDP). The PDP of an organization should already describe, in sufficient detail, the activities involved in the development of all work products. Therefore, copying this content into the DIA is not practical. However, the reference must include the specific version of the PDP. This ensures that, if the PDP is updated after the DIA has been released, the reference still clearly points to the version that was valid at the time the DIA was issued.
Requirement 4: “the information and the work products to be shared, including distribution and reviews.” End of quote.
This refers to the list of work products typically included in the well-established table format. For each work product, the responsible party for its development is defined, along with how—if at all—it should be exchanged. Common categories include: “delivery of the original file,” “delivery of a summary,” “presentation or online review,” or “no exchange.”
Strictly speaking, this requirement goes beyond just work products, as it also mentions “information.” This means that any type of information to be exchanged should be described in the DIA as well. This makes perfect sense and can significantly help to avoid unnecessary discussions later in the course of the project.
Requirement 5: “the responsibility assigned to each party for each activity.” End of quote. “Note 1” helps clarify this requirement. It means that for each safety activity, the specific type of responsibility for all involved parties must be defined. The note provides example categories such as “Responsible,” “Accountable,” “Support,” “Inform,” and “Consult.” However, other categories are also permitted, depending on what is needed and mutually agreed upon.
Requirement 6: “the communication or confirmation [see 5.4.2.2 d)] of the target values, derived from the system level targets, to each relevant party in order for them to meet the target values for single-point fault metric and latent fault metric in accordance with the evaluation of the hardware architectural metrics and the evaluation of safety goal violations due to random hardware failures (see ISO 26262-5).” End of quote. Wow! That’s quite a mouthful! It sounds complicated, but it basically means that the targets for the hardware metrics are jointly documented in the DIA. Usually, the customer provides these targets to the supplier as design goals for the product being developed. The supplier must confirm these targets, and this confirmation happens automatically by documenting the targets in the DIA (otherwise, the supplier would not approve the DIA).
Requirement 7: “the interface-related processes, methods and tools needed for the collaboration between customer and supplier.” End of quote. This is a requirement that you’ll likely find fulfilled in very few DIAs. It calls for describing all processes, methods, and tools (PMTs) necessary for collaboration. Typical examples include PMTs for exchanging requirement documents, for sharing IP-protected information, or simply the PMTs needed for joint meetings. Whenever collaboration is involved… the required PMTs must be described in the DIA. Have you ever seen that done in a DIA?
Requirement 8: “the agreement on which party (supplier or customer) performs the safety validation in accordance with ISO 26262-4.” End of quote. Note that this concerns safety validation, not verification. It is about checking whether the safety concepts are ultimately effective enough to sufficiently reduce the risk of safety goal violations—for all safety goals. A supplier of sensor systems will typically support safety validation but usually will not be fully responsible. The OEM is generally fully responsible, as it is their vehicle. However, there are cooperation models where partial responsibilities are assigned to business partners. In any case, this must be described in detail in the DIA.
Requirement 9: “the functional safety assessment activities, in accordance with ISO 26262-2, regarding the elements or work products developed by the supplier.” End of quote. In my opinion, this requirement is redundant with previously discussed requirements, namely numbers 3, 4, 5, and 7. An interesting addition is “Note 1,” which points out that the customer is not automatically responsible for assessing the supplier’s work products, nor must they carry out the assessment themselves. Functional safety assessments can also be performed by the supplier, either internally or with the support of external service providers. This option is already possible due to the tailoring requirement.
Requirement 10: “the planning of the supplier’s functional safety assessment report.” End of quote. From my perspective, this requirement is also redundant, at least with respect to requirements number 4 and 5.
Requirement 11: “the agreement between customer and supplier(s) that allows a customer assigned auditor to perform functional safety audits at the supplier’s premises.” End of quote. This final requirement for the DIA is basically already covered by previously mentioned requirements, namely numbers 3 and 5. The description of any kind of collaboration is already required, and this naturally includes the case where a customer-assigned auditor audits the supplier. Thus, this eleventh requirement should be understood more as an emphasis on the importance of such an audit.
So, those were eleven requirements regarding the content and scope of the DIA. In the context of distributed development, there are further requirements related to the DIA, but none that define its content. Let’s compare the requirements we just discussed again with the initially mentioned table that is so commonly used. The table contains all work products from ISO 26262. For each work product, it indicates who is responsible and in what form it should be exchanged (if at all). Occasionally, there are additional columns with, for example, document numbers or status. Accordingly, some of the requirements are met—namely requirements 2, 8, 9, 10, and 11. The first requirement is usually also fulfilled, as there should be a cover page containing key project data, including the functional safety managers. However, all other requirements are either not met or only partially met. Let’s go through them one by one. Requirement 3: All safety-relevant activities must be described. As mentioned earlier, the easiest way to do this is by referencing the respective Product Development Process (PDP). While the table implies activities—since without them the work products couldn’t be developed—it lacks concrete details about what these activities actually entail. Requirement 4: The DIA must list not only the work products to be exchanged but also all types of information. A list that contains only the work products does not fulfill this requirement either. Requirement 5: This calls for the responsibilities assigned to activities, not just the work products as listed in the table. This matters because developing work products often involves multiple activities with different responsible parties. Full transparency means the DIA must specify the responsible party for each individual activity. Requirement 6: The table usually only defines responsibility for the FMEDA. However, requirement 6 (specifically clause 5.4.3.1 f) requires that the target values themselves also be documented in the DIA. Requirement 7: Processes, methods, and tools needed for collaboration are not described at all in the commonly used table. Therefore, this requirement is not even partially fulfilled—it is completely unmet.
Summary. We have explained in detail the eleven requirements defined by ISO 26262 for the contents of the DIA. We have shown that the widely used table—which only includes work products along with information on responsibility, exchange modalities, and sometimes status or references—is not a fully valid DIA, as some ISO requirements are either not met at all or only partially fulfilled. The DIA is one of the most important interface documents, also from a legal perspective. It should be initiated already during the offer phase and finalized at the latest by the project kick-off. From my experience, many problems related to the development and delivery of work products stem from insufficient or completely missing alignment in this regard. This often leads to unspoken or at least undocumented expectations, whose failure to be met can cause critical delays and associated costs. Please try to avoid this. Pay close attention to the DIA requirements as we have laid them out in detail for you in this podcast. It takes some time and effort upfront, but you can avoid many escalations this way. In the end, all parties will be grateful.
Applied FuSa – a podcast for Functional Safety pragmatists. Get your new piece of FuSa every other week.
Expert
00:00:37
Moderator
00:16:03