 |
| A400M, photo AFP |
Une analyse poussée en fonction des données actuelles effectuée par notre rédacteur Richard Rutily.
D’après
Aviation Week il semble que l’avion MSN23,
destiné à la Turquie, était équipé d’un nouveau
logiciel.
Aviation Week il semble que l’avion MSN23,
destiné à la Turquie, était équipé d’un nouveau
logiciel.
Ce
logiciel gérait les réservoirs de carburant de
façon à permettre a l’avion d’effectuer certaines
manœuvres. Ce nouveau
logiciel pourrait ne pas avoir fonctionné
correctement conduisant a l’arrêt des
moteurs par manque de carburant.
logiciel gérait les réservoirs de carburant de
façon à permettre a l’avion d’effectuer certaines
manœuvres. Ce nouveau
logiciel pourrait ne pas avoir fonctionné
correctement conduisant a l’arrêt des
moteurs par manque de carburant.
Il
semble y avoir eu aussi un problème de
déséquilibre
entraînant une inclinaison anormale qui n’a pas pu
être contrée.
L’alimentation
en carburant a
été rétablie, mais pas assez rapidement pour
assurer la sécurité.
semble y avoir eu aussi un problème de
déséquilibre
entraînant une inclinaison anormale qui n’a pas pu
être contrée.
L’alimentation
en carburant a
été rétablie, mais pas assez rapidement pour
assurer la sécurité.
A
partir de cette description de l’accident, et à
condition qu’elle recouvre un peu de réalité, nous
allons tenter de comprendre
ce qui a pu se passer. En fait il faudrait
beaucoup plus d’informations pour
que l’exercice soit sérieux, mais même si
l’analyse que l’on va produire est
fausse, elle permettra à certains lecteurs de
sentir où sont les difficultés,
et comment il est possible qu’un tel accident se
produise.
partir de cette description de l’accident, et à
condition qu’elle recouvre un peu de réalité, nous
allons tenter de comprendre
ce qui a pu se passer. En fait il faudrait
beaucoup plus d’informations pour
que l’exercice soit sérieux, mais même si
l’analyse que l’on va produire est
fausse, elle permettra à certains lecteurs de
sentir où sont les difficultés,
et comment il est possible qu’un tel accident se
produise.
D’après la description précédente
de l’accident, un
logiciel est en cause. Et comme ce logiciel à
entraîné un accident
catastrophique, on sait maintenant qu’il est
critique. Le classement des
logiciels suivant leur niveau de criticité obéit à
la norme DO-178 qui a
plusieurs indices dont le plus récent est l’indice
C.
de l’accident, un
logiciel est en cause. Et comme ce logiciel à
entraîné un accident
catastrophique, on sait maintenant qu’il est
critique. Le classement des
logiciels suivant leur niveau de criticité obéit à
la norme DO-178 qui a
plusieurs indices dont le plus récent est l’indice
C.
Le niveau le plus critique pour un
logiciel est le niveau
DAL A dont la définition est la suivante:
logiciel est le niveau
DAL A dont la définition est la suivante:
Un défaut du
système ou sous-système étudié peut
provoquer un problème
catastrophique (Sécurité du vol ou
atterrissage compromis) Crash de l’avion.
système ou sous-système étudié peut
provoquer un problème
catastrophique (Sécurité du vol ou
atterrissage compromis) Crash de l’avion.
C’est bien ce que l’on déplore, et
donc le classement de
la criticité du logiciel est maintenant évidente,
mais il n’en était pas de
même avant l’accident.
donc le classement de
la criticité du logiciel est maintenant évidente,
mais il n’en était pas de
même avant l’accident.
Un logiciel qui gère des
transferts de carburant, cela ne
paraît pas critique a priori. Il faut une analyse
sérieuse pour obtenir un
classement DAL A, surtout que ce classement
entraîne des surcoûts de test
importants et qu’il faut en général batailler pour
faire accepter à la
hiérarchie ce type de classement.
transferts de carburant, cela ne
paraît pas critique a priori. Il faut une analyse
sérieuse pour obtenir un
classement DAL A, surtout que ce classement
entraîne des surcoûts de test
importants et qu’il faut en général batailler pour
faire accepter à la
hiérarchie ce type de classement.
Et il faut se rendre compte que la
taille des logiciels
augmente sans cesse, parce qu’ils exécutent de
plus en plus de fonctions, et
qu’il n’est pas évident d’imaginer tous les cas de
figures pour tous ces
logiciels afin de déterminer lesquels sont
critiques et à quel niveau.
Finalement lorsqu’il y avait peu de logiciels, on
était plus méfiant, aussi,
parce qu’on pouvait se le permettre au niveau des
analyses nécessaires.
taille des logiciels
augmente sans cesse, parce qu’ils exécutent de
plus en plus de fonctions, et
qu’il n’est pas évident d’imaginer tous les cas de
figures pour tous ces
logiciels afin de déterminer lesquels sont
critiques et à quel niveau.
Finalement lorsqu’il y avait peu de logiciels, on
était plus méfiant, aussi,
parce qu’on pouvait se le permettre au niveau des
analyses nécessaires.
Un
logiciel DAL A doit être développé en suivant
toutes
les bonnes pratiques que vous pouvez imaginer,
doit être bien documenté, bien
testé surtout. A ce niveau la spécificité qui est
introduite est appelé « decision
coverage », pendant
le test, tous les points ci-dessous doivent être
vrais au moins une fois
logiciel DAL A doit être développé en suivant
toutes
les bonnes pratiques que vous pouvez imaginer,
doit être bien documenté, bien
testé surtout. A ce niveau la spécificité qui est
introduite est appelé « decision
coverage », pendant
le test, tous les points ci-dessous doivent être
vrais au moins une fois
·
Chaque
décision essaie toutes les issues possibles ;
Chaque
décision essaie toutes les issues possibles ;
·
Chaque
condition, dans une décision, prend toutes les
issues possibles ;
Chaque
condition, dans une décision, prend toutes les
issues possibles ;
·
Chaque point
d’entrée et de sortie est passé ;
Chaque point
d’entrée et de sortie est passé ;
·
Chaque condition
dans une décision affecte indépendamment l’issue
de la décision.
Chaque condition
dans une décision affecte indépendamment l’issue
de la décision.
Avoir
100% de « decision coverage » est
toujours
difficile et parfois impossible. C’est en
particulier impossible lorsque la
fonction est complexe. Or la fonction qui est en
cause dans cet accident est
complexe.
100% de « decision coverage » est
toujours
difficile et parfois impossible. C’est en
particulier impossible lorsque la
fonction est complexe. Or la fonction qui est en
cause dans cet accident est
complexe.
 |
