Veille technologique

pour les professionnels de l’industrie
S’abonner

S’inscrire à l’hebdo de la techno :

Rechercher sur Industrie & Technologies

Facebook Twitter Google + Linkedin Email
×

Systèmes embarqués ce qu'on attend du logiciel

|

Publié le à 00h00

Ergonomie, temps réel, sécurité, évolutivité... Le logiciel conditionne plus que jamais les performances d'une grande variété de produits. Aujourd'hui, on lui demande presque tout. Aux industriels d'en faire un élément clé de leur stratégie globale de qualité.

Janvier 1992 : un Airbus A320 d'Air Inter, effectuant la liaison Lyon-Strasbourg, s'écrase au mont Sainte-Odile. En cause : l'informatique de bord. Juin 1996 : la fusée Ariane 5 explose en plein vol. En cause : le logiciel du calculateur de vol. Juin 2003 : Sony Ericsson rappelle au Japon son téléphone mobile SO505i à appareil photo. En cause : un bug dans la fonction messagerie.

Ces incidents aux conséquences parfois dramatiques mettent en lumière le rôle vital du logiciel dans les systèmes embarqués. De sa qualité dépend non seulement le bon fonctionnement du produit qui l'embarque, mais aussi, dans bien des cas, la sécurité de l'équipement et/ou des personnes. On le voit : même des secteurs ultrasensibles comme l'avionique ou le spatial, soumis à des contraintes de conception draconiennes, ne sont pas totalement à l'abri d'un code erroné.

 

Des fonctions de plus en plus étendues

 

Or, avec la généralisation de l'électronique et du contrôle numérique, le logiciel embarqué se trouve aujourd'hui partout ou presque. Perceptible à travers l'interface Windows sur le PC, il se cache au coeur de nos objets les plus familiers : automobiles, montres, téléphones, lave-linge, cafetières, fours à micro-ondes, poupées et même cocotes minutes.

Parfois, ce sont des génies bénéfiques, comme ces elfes qui déclenchent l'airbag lors d'un accident de voiture, ou qui font que le pilote de l'avion pique en toute tranquillité un petit roupillon. D'autre fois, ils se présentent sous la forme de créatures grimaçantes capables d'empêcher les seniors de programmer leur magnétoscope ou de rappeler la dernière personne les ayant contactés sur leur mobile.

Non content d'être omniprésent, le logiciel voit son volume exploser, étendant sans cesse les fonctions du produit qui l'embarque et augmentant d'autant les risques de défaut et les points de vulnérabilité. Un téléphone mobile courant offre aujourd'hui des centaines de fonctions régies par des centaines de milliers de lignes de codes ! Les voitures actuelles intègrent plus d'électronique que les avions Airbus entrés en service il y a une vingtaine d'années.

Dans les secteurs sensibles comme le militaire, l'aérospatial, le nucléaire, les transports publics ou la banque, régis par des règles strictes de certification, la qualité du logiciel constitue une préoccupation ancienne. Elle tend à descendre dans les produits industriels et grand public. Partout, les industriels prennent conscience des répercussions négatives de la non-qualité. Rappeler des milliers de produits coûte cher en logistique et en réparation. Sans compter l'effet désastreux sur l'image de marque.

Faire de la qualité, c'est possible. Mais cela coûte cher. De l'avion à une cafetière, les enjeux ne sont pas identiques. Les moyens mis en oeuvre non plus. Ce qui fait dire à Claude Pinet, consultant sur ces questions, que la qualité du logiciel se résume souvent à une équation économique. « À chaque entreprise de définir son optimum en fonction de sa stratégie marketing et des exigences propres à l'application. »

La comparaison entre l'automobile et l'aéronautique illustre cette différence. Avant d'arriver dans la voiture, le système de freinage ABS a été développé vingt ans plus tôt pour l'avion. Quant au niveau de sécurité, c'est-à-dire l'assurance que le logiciel fasse bien ce qui est prévu, on est carrément à deux ordres de grandeur d'écart. Si la probabilité de panne reste inférieure à 10-9 dans l'avionique, l'automobile se contente en général de 10-7. Il est vrai que le logiciel de l'automobile n'est pas soumis à certification comme c'est le cas dans l'aéronautique. Les constructeurs automobiles sont donc leurs propres juges. Mais, dans ce domaine, la véritable sanction est d'ordre marketing : la qualité du logiciel n'est qu'une des facettes de la qualité totale, prônée par tous.

