DO-178B - DO-178B

Considérations logicielles dans la certification des systèmes et équipements aéroportés
Dernière version 1er décembre 1992 ; il y a 28 ans ( 1992-12-01 )
Organisation
Domaine Aviation
Abréviation

DO-178B, Software Considerations in Airborne Systems and Equipment Certification est une directive traitant de la sécurité des logiciels critiques pour la sécurité utilisés dans certains systèmes aéroportés. Il a été développé conjointement par le groupe de travail critique pour la sécurité RTCA SC-167 de la Commission technique radio pour l'aéronautique (RTCA) et le WG-12 de l' Organisation européenne pour l'équipement de l'aviation civile (EUROCAE). RTCA a publié le document sous le nom RTCA/DO-178B , tandis qu'EUROCAE a publié le document sous le nom ED-12B . Bien que techniquement une ligne directrice, il s'agissait d'une norme de facto pour le développement de systèmes logiciels avioniques jusqu'à son remplacement en 2012 par le DO-178C .

La Federal Aviation Administration (FAA) applique le DO-178B comme document qu'elle utilise comme guide pour déterminer si le logiciel fonctionnera de manière fiable dans un environnement aéroporté, lorsque spécifié par le Technical Standard Order (TSO) pour lequel la certification est demandée. Aux États-Unis, l'introduction des TSO dans le processus de certification de navigabilité, et par extension DO-178B, est explicitement établie dans le Titre 14 : Aeronautics and Space du Code of Federal Regulations (CFR), également connu sous le nom de Federal Aviation Regulations , Partie 21, sous-partie O.

Niveau logiciel

Le niveau de logiciel , également appelé niveau d'assurance de conception (DAL) ou niveau d'assurance de développement d'articles (IDAL) tel que défini dans ARP4754 ( DO-178C ne mentionne IDAL que comme synonyme de niveau de logiciel), est déterminé à partir du processus d'évaluation de la sécurité et de l' analyse des risques par examiner les effets d'une condition de défaillance dans le système. Les conditions de défaillance sont classées en fonction de leurs effets sur l'avion, l'équipage et les passagers.

  • Catastrophique – Une panne peut provoquer un crash. Erreur ou perte d'une fonction critique requise pour voler et atterrir en toute sécurité.
  • Dangereux - Une panne a un impact négatif important sur la sécurité ou les performances, ou réduit la capacité de l'équipage à piloter l'avion en raison d'une détresse physique ou d'une charge de travail plus élevée, ou provoque des blessures graves ou mortelles parmi les passagers. (important pour la sécurité)
  • Majeure - La défaillance est importante, mais a un impact moindre qu'une défaillance dangereuse (par exemple, entraîne une gêne pour les passagers plutôt que des blessures) ou augmente considérablement la charge de travail de l'équipage (liée à la sécurité)
  • Mineur - La défaillance est perceptible, mais a un impact moindre qu'une défaillance majeure (par exemple, causant des désagréments aux passagers ou un changement de plan de vol de routine)
  • Aucun effet – La panne n'a aucun impact sur la sécurité, l'exploitation de l'aéronef ou la charge de travail de l'équipage.