| Restes de l’A400 après son crash… |
Il est difficile de
définir ce qu’est une fonction complexe, on va
dire que
c’est une fonction qui n’est pas simple, et on
dira qu’une fonction est simple
si on peut la réaliser avec de la logique
câblée. Pour clarifier un peu, si on
appelle ça, ceci, cela les
valeurs
prises par certains paramètres mesurables du
vol, la fonction est simple si on
peut la décrire par des phrases du genre: “si
tel paramètre est inférieur
à ça mais pas plus grand que ceci alors qu’on a
aussi cela, la situation est
anormale et il faut arrêter les transferts.”
C’est-à-dire en employant uniquement
des fonctions “et”, “ou” et “non”.
définir ce qu’est une fonction complexe, on va
dire que
c’est une fonction qui n’est pas simple, et on
dira qu’une fonction est simple
si on peut la réaliser avec de la logique
câblée. Pour clarifier un peu, si on
appelle ça, ceci, cela les
valeurs
prises par certains paramètres mesurables du
vol, la fonction est simple si on
peut la décrire par des phrases du genre: “si
tel paramètre est inférieur
à ça mais pas plus grand que ceci alors qu’on a
aussi cela, la situation est
anormale et il faut arrêter les transferts.”
C’est-à-dire en employant uniquement
des fonctions “et”, “ou” et “non”.
La fonction qui gère les
transferts de carburant est complexe parce qu’il
est vraisemblable qu’elle calcule des quantités
à transférer en fonctions de
règles élaborées à partir des spécifications.
transferts de carburant est complexe parce qu’il
est vraisemblable qu’elle calcule des quantités
à transférer en fonctions de
règles élaborées à partir des spécifications.
Si maintenant on la
classe Dal A, il va falloir abaisser son niveau
de
criticité, en séparant ce qui est critique de ce
qui ne l’est pas.
classe Dal A, il va falloir abaisser son niveau
de
criticité, en séparant ce qui est critique de ce
qui ne l’est pas.
On peut par exemple
imaginer une fonction supplémentaire, critique
DAL A,
chargée de veiller à la sécurité du vol. Cette
fonction travaille à partir de
paramètres bien choisis pour vérifier que
l’avion reste dans son domaine de vol
et ne risque pas d’en sortir à brève échéance et
pour cela elle a juste besoin
de tester des valeurs par rapport à des seuils.
Si la situation est normale du
point de vue “sécurité du vol” la fonction ne
fait aucun traitement,
sinon elle bloque les transferts de carburant
jusqu’à ce que la situation
redevienne normale et qu’un pilote ait autorisé
la reprise.
imaginer une fonction supplémentaire, critique
DAL A,
chargée de veiller à la sécurité du vol. Cette
fonction travaille à partir de
paramètres bien choisis pour vérifier que
l’avion reste dans son domaine de vol
et ne risque pas d’en sortir à brève échéance et
pour cela elle a juste besoin
de tester des valeurs par rapport à des seuils.
Si la situation est normale du
point de vue “sécurité du vol” la fonction ne
fait aucun traitement,
sinon elle bloque les transferts de carburant
jusqu’à ce que la situation
redevienne normale et qu’un pilote ait autorisé
la reprise.
La fonction “sécurité du
vol” est simple et critique et va
pouvoir être développée en suivant la norme
DO-178, et elle abaisse la
criticité de la fonction qui gère les transferts
de carburant qui, de ce fait,
va pouvoir aussi être développée en suivant la
norme.
vol” est simple et critique et va
pouvoir être développée en suivant la norme
DO-178, et elle abaisse la
criticité de la fonction qui gère les transferts
de carburant qui, de ce fait,
va pouvoir aussi être développée en suivant la
norme.
One Comment
Anonyme
Dans le domaine logiciel, dés que la fonction est critique (met en jeu la vie humaine) on a pas le choix. Il faut décomposer en fonction simple totalement testable et avoir un repli dans un mode dégradé mais fiable par principe.
Et le coût du test dépasse de plusieurs ordre de grandeur celui du logiciel proprement dit. En info de gestion, dix fois plus de lignes de tests que de logiciel testé n'est pas anormal. En aéronautique, ferroviaire… le rapport doit exploser.