Objet de cours à Supélec, Supaéro, Télécoms Bretagne et autres écoles d'ingénieurs, la qualité du logiciel devient une composante essentielle de la démarche globale de qualité en entreprise. Il existe dans ce domaine cinq normes ISO. Mais elles ne définissent pas des standards de qualité. Elles se contentent de définir un modèle de référence pour le développement, le test ou la validation du logiciel. À chacun ensuite de le décliner en fonction de son métier, de son marché et de sa stratégie. Il existe aussi des recommandations de bonne pratique, issues souvent des retours d'expérience. Mais elles ne sont obligatoires que pour les certifications.

Chaque application requiert une architecture électronique et logicielle adaptée. Dans l'aéronautique, plusieurs processeurs remplissent en parallèle la même fonction, mais avec des algorithmes différents, codés par différents experts. Ils s'observent et s'élisent entre eux, éliminant l'éventuel fautif. Les différentes générations de métro automatique de Matra Transports, depuis le premier Val jusqu'à Météor, offrent une vitrine des technologies sécuritaires les plus raffinées : fonctions "ET" à base d'oscillateurs, microprocesseurs codés, logiciels autocontrôlés... jusqu'à la mise en oeuvre intensive de "langages à preuve formelle" comme le langage B, construits comme des théorèmes : le but est de prouver que telle ou telle conjonction (funeste) d'événements ne peut en aucun cas se produire. Autant de technologies plus ou moins lourdes à déployer mais où toute l'industrie de l'"embarqué" vient faire aujourd'hui "son marché"...

Dans cette quête de la qualité, le test occupe une place primordiale. Du niveau de cette opération dépendent à la fois la qualité et le coût du produit qui sera mis sur le marché. Dans les secteurs sensibles, l'usage est de procéder à des tests à 100 %. Peu importe le coût et le temps que cela prend. Ceux qui l'oublient en paient le prix fort. L'exemple d'Ariane 5 le démontre. Les ingénieurs ont repris pour le calculateur de vol le code développé et testé pour Ariane 4. Par manque de temps, ils ont choisi de ne pas le tester à nouveau. Erreur fatale !

 

L'ergonomie reprise par les spécialistes

 

Dans les produits grand public, les enjeux sont différents. Ils portent plutôt sur les prix, la concurrence et le besoin d'arriver vite sur le marché. Sauf dans certains secteurs comme l'automobile (où la sécurité demeure l'alpha et l'oméga), les contraintes économiques excluent le test exhaustif. Les industriels se permettent alors de "tenter le coup" en procédant seulement aux tests les plus importants. Quitte à se tenir prêts à rappeler le produit sur le marché en cas de déclaration de défaut. À l'image de ce que font NEC, Panasonic ou Sony Ericsson au Japon pour le téléphone mobile.

On demande beaucoup au logiciel. La norme ISO/CEI 9126 fixe six grandes fonctions de référence pour le produit ou service qui l'utilise. Au total pas moins de 21 critères sont explicités. « Selon l'application et la stratégie de l'entreprise, l'accent sera mis sur tels ou tels aspects », explique Claude Pinet.

L'ergonomie de l'interface homme-machine émerge comme un dénominateur commun fort. Plus le produit devient complexe, plus elle doit être soignée. Longtemps laissée entre les mains des techniciens, elle est reprise aujourd'hui par des ergonomes et des spécialistes du marketing, plus proches des utilisateurs. Si elle s'attache d'abord à la facilité d'emploi, elle peut aussi affecter la sécurité. Le crash de l'Airbus au mont Sainte-Odile le prouve. Officiellement, il est attribué à une erreur humaine. Dans la réalité, on soupçonne l'instrumentation d'avoir induit le pilote en erreur.

Du téléphone à l'automobile, nous sommes assaillis d'interfaces dites "intuitives". Pour le meilleur comme pour le pire. Quiconque utilise un système de navigation à bord d'une automobile actuelle s'en trouve émerveillé. Les taxis les plus blasés s'enorgueillissent. Les concepteurs ont eu le temps de défricher toutes les voies. Et d'éliminer les "fausses bonnes solutions", comme la commande vocale. Pour une raison simple : personne ne veut parler à son téléphone ou à sa voiture. Après bien des tâtonnements, les industriels ne trouvent rien de mieux que de transposer sur leurs produits les interfaces du PC ou de la télévision.

 

