• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 05/12/2019

Lancez-vous dans la génération automatique de code et la qualification d’outils

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Aujourd’hui, la génération automatique de code et la qualification des outils sont des éléments clefs qui permettent aux industriels de développer des logiciels embarqués critiques de plus en plus complexes. Cela permet aussi de maîtriser la production de gros volumes de lignes de code, dans des délais très courts et à des coûts de revient très compétitifs pour ce type de produit.

L’utilisation d’outils logiciels qualifiés DO-178 : un avantage compétitif avéré

Les outils logiciels

Besoin d’outils logiciels pour automatiser les activités
Les besoins en outils logiciels pour automatiser les activités

Le DO-178C précise les règles à respecter pour le développement des logiciels avioniques. Il impose en particulier de satisfaire un ensemble d’objectifs de vérification. L’atteinte de ces objectifs nécessite beaucoup d’efforts de développement et de vérification, mais c’est le prix à payer si on veut obtenir des logiciels fiables. Et surtout avec une sûreté de fonctionnement compatible avec la criticité de l’équipement.

Cependant, pour rester dans la compétition, l’industrie aéronautique doit réduire les délais de production et les coûts de développement de ses logiciels avioniques. Pour répondre à ce besoin, les industriels du secteur ont choisi d’utiliser, massivement, des outils logiciels dans le but d’automatiser des activités du cycle de vie. Cette stratégie a été mise en œuvre dès le début des années 90.

Des outils logiciels sont donc utilisés pour remplacer des activités manuelles dans toutes les phases du cycle de vie du logiciel.

Les outils pour automatiser le codage

Logiciel avionique "correct par construction"

L’automatisation améliore l’efficacité de production des logiciels.

En particulier :

  • on accélère le cycle de développement et de modification des logiciels ;

  • on est capable de produire une quantité beaucoup plus importante de code dans des délais très courts. C’est un avantage considérable pour des systèmes dont la mise au point nécessite beaucoup d’itérations, ou bien pour le traitement de grandes quantités de données (structures de données, séquenceur d’entrées/sorties, bases données…) ;

  • l’utilisation de notations formelles, nécessaire pour le traitement de données par des outils, permet de lever des ambiguïtés qui seraient présentes avec une notation informelle (texte…) ;

  • on élimine la plupart des erreurs de codage dues au codage manuel. En particulier, on élimine les régressions ou les effets de bords lors des modifications du programme ;

  • on garde le même niveau de qualité durant toute la durée de vie du logiciel. C’est très important pour des logiciels avioniques dont la durée de service dépasse les 40 ans.

Aujourd’hui, les industriels utilisent massivement les outils logiciels. Pour autant, peut-on faire totalement confiance dans les résultats produits par ces outils (les sorties de l’outil) ?

Qualification des outils logiciels

La qualité des outils peut être variable et est dépendante du fournisseur. De plus, il est difficile de faire totalement confiance dans les outils logiciels, car on n’a jamais de garantie absolue qu’un logiciel est exempt d’erreur. Le zéro bug n’existe pas en génie logiciel et la présence d’effets de bords (obtention d’un résultat correct par erreur), de régressions (modifications du logiciel non maîtrisées), de fonctions non attendues (exigences dérivées non identifiées, l’outil fait plus que ce qui est prévu dans ses exigences) est tout à fait possible…

Principes de qualification

On peut qualifier un outil logiciel pour augmenter le niveau de confiance. Cela ne veut pas dire pour autant que l’outil est exempt d’erreur. Mais on aura apporté la démonstration qu’il a atteint un degré de qualité compatible avec la sûreté de fonctionnement demandée.

Cette démonstration sera valide dans le contexte de certification d’un logiciel embarqué donné. L’utilisation d’un outil déjà qualifié pour un autre logiciel embarqué nécessitera de réévaluer la qualification.

Alléger la charge de vérification du logiciel embarqué

Quand doit-on qualifier un outil ?

La qualification d’un outil est nécessaire seulement si on ne vérifie pas les sorties de l’outil (résultats produits par l’outil). Par exemple, cela permet d’éliminer ou de réduire des activités de vérification sur un logiciel embarqué produit automatiquement, qui seraient très fastidieuses et très coûteuses (activités manuelles). Ainsi, on réduit les délais de modification des logiciels embarqués en supprimant des revues de code, des vérifications ou des tests... que l’on devrait faire à chaque modification du logiciel.

