Menu Fermer

Développer du logiciel DO-178 niveau D

PREAMBULE

Développer du logiciel embarqué sous contrainte de la norme DO 178 n’est pas chose facile car la norme est très éxigente pour garantir la sécurité de fonctionnement des équipements et implicitement celle des passagers à bord des aéronefs. CEI-PROJETS vous propose à travers cet article de faire un petit tour d’horizon des différentes contraintes et des processus à mettre en place au sein de votre organisation pour développer du logiciel en Design Assurance Level D.

CLASSIFICATION NORME DO 178 B

La F.A.A (Federal Aviation Administration) a définie 5 catégories de conditions de panne sur lesquelles la DO178 B se base :

Niveau A, catastrophique : Conditions de panne susceptibles d’empêcher la poursuite en toute sécurité d’un vol ou d’un atterrissage.

Niveau B, dangereuse : Conditions de panne susceptibles de réduire les possibilités de l’aéronef ou la capacité de l’équipage à faire face à des conditions hostiles.

Niveau C, majeure : Conditions de panne susceptible de réduire les possibilités de l’aéronef ou la capacité de l’équipage à faire face à des conditions hostiles d’une gravité se traduisant, par exemple, par une réduction significative des marges de sécurité ou des capacités fonctionnelles, un accroissement significatif de la charge de travail de l’équipage ou des conditions affectant son efficacité ou un inconfort pour les occupants comportant éventuellement des blessures.

Niveau D, mineure : Conditions de panne n’engendrant pas de réduction significative de la sécurité de l’aéronef et susceptibles d’entraîner pour l’équipage des actions se situant tout à fait dans le domaine de leurs capacités. Les conditions de panne mineures peuvent comprendre par exemple, une légère réduction des marges de sécurité ou des capacités fonctionnelles, une légère augmentation de la charge de travail de l’équipage telle que modifications ordinaires de plan de vol, ou une certaine gêne pour les occupants.

Niveau E, sans effet : Conditions de panne n’affectant pas la capacité opérationnelle de l’aéronef ou n’entraînant pas une augmentation de la charge de travail de l’équipage.

Parallèlement aux catégories de conditions de panne, on définit 5 niveaux de logiciel. 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.

CYCLE DE VIE LOGICIEL

Le développement d’un logiciel doit suivre un ensemble de processus au cours de son cycle de vie. Chaque processus comporte un ou plusieurs critères de transition qui permettent de passer au processus suivant. Pour chaque logiciel développé suivant la DO 178B, un cycle de vie incluant les processus doit être élaboré.

Les processus du cycle de vie d’un logiciel sont les suivants :

  • La planification du logiciel qui définit et coordonne les activités de développement et les processus du projet
  • Les spécifications, la conception, le codage et l’intégration.
  • La vérification du logiciel
  • La gestion de configuration
  • L’assurance qualité
  • La coordination pour la certification
Un projet logiciel définit un ou plusieurs cycles de vie en choisissant les activités et leur séquencement et en allouant des responsabilités pour chaque activité. L’enchaînement habituel des processus de développement est : spécifications, conception, codage, intégration, validation suivant le cycle en V :

 

Un produit logiciel peut être construit avec plusieurs composants ayant des cycles de vie différents. Par exemple pour les composants réutilisés et dèjà certifiés, le cycle de vie est différent des nouveaux composants à développer. Les processus du cycle de vie d’un logiciel peuvent être itératifs suivant la complexité, l’évolution des spécifications, la disponibilité du matériel ou le retour d’information des processus antérieurs.
 

PLANIFICATION DU LOGICIEL

La planification du logiciel a pour but de définir les moyens de réalisation du logiciel satisfaisant les spécifications du système et donnant la confiance nécessaire pour répondre aux exigences de navigabilité.

