ISO 26262 : Le guide complet

Qu'est-ce que l'ISO 26262 ? Pourquoi l'ISO 26262 est-elle nécessaire ?

L'ISO 26262 est une norme internationale relative à la sécurité fonctionnelle des systèmes électriques et électroniques de tous les véhicules routiers, à l'exception des cyclomoteurs.

La norme ISO 26262 a été la première norme internationale traitant de la sécurité des systèmes électriques/électroniques/programmables. Elle a été annoncée en 2011 par l'Organisation internationale de normalisation (ISO), mais elle trouve ses racines dans la norme IEC 61508, publiée en 1998.

L'objectif de l'ISO 26262 est de minimiser les risques associés à la conception et au développement des produits afin de prévenir les dangers et les défaillances potentiellement menaçantes pour la santé et la vie humaines. Le but est d'atteindre un risque résiduel acceptable.

ISO 26262 couvre l'ensemble du cycle de vie de la sécurité produit : de la gestion, au développement et à la production jusqu'au service. Tout au long du processus de développement, la norme couvre tous les aspects liés à la sécurité à un niveau très détaillé, y compris la spécification des exigences, la conception, la mise en œuvre, l'intégration, la vérification, la validation, la configuration, la production, les services, l'exploitation et le déclassement. ISO 26262 décrit également le cadre de la sécurité fonctionnelle pour faciliter le développement du système lié à la sécurité.

Pour plus d'informations sur cette norme, consultez notrelignes directrices relatives à l'ISO 26262.

Quelle est la différence entre l'IEC 61508 et l'ISO 26262 ?

Vous pouvez considérer l'ISO 26262 comme une adaptation de l'IEC 61508 aux besoins de l'automobile. L'IEC 61508 concerne tout système électronique ou électrique, mais peut être appliquée dans diverses industries. De ce point de vue, l'IEC 61508 est souvent reconnue comme une norme maîtresse de sécurité fonctionnelle.

L'ISO 26262 est-elle obligatoire ?

Bien que l'ISO 26262 soit largement utilisée dans le secteur automobile, elle n'est pas obligatoire. Cependant, la conformité généralisée montre qu'elle est considérée comme une norme essentielle, car le respect des règles et des meilleures pratiques définies par l'ISO 26262 rend les processus de développement et de production plus efficaces et structurés. Elle introduit plus d'efforts et de restrictions dans le flux de travail, mais en conséquence, vous obtenez des processus bien organisés et vous vous assurez que tout point faible possible est identifié et traité. Cela vous donne, à son tour, un produit sûr et de haute qualité. Pour cette seule raison, les OEM insisteront pour que leurs propres fournisseurs appliquent l'ISO 26262 dans leur processus.

Parties de l'ISO 26262

La norme ISO 26262 se compose dedouze parties, chacun se référant à un niveau différent du cycle de vie du produit :

PPartie 1 : Vocabulaire

Cette partie spécifie le vocabulaire, les définitions et les abréviations couramment utilisés afin de maintenir la cohésion et de prévenir les malentendus.

PPartie 2 : Management de la sécurité fonctionnelle

Cette section décrit la méthodologie appropriée de gestion de la sécurité fonctionnelle pour les applications automobiles. Elle comprend la gestion globale de la sécurité ainsi que des informations spécifiques au projet liées aux activités de gestion tout au long des différentes phases du cycle de vie de la sécurité.

Ppartie 3 : Phase de conception

La Partie 3 est appliquée lors de la phase initiale de développement du produit. Elle exige la réalisation d'une Analyse des Dangers et des Risques (HARA) basée sur la Définition de l'Élément. Elle comprend également la définition des Exigences de Sécurité Fonctionnelle, qui sont ensuite transmises à l'Équipe Système. À partir de ce moment, les Objectifs de Sécurité du projet doivent être définis.

Part 4 : Développement du produit au niveau système

La partie 4 couvre les problématiques de développement au niveau du système. Elle décrit les spécifications qui doivent être initiées pour la sécurité technique, telles que le concept de sécurité technique, la conception architecturale du système, l'intégration et les tests de l'élément.

PPartie 5 : Développement produit au niveau matériel

La partie 5 couvre des sujets de base, tels que la conception matérielle ou l'évaluation des métriques architecturales du matériel. Dans cette section, il est également nécessaire d'évaluer les violations des objectifs de sécurité causées par des défaillances aléatoires.

PPartie 6 : Développement produit au niveau logiciel

