Nous suivre Industrie Techno

QUALITÉ DU LOGICIEL UNE ARDENTE NÉCESSITÉ !

Thierry Mahé
QUALITÉ DU LOGICIEL UNE ARDENTE NÉCESSITÉ !

© Esa ; D.R.

Des techniques issues de la recherche fondamentale relancent l'ambition du logiciel "sans fautes". Ce n'est pas trop tôt car, dans les systèmes embarqués, les bugs peuvent avoir des conséquences... explosives !

Les ingénieurs de Kourou gardent vivace à l'esprit l'échec du 4 juin 1996. Ariane V anéantie après 40 secondes de vol par l'un des bugs les plus coûteux de l'histoire informatique. La bévue résume à elle seule le best of du bêtisier numérique. C'est à la fois une erreur de spécification - la partie logicielle fautive, héritée de Ariane III, ne servait plus à rien sur ce nouveau lanceur -, une faute de robustesse - les conditions de vol au décollage différaient notablement entre les deux générations de fusées. Mais aussi un grand classique du débordement de mantisse (conversion d'une donnée de 64 vers 16 bits)... et un excès de confiance : la gestion d'erreurs de ce débordement avait été retirée pour accélérer le temps de calcul... Ironie méchante, ce bug, codé en ADA, le langage le plus sécuritaire qui soit, s'est gentiment moqué de la redondance matérielle : il s'est simplement produit à l'identique sur les deux gyroscopes !

La quête du logiciel "zéro défaut"

Les experts du logiciel critique sont intarissables sur les effets collatéraux de missiles ayant perdu tout sens de l'orientation. De même que les blogs du Net regorgent de récriminations sur les erreurs de jeunesse de telle console de jeux ou les ratés à l'allumage de tel système d'exploitation lancé à grands cris.

Le logiciel, comme activité industrielle, a longtemps eu une place à part, assimilé à un travail "artistique" plus qu'à une tâche d'ingénierie. On évoque le "style" d'un programmeur. Rarement celui d'un mécanicien.

Lui demandant beaucoup, on pardonnait à proportion au logiciel. Et les bugs récurrents des grands éditeurs suscitaient plus le quolibet qu'une sanction commerciale.

Or l'utilisateur devient sévère, plus particulièrement avec des objets comportant du « logiciel qu'on ne voit pas », c'est-à-dire les systèmes embarqués. Il est concevable pour l'esprit qu'un logiciel de comptabilité plante... Pas un lève-vitre !

Aujourd'hui, le problème de la qualité du logiciel devient criant. En particulier parce qu'il met en relief l'équation démoniaque qu'ont à résoudre les industriels : réaliser des produits toujours plus complexes dans un temps plus court. Or, quasiment toutes les fonctionnalités apportées à un nouveau modèle d'avion, un nouveau véhicule, résident dans le soft et dans le silicium.

D'autant qu'à ce paradigme cynique - achetez tout de suite, on vous le changera si ça ne marche pas - répond le coup de pied dans la fourmilière du logiciel libre. Qui clame que le bug n'est pas le péché originel et indélébile de l'écriture logicielle !

De fait, l'essor de Linux est moins le fait de sa gratuité - qui n'est qu'apparente - que de sa parfaite robustesse. La moindre portion d'un logiciel open source est passé au crible de milliers de programmeurs, la remontée d'erreurs est sans faille, la correction hyperrapide. Très révélateur, le fait qu'EADS Astrium ait "téléchargé sur le Net", puis "nettoyé" et certifié le noyau temps réel qui ordonnance l'exécution de ses logiciels de contrôle de satellites.

Les stratégies pour parvenir à un logiciel "zéro défaut" se sont, jusqu'à ces dernières années, fondées sur un triptyque : méthodologies de conception, usage de langages peu permissifs et tests systématiques. Bien sûr, ça marche. Mais insuffisamment. Pour aller vite, le respect quasi sacerdotal de méthodologies de spécification-conception génère de la lourdeur, bride la créativité, déresponsabilise le programmeur. Surtout, le carcan méthodologique ne garantit nullement que le codage final respecte les spécifications. C'est gênant dans un premier temps. Cela peut devenir catastrophique lorsque le logiciel est appelé à évoluer. Car celui-ci est loin d'être un produit éphémère. Le programme de contrôle châssis d'un véhicule demeure inchangé dans son principe aussi longtemps que le châssis lui-même. Soit quelques décennies...

