Risk reduction: a short guide on how to use ideas described in ISO 26262 in safety-related projects

The recent fast growth of automotive technology has put the vehicle manufacturers in front of new challenges regarding product and process evolution. Nowadays, there is nothing uncommon about having adaptive headlights, lane assistance or parking distance control in vehicles from an average price shelf. However, a few years ago such technology was something rare.

The complexity of functions, distributed development and rising certification requirements force engineers to constantly develop new skills to handle a growing industry demand. Software manufacturers need to figure out a way to manage multiple systems, approaches and tools.

In the real world, there is no ideal path which should be followed to accomplish safety compliance. Solutions will vary, depending on the project scope, company, or customer needs. The most important is to remember what functional safety really is about.

Documentation and audits, right?

No, I mean…yes, to some extent.

But first of all, the risk of dangerous failures must be reduced to the acceptable level, and sure… the evidence that it was done properly will be needed.

Develop safety culture

Because of growing pressure on safety aspects, the need of defining safety roles in every organisation emerges. By making the responsibilities clear, from senior management down to engineering levels, an effective reporting and escalation path regarding safety activities and interfaces should be defined as the first step for dealing with safety aspects.

Create a functional safety process on the grounds of already defined one

The development of a safety-related product brings up some additional factors which have to be considered. There has to be a quality lifecycle process (like for example A-SPICE) for building safety activities and working on products. Both processes have to be consistent with each other. Functional safety mapping should directly refer to already defined operation scenarios and operating modes. This will allow to diminish the risk of overheads and have a clear product structure.

A good approach in every project is to agree on the expected work products with the customer/supplier. ISO 26262 recommends to define such aspects in separate documents:

Development Interface Agreement (DIA)

To tailor the required documentation you ought to define work products and the extent to which they will be shared (original, extract etc.) based on a safety plan. Agree on the responsibilities to have a clear distinction of project activity ownership on both sides.

Safety Plan (SP)

Include all safety-relevant information like process inputs and outputs, explanations, mapping, the status of the activities, due dates and responsibilities.

Connect it with DIA.

Manage safety requirements

There is nothing extraordinary regarding requirements management in terms of ISO 26262 except that they have to be traceable to concrete safety work products (like for example Technical (TSC) or Functional Safety Concept (FSC). The known characteristics already defined in quality life-cycle processes apply here. Requirements have to be defined with adequate test criteria. Their status and progress need to be verified against project planning.

Analyse and verify

Functional safety focuses strongly on looking for plausible systematic and random failures. That is why a need to develop a systematic approach towards faults and failures handling is required. Quality lifecycle processes encourage preparing Failure Mode and Effects Analysis (FMEA). Functional Safety goes few steps further and recommends to prepare for example Fault Tree Analysis (FTA) and analysis of dependent failures (DFA) for higher ASILs. Such activities need to be planned in the already mentioned safety plan. For sure, they will affect project time and resources, but in the word of functional safety this is highly recommended.

Use qualified tools

Worth mentioning are tools for requirements management. Because of the importance and consequences, there shouldn’t be many possibilities to introduce a failure in requirements management. That’s why appropriate tools, which allow full traceability and history view have to be embedded in an already defined workflow. ISO 26262 requires evaluating and qualifying all used tools.

Summary

Presented aspects of process development shall be treated as the top of an iceberg, which gives only a basic glimpse on how to evolve from classic development to safety-related product development.

Improvement in processes capabilities to fulfill requirements of the safety standards is needed as the technology constantly evolves. Functional Safety can be achieved only on the basis of a mature development process, in which both OEMs and suppliers will be involved.