Cette partie contient les spécifications relatives à la sécurité logicielle, à la conception architecturale du logiciel, à la conception et à la vérification des unités logicielles, à l'intégration logicielle et aux tests des logiciels embarqués. À ce stade, des analyses qualitatives, telles que l'Analyse par Arbre de Défaillances (FTA) et l'Analyse des Modes de Défaillance et de leurs Effets (FMEA), sont souvent mises en œuvre.

PPartie 7 : Production, exploitation, maintenance, décommissionnement

Cette partie décrit comment développer et maintenir un processus de production pour les éléments et articles liés à la sécurité destinés à être installés dans les véhicules routiers. Elle inclut également des informations sur les opérations, les services et le décommissionnement pour les utilisateurs, qui interagissent avec les articles liés à la sécurité.

PPartie 8 : Processus de support

Cette partie s'applique à toutes les phases du cycle de vie de la sécurité du produit. Parmi les sujets qu'elle couvre figurent la manière de procéder correctement à la vérification, la manière d'effectuer la qualification des outils ou la manière d'introduire des arguments éprouvés en usage.

Partie 9 : analyses orientées Automotive Safety Integrity Level (ASIL) et orientées sécurité

La partie 9 couvre la décomposition ASIL, les critères de coexistence des éléments, l'analyse des défaillances dépendantes et les analyses de sécurité.

Partie 10 : Lignes directrices sur ISO 26262

La partie 10 est une vue d'ensemble de l'ISO 26262 enrichie d'informations supplémentaires. L'objectif est d'améliorer la compréhension des autres parties et de l'ISO 26262 en général.

Part 11 : Lignes directrices sur l'application de la norme aux semi-conducteurs

La Partie 11 fournit des informations détaillées pour soutenir les fabricants de semi-conducteurs et la propriété intellectuelle (IP) silicium. Son objectif est de définir comment les fournisseurs et intégrateurs d'IP devraient travailler ensemble.

Partie 12 : Adaptation de l'ISO 26262 aux motocycles

La dernière partie est un aperçu de l'adaptation des normes ISO 26262 pour les motos. Elle décrit la culture de sécurité, les mesures de confirmation, l'analyse des dangers et l'évaluation des risques, l'intégration et les tests du véhicule, ainsi que la validation de la sécurité.

ISO 26262 vs ISO PAS 21448 (SOTIF)

L'ISO 26262 ne couvre pas tous les domaines de la sécurité fonctionnelle. Elle ne comporte pas de sections consacrées, par exemple, aux mauvais usages ou à la conduite automatisée. L'ISO PAS 21448 (SOTIF) a été introduite pour combler ces lacunes. Il était prévu de l'intégrer à l'ISO 26262 en tant que quatorzième section, mais elle a finalement été publiée en tant que document distinct.

La SOTIF aborde certains aspects de la conduite autonome, où la sécurité n'est pas compromise par la défaillance elle-même, mais par le comportement non spécifié du véhicule. En d'autres termes, la SOTIF adopte une approche plus holistique de l'utilisation du produit que l'ISO 26262.

Qu'est-ce que l'ASIL ?

L'Automotive Safety Integrity Level (ASIL) est un système de classification des risques introduit et défini par l'ISO 26262. Il est utilisé pour définir les exigences de sécurité nécessaires pour être conforme à l'ISO 26262. Les critères de classification incluent plusieurs facteurs, tels que la probabilité d'une blessure et sa gravité potentielle. Sur la base de ces informations, le produit peut ensuite être certifié et considéré comme infaillible en termes de fonctions critiques pour la sécurité.

Il existe quatre niveaux de danger ASIL : A, B, C et D. Il existe également un cinquième niveau – MQ, qui est un niveau non dangereux. L'ASIL de A à D signifie qu'il existe un certain niveau de risque inacceptable dans le système, et des efforts FUSA particuliers sont nécessaires pour augmenter la contrôlabilité des situations indésirables.

ASIL D est le degré le plus élevé de danger automobile, ce qui signifie que le produit doit répondre aux exigences de sécurité les plus strictes car il présente le risque de blessure le plus élevé en cas de dysfonctionnement. Si un produit est certifié pour satisfaire aux exigences ASIL D, il est également conforme à tout ASIL inférieur.

À l'autre extrémité du spectre des niveaux de risque se trouve le QM, qui signifie « Quality Management » (gestion de la qualité). Il représente le niveau de risque le plus faible, ce qui signifie qu'il n'y a aucun danger automobile ou, en d'autres termes, qu'aucune exigence ne doit être assurée au titre de l'ISO 26262.

