Les normes de certification logicielle DO-178B et DO-178C servent de référence pour la production de systèmes aériens navigables. Publiée pour la première fois en 1992, la DO-178B (Software Considerations in Airborne Systems and Equipment Certification) constituait un document important pour l'obtention de la certification nécessaire auprès d'autorités commerciales telles que l'EASA (Agence de l'Union européenne pour la sécurité aérienne) et la FAA (Federal Aviation Administration) pour les systèmes aériens logiciels. Cependant, les Federal Aviation Regulations ont accepté la DO-178C en tant que méthode de démonstration de conformité de navigabilité en 2013. Pour des informations plus générales sur les normes DO-178B et DO-178C, vous pouvez lire cet article.
Les normes DO-178B ou DO178C doivent être satisfaites par les documents d'exemple suivants, entre autres.
- 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)
Les documents requis pour satisfaire les normes DO-178B et DO-178C ne se limitent pas à ceux-ci. De nombreux autres documents viennent enrichir la navigabilité. Vous pouvez consulter et acheter ces documents ici.
Documents DO178
Document PSAC
Le document PSAC (Plan for Software Aspects of Certification), en plus de produire les données de cycle de vie, explique les normes, processus, protocoles et méthodologies nécessaires à suivre. Cela permet de satisfaire les normes DO-178. Le PSAC précise également le calendrier de développement logiciel et l'état général du système. Ce document profite à la fois à l'autorité d'approbation et au demandeur. Le PSAC doit être produit durant le processus initial de planification logicielle et approuvé par l'autorité de certification. Veuillez cliquer ici pour consulter notre document PSAC.
Document SDP
Le document SDP (Software Development Plan) vise à vérifier si les informations nécessaires, telles que les procédures de développement, les protocoles, les normes, les cycles de vie et l'environnement de développement, ont été déterminées. Le document SDP constitue un élément important du processus de planification logicielle. Veuillez cliquer ici pour consulter notre document SDP.
Document SVP
Le document SVP (Software Verification Plan) précise les scénarios de test et la couverture requis, les procédures, les protocoles, la vérification des exigences et la vérification du code source, tout en assurant un contrôle de version approprié. Le SVP constitue également un élément important du processus de planification. Veuillez cliquer ici pour consulter notre document SVP.
Document SCMP
Le document SCMP (Software Configuration Management Plan) est un autre élément important du processus de planification. Le plan initial élaboré au cours du processus de développement logiciel fait souvent l'objet de modifications. Le SCMP nous aide à détecter, contrôler, maintenir et suivre ces modifications. Il est appliqué tout au long du processus de développement logiciel. Le SCMP vise à minimiser les erreurs et à maximiser l'efficacité. Les membres de l'équipe doivent s'efforcer de se signaler et de se notifier mutuellement les modifications. Veuillez cliquer ici pour consulter notre document SCMP.
Document SQAP
Le document SQAP (Software Quality Assurance Plan) contient les outils, méthodes et techniques utilisés pour garantir qu'un produit ou service satisfait aux spécifications figurant dans le 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. Le SQA est mené tout au long du cycle de vie logiciel. Veuillez cliquer ici pour consulter notre document SQAP
Document SAS
Le SAS (Software Accomplishment Summary) résume chaque étape des composants logiciels durant les processus de développement et de vérification. Le SAS doit inclure un résumé des conclusions de la qualification des outils de vérification. La FAA doit être informée du SAS. Ce document apporte à l'autorité de certification la validation des conclusions des données de vérification et sert de preuve du statut de qualification de l'outil. Veuillez cliquer ici pour consulter notre document SAS
Normes ARP4754 et normes DO178
ARP4754 signifie « Aerospace Recommended Practice ARP4754A Guidelines for Development of Civil Aircraft and Systems ». Les normes ARP4754 fournissent des lignes directrices pour les systèmes de l'aéronef dans leur ensemble, tandis que les normes DO178 ne s'appliquent qu'au logiciel de vol. Les deux normes sont reconnues par des autorités telles que la FAA et l'EASA.
ARP4754 a été développée et publiée par la SAE (Society of Automotive Engineers) en 1996. En 2010, la SAE a publié ARP4754A, qui correspond aux Guidelines for Development of Civil Aircraft and Systems. ARP4754A enrichit la notion de garantie de conception utilisée aux niveaux de l'aéronef et du système, et normalise également l'usage du terme « garantie de développement ». ARP4754 a été approuvée par la FAA en novembre 2011.
ARP4754 couvre l'ensemble du cycle de développement de l'aéronef, depuis l'identification des exigences jusqu'à la fin des processus d'intégration et de vérification. ARP4754 fournit un cadre d'abstraction pour l'aéronef, les systèmes et les composants. Pour la conception des composants, ARP4754 renvoie explicitement à la DO-178 et à la DO-254. ARP4754 met l'accent sur l'évaluation de la sécurité à travers différents processus tels que le développement, la conception et la vérification. Il convient toutefois de noter qu'ARP4754 n'inclut pas le périmètre spécifique du développement logiciel ou matériel électronique, des activités de sécurité en service, ni du processus de développement structural de l'aéronef.
Phases de conception
Revue de conception préliminaire (PDR)
La conception préliminaire est une phase importante du processus de développement logiciel. Durant la conception préliminaire, les exigences de haut niveau et les cas d'usage sont identifiés afin de former l'architecture du système. Des documents d'interface, de base de données et d'architecture, ainsi que des diagrammes de relations entre composants, peuvent être utilisés dans la conception. La conception préliminaire fournira une représentation visuelle du système en début de projet, sur la base de ces éléments. Elle pose également les bases des phases de conception plus détaillées qui suivent. Elle peut être vue comme une ébauche.
La revue de conception préliminaire (PDR) conclut la phase de conception préliminaire du projet. La PDR doit apporter une assurance suffisante pour permettre de poursuivre vers la conception détaillée. L'objectif de la PDR est de garantir que la conception préliminaire et l'architecture système de base sont complètes, et qu'il existe une confiance technique suffisante quant au respect des exigences dans les limites de budget et de calendrier.
Revue de conception critique (CDR)
La revue de conception critique (CDR) conclut la phase de conception critique du projet. Les conceptions finales sont présentées lors de la CDR au moyen d'analyses approfondies, de simulations, de schémas, de code logiciel et de données de test. La CDR garantit que le système peut passer au test et à la production. Elle établit également que les exigences en question peuvent être respectées dans les limites de budget et de calendrier. Les plans et spécifications complets qui en résultent fournissent une référence finale, complétant une référence produit initiale. La CDR doit être large en portée et détaillée.
Phase de conception finale
La phase de conception finale fournit les plans architecturaux et techniques détaillés de chaque composant du projet. Pour certains projets, il peut être nécessaire d'établir un rapport de conception finale. Les problèmes de conception identifiés doivent être résolus avant l'achèvement de la phase de conception finale. Les plans et rapports doivent fournir un niveau de détail suffisant pour permettre des estimations planifiées. Le rapport de conception finale doit inclure un calendrier actualisé, des estimations de coûts et les spécifications. La viabilité économique du projet doit également être confirmée. Toute modification effectuée durant la phase de conception finale est plus coûteuse que dans les autres phases. Elles doivent par conséquent être effectuées avec le plus grand soin.
SOI (Stages of Involvement)
Pour évaluer la conformité des projets à la DO-178B, des évaluations SOI sont menées par les autorités aéronautiques des pays concernés à différentes étapes du projet, telles que la planification, le développement et la vérification. Idéalement, un total de quatre revues SOI est prévu.
La première évaluation SOI porte sur la phase de planification des travaux de conformité de certification du projet. La deuxième revue SOI se concentre sur les phases de développement du projet. À partir du développement des exigences logicielles de haut niveau, elle examine si la conception, les exigences logicielles de bas niveau et le code source ont été produits en conformité avec la DO178B. La troisième revue SOI se concentre sur les phases de vérification. Ce ne sont pas seulement les activités de test, mais toutes les activités menées à des fins de vérification qui sont examinées. La quatrième SOI est l'évaluation de clôture, menée vers la fin du projet, examinant s'il subsiste des activités en suspens et si de nouveaux problèmes sont apparus depuis les évaluations précédentes.
Ce que la DO-178B attend des produits logiciels élaborés en phase de planification, c'est de s'accorder sur un ensemble commun de règles entre l'autorité et l'entreprise qui les met en œuvre, et de respecter cet ensemble de règles tout au long du projet. Autrement dit, en rédigeant les plans et normes, l'entreprise ne définit pas seulement ses propres processus, mais établit également les règles selon lesquelles l'autorité s'évaluera elle-même tout au long du processus de certification.
Auteur : Can Önal ([email protected])