Au final, la qualification permet d’obtenir un niveau de confiance dans l’outil équivalent aux activités de vérification que l’on aura éliminées. Le niveau de confiance est donc associé à la criticité du logiciel embarqué (au niveau de sûreté de fonctionnement demandé).  On sera très rigoureux pour les logiciels les plus critiques, comme les commandes de vol, le freinage, les moteurs… donc, le processus de développement et de vérification des outils qui vont automatiser la production de ce logiciel sera aussi très rigoureux.

Par conséquent, l’utilisation d’un outil déjà qualifié, dans un nouveau contexte (pour un autre logiciel avionique), nécessitera de requalifier cet outil. Concrètement, il s’agit de réévaluer la qualification.

Classification des outils et critères de qualification

Les outils logiciels utilisés dans le contexte aéronautique (DO-178) sont classés en fonction de leurs impacts sur la sûreté de fonctionnement (Safety).

Si une erreur dans l’outil peut se propager jusque dans le code embarqué, alors l’outil est classé comme « outil de développement », c’est-à-dire critère 1. Pour ce type d’outil, le processus de développement est équivalent à celui d’un logiciel embarqué.

Si une erreur dans l’outil peut empêcher la détection d’une erreur dans le code embarqué, alors l’outil est classé comme « outil de vérification » c’est-à-dire critère 3. Pour ce type d’outil, le processus de développement de l’outil est limité à la vérification du comportement de l’outil en regard de ses exigences opérationnelles.

Niveau de qualification (Tool Qualification Level)
Niveau de qualification (Tool Qualification Level)

Les critères et la criticité du logiciel permettent de définir le niveau de qualification d’un outil qui va de TQL1 pour le plus rigoureux à TQL5 pour le moins rigoureux. Le document DO-330 « Tool Software Qualification Aspects » décrit les processus et les objectifs à atteindre en fonction du niveau de TQL.

Certains outils de vérification particuliers, comme les outils de preuve formelle qui apportent une confiance supplémentaire, permettent d’éliminer ou de réduire d’autres activités (développement ou vérification) et sont classés comme « super outils de vérification » c’est-à-dire critère 2. Dans ce cas, le processus de développement de l’outil sera plus exigeant que pour les outils critère 3.

Précautions pour le développement d’outils qualifiés

Le choix d’utiliser un outil pour automatiser une activité du cycle de vie et de le qualifier doit être déterminé dès le début du développement du logiciel embarqué. On ne peut pas développer un outil et à la fin décider de le qualifier, ça ne marche pas comme ça… En effet, pour qualifier un outil, il est nécessaire d’apporter les preuves que celui-ci a été développé et vérifié conformément à des processus qui ont été préalablement approuvés par une autorité indépendante (par exemple l’EASA).

De plus, il faudra disposer de données du cycle de vie pour montrer que l’outil est bien conforme à ses exigences. L’ensemble de ces contraintes font qu’il est quasi impossible de qualifier certains outils critère 1, comme des compilateurs, par exemple. Toutefois, certains outils du commerce (COTS), classés critère 3, peuvent être qualifiés en tant qu’outils de vérification.

Bien utiliser des outils logiciels de génération automatique de code

Générateur automatique de code

Le GAC permet de produire le code source correspondant au modèle ni plus, ni moins (pas de fonction non attendue)
Le GAC permet de produire le code source correspondant au modèle, ni plus, ni moins (pas de fonction non attendue)

Un générateur automatique de code (appelé GAC, ou ACG en anglais) est un outil logiciel qui permet de transformer un modèle vers du code source comme de l’Assembleur, du C, de l’Ada… (langages les plus répandus pour les systèmes embarqués). En général, le code source produit automatiquement est compilé et linké avec d'autres sous-ensembles logiciels, (comme l’OS, le démarrage, le téléchargement, la gestion des pannes…) pour former le logiciel embarqué d’un système donné. Ce logiciel pourra ensuite être exécuté sur une plateforme matérielle cible (par ex. un calculateur, un simulateur, un objet IoT…).

Le comportement fonctionnel du code source produit sera donc strictement équivalent à celui défini par le modèle. D’ailleurs, si le modèle est fonctionnellement incorrect (qu’il s’agisse d’une erreur, d’un effet de bord…), le code produit automatiquement aura le même comportement erroné que le modèle... On peut écarter facilement les erreurs de codage (bug…) pour se concentrer sur la mise au point de la fonction dans le modèle. Les erreurs se concentrent plutôt au niveau du modèle. D’ailleurs, la présence d’erreur dans les générateurs de code est en général peu courante et peut survenir durant la mise au point du GAC ou lorsque les modèles à coder utilisent des constructions (combinaisons d’instructions) complexes pour lesquelles le GAC n’a pas été éprouvé.