Comment déterminer le niveau ASIL pour les logiciels automobiles ?

L'ASIL est déterminé par une analyse des dangers et des risques (HARA), qui comprend l'évaluation de la gravité, de l'exposition et de la contrôlabilité du scénario de conduite du véhicule.

Vaut-il la peine de réaliser une décomposition ASIL ?

La décomposition ASIL est une méthode de personnalisation de l'ASIL lors des phases de conception et de développement. Elle peut être appliquée aux exigences de sécurité fonctionnelles, techniques, matérielles ou logicielles d'un élément ou d'un composant.

À la suite d'une liste d'objectifs de sécurité, les exigences de sécurité sont dérivées et affinées. Lorsque les exigences de sécurité sont allouées aux éléments architecturaux respectifs, des bénéfices peuvent être obtenus en attribuant un ASIL potentiellement inférieur aux composants architecturaux grâce à l'utilisation de solutions redondantes. En décomposant les exigences au niveau du système en plusieurs sous-exigences redondantes allouées à différents composants, vous parvenez à un point où chaque sous-exigence (composant) contribue directement à la réalisation de l'exigence au niveau du système.

Dschémas de décomposition selon ISO26262

La stratégie de décomposition est décrite dans la norme ISO 2626-9:2018, article 5. Selon l'objectif de sécurité le plus élevé, différentes stratégies de décomposition ASIL peuvent être appliquées par l'architecte pour concevoir le système, en tenant compte des technologies nécessaires et des meilleures pratiques.

Exemple :

Le développement des éléments décomposés doit être réalisé, au minimum, conformément aux exigences ASIL après la décomposition effectuée. Toutefois, il existe une exception concernant le niveau matériel. Les valeurs cibles pour l'évaluation des métriques architecturales matérielles et l'évaluation des violations d'objectifs de sécurité dues à des défaillances matérielles aléatoires doivent être issues de l'ASIL générique (avant décomposition (ISO26262-9:2018, 5.4.11))

La décomposition doit tenir compte de la faisabilité technique. Par exemple, une exigence ASIL D allouée à une fonctionnalité exécutée par un ECU ne peut pas être décomposée en ASIL QM(D) pour l'ECU et ASIL D(D) attribué à un simple chien de garde (agissant comme un mécanisme de sécurité), car le chien de garde pourrait être insuffisant pour couvrir tous les modes de défaillance pertinents du microcontrôleur.

Menaces de décomposition

La décomposition est intrinsèquement liée à un effort de création d'exigences de sécurité supplémentaires. Bien entendu, toutes ces exigences doivent être associées à des attributs de sécurité ainsi qu'à des règles de mise en œuvre et de vérification.

Deuxièmement, la décomposition n'aura pas lieu si une indépendance suffisante n'est pas garantie. Cela signifie qu'aucune défaillance de cause commune n'existe et que l'absence d'interférence est assurée entre les éléments décomposés. Pour ce faire, une analyse des défaillances dépendantes doit être menée conformément à l'ISO 26262-9:2018, article 5.

Un autre inconvénient est que, en raison des différentes méthodes de développement et de vérification requises pour les différents ASIL, l'équipe de développement pourrait potentiellement ne plus être en mesure de suivre les exigences du processus de sécurité et, par conséquent, l'acceptation des méthodes ISO26262 pourrait être menacée.

De plus, en ce qui concerne la conception de l'architecture matérielle, des pièces ou composants matériels supplémentaires peuvent être nécessaires pour mettre en œuvre la redondance. L'augmentation du nombre de pièces affectera la fiabilité. L'objectif FIT du produit peut être compromis. En outre, dans le cas d'une redondance homogène, il n'y aura aucune argumentation sur l'évitement des défaillances systématiques.

Opportunités découlant de la décomposition ASIL

La réduction des risques résultant de la mise en œuvre de la redondance est certainement l'un des principaux avantages de la décomposition.

Parfois, la décomposition est le seul moyen de répondre à des exigences de projet très élevées, en raison du manque de technologie disponible.

De plus, des économies de coûts significatives peuvent être réalisées en utilisant la décomposition. En particulier lorsque la décomposition ASIL est effectuée de manière à ce que la majorité du logiciel soit classée QM (Quality Managed) ou ASIL A/B au lieu d'ASIL C ou D. L'avantage augmentera encore davantage lorsque la partie du logiciel soumise à des modifications fréquentes aura un ASIL faible. Une bonne architecture de sécurité se caractérise par le fait que seule une petite partie du logiciel, qui n'est pas fréquemment modifiée, est développée selon des niveaux ASIL élevés.

