Pourquoi ne pas copier les méthodes du logiciel embarqué ?

#Sommaire-

Le 6 juillet 2009 le Club des maîtres d'ouvrage des Systèmes d'information a reçu Monsieur Jean-François Salessy, Directeur du département conception intégration et validation des architectures électronique moteur et liaison sol chez PSA Citroën, pour un exposé sur le thème Processus et méthodologies de tests appliqués à l'électronique embarquée dans une voiture. Voici les grandes lignes de ce qui m'en a le plus impressionné.

Logiciel embarqué : méthodes de conception et de réalisation

Une auto contemporaine comporte une quarantaine d'ordinateurs, pour contrôler par exemple le freinage, l'antipatinage, le fonctionnement des airbags, la pression des pneus, l'adaptation de la traction et du freinage aux conditions atmosphériques, etc. Pour un gros modèle avec plus de gadgets ce seront quatre-vingt ou une centaine d'ordinateurs. Sur un véhicule hybride c'est le système informatique qui détermine si le moteur à combustion doit se mettre en marche, quelle répartition du travail doit s'établir avec le moteur électrique, si le freinage est effectué par un moteur électrique en inversion de polarité, par le système hydraulique, ou par les deux.

Certains constructeurs, Mercedes par exemple, ont envisagé de réduire cette prolifération électronique en centralisant tous les traitements sur un seul ordinateur plus puissant : le résultat n'a pas été concluant, notamment pour des raisons d'encombrement. En effet bien qu'une voiture soit pleine de vide, il n'y a de place nulle part.

On imagine bien que pour certains au moins de ces ordinateurs une panne ne serait pas tolérable. La source de panne la plus difficile à identifier et à corriger est le logiciel, dont les procédures de test et de vérification faisaient l'objet de l'exposé.

Une autre contrainte forte s'impose à la conception des logiciels indispensables à cette pléiade d'ordinateurs : le délai de production. Les constructeurs automobiles les mieux organisés, comme Toyota, ont réduit le temps de conception d'un nouveau modèle à un peu plus d'un an, il faut donc que le logiciel soit prêt dans le même laps de temps.

Développer une telle quantité de logiciels aussi complexes dans un délai aussi court n'est possible que par le recours à des méthodes propres à éliminer la plus grande part des incertitudes inhérentes à la programmation, notamment :

utilisation de matériels éprouvés et déjà testés, pas de prototypes ;
de même, utilisation de composants logiciels éprouvés et largement testés par le service des études amont.

En fait, la réalisation de logiciels selon ces principes revient pour l'essentiel à de l'assemblage de composants existants, ce qui signifie, sans sous-estimer la complexité de ce travail d'assemblage, que la plus grande part du développement proprement dit a lieu lors des études amont. Ces études comprendront éventuellement la spécification des composants logiciels au moyen d'une méthode formelle comme la méthode B, ce qui procure une grande certitude de justesse du programme, mais à un coût élevé.

Cette réduction drastique des incertitudes permet de prévoir des délais assez précis pour chaque opération, et donc d'établir des plannings détaillés et une véritable gestion de projet. C'est ainsi que les développements peuvent être réalisés dans les délais prévus.

Un autre résultat de cette méthode de conception et de réalisation est une spécification détaillée du logiciel, avec les avantages qui en résultent pour les tests, l'intégration, la maintenance, la certification, l'évolution.

Pourquoi ne pas procéder ainsi pour les Systèmes d'information ?

Les avantages de la méthodologie de développement exposée par Jean-François Salessy sont vraiment très séduisants :

délais de réalisation exacts et respectés ;
spécification du logiciel précise et respectée ;
maintenance facilitée.

Alors, dira-t-on, pourquoi ne pas procéder ainsi pour tous les logiciels, et notamment pour le Système d'information utilisé pour la gestion des entreprises ?

Plusieurs différences significatives entre logiciels de gestion et logiciels embarqués s'y opposent.

Notons d'abord une différence de coût : il faut accorder tout son poids au fait que la plus grande part du développement proprement dit d'un système embarqué a lieu lors des études amont. Ces études amont n'entrent pas dans le planning, mais elles représentent un volume de travail, et donc un coût, considérables. À quoi s'ajoutent les tâches d'intégration. On estime généralement que les coûts de développement tout compris sont supérieurs d'un ordre de grandeur à ce que l'on observe en gestion, pour des logiciels embarqués dont le niveau critique est celui de l'industrie automobile (c'est-à-dire plus bas que pour la navette spatiale, mais plus élevé que pour une machine à laver).

Seconde différence notable : les caractéristiques d'un modèle de voiture, dès lors qu'il est mis en production, sont stables, et le logiciel qui lui permet de fonctionner n'évoluera pas de façon significative. Il y aura quelques mises à jour de détail, de même qu'il y aura quelques modifications de carrosserie, mais en gros la voiture et son logiciel resteront les mêmes. Alors qu'un logiciel de gestion est soumis aux évolutions de son domaine d'application, que ce soit par les innovations législatives du parlement ou par les bouleversements des marchés, qui peuvent remettre en question la structure logique des traitements. En bref, cela change sans arrêt.

Troisième différence : les logiciels embarqués sont installés sur de petits ordinateurs spécialisés, dont le coût unitaire est forcément faible puisqu'ils devront être déployés à des millions d'exemplaires. De ce fait les caractéristiques de la plate-forme matérielle sont fixées une fois pour toutes. Tandis qu'un logiciel de gestion devra fonctionner sur des plates-formes soumises à des évolutions fréquentes, en fonction des volumes de données et des conditions économiques.

Pour conclure, si les architectes de systèmes d'information souhaitent profiter des avantages des systèmes embarqués pour leurs propres logiciels, il faut qu'ils acceptent de payer dix fois plus cher et de renoncer à toute évolution fonctionnelle significative et à toute modification du matériel. En un mot c'est impossible.