.jpg)
DO-178C - Aperçu
Cette page a pour but de présenter le DO-178C de la façon la plus simple
Elle devrait-être lue et comprise en préambule à une formation plus complète ou nous pourrons entrer dans plus de détails et exemples
Une formation de 2 jours sur le DO-178C est assez dense et l'expérience montre que des stagiaires peuvent saturer s'ils n'ont aucune idée du sujet en arrivant à la formation
Préambule
A quoi servent les ARP-4754, DO-178/DO-254 et autres standards ?
Cette section s’adresse aux débutants qui se demandent d’où viennent ces standards ou « normes » aéronautiques et quelle est leur utilité. Nous prenons volontairement des raccourcis et simplifications pour aller à l’essentiel du message
La loi
En fonction des pays, les lois sont identifiées via divers supports, par exemple le CFR : Code of Federal Regulations aux USA. C’est un peu plus compliqué pour les états de l’union Européenne mais concernant les lois relatives à l’aéronautique, le contenu de ces lois est à peu près le même dans la plupart des pays, en particulier aux USA et en Europe
Les lois relatives à l’aéronautique ont comme origine, pour la presque totalité, la sécurité des personnes
La sécurité avant tout
Au titre de la loi, et entre autres lois, le développement d’un avion, d’un système ou équipement embarqué à bord d’aéronef, nécessite de réaliser des analyses de sécurité. Les standards (guides) reconnus, et appliqués par les avionneurs et leurs fournisseurs, pour la réalisation de ces analyses sont l’ARP-4754 et l’ARP-4761 dans leur révision applicable. Ces analyses débutent au niveau de l’avion puis continuent au niveau des systèmes et des équipements, de l’électronique et des logiciels embarqués
De ces analyses, un niveau de criticité est déterminé pour chaque système, équipement, électronique et logiciel embarqué. Le niveau de criticité le plus élevé est « Catastrophique », le moins élevé est « pas d’effet sur la sécurité ». Par exemple, on peut comprendre que la perte totale du freinage a l’atterrissage est catastrophique
Par une méthode proposée dans les ARP4754 & ARP4761, en partant de la criticité et de l’architecture, on détermine un niveau d’assurance de la conception (DAL) pour chaque système, équipement, électronique et logiciel embarqué
Le DAL
(Design Assurance Level = Niveau d’Assurance de la Conception en Français)
Le DAL est représenté arbitrairement par une lettre : A pour le plus élevé, E pour le moins élevé. Le DAL étant lié à la criticité il est fondamental de comprendre le concept suivant :
-Plus le DAL est élevé, plus les activités de vérifications seront nombreuses et poussées
-Plus le DAL est élevé, plus il y aura besoin d’indépendance entre certaines activités
Ces objectifs visent à garantir un certain niveau de confiance dans le design (Design Assurance) du système, de l’équipement, de l’électronique ou du logiciel considéré. Plus le DAL est élevé plus le niveau de confiance doit être élevé
Les standards (certains parleront de « normes » mais peu importe)
Les lois sont écrites sous des formes non techniques, par exemple du genre « les systèmes critiques doivent être sûrs ». Les standards (ARPS, Dos…) tentent de traduire ces règles de haut niveau en objectifs et activités qui puissent être compris, et pour lesquels des preuves peuvent être apportées. Les standards sont rédigés par des groupes de travail associant des avionneurs (Airbus, Boeing, …), des systémiers (Thales, Safran, Honeywell, …) et des autorités (EASA, FAA, …)
ARP-4754, DO-178/DO-254
Ces standards, mais d’autres également (DO-200, DO-326, DO-330, DO-356…), identifient des objectifs en fonction du DAL ainsi que le besoin d’indépendance pour la tenue de ces objectifs.
Chaque standard contient, vers la fin du document, des tables d’objectifs. Connaissant le DAL, il suffit de regarder dans les colonnes « DAL » ce qui s’applique au projet. Prenons un exemple concret avec le DO-178C :
Responsabilité
Les standards aéronautiques applicables sont dictés par des lois qui ont pour origine la sécurité des personnes.
Il est important pour les intervenants de comprendre qu’ils ont une responsabilité sur leur correcte application.
Il faut garder en tête que la majorité des systèmes embarqués à bord d’aéronefs sont des systèmes critiques.
Aperçu des activités
Ici nous présentons les principales activités liées aux objectifs du DO-178C. Comme expliqué plus haut, certaines activités ne sont pas obligatoires ou sont à moduler en fonction du DAL.
La planification
Comme expliqué précédemment, le DO-178C contient une table d’objectifs en fonction du DAL.
La première activité est d’élaborer des plans qui vont établir la façon de travailler (méthodes) pour être en conformité avec ces objectifs.
Les plans ne sont pas écrits à titre d’information pour une autorité de certification, ils sont applicables par l’équipe de développement.
Une autorité (e.g. EASA, FAA..), ou son représentant (e.g. Airbus, …) est susceptible de réaliser des audits durant le développement (SOI#1, SOI#2, SOI#3, SOI#4). Une fois qu’elle aura approuvé les plans (durant le SOI#1) comme étant en ligne avec les objectifs, elle fera des audits et procèdera par échantillonnage pour s’assurer que les plans sont appliqués et correctement appliqués.
NOTE: le DO-178C exprime des objectifs mais ne propose pas de solution. Par exemple, un objectif est d’établir des règles de codage susceptibles de rendre le code lisible, maintenable… avec comme arrière pensée de limiter les risques d’erreurs inhérents à un codage « tortueux ». Ces règles de codage sont à définir par le projet, le DO ne les impose pas. Il arrive souvent qu’une société décide d’avoir des règles communes à l’ensemble des projets ou d’utiliser des règles standardisées (e.g. MISRA), dans ce cas on parlera de « standards » qui seront référencés dans les plans.
La spécification
Une fois les plans établis (pour mémo ils contiennent les méthodes de développement applicables au projet), le développement commence par la première étape: spécifier le besoin.
Dans une spécification on trouve des « exigences » ou « requirements » en Anglais.
Dans une spécification on trouve généralement un groupe d’exigences pour chaque fonction et des exigences liées à divers facteurs (performance, interfaces...). Par exemple (simplifié) pour une fonction d’affichage:
Exigence #1 L’affichage du texte xxx doit être de couleur xxx et de taille xxx
Exigence #2 L’affichage de l’altitude doit être en pieds
...
A noter que les exigences sont décrites en termes de besoins ou attendus, pas de solution.
La façon de capturer/rédiger des exigences suit des règles identifiées dans les plans.
Chaque exigence doit avoir un identifiant unique (ici encore, rien d’imposé par le DO, chacun est libre de déterminer comment on identifie une exigence). Ceci servira en particulier pour la traçabilité.
Le design
Une fois la spécification vérifiée (voir section sur les vérifications) et approuvée, la prochaine étape est le design (ou conception).
L’objectif du design est d’établir une solution pour répondre aux exigences de la spécification. La phase de design comporte 2 principaux aspects:
- L’architecture (fonctions, aspects temps réel, répartition en tâches autour d’un OS, …)
- Les exigences de bas niveau (raffinement de la spécification en exigences plus détaillées, algorithmes…)
Le design (architecture plus exigences de bas niveau) sera le point d’entrée pour le codage. En principe, outre les règles de codage, le codeur n’aura besoin que de ces infos (plus éventuellement d’infos d’interfaces avec le Hw) pour coder.
NOTE: en Anglais on parle de HLRs et LLRs.
Les HLRs (High Level Requirements) sont les exigences de haut niveau, ce sont les exigences de la spécification (pour mémo qui expriment le besoin et non pas la solution.
Les LLRs (Low Level Requirements) sont les exigences de bas niveau, ce sont les exigences du design (exprimées en termes de solution).
Codage et intégration
Une fois le design vérifié (voir slides sur les vérifications) et approuvé, la prochaine étape est le codage (dans la vraie vie on procède par morceaux, on n’attend pas la fin de la conception pour coder la première ligne, dans cette présentation de haut niveau on n’entre pas dans une discussion un peu plus complexe mettant en jeu la gestion de configuration).
Ces phases sont bien connues des développeurs, on parle ici de:
Codage source (C, C++, ADA…)
Compilation (production de l’assembleur)
Link (production de l’exécutable)
NOTE1: comme cité plus haut en exemple, le codage, outre devoir être conforme au design, doit aussi être conforme aux règles de codage.
NOTE2: en cas d’utilisation de langage orienté objet (C++…), un autre DO (DO-332) s’applique, qui contient des objectifs supplémentaires.
Les vérifications
En fonction du DAL, le DO-178C identifie un certain nombre de vérifications à effectuer, parfois avec indépendance.
Pour mémo, plus le logiciel est critique, plus les couches de vérifications sont nombreuses.
Cette présentation est simplifiée mais présente un aperçu des vérifications applicables pour un DAL A (donc le maximum):
Vérification des plans (vérifier que tous les objectifs applicables sont couverts)
Vérification des exigences de haut niveau (vérifier que les HLRs sont correctes et complètes)
Vérification des exigences de bas niveau (vérifier que les LLRs sont correctes et complètes)
Vérification de l’architecture (vérifier que l’architecture est compatible avec la spécification)
Vérification du code source (vérifier que le code est conforme au design et aux règles de codage)
Etablissement des cas de tests (pour chaque exigence, des cas de tests couvrent l’exigence en question)
Vérification des cas de tests (vérifier que les cas de tests couvrent complètement les exigences)
Etablissement des procédures de tests (pour chaque cas de test, établir la procédure de test, voir slide 3/3)
Vérification des cas de tests (vérifier que les procédures de tests sont conformes et couvrent les cas de tests)
Vérification des résultats de tests (vérifier que les résultats sont conformes aux attendus identifiés dans les cas de tests)
Vérification de la couverture structurelle (vérifier si certaines parties du code n’ont pas été exercées durant les tests)
WCET (Worst Case Execution Time) (vérifier que toutes les tâches ont le temps de s'exécuter dans les pires scenarios de charge CPU)
Vérifier que le code généré par le compilateur ne contient pas de comportements non souhaités
Vérifier les sorties de l’intégration (vérifier les sorties de la compilation et du link)
Différence entre cas et procédures de tests:
Les cas de tests sont écrits à partir des exigences, un cas de test identifie:
•L’exigence (ou groupe d’exigence) que le cas traite
•L’objectif du test (quelle partie on souhaite tester)
•Les conditions d’entrée du test
•Le résultat attendu
Les procédures sont écrites à partir des cas de tests:
•Soit en termes d’actions à réaliser par le testeur, soit par exemple en Python pour une exécution automatique, soit une combinaison des 2.
•Une fois exécutées, les procédures génèrent les résultats (qui seront ensuite comparés aux attendus identifiés dans les cas de tests).
La traçabilité
Parmi les intérêts de la traçabilité on peut noter:
•Descendante (par exemple de la spécification vers le design): on s’assure qu’on n’oublie rien
•Montante (par exemple du design vers la spécification): on s’assure que l’on n’introduit pas de comportements non souhaités
Les niveaux de traçabilité attendus dépendent du DAL
Ci-dessous le cas du DAL A (donc maximum):
•Entre la spécification de l’équipement et la spécification du logiciel
•Entre la spécification du logiciel et le design
•Entre le design et le code source
•Entre le code source et le code objet
•Entre les exigences (HLRs & LLRs) et les cas de tests
•Entre les cas de tests, les procédures de tests, les résultats de tests
Et d’une façon générale, il faut une traçabilité entre les différents éléments (spécification, design, code…) et les preuves de vérification (voir liste des vérifications). Par exemple, entre le code source et les preuves de vérifications de la conformité avec les règles de codage
En théorie on peut gérer la traçabilité avec un ou plusieurs fichiers Excel, ce qui est faisable pour un petit projet, la principale difficulté étant la gestion de configuration. En général beaucoup d’industriels utilisent des outils dédiés (JAMA, DOORS…)
La qualité
Au moins un(e) responsable qualité du logiciel doit être désigné(e) sur le projet
Son rôle est de s’assurer que les plans, une fois approuvés, sont appliqués. Et, dans le cas contraire, définir un moyen pour revenir à la normale
La qualité doit être indépendante du développement. En principe elle réfère directement à la Direction dans l’organigramme de la société ou, au moins, à l’organe qui se trouve au-dessus de l’équipe de développement
Il/elle remplit sa tâche en réalisant des inspections et des audits tout au long du développement
La qualité a son propre plan qui détermine les méthodes et outils utilisés mais aussi le planning de ses activités corrélé avec le planning du développement
Le/la responsable qualité doit avoir une bonne connaissance et compréhension du DO-178C, ou à minima des plans applicables
La gestion de configuration
•Comment identifier des « items » (e.g. un plan, une spécification, un fichier source…), et leur version à un instant T
•Comment identifier leur état (e.g. vérifié et pas d’action ouverte, actions ouvertes…)
•Comment et quand mettre en place un système de suivi des modifications
La mise en place de cette activité n’est pas simple
L’intérêt premier (en termes de certification) de la gestion de configuration est de pouvoir tirer crédit, en termes de certification, d’une activité
Par exemple, si l’on veut pouvoir justifier qu’un fichier source a été vérifié pour sa conformité avec les règles de codage, il va déjà falloir avoir une méthode qui permette d’identifier ce fichier et sa version. De telle sorte que le rapport de vérification (e.g. un rapport de revue ou une sortie d’outil d’analyse) puisse se référer à ce fichier et à sa version. Par la suite, si ce fichier est modifié, il faudra être capable, déjà d’identifier que le fichier à été modifié, et d’identifier le besoin pour une re vérification, même partielle
A noter que la gestion de configuration n’aide pas seulement à justifier la tenue d’objectifs de certification, elle aide avant tout le chef de projet à savoir exactement ou en est le projet, ce qui est terminé et ce qu’il reste à faire (ou à refaire)
Autres considérations
Le DO-178C identifie des objectifs propres à certaines situations particulières. Par exemple nous avons déjà parlé de la conception orientée objet qui rend applicable le DO-332. Ci-dessous quelques exemples de cas particuliers qui entraînent des objectifs supplémentaires:
Le développement basé sur des modèles, entraîne l’application du DO-331
Qualification d’outils: dans certains cas il est nécessaire, soit d’utiliser un outil déjà qualifié soit de qualifier l’outil. La qualification d’outils est traitée en partie par le DO-178C mais principalement dans le DO-330
Utilisation de fichiers de configuration modifiables en service
Demande de crédit de certification pour l'utilisation de logiciels déjà en service sur d’autres programmes
En résumé
Cette présentation fait l’impasse sur une foule de détails pour chaque activité qui, même avec une formation de 2 jours, ne pourraient pas tous être discutés exhaustivement
Beaucoup de subtilités s’apprennent en pratiquant. Bien souvent il n’est pas nécessaire, pour un/e ingénieur/e, de maîtriser l’ensemble du DO-178. Par exemple, un/e ingénieur/e, dédié à écrire des cas ou procédures de test, devra être informé de la façon de faire décrite dans le « Plan de Vérification » et de certains aspects de la gestion de configuration décrits dans le « Plan de Gestion de la Configuration ». Il/elle n’aura pas ou peu besoin d’autres éléments.
Pour un/e débutant/e avec le DO-178C il est important de retenir les informations suivantes
•Les objectifs identifiés dans le DO-178C, visent à améliorer autant que possible la confiance que l’on peut avoir dans un logiciel, ceci à fin de sécurité des personnes. Si le DO-178C est applicable à un projet, il fait force de loi, ce n’est pas optionnel
•Les objectifs identifiés dans le DO-178C, à part ceux pour la Qualité, sont directement liés aux techniques de développement (les auditeurs des autorités qui vous surveillent, ont, en principe, un background de concepteurs et peuvent s’appuyer sur un panel d’experts)
•Le DO-178C identifie des objectifs mais ne propose pas de solutions. Les solutions pour atteindre ces objectifs, sont à déterminer par l’entreprise responsable du projet et sont détaillés dans les « plans & standards » applicables au projet
Lorsque vous arrivez sur un projet, vous devez être informé de ce qui est applicable pour vous en fonction de votre rôle. Soit on vous fourni le plan qui vous concerne, soit on vous l’explique.