La décomposition ASIL offre aux concepteurs la flexibilité nécessaire pour atteindre les niveaux les plus élevés de couverture diagnostique. Tirer parti des principes de décomposition permet d'utiliser des composants de niveau ASIL inférieur tout en répondant aux besoins des systèmes ASIL les plus élevés. Par conséquent, la décomposition apporte le plus de valeur lorsqu'elle est réalisée au niveau du système. De plus, lorsque les éléments décomposés sont mis en œuvre sous forme de deux canaux totalement indépendants, le système peut être rendu résilient aux défaillances de cause commune. Toutefois, cela a un coût en termes de travail supplémentaire, principalement en ce qui concerne la gestion des processus.

Comment atteindre la conformité ISO 26262 ?

Pour garantir la conformité avec l'ISO 26262, chaque élément du système doit être vérifié selon les principes de la sécurité fonctionnelle. Le processus ne se limite pas aux produits mais s'applique également au cadre de livraison sur lequel le produit a été basé. Par conséquent, pour les systèmes liés à la sécurité, l'ensemble du processus d'ingénierie de la sécurité doit être confirmé.

À cette fin, l'ISO 26262 introduit les Mesures de Confirmation, qui sont regroupées en trois catégories :

• Revue de confirmation– concerne les objectifs du produit de travail (Concept de sécurité fonctionnelle, Conception architecturale logicielle)
• Audit– couvre le processus mis en œuvre en ce qui concerne les objectifs du processus (ISO 26262)
• Évaluation– examine un élément ou les caractéristiques d'un composant par rapport aux objectifs du processus (Body Control Module)

Comment réaliser une revue de confirmation selon l'ISO 26262 ?

Lors du développement d'un produit selon l'ISO 26262, des activités supplémentaires doivent être prises en considération pour satisfaire aux exigences de la norme. L'une d'elles est un processus de vérification clairement défini, dont les caractéristiques diffèrent selon l'ASIL attribué. Une forme spécifique de revue connue sous le nom de revue de confirmation est introduite par la norme afin de réduire le risque. Comment y procéder, à quel stade et par quels moyens, cependant, n'est pas si clair et dépend de différents facteurs tels que l'ASIL du projet. Une forme spécifique de revue connue sous le nom de revue de confirmation est également requise dans l'industrie automobile, où la sécurité fonctionnelle est mise en œuvre.

La revue de confirmation (CR), dans sa spécification, est très similaire à la revue de vérification, mais elle n'est pas exactement identique ; ce qui la rend encore plus intéressante, c'est qu'elle exige un certain degré d'indépendance organisationnelle. Plus l'organisation est petite, plus le défi est important.

Pourquoi réaliser une revue de confirmation ?

L'objectif principal d'une revue de confirmation est de garantir la conformité à la norme ISO 26262. Elle doit être réalisée pour les produits de travail considérés comme cruciaux lors du cycle de vie de sécurité du produit, donc ne vous inquiétez pas – tous les produits de travail ne doivent pas être confirmés de manière indépendante. Compte tenu de l'indépendance respective du réviseur, cela permet la validation de toutes les hypothèses possibles concernant les méthodes, principes et preuves sélectionnés pour satisfaire aux exigences de la norme.

Qu'est-ce qu'une revue de confirmation ?

La définition incluse dans la norme est simple :

“Confirmation qu'un produit de travail lié à la sécurité fournit des preuves suffisantes et convaincantes de sa contribution à l'atteinte de la sécurité fonctionnelle, compte tenu des objectifs et exigences correspondants de l'ISO 26262”

Toutefois, des questions telles que : ce que l'on entend par « preuves suffisantes et convaincantes », qui réalise un tel examen et pour quel livrable il est nécessaire, ne sont pas expliquées dans la définition, ce qui constitue un autre défi dans l'atteinte de la sécurité fonctionnelle.

Ce qui rend les CR uniques, c'est l'indépendance requise. L'ISO 26262 décrit quatre niveaux d'indépendance présentés ci-dessous :

Comment se déroule la revue de confirmation ?

Si vous souhaitez réaliser une revue de confirmation, voici une liste rapide d'activités et des aspects correspondants, préparée par notre Ingénieur en Sécurité Fonctionnelle, Piotr Peret, qui devraient être pris en compte au préalable.

Identifier les produits de travail nécessitant une revue de confirmation