Les GAC sont donc des outils logiciels fiables sur lesquels il est possible de s’appuyer lorsqu’on développe de logiciels/systèmes complexes. Beaucoup d’industriels utilisent des GAC. Concernant la qualification des GAC, on peut dire que le développeur aura toujours le choix entre vérifier le logiciel embarqué ou bien qualifier le GAC. Le choix de qualifier un GAC doit être évalué en fonction du profil du logiciel (nombre de modification, taille, complexité…).

Quand peut-on utiliser un GAC ?

On utilisera donc des GAC dès que :

  • la mise au point du logiciel nécessite beaucoup d’itérations ;

  • ou bien lorsqu’il s’agit de produire de grandes quantités de code ;

  • ou bien lorsque la structure du code est complexe ou peu lisible (adresse mémoires…).

C’est souvent le cas des applications fonctionnelles avioniques (alarmes, freinage, commande de vol, moteurs…).

Mais, comme indiqué précédemment, la qualification d’un outil (donc d’un GAC) n’est pas obligatoire. Dans le développement d’un logiciel embarqué soumis aux règles du DO-178, il est toujours important d’évaluer les gains liés à la qualification du GAC vis-à-vis des critères déjà évoqués ci-avant (nombre d’itérations pour mettre au point le logiciel, complexité, taille du code à produire…).

Le crédit de certification tiré de la qualification des outils est une particularité du domaine des logiciels aéronautiques. Il ne se décline pas de la même manière dans les autres domaines comme le spatial, l’automobile, le rail ou le nucléaire. Souvent dans ces domaines, la qualification des outils est plutôt une contrainte et dépend de la criticité du logiciel (si le logiciel n’est pas critique, pas la peine de qualifier…).

Développement basé sur les modèles

L’utilisation de modèles apporte de la rigueur et permet d’augmenter le niveau qualité du logiciel. Mais, comment bien utiliser les modèles pour en tirer un maximum d’avantages ?

Prenons le cas des modèles de bas niveau. Ce sont des modèles à partir desquels il est possible de produire directement le code source sans informations supplémentaires.

Garder la maîtrise du code est crucial pour assurer la sûreté de fonctionnement. Pour les logiciels niveau A (les plus critiques), on doit maîtriser le code objet. Plus le modèle utilisera des constructions de haut niveau, plus le code source équivalent sera complexe, à lire, à comprendre, à vérifier, à maîtriser…

Il faut aussi tenir compte des propriétés du hardware et de la programmation des circuits matériels (protocoles de communication, capacité des FIFO , temps maximum d’exécution, OS , E/S…).

Définir un « Usage domain » du formalisme compatible avec les exigences de certification et les contraintes du matériel est fondamental. Pour répondre à cette contrainte, les DSL (Domain Specific Language) sont généralement une bonne solution.

On ne pourra pas tout faire avec les modèles, ni utiliser toutes les propriétés et toute la puissance du formalisme, même si cela semble plus efficace lors de certaines phases du développement. Il est préférable de regarder l’efficacité globale du processus.

Les retours d’expériences dans plusieurs domaines tendent à démontrer que la définition de DSL simples et adaptés au domaine procure une solution globale efficace pour le développement de logiciels avioniques.

En résumé

Les processus de développement des systèmes embarqués se sont considérablement améliorés depuis les années 80. L’utilisation des outils de génération automatique de code a démontré son efficacité (pas d’erreur détectée après la certification sur les commandes de vol des Airbus).

Aujourd’hui, on cherche à utiliser les modèles à plus haut niveau pour réduire le nombre d’erreurs introduites lors du développement des systèmes. Les modèles permettent l’utilisation de la simulation, de preuves... On va donc détecter les erreurs fonctionnelles en amont plutôt que pendant la phase d’intégration pour laquelle les coûts sont bien plus élevés. Cependant, l’utilisation de plusieurs niveaux d’abstraction nécessite une grande maîtrise pour éviter les recouvrements.

Les erreurs sont cependant parfois externes et intentionnelles, dues à de la malveillance... Il faut que notre système soit robuste face à de telles agressions...

Exemple de certificat de réussite
Exemple de certificat de réussite