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 et audits, n'est-ce pas ?

Non, je veux dire… oui, dans une certaine mesure.

Mais avant tout, le risque de défaillances dangereuses doit être réduit à un niveau acceptable, et bien sûr… la preuve que cela a été fait correctement sera nécessaire.

Développer une culture de la sécurité

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.

Créer un processus de sécurité fonctionnelle sur la base d'un processus déjà défini

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.

En savoir plus sur l'ISO 26262 !

Découvrez nos

Une bonne approche dans chaque projet consiste à convenir des produits de travail attendus avec le client/fournisseur. ISO 26262 recommande de définir ces aspects dans des documents séparés :

Accord d'interface de développement (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.

Plan de sécurité (SP)

Incluez toutes les informations pertinentes pour la sécurité, telles que les entrées et sorties de processus, les explications, la cartographie, le statut des activités, les échéances et les responsabilités.

Connectez-le avec DIA.

Gérer les exigences de sécurité

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.

Analyser et vérifier

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.

Utiliser des outils qualifiés

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 nécessite l'évaluation et la qualification de tous les outils utilisés.

Résumé

Les aspects présentés du développement de processus doivent être considérés comme la partie émergée de l'iceberg, qui ne donne qu'un aperçu de base de la manière d'évoluer du développement classique vers le développement de produits liés à la sécurité.

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.

Parce que les véhicules d'aujourd'hui reposent fortement sur des fonctionnalités complexes pilotées par logiciel, le risque de défaillances augmente. La sécurité fonctionnelle garantit que ces systèmes fonctionnent de manière fiable et que les défaillances dangereuses sont réduites à un niveau acceptable.

Pas exactement. Bien que la documentation et les audits soient importants, l'objectif principal est de réduire les risques de sécurité. Des preuves sont nécessaires pour démontrer la conformité, mais la sécurité fonctionnelle consiste avant tout à prévenir les dangers.

The Development Interface Agreement (DIA) defines the safety work products, the rules for sharing documentation, and the responsibilities between the customer and the supplier. The Safety Plan (SP) outlines the safety activities, their timelines, the required inputs and outputs, and how these elements map to the overall development process. The Safety Plan should always remain aligned and connected with the DIA to ensure clear coordination and accountability.

In addition to FMEA, ISO 26262 recommends techniques like Fault Tree Analysis (FTA) and Dependent Failure Analysis (DFA), especially for higher ASIL levels. These help identify and mitigate both systematic and random failures early in the development process.