Pour la réponse, vous devez vous référer à la norme ISO 26262 partie 2. Ce qu'il faut souligner à nouveau, c'est que la réponse à cette question dépend de l'ASIL le plus élevé dans le projet donné, mais est également limitée par le périmètre du projet. Par exemple, le concept de sécurité fonctionnelle est généralement hors périmètre pour les projets logiciels développés en tant qu'élément de sécurité hors contexte (SEooC).

Le tableau ci-dessous répertorie les produits de travail qui doivent faire l'objet d'une revue de confirmation ainsi que le niveau requis d'indépendance organisationnelle pour chacun.

Identifier qui sera responsable de la revue de confirmation

Une personne ou un groupe responsable de la revue de confirmation doit être désigné. L'organisation doit s'assurer que cette personne dispose de l'autorité, des compétences et des qualifications nécessaires pour réaliser la CR. Un ou plusieurs assistants peuvent être désignés pour soutenir la réalisation de la revue de confirmation. Ces personnes peuvent ne pas être indépendantes des développeurs de l'élément, des éléments ou des produits de travail correspondants, mais leur indépendance doit être au moins de niveau I1, tel que défini dans le tableau 1, et le réviseur doit évaluer leur contribution afin de garantir qu'un avis impartial soit donné.

Établir ce qui constituera la preuve de la revue de confirmation

La personne susmentionnée responsable de la CR doit fournir un rapport contenant une évaluation de la contribution obtenue à la sécurité fonctionnelle par le produit de travail respectif. Pour accroître la confiance dans l'atteinte des objectifs de la revue, le réviseur vérifie la correctitude, l'exhaustivité, la cohérence, l'adéquation et le contenu du produit de travail par rapport aux exigences correspondantes de la série de normes ISO 26262.

Planifier le moment de réaliser la revue de confirmation

La règle principale est que les revues de confirmation doivent être finalisées avant que le projet ne soit mis en production. Évidemment, le plus tôt sera le mieux. Disposer d'un plan avant le développement aide certainement à établir une échéance. La revue de confirmation, bien que chronophage, peut apporter une conclusion pertinente pour la sécurité fonctionnelle du produit, alors qu'il est encore temps de reconcevoir le système. Une revue de confirmation tardive pourrait aboutir à une situation où la résolution d'un problème identifié impacte le calendrier de tout un projet.

Si le calendrier ne permet pas de réaliser des revues de confirmation distinctes, une revue de confirmation et une revue de vérification peuvent être combinées. Toutefois, pour qu'elle soit considérée comme une revue de confirmation, il faut s'assurer que la revue de vérification est effectuée avec une indépendance suffisante.

Si vous souhaitez en savoir plus sur les autres mesures de confirmation, ou si vous rencontrez des difficultés pour atteindre une indépendance suffisante dans votre projet, contactez l'équipe Spyrosoft Functional Safety à l'aide du formulaire ci-dessous.

Comment réaliser un audit de sécurité fonctionnelle (ISO 26262) pour un logiciel ?

L'audit de sécurité fonctionnelle est un examen formalisé visant à identifier les lacunes et les anomalies dans le processus ISO 26262 établi. Il implique toutes les parties concernées et s'accompagne d'un périmètre, d'un ordre du jour, de modèles, d'une liste de contrôle et de rôles spécifiés.

Cela commence par la détermination de la personne responsable de l'audit des processus, avec l'affirmation d'un niveau d'indépendance requis pour une mesure de confirmation particulière, déterminé par un niveau d'intégrité de sécurité automobile (ASIL) spécifique.

L'indépendance organisationnelle suivante est requise pour réaliser un audit ISO 26262 :

• Pour le QM et l'ASIL A, aucune exigence ne porte sur la réalisation d'un audit de sécurité fonctionnelle.
• L'ASIL B exige que l'audit du plus faible niveau d'indépendance (I0) soit réalisé par une personne non impliquée dans la création de tout produit de travail en dehors du projet.
• L'ASIL C exige qu'un audit d'indépendance de niveau 2 (I2) soit réalisé par une personne indépendante de l'équipe responsable de la création, par exemple, ne dépendant pas du même manager.
• L'ASIL D exige que l'audit du plus haut niveau d'indépendance (I3) soit réalisé par une personne indépendante du département responsable de la création. Idéalement, un organisme d'audit distinct appartenant à une autre entreprise.

Une fois le niveau d'indépendance déterminé, chaque artefact ISO 26262 inclus dans le périmètre de l'audit est évalué sous différents angles, notamment :

