ISO 26262 : securite fonctionnelle automobile
Guide · ISO 26262
ISO 26262 est la norme internationale horizontale de securite fonctionnelle (Functional Safety, FuSa) appliquee aux systemes electriques et electroniques des vehicules routiers. Publiee initialement en 2011 et revisee en 2018 (2e edition), elle est aujourd'hui la reference unanimement utilisee par les constructeurs automobiles (OEM) et leurs equipementiers (Tier 1, Tier 2) pour structurer la maitrise des dysfonctionnements electroniques susceptibles d'entrainer des situations dangereuses. Cette page expose la genese de la norme, son articulation avec la norme generique mere IEC 61508 et avec ses normes soeurs (SOTIF ISO 21448, cybersecurite ISO/SAE 21434), la structure en douze parties, le mecanisme de classification ASIL, le cycle de vie de securite, la notion de Safety Element out of Context, et les mesures de confirmation requises.
Une derivee sectorielle d'IEC 61508
Section intitulée « Une derivee sectorielle d'IEC 61508 »ISO 26262 n'est pas un texte isole. Elle est l'une des principales derivees sectorielles d'IEC 61508 (Functional safety of electrical/electronic/programmable electronic safety-related systems), la norme generique de securite fonctionnelle publiee par la CEI. IEC 61508 fournit le cadre conceptuel commun (SIL, lifecycle, separation defaillances aleatoires / systematiques), et chaque secteur en derive sa norme adaptee : ISO 26262 pour l'automobile, IEC 61511 pour les industries de procede, EN 50128 / EN 50657 pour le ferroviaire embarque, DO-178C pour le logiciel d'aviation civile (sous l'angle de l'autorite FAA / EASA), IEC 62061 pour la machine.
Le passage de la base generique IEC 61508 a la version automobile ISO 26262 traduit plusieurs adaptations propres au secteur :
- une echelle de risque specifique (ASIL A a D) calibree sur les scenarios vehicule, et non sur la frequence et la probabilite d'erreur typiques de l'industrie de procede,
- l'introduction explicite de la HARA comme entree obligatoire du concept de securite, alors qu'IEC 61508 reste plus abstraite sur la methode d'analyse de risque amont,
- la prise en compte structurelle de la chaine d'approvisionnement automobile, OEM, Tier 1, Tier 2, avec des livrables d'interface formalises (Hardware-Software Interface, Development Interface Agreement, Safety Manual),
- la reconnaissance des defaillances aleatoires permanentes et transitoires des semi-conducteurs comme un sujet de premier plan, ce qui a justifie la publication d'une Partie 11 dediee aux semi-conducteurs en 2018,
- une prise en compte du logiciel embarque plus integree, complementaire mais pas redondante avec d'autres normes logiciel.
La 1re edition de 2011 couvrait les voitures particulieres et les vehicules legers jusqu'a 3,5 tonnes. La 2e edition de 2018 a etendu le perimetre aux camions, bus et autocars, et ajoute une Partie 12 specifique aux motos. La 2e edition est aujourd'hui la reference unique.
Les douze parties d'ISO 26262
Section intitulée « Les douze parties d'ISO 26262 »ISO 26262 est decoupee en douze parties publiees ensemble, chacune ciblant un perimetre du cycle de vie ou un type d'analyse. Le numero de partie est explicite dans les references croisees au sein du dossier de securite.
| Partie | Titre | Contenu indicatif |
|---|---|---|
| Part 1 | Vocabulary | Vocabulaire, definitions, acronymes ; base terminologique commune (ASIL, item, element, fault, error, failure, HARA, FSC, TSC, SEooC, etc.) |
| Part 2 | Management of functional safety | Gestion de la securite a l'echelle de l'organisation et du projet ; roles (Functional Safety Manager, Functional Safety Assessor), Safety Culture, planification, livrables, mesures de confirmation |
| Part 3 | Concept phase | Definition de l'item (item definition), Hazard Analysis and Risk Assessment (HARA), Safety Goals, Functional Safety Concept (FSC) |
| Part 4 | System level | Specification de la securite au niveau systeme, Technical Safety Concept (TSC), exigences techniques de securite, integration et essais systeme, validation par rapport aux Safety Goals |
| Part 5 | Hardware level | Exigences materielles, analyse quantitative des defaillances aleatoires (PMHF, SPFM, LFM), Hardware Safety Requirements, integration et essais materiel |
| Part 6 | Software level | Exigences logicielles, architecture logicielle, conception, verification, integration et essais logiciel ; tables de techniques recommandees par ASIL |
| Part 7 | Production, operation, service and decommissioning | Production en serie sous controle de securite, maintenance, mise hors service ; lien avec IATF 16949 (qualite) |
| Part 8 | Supporting processes | Processus transverses, gestion des exigences, configuration, modification, documentation, qualification d'outils logiciel (Tool Confidence Level), qualification de composants logiciel et materiel, criteres d'integration de composants prequalifies |
| Part 9 | Automotive safety integrity level (ASIL)-oriented and safety-oriented analyses | Decomposition d'ASIL, analyse des defaillances de cause commune et des dependances, criteres de coexistence d'elements de criticite differente sur un meme calculateur |
| Part 10 | Guideline on ISO 26262 | Lignes directrices, exemples d'application, notamment cadre du Safety Element out of Context (SEooC) |
| Part 11 | Guidelines on application of ISO 26262 to semiconductors | Guide specifique aux semi-conducteurs, ajoute dans la 2e edition pour adresser la specificite des SoC, MCU, ASIC, dont le mode de defaillance et la chaine de fourniture different fortement du materiel discret |
| Part 12 | Adaptation of ISO 26262 for motorcycles | Adaptation aux motos (ASIL motos, scenarios de risque, exigences allegees ou specifiques), ajoutee dans la 2e edition |
Les Parties 3 a 7 forment la colonne vertebrale du cycle en V de securite. La Partie 8 contient des chapitres transverses tres frequemment cites (qualification des outils, qualification des composants prequalifies). Les Parties 9 a 12 sont des annexes thematiques.
La classification ASIL (S, E, C)
Section intitulée « La classification ASIL (S, E, C) »ASIL designe Automotive Safety Integrity Level. Quatre niveaux croissants sont definis (A, B, C, D), plus une categorie QM (Quality Managed) pour les scenarios qui n'imposent pas d'exigence de securite fonctionnelle au sens de la norme et restent geres au titre de la qualite (IATF 16949).
Le niveau ASIL d'un Safety Goal resulte du croisement, au sein de la HARA, de trois parametres independants.
| Parametre | Sigles | Interpretation |
|---|---|---|
| Severite | S0, S1, S2, S3 | Severite des consequences potentielles, des aucune lesion (S0) a des lesions vitales mortelles ou critiques (S3) |
| Exposition | E0, E1, E2, E3, E4 | Probabilite que le scenario operationnel se presente, de incredible (E0) a tres frequent (E4) |
| Controlabilite | C0, C1, C2, C3 | Capacite du conducteur (ou d'un tiers concerne) a controler la situation dangereuse et eviter le dommage, de tres controlable (C0) a difficile a controler (C3) |
Le croisement est tabule dans la Partie 3, annexe ASIL determination table. Les combinaisons donnant un risque tres faible aboutissent a QM ; les combinaisons cumulant severite, exposition et faible controlabilite aboutissent a ASIL D.
| Severite | Exposition | C1 | C2 | C3 |
|---|---|---|---|---|
| S1 | E1 | QM | QM | QM |
| S1 | E2 | QM | QM | QM |
| S1 | E3 | QM | QM | A |
| S1 | E4 | QM | A | B |
| S2 | E1 | QM | QM | QM |
| S2 | E2 | QM | QM | A |
| S2 | E3 | QM | A | B |
| S2 | E4 | A | B | C |
| S3 | E1 | QM | QM | A |
| S3 | E2 | QM | A | B |
| S3 | E3 | A | B | C |
| S3 | E4 | B | C | D |
Cette table de la Partie 3 est, en pratique, le passage le plus repete d'ISO 26262 dans la litterature pedagogique. Elle merite d'etre lue avec deux precautions : (1) les classes S, E, C sont des classes definies par la norme, leur attribution s'appuie sur des exemples normatifs mais reste sujette a interpretation et doit etre justifiee documentairement ; (2) la cotation se fait par scenario, pas par item global, un meme item pouvant porter des Safety Goals d'ASIL differents selon les dangers analyses.
La decomposition d'ASIL
Section intitulée « La decomposition d'ASIL »La Partie 9 introduit le mecanisme de decomposition d'ASIL. Un exigence de niveau eleve peut etre derivee en deux exigences de niveau inferieur portees par des elements suffisamment independants, par redondance et separation de cause commune. Les decompositions admises sont notees sous la forme ASIL X (Y) avec, par exemple :
- ASIL D peut etre decompose en ASIL B (D) + ASIL B (D), ou en ASIL C (D) + ASIL A (D), ou en ASIL D (D) + ASIL QM (D),
- ASIL C peut etre decompose en ASIL B (C) + ASIL A (C), ou en ASIL C (C) + QM (C),
- et ainsi de suite jusqu'au niveau ASIL A.
La decomposition n'est pas une diminution gratuite de la rigueur. Elle est conditionnee a une demonstration formelle d'independance entre les elements decomposants (absence de defaillances de cause commune, separation physique et logique, qualification independante). En pratique, la decomposition est utilisee pour rendre realiste la conception d'un Safety Goal ASIL D en s'appuyant sur deux canaux ASIL B independants, par exemple un canal de commande et un canal de surveillance.
Le cycle de vie de securite
Section intitulée « Le cycle de vie de securite »ISO 26262 organise le cycle de vie produit en phases formellement enchainees. La structure est conforme au cycle en V utilise dans la plupart des normes de securite fonctionnelle. Le sequencement type, simplifie ici, comporte les etapes suivantes.
- Definition de l'item (Item Definition, Partie 3). Description fonctionnelle, frontieres, interfaces, environnement operationnel, hypotheses d'usage.
- HARA (Partie 3). Identification des dangers, scenarios, cotation S/E/C, derivation des Safety Goals et de leur ASIL.
- Functional Safety Concept (FSC, Partie 3). Strategie de securite au niveau fonctionnel, derivation des Functional Safety Requirements (FSR), allocation aux elements (calculateurs, capteurs, actionneurs).
- Technical Safety Concept (TSC, Partie 4). Specification technique des exigences de securite (TSR), architecture systeme, allocation materielle et logicielle, definition de la Hardware-Software Interface (HSI agreement).
- Developpement materiel (Partie 5). Conception, analyse quantitative des defaillances aleatoires (calcul PMHF, metriques SPFM et LFM), verification, integration materiel.
- Developpement logiciel (Partie 6). Specification, architecture, conception detaillee, codage, verification et integration logiciel ; choix des techniques en fonction de l'ASIL.
- Integration systeme (Partie 4). Integration progressive, verification de la conformite aux TSR et FSR, essais de validation au niveau systeme.
- Validation au niveau item (Partie 4). Demonstration que les Safety Goals sont respectes dans l'environnement vehicule cible.
- Production et exploitation (Partie 7). Lancement serie sous controle de securite ; coordination avec le systeme qualite IATF 16949.
- Maintenance, modification, retrait (Partie 7 et Partie 8). Gestion des modifications, releases logicielles, retrait controle.
Chaque phase produit des work products (livrables) explicitement nommes par la norme. Le dossier de securite (Safety Case) consolide l'ensemble des work products et la chaine d'arguments demontrant que le risque residuel est acceptable. Le Safety Case n'est pas un document final ajoute en bout de chaine, il est construit en parallele tout au long du projet.
Safety Element out of Context (SEooC)
Section intitulée « Safety Element out of Context (SEooC) »Le concept de SEooC (Safety Element out of Context) est decrit en Partie 10. Il repond a une realite economique du secteur : un fournisseur de semi-conducteur ou d'un RTOS ne developpe pas son composant pour un projet vehicule precis, mais pour un marche. Il ne peut donc pas, par construction, suivre la HARA d'un item dont il ignore les details.
La Partie 10 organise le mecanisme suivant :
- le fournisseur formule des hypotheses sur l'usage cible (Assumed Use Case) et un ASIL vise (par exemple un MCU SEooC ASIL B ou ASIL D),
- il developpe l'element en suivant les exigences correspondantes des Parties 4, 5 et 6 sous ces hypotheses,
- il fournit un Safety Manual decrivant les hypotheses, les mecanismes de securite implementes, les contraintes d'integration, les diagnostics couverts, les metriques materielles obtenues,
- l'integrateur (typiquement le Tier 1 qui livre un calculateur a l'OEM) verifie au moment de l'integration que les hypotheses du SEooC restent valides pour l'item reel et derive ses propres exigences de securite a partir du Safety Manual.
Le mecanisme SEooC est aujourd'hui un standard de fait pour les MCU, SoC et bibliotheques logicielles certifiees du marche automobile. Sa correcte utilisation suppose une lecture attentive du Safety Manual, en particulier des assumptions et des conditions d'usage, dont la violation invalide l'argument de securite.
ISO 26262 face a ses normes soeurs
Section intitulée « ISO 26262 face a ses normes soeurs »Plusieurs normes voisines, frequemment citees ensemble, doivent etre distinguees pour eviter les confusions.
| Norme | Champ | Articulation avec ISO 26262 |
|---|---|---|
| IEC 61508 | Securite fonctionnelle generique (SIL 1 a 4) | Norme mere generique ; ISO 26262 en est la derivee automobile. Le mapping ASIL / SIL n'est pas mathematique, doit etre justifie projet par projet. |
| ISO 21448 | SOTIF, Safety Of The Intended Functionality | Norme soeur, traite des limitations de la fonction prevue (limites des capteurs, cas non prevus en conception) ; cible en particulier les ADAS et la conduite automatisee. Complementaire et non redondante. |
| ISO/SAE 21434 | Cybersecurite vehicule | Norme soeur, traite de la cybersecurite vehicule. Alimente la conformite UN-ECE R155 et R156. Necessite une coordination explicite avec l'equipe FuSa lorsque la menace cyber peut entrainer une consequence de securite. |
| IATF 16949 | Qualite, automobile | Systeme de management qualite specifique automobile (derive d'ISO 9001). ISO 26262 et IATF 16949 sont complementaires : la qualite cible la conformite repetable, la securite fonctionnelle cible la maitrise du risque. La Partie 7 d'ISO 26262 fait le lien avec la production serie. |
A ces normes s'ajoutent les reglements UN-ECE (sous l'egide du Forum WP.29 de la CEE-ONU), juridiquement contraignants en homologation, en particulier :
- R155 sur la gestion de la cybersecurite vehicule (CSMS),
- R156 sur la gestion des mises a jour logicielles (SUMS),
- l'ensemble R157 sur les systemes ALKS (Automated Lane Keeping Systems).
Cote Union europeenne, le reglement (UE) 2019/2144 (General Safety Regulation, GSR) impose un ensemble de fonctions de securite obligatoires sur les nouveaux vehicules immatricules dans l'UE (assistance intelligente a la vitesse, freinage d'urgence autonome, surveillance d'angle mort, etc.), dont la conception sous-jacente releve typiquement d'ISO 26262. Le GSR ne cite pas ISO 26262 comme norme harmonisee au sens du marquage CE, le cadre d'homologation des vehicules reposant sur le reglement type-approval (UE) 2018/858 et sur les reglements UN-ECE plutot que sur le mecanisme de marquage CE.
La chaine d'approvisionnement automobile
Section intitulée « La chaine d'approvisionnement automobile »ISO 26262 reconnait formellement l'organisation industrielle du secteur, structuree en trois niveaux principaux. Cette structure conditionne la distribution des livrables.
- L'OEM (constructeur vehicule) porte la responsabilite globale du vehicule et de l'item integre. Il realise la HARA et fixe les Safety Goals et ASIL. Il peut sous-traiter l'item, integre les livraisons et porte le Safety Case final.
- Le Tier 1 (equipementier de rang 1) recoit du OEM les Safety Goals et les Functional Safety Requirements, et livre un sous-systeme ou un calculateur complet (ECU). Il porte le Technical Safety Concept et derive les exigences vers ses fournisseurs.
- Le Tier 2 (composant) livre typiquement un semi-conducteur, un RTOS, un bibliotheque logicielle, generalement sous forme de SEooC. Il livre un Safety Manual et les metriques associees.
Plusieurs livrables d'interface formalisent les echanges entre niveaux, dont les principaux sont :
- le Development Interface Agreement (DIA) qui repartit responsabilites et activites entre les parties,
- la HSI Agreement (Hardware-Software Interface) qui fige le contrat entre l'equipe hardware et l'equipe software d'un meme element,
- le Safety Manual du SEooC, comme decrit plus haut.
Sur des programmes recents, l'OEM developpe parfois son propre calculateur (in-house), ce qui efface temporairement la separation OEM / Tier 1 sans annuler la logique de DIA, formalisee alors entre equipes internes.
Les mesures de confirmation
Section intitulée « Les mesures de confirmation »La Partie 2 d'ISO 26262 definit trois mesures de confirmation cumulatives, dont l'application est exigee a partir de certains ASIL et selon des niveaux d'independance graduellement renforces (I0, I1, I2, I3).
- Confirmation Review. Revue de confirmation d'un livrable specifique (HARA, FSC, TSC, etc.) par une personne qualifiee independante de l'auteur. L'objectif est de verifier que le livrable satisfait son intention et les exigences de la norme. L'independance attendue varie selon l'ASIL : pour ASIL D, l'organisation requiert une independance organisationnelle (I3).
- Functional Safety Audit. Audit de l'application effective des processus de securite definis dans le Safety Plan. L'audit verifie le "comment on fait", pas le "ce qu'on a fait". Realise par un auditeur independant du projet.
- Functional Safety Assessment (FSA). Evaluation globale du caractere suffisant de la demonstration de securite, generalement en fin de phase ou de programme. Le Functional Safety Assessor (assesseur de securite fonctionnelle) est independant du projet et porte un jugement motive sur le Safety Case complet. Pour ASIL D, l'independance attendue est I3, c'est-a-dire une independance organisationnelle complete.
Ces trois mesures sont distinctes mais articulees. Une non-conformite identifiee lors d'une Confirmation Review se traite en local ; une non-conformite recurrente identifiee lors d'un audit peut declencher une remediation processus ; un FSA negatif en fin de programme empeche la liberation pour production serie.
Couplages avec d'autres pages
Section intitulée « Couplages avec d'autres pages »ISO 26262 ne se substitue pas au cadre reglementaire general. Plusieurs articulations sont pertinentes :
- pour le cadre du marquage CE des produits electroniques non-vehicule (radio, EMC, cyber), voir la page CE ;
- pour le calendrier projet et la combinaison des etapes de certification, voir le calendrier de certification ;
- pour le glossaire complet des termes utilises (ASIL, HARA, SEooC, Safety Goal, FSC, TSC, FSA), voir le glossaire.
Voir aussi
Section intitulée « Voir aussi »- Recharge VE : conformite IEC 61851, ISO 15118 et OCPP
- EN 50128 et EN 50657 : logiciel ferroviaire
- DO-178C et DO-254 : logiciel + materiel avionique
- DO-326A et ED-202A: cybersecurite avionique
Quelques ecueils observes
Section intitulée « Quelques ecueils observes »Sans constituer un guide d'implementation, plusieurs erreurs reviennent dans les retours de programmes :
- Confondre ASIL et SIL. Le mapping IEC 61508 / ISO 26262 n'est pas mathematique. Importer un composant "SIL 2" d'un projet industriel et le considerer ASIL B sans analyse de transfert est une approximation risquee.
- HARA decoree. La HARA n'est pas un livrable de conformite, elle est l'entree du concept. Une HARA realisee en fin de projet pour caler les ASIL sur la conception deja figee est l'erreur amont la plus courante.
- SEooC mal integre. Reutiliser un MCU SEooC ASIL D sans relire le Safety Manual ni verifier la validite des assumptions d'usage est une cause frequente de non-conformite a l'integration. Le Safety Manual fait partie du dossier de securite de l'integrateur.
- Decomposition d'ASIL sans demonstration d'independance. Une decomposition n'est valable que si l'independance des elements est demontree (separation physique, separation logique, absence de cause commune). Une decomposition revendiquee sans demonstration ne sera pas acceptee par un FSA serieux.
- Confusion FuSa / SOTIF. Une limite capteur en conditions degradees (brouillard, contre-jour) n'est pas un dysfonctionnement au sens d'ISO 26262. Elle releve d'ISO 21448 (SOTIF). Tenter d'encoder un cas SOTIF en Safety Goal ISO 26262 conduit a des resultats qui ne tiennent pas.
- Confusion FuSa / cybersecurite. Une menace cyber qui peut entrainer une consequence de securite doit etre traitee a la fois sous ISO/SAE 21434 (perimetre menace, ETS, traitement du risque cyber) et sous ISO 26262 (consequence de securite, Safety Goal). La coordination entre les deux equipes est explicitement attendue par les deux normes.
- Confusion FuSa / qualite (IATF 16949). La conformite qualite ne dispense pas de la securite fonctionnelle, et inversement. Les deux systemes coexistent et se referencent mutuellement (Partie 7 d'ISO 26262, lien avec IATF 16949).
Pour aller plus loin
Section intitulée « Pour aller plus loin »Cette page expose le cadre general d'ISO 26262. Plusieurs sujets meritent des pages dediees :
- la HARA pas a pas, avec exemples de cotation S/E/C documentes,
- la metrique materielle ASIL (PMHF, SPFM, LFM) et son calcul concret,
- ISO 21448 (SOTIF) et son articulation avec les ADAS et la conduite automatisee,
- ISO/SAE 21434 et les reglements UN-ECE R155 / R156, sous l'angle de l'homologation,
- la qualification d'outils logiciel (Tool Confidence Level) au sens de la Partie 8.
Sources & références
- ISO 26262:2018, Road vehicles, Functional safety , ISO www.iso.org/standard/68383.html
- ISO 21448:2022, Road vehicles, Safety of the intended functionality , ISO www.iso.org/standard/77490.html
- ISO/SAE 21434:2021, Road vehicles, Cybersecurity engineering , ISO www.iso.org/standard/70918.html
- UN-ECE WP.29, vehicle regulations including R155 and R156 , UNECE unece.org/transport/vehicle-regulations
- Reglement (UE) 2019/2144 (General Safety Regulation, GSR) , EUR-Lex eur-lex.europa.eu/eli/reg/2019/2144/oj
- IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related systems , IEC webstore.iec.ch/publication/22273