Nous suivre Industrie Techno

Une affaire de moyens avant tout

Jean-Charles Guézel
Concevoir des logiciels sûrs à 100 %, c'est possible ! Soit en s'attelant aux méthodes d'écriture "formelles", soit en blindant côté validation. Mais cela a un coût !

Le 4 juin 1996 : mission inaugurale de la fusée Ariane 5. Quarante secondes après son envol, le lanceur entame une trajectoire pour le moins curieuse jusqu'à... l'explosion finale, restée gravée depuis dans toutes les mémoires. Tout cela pour une ridicule erreur de programmation !

Car, après enquête, c'est bien la conclusion à laquelle sont parvenus les experts mandatés par le Cnes et l'ESA. « La panne s'explique par le fait qu'une variable liée à la vitesse horizontale du lanceur a dépassé une limite inscrite dans le logiciel d'un calculateur. Dès lors, il était impossible d'obtenir des données de guidage exactes et la perte de la mission devenait inévitable », peut-on lire dans le rapport d'enquête.

Si les erreurs logicielles auxquelles nous sommes quotidiennement confrontés se révèlent en général moins dramatiques, elles peuvent tout de même agacer. Pour preuve les commentaires de notre confrère L'Auto-Journal à propos d'un véhicule de haut de gamme récemment commercialisé : « Verrouillage centralisé des portières aléatoire, allumage des codes retardé, mémoire de position des sièges capricieuse, GPS inopérant... », relève le magazine. Des dysfonctionnements qui résulteraient de « problèmes de programmation » entre autres. Et ce n'est, hélas, qu'un exemple parmi beaucoup d'autres.

La sécurité de l'application

Faut-il s'inquiéter de ces dérives à l'heure où les logiciels tendent non seulement à piloter nos voitures (dispositifs de contrôle de trajectoire, de maintien de la distance de sécurité, de direction électrique...), mais gèrent également les données de nos cartes à puce et s'installent aux commandes de nos téléphones ? Sans doute. Mais le côté rassurant des choses, c'est que les industriels, eux aussi, apparaissent de plus en plus préoccupés par le problème.

Sûreté ? Sécurité ? Fiabilité ? Encore faut-il s'entendre sur les mots. « Un logiciel sûr, c'est un programme qui se comporte comme prévu dans les situations prévues », s'accordent à dire les professionnels. Même si se mêlent parfois à cette définition des notions proches, comme celle de robustesse, c'est-à-dire, en l'occurrence, la capacité à s'accommoder de certains événements non prévus au départ. « En général, l'idée qui vient à l'esprit lorsque l'on évoque la sécurité d'un logiciel, c'est le lien qu'elle peut avoir avec la sauvegarde des biens et des personnes. Ce n'est pas faux mais, le plus souvent, c'est sur l'image commerciale que l'effet des bugs est le plus désastreux », constate Patrice Labbé, PDG de Créalie, une société d'ingénierie et de conseils spécialisée dans l'informatique embarquée.

« Ce qui compte, c'est la sécurité de l'application », insiste pour sa part Jean-Michel Vray, responsable développement et marketing de Gérard Perrier Industrie, un groupe dont la filiale Geral exerce une importante activité d'études et de fabrication dans ce même domaine. « Et pour que l'application soit sûre, ajoute le responsable, il faut avant tout que le cahier des charges le soit, car il suffit alors de concevoir un logiciel aussi ressemblant que possible... » Plus facile à dire qu'à faire, d'autant qu'avec les possibilités d'intégration offertes par l'industrie microélectronique, les donneurs d'ordres ne se fixent plus guère de limites quant à la complexité des programmes.

La recherche du bug est trop coûteuse

« L'idéal, compte tenu des faibles possibilités de correction offertes a posteriori pour nombre de logiciels diffusés à large échelle, c'est que le premier jet soit parfait. Mais en pratique, n'importe quel développeur peut commettre des erreurs, admet Patrice Labbé. Il faut donc faire en sorte que les erreurs résiduelles restent bénignes : dans l'"embarqué", on a tout de même des exigences de base nettement plus élevées que dans la bureautique. »

