Note: Descriptions are shown in the official language in which they were submitted.
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
1
Procédé de traitement du volume d'informations manipulé durant une phase
de débogage d'un logiciel de fonctionnement d'un système embarqué à bord
d'un aéronef, et dispositif de mise en oeuvre
La présente invention a pour objet un procédé de traitement
d'informations manipulées durant une phase de débogage d'un logiciel de
fonctionnement d'un système destiné à être embarqué à bord d'un aéronef.
Ce procédé permet à un développeur de réduire de manière significative le
volume d'informations, et donc les ressources mémoires, nécessaires à la
recherche et à la correction d'erreurs dans des logiciels de fonctionnement
de systèmes destinés à être embarqués.
La présente invention trouve des applications particulièrement
avantageuses, mais non exclusives, dans le domaine de l'aéronautique et,
plus particulièrement, dans le domaine des tests de logiciels de
fonctionnement des systèmes embarqués.
Pour des raisons de sécurité, les systèmes destinés à être embarqués
à bord d'un aéronef sont soumis à des vérifications de bon fonctionnement
au cours desquels il doit être démontré que lesdits systèmes répondent à
des exigences de certification, avant qu'un aéronef équipé de tels systèmes
soit autorisé à voler et, plus encore, à entrer en service commercial.
Avant leur implantation, ces systèmes subissent de nombreux tests
pour vérifier qu'ils répondent aux exigences d'intégrité et de sécurité, entre
autre, émises par les autorités de certification. Ces systèmes embarqués
peuvent être, notamment, des calculateurs spécialisés destinés à réaliser
des fonctions pouvant être importantes pour l'aéronef, par exemples des
fonctions de pilotage. Ces systèmes seront appelés par la suite calculateurs.
Le plus souvent, dans les architectures des systèmes actuels, chaque
calculateur est dédié à une application ou à plusieurs applications de même
nature, par exemple des applications de commande de vol. Chaque
calculateur comprend une partie matérielle et une partie logicielle. La partie
matérielle comporte au moins une unité de traitement central (CPU: Central
Processing Unit en anglais) et au moins une unité d'entrées/sorties par
laquelle le calculateur est connecté à un réseau de calculateurs, à des
périphériques externes, etc...
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
2
Une caractéristique essentielle des systèmes embarqués souvent mis
en oeuvre dans le domaine aéronautique est liée à une architecture, tant
matérielle que logicielle, qui évite l'introduction, autant que possible, de
tout
moyen non nécessaire pour exécuter les fonctions dédiées audits systèmes.
Ainsi, contrairement aux systèmes généralement rencontrés dans des
applications répandues, en aéronautique, le calculateur n'est pas pourvu
d'un système d'exploitation complexe. De plus, le logiciel est réalisé dans un
langage aussi proche que possible du langage compris par l'unité de
traitement central et les seules entrées/sorties disponibles sont celles
nécessaires au fonctionnement du système, par exemple des informations
provenant de capteurs ou d'autres éléments de l'aéronef ou des informations
à destination d'actionneurs ou d'autres éléments.
L'avantage de ce type d'architecture tient au fait que le
fonctionnement d'un tel système est beaucoup mieux maitrisé. Il n'est pas
dépendant d'un système d'exploitation complexe dont certains aspects du
fonctionnement sont fonction de paramètres non maitrisés et qui devrait,
sinon, faire l'objet des mêmes démonstrations de sécurité que les logiciels
d'application. Le système est plus simple et moins vulnérable car il ne
comporte que les moyens strictement nécessaires à l'exécution des fonctions
confiées audit système.
En contrepartie, le fonctionnement d'un tel système est beaucoup plus
difficile à observer. Par exemple, le système ne dispose pas des interfaces
homme/machine conventionnelles, comme les claviers et écrans, permettant
de vérifier le déroulement correct des suites d'instructions et d'interagir
sur
ce déroulement, ce qui rend difficile les vérifications indispensables pendant
le développement, la vérification et la qualification des logiciels.
La partie logicielle du calculateur comprend un logiciel spécifique à
l'application considérée et qui assure le fonctionnement du calculateur, dont
les instructions logiques correspondent aux algorithmes qui déterminent le
fonctionnement du système.
Pour obtenir la certification du système, préalable à sa mise en service
et à celle de l'aéronef, une phase de validation du calculateur est effectuée.
De façon connue, la phase de validation consiste, en général, à
vérifier à chaque étape du processus de réalisation du calculateur, que celui-
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
3
ci est conforme aux spécifications qui ont été établies pour que ledit
calculateur réponde au fonctionnement attendu du système.
Cette conformité aux spécifications est réalisée, en particulier pour les
logiciels, par étapes successives depuis la vérification des composants les
plus simples du logiciel jusqu'au logiciel complet intégrant tous les
composants devant être intégrés dans le calculateur cible.
Dans une première étape, les éléments de logiciel les plus simples
pouvant être testés sont soumis à des tests, dits tests unitaires. Au cours de
ces tests, il est vérifié que les instructions logiques, c'est-à-dire le code,
desdits éléments de logiciel ont été, pris individuellement, réalisés
conformément aux exigences de conception.
Dans une deuxième étape, dite étape d'intégration, différents
composants logiciels, ayant été soumis individuellement à une vérification
isolée, sont intégrés, pour constituer un ensemble dans lequel les
composants logiciels interagissent. Ces différents composants logiciels sont
soumis à des tests d'intégration destinés à vérifier que les composants
logiciels sont compatibles, en particulier au niveau des interfaces
fonctionnelles entre lesdits composants.
Dans une troisième étape, l'ensemble des composants logiciels est
intégré dans le calculateur auquel ils sont destinés. Des essais de validation
sont alors réalisés pour démontrer que le logiciel, formé par l'ensemble des
composants intégrés dans le calculateur, est conforme à la spécification,
c'est-à-dire qu'il réalise les fonctions attendues, et que son fonctionnement
est fiable et sûr.
Pour garantir qu'un logiciel est sûr, et pour satisfaire aux exigences de
certification, il est également nécessaire, au cours de cette phase de
validation, de démontrer que l'ensemble des tests auxquels le logiciel a été
soumis permet de conclure, avec un niveau de probabilité adéquat, que le
logiciel est conforme aux exigences de sûreté requises du système où il est
incorporé.
Les différents tests effectués, pendant la phase de validation, sur le
logiciel, permettent de s'assurer qu'aucun dysfonctionnement dudit logiciel
(qui pourrait avoir un impact sur le bon fonctionnement des calculateurs, et
par suite sur l'aéronef et sa sécurité) ne peut se produire ou que, si un
dysfonctionnement se produit, le logiciel est apte à le maitriser.
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
4
Toutefois, pendant la phase de validation, et surtout pour les
opérations d'investigation lorsque des anomalies sont constatées, il est
souvent nécessaire de s'assurer que, non seulement, les paramètres
d'entrée et de sortie du calculateur sur lequel est implanté le logiciel sont
conformes aux attentes mais, également, que certains comportements
internes du logiciel sont corrects.
Dans ce cas, en raison de l'architecture spécifique des calculateurs
spécialisés pour les applications embarquées, il est généralement très
difficile d'observer le fonctionnement du logiciel sans mettre en oeuvre des
dispositifs et des méthodes particulières.
Une première méthode connue consiste à mettre en place un
système de distribution de fichiers entre le calculateur en test avec le
logiciel
implanté et une plate-forme associée, en utilisant des émulateurs. On
entend, par émulateur, un dispositif permettant de simuler, sur la plate-forme
associée, le fonctionnement logique d'une unité de calcul, d'un processeur
du calculateur.
Dans un tel mode de fonctionnement avec un émulateur, le
processeur du calculateur est remplacé par une sonde qui assure l'interface
avec la plate-forme associée portant l'émulation du processeur.
Ainsi, il est possible de faire exécuter le logiciel à tester sur le
calculateur, sauf pour la partie processeur et, par des fonctions propres de
la
plate-forme associée, d'observer le fonctionnement ou certains
dysfonctionnements internes du logiciel, par exemple, en réponse à des
stimulations des entrées des unités d'entrée/sortie, en plus de l'observation
des sorties desdites unités d'entrée/sortie.
Cette première méthode présente de nombreux inconvénients. En
effet, chaque type de calculateur à tester nécessite un banc de tests
spécifique ou pour le moins une configuration très spécialisée d'un banc de
test. Un banc de tests est un ensemble comportant, en particulier, des
moyens d'interconnexion avec le calculateur à tester, des moyens pour
émuler le ou les processeurs du calculateur ainsi que pour exécuter des
programmes de tests.
Comme chaque processeur nécessite un émulateur spécifique, tant
pour le logiciel d'émulation que pour la sonde se raccordant à la place du
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
processeur, il est nécessaire de multiplier les émulateurs conformément aux
définitions des calculateurs.
Par ailleurs, les possibilités d'investigation au moyen des émulateurs
sont en général limitées. De plus, la nécessité de travailler avec un langage
machine spécifique du processeur considéré implique que le développeur
soit un spécialiste de la programmation en langage machine.
En outre, un émulateur est un produit coûteux qui n'est généralement produit
qu'en faible quantité. Le cycle de vie de ce type de produit est très court (6
mois à 2 ans) alors que le maintien en condition opérationnelle des moyens
de développement et de vérification est exigible (réglementations, réactivité
industrielle) pour la durée du programme avion (20 ans, voire plus). Cela se
traduit par des problèmes de traitement d'obsolescence de plus en plus
difficiles à résoudre.
Cette solution de l'émulateur s'avère donc mal adaptée car, outre ses
performances limitées en termes d'investigation, elle est coûteuse à mettre
en place et coûteuse à entretenir.
Le coût se trouve également pénalisé par le fait que différents
modèles de processeurs sont en général utilisés pour assurer des
redondances fonctionnelles par sécurité de conception, multipliant d'autant
les besoins en émulateurs.
Une deuxième méthode, qui vise à s'affranchir des problèmes des
émulateurs, consiste à simuler, sur une plate-forme hôte, le fonctionnement
du calculateur devant exécuter le programme à tester. Dans ce cas, les
logiciels sous test doivent accéder à des fichiers de la plate-forme hôte,
soit
pour lire les vecteurs de tests, soit pour enregistrer des résultats de tests.
Comme le logiciel à tester ne comporte pas naturellement les
fonctions pour de tels accès au système de fichiers de la plate-forme hôte, il
est nécessaire de modifier le logiciel à tester pour intégrer ces fonctions
d'accès.
Pour transférer les informations, on utilise généralement des
instructions d'appels système qui sont émises par l'environnement de test
simulé. Les instructions d'appels système peuvent être, par exemple,
l'ouverture d'un fichier, l'écriture d'un fichier ou encore la lecture d'un
fichier.
Les instructions d'appels système sont interceptées par le système
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
6
d'exploitation de la plate-forme hôte qui les convertit en appels système de
la
plate-forme hôte.
Cette deuxième méthode présente également des inconvénients. En
effet, la variété des fichiers est telle que le développement des
fonctionnalités d'accès est très dépendant de la plate-forme hôte et de son
système d'exploitation. Or, la variabilité des plates-formes hôtes est
importante tant dans l'espace (cas des équipes de développement
dispersées dans le monde) que dans le temps (remplacement des plates-
formes hôtes), ce qui pose des difficultés pratiques de mise en oeuvre de la
méthode.
Ces difficultés sont accentuées par le fait que des compétences
d'experts capables de modifier des fonctions du système d'exploitation sont
requises pour le développement de telles fonctionnalités d'accès aux
systèmes de fichiers et ne peuvent donc pas être confiées à des spécialistes
des essais.
En conséquence, cette méthode s'avère coûteuse et difficile à mettre
en oeuvre.
En outre cette méthode est très intrusive vis-à-vis du logiciel à tester
et la modification d'un logiciel, pour en réaliser des tests, est une source
de
risque de perturbation du fonctionnement du logiciel lui-même.
Pendant la phase de validation du calculateur, c'est-à-dire pendant les
tests, il peut y avoir une interruption de l'exécution du logiciel de
fonctionnement. Cette interruption se manifeste par un arrêt du déroulement
du logiciel de fonctionnement ou par le fait que le logiciel reste bloqué dans
une boucle d'instructions infinie. Le développeur doit alors rechercher des
anomalies ou des erreurs dans les lignes de codes instructions, afin de
pouvoir les corriger. Cette recherche est effectuée par une exécution dans
laquelle la succession des points du chemin d'exécution apparaît dans l'ordre
inverse de celle d'une exécution normale. Autrement dit, on remonte une
séquence de lignes de codes dans laquelle on recherche l'erreur (c'est-à-dire
qu'on retourne dans une séquence de lignes de codes déjà exécutée mais
contenant une ou plusieurs erreurs) et on ré-exécute la séquence remontée.
Cette recherche est appelée exécution reverse.
Cette exécution reverse exige, qu'en tout point d'un chemin
d'exécution du logiciel de fonctionnement formé d'une succession de lignes
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
7
de codes instructions, le développeur comprenne le déroulement des lignes
de codes instructions. Or, le développeur ne sait pas à quel niveau du
chemin d'exécution se situe l'erreur. Il ne sait donc pas sur combien de
lignes de codes l'exécution reverse doit s'effectuer. De plus, pour les
logiciels
embarqués, l'exécution reverse doit se faire dans le même langage que
l'exécution normale, c'est-à-dire en langage machine. Il est donc difficile,
pour le développeur, de comprendre suffisamment le déroulement du
programme du logiciel de fonctionnement pour remonter la séquence de
lignes et retrouver l'erreur. En outre, il n'y a aucun moyen de contrôle ou de
suivi de l'exécution reverse pour permettre au développeur de savoir
jusqu'où il doit remonter la chaîne défaillante afin de trouver l'erreur ou
l'anomalie.
Compte tenu de sa complexité, cette recherche d'erreur nécessite un
temps considérable pouvant aller de quelques heures à plusieurs jours, ce
qui entraîne un coût relativement élevé de la phase de débogage, en terme
de productivité et de main d'oeuvre.
De plus, pour pouvoir effectuer l'exécution reverse du programme, il
faut avoir, au préalable, capturé puis restitué des informations sur l'état
d'exécution du programme. L'ensemble de ces informations capturées est
mémorisé dans une mémoire de données pour être régénéré ultérieurement.
Cependant, le chemin d'exécution d'un programme peut être long ; le volume
des données manipulées et mémorisées est alors considérable, ce qui peut
poser un problème de capacité de la ressource mémoire.
Pour résoudre les différents problèmes exposés précédemment,
plusieurs solutions ont été élaborées. Une première solution consiste à
compresser l'ensemble des données manipulées. Cette solution est peu
efficace car le coefficient de compression est aléatoire (il varie en fonction
des différentes données manipulées). De plus, il s'avère qu'à la fin de
l'opération de compression, le gain de place mémoire obtenu est
relativement faible pour un coût de compression de données élevé.
Une deuxième solution consiste à réduire les données en ne capturant
que les données strictement nécessaires. La méthode utilisée dans cette
deuxième solution est celle de la copie sur écriture (en anglais : copy-on-
write). Cette solution se base sur une vérification régulière du pointage des
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
8
informations pour capturer uniquement les pages de données modifiées, ce
qui permet d'avoir un minimum d'informations pour la régénération ultérieure.
A la différence de la première solution, le coût de cette capture est
minimal ; par contre, la régénération qui est faite nécessite un temps
relativement long, surtout durant une activité de débogage interactive car
chaque reconstitution d'un état d'exécution initial est établie à partir de la
totalité des points de contrôle capturés, depuis le début du programme.
La présente invention a pour but de remédier aux inconvénients
exposés précédemment. Pour cela, l'invention propose un procédé de
traitement du volume d'informations manipulées durant une phase de
débogage d'un logiciel de fonctionnement d'un système embarqué.
Le procédé de l'invention permet de réduire et optimiser les demandes
en ressource mémoire attribuées à un système embarqué. Pour cela, le
procédé de l'invention propose de découper le chemin d'exécution du logiciel
de fonctionnement en intervalles fonctionnels, de capturer des informations
relatives à l'état d'exécution du logiciel sous test, à un emplacement donné,
et de restituer ces informations ultérieurement.
Plus précisément, l'invention concerne un procédé de traitement du
volume d'informations manipulé durant une phase de débogage d'un
programme du logiciel de fonctionnement d'un système embarqué,
caractérisé en ce qu'il comporte les étapes suivantes :
a) découpage du chemin d'exécution dudit programme de
fonctionnement en intervalles fonctionnels en positionnant des points de
cheminement à chaque fonction du programme,
b) mise en place de points de contrôle associés à chaque point de
cheminement,
c) exécution normale du programme, dans laquelle est effectuée :
- une mémorisation d'un état d'exécution du programme à
l'emplacement de chaque point de cheminement,
- la mémorisation d'un état d'exécution entraîne une suppression de
l'état d'exécution précédemment mémorisé pour ledit point de
cheminement,
- lors d'une détection d'erreur :
- recherche du point de cheminement correspondant à une
fonction défaillante,
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
9
- recherche d'un état d'exécution de départ du programme,
- régénération de cet état d'exécution de départ,
- correction de l'erreur dans la fonction défaillante, et
- ré-exécution du programme.
L'invention peut comporter aussi une ou plusieurs des caractéristiques
suivantes :
- un seul état d'exécution est mémorisé simultanément dans une
mémoire de donnée ;
- après l'exécution normale d'une fonction, le point de cheminement
correspondant à cette fonction passe d'un état désactivé à un état activé ;
- la recherche de la fonction défaillante consiste à rechercher le
dernier point de cheminement activé ;
- une liste des points de cheminement avec leur état est mémorisée ;
L'invention concerne également un dispositif simulant le
fonctionnement d'un calculateur embarqué à bord d'un aéronef, caractérisé
en ce qu'il met en oeuvre le procédé tel que défini précédemment.
Ce dispositif peut comporter une mémoire de données apte à
mémoriser un état d'exécution du programme.
L'invention à également pour objet un programme du logiciel de
fonctionnement pour système embarqué à bord d'un aéronef, chargeable sur
une unité de commande comprenant des séquences d'instructions pour
mettre en oeuvre le procédé tel que décrit précédemment, lorsque le
programme est chargé sur l'unité et y est exécuté.
L'invention sera mieux comprise à la lecture de la description qui suit
et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à
titre indicatif et nullement limitatif de l'invention.
La figure 1 illustre un diagramme fonctionnel du procédé de l'invention
Les figures 2a et 2b représentent schématiquement un dispositif dans
lequel le procédé de l'invention est mis en oeuvre.
Un logiciel de fonctionnement est constitué d'un ensemble de
programmes. Un programme étant constitué d'un ensemble de suites
d'instructions écrites appelé par la suite chaînes d'instructions. Ces chaînes
d'instructions sont exécutées, normalement, dans leur ordre d'occurrence,
c'est-à-dire de la première instruction à la dernière instruction. Ces chaînes
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
d'instructions exécutées dans leur ordre d'occurrence constituent le chemin
d'exécution normal du programme.
Pour déboguer un programme de manière efficace, c'est-à-dire pour
rechercher et corriger les erreurs, les défauts de conception et les anomalies
de fonctionnement d'un programme, le procédé de l'invention propose de
positionner des balises dans le chemin d'exécution du programme afin de
pouvoir déterminer, par rapport à ces balises, où se situe l'erreur ou
l'anomalie. Les balises sont des repères virtuels positionnés à des
emplacements spécifiques du programme. Ces emplacements
correspondent, par exemple, au début ou à la fin des différentes fonctions du
programme. Une fonction est une séquence d'instructions permettant,
ensemble, de réaliser une opération spécifique. Les fonctions du programme
s'exécutent les unes à la suite des autres. Les balises sont placées, par
exemple, à chaque point d'entrée ou à chaque point de sortie d'une fonction
du programme. Lorsque les balises sont placées à l'entrée ou à la sortie de
chaque fonction du programme, on dit que les balises réalisent un
jalonnement fonctionnel du programme.
Chaque balise comporte un point de cheminement et un point de
contrôle.
Le point de cheminement est un repère virtuel qui peut être positionné
à des emplacements spécifiques du programme. Les emplacements des
points de cheminement dans le programme sont ceux décrits précédemment
pour les balises. Les points de cheminement constituent des points de repère
lors de l'exécution du programme. On comprendra, par la suite, que les
points de cheminement constituent des points de reprise du déroulement du
chemin d'exécution du programme, en cas d'exécution reverse suite à une
interruption du déroulement du programme (lorsqu'une ou plusieurs
anomalies ou erreurs ont été rencontrées). En effet, une répartition régulière
de ces points de cheminement tout au long du chemin d'exécution du
programme permet de rechercher facilement et rapidement les erreurs ou
anomalies rencontrées. Cette répartition peut être de type fonctionnel, c'est-
à-dire que les points de cheminement découpent le chemin d'exécution du
programme en intervalles fonctionnels adjacents.
Le point de contrôle de chaque balise est un vecteur d'état qui
correspond à une image de la mémoire dans laquelle sont enregistrées les
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
11
différentes données utilisées lors de l'exécution du programme. Un point de
contrôle indique l'état d'exécution du programme à un emplacement donné,
c'est-à-dire à l'emplacement du programme où se situe la balise, ce qui
permet, ultérieurement, de réinitialiser la mémoire avec les informations du
point de contrôle. Un point de contrôle est associé à chaque point de
cheminement. Un point de contrôle est constitué de l'ensemble des
informations référencées par l'exécution du programme entre deux balises
temporellement consécutives. Cet ensemble est donc l'ensemble le plus
petit, nécessaire et suffisant, pour ré-exécuter le programme entre ces deux
balises.
Chaque point de cheminement peut prendre deux états : un état activé
et un état désactivé. Un point de cheminement contient, outre son état
(activé/désactivé), l'adresse programme associé ainsi que les informations
qui définissent les traitements à faire quand l'exécution du programme atteint
l'adresse du point de cheminement. Au début du déroulement du
programme, tous les points de cheminement sont désactivés. Tous les points
de contrôle correspondant aux points de cheminement sont neutres, c'est-à-
dire qu'ils ne contiennent aucune information.
Chaque fois qu'une fonction a été exécutée normalement, le point de
cheminement situé à la fin de la fonction, ou à l'entrée de la fonction
suivante, change d'état en s'activant. Le point de contrôle associé à ce point
de cheminement capture ou mémorise alors l'état d'exécution dans lequel se
trouve le programme à l'emplacement du point de cheminement.
Lors de l'exécution normale du programme, le point de cheminement
situé après une fonction exécutée normalement (à la fin de la fonction ou à
l'entrée de la fonction suivante) passe d'un état désactivé à un état activé.
Lorsqu'un point de cheminement passe à un état activé, l'état d'exécution du
programme est capturé par le point de contrôle correspondant à ce point de
cheminement. Autrement dit, l'état d'exécution du programme à un endroit
donné du programme est enregistré dans une mémoire de données.
Selon l'invention, les différents états d'exécution du programme sont
enregistrés successivement, les uns à la suite des autres dans une même
mémoire de données de sorte que un seul état d'exécution est mémorisé
simultanément dans la mémoire de données. Cet état d'exécution mémorisé
est le dernier état d'exécution capturé, c'est-à-dire l'état d'exécution du
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
12
programme à l'emplacement du dernier point de cheminement activé. En
effet, on considère, dans l'invention, que seule la mémorisation de ce dernier
état d'exécution est nécessaire pour régénérer, ultérieurement, l'état
d'exécution du programme, lors d'une exécution reverse. Dans un mode de
réalisation, la capture d'un état d'exécution écrase l'enregistrement de
l'état
d'exécution précédent. Dans un autre mode de réalisation, après chaque
enregistrement d'un état d'exécution, on supprime l'état d'exécution
précédemment enregistré, de sorte que la mémoire de données ne contient
qu'un seul état d'exécution, à savoir l'état d'exécution utile pour la reprise
du
programme lors de l'exécution reverse.
Lorsqu'une erreur survient, le développeur effectue une exécution
reverse du programme pour retrouver ladite erreur au sein du programme.
Cette exécution reverse permet de remonter le programme en sens inverse
du déroulement normal du programme, pour reprendre son exécution à la
première ligne d'instruction de la fonction correspondant au dernier point de
cheminement activé, c'est-à-dire la dernière fonction dont le point de
contrôle
a capturé les informations d'état du programme.
Une liste des points de cheminement est mémorisée avec l'état de
chacun de ces points. Ainsi, lorsqu'une interruption de l'exécution du
programme se produit, on recherche quel était le dernier point de
cheminement activé et on se replace à l'endroit du programme
correspondant à ce point de cheminement. On recherche ensuite, dans la
mémoire de données, l'état d'exécution enregistré et on ré-exécute le
programme à partir de cet endroit, en utilisant les données relatives à l'état
d'exécution enregistré.
Ainsi, selon l'invention, l'exécution reverse est menée en suivant les
points de cheminement pour remonter la chaîne d'instructions du programme
et déterminer l'emplacement de la chaîne d'instructions défaillante.
L'exécution reverse peut ainsi être effectuée à l'intérieur d'un seul
intervalle
fonctionnel. Lorsqu'une chaîne défaillante, ou erreur, a été détectée dans cet
intervalle fonctionnel, le développeur recherche l'erreur ou l'anomalie dans
cette chaîne, puis la corrige.
Grâce aux points de contrôle, le programme peut être ré-exécuté à
partir de l'emplacement du dernier point de cheminement activé. Cette
reprise du programme nécessite de récupérer l'état d'exécution de départ.
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
13
Selon l'invention, cette récupération de l'état d'exécution nécessite
uniquement, comme place mémoire, la place correspondant à un état
d'exécution. En outre, le lien entre le point de cheminement et le point de
contrôle permet de récupérer l'état d'exécution de départ rapidement.
La figure 1 est un exemple de diagramme fonctionnel du procédé de
l'invention. Ce procédé comporte une étape préliminaire 31 d'initialisation
d'une phase de débogage. Cette étape réinitialise les différents paramètres
utiles au bon déroulement de la phase de débogage.
A l'étape 32, une découpe régulière et appropriée du chemin
d'exécution du programme du logiciel de fonctionnement est effectuée. Cette
découpe permet d'identifier le contexte de fonctionnement associé à tout
intervalle du chemin d'exécution du programme.
A l'étape 33, on répartit des points de cheminement le long du chemin
d'exécution du programme de façon à découper ledit chemin d'exécution en
intervalles fonctionnels. En regard de chaque point de cheminement est
associé un point de contrôle. L'ensemble des points de contrôle et des points
de cheminement forment un balisage. Chaque point de cheminement a un
rôle passif ; il constitue uniquement un indicateur indiquant le point de
reprise
de l'exécution du programme. Le point de contrôle a un rôle actif, c'est-à-
dire
qu'il peut prendre deux états différents (activé ou désactivé). Le point de
contrôle a pour rôle de capturer les informations d'état d'exécution à un
endroit précis du programme et à un moment déterminé.
A l'étape 34, une exécution normale du programme est effectuée. Une
boucle de test est appliquée au programme à l'étape 35. A cette étape 35, on
détecte les passages sur un point de cheminement. Si un passage sur un
point de cheminement a été détecté durant l'exécution du programme, c'est-
à-dire si un point de cheminement a été franchi, on applique l'étape 36. Dans
le cas contraire, on réitère l'étape 34.
A l'étape 36, on capture l'état d'exécution du programme à un
emplacement donné. Cet état d'exécution du programme capturé est
mémorisé à l'étape 37.
L'étape 38 est une étape de détection d'erreur dans le programme. Si
une erreur a été détectée dans le programme, alors on applique l'étape 39,
sinon on applique l'étape 40.
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
14
A l'étape 39, l'exécution du programme est arrêtée. On détermine
alors, à l'étape 41, l'état de départ d'exécution du programme. Cet état de
départ de l'exécution est le dernier état d'exécution enregistré dans la
mémoire de données lors de l'étape 37.
A l'étape 42, on régénère l'état de départ de l'exécution, c'est-à-dire
l'état d'exécution dans lequel était le programme à la fin de la dernière
fonction exécutée sans erreur. Cette régénération de l'état de départ
d'exécution permet de restituer le contexte de l'intervalle fonctionnel du
chemin d'exécution.
A l'étape 43, une exécution reverse est effectuée dans laquelle le
programme est ré-exécuté à partir du dernier point de cheminement activé et
en considérant, comme état d'exécution, celui capturé par le point de
contrôle associé au point de cheminement activé.
A l'étape 44, on recherche la cause racine de l'erreur, dans la fonction
défaillante, afin de remonter la chaîne défaillante, puis corriger l'erreur
dans
le programme.
A l'étape 45, on vérifie que la phase de débogage est terminée. Si la
phase de débogage est terminée alors le programme peut être exécuté dans
sa totalité (étape 46). Dans le cas contraire, on retourne à l'étape 34 et on
ré-
exécute les étapes 34 à 45.
Lorsqu'il n'y a pas d'erreurs dans le programme (étape 38), on
applique l'étape 40. A l'étape 40, on détermine si un saut d'intervalle
fonctionnel a été requis de manière interactive par le développeur. Si un saut
d'intervalle fonctionnel a été requis, alors on applique l'étape 41 et les
étapes
suivantes. Dans le cas contraire, on applique à nouveau l'étape 34
permettant de poursuivre l'exécution du programme. En effet, dans
l'invention, le jalonnement du programme peut être réalisé de manière
automatique, c'est-à-dire qu'une balise est positionnée automatiquement au
début de chaque intervalle fonctionnel. Ce jalonnement du programme peut
aussi être interactif, c'est-à-dire que le développeur choisit de positionner
des
balises supplémentaires, au sein d'une même fonction. Ces balises
supplémentaires peuvent être des balises d'entrée, des balises de sortie
et/ou des balises intermédiaires. Le choix du jalonnement, interactif ou
automatique, est déterminé par le développeur lui-même. Le jalonnement
interactif permet d'affiner l'intervalle de recherche et de correction d'une
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
erreur, ce qui permet de réduire ledit intervalle et donc de faciliter la
détection
de l'erreur.
On comprend de ce qui précède, que le procédé de l'invention permet
d'effectuer un débogage en utilisant un volume d'informations peu élevé, par
rapport aux procédés connus, car les données capturées puis restituées au
moyen des points de contrôle et des points de cheminement sont
uniquement celles correspondant à un seul état d'exécution. En effet, le
volume des informations d'état d'exécution du programme est faible. En
outre, le coût d'une telle régénération ne dépend ni de la position de l'état
d'exécution de départ du programme que l'on cherche à régénérer, ni de la
taille de la mémoire de données 4.
La figure 2a montre un exemple d'une unité de commande 1 d'un
environnement de test d'un logiciel de fonctionnement d'un système destiné
à être embarqué dans un aéronef. L'environnement de test peut être, selon
des variantes de réalisation, soit simulé virtuellement sur une plateforme
hôte, soit basé sur un équipement matériel de type émulateur.
L'unité de commande 1 comporte, de manière non exhaustive, un
processeur 2, une mémoire programme 3, une mémoire de données 4, et
une interface d'entrée/sortie 5. Le processeur 2, la mémoire de programme
3, la mémoire de données 4 et l'interface d'entrée/sortie 5 sont connectés les
uns aux autres par un bus de communication 6 bidirectionnel.
Sur la figure 2a, on a représenté schématiquement, un programme 7
du logiciel de fonctionnement, durant une phase de débogage. Le
programme 7 comporte un chemin d'exécution 8. Le chemin d'exécution 8
comporte un ensemble de lignes de codes instructions. Le chemin
d'exécution 8 est découpé de manière régulière et appropriée pour former
des intervalles fonctionnels. Le programme 7 est donc en liaison constante,
pendant la phase de débogage, avec le processeur 2, la mémoire
programme 3 et la mémoire de données 4.
La mémoire programme 3 comporte, dans une zone 9, les instructions
permettant d'effectuer un balisage du programme 7. Le balisage du
programme 7 permet de mettre en place tout au long du chemin d'exécution
8 des points de cheminement 10. Chaque point de cheminement 10 est
associé à un intervalle fonctionnel. Le balisage du programme 7 permet
également de positionner des points de contrôles 11, 12, 13, 14 et 15 en
CA 02697725 2010-02-24
WO 2009/047433 PCT/FR2008/051647
16
regard des points de cheminement 10 respectifs. La mémoire programme 3,
comporte, dans une zone 21, les instructions permettant une exécution du
programme 7. L'exécution du programme 7 permet de dérouler le chemin
d'exécution 8, instruction par instruction. Le déroulement du chemin
d'exécution du programme 7 valide le passage sur des points de
cheminement 10. Le franchissement de points de cheminement active
séquentiellement les points de contrôle 11, 12, 13, 14 et 15. La mémoire
programme 3, comporte dans une zone 22 les instructions pour capturer des
informations d'état de départ d'exécution du programme 7. L'activation des
points de contrôle 11, 12, 13, 14 et 15 permet de capturer séquentiellement
les états de départ d'exécution du programme 7. La mémoire programme 3,
comporte, dans une zone 23, les instructions pour mémoriser les
informations d'état de départ d'exécution du programme 7. La mémorisation
de ces informations est effectuée dans la mémoire de données 4. La
mémoire programme 3, comporte, dans une zone 24, les instructions
permettant de restituer les informations d'état d'exécution mémorisées. Sur
la figure 2b, on a représenté plus en détail la mémoire de données 4.
