Automotive SPICE – Handling Detailed Customer Designs

According to A-SPICE SYS.3.BP3 (see figure 1) and SWE.2.BP3 we shall not only document design decisions but also the rationale behind them[1]:

In theory, requirements should remain solution-agnostic, focusing solely on functional goals (black box input-output relations). During the architectural or detailed design phases, engineers develop the »best satisficing«[2] technical solution (white box view). This iterative process, as illustrated in Figure 2, ensures that decisions are made at the most appropriate level of expertise.[3]

However, when customers specify detailed designs, this process is undermined. While such constraints are often necessary—for example, to define system interfaces or ensure safety mechanisms—they create methodical issues for suppliers. Common issues include:

• copy-pasting requirements along the V-model: This approach introduces functionality at higher system levels where it cannot be verified. For instance, memory protection mechanisms require white box fault injection tests at the driver level.
• bypassing the system level: Directly linking requirements to hardware, software, or mechanical components creates gaps at the system level. This can result in missing system test cases or incomplete traceability.
• abstract re-engineering of the system level: Pretending that the customer’s detailed design does not exist leads to redundant efforts. This is merely norm fulfillment without adding tangible value.

These approaches result in waste and fail to meet the intent of SYS.3.BP3 and SWE.2.BP3. While such practices may still pass superficial audits, a critical auditor might devalue the base practices, emphasizing their ineffectiveness.

To address these issues, I take a step back from A-SPICE. From an architectural viewpoint we need to identify what constrains our freedom in design, implementation, processes, and decision-making.[4] Constraints have a wide range from project goals (e.g., time, budget), over business goals (e.g., product roadmap) to technical limitations. A customer’s detailed design specification is no more than such a constraint. That is exactly how we can address this topic efficiently while ensuring A-SPICE compliance: The design constraint was specified and contracted »a priori«. The following is an example of a generic system requirement:

For illustrative purposes, consider the following example:

A more extended example:

Crucial Condition: The customer’s detailed design is a valid solution for your system. If not, renegotiation is unavoidable.

A-SPICE SYS.3.BP3 (Figure 1) and SWE.2.BP3 require documented rationale. Stating that the design constraint was specified by the customer should already constitute a valid rationale. However, some assessors may not accept this reasoning.

To support your rationale, provide evidence from prototypes or early samples that validate the solution. Ensure a trace between the design constraint and the evidence.

Since my proposed solution is not explicitly outlined in A-SPICE, some assessors might question whether it is an accepted methodology within my organization.

We can address this issue with process descriptions. They shift the burden of proof from the people to the organization. Demonstrating adherence to process descriptions often satisfies audit requirements. A concise statement in the process description at the system level might be:

Note: In order to comply with A-SPICE Level 3 or ISO 26262-8, it is essential to have a process description in place.

Customers often specify detailed designs for new systems. By reframing these as constraints, they become structured elements of the system design, streamlining efforts while ensuring A-SPICE compliance. Support the rationale with test evidence and clear process descriptions.

Yours, Nico Litschke

Titelbild: generiert mit DALL-E von OpenAI