Compliance in engineering

ACurrently, in most cases, this verification is done manually, or to put it more bluntly: a week before the auditors arrive, all kinds of documentation are gathered or - even worse! - the proofs are created after the fact. The bottom line is that highly skilled automotive engineers are busy filling out pages and pages of Excel sheets. That's not particularly value-adding, to say the least.

Compliance implemented in a meaningful way

This inefficient approach is due, among other things, to the fact that processes are not always defined in a practical manner within the framework of Automotive SPICE ® or CMMI programs. In far too many cases, process definition is done by consultants. They "prescribe" certain processes to a company without taking into account whether these processes are aligned with the business objectives or, more generally, the realities of

Processes without practical relevance

of the company. Also, too many auditors, appraisers and assessors still check processes against checklists for nominal conformity to the standard. The result is completely unrealistic, ineffective or even business-damaging process specifications that developers and engineers grudgingly apply at best or ultimately ignore.

CMMI practices such as "PP SP 2.6: Plan Stakeholder Involvement", for example, do not serve an end in themselves! For this reason alone, no one should have to create pages of documents, fill out templates, give approvals, and hold meetings that last for hours. No, this practice simply wants to encourage those involved in the project to think about it: Who can contribute to the success of the project? How can these people be optimally involved in the project? When should this happen? In short, the basic idea of models like Automotive SPICE ® or CMMI can be summarized with the sentence: "Think before you act."

Directly in the value chain

It therefore makes much more sense to use experience from the aviation industry, railway technology, and other safety-critical areas of application and to build compliance verification directly into the development value chain (analysis, design, implementation, integration, testing). If certain activities are not value adding, they should be eliminated immediately. However, value creation should not be considered only in terms of short-term project benefits. Rather, the following value enhancements, for example, should be factored in:

• for the company as a whole
• when the process or practice is reused in other projects
• by exceeding the quality expectations of customers
• in the case of a successful approval by TÜV, FDA, notified bodies and other control authorities.

To achieve this goal, the traceability concepts known from requirements management, i.e. the traceability of a requirement across design, implementation and test, are used and applied to the management of processes. The upper part of Figure 1 shows this connection between the compliance level and the process level.

Acceptance through insight

Specifically, the standards are broken down into their individual requirements, which are mapped to the respective elements of the standard process description. For example, a requirement "6-6.4.1: The software safety requirements shall address each software-based function whose failure could lead to a violation of a technical safety requirement allocated to software" from ISO 26262 is mapped to the process steps "Elaborate Requirements", "Validate requirements" and the "Software Requirements" work product.

Chart 1 can be used for gap analysis in both directions:

1. Standard → Process: Are all standard requirements covered by process steps and implemented in practice? This ensures that all requirements of norms and standards are fulfilled, i.e. the process is checked for completeness.
2. Process → Norm/Standard/Pre

Excess "process waste

Is there a methodological, technical, normative or business justification for each process step? In this way, superfluous steps ("waste" in the sense of LEAN or simply excess "process waste") can be identified and eliminated.

Acceptance arises through rational and emotional insight - a widely held insight in psychology. The aim is therefore to show a continuous chain of reasoning from the individual standard requirements to the individual development steps. This makes it transparent for the end user why certain steps have to be carried out. This transparency ensures greater understanding and ultimately leads to increased process acceptance. Everyone is much more likely to understand and follow specifications and regulations if the reasons for the respective measures are clearly explained and made understandable to them. This procedure can be applied in parallel to several norms or standards. Examples of such combinations are

• Automotive: ISO 26262, Automotive SPICE ® and ISO TS 16949
• Medical Devices: IEC 62304, ISO 14971, ISO XXX
• Aerospace/Defense: CMMI-DEV, DO-178B/C, DO-254 and AS 9100 C

The effort can be reduced even further if these specifications are combined with each other and the processes are mapped to the resulting overall model. In this way, overlaps in the content of the specifications can also be eliminated and implemented uniformly in the processes. This approach has already been successfully implemented for the SPICE and CMMI models as well as for the standards for the development of medical devices. The number of individual

