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 14 décembre 2014

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

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 coeur de
leur outil de production, voire leur coeur 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é.

Forum
Répondre à cet article


pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.86.44