De même, un langage comme ADA, qui a massivement été mis en oeuvre dans les projets de défense des années 1980-1990, a entretenu l'illusion d'une programmation sans défaut parce qu'astreignante. L'acmé de la rigueur. Mais trop lourd à mettre en oeuvre, rien qu'en termes de formation des équipes, il fait aujourd'hui pâle figure face au langage C, "piégeux", ambigu, peu "typé" mais d'une extraordinaire souplesse.

Traquer les erreurs intrinsèques du code

Enfin, les constructeurs ont cru se garantir de la faute grâce aux tests systématiques - tests unitaires puis d'intégration - réalisés par des techniciens spécialisés. Bien sûr, le test fonctionnel demeure la preuve in fine que le logiciel fonctionne et demeure la clé de voûte de la qualification. Le problème est que l'enrichissement fonctionnel des produits va de pair avec une explosion exponentielle des cas de figure à tester. Plus que jamais, le test exhaustif est un leurre. Comme de plus, c'est la phase finale de conception, c'est aussi elle qui encaisse tous les retards accumulés et, dans les faits, se voit sacrifiée sur l'autel du time-to-market.

Aujourd'hui, du moins dans le logiciel très critique comme celui de l'aéronautique, du spatial, de la défense, la tendance est à l'examen des "erreurs intrinsèques" du code. Soit, débusquer l'erreur de principe, indépendamment de la fonction que remplit le programme. Et ceci, sans avoir besoin d'exécuter le logiciel, mais par une analyse très poussée de son contenu. Le leader mondial de ce type d'outils, tout droit venu de la recherche fondamentale, est le Polyspace Verifier (du français Polyspace), qui fonctionne pour le langage C et ADA.

