DO 178, le développement de logiciels critiques

Les normes ED-12 et DO-178 (Software considerations in airborne systems and equipment certification) développées en commun et éditées respectivement par EUROCAE l’Organisation européenne pour l’équipement de l’aviation civile, et RTCA, Radio Technical Commission for Aeronautics en relation avec FFA (Federal Aviation Administation), fixent les conditions de sécurité applicables aux systèmes critiques, c’est à dire dont la panne peut avoir des conséquences dramatiques, pour l’ensemble des équipements informatiques qui aident au pilotage des aéronefs et des astronefs dans l’espace aérien. Elles régissent les activités de développement et de test des logiciels embarqués à bord des avions et aéronefs commerciaux

do178-aviation

Historique

La rédaction de la norme débuta en 1982. Une première version, baptisée DO-178A, fut établie en 1985. Elle fixa entre autres l’obligation de procéder à des tests unitaires sur tous les composants logiciels. Elle fut ensuite remise à jour en 1992 pour devenir la DO-178B. Parmi les améliorations de cette version, on peut citer la prise en compte des systèmes d’exploitation avec des noyaux “préemptifs” qui permet à une  application prioritaire peut prendre la main lorsque survient un certain type d’évènement. En 2004, elle a été mise à jour avec une version DO-178C pour clarifier certains points de la norme et permettre l’intégration de nouvelles techniques de génie logiciel jugées suffisamment matures pour être utilisées dans les systèmes aéronautiques et leur certification. C’est le cas du développement orienté objet, de l’utilisation de modèles pour la génération automatique de code ou de tests, ou encore des méthodes de vérification basées sur des équations mathématiques appelées “méthodes formelles”.

Niveau de criticité

La norme définit 5 catégories de conditions de panne comme suit:

  • Niveau A, catastrophique : Conditions de panne susceptibles de provoquer un problème catastrophique (Sécurité du vol ou atterrissage compromis, Crash de l’avion … )
  • Niveau B, dangereuse : Conditions de panne susceptibles de provoquer un problème dangereux entraînant des dégâts sérieux voire la mort de quelques occupants
  • Niveau C, majeure : Conditions de panne susceptibles de provoquer un problème majeur entraînant un dysfonctionnement des équipements vitaux de l’appareil
  • Niveau D, mineure: Conditions de panne susceptibles de provoquer de provoquer un problème mineur sans effet sur la sécurité du vol
  • Niveau E, sans effet : Conditions de panne susceptibles de provoquer un problème sans effet sur la sécurité du vol

La corrélation entre la fréquence et les niveaux est la suivante avec une probabilité en nombre d’accident par heure de vol :

DO 178 1.jpg

La norme définit ainsi 5 niveaux de logiciel pour chaque catégorie. Ainsi un logiciel est dit de niveau D lorsque son dysfonctionnement mis en évidence par l’analyse de sécurité du système, provoquerait ou contribuerait à une panne d’une fonction du système entraînant une condition de panne de niveau D pour l’aéronef.

Ces 5 niveaux sont aussi appelés niveaux DAL (Development Assurance Level).

Cycle de vie et processus

La norme n’impose pas de cycle de vie mais des processus séparés qui seront combinées pour décrire son cycle de vie:

  • Processus de planification : organisation et plans
  • Processus de développement : spécification, conception, codage et intégration
  • Processus intégraux : vérification, gestion de configuration, assurance qualité, coordination pour la certification.

La norme définit des objectifs pour chacun de ces processus, et décrit un ensemble d’activités pour atteindre les objectifs.

Processus de planification

Les processus liés à la phase de planification s’accompagnent de l’édition de plusieurs documents  :

  • Le plan pour les aspects logiciels de la certification (PALC) : support initial utilisé par l’autorité de certification pour déterminer si un postulant propose un cycle de vie du logiciel en accord avec le niveau du logiciel à développer, il précise le niveau de criticité retenu
  • Le plan de développement du logiciel (PDL): comprend les objectifs, les règles et les cycles de vie du logiciel à utiliser dans les processus de développement
  • Le plan de validation du logiciel (PVL): description des procédures de vérification pour satisfaire les objectifs du processus de vérification
  • Le plan de gestion de configuration (PGCL): détermine les méthodes à utiliser pour atteindre les objectifs de gestion de configuration du logiciel pendant tout le cycle de vie
  • Le plan d’assurance qualité du logiciel (PAQL): définit les méthodes à utiliser pour atteindre les objectifs du processus d’assurance qualité du logiciel
  • Règles de spécifications du logiciel
  • Règles de conception du logiciel
  • Règles de codage du logiciel

Les processus de développement logiciel

Les processus liés à la phase de développement :

  • Les spécifications du logiciel (DSL) : utilise les produits du cycle de vie du système pour développer les exigences de haut niveau du logiciel. Cela comprend, les exigences fonctionnelles, de performance, d’interface et celle liées à la sécurité.
  • La conception du logiciel (DCL) : développe l’architecture du logiciel et les exigences de bas niveau qui peuvent être utilisés pour réaliser l’application.
  • Le codage du logiciel
  • L’intégration du logiciel

Les processus intégraux

Concernant le processus de vérification des spécifications:

  • Conformité avec les spécifications du système :
  • Précision et cohérence
  • Traçabilité
  • Revues et analyses d’architecture du logiciel

Concernant le processus de vérification du logiciel:

  • Cas et procédures de vérification du logiciel
  • Résultats de la vérification du logiciel :
    • Résultats de tests unitaires
    • Résultats de tests d’intégration
    • Résultats de tests
    • Analyse de la couverture de code (MC/DC)
    • Revue de chaque document du logiciel

Concernant le processus de gestion de configuration :

  • Index de la configuration du logiciel
  • Index de l’environnement du cycle de vie du logiciel

Concernant le processus d’assurance qualité :

  • Enregistrements relatifs à la qualité
  • Compte-rendu de revue de conformité
  • Résumé des travaux réalisés

Objectifs à atteindre selon le niveau requis

Plus le niveau de criticité est proche du niveau A, plus le nombre d’objectifs à tenir est élevé. Ainsi :

  • Niveau E :
    • aucune contrainte particulière.
  • Niveau D :
    • Le logiciel doit être documenté, les plans doivent être établis. Tout ce qui est spécifié doit être formellement vérifié. Tous les documents doivent être formellement vérifiés.
    • Le logiciel doit être géré en configuration
    • Un service Qualité indépendant doit assurer le respect de la norme
  • Niveau C : en plus des contraintes du niveau D :
    • Des règles de développement doivent être fixées au préalable
    • Les contraintes de traçabilité et de vérification s’appliquent également aux phases de conception et de codage du logiciel.
    • Les exigences de bas niveau (ou exigences de conception) doivent être formellement vérifiées.
    • Couverture des instructions (Statement Structural Coverage); Ces contraintes amènent souvent à devoir passer des tests unitaires.
  • Niveau B : en plus des contraintes du niveau C :
    • Couverture de décision / Couverture de condition (Decision/Condition Structural Coverage)
    • Les activités de développement et de vérification doivent être confiées à des équipes indépendantes.
  • Niveau A : en plus des contraintes du niveau B :
    • Couverture de condition / Décision modifiée (Modified Condition Decision Structural Coverage, MC/DC)

Références:

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s