DO-178B seul n'est pas destiné à garantir les aspects de sécurité du logiciel. Les attributs de sécurité dans la conception et mis en œuvre en tant que fonctionnalité doivent recevoir des tâches de sécurité du système obligatoires supplémentaires pour conduire et montrer des preuves objectives du respect des exigences de sécurité explicites. En règle générale, les plans de sécurité du logiciel IEEE STD-1228-1994 sont alloués et les tâches d'analyse de la sécurité du logiciel sont accomplies par étapes séquentielles (analyse des exigences, analyse de la conception de haut niveau, analyse de la conception détaillée, analyse au niveau du code, analyse des tests et analyse des modifications). Ces tâches et artefacts de sécurité logicielle font partie intégrante du processus de détermination de la gravité des dangers et de la DAL à documenter dans les évaluations de la sécurité du système (SSA). Les autorités de certification exigent et DO-178B spécifie que la DAL correcte doit être établie à l'aide de ces méthodes d'analyse complètes pour établir le niveau logiciel AE. Tout logiciel qui commande, contrôle et surveille les fonctions critiques pour la sécurité doit recevoir le DAL le plus élevé - Niveau A. Ce sont les analyses de sécurité du logiciel qui conduisent les évaluations de sécurité du système qui déterminent le DAL qui conduit au niveau de rigueur approprié dans DO-178B. Les évaluations de la sécurité du système combinées à des méthodes telles que SAE ARP 4754A déterminent le DAL après atténuation et peuvent permettre de réduire les objectifs de niveau logiciel DO-178B à satisfaire si la redondance, les caractéristiques de sécurité de conception et d'autres formes architecturales d'atténuation des risques sont dans les exigences entraînées par les analyses de sécurité. Par conséquent, le thème central du DO-178B est l'assurance et la vérification de la conception une fois que les exigences de sécurité préalables ont été établies.

Le nombre d'objectifs à satisfaire (éventuellement avec indépendance) est déterminé par le niveau logiciel AE. L'expression « avec indépendance » fait référence à une séparation des responsabilités où l'objectivité des processus de vérification et de validation est assurée en vertu de leur « indépendance » vis-à-vis de l'équipe de développement logiciel. Pour les objectifs qui doivent être satisfaits avec indépendance, la personne vérifiant l'élément (comme une exigence ou un code source) peut ne pas être la personne qui a créé l'élément et cette séparation doit être clairement documentée. Dans certains cas, un outil automatisé peut être équivalent à l'indépendance. Cependant, l'outil lui-même doit alors être qualifié s'il se substitue à l'examen humain.

Niveau Condition de défaillance Objectifs Avec indépendance Taux d'échec
UNE Catastrophique 66 25 10 -9 /h
B Hasardeux 65 14 10 -7 /h
C Majeur 57 2 10 -5 /h
ré Mineur 28 2 10 -3 /h
E Aucun effet 0 0 n / A

Processus et documents

