Development Interface Agreement (DIA) - A deep dive
How important is the DIA? This was the question one of our team members asked us when we started reviewing a DIA. It is a simple yet profound question, for there are a lot of nuances to be unpacked as part of the answer.
<< Assumption for the
article: We are standing in the shoes of a Tier-1 supplier. For a Tier-1,
their customer is the OEM. This implies that the DIA will be between the Tier-1
and OEM FuSa managers. >>
Straight up, the DIA is the first
document with which we start discussions with the customer. The discussions on
the DIA should ideally start at the RFI/RFQ stage itself. Starting the DIA at
the RFI/RFQ stage ensures that the work products agreed upon with the customer
are properly estimated (time and money) during the quote. This, in turn, means
that the Tier-1 is able to plan their work accordingly.
As an example, we had an OEM who
asked us to perform FMEDA calculations for an ASIL-A program. (I’m sure you are
all aware that FMEDA becomes mandatory only from ASIL-C.) We did the most
logical thing — we discussed with the OEM why they wanted to do FMEDA for an
ASIL-A program (refer to Note #1 below). The OEM had their own reasons
for wanting it, and hence we went ahead with the second most logical thing — to
plan for this activity in our overall project plan. We had to estimate the
effort required for the FMEDA activity, plan the activity in our HW and FuSa
development timelines, and deliver the results to the OEM at regular
milestones.
As you could guess by this time,
the DIA is one of the critical inputs for planning the future course of action
in the project.
Note #1: An important
lesson that we have learned from numerous projects is that we need to have
multiple discussions with the OEM on the DIA. The ISO 26262 standard —
unfortunately — is not black and white, but written with a lot of shades of
grey. This means that there are some work products and requirements prone to
different interpretations. Due to this interpretation mismatch, it becomes
necessary for us to discuss and align on expectations.
Many times — once we have an open
discussion with our customers — we are able to understand each other and
fine-tune the work products required for the project. This upfront discussion
on the DIA ensures that we spend our effort on FuSa for the most critical
things, and not end up doing work that has no significant effect on the safety
of the product.
The second critical aspect of the
DIA is the decision on which documents would be shared with the OEM and which
would not be. Why is this important?
Some documents contain the
intellectual property (IP) of a Tier-1 (like the HW schematic or the HW Bill of
Material (BOM)), and Tier-1s are definitely not fine with sharing them as-is
with an OEM. Then, there are documents containing sensitive information (like
the FMEA). A Tier-1 might not be willing to wash their dirty linen in front of
the OEM. (Which OEM would be happy to see that their ECU supplier has basic
process issues?)
Due to the reasons listed above,
it is essential that discussions happen upfront about the documents that would
be shared, the format in which they would be shared, and the sharing
methodology. Some of the common sharing methodologies we have seen are:
- Full: The entire document would be shared.
- Report: Only a summary of the document would
be provided.
- Online only: Shared through a conference
call; no copies are sent.
- At Tier-1 premises only: The OEM can view
the document only at the Tier-1 premises.
- Last but not least, the good old N/A: (Not
applicable, of course 😉)
A small, related aspect is that
we have also seen certain OEMs and Tier-1s include work products that are not
part of the ISO 26262 work product list in their DIA. These could include
documents relating to CPU load analysis, static analysis, etc. The idea here is
that when some of these documents are added to the safety process deliverables,
the chances of them going through higher scrutiny increases, and hence the OEM
might push for such an approach.
In such a case — as a Tier-1 — it
becomes essential that we sign up carefully only for the most relevant and
safety-related documents as part of the DIA. It should not end up being a
wishlist of sorts where all project documents are curated and tracked through
the DIA.
The third critical aspect of a
DIA is the aspect of milestones. The OEM and Tier-1 might agree on when a
certain work product needs to be available. Sometimes, there could even be
intermediate milestones at which documents need to be submitted.
Let us consider two examples.
In the first example of a FMEDA,
the OEM might be interested (or concerned) to know whether we are able to meet
the HW metrics or not. As meeting the HW metrics is an essential aspect of
demonstrating safety, OEMs might push to have these results available early in
the development cycle (say, during B-Sample or, in the worst case, before the
DV build). At this point, the SW development might not be complete, and hence
the HW metric achieved might come with the caveat that these metrics
assume the SW safety mechanisms identified will be implemented in the coming
milestones.
As generally happens in any
project, some of the assumptions might go for a toss (due to various valid or
invalid reasons). Due to this, the OEM might be interested in viewing the FMEDA
results/report a second time after the SW development milestones are completed.
The second example concerns SW
test results (say, unit testing results). These results would be available only
after SW development is completed, and the OEM might want to just look at the
coverage report (Statement, Branch, and MC/DC). For this summary report, the
OEM might agree to view it after the SW development milestone is completed and
not push for an early milestone. This gives the Tier-1 some breathing space
(and this breathing space is something we have never seen!).
Even as we have taken to heart
what Frederick the Great is rumoured to have said — “My people and I have
come to an agreement which satisfies us both. They are to say what they please,
and I am to do what I please.” — DIAs are an essential part of safety
development, and utmost attention is to be paid to satisfying what has been
agreed.
Comments
Post a Comment