Pour un utilisateur de composants logiciels, bien souvent, la sûreté se résume à une question d'équilibre : d'un côté faire bonne impression auprès des clients, de l'autre éviter tout retard de lancement synonyme de manque à gagner. « Les consommateurs vont systématiquement se précipiter sur les dernières nouveautés, quitte à prendre le risque qu'elles n'aient pas été entièrement débarrassées des anomalies. Et cela, les industriels en tiennent compte, regrette le PDG de Créalie. De fait, la recherche des bugs est une opération généralement jugée trop longue et trop coûteuse : alors qu'il faudrait y consacrer au moins 25 à 30 % du temps de développement, les clients nous limitent à 10 %. »

Rigueur mathématique pour le zéro défaut

Difficile, dans ces conditions, de parvenir au zéro défaut. Pourtant, les logiciels "sûrs de fonctionnement", cela existe bel et bien. Celui qui assure le pilotage de la ligne de métro automatique parisienne Météor, par exemple, n'a souffert d'aucun incident lié à l'informatique embarquée depuis sa mise en service, en 1998. Un résultat remarquable, à mettre à l'actif d'une méthode de conception d'origine française, sobrement baptisée "B". Son secret : un processus de développement à base mathématique capable de garantir que le logiciel résultant sera rigoureusement conforme aux équations de départ.

Même formalisme mathématique pour les langages dits "synchrones", comme Lustre (dérivé des techniques de traitement du signal) ou Esterel (orienté système de contrôle). C'est sur ce dernier que repose la plate-forme Scade, mise en oeuvre pour la conception et la vérification des commandes de vol de l'Airbus A380. La particularité de cet outil proposé par la société Esterel Technologies est de générer du code "correct par construction", prêt à être embarqué. La liste des clients de l'entreprise (Audi, Dassault Aviation, General Motors, Schneider, STMicroelectronics...) en dit d'ailleurs long sur les capa-cités de cet outil. Elle en révèle aussi les exigences en termes de coût et de complexité de mise en oeuvre. Tout le monde ne peut pas se le payer... Si bien que les sociétés de moyenne importance sont, la plupart du temps, dans l'obligation de faire appel à des langages moins sophistiqués, moins sûrs. D'où les problèmes de design et de validation évoqués précédemment.

Les incohérences de codage

En l'absence de méthodologie de validation universellement reconnue, chaque industriel mise en fin de compte sur son expérience et sur son savoir-faire. « Pour ce qui nous concerne, la réalisation du logiciel, implanté sur un microcontrôleur 16 bits, passe par l'élaboration d'un diagramme de contexte : en décrivant l'architecture globale du projet, ce document nous donne la vue d'ensemble nécessaire avant de pouvoir rentrer dans les détails. L'écriture se fait ensuite en C ou en C++, des langages structurants et générateurs de codes de bonne qualité », estime Jean-Michel Vray. D'autres sociétés auraient pu citer Java, un langage moins lourd que le C++ tout en étant lui aussi réputé sûr, notamment grâce au fameux gestionnaire de mémoire antisaturation appelé "ramasse-miettes".

Une fois la phase d'écriture achevée, se profile la rébarbative mais cruciale étape de validation. Chez Geral, c'est le logiciel expert Polyspace Verifier, de Polyspace Technologies, qui s'en charge. Objectif : traquer les incohérences de codage et tout ce qui pourrait générer des problèmes d'exécution (division par zéro, débordement de capacité mémoire, conflits d'accès...). Finalement, le passage sur des bancs de tests spécifiques, conçus directement à partir des spécifications du logiciel (de façon à s'affranchir de toute erreur de transcription), parachève la mise au point.

La conformité du programme aux spécifications du cahier des charges est une chose, l'obtention des certifications en est une autre. Et pas toujours des plus évidentes.

L'accès au code source