Les exigences pour le niveau D sont :

  • Le plan pour les aspects logiciels de la certification (PALC). Ce plan est le 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
  • Le plan de développement du logiciel (PDL). Le plan de développement logiciel comprend les objectifs, les règles et les cycles de vie du logiciel à utiliser dans les processus de développement. Ce plan peut être inclus dans le plan des aspects logiciels de la certification
  • Le plan de validation du logiciel (PVL). Le plan de validation du logiciel est une description des procédures de vérification pour satisfaire les objectifs du processus de vérification.
  • Le plan de gestion de configuration) (PGCL). Le plan de gestion de configuration du logiciel détermine les méthodes à utiliser pour atteindre les objectifs de gestion de configuration du logiciel pendant tout le cycle de vie.
  • Le plan SQA (Assurance qualité du logiciel) (PAQL). Ce plan définit les méthodes à utiliser pour atteindre les objectifs du processus d’assurance qualité du logiciel.Il peut comprendre des descriptions d’amélioration de ce processus, des métriques et des méthodes de gestion continue de la qualité.

 

DEVELOPPEMENT DU LOGICIEL

  • Les spécifications du logiciel (DSL) : Le processus des spécifications du logiciel 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) : Les exigences de haut niveau du logiciel sont affinées au moyen d’une ou plusieurs itérations dans la conception afin de développer l’architecture du logiciel et les éxigences de bas niveau qui peuvent être utilisés pour réaliser l’application.
  • Le codage du logiciel : Dans le codage, le code source est réalisé à partir du DSL, de l’architecture et des exigences de bas niveau issues du document de conception logiciel (DCL).
  • L’intégration du logiciel :Dans l’intégration on utilise les différents composants constituant le logiciel issus du codage pour charger le code exécutable sur la machine cible.

 

VERIFICATION DES SPECIFICATIONS

Les revues et analyses des spécifications du logiciel Les revues et analyses ont pour objectif de détecter et de rendre compte des erreurs d’exigences qui peuvent avoir été introduites au cours de la définition des spécifications. Ces revues et analyses confirment que les exigences de haut niveau satisfont les objectifs suivants :
  • Conformité avec les spécifications du système : Il faut s’assurer que les fonctions du système à réaliser par logiciel sont définies, que les spécifications fonctionnelles, de performances, et relative à la sécurité du système sont satisfaites par les exigences de haut niveau.
  • Précision et cohérence : L’objectif est de s’assurer que chaque exigence de haut niveau est précise, sans ambiguité et suffisamment détaillée.
  • Traçabilité : L’objectif est de s’assurer que les spécifications fonctionnelles et de performance, ainsi que celles relatives à la sécurité et allouées au logiciel ont été développées sous la forme d’exigences de haut niveau.
  • Les revues et analyses d’architecture du logiciel : Ces revues ont pour objectif de détecter et de rendre compte des erreurs qui ont pu être introduites au cours du développement de l’architecture du logiciel.

 

VALIDATION DU LOGICIEL

Les exigences pour la validation du logiciel de niveau D :

Les jeux de test avec des données dans les plages de variation prévues ont pour objectif de démontrer la capacité du logiciel à répondre à des données d’entrée et des conditions normales.

Ces jeux de test contiennent notamment :

  • Des variables réelles et entières doivent être mises en œuvre par le biais de classes d’équivalence valides et de valeurs limites.
  • Pour les fonctions liées au temps, tels que filtres, intégrateurs et retard, on doit réaliser des itérations multiples afin de vérifier les caractéristiques de la fonction dans son contexte.
  • Pour les transitions d’états, on doit développer des jeux de test afin de mettre en œuvre les transitions possibles en fonctionnement normal.
  • Pour les spécifications de logiciel exprimées par des équations logiques, les jeux de test doivent vérifier l’utilisation des variables et les opérateurs booléens.
Les jeux de test de robustesse ont pour objectif de démontrer la capacité du logiciel à répondre à des données d’entrée et des conditions anormales.