1. Évaluation du processus mis en œuvre par rapport à ses définitions ou spécifications dans un plan de sécurité.
2. Évaluation des arguments fournis pour la mise en œuvre du processus.
3. Évaluation des produits de travail (sur différents projets).
4. Recommandations d'amélioration (en cas de non-conformité).

Étant donné que l'ISO 26262 ne fournit aucun modèle ni cadre pour la réalisation d'audits, nos Functional Safety Professionals (CFSE) certifiés, dotés de l'expertise nécessaire pour réaliser et superviser le processus d'audit, peuvent vous aider à vous assurer que l'ordre du jour de l'audit est entièrement couvert et que toutes les étapes d'audit sont correctement suivies.

Et que faire des résultats de l'audit ?

Une fois l'audit terminé, les résultats doivent être regroupés dans un rapport d'audit qui met en évidence :

• Points de non-conformité majeure
• Points de non-conformité mineurs
• Actions à entreprendre pour améliorer ou résoudre les lacunes et anomalies identifiées.

Les recommandations d'amélioration doivent être traitées ensuite et éventuellement résolues par les parties responsables.

Il est recommandé de réaliser régulièrement un audit de sécurité logicielle, car cela diminue la probabilité qu'une mise en œuvre incorrecte des processus impacte différents projets ou que des incohérences produit apparaissent ultérieurement lors de l'évaluation. Cela améliore également la culture de la sécurité, facilite l'identification des points faibles dans le développement sécurisé et limite la responsabilité produit.

Gardez à l'esprit que les audits de sécurité fonctionnelle sont les plus bénéfiques lorsqu'ils sont réalisés au stade précoce du développement du projet/produit. Étant donné que l'audit de sécurité fonctionnelle doit être finalisé avant la mise en production, il est conseillé de le réaliser dès que le processus conforme à l'ISO 26262 est établi dans l'entreprise.

Il convient également de noter que l'audit ISO 26262 et l'évaluation Automotive SPICE peuvent être réalisés de manière coordonnée afin d'éviter la duplication du travail et les incohérences. À cette fin, un modèle d'évaluation des processus (PAM) étendu est introduit.

Comment réaliser une évaluation ISO 26262 ?

Lorsqu'un produit est en cours de développement conformément à l'ISO 26262, il arrive toujours un moment où il faut évaluer si la sécurité fonctionnelle est atteinte. L'ISO 26262 nous offre diverses possibilités pour vérifier si notre conception est conforme au niveau ASIL, comme des mesures de vérification et de confirmation. Celle qui peut aider à identifier les lacunes et montrer comment les corriger est l'évaluation de la sécurité fonctionnelle.

Organisation de l'évaluation

L'une des questions concernant l'évaluation est la suivante :Quand faut-il la réaliser ?Nous avons ici deux aspects : le premier concerne les cas où cela est exigé par l'ISO. C'est recommandé à partir de l'ASIL B et obligatoire pour les ASIL C et D. L'évaluation de la sécurité fonctionnelle étant l'une des mesures de confirmation, il existe également un niveau d'indépendance requis en fonction de l'ASIL.

• Pour QM et ASIL A, il n'y a pas de recommandation pour ou contre la réalisation de l'évaluation.
• L'ASIL B exige une indépendance I0, l'évaluation doit donc être réalisée par une personne différente qui n'est pas impliquée dans le projet et la création du produit de travail.
• L'ASIL C exige une indépendance I2, et l'évaluation doit ensuite être réalisée par une personne indépendante de l'équipe responsable de la création du produit de travail.
• L'ASIL D exige une indépendance I3, ce qui signifie que l'évaluation doit être réalisée par une personne indépendante, sur le plan de la gestion et des ressources, du département responsable de la création du produit de travail, ce qui pourrait être, par exemple, une entreprise externe.

La prochaine chose à déterminer est le calendrier de développement du projet. L'évaluation doit être réalisée et finalisée en général avant le début de la production. La bonne pratique et la recommandation de l'ISO consistent à planifier l'évaluation au début du développement du produit au niveau système et à la réaliser progressivement pendant le développement, par exemple pour chaque phase du projet comme les échantillons de conception ou de validation du produit.

Une autre question importante est :Qui doit planifier l'évaluation ?En d'autres termes, qui est responsable de toutes les activités liées à la préparation et à l'organisation de l'évaluation ? Il s'agit généralement d'un Functional Safety Manager ou d'une personne responsable d'un plan de sécurité où tous les produits de travail et activités pertinents pour la sécurité sont planifiés. Cette personne doit également préparer toutes les équipes impliquées dans le développement du produit afin de les sensibiliser à ce qui est requis pour l'évaluation de la sécurité fonctionnelle et de les familiariser avec le processus d'évaluation.