Dans l'aéronautique, c'est le standard DO178B, établi par la Radio Technical Commission for Aeronautics, qui fait force de loi. Au sens de cette norme, un logiciel est dit de niveau A lorsque l'on considère que son dysfonctionnement conduirait à une panne qualifiée de "catastrophique". Cette appréciation descend à "dangereuse" pour le niveau B, à "majeure" pour le C et à "mineure" pour le D.

Se mettre en conformité avec ce standard (ou d'autres), c'est non seulement une question d'applicatif mais aussi de système d'exploitation (OS, en jargon informatique). C'est la raison pour laquelle certains fournisseurs de noyaux temps réel, comme Accelerated Technology (Mentor Graphics), n'hésitent pas, le cas échéant, à fournir le kit de certification en même temps que l'OS. Une aide précieuse, comme l'est aussi le fait de mettre le code source à la disposition de l'utilisateur, à l'image de ce qui est pratiqué pour Linux. « La fourniture du code a eu des répercussions positives sur l'aspect sécurité des logiciels embarqués, ou du moins sur la perception qu'en ont les utilisateurs, remarque Vincent Sallez, directeur de la division systèmes embarqués de cet éditeur pour la zone Europe du Sud. Désormais, l'ingénieur voit ce qu'il y a dans l'OS et se sent moins dépendant de notre support technique. Et puis le code est devenu une véritable vitrine, émaillée de notes didactiques qui mettent en avant certains points clés. »

Pour le produit vedette d'Accelerated Technology, à savoir Nucleus, l'un d'entre eux est le support du mécanisme MMU (Memory Management Unit) : « Un dispositif très important au plan sécurité car capable de cloisonner automatiquement et sans faillir l'utilisation de la mémoire en fonction des tâches », précise Vincent Sallez. Reste que tous les microprocesseurs et microcontrôleurs ne se montrent pas tous assez intelligents pour en profiter.

LES POINTS CLÉS

Opter, en phase de conception, pour les méthodes "formelles" et les langages "synchrones", à même de générer des codes "corrects par construction". Miser sur la gestion MMU (Memory Management Unit) : un cloisonnement strict de la mémoire en fonction des différentes tâches. Consacrer si possible 30% du temps total de développement à la validation : couverture de code, tests au moyen de bancs spécifiques...

UN APPAREIL DE CONTRÔLE FIABLE

Nul besoin de désosser un train ou une centrale nucléaire pour tomber sur un système d'exploitation temps réel performant. Il suffit pour cela de regarder ce qu'il y a au coeur de l'ADTS (Air Data Test Set) 505, un simple appareil de contrôle destiné aux techniciens de l'aviation civile. Il est vrai que dans ce domaine, on ne plaisante pas avec la sécurité de fonctionnement. Reposant sur le noyau Nucleus Plus d'Accelerated Technology, cet instrument construit par la société britannique Druck a pour tâche de vérifier le bon fonctionnement de l'instrumentation embarquée dans les aéronefs. Sur quels critères Druck a-t-il retenu ce noyau : « La fiabilité qu'il a démontrée lors des tests, l'accessibilité du code source et l'important retour d'expérience relatif au processeur cible [un coeur Motorola 68332] », répond le fabricant.

COMMENT TRAQUER LES BUGS ?

Selon Bence Molnar, ingénieur de développement chez Créalie, il y au moins cinq grandes règles à respecter pour traquer les bugs dans les plans de validation logicielle. 1. Identifier les zones à forte contrainte temporelle (gestion de protocole de communication par exemple) et se concentrer sur les tests aux limites des spécifications. 2. Explorer toutes les phases de la vie du produit en provoquant des changements rapides de mode de fonctionnement, sans forcément respecter l'ordre logique des choses. 3. Enchaîner des fonctionnalités très proches, ces situations étant parfois génératrices d'erreurs. 4. Porter un effort particulier sur les tests comportant des perturbations physiques externes (alimentation, entrées/sorties), de préférence hors des limites spécifiées. 5. Ne rien laisser passer : vérifier que l'exécution d'un scénario destiné à tester une fonctionnalité particulière n'empêchera pas la détection d'une anomalie a priori sans rapport.

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

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

Bienvenue !

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