Les processus sont destinés à soutenir les objectifs, selon le niveau de logiciel (A à D—Le niveau E n'était pas du ressort de DO-178B). Les processus sont décrits comme des domaines de travail abstraits dans DO-178B, et il appartient aux planificateurs d'un projet réel de définir et de documenter les détails de la manière dont un processus sera exécuté. Sur un projet réel, les activités réelles qui seront réalisées dans le cadre d'un processus doivent être démontrées pour soutenir les objectifs. Ces activités sont définies par les planificateurs du projet dans le cadre du processus de planification.

Cette nature basée sur les objectifs du DO-178B permet une grande flexibilité en ce qui concerne le suivi des différents styles de cycle de vie du logiciel . Une fois qu'une activité dans un processus a été définie, on s'attend généralement à ce que le projet respecte cette activité documentée dans son processus. De plus, les processus (et leurs activités concrètes) doivent avoir des critères d'entrée et de sortie bien définis, selon DO-178B, et un projet doit montrer qu'il respecte ces critères lorsqu'il exécute les activités du processus.

La nature flexible des processus et des critères d'entrée/sortie du DO-178B le rend difficile à mettre en œuvre la première fois, car ces aspects sont abstraits et il n'y a pas d'« ensemble de base » d'activités à partir duquel travailler. L'intention de DO-178B n'était pas d'être prescriptif. Il existe de nombreuses manières possibles et acceptables pour un projet réel de définir ces aspects. Cela peut être difficile la première fois qu'une entreprise tente de développer un système d'avionique civile selon cette norme et a créé un marché de niche pour la formation et le conseil DO-178B.

Pour un processus générique basé sur DO-178B, un résumé visuel est fourni, y compris les étapes d'implication (SOI) définies par la FAA sur les « orientations et aides au travail pour les logiciels et le matériel électronique complexe ».

Planification

Les exigences du système sont généralement entrées dans l'ensemble du projet.

Les 3 derniers documents (normes) ne sont pas requis pour le niveau logiciel D..

Développement

DO-178B n'est pas conçu comme une norme de développement logiciel ; c'est l'assurance logicielle utilisant un ensemble de tâches pour atteindre des objectifs et des niveaux de rigueur.

Les documents de sortie du processus de développement :

  • Données sur les exigences logicielles (SRD)
  • Description de la conception du logiciel (SDD)
  • Code source
  • Code objet exécutable

La traçabilité des exigences du système à tout le code source ou code objet exécutable est généralement requise (selon le niveau du logiciel).

Processus de développement logiciel généralement utilisé :

Vérification

Documenter les extrants générés par ce processus :

L'analyse de tout le code et la traçabilité des tests et des résultats à toutes les exigences sont généralement requises (selon le niveau du logiciel).

Ce processus implique généralement également :

D'autres noms pour les tests effectués dans ce processus peuvent être :

Gestion de la configuration

Documents conservés par le processus de gestion de configuration :

  • Indice de configuration logicielle (SCI)
  • Indice de configuration de l'environnement du cycle de vie du logiciel (SECI)

Ce processus gère les rapports de problèmes, les modifications et les activités connexes. Le processus de gestion de configuration fournit généralement une identification d'archivage et de révision de :

  • Environnement de développement de code source
  • Autres environnements de développement (par exemple, outils de test/analyse)
  • Outil d'intégration de logiciels
  • Tous les autres documents, logiciels et matériels

Assurance qualité

Documents de sortie du processus d'assurance qualité :

  • Dossiers d' assurance qualité des logiciels (SQAR)
  • Revue de conformité logicielle (SCR)
  • Résumé des réalisations logicielles (SAS)

Ce processus effectue des examens et des audits pour montrer la conformité avec DO-178B. L'interface avec l'autorité de certification est également assurée par le processus d'assurance qualité.

Chargée de certification

Généralement, un représentant technique désigné (DER) examine les données techniques dans le cadre de la soumission à la FAA pour approbation.

Outils

Le logiciel peut automatiser, assister ou autrement gérer ou aider dans les processus DO-178B. Tous les outils utilisés pour le développement du DO-178B doivent faire partie du processus de certification. Les outils générant du code embarqué sont qualifiés d'outils de développement , avec les mêmes contraintes que le code embarqué. Les outils utilisés pour vérifier le code (simulateurs, outil d'exécution de test, outils de couverture, outils de reporting, etc.) doivent être qualifiés d'outils de vérification , un processus beaucoup plus léger consistant en un test complet en boîte noire de l'outil.

Un outil tiers peut être qualifié d'outil de vérification, mais les outils de développement doivent avoir été développés suivant le processus DO-178. Les entreprises fournissant ce type d'outils en tant que COTS sont soumises à des audits de la part des autorités de certification, auxquelles elles donnent un accès complet au code source, aux spécifications et à tous les artefacts de certification.

En dehors de cette portée, la sortie de tout outil utilisé doit être vérifiée manuellement par des humains.

Gestion des exigences

La traçabilité des exigences concerne la documentation de la durée de vie d'une exigence. Il devrait être possible de remonter à l'origine de chaque exigence et chaque modification apportée à l'exigence devrait donc être documentée afin d'assurer la traçabilité. Même l'utilisation de l'exigence après le déploiement et l'utilisation des fonctionnalités implémentées doit être traçable.

Critique

VDC Research note que le DO-178B est devenu "un peu obsolète" en ce sens qu'il ne s'adapte pas bien aux besoins et aux préférences des ingénieurs d'aujourd'hui. Dans le même rapport, ils notent également que le DO-178C semble bien placé pour résoudre ce problème.

Ressources

  • FAR Partie 23/25 §1301/§1309
  • Loin partie 27/29
  • AC 23/25.1309
  • CA 20-115B
  • RTCA/DO-178B
  • FAA Order 8110.49 Directives d'approbation de logiciel

Voir également

Les références

Liens externes