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 :

Logiciel embarqué vs. SI d’entreprise
Article mis en ligne le 31 octobre 2009
dernière modification le 5 juillet 2024

par Éric Gressier, Jean Kott, Laurent Bloch, Michel Volle

Cet article rapporte une discussion déclenchée par l’article Pourquoi ne pas copier les méthodes du logiciel embarqué.

Texte de Jean Kott

Pourquoi ne pas copier les méthodes des logiciels embarqués ?

Remarques de Jean KOTT relatives à l’article de Laurent Bloch sur le même sujet.

Quelques caractéristiques des systèmes embarqués

J’admets comme embarqué tout système informatique, logiciel et matériel pilotant ou contrôlant le fonctionnement d’un dispositif physique dont les lois de comportement et d’évolution sont représentables par des règles en nombre fini formalisables sous forme d’équations ou de formules algébriques. Véhicules, systèmes industriels et asservissement divers entrent en général dans cette catégorie.Ce genre de système a une grande autonomie et n’interagit avec l’humain qu’au travers de quelques individus bien formés et particulièrement compétents.

Leur domaine et leur périmètre sont connus de manière rigoureuse : la mathématique permet, à partir des équations de comportement de connaître de manière précise les valeurs possibles en entrée et en sortie ainsi que leurs limites.

Le référentiel équationnel modélisant l’ensemble constitue un étalon de référence pour mesurer de manière juste et précise la qualité du système : preuves ou vérifications par relecture sont relativement facile à mener et les jeux d’essais sont aisés à produire automatiquement car l’on sait, pour chaque donnée en entrée, le résultat que l’on doit attendre (les formules et équations de modélisation sont là pour ça). Le déterminisme du système est total.

Le système est toujours cohérent avec la réalité qui l’entoure car l’acquisition des données est en temps réel et automatique (pas de discontinuité dans la chaine acquisition/traitement/sortie).

Le système est très souvent gouverné par les données. Les flux de contrôle en sont minimes et ne provoquent que des changements d’états très mineurs et n’entraînant que peu de complexité supplémentaire. Ce point est important car il existe quelques cas de systèmes embarqués ou le flux de contrôle est important. Dans un tel cas, la mise au point du système est beaucoup plus douloureuse (j’ai expérimenté ce genre de cas). et les méthodes classiques de développement de systèmes embarqués peuvent même être mises en défaut.

Le système est invariant dans le temps : placé dans les mêmes conditions à plusieurs époques différentes, le système aura toujours le même comportement. Cette propriété est, par ailleurs, une condition suffisante de son déterminisme. Ces propriétés permettent d’avoir une mesure précise de l’écart entre la réalité du système et ce que dit la théorie. Le « bruit » est donc bien contrôlé.

Quelques caractéristiques des systèmes d’informations d’entreprise.

On est dans un univers à l’opposé de ce qui est dit au paragraphe précédent, sauf peut-être chez les industriels baignant déjà dans une culture scientifique et technique. Il ne faut voir aucune critique ni jugement de valeur dans ce qui pourrait être interprété comme des insuffisances ou erreurs dans ce que je dis ci-après

Le domaine d’application et le périmètre, s’ils sont connus de certains des acteurs, ne sont pas ou mal formalisés.

Les exigences fonctionnelles, rarement modélisées par des règles strictes (à défaut d’équations algébriques) , sont souvent non exprimées car considérées comme allant de soi dans la culture ambiante. Mesurer la qualité d’un système dans un tel environnement relève de la gageure. Il est toujours extrêmement difficile de savoir si un dysfonctionnement relève d’un bogue du système ou de l’insuffisance des exigences initiales.

Sauf exception, les process de l’entreprise ne peuvent garantir la cohérence entre le système et la réalité (comme par exemple des écarts entre le stock réel et le stock enregistré dans le S.I.).

Le système interagit avec de nombreux humains dont la formation est souvent inappropriée ou insuffisante. Trop d’acteurs n’ont pas toujours conscience des impacts d’une saisie incomplète ou inexacte.

Les flots de contrôle sont nombreux et complexes. Le système connait ainsi de nombreux états internes dont l’influence sur le résultat des opérations est loin d’être anodin. Il n’est jamais facile de mettre en place des jeux d’essais couvrant correctement l’ensemble car la chance de pouvoir maitriser toute la combinatoire des états possibles est très faible.

Le nombre d’acteurs est tel qu’il est déraisonnable de considérer le système comme déterministe. Par exemple, si deux acheteurs sont en concurrence pour acquérir le même objet unique dans le stock (ou dernière place sur un avion), nul ne peut dire qui sera servi et la même opération avec les mêmes acteurs répétée à deux époques différentes pourra conduire à un résultat différent. Le même problème se pose pour l’allocation d’une ressource unique au sein d’une entreprise.