Alain Ourghanlian travaille au département Simulation et traitement de l'information pour l'exploitation des systèmes de production à EDF. Ce chercheur a surtout évalué, depuis 2000, cet outil sur les familles de codes les plus sécuritaires qui contrôlent les centrales nucléaires, comme les mécanismes d'arrêt d'urgence de la fission. « Ce sont généralement des programmes courts, coupés de la gestion du processus et déclenchés automatiquement. D'ailleurs, la vérification symbolique du code met en oeuvre des algorithmes très lourds, dont le temps d'exécution serait rapidement prohibitif sur plusieurs milliers de lignes. » En tout cas, le résultat semble parfaitement concluant puisque Polyspace va se généraliser dans différents services d'EDF et être adopté par l'IRSN (l'Institut de radioprotection et de sûreté nucléaire). À noter, et c'est crucial, qu'EDF ne développe généralement pas son informatique, mais définit des cahiers des charges et réceptionne le travail fait par des tiers.

En fait, le rôle de "vérificateur de codes", dans lequel sont passés maîtres EDF ou le CEA, va se généraliser dans l'industrie, notamment automobile. Le chercheur précise : « Cette analyse sémantique, et non pas seulement syntaxique, des programmes provient de l'analyse abstraite développée dans les années 1970, en particulier à l'ENS-Ulm par le professeur Patrick Cousot, puis poursuivie au sein de l'Inria dont Polyspace est une émanation. »

Comment ça marche ? En fonction d'un jeu de variables d'entrées, ou bien dans l'absolu, l'outil va "indiquer" des zones rouges, qui provoquent immanquablement une erreur (division par zéro, débordement d'indice...), des zones vertes (toujours dignes de confiance), des zones grises où le programme ne passera jamais (par exemple, tout ce qui suit « si 2 > 3 »...) et enfin des zones critiques, en orange, où l'erreur est possible mais pas certaine... Ces dernières soulèvent évidemment les problèmes les plus ardus puisqu'elles requièrent une expertise humaine. « Attention, souligne Alain Ourghanlian, en aucun cas ce type d'outils ne dit si le programme fait bien ce qu'on lui demande de faire ! Il ne détecte que des erreurs intrinsèques. »

À noter qu'au moins deux autres produits du marché, tous deux américains, remplissent, sur des principes un peu différents, le rôle de Polyspace. Ce sont Code Sonar et Coverity. Il faut aussi signaler que la théorie de l'interprétation abstraite a un domaine de couverture plus général encore que l'analyse syntaxique. Elle intervient dans la recherche d'erreurs de calcul sur des nombres flottants, par exemple dans les travaux d'Éric Goubault (logiciel Fluctuact) du CEA-List de Saclay. Ces erreurs de troncature interviennent en particulier dans des boucles de régulation où une mince erreur s'amplifie jusqu'à devenir aberrante. La recherche en matière d'interprétation abstraite est en pleine effervescence. Elle se prolonge, en particulier, dans le programme Astree (Analyse statique de logiciels temps réel embarqués).

Reste que, comme on vient de le voir, ces outils, aussi puissants soient-ils, ne démontrent en rien que le logiciel satisfait le cahier des charges. Et là, tout se passe dans la phase la plus amont, la spécification. Et dans la phase la plus aval, les batteries de tests.

Appuyer les tests sur des travaux théoriques

Sur le premier point, la philosophie qui remporte tous les suffrages se nomme l'UML (Unified Modeling Language ou langage de modélisation unifié). Elle est magnifiquement adaptée à la structuration d'un système complexe. Les diagrammes d'UML, en effet, de treize types différents, rendent compte de toutes les vues d'une entité et simplifient énormément le dialogue entre les différents métiers et intervenants d'un projet. L'UML est, par exemple, au coeur du consortium Autosar, qui définit l'architecture informatique des futurs véhicules (à partir de 2010).

Des méthodes plus spécifiques s'imposent dans le même temps comme le langage Esterel, d'origine française (travaux de Gérard Berry à l'École des mines puis à l'Inria). Ce dernier sert à spécifier de façon non ambiguë les processus parallèles que l'on trouve dans les algorithmes de contrôle et, surtout, apporte la preuve formelle que de telles configurations critiques ne se produiront jamais. Là encore, le succès d'Esterel Technologies, fondé sur ce langage, emporte un vif succès dans l'automobile, l'espace et le ferroviaire. En revanche, le langage B à preuve formelle mis massivement en oeuvre, et avec succès, par la RATP pour le métro automatique parisien semble en perte de vitesse.

Les méthodes de tests sont, de même, en train d'évoluer à grand pas et, surtout, de se doter d'un corpus théorique. C'était devenu impératif. Laurent Py préside la société française Leirios. Cette dernière met en oeuvre une technologie là encore issue de travaux théoriques, afin de générer automatiquement les procédures de test. Laurent Py explique : « Nous extrayons les données de n'importe quel modeleur du marché [outil logiciel apte à décrire un système avec des diagrammes UML] et, en fonction de la criticité que le programmeur affecte à certaines parties du processus, nous générons le script de tests le plus judicieux. Cette technique a d'abord fait florès dans la carte à puce et les téléphones mobiles. « En raison de l'explosion du nombre de fonctionnalités de ce type de produits. Mais aujourd'hui, nous travaillons sur l'immense marché des systèmes transactionnels, notamment bancaires. » De tels outils servent une productivité accrue. Ils ont aussi la vertu de rapprocher plus avant la programmation informatique des sciences exactes.

L'ENJEU

Les systèmes complexes, comme ceux de l'automobile, juxtaposent une pléiade de logiciels fournis par des tiers. Les constructeurs et ensembliers ont donc l'obligation de mieux définir, centraliser, codévelopper et valider le code à réception.

LES SOLUTIONS

Une meilleure spécification du système - En particulier grâce à l'UML (Unified Modeling Language) et à son pendant temps réel SysML, encore à ses débuts. Des produits de simulation de systèmes dynamiques (mécatronique) comme Simulink (Matlab) sont aussi précieux pour spécifier. La validation intrinsèque - C'est le sujet chaud du moment. Ce type d'outils analyse à la loupe la "chair" même du logiciel et non plus seulement sa structure syntaxique. Elle est appelée à se diffuser dans l'industrie, depuis les bastions de l'aéronautique et du nucléaire. Le test fonctionnel - A toujours été pratiqué, bien sûr, mais trouve ses lettres de noblesse grâce à des générateurs (très) intelligents de jeux de tests.

LE BUG N'A PLUS LE DROIT DE CITÉ. "CHRISTOPHE CANTENOT, CHEF DE PROJET DU LOGICIEL AVIONIQUE DE GALILEO CHEZ EADS ASTRIUM

Christophe Cantenot est responsable de l'équipe franco-allemande d'EADS Astrium (dix personnes en tout) qui développe le logiciel avionique (hors communications) des trente satellites de géolocalisation qui constitueront Galileo, rival européen de GPS.

I&T : En quoi vos développements marquent-ils une rupture technologique ? C. C. : Je vois trois innovations majeures. D'abord l'usage intensif du logiciel de vérification formelle Polyspace. Bien que notre logiciel temps réel soit beaucoup moins sécuritaire que celui d'un vol habité, les contraintes en disponibilité de service sont absolues : une exigence inédite. Le bug n'a plus le droit de cité. Ensuite, nous étrennons un noyau temps réel qui n'est pas un produit du commerce, mais du "libre". Nous avons téléchargé RTEMS sur le Net, avant de le nettoyer des parties inutiles et de le qualifier. Enfin, l'ensemble des programmes a été testé dans un environnement numérique, rendant compte des entrées sorties, des temps de réponses physiques, etc. Ce développement, 100 % EADS, est un outil fantastique ! Par exemple, on peut arrêter le temps, ou "réaliser" une orbite en seulement cinq heures ! Et surtout, en France comme en Allemagne, nous avons pu le tester de concert sur un satellite unique et... virtuel. I&T : Quelles leçons tirer de l'usage systématique d'un outil de vérification sémantique ? C. C. : Nous avons observé un mécanisme vertueux qui fait que le programmeur améliore la lisibilité et la qualité de son code en retour de l'analyse qu'en fait Polyspace. Prévoyant, avec l'usage, la réaction de l'outil, il écrira de façon telle qu'il y ait très peu "d'orange" - les zones de code qui peuvent éventuellement être fautives. C'est pourquoi nous avons mis cet outil entre les mains de tous les programmeurs, pas seulement du responsable qualité. Cette technique va, je pense, se généraliser hors aéronautique, espace et nucléaire. Nous avons aussi gagné en robustesse, c'est-à-dire la faculté du logiciel à fonctionner dans un environnement un peu différent. Important, sur des programmes appelés à durer au moins vingt ans ! Gain aussi en maintenabilité (une évolution locale du code n'affecte que peu ce qu'il y a autour) et en portabilité. Ne pas oublier le gain financier : plus tôt on teste, moins ça coûte.

AUTOSAR LE LOGICIEL AUTOMOBILE CONQUÉRANT

- Le consortium Autosar, allemand d'origine, auquel s'est ralliée l'automobile mondiale, promeut une architecture ouverte et modulaire dans laquelle des morceaux de codes dialogueront afin de réaliser des fonctions transversales : confort, sécurité, dépollution. - Surtout, Autosar ouvre le pré carré de l'automobile numérique (Bosch, Siemens et consorts) à une vaste communauté de tiers. Constructeurs et équipementiers devront apprendre un "nouveau" métier : valider le code des autres. - L'architecture fait la part belle à l'UML (conception par modèles) ainsi qu'à son pendant temps réel, SysML, gages d'excellentes spécifications. Le suédois Telelogic, parmi les premiers, vient de spécialiser son "modeleur" Rhapsody à l'environnement Autosar, pour des logiciels qui sortiront dès 2010.

vous lisez un article d'Industries & Technologies N°0886

Découvrir les articles de ce numéro Consultez les archives 2007 d'Industries & Technologies

Bienvenue !

Vous êtes désormais inscrits. Vous recevrez prochainement notre newsletter hebdomadaire Industrie & Technologies

Nous vous recommandons

AUTOSAR : UNE RÉVOLUTION SE PRÉPARE !

AUTOSAR : UNE RÉVOLUTION SE PRÉPARE !

- Les concepts de standard et d'interopérabilité, qui ont fondé l'informatique moderne, entrent en fanfare dans l'automobile. Un immense progrès[…]

FlexRay va booster l'électronique automobile

FlexRay va booster l'électronique automobile

Plus d'articles