Making steps transparent

standard requirements could be reduced by more than 75 percent.

However, these processes are still at the theoretical level. Far too many companies remain stuck in process management with pure process publication. A visualization of the processes - as useful as it is - can only ever be a first step. For real improvements in everyday development, it is crucial that each defined process step really makes sense and is implemented in practice.

Concrete processes through tailoring

For the end user, it is important that the processes are as concrete as possible and suitable for his purpose. However, it is in the nature of things that standardized processes are inevitably abstract and thus in the rarest cases really concise enough to be directly useful and applicable in daily project practice.

Anyone who has managed or played a decisive role in several development projects can confirm that no two development projects ever follow exactly the same process. There is far too much variance, for example, in project goals, technologies used, customer requirements, organizational structures, or the experience of those involved in the project. Also, good organizations are constantly learning, adapting to changing circumstances, and using new technologies profitably. No standard process can ever take this variance and speed of change into account.

Via tailoring to accepted processes

It is therefore a matter of tailoring an abstract standard process description to the specific project application, i.e. selecting the right steps for a particular project and detailing them in the project context. A standard process specifies, for example, that requirements must be recorded, documented and checked for reasonableness and completeness. How this should be done optimally in a concrete project depends very much on the context.

In a safety-critical environment, such as an automobile, these requirements must normally be recorded in a structured manner, documented in a requirements management system, and checked by verification and validation. ISO 26262 makes a number of clear specifications here: For example, all technical safety requirements must be checked for conformance and consistency with the functional safety concept and the preliminary architectural assumptions (ISO 26262:2011 4-6.4.6.1). This verification can only be performed efficiently by at least semi-automated requirements management systems.

However, there are also system areas in every automobile that are not classified as safety-critical, for example most of the functions of an infotainment system. A formal examination of all the requirements for such systems would completely overshoot the mark. Does this mean that the structured management of these requirements can be dispensed with? Absolutely not! Requirements for infotainment systems are very extensive; it is not uncommon for complex systems to have up to a thousand individual requirements. It is impossible to manage such a number of requirements in a meaningful way using Excel, even if many companies still try to do so today, sometimes across many product variants.

In other system areas, it may be most efficient to describe the requirements with use cases or in a less structured way with user stories and to proceed directly to implementation without further testing.

So how do you apply abstract standard processes to concrete project circumstances? The solution is: through process tailoring. Tailoring means two things:

1. Known variants are already built into the standard processes and a decision is made for each project as to which variant will be used. This is usually done on the basis of tailoring criteria, such as the safety classification of the product (ASI level) or the number of requirements.
2. Unknown variances - for example when using completely new technologies - can be controlled by granting the development team a higher degree of freedom in process design. In extreme cases, the development team defines its processes itself!

Process tailoring is another important step towards meaningful, concrete and accepted processes in development. However, in order to achieve the greatest possible added value, it is crucial that the practical implementation is as efficient as possible.

Efficiency through automation

As a final step towards a value-adding process orientation, the most important process steps should therefore be automated. This applies, for example, to change, build or release processes. Here, the processes specified by tailoring are used directly in the PLM/ALM tools that engineers use every day to develop hardware, software and electronics. Modern development platforms can be configured on a project-specific basis by means of process definitions or contain workflow engines that, for example, manage change requests and control them across several disciplines until they are implemented. The lower part of Figure 1 shows this connection between the process level and the execution level.

Chain of evidence in the background

From a compliance point of view, you automatically get a continuous chain of evidence from the requirements of the standards to the concrete work results. If modern PLM/ALM tools are coupled with appropriately equipped process management systems, this chain of evidence functions completely without media disruption or manual intervention.

This means that the proofs are collected in the background through the normal execution of the processes in the development projects and can be generated as a report with a direct reference to the norms and standards if required. The engineers are exclusively involved in adding value, and the verification is generated automatically. Of course, this approach also works in parallel with several standards and norms. Leading vehicle manufacturers and their suppliers achieve efficiency gains in this way that are well into the double-digit percentage range.