Le système n’est donc pas invariant dans le temps ce qui rend encore plus difficile l’élaboration de tests ayant une couverture totale. On pourrait ainsi poursuivre la compraison, mais il n’est pas très utile d’enfoncer le clou davantage.

Transposabilité des méthodes d’un univers à l’autre

Une lecture rapide de mes propos pourrait laisser supposer que je suis sévère avec les DSI et MOA d’entreprises et qu’il suffirait d’un peu plus de rigueur de leur part pour améliorer la situation.

Le problème n’est pas du tout là...

Il faudrait , en toute rigueur, distinguer le cas des entreprises pour lesquels le SI est le cœur de leur outil de production, voire leur cœur de métier, et celles chez qui le SI n’est pas ou peu présent dans la production.

Un autre point à prendre en compte est la diversité et le nombre des acteurs interragissant avec le SI. Les systèmes embarqués sont pilotés par une petite élite de gens bien formés à cette tâche. Le SI d’un banque ou d’un grand commerçant est en relation avec un grand nombre d’employés dont la compréhension du S.I. est très inhomogène voire inégale. En outre, un encore plus grand nombre de clients peuvent souvent accéder au S.I. ce qui aggrave encore les difficultés.

Ces considérations ainsi que d’autres montent qu’en entreprise, la rigueur souhaitable des exigences fonctionnelles est souvent en contradiction avec une organisation faite d’êtres humains qui ont chacun leur ego, leurs peurs, leurs certitudes et leur plus ou moins grande lucidité. Sauf à « nazifier » (pardon pour le néologisme) l’organisation d’une entreprise, les espaces de libertés laissés aux collaborateurs (surtout lorsqu’ils ont quelque responsabilité) ne permettent en général pas, d’aboutir à un ensemble d’exigences vraiment cohérentes. Il suffit de permuter deux managers pour faire évoluer les exigences d’un S.I.

Il faut donc vivre avec cette réalité, les exigences totalement formalisées pour un S.I. classique relèvent plutôt du voeu pieu. Il existe même des cas ou fixer une règle fonctionnelle d’arbitrage est impossible ce qui peut conduire à une indétermination de certains résultats (ce sont en fait les règles techniques internes du système qui arbitrent sans aucune cohérence avec la réalité fonctionnelle).

Il faut se dire que l’erreur est indissociable de l’intelligence. On ne peut concevoir comme sans erreur qu’un système dont l’humain serait totalement absent.

Il me parait plus important de pratiquer une culture qui permet de prendre du recul par rapport aux dysfonctionnements du S.I. en ne les diabolisant pas. Si les pannes sont bien anticipées et les procédures de secours connues de tous, elles sont plus facilement acceptées. Jusqu’à un certain taux (quelques heures par an ou par mois selon la criticité) elles font partie de la vie normale du S.I.

Il est bien préférable d’avoir à supporter quelques incidents que de travailler dans un univers proche de celui du meilleur des mondes d’Aldous Huxley.

Réponse de Michel Volle

La conclusion me semble très pertinente. Il faut aussi rappeler que le logiciel le mieux vérifié (par exemple, celui d’une sonde spatiale de la NASA) comporte encore en moyenne un défaut toutes les 10 000 lignes de code source (Jacques Printz, Architecture logicielle, Dunod, 2006, p. 73). Au delà d’une certaine taille, il n’existe pas de logiciel sans défaut.

C’est pourquoi il faut, dans nos systèmes d’information, prévoir une supervision de l’automate, toujours sujet à des pannes aléatoires ; dans les automobiles, avions, sondes spatiales et autres, il faut... croiser les doigts en espérant que les tests ont couvert toutes les situations que la machine pourrait rencontrer, y compris les plus rares, et que les défauts du logiciel (qui inévitablement sont là) resteront en sommeil et sans conséquence.

Addendum de Jean Kott

À propos de l’échec du premier lancement d’Ariane V, je crois me souvenir que c’est parce qu’on avait voulu réutiliser tout ou partie du système de guidage d’Ariane 4 en ayant "oublié" que la présence de booster latéraux changeait complètement l’environnement et les conditions d’équilibre du système. Le monde réel n’est pas Plug and Play.....

Autour de l’accident du vol AF447 (Rio Paris) du 31 mai dernier, une polémique a surgi autour de l’utilisation de sondes Pitot fabriqué par Thalès (sondes mesurant la pression dynamique permettant de calculer la vitesse air de l’avion après correction altimétrique) qui équipaient l’A330 victime du crash . Ces sondes avaient été certifiées sur Boeing 737 et Air France les avait installé sur ses Airbus en appliquant un principe de transitivité du genre "ce qui marche sur Boeing doit marcher sur Airbus". Sans penser aujourd’hui (l’enquête est loin d’être close) que les sondes sont pour partie responsables de ce crash, ce genre de principe repose largement sur la croyance que le monde est plug and play. Ceci dit, Air France fait actuellement machine arrière et ré-équipe ses Airbus avec les sondes Goodyear qui avaient été certifiées par le constructeur sur les prototypes des avions.