Les jeux de test de robustesse contiennent notamment :

  • La mise en œuvre des variables réelles et entières en prenant des valeurs des classes d’équivalence invalides
  • L’initialisation du système doit se faire avec des conditions anormales.
  • On doit déterminer les modes de panne possibles des données d’entrée, en particulier les chaînes de données numériques complexes provenant d’un système extérieur
  • Pour les boucles dont l’indice est une valeur calculée, on devra développer des jeux de test de manière à calculer des valeurs de l’indice de boucle extérieures au domaine de validité du compteur et démontrer ainsi la robustesse du code lié aux boucles
  • On doit vérifier que les mécanismes de protection contre les temps de calculs excessifs répondent correctement
  • Pour les fonctions liées au temps, on doit développer des jeux de test pour vérifier les mécanismes de protection contre les débordements de capacité arithmétique
  • Pour les transistions d’états, on doit développer des jeux de test afin de provoquer des transitions qui ne soient pas permises par les spécifications du logiciel

 

INTEGRATION MATERIEL / LOGICIEL

Le test d’intégration matériel/logiciel a pour objectifs de s’assurer que le logiciel dans la machine cible satisfait les exigences de haut niveau.

Les erreurs typiques révélées lors des tests d’ intégration sont les suivantes :

  • Mécanisme incorrect de traitement des interruptions
  • Non respect des exigences de temps d’exécution
  • Réponse incorrecte du logiciel à des transitoires ou des pannes du matériel, par exemple séquencement de mise en route, transitoires sur les flux d’entrées ou sur les alimentations
  • Problèmes de bus de données et autres conflits d’accès aux ressources, par exemple d’organisation de la mémoire
  • Inaptitude des tests intégrés à détecter des pannes
  • Erreur d’interfaces matériel / logiciel
  • Comportement incorrect des boucles de retour d’information
  • Contrôle incorrect du matériel de gestion mémoire ou d’autres dispositifs matériels sous contrôle logiciel
  • Débordement de piles
  • Violation du partitionnement du logiciel

 

GESTION DE LA CONFIGURATION DU LOGICIEL

Identification de la configuration :
L’activité d’identification de configuration a pour objectif de repérer sans ambiguité chaque élément de configuration (et ses versions successives) de manière à constituer une base pour la gestion et la référence des éléments de configuration.
Référentiels et traçabilité :
L’activité d’établissement des référentiels a pour objectif de définir une base pour les activités ultérieures du cycle de vie du logiciel, de permettre de se référer aux éléments de configuration, de les gérer et de permettre la traçabilité entre éléments.
Compte rendu des anomalies :
Les activités de compte-rendu, de suivi des anomalies et des actions correctives ont pour objectif d’enregistrer les non conformités des processus vis à vis des plans et règles du logiciel, les insuffisances des produits du cycle de vie du logiciel, les dysfonctionnements du logiciel et de garantir la résolution de ces problèmes. Voir DO178 B § 7.2.3 pour les directives.
Gestion des modifications :
L’activité de gestion des modifications a pour objectif d’enregistrer, d’évaluer, de réaliser et d’approuver des modifications tout au long du cycle de vie du logiciel.
Revue des modifications :
L’activité de revue des modifications a pour objectif de garantir que les anomalies et les modifications sont évaluées et approuvées ou rejetées, que les modifications approuvées sont réalisées, et que les méthodes de compte-rendu des anomalies et de gestion des modifications définies durant la planification du logiciel assurent un retour d’information vers les processus mis en cause.
Suivi des états de configuration :
L’activité de suivi des états de configuration a pour objectif de fournir des données de gestion de configuration relatives à l’identification de la configuration, aux référentiels, aux rapports d’anomalies et à la gestion des modifications.
Archivage, restauration et mise à disposition :
L’activité d’archivage et de restauration a pour objectif de garantir que les données du cycle de vie associées au produit logiciel peuvent être restaurées pour reproduire, regénérer, tester de nouveau ou modifier ce produit. L’activité de mise à disposition a pour objectif de garantir de plus, que seul le logiciel autorisé est utilisé, en particulier à des fins de production.
Contrôle du chargement du logiciel :
L’activité de contrôle du chargement du logiciel a pour objectif de garantir que le code objet exécutable est chargé dans le système ou l’équipement de bord en utilisant des protections appropriées. Le contrôle de chargement du logiciel concerne le processus par lequel des instructions et des données programmées sont transférées d’un dispositif de mémoire étalon vers le système ou équipement de bord. Par exemple les méthodes peuvent comprendre (sous réserve de l’approbation par l’autorité de certification) l’installation d’éléments mémoire pré-programmés en usine ou la reprogrammation in situ du système ou équipement de bords au moyen d’un dispositif de téléchargement