La question suivante est :Qui peut réaliser l'évaluation ?Cette question a déjà été partiellement traitée précédemment dans la partie relative au niveau d'indépendance des évaluateurs. Pour réaliser une évaluation de la sécurité fonctionnelle, au moins une personne doit être désignée. L'évaluateur de sécurité fonctionnelle peut nommer un ou plusieurs assistants pour le soutenir dans les activités d'évaluation. Leur indépendance est également définie et doit être au minimum de niveau I1 par rapport aux développeurs. De plus, les évaluateurs doivent disposer de l'autorité nécessaire pour réaliser l'évaluation, y compris : le périmètre de l'évaluation, les informations à mettre à disposition et le soutien nécessaire de la part des personnes responsables de produits de travail spécifiques.

Périmètre de l'évaluation

Le périmètre d'une évaluation de la sécurité fonctionnelle doit inclure :

• Le plan de sécurité et tous les produits de travail requis – le niveau de détail peut être adapté par un évaluateur ; ici également, la gestion des exigences de sécurité fonctionnelle, y compris la traçabilité bidirectionnelle, peut être vérifiée.
• Évaluation du processus de sécurité fonctionnelle.
• L'efficacité des mesures de sécurité mises en œuvre.
• Les arguments des personnes responsables des produits de travail justifiant l'atteinte de la sécurité fonctionnelle.
• Dossier de sécurité.
• La justification des anomalies de sécurité, le cas échéant.

L'évaluation doit également prendre en compte la planification et les résultats des autres mesures de confirmation applicables au projet, y compris l'audit de sécurité fonctionnelle, les recommandations et les actions correctives issues des évaluations précédemment réalisées, par exemple pour un jalon antérieur du projet, ainsi que les résultats des activités d'évaluation concernant les produits de travail développés par les fournisseurs.

Un exemple d'agenda de sécurité fonctionnelle figure dans l'ISO26262-8 ANNEXE D.

Le résultat de l'évaluation

À l'issue de l'évaluation de la sécurité fonctionnelle, le rapport, incluant le résultat de l'évaluation (accepté, accepté sous conditions ou rejeté), doit être créé. Le rapport peut également inclure une recommandation d'acceptation conditionnelle. Dans ce cas, les conditions d'acceptation doivent également être définies. Si la recommandation figurant dans un rapport d'évaluation de la sécurité fonctionnelle est rejetée, des actions correctives appropriées (qui peuvent également faire partie du rapport) doivent être planifiées et exécutées, puis l'évaluation de la sécurité fonctionnelle doit être répétée.

En résumé, comme dans la plupart des aspects automobiles, un bon plan est la clé du succès. Il en va de même pour l'évaluation de la sécurité fonctionnelle. Lorsqu'elle est réalisée pour chaque phase de développement ou jalon du projet, les risques potentiels et les lacunes peuvent être détectés et corrigés dès les tout premiers stades du projet. Elle peut également nous aider à assurer une gestion appropriée de la sécurité fonctionnelle au sein du projet en identifiant les risques et en définissant des recommandations pour les actions correctives, car l'évaluation est généralement réalisée par des personnes expérimentées dans les processus d'ingénierie et/ou liés à l'ISO. C'est comme faire d'une pierre deux coups : d'une part, nous accomplissons une activité requise par l'ISO 26262, et d'autre part, nous disposons d'un outil pour identifier et résoudre les incompatibilités potentielles.

Qualification d'outils ISO 26262

La qualification des outils est essentielle pour atteindre la conformité avec l'ISO 26262. Son objectif est de garantir que tous les outils utilisés dans le projet sont fiables, que tout dysfonctionnement est identifié et que tout problème survenant peut être traité. Il est important de prendre en considération tous les outils impliqués dans le processus de développement, y compris ceux utilisés indirectement.

Comment qualifier les outils logiciels selon l'ISO 26262 ?

L'objectif de la qualification d'outil est de fournir la preuve qu'un outil logiciel est adapté à une utilisation dans le développement de logiciels liés à la sécurité conformément à la norme ISO26262. L'article 11 de la Partie 8 comprend des méthodes et des guides qui facilitent la qualification d'outil. Néanmoins, il est nécessaire de déterminer si l'outil a besoin d'être qualifié ou non. La réponse à cette question dépend fortement du cas d'usage, du périmètre du projet et du contexte.