Réponse de Laurent Bloch

Le chiffre avancé par Jacques Printz me semble devoir être considéré avec prudence, il concerne plutôt les logiciels de gestion. Il faut d’abord se poser la question : qu’est-ce qu’un défaut dans un logiciel ? L’article de Gérard Le Lann sur l’échec du premier vol d’Ariane 5 me semble une piste de réflexion plus fructueuse pour le monde qui relève des équations de la physique :

https://hal.inria.fr/inria-00073613...

Je pense à un autre exemple dans le domaine de l’embarqué, un accident du métro sans pilote de Lille : les concepteurs du logiciel n’avaient pas su prévoir qu’un camion de 35 tonnes tomberait d’un échangeur sur un pont enjambant la voie et que ce pont ne résisterait pas au choc. On est assez loin de la problématique du nombre d’erreurs par ligne de code. Et la plupart des défauts imputables à l’embarqué sont de cet ordre. Tel logiciel parfaitement sûr pour Ariane 4 ne l’est plus pour Ariane 5 parce que les grandeurs physiques considérées ne sont plus dans les mêmes intervalles. Le système de commande des missiles Patriot (accident de Dahran pendant la guerre du Golfe) n’avait jamais été testé pour 17 jours de fonctionnement ininterrompu, d’où débordement de zone mémoire.

Michel Volle derechef

Je trouve le sujet tellement important que je me fais un devoir de recopier ici ce que Jacques Printz a écrit dans son ouvrage Architecture logicielle, à partir de la p. 71 :

« Depuis les premières statistiques produites par la NASA avec le programme navette spatiale, on a pris l’habitude de mesurer la qualité d’un programme du point de vue des défauts par le taux d’erreur résiduelle ramené au millier d’instructions effectivement livrées, soit :

 Partie embarquée : 700 kLS, 0,1 Err./kLS
 Partie sol : 1 400 kLS, 0,5 Err./kLS

(...)
Il y a consensus parmi les experts sur les chiffres suivants : en fin de programmation, on observe des taux d’erreur de l’ordre d’une erreur toutes les 10-15 lignes de code. Pour installer dans de bonnes conditions, les processus IVVT doivent ramener ce taux aux alentours de 1-2 Err/kLS. »

Laurent Bloch encore

Je précise mon objection à la citation de Printz : il concerne des logiciels écrits « à la main ». Les exemples que je donne concernent plutôt des logiciels engendrés par des systèmes qui produisent leurs propres preuves. Loin de moi l’idée que ce soit une garantie absolue contre les erreurs de programmation, mais dans les exemples que je donne, et l’article de Le Lann explique pourquoi, les défauts ne sont pas des erreurs de programmation, ni des erreurs de spécification du logiciel, mais des erreurs de conception de systèmes, où des éléments de l’environnement n’avaient pas été pris en considération.

Et enfin Michel Volle

Deux remarques :

1) « Des logiciels engendrés par des systèmes qui produisent leurs propres preuves » : en théorie des automates un théorème dit qu’il est impossible de construire le programme qui vérifierait la justesse des programmes, quelle que soit la manière dont ces programmes sont construits. Les preuves que produisent les systèmes ne peuvent donc pas être absolues mais seulement limiter la casse - ce qui est déjà beaucoup. Je suppose que les logiciels embarqués de la NASA sont engendrés par de tels systèmes : alors la statistique que cite Printz aurait une portée plus large que tu ne le crois.

2) Toute programmation part d’un modèle du monde sur lequel le programme devra agir : « l’environnement » est représenté par ce modèle. Mais il ne peut pas exister de modèle qui représente parfaitement et entièrement le monde réel. Il se produit toujours des surprises... C’est pourquoi il convient d’associer à l’automate une supervision par des êtres humains qui seront capables de réagir à une surprise, et aussi des dispositifs comme la « reprise automatique en cas d’erreur » ou le « fonctionnement en régime dégradé » qui permettent à l’automate de continuer à fonctionner dans l’attente de l’intervention du superviseur.

Intervention d’Éric Gressier

(mailto:Eric.Gressier_at_cnam.fr)

Comment placez-vous le téléphone mobile dans le débat ? C’est un système embarqué qui amène le Système d’Information global dans votre univers réel et qui modifie votre comportement de façon difficilement prévisible (exemple du dispositif GPS d’aide a la conduite). Pour élargir le débat, il faut considérer les systèmes embarqués en mobilité.