Quelle que soit la méthode utilisée, le contrôle du chargement du logiciel doit comprendre :

  • Des procédures de numérotation des éléments et d’identification des supports qui référencent les configurations de logiciel destinées à être approuvées en vue de leur chargement dans le système ou équipement de bord
  • Des documents confirmant la compatibilité du logiciel avec le matériel du système ou équipement de bord qui doivent être conservés, que le logiciel soit livré comme produit final ou chargé dans le système ou équipement de bord
Contrôle de l’environnement de développement du logiciel :
Le contrôle de l’environnement de développement du logiciel a pour objectif de garantir que les outils utilisés pour générer le logiciel sont identifiés, gérés et qu’il est possible de les restaurer. Les outils de l’environnement de développement du logiciel sont définis par le processus de planification du logiciel et identifiés dans le répertoire de la configuration de l’environnement du logiciel.
 

ASSURANCE QUALITE DU LOGICIEL

Le processus d’assurance qualité (à faire avec indépendance)
Les objectifs du processus SQA sont d’assurer que le cycle de vie produit un logiciel conforme à ses spécifications en garantissant que les processus du cycle de vie sont réalisés en accord avec les plans et règles approuvés.

Le processus de SQA a pour objectif d’obtenir l’assurance que :

  • Le développement du logiciel et les processus intégraux sont conformes aux plans et règles approuvés
  • Les critères de transition pour chaque processus du cycle de vie du logiciel sont satisfaits
  • Une revue de conformité du produit logiciel est menée
Revue de conformité du logiciel (à faire avec indépendance)
La revue de conformité du logiciel a pour objectif d’obtenir l’assurance, pour un logiciel présenté dans le cadre d’une certification, que les processus du cycle de vie du logiciel sont achevés, que ses données sont complètes, et que le code objet exécutable est géré en configuration et peut être régénéré.
 

CERTIFICATION DU LOGICIEL

Moyen de conformité et planification :
Le postulant propose un moyen de conformité et de quelle manière le développement du système ou équipement de bord satisfait les bases de la certification. Le plan des aspects logiciels de la certification définit les aspects logiciels du système ou équipement de bord dans le contexte du moyen de conformité proposé. Ce plan établit aussi le niveau logiciel déterminé par l’analyse de sécurité du système.
Justification de conformité
Le postulant démontre que les cycles de vie du logiciel satisfont les plans du logiciel. Les revues par l’autorité de certification peuvent se faire dans les locaux du postulant ou dans ceux des fournisseurs du postulant. Cela peut impliquer des discussions avec le postulant ou ses fournisseurs. Le postulant organise ces revues et tient à disposition les données du cycle de vie en cas de nécessité.

Données minimales du cycle de vie soumises à l’autorité :

  • Plan des aspects logiciels de la certification
  • Répertoire de la configuration du logiciel
  • Résumé des travaux réalisés

Données du cycle de vie liées à une définition de type :

  • Données de spécification du logiciel
  • Description de conception Code source
  • Code objet exécutable
  • Répertoire de la configuration du logiciel
  • Résumé des travaux réalisés