Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Pour construire le Système d’information :
Pourquoi ne pas copier les méthodes du logiciel embarqué ?
D’un exposé au Club des Maîtres d’ouvrage du SI
Article mis en ligne le 20 août 2009
dernière modification le 16 septembre 2014

par Laurent Bloch

Cet article a suscité une discussion. La contribution de Jean Kott et les réponses sont dans l’article suivant.

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, l’injection de carburant, 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 dispositifs techniques 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 ; lorsque le conducteur appuie sur la pédale de frein, cela n’actionne pas le circuit hydraulique de freinage, mais envoie à un ordinateur un signal et une demande de freinage, que le logiciel analyse pour déterminer si le freinage devra être effectué par un moteur électrique en inversion de polarité, par le système hydraulique, ou par les deux ; on imagine que le temps de réponse est une exigence forte pour un tel système.

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é.

Vous pouvez télécharger ici mon manuel de systèmes d’exploitation au format PDF :
Systèmes d’exploitation

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.