La maintenabilité, une pratique risquée

 

La sécurité, le temps réel et la maintenabilité sont trois autres critères forts de la qualité du logiciel. D'abord vécue comme une contrainte, la maintenabilité est de plus en plus utilisée comme une arme de marketing. Prenant exemple sur Microsoft, les grands industriels, animés par l'obsession d'arriver vite sur le marché, se donnent la liberté d'introduire des produits inachevés. Et peu importe si les premiers clients, transformés insidieusement en bêta-testeurs, essuient les plâtres. On leur proposera plus tard une nouvelle version de logiciel bien au point. On se souvient de l'appareil photo numérique Dimage de Minolta, dont l'exposition (ouverture plus vitesse) ne fonctionnait pas correctement avec le flash, ou de la Mégane dont les phares ne s'éteignaient pas à volonté.

Cette dérive pourrait se révéler dangereuse, avertit Claude Pinet. Car si Microsoft jouit d'un quasi-monopole, il en est différemment pour les fabricants d'appareils photo, de voitures ou de téléphones. À chaque industriel donc de bien peser les avantages de cette nouvelle pratique, mais aussi les risques.

SOMMAIRE

1. sûreté de fonctionnement Une affaire de moyens avant tout Page 48 2. Déterminisme Le temps réel n'accepte aucune approximation Page 52 3. Ergonomie Le PC impose son interface Page 54 4. Évolutivité L'automobile montre la voie Page 56

DIX CRITÈRES CLÉS DE QUALITÉ DU LOGICIEL

1. Validité (ou conformité) Aptitude à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications 2. Fiabilité (ou robustesse) Aptitude à fonctionner dans des conditions hors limites 3. Extensibilité Facilité de modification ou d'extension des fonctions demandées 4. Réutilisabilité Aptitude à être repris, en tout ou en partie, dans de nouvelles applications 5. Compatibilité (ou interopérabilité) Capacité de fonctionner en association avec d'autres logiciels 6. Efficacité Utilisation optimale des ressources matérielles en traitement, calcul ou mémoire 7. Portabilité Possibilité de transfert sur d'autres environnements logiciels et matériels 8. Vérifiabilité (ou testabilité) Facilité de préparation des procédures de tests 9. Intégrité (ou sécurité) Aptitude à protéger son code et ses données contre des accès non autorisés 10. Maniabilité Facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de correction

CINQ NORMES SUR LA QUALITÉ DU LOGICIEL

ISO 9000-3 Déclinaison de la norme ISO 9001 pour le système d'information des entreprises. ISO/CEI 12207 Définit un référentiel pour les processus de développement - une cinquantaine en tout (spécification, acquisition de données, conception, test...). ISO/CEI 1554 Définit un référentiel pour l'évaluation des processus d'ingénierie logiciel. Chaque processus est évalué par une note de maturité sur une échelle de 0 à 5. ISO/CEI 9126 Définit six caractéristiques clés, déclinées en 21 critères de qualité pour le produit ou service utilisant le logiciel. ISO/CEI 14598 Définit un référentiel d'évaluation des produits et services utilisant le logiciel.

Claude Pinet, Consultant CPI Conseil "La qualité reste difficile à mesurer."

Auteur de deux ouvrages sur la qualité du logiciel, Claude Pinet exerce son expertise sur le sujet depuis une dizaine d'années au sein de son cabinet CPI Conseil. « Les donneurs d'ordres, qui confient à l'extérieur le développement de leurs systèmes embarqués, ne sont pas, par inconscience, suffisamment exigeants sur la qualité du logiciel », constate-t-il. Pour cet ingénieur du Cnam, la difficulté vient du fait que le logiciel est quelque chose d'immatériel. « Dans le monde physique, on demande des niveaux de qualité précis et on sait les mesurer. Dans le logiciel, il faudrait aussi pouvoir s'appuyer sur des notions objectives. Mais là, c'est beaucoup plus difficile. »

Abonnez-vous et accédez à l’intégralité de la veille technologique

Commentaires

Réagissez à cet article

* Informations obligatoires

erreur

erreur

erreur