Development Interface Agreement: The Key to a Successful Functional Safety Program

A mutually understood and agreed upon Development Interface Agreement will provide both the customer and supplier the necessary information to properly plan and execute the activities and work products that result in a functionally safe end product. As simple as this sounds, there seems to be a vast difference in how these agreements are presented and executed, which could potentially lead to issues or concerns later in the project.

Following are some of the issues and concerns I have noticed within DIAs in the industry:

1. The DIA is not agreed upon prior to, or at, sourcing.

One of the most important aspects of the DIA is to identify who is responsible for performing activities, approving work products, supporting the development or performance of activities, informing the other party of required information and, if necessary, requiring consult on the activity or work product (the well-known RASIC). The DIA should also go into detail about what the expected work product is and how it should be completed (is there a specific format required, will an assessment be performed by the customer or a third party, etc.).

While it may not be possible to complete a DIA prior to sourcing, it should be completed as soon as possible once the program begins. If this is delayed, there could be different expectations assumed by each party and the project may not be properly supported to ensure a success. This could result in timing concerns, resource concerns and potentially design concerns. When the DIA is completed (meaning mutually understood and agreed upon) prior to, or at sourcing, the project can be properly supported by both the customer and supplier and each will be able to effectively plan and support the project for a successful and timely completion.

2. The DIA is a “one-size-fits-all”.

I am a big proponent of common documentation, especially for Functional Safety. Common documentation lends credibility to the expected outcome of the project and assists in making sure the document is complete, correct and fully understood by all in the organization who are issuing it. The DIA should not be individually written for each project or supplier; however, it should be reviewed and tailored accordingly. Many customer DIAs I have seen are a standard template sent to the supplier that don’t consider the actual requirements of the project and the particular supplier’s role.

The customer should take care to review the DIA with respect to the specific deliverables required by each particular supplier. The customer should identify what is expected to be completed by the supplier and what documentation and information will be provided to the supplier to effectively complete those requirements. This should then be very carefully reviewed by the supplier to be certain that all these requirements are understood and the supplier should state assumptions clearly as well as ask for clarification on anything that is not fully understood.

3. There are “gray areas” in the DIA.

This closely follows the last point. While the customer may see “gray areas” as no cause for concern, they could very likely lead to a project delay or less than successful achievement of the project. For the supplier, these “gray areas” will likely lead to assumptions that may be incorrect, causing unnecessary work or an incorrect deliverable.

Again, the customer should be as specific as possible when defining the expectations for the project and the supplier should take due care when reviewing the DIA and only agree to the DIA once it is fully understood.

4. The DIA is not reviewed throughout the program.

If completed properly, the DIA is a very important tool to determine the status and successful completion of Functional Safety within a program. If the DIA is only used at the beginning of a project as a “box check” and not reviewed throughout the project to be certain that each party is properly fulfilling its obligation, there are items that may be missed or not fully completed.

It is very useful to use the DIA as the basis to develop the safety plan, following with regular reviews throughout the program to ensure that the obligations by each party are being met. This will help to provide open communication between both parties and assist in the goal of a successful completion of a functionally safe product.

5. The target values are not defined.

This is likely the most missed portion of the DIA. Without identification of the target values at the beginning of the program, design requirements, and hardware component requirements, can be incorrectly identified. This can very well lead to concerns with the successful completion of a functionally safe product.

It is the customer’s responsibility to communicate the target values relevant to the particular system or component sourced based on the system level targets, in order for the supplier to meet the target values for single-point and latent fault metrics. If not properly communicated this can lead to assumptions by the supplier that may not meet the system level requirements identified for the project. This could very likely lead to redesign resulting in significant cost and timing concerns, and depending on when the discrepancy is discovered could lead to concerns with meeting the overall Functional Safety Requirements.

By avoiding these mistakes, the Development Interface Agreement will be an informative and resourceful tool for the successful completion of Functional Safety in a project. An effective DIA will provide guidance throughout the program and will enhance the working relationship between the customer and supplier while providing a functionally safe product to the end customer.