Identifier l'outil

L'utilisation d'outils logiciels peut simplifier ou automatiser les activités et les tâches essentielles au développement de logiciels liés à la sécurité. L'un des objectifs du processus de qualification est de démontrer une conscience et une connaissance approfondie de l'outil concerné. La première étape pour atteindre cet objectif consiste à identifier correctement les caractéristiques de l'outil. À ce stade, il est nécessaire de fournir des informations telles que le numéro de version, le fournisseur, la calibration ou la configuration. Il est de bonne pratique de vérifier le journal officiel des vulnérabilités créé par le fournisseur de l'outil et de comparer la manière dont les faiblesses de l'outil donné affectent le cas d'usage dans le projet lié à la sécurité.

Évaluer les risques

Les facteurs TCL (Tool Confidence Level) sont classés de TCL1 à TCL3. Le TCL1 signifie que pour les étapes suivantes, les méthodes de qualification ne sont pas nécessairement applicables, de sorte que la qualification elle-même n'est pas requise. Pour les TCL 2 et TCL 3, on suppose que le comportement de l'outil n'est pas entièrement prévisible et que certaines méthodes de qualification doivent être appliquées. Le Tool Confidence Level résulte de la combinaison du Tool Impact (TI) et du Tool Error Detection (TD).

Tool Impact – est un coefficient permettant de déterminer si l'outil peut introduire ou ne pas détecter des erreurs susceptibles d'affecter les fonctionnalités liées à la sécurité du produit final. Si une violation d'une exigence de sécurité n'est pas possible, il convient de choisir « TI 1 ». Dans le cas contraire, l'impact de l'outil est « TI 2 ».

T est divisé en trois niveaux. Sélectionnez « TD1 » lorsque le propriétaire de l'outil a une confiance élevée que l'utilisation de l'outil n'est pas impliquée dans des activités liées à la sécurité, ou que son utilisation ne peut pas affecter la sécurité du produit. Le « TD2 » est un coefficient intermédiaire ; il doit être retenu lorsque le niveau de confiance n'est pas suffisamment élevé pour affirmer que la robustesse et la fiabilité de l'outil ne peuvent pas introduire de risque inacceptable, même si une fonction de protection pourrait être en place. Le dernier niveau est « TD3 » ; il représente la situation inverse du cas « TD1 », et doit donc être choisi si l'outil présente un faible niveau de confiance quant à son comportement approprié dans toute situation requise liée à la sécurité.

Il convient de rappeler que dans de nombreux cas, le choix entre des qualités spécifiques est fortement subjectif et qu'il est très souvent difficile, voire impossible, de parvenir à une réponse sans ambiguïté. Toutefois, le résultat final repose sur des connaissances et une expérience spécialisées.

Qualifier l'outil

L'ISO 26262 détermine quatre méthodes pouvant être appliquées lors de la qualification des outils. Si le résultat global de l'évaluation est « TCL2 » ou « TCL3 », les méthodes sont les mêmes, mais la recommandation d'utilisation par rapport au niveau ASIL est différente. Le tableau ci-dessous répertorie les combinaisons possibles de ces facteurs.

La première méthode de la liste est la « Confiance Accrue Issue de l'Utilisation ». La confiance provient de l'utilisation antérieure de l'outil dans un environnement de développement et des cas d'usage similaires. Mais dans de nouveaux projets, la chaîne d'outils et les versions des outils peuvent changer, donc même si les cas d'usage sont identiques, la « Confiance Accrue Issue de l'Utilisation » peut être difficile à appliquer.

« L'évaluation du processus de développement » est la méthode qui exige une analyse détaillée du processus de développement de l'outil. Parfois, le fournisseur de l'outil fournit ces preuves de qualification avec l'outil.

La méthode « Validation de l'outil logiciel » est recommandée pour une conformité ASIL élevée, comme ASIL C ou D. Elle repose essentiellement sur le développement de tests couvrant tous les cas d'usage liés à la sécurité de l'outil logiciel. Selon l'ISO 26262-8, elle peut également être fournie par le fournisseur de l'outil.

La dernière méthode, « Développement conformément à une norme de sécurité », est malheureusement pour la plupart inapplicable. L'environnement de développement de logiciels embarqués est essentiellement basé sur PC, de sorte que les outils logiciels ne sont généralement pas conçus pour être utilisés conformément à une norme de sécurité.