Recherche

Bonjour,
que recherchez-vous ?

Fermer le volet de recherche
E-commerce
Ouvrir le menu Fermer le menu
Français Anglais
  1. Accueil

DO-178 : Répondre aux exigences de la norme de Sûreté de Fonctionnement Logiciel Avionique

La norme DO-178C, quatrième version parue en 2012 de la DO-178, traite de la sûreté de fonctionnement des logiciels bord intégrés au sein des avions commerciaux et civils.
Assurer la conformité d’un projet à la DO-178C, c’est mettre en place, dès son démarrage, une méthodologie délimitée et rigoureuse dont l’objectif est la diminution des risques à un niveau acceptable.
pdf_isit

DO-178C : Généralités de la norme

La norme DO-178C fait suite aux versions DO-178 (parue en 1982), DO-178A (parue en 1985) et DO-178B (parue en 1992), travaux conjoints entre les organisations européennes EUROCAE et américaine RTCA. Elle se compose de 10 parties:
1.0      Introduction
2.0      Aspects système liés au développement du logiciel
3.0      Cycle de vie du logiciel
4.0      Planification du logiciel
5.0      Processus de développement du logiciel
6.0      Processus de vérification du logiciel
7.0      Processus de gestion de configuration du logiciel
8.0      Processus d’Assurance Qualité du Logiciel
9.0      Coordination pour la certification
10.0     Vue générale sur la certification des aéronefs et des moteurs
11.0      Données du cycle de vie du logiciel
12.0     Considérations complémentaires

Puisque le logiciel bord installé dans l’aéronef ou le moteur n’est considéré par les autorités de certification que comme une partie d’un système, et non comme un produit isolé unique, le logiciel ne sera pas certifié séparément de l’ensemble de l’aéronef et la norme DO-178C doit donc s’appliquer conjointement avec les autres normes du secteur avionique, comme la DO-160 (Tests des équipements bord d’un aéronef), la DO-254 (Electronique avionique bord) (Formation DO-254), …

Niveaux de DAL

La norme DO-178C définit 5 niveaux de criticités du logiciel appelés DAL (« Design Assurance Level »), allant de A (le plus critique) à E (le moins critique) :
  • DAL A : Logiciel dont le dysfonctionnement contribuerait à une panne "catastrophique" (empêche la poursuite en toute sécurité du vol ou atterrissage)
  • DAL B : Logiciel dont le dysfonctionnement contribuerait à une panne "dangereuse" (réduction importante des marges de sécurité ou des fonctionnalités, problèmes physiques ou augmentation considérable de la charge de  l’équipage, blessures graves pour au moins quelques occupants, …) 
  • DAL C : Logiciel dont le dysfonctionnement contribuerait à une panne "majeure" (réduction significative des marges de sécurité ou des fonctionnalités, augmentation notable de la charge de  l’équipage, inconfort voire blessures pour les occupants, …)
  • DAL D : Logiciel dont le dysfonctionnement contribuerait à une panne "mineure" (légère réduction des marges de sécurité ou des fonctionnalités, légère augmentation de la charge de  l’équipage, léger inconfort pour les occupants, …)
  • DAL E : Logiciel dont le dysfonctionnement contribuerait à une panne sans effet sur la capacité opérationnelle de l'aéronef ni sur la charge de travail du pilote
Un logiciel de DAL E (une fois que l'Autorité de certification a confirmé qu'un logiciel est de DAL E) est considéré hors cadre de la DO-178 ; aucune exigence n’est imposé. Ce niveau correspond donc au niveau QM de l’ISO 26262.
DO178_DAL

Qualification d’outils et DO-330

En ce qui concerne la qualification d’outils de développement ou de tests, la norme DO-178C renvoie à la DO-330 (« Considérations sur la qualification d’outils logiciels »), parue en 2012. Celle-ci définit qu’un outil logiciel doit être qualifié s’il est utilisé pour automatiser tout ou partie d’un processus exigé par la DO-178C, et que dépendant de sa criticité, des exigences de vérification doivent être appliqués par les fournisseurs d’outils.

La DO-330 définit cinq niveaux de qualification d’outils, liés au niveau de DAL du logiciel bord, ainsi que trois critères d’utilisation de l’outil :
  • Critère 1 : Un outil dont la sortie est intégrée au logiciel bord, et peut donc y insérer une erreur
  • Critère 2 : Un outil pouvant, dans le cadre régulier de son utilisation, échouer à détecter une erreur, et dont la sortie est utilisée pour justifier la réduction ou élimination d’une tâche de vérification autre que celle automatisée par l’outil, ou un processus de développement qui pourrait avoir un impact sur le logiciel avionique
  • Critère 3 : Un outil pouvant, dans le cadre régulier de son utilisation, échouer à détecter une erreur
Le critère 1 est équivalent à la notion d’ « outil de développement » de la précédente version DO-178B, tandis que critères 2 et 3 regroupent l’ancienne notion « d’outil de vérification ». Le critère 2 a été ajouté pour les outils de tests clamant que leur utilisation rend inutile une autre tâche de vérification exigée par la DO-178C (outil de « preuve »).
DO178_DAL-1

Afin d’être conforme à la DO-330, les fabricants d’outils logiciels doivent non seulement respecter une suite d’exigences et de tâches de vérification, mais aussi et surtout en fournir les preuves aux utilisateurs, ce qui est généralement effectué au travers d’un pack de qualification.
Les outils LDRA (Analyse statique et dynamique, tests unitaires et d’intégration) et CodeSonar de GrammaTech (Analyse statique avancée) disposent d’un pack de qualification DO-178B/C complet de DAL A à D (TQL-5).

DO-178C : Exigences principales

DO178_Exigences

La norme DO-178 introduit la notion de réalisation d’une activité avec indépendance (notée ●), afin de garantir une évaluation objective de sa complétude. Dans le cadre d’une activité de vérification du logiciel, il s’agit par exemple qu’elle soit réalisée par une ou plusieurs personnes indépendantes du responsable du développement de l’élément à vérifier, et qu’on puisse utiliser un outil pour effectuer une vérification équivalente à celle d’un être humain.

DO-178C : Comment automatiser la réponse aux exigences ?

La DO-178C implique la mise en place d’un Plan d’Assurance Qualité Logiciel, contenant a minima les éléments suivants :
  • Gestion de la configuration et des versions 
  • Suivi de la traçabilité des exigences (fonctionnelles, méthodologiques, normatives) 
  • Mise en place et vérification de règles de codage et de métriques de qualité de code 
  • Tests unitaires, d’intégration et système liés aux exigences 
  • Mesure de la couverture structurelle
De plus, la détection de bugs et erreurs « Runtime » au plus tôt dans le cycle de développement a pour but, comme la DO-178C, de diminuer la probabilité d’occurrence de défaillance du système.
ISIT propose un ensemble de solutions produits et services, allant de la sensibilisation à l’automatisation des réponses aux exigences de la DO-178C, en passant par l’accompagnement projet :