Note: Descriptions are shown in the official language in which they were submitted.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
1
Procédé 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 appartient au domaine de la sécurité de
fonctionnement des systèmes lorsque le fonctionnement de ces systèmes
dépend de l'exécution, dans un calculateur, de suites d'instructions logiques.
En particulier, l'invention a pour objet un procédé de débogage d'un
logiciel de fonctionnement d'un système devant exécuter des suites
d'instructions logiques, notamment d'un système ayant des exigences de
sécurité élevées tel qu'un système électronique destiné à être embarqué à
bord d'un aéronef.
Le procédé permet, à un développeur, de pouvoir rechercher et
corriger des erreurs dans les suites d'instructions logiques des logiciels de
fonctionnement de systèmes 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 de la
réalisation de tests de logiciels de fonctionnement de systèmes destinés à
être 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
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
2
laquelle le calculateur est connecté à un réseau de calculateurs, à des
périphériques externes, etc...
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.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
3
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-
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
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
4
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.
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.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
Comme chaque processeur nécessite un émulateur spécifique, tant
pour le logiciel d'émulation que pour la sonde se raccordant à la place du
processeur, il est nécessaire de multiplier les émulateurs conformément aux
définitions des calculateurs.
5 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.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
6
Les instructions d'appels système sont interceptées par le système
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 et de vérification du logiciel du
calculateur, l'exécution des tests peut révéler des erreurs qui se manifestent
soit par un arrêt du déroulement du logiciel de fonctionnement, soit par le
fait
que un ou plusieurs cas de test ont produit des résultats erronés. 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.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
7
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
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. Cela est dû au fait que les outils de
débogage actuels n'offre aucun moyen pour supporter efficacement
l'exécution reverse : il s'agit de revenir soit de n unités de temps
(généralement la seconde), soit de n pas de calcul. Il n'y a aucun lien
fonctionnel avec la logique du logiciel à déboguer. L'efficacité de
l'exécution
reverse en est considérablement amoindrie, voire complètement annihilée s'il
s'agit d'un logiciel à logique complexe comme c'est généralement le cas pour
le logiciel embarqué.
La présente invention a pour but de remédier aux inconvénients des
techniques exposées précédemment. A cette fin, l'invention propose un
procédé de débogage d'un logiciel de fonctionnement permettant à un
développeur de retrouver facilement l'emplacement d'une erreur ou d'une
anomalie dans la suite d'instruction écrite par le développeur. Pour cela, le
procédé de l'invention propose de structurer l'exécution d'un programme du
logiciel de fonctionnement au moyen d'un jalonnement fonctionnel du chemin
d'exécution. Ce jalonnement fonctionnel est réalisé en positionnant des
balises à des emplacements spécifiques du chemin d'exécution normal du
programme de façon à découper le programme en unités fonctionnelles, ce
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
8
qui permet au développeur de repérer l'emplacement à partir duquel une
exécution reverse doit être effectuée. Ce jalonnement peut être effectué de
manière interactive ou automatique.
Plus précisément, l'invention a pour objet un procédé de débogage
d'un programme de logiciel de fonctionnement d'un système embarqué,
caractérisé en ce qu'il comporte les étapes suivantes :
a) balisage du programme en positionnant des balises le long d'un
chemin d'exécution pour découper ledit chemin d'exécution en intervalles
fonctionnels adjacents,
b) exécution normale du programme,
c) capture d'un état d'exécution du programme par des vecteurs d'état
des balises,
d) lorsqu'une erreur est détectée :
- recherche d'un intervalle fonctionnel défaillant en fonction
des vecteurs d'état des balises,
- exécution reverse du programme dans cet intervalle
fonctionnel défaillant,
- détermination et correction de l'erreur.
Le procédé de l'invention peut comporter également une ou plusieurs
des caractéristiques suivantes :
- une erreur est détectée lorsqu'un arrêt du programme a été détecté,
suite à une exception processeur.
- il comporte une opération d'affinage de l'intervalle fonctionnel dans
lequel se trouve l'erreur.
- l'opération d'affinage de l'intervalle fonctionnel comporte une
détermination de balises supplémentaires d'entrée et de sortie et/ou de
balises intermédiaires.
- l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée
de manière automatique.
- l'étape de recherche de l'intervalle fonctionnel défaillant est effectuée
de manière interactive par intervention d'un développeur.
- il comporte une étape d'enregistrement de la position de chaque
balise et des informations sur l'état d'exécution du programme, dans un
fichier de résultats d'une plate-forme hôte.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
9
L'invention concerne également un dispositif simulant le
fonctionnement d'un système embarqué à bord d'un aéronef, caractérisé en
ce qu'il comporte un processeur mettant en oeuvre un procédé tel que définit
précédemment.
Le dispositif de l'invention peut comporter la caractéristique suivante :
- le processeur est simulé virtuellement sur une plate-forme hôte de
test et de débogage.
L'invention a également pour objet un programme de fonctionnement
pour système embarqué pour aéronef, chargeable sur une unité de
commande comprenant des séquences d'instructions pour mettre en oeuvre
le procédé tel que définit 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 est une représentation schématique du programme selon
l'invention.
La figure 2 illustre un diagramme fonctionnel du procédé de
l'invention.
La figure 3 est une représentation schématique d'un environnement
de test en phase de débogage d'un logiciel de fonctionnement d'un système
embarqué.
Un logiciel de fonctionnement est constitué d'un ensemble de
programmes. Un programme étant constitué d'un ensemble de suite
d'instructions écrites appelé par la suite chaîne d'instructions. Le procédé
selon l'invention propose de positionner des points de repère dans le chemin
d'exécution du programme du logiciel de fonctionnement du système
embarqué afin de pouvoir déterminer, par rapport à ces points de repère, où
se situe l'erreur ou l'anomalie.
La figure 1 est une représentation schématique des différentes phases
de ce procédé. Chaque phase de la figure 1 représente le programme du
logiciel de fonctionnement du système embarqué à une étape différente du
procédé de l'invention. La première phase de la figure 1 est un exemple du
programme avant application du procédé de l'invention. Ce programme,
référencé 20, comprend un ensemble de chaînes d'instructions 20-1 à 20-n.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
Ces chaînes d'instructions exécutées dans leur ordre d'occurrence, c'est-à-
dire de l'instruction 20-1 à l'instruction 20-n, constituent le chemin
d'exécution normal du programme.
La deuxième phase de la figure 1 représente le programme 21 qui
5 correspond au programme 20 après que des balises 28 aient été
positionnées. Les balises 28 sont des repères virtuels positionnés à des
emplacements spécifiques du programme. Ces emplacements
correspondent, de préférence, au début et/ou à la fin des différentes
fonctions du programme. Les balises 28 sont placées, par exemple, à un
10 point d'entrée ou à un 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 le positionnement des balises est réalisé suivant un
jalonnement fonctionnel.
Les balises peuvent aussi être positionnées à tout autre emplacement
prédéfini du chemin d'exécution, par exemple, à un point de défaillance du
programme, au niveau des flots de données ou au niveau du flot de contrôle.
Les balises constituent des points de repère dans le chemin d'exécution du
programme. On comprendra, par la suite, que les balises constituent ainsi
des points de reprise du déroulement du chemin d'exécution du programme,
lorsqu'une ou plusieurs anomalies(s) ou erreur(s) a (ont) été rencontrée(s),
ce qui se manifeste soit par des résultats erronés, soit par une interruption
du
déroulement du programme, soit par une boucle d'exécution infinie.
Une anomalie ou une erreur peut être fonctionnelle. Dans ce cas, le
procédé envoie, au développeur, une invitation à corriger ladite anomalie ou
ladite erreur.
L'anomalie ou l'erreur peut aussi être de nature à engendrer une perte
de contrôle du déroulement du programme. Une telle erreur peut être, par
exemple, un débordement arithmétique du processeur faisant suite, par
exemple, à la présence d'un pointeur positionné sur une zone interdite. Dans
ce cas, l'exécution du programme s'interrompt. Une interruption consécutive
à un débordement arithmétique est appelée interruption sur exception
processeur.
Le jalonnement fonctionnel du chemin d'exécution proposé dans
l'invention permet de détecter, puis de corriger, ce type d'erreur avec
interruption sur exception processeur. Pour cela, le jalonnement selon
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
11
l'invention découpe le chemin d'exécution du programme en intervalles
fonctionnels adjacents. Les fonctions s'exécutent les unes à la suite des
autres. Dans un mode de réalisation de l'invention, une balise est
positionnée au début de chaque fonction. Chaque balise comporte un
vecteur d'état qui correspond à l'image de la mémoire. Ce vecteur d'état
indique l'état de la mémoire à un emplacement prédéfini, c'est-à-dire à
l'emplacement où se situe la balise, ce qui permet, ultérieurement, de
réinitialiser la mémoire Avec les informations du vecteur d'état.
Au début du déroulement du programme, toutes les balises sont
désactivées. Le vecteur d'état de chacune de ces balises est neutre, ou
désactivé, c'est-à-dire qu'il ne contient aucune information. Chaque fois
qu'une fonction a été exécutée normalement, la balise située à l'entrée de la
fonction suivante change d'état en s'activant. Le vecteur d'état de la balise
capture alors un état d'exécution du programme, c'est-à-dire qu'il capture les
informations enregistrées dans la mémoire du système à ce niveau
d'exécution du programme.
Le jalonnement 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. Il 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 erreur, ce qui permet de réduire ledit intervalle et donc
de
faciliter la détection de l'erreur.
Une troisième phase de la figure 1 représente le programme 22
correspondant au programme 21 lors d'une exécution dudit programme en
mode normal. Cette exécution en mode normal, appelée exécution normale,
correspond au déroulement logique du programme, instruction par
instruction, en commençant par la première ligne d'instruction 20-1.
Une quatrième phase de la figure 1 représente le programme 23
correspondant au programme 21, lorsque les informations à l'état d'exécution
du programme et à la position des balises ont été capturées. En effet, lors de
l'exécution normale du programme, la balise située à la fin d'une fonction
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
12
exécutée normalement est activée. Le vecteur d'état de cette balise capture
ou mémorise l'état de la mémoire à ce niveau d'exécution du programme.
Lors d'une interruption du programme, la dernière balise activée
indique la fonction où une interruption du programme a eu lieu. Le vecteur
d'état de cette balise permet de retrouver l'état d'exécution dans lequel
était
le programme au moment où débutait l'exécution de la fonction défaillante.
Pour permettre la capture par les vecteurs d'état, un outil
d'observation de l'exécution normale détermine les passages sur les balises,
dans leur ordre d'occurrence normale, c'est-à-dire suivant une exécution
normale des lignes d'instructions du programme. Lorsqu'une balise a été
franchie, l'outil d'observation capture l'état de la mémoire dans le vecteur
d'état de la dernière balise rencontrée et l'enregistre dans une mémoire de
données 4.
Lorsqu'une erreur survient, le développeur effectue une exécution
reverse du programme pour retrouver ladite erreur au sein du programme. La
cinquième phase de la figure 1 représente le programme 24 correspondant
au programme 23 lors de cette exécution reverse. 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 à la dernière balise activée, c'est-à-dire la
dernière fonction dont le vecteur d'état a été capturé.
Autrement dit, l'exécution reverse est menée en suivant les balises
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 balises, le développeur est capable de repérer facilement
la chaîne d'instructions défaillante. Lorsqu'une erreur a été corrigée, le
développeur peut continuer l'exécution reverse pour détecter les éventuelles
autres erreurs. En effet, avec le procédé de l'invention, le chemin
d'exécution
est structuré de telle sorte que plusieurs erreurs ou anomalies peuvent être
détectées et corrigées en une seule phase de débogage du programme.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
13
La phase de débogage qui vient d'être décrite, c'est-à-dire la phase de
recherche et de correction d'une erreur, est représentée par le programme
25 sur la figure 1.
Lorsqu'une erreur a été fixée et que le développeur souhaite passer à
une erreur suivante ou précédente, il peut disposer d'une phase interactive.
Dans cette phase interactive, le programme 26 comporte un jalonnement
interactif grâce auquel le développeur peut sauter d'un intervalle fonctionnel
à un autre.
La figure 2 illustre de façon détaillée les différentes étapes du procédé
de l'invention. Le diagramme fonctionnel de la figure 2 montre une étape
préliminaire 30 dans laquelle une unité de commande de l'environnement de
test détecte si une phase de débogage a été sollicitée par le développeur.
Lorsque le développeur souhaite effectuer un débogage, l'unité de
commande de l'environnement de test effectue, à l'étape 31, un balisage du
programme en positionnant des balises le long du chemin d'exécution pour
découper ledit chemin d'exécution en intervalles fonctionnels adjacents.
Chaque balise comporte un vecteur d'état activé ou désactivé, comme
expliqué précédemment. Le vecteur d'état d'une balise est dit activé lorsque
les informations relatives à l'état d'exécution du programme ont été
capturées. Ainsi, un vecteur d'état d'une balise est activé lorsque la
fonction
qui précède la balise a été exécutée sans erreur. Il reste désactivé dans le
cas contraire.
A l'étape 32, l'unité de commande lance l'exécution normale du
programme.
A l'étape 33, l'unité de commande capture les informations d'état dans
les vecteurs d'états des balises afin de connaitre l'état d'exécution du
programme.
A l'étape 34, l'unité de commande détecte s'il y a une interruption de
l'exécution du programme du logiciel de fonctionnement. Si le programme
s'arrête, cela signifie qu'une erreur ou une anomalie a été détectée. On
applique, alors l'étape 35. Si aucune interruption n'a lieu, l'exécution
normale
se poursuit et les étapes 32 et 33 sont réitérées.
A l'étape 35, on détermine si l'interruption a eu lieu sur une exception
processeur. Si tel est le cas, alors on applique l'étape 36. Dans le cas
contraire, on applique l'étape 37. Dans ce cas, un message est transmis au
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
14
développeur pour signifier que l'exécution du programme se termine, soit
parce qu'une erreur fonctionnelle a été détectée, soit parce que l'exécution
normale s'est terminée sans erreur.
Le procédé se poursuit alors par une étape 43, dans laquelle l'unité de
commande enregistre la position des balises dans un fichier de résultats des
tests, pour permettre une consultation ultérieure du cheminement
d'exécution.
A l'étape 44, le fichier de résultats des tests est fermé. L'étape 45 est
une étape finale indiquant la fin du test ou de l'exécution du programme.
Si une exception processeur a été détectée à l'étape 35, alors, on
recherche, à l'étape 36, la première balise désactivée dans le cheminement
normal afin d'en déduire l'intervalle fonctionnel où se trouve la chaîne
défaillante. On applique ensuite l'étape 38. A l'étape 38, le développeur peut
implanter, de manière interactive, des balises supplémentaires d'entrée, des
balises supplémentaires de sortie et/ou des balises intermédiaires pour
affiner l'intervalle de recherche de l'erreur dans l'intervalle fonctionnel
déterminé à l'étape 36. A l'étape 39, on détecte des points de défaillance
dans les flots de données ou les flots de contrôle. Ces points de défaillance
permettent d'affiner encore l'intervalle autour de l'erreur. Après
détermination
de ces points de défaillance, on délimite, à l'étape 40, un intervalle
défaillant
autour de l'erreur.
Il est à noter que les étapes 38 à 40 constituent un mode de
réalisation préféré de l'invention dans lequel l'intervalle autour de l'erreur
est
réduit afin de faciliter la recherche de l'erreur lors de l'exécution reverse.
Toutefois, le procédé peut prévoir de passer simplement de l'étape 36
de détection de la balise inactive à l'étape 41 d'exécution reverse. Dans ce
cas, le développeur doit effectuer l'exécution reverse sur l'ensemble de la
fonction dans laquelle l'erreur a été détectée.
A l'étape 41, on lance l'exécution reverse permettant de remonter à la
fonction où la chaîne d'instructions défaillante du programme a été détectée.
Dans un mode de réalisation de l'invention, l'exécution reverse se fait entre
deux balises successives (intervalle). Cela correspond dans le cas les plus
courants au début et à la fin de la fonction défaillante. On peut bien sûr
sauter d'un intervalle à l'autre sans aucune contrainte particulière. Dans un
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
autre mode de réalisation, l'exécution reverse est effectuée sur un intervalle
affiné autour de l'erreur, c'est-à-dire sur une partie seulement de la
fonction.
A l'étape 42, le développeur effectue le débogage de l'erreur c'est-à-
dire qu'il détermine l'erreur dans l'intervalle fonctionnel défaillant et la
corrige.
5 Lorsque l'étape 42 de débogage est terminée, le procédé est réitéré à
l'étape
31 afin de vérifier si le programme s'exécute correctement.
Lorsque l'unité de commande ne détecte plus d'interruption sur
exception processeur, alors l'unité de commande envoie, au développeur, un
message indiquant que la phase de débogage du programme est terminée
10 (étape 37).
Le procédé selon l'invention peut être mis en oeuvre dans un
environnement de test du système simulé virtuellement sur une plate-forme
hôte. Il peut être également implanté sur une station de travail connectée à
un système embarqué réel par l'intermédiaire d'un émulateur de
15 fonctionnement dédié. Dans ce cas, la position des balises et/ou les
vecteurs
d'états sont enregistrés (étape 43) sur un support accessible au développeur,
par exemple, dans un fichier de résultats de la plate forme hôte. Lorsque
toutes les positions de balises ont été enregistrées, le fichier de résultats
est
fermé (étape 44) et le test est terminé (étape 45). Une vérification de tous
les
résultats est effectuée (étape 46). Lorsque tous les résultats sont bons, ou
ok, on arrive à une étape 47 de fin indiquant que tous ces résultats sont ok.
Si tous les résultats ne sont pas ok, les étapes 36 à 42 sont réitérées.
La figure 3 montre un exemple d'une unité de commande 1 de
l'environnement de test du programme de fonctionnement du système
embarqué, mettant en oeuvre le procédé selon l'invention. L'unité de
commande 1 comporte 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 programme 3, la mémoire de donnée 4, et l'interface entrée/sortie 5
sont reliés les uns aux autres par un bus de communication 6 bidirectionnel.
Un programme 7 est exécuté par le processeur 2, en utilisant des
chaînes de codes instructions implantées dans la mémoire programme 3. Le
programme 7 a pour rôle de piloter et de contrôler le fonctionnement du
système embarqué. Le programme 7 comporte, de manière non exhaustive,
un gestionnaire d'interruptions 8, une librairie 9, un ordonnanceur 10, et un
ensemble d'applications 11.
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
16
La librairie 9 comporte une collection de fonctions de commandes
activées par le programme 7. Le gestionnaire d'interruptions 8 a pour rôle de
réagir en temps réel à des sollicitations du processeur 2 inattendues mais
aussi d'assurer la cohabitation multitâche de l'environnement de test.
L'ordonnanceur 10 est un programme de service permettant de déterminer
automatiquement un ordre de priorité dans le traitement des tâches que le
processeur 2 doit effectuer, en fonction de divers critères de priorité et en
fonction des ressources disponibles.
La mémoire programme 3 comporte, dans une zone 12, les
instructions permettant de construire un jalonnement fonctionnel du
programme 7 tel que décrit précédemment et d'indiquer la position de l'erreur
ou de l'anomalie rencontrée afin de la corriger.
La mémoire programme 3 comporte, dans une zone 13, des
instructions pour capturer les vecteurs d'état des balises dans le programme
7. La position de chaque balise activée ainsi que son vecteur d'état sont
enregistrés dans la mémoire de données 4.
La mémoire programme 3 comporte, dans une zone 14, des
instructions pour lancer l'exécution normale du programme 7. L'exécution du
programme 7 du logiciel de fonctionnement se déroule séquentiellement,
instruction par instruction, et provoque progressivement l'activation des
vecteurs d'état des balises. Quand une erreur survient dans une fonction,
l'exécution du programme 7 s'arrête. Les vecteurs d'état des balises qui se
trouvent après la fonction où se trouve l'erreur ne sont pas activés. Le
vecteur d'état de la dernière balise activée constitue alors un repère qui
indique la fonction défaillante, c'est-à-dire la fonction contenant l'erreur.
La mémoire programme 3 comporte, dans une zone 15, des
instructions pour lancer une exécution reverse. L'exécution reverse permet,
lorsqu'une erreur a été détectée, de remonter jusqu'à la fonction contenant
l'instruction défaillante. Le développeur se place sur la balise associée au
dernier vecteur d'état activé pour recommencer l'exécution de la fonction.
Ainsi, le développeur effectue uniquement l'exécution reverse sur la fonction
défaillante.
La mémoire programme 3 comporte, dans une zone 16 des
instructions permettant d'exploiter les informations recueillies par
CA 02697726 2010-02-24
WO 2009/047435 PCT/FR2008/051649
17
l'intermédiaire des balises. Ces instructions permettent le débogage du
programme 7.
La mémoire programme 3 comporte, dans une zone 17, des
instructions permettant d'effectuer des sauts d'intervalles fonctionnels. En
d'autres termes, les codes instructions de la zone 17 permettent de sauter
d'un intervalle fonctionnel à un autre, que le déroulement du programme 7
soit en exécution normale ou en exécution reverse.
On comprend de ce qui précède que le jalonnement fonctionnel de
l'invention permet un débogage de logiciels efficace car il offre un moyen de
repérer les chaînes d'instructions défaillantes afin de limiter l'exécution
reverse aux instructions d'une seule fonction. En outre, il permet de corriger
plusieurs erreurs en une seule phase de débogage.
