La création de logiciels d’avionique

Méthodologie de définition des exigences et de conception pour les logiciels d’avionique

Figure 1. Le LGCS dans son contexte opérationnel

Le développement de logiciels d’avionique est grandement contraint par la norme DO-178C [1] (et son équivalent européen ED-12C). À notre connaissance, aucune méthodologie établissant les exigences de spécification et la conception de logiciels selon la norme DO-178C n’a été rapportée dans la littérature. Par conséquent, nous en avons défini une. Nous donnons un aperçu simplifié et général de cette méthodologie à la Figure 2. Le processus débute quand un ensemble d’exigences générales de système et de sécurité est alloué au logiciel (SRATS – system and safety requirements allocated to software). Le processus de spécification des exigences comprend le développement (spécialisation et décomposition) de ces SRATS en exigences logicielles de haut niveau (HLR – high-level requirements). Un examen des HLR compare ces exigences aux SRATS afin de vérifier que leur sens est bien conservé par les HLR de manière à bien diriger le processus de conception de logiciels. Le processus de conception de logiciels comprend la définition de l’architecture logicielle et la spécification des exigences logicielles de bas niveau (LLR – low-level requirements). Les LLR et l’architecture logicielle sont conçus à partir des HLR spécifiés et servent à la mise en œuvre du code source.

Figure 2. Déroulement général de la méthodologie proposée

Bien que les activités soient séquentielles, la norme DO-178C les décrit comme un moyen de favoriser une approche rigoureuse visant à créer un produit sûr. Néanmoins, nous avons organisé les actions à l’intérieur même de ces activités pour obtenir des cycles itératifs et incrémentiels qui mènent progressivement aux spécifications et à la conception d’exigences logicielles permettant de diriger les phases subséquentes du processus de développement : le codage et la vérification.

Élaborer les HLR, les LLR et l’architecture logicielle

Les systèmes avioniques sont spécifiés en langage naturel [2–4]. Ainsi, notre méthodologie considère que les SRATS et les HLR sont spécifiés en langage naturel. Cependant, le langage naturel, en raison de ses ambiguïtés inhérentes, n’est pas une spécification appropriée pour réaliser des analyses et vérifications fondées sur les exigences [5]. Par conséquent, avant d’affiner et de décomposer les SRATS, il faut en faire une vérification manuelle afin de résoudre les ambiguïtés, les incohérences et les conditions non définies. C’est ce qui a été fait pour la spécification du LGCS. Pour cette spécification, nous avons utilisé comme SRATS les descriptions d’un train d’atterrissage classique à configuration en tricycle, présenté à la référence [6]. Ces descriptions ont été rédigées en langage naturel et présentaient plusieurs problématiques. Nous avons donc commencé par les corriger et les améliorer avant d’élaborer les HLR pour le LGCS. Afin d’éviter le même genre de problème dans la spécification des HLR, nous avons eu recours à un langage naturel contrôlé. Il fallait donc spécifier les exigences de manière cohérente sous forme d’énoncés sur la façon dont le logiciel modifie un ensemble de variables contrôlées (ou variables que le logiciel peut modifier directement) en réponse aux modifications d’un ensemble de variables observables (ou variables d’entrées du logiciel). Le Tableau 1 décrit un sous-ensemble de HLR élaborés à partir des SRATS.

Tableau 1. Exemples de HLR pour le LGCS

La norme DO-178C souligne l’importance d’éviter la complexité dans le processus de conception. Par conséquent, nous avons incorporé des principes de génie logiciel qui aident à gérer la complexité et à promouvoir la vérifiabilité, comme la modularité et l’encapsulation [7]. Le résultat est reproduit dans le diagramme de composants UML à la Figure 3. Nous avons commencé par choisir un style architectural conforme aux fonctionnalités attendues du LGCS. La correspondance la plus proche était le style architectural Process Control [8], où un système détermine, à partir d’un ensemble d’entrées, un ensemble de sorties qui produiront un nouvel état de l’environnement. Nous avons ensuite pu définir les composants logiciels qui réaliseraient les fonctionnalités exprimées dans les HLR. Chaque HLR a été attribué à un sous-ensemble de composants, comme indiqué à la Figure 3.

Figure 3. Architecture du LGCS

Deux spécifications LLR parallèles ont été créées : une spécification textuelle en langage naturel (puisqu’il s’agit d’exigences) et une spécification basée sur les modèles utilisant des machines à états UML (pouvant être considérée comme la conception logicielle détaillée). Pour ce qui est de la spécification textuelle, nous avons eu recours à la même stratégie de langage naturel contrôlé que celle utilisée pour les HLR. Le tableau 2 décrit un sous-ensemble de LLR textuels.

Tableau 2. Exemples de LLR pour le LGCS

La Figure 4 est tirée de la spécification basée sur les modèles et elle montre une machine à états UML équivalente aux LLR du Tableau 2.

Figure 4. Extrait de la machine à états UML pour le composant CommandeSéquentielle

Discussion

Nous avons élaboré les spécifications et la conception du LGCS conformément à la norme actuelle sur le développement de logiciels d’avionique (DO-178C). Nous les avons construites de manière itérative, en les faisant vérifier par plusieurs experts du domaine. Nous résumons nos observations du processus global en quatre points :

1. Qualité et granularité des SRATS. Au début du processus, les SRATS comportaient plusieurs incohérences, ambiguïtés et libellés confus. Nous avons dû les corriger et les clarifier avant de poursuivre l’élaboration des HLR. Ainsi, plus les SRATS sont clairs, précis et complets, plus le travail de l’équipe de développement de logiciels est facilité.
2. Langage utilisé pour la spécification des exigences. Nous avons utilisé une forme de langage naturel contrôlé pour les HLR et les LLR afin d’éviter les ambiguïtés. Les LLR ont également été spécifiés à l’aide de modèles de conception. Spécifier les HLR à l’aide d’un langage formel reste un défi et s’inscrit dans des travaux futurs qui viseront à appuyer la vérification des exigences.
3. Granularité des LLR. Selon la norme DO-178C, les LLR doivent être très détaillés afin de permettre la mise en œuvre du code source. Cela peut induire en erreur lorsqu’on essaye d’exprimer des conditions aussi proches que possible du code. Toutefois, la norme DO-178C requiert une séparation plus grande entre les LLR et le code que ce que le pseudocode ou les langages d’action peuvent offrir. Il a donc été difficile d’élaborer les LLR du LGCS avec un niveau de granularité approprié.
4. Traçabilité bidirectionnelle. Nous avons utilisé des blocs de commentaires dans les modèles de conception pour assurer une traçabilité en amont de l’architecture logicielle et des LLR à leurs HLR sources (voir les figures 3 et 4). Cependant, la traçabilité en aval, c’est-à-dire la liaison des HLR aux LLR résultants, également requise par la DO-178C, ne pouvait se faire avec les modèles de conception.

Bien qu’il s’agisse d’un travail en cours, nous avons rendu les spécifications et la conception du LGCS publiques et à la disposition des chercheurs. Ce faisant, nous permettons à la communauté des chercheurs de l’utiliser à titre de spécification logicielle de référence pour l’analyse de différents problèmes d’ingénierie dans l’industrie de l’avionique et l’évaluation des solutions proposées.

Information supplémentaire

Pour plus d’information sur cette recherche, consulter l’article de conférence suivant :

Andrés Paz et Ghizlane El Boussaidi. Building a Software Requirements Specification and Design for an Avionics System: An Experience Report. Actes du SAC 2018 : ACM Symposium on Applied Computing, Pau, France, 9 au 13 avril 2018 (SAC 2018). DOI: 10.1145/3167132.3167268