Les normes de certification logicielle DO-178B et DO-178C servent de lignes directrices pour produire des systèmes aéroportés dignes de vol. DO-178B (Considérations logicielles dans la certification des systèmes et équipements aéroportés), publié pour la première fois en 1992, était le document prédominant pris en compte pour obtenir la certification d’autorités telles que l’EASA (Agence Européenne de la Sécurité Aérienne) et la FAA (Federal Aviation Administration) pour les systèmes aéroportés commerciaux basés sur des logiciels. Cependant, les Réglementations Fédérales de l’Aviation ont reconnu le DO-178C comme une méthode de démonstration de la conformité à la navigabilité en 2013. Pour plus d’informations générales sur les normes DO-178B et DO-178C, vous pouvez lire cet article.
Les normes DO-178B ou DO-178C doivent être satisfaites par des documents tels que :
- PSAC (Plan for Software Aspects of Certification)
- SDP (Software Development Plan)
- SVP (Software Verification Plan)
- SCMP (Software Configuration Management Plan)
- SQAP (Software Quality Assurance Plan)
- SAS (Software Accomplishment Summary)
Ce ne sont pas les seuls documents requis pour satisfaire les normes DO-178B et DO-178C. Il existe un grand nombre d’autres documents pour enrichir la navigabilité. Vous pouvez consulter et acheter ces documents ici.
Documents DO178
Document PSAC
Le document PSAC(Plan for Software Aspects of Certification) décrit les normes, processus, protocoles et méthodologies nécessaires à suivre ainsi que les données du cycle de vie. Ainsi, les objectifs des documents DO-178 peuvent être atteints. PSAC spécifie également le calendrier de développement logiciel et l’aperçu du système. Tant l’autorité de certification que le demandeur utilisent ce document. Le PSAC doit être produit au début du processus de planification logicielle et être approuvé par l’autorité. Pour consulter notre document PSAC, veuillez cliquer ici.
Document SDP
Le document SDP (Software Development Plan) vise à vérifier si des informations nécessaires telles que les procédures de développement logiciel, les protocoles, les normes, les cycles de vie et l’environnement de développement sont spécifiées. Le document SDP est une partie essentielle de la période de planification logicielle. Pour consulter notre document SDP, veuillez cliquer ici.
Document SVP
Le document SVP (Software Verification Plan) spécifie les cas de test nécessaires et les couvertures, les procédures, les protocoles, la vérification des exigences, la vérification du code source avec un contrôle de version approprié. Le SVP est également un élément clé du processus de planification. Pour consulter notre document SVP, veuillez cliquer ici.
Document SCMP
Le document SCMP (Software Configuration Management Plan) est un autre aspect clé de la période de planification. Pendant le processus de développement du logiciel, il arrive souvent que le plan initial change. Le SCMP nous aide à détecter, contrôler, maintenir et suivre ces changements. Il est appliqué tout au long du processus de développement logiciel. Le SCMP vise à minimiser les erreurs et à maximiser la productivité. Les membres de l’équipe doivent s’efforcer de signaler et de notifier les changements. Pour consulter notre document SCMP, veuillez cliquer ici.
Document SQAP
Le document SQAP (Software Quality Assurance Plan) comprend des outils, des méthodes et des techniques utilisés pour garantir qu’un produit ou service répond aux spécifications données dans la SRS (Software Requirement Specification). Le SQAP explique comment les activités d’assurance qualité logicielle seront menées dans le projet. L’équipe SQA établit des jalons et évalue la qualité du projet à chaque jalon. La SQA est menée tout au long du cycle de vie logiciel. Pour consulter notre document SQAP, veuillez cliquer ici.
Document SAS
Le document SAS (Software Accomplishment Summary) résume chaque étape des composants logiciels pendant le développement et la vérification. Le SAS doit inclure le résumé des résultats de la qualification des outils de vérification. La FAA doit être informée du SAS. Cela permet à l’autorité de certification de valider les résultats des données de vérification et sert de preuve du statut de qualification de l’outil. Pour consulter notre document SAS, veuillez cliquer ici.
Normes ARP4754 et Normes DO178
ARP4754 représente les « Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems » (Pratiques recommandées en aérospatiale ARP4754A pour le développement des aéronefs civils et des systèmes). Les normes ARP4754 fournissent des directives pour les systèmes d’aéronefs complets tandis que les normes DO178 sont utilisées pour les logiciels de vol. Ces deux normes sont acceptées par des autorités telles que la FAA et l’EASA.
ARP4754 a été développé et publié par la SAE (Society of Automotive Engineers) en 1996. En 2010, la SAE a publié ARP4754A qui représente les directives pour le développement des aéronefs civils et des systèmes. ARP4754A élargit l’idée de l’assurance de conception pour l’utilisation au niveau des aéronefs et des systèmes, ainsi que la standardisation de l’utilisation du terme assurance de développement. ARP4754 a été reconnu par la FAA en novembre 2011.
Du cahier des charges à l’intégration et à la vérification, ARP4754 couvre l’ensemble du cycle de développement des aéronefs. ARP4754 fournit une abstraction pour les aéronefs, les systèmes et les éléments. Pour la conception des éléments, ARP4754 fait explicitement référence à DO-178 et DO-254. ARP4754 se concentre sur l’évaluation de la sécurité tout au long de différents processus tels que le développement, la conception et la vérification. Néanmoins, il convient de noter qu’ARP4754 ne comprend pas le champ d’application spécifique du développement logiciel ou matériel électronique, des activités de sécurité en service et du développement structurel des aéronefs.
Phases de Conception
Revue de Conception Préliminaire – Preliminary Design Review (PDR)
La conception préliminaire est une phase essentielle du processus de développement logiciel. Durant la conception préliminaire, les exigences de haut niveau et les cas d’utilisation sont spécifiés pour construire l’architecture du système. Des documents pour l’interface, la base de données, l’architecture et les diagrammes des relations entre composants peuvent être utilisés dans la conception. La conception préliminaire offrira une représentation visuelle du système au début du projet sur la base de ces entrées. La conception préliminaire crée également les bases des phases de conception plus détaillées suivantes. Elle peut être considérée comme un plan.
La Revue de Conception Préliminaire (PDR) termine la phase de conception préliminaire du projet. Pour avancer vers la conception détaillée, le PDR doit offrir suffisamment d’assurance. Le but du PDR est d’assurer que la conception préliminaire et l’architecture système de base sont complètes, qu’il y a une confiance technique que les exigences peuvent être satisfaites dans les limites du budget et du calendrier.
Revue de Conception Critique- Critical Design Review (CDR)
La Revue de Conception Critique (CDR) termine la phase de conception critique du projet. Les conceptions finales sont présentées avec le CDR à travers une analyse complète, des simulations, des schémas, du code logiciel et des données de test. Le CDR assure que le système peut avancer vers les tests et la production. Il exprime également que les exigences mentionnées peuvent être satisfaites dans les limites du budget et du calendrier. Les dessins et spécifications complets qui en résultent fournissent une ligne de base initiale du produit, avec une ligne de base finale. Le CDR doit être complet et exhaustif.
Phase de Conception Finale- Final Design Phase
La Phase de Conception Finale fournit des dessins architecturaux et techniques détaillés de chaque composant du projet. Pour certains projets, il peut être nécessaire de créer un rapport de conception finale. Les problèmes de conception détectés doivent être résolus avant de terminer la phase de conception finale. Les dessins et le rapport doivent offrir suffisamment de détails pour permettre des estimations raisonnablement précises des coûts de construction et d’exploitation, ainsi que du calendrier de construction. Le rapport de conception finale devrait inclure un calendrier mis à jour, des estimations de coûts et des spécifications. Il devrait également être approuvé que le projet est économiquement réalisable. Tout changement durant la Phase de Conception Finale est plus coûteux par rapport aux autres phases. Ainsi, elle doit être réalisée avec beaucoup d’attention.
SOI (Stages of Involvement)
Les évaluations des Stages of Involvement (SOI) sont effectuées par les autorités de l’aviation des pays concernés à diverses étapes du projet telles que la planification, le développement et la vérification afin d’évaluer la conformité des projets avec DO-178B. Dans des cas idéaux, un total de quatre évaluations SOI sont prévues.
L’évaluation initiale, qui est le premier SOI, comprend la phase de planification des études de conformité à la certification du projet. La deuxième évaluation SOI se concentre sur les phases de développement du projet. Commencez par le développement des exigences logicielles de haut niveau, il s’interroge sur le fait que la conception, les exigences logicielles de bas niveau et le code source soient produits conformément à DO178B. La troisième évaluation SOI se concentre sur les phases de validation. Pas seulement les activités de test, mais toutes les activités effectuées à des fins de vérification sont examinées. Le quatrième SOI, en revanche, est l’évaluation finale menée vers la fin du projet, questionnant s’il reste une activité en suspens et si un nouveau problème est survenu depuis les évaluations précédentes.
L’attente de DO-178B des produits logiciels produits durant la phase de planification est de convenir d’un ensemble de règles commun entre l’autorité et la société le réalisant et de se conformer à cet ensemble de règles tout au long du projet. En d’autres termes, lors de la rédaction des plans et des normes, la société ne détermine pas seulement ses propres processus, mais écrit également les règles pour la manière dont l’autorité s’évaluera elle-même tout au long du processus de certification.
Auteur: Can Önal ([email protected])
Mor Teknoloji
