A mutually agreed and agreed development interface agreement provides the customer and supplier with the information necessary to properly plan and execute the activities and work products that lead to a functionally safe end product. As simple as it may seem, there seems to be a big difference in how these agreements are presented and executed, which can lead to problems or concerns in the subsequent project. The interface agreement is similar to the document interface. Some contractors may refer to an interface issue that has been agreed (and possibly signed) as an interface agreement. It can be signed by both parties when an agreement is reached, but not always. An interface agreement is a document that defines an interface between two teams/sites/functional responsibilities. It can usually contain (or refer to) battery limit drawings, an interface matrix, or an interface register, for example. An interface plan is an agreement between the parties to the interface on the intended access to “contract items” prior to unloading and delivery – for example, to test underwater COMPUTERS, umbilical cords, etc. Note that the project interface management plan is a basic project document that defines how interfaces are managed and is described in more detail here. When the RDA is properly completed, it is a very important tool for determining the status and success of functional safety within a program. If the DIA is only used as a “checkbox” at the beginning of a project and is not reviewed throughout the project to ensure that each party is properly fulfilling its commitment, there are points that may be overlooked or not completely completed. Used more by stakeholders who “own” a part of a project than between contractors (who relate to their contract) – but see the green note below. I am a strong supporter of joint documentation, especially for functional safety.
Joint documentation lends credibility to the expected outcome of the project and helps to ensure that the document is complete, accurate and fully understood by all members of the organization who publish it. The DIA does not have to be written individually for each project or supplier; however, it should be reviewed and adapted accordingly. Many of the aid clients I`ve seen are a standard template that is sent to the supplier and doesn`t take into account the actual requirements of the project and the role of the particular supplier. The customer should take care to review the DIA with respect to the specific services required by each individual provider. The customer must indicate what is expected of the supplier and what documentation and information is provided to the supplier in order to effectively meet these requirements. This should then be checked very carefully by the supplier to ensure that all these requirements are understood, and the supplier should clearly state assumptions and seek clarification on anything that is not fully understood. Again, the client must be as specific as possible in defining the project expectations, and the supplier must take care to review the DIA and not accept the DIA until it is fully understood. Jennifer Giangrande has worked on alternative energy projects, clean commercial vehicles and, most recently, on the functional safety of propulsion systems. Jennifer holds a BSME from Lawrence Technological University and an MSME from Oakland University.
By avoiding these errors, the development interface agreement will be an informative and imaginative tool for the success of functional safety in a project. An effective DIA will provide guidance throughout the program and improve the working relationship between the customer and the supplier, while providing the end customer with a functionally safe product. This is probably the most overlooked part of the DIA. Without identifying target values at the beginning of the program, design requirements and hardware components can be incorrectly identified. This may well raise concerns about the success of a functionally safe product. It is very useful to use the DIA as a basis for the development of the security plan, which is regularly reviewed throughout the program to ensure that each party`s obligations are met. This will help ensure open communication between the two parties and support the goal of success of a functionally safe product. This closely follows the last point. Although the client does not consider the “grey areas” to be a cause for concern, they could most likely cause a delay or less than the successful completion of the project. For the supplier, these “grey areas” are likely to lead to assumptions that may be wrong, resulting in unnecessary work or incorrect performance. Here are some of the issues and concerns I have noticed with LIAs in the industry: One of the most important aspects of RFA is determining who is responsible for conducting activities, approving work products, supporting the development or execution of activities, informing the other party of the required information, and, where applicable, the need to consult on the activity or work product. (the famous RASIC).
The DIA should also go into detail about the expected work product and how it should be completed (if a certain format is required, an assessment will be conducted by the client or a third party, etc.). Very useful for me to understand the relevant documents of the ISO26262 standard Although it may not be possible to complete an DIA before procurement, it should be completed as soon as possible from the beginning of the program. If this is delayed, there may be different expectations that are accepted by each party, and the project may not be properly supported to ensure success. This could lead to time constraints, resource issues, and possibly design issues. If the DIA is completed before or during procurement (i.e. mutually understood and agreed), the project can be adequately supported by both the client and the supplier, and everyone will be able to effectively plan and support the project for successful and timely completion. I really like reading on this page, it contains excellent blog posts. Tags: DIA, Functional Safety Requirements, Latent Defect Metric, Security Plan The Development Interface Agreement (DIA) is the most important document to ensure the successful planning and achievement of a program`s functional safety objectives. It is supposed to be a tool and a record of what is expected of each party, and should specify the exact means for completion. It is the customer`s responsibility to communicate the relevant target values for the respective system or component based on the system-level targets so that the supplier achieves the target values for point and latent error measurements.
If you do not communicate it correctly, it may result in vendor assumptions that may not meet the system-level requirements identified for the project. This could most likely lead to a redesign that will result in significant cost and time issues, and depending on when the discrepancy is discovered, this could lead to concerns about meeting overall functional safety requirements. .