Brevet FR2921171A1 — publié le 20090320

Procédé de minimisation du volume d'informations requis pour le débogage d'un logiciel de fonctionnement d'un système embarqué à bord d'un aéronef, et dispositif de mise en oeuvre Domaine de l'invention 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 utilisateur de réduire de manière significative le io 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, 15 plus particulièrement, dans le domaine des tests de logiciels de fonctionnement des systèmes embarqués. Etat de la technique 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 20 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 25 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 30 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... 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 io 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. 15 L'avantage de ce type d'architecture tient au fait que le fonctionnement d'un tel système est beaucoup mieux maîtrisé. Il n'est pas dépendant d'un système d'exploitation complexe dont certains aspects du fonctionnement sont fonction de paramètres non maîtrisés et qui devrait, sinon, faire l'objet des mêmes démonstrations de sécurité que les logiciels 20 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 25 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 à 30 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-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 io 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 15 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 20 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, 25 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é 30 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 35 (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 maîtriser. 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 io 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 15 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 20 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 25 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 30 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 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 l'utilisateur 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 io 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 15 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 20 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 25 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 30 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, 35 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 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 15 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 20 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 25 du logiciel de fonctionnement ou par le fait que le logiciel reste bloqué dans une boucle d'instructions infinie. L'utilisateur 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 30 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 de codes instructions, l'utilisateur comprenne le déroulement des lignes de codes instructions. Or, l'utilisateur 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 l'utilisateur, de comprendre suffisamment le déroulement du programme io 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 à l'utilisateur 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 15 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 20 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. 25 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 30 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- 35 write). Cette solution se base sur une vérification régulière du pointage des 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. Exposé de l'invention La présente invention a pour but de remédier aux inconvénients io 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 15 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 20 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 25 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, d) lorsqu'une erreur est détectée : 30 -recherche du point de cheminement correspondant à une fonction défaillante, - 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 35 - ré-exécution du programme. L'invention peut comporter aussi une ou plusieurs des caractéristiques suivantes : - l'exécution normale du programme comporte une capture de l'état d'exécution du programme à l'emplacement de chaque point de 5 cheminement. - un seul état d'exécution est mémorisé simultanément dans une mémoire de donnée. - la mémorisation d'un état d'exécution entraîne une suppression de l'état d'exécution précédemment mémorisé. io - 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. 15 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. 20 L'invention à également pour objet un programme 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é. 25 Brèves description des dessins 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 30 Les figures 2a et 2b représentent schématiquement un dispositif dans lequel le procédé de l'invention est mis en oeuvre. Description détaillée de modes de réalisation de l'invention Un programme de fonctionnement d'un système embarqué comprend un ensemble de chaînes d'instructions. Ces chaînes d'instructions sont 35 exécutées, normalement, dans leur ordre d'occurrence, c'est-à-dire de la première instruction à la dernière instruction. Ces chaînes 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 et les anomalies 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 io 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 15 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. 20 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 25 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 30 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 35 correspond à une image de la mémoire dans laquelle sont enregistrées les 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 io 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 15 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 20 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 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 25 situé après une fonction exécutée normalement (à la fin de la fonction ou à l'entre 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 30 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é 35 est le dernier état d'exécution capturé, c'est-à-dire l'état d'exécution du 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 io programme lors de l'exécution reverse. Lorsqu'une erreur survient, l'utilisateur 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 15 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 20 programme se produit, on recherche quel était le dernier point de cheminement activé et on se replacement à 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 25 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 30 fonctionnel. Lorsqu'une chaîne défaillante, ou erreur, a été détectée dans cet intervalle fonctionnel, l'utilisateur 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 35 reprise du programme nécessite de récupérer l'état d'exécution de départ. 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 io 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 15 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 20 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 25 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 30 emplacement donné. Cet état d'exécution du programme capturé est mémorisé à l'étape 37. A 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. 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. io 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 15 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 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é- 20 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 l'utilisateur. Si un saut d'intervalle fonctionnel a été requis, alors on applique l'étape 41 et les étapes 25 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. Il peut aussi être interactif, c'est-à- 30 dire que l'utilisateur 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 l'utilisateur 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. 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 io 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 15 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 20 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 25 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. 30 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 35 également de positionner des points de contrôles 11, 12, 13, 14 et 15 en 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 io 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 15 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. 20 REVENDICATIONS 1 ù Procédé de traitement du volume d'informations manipulé durant une phase de débogage d'un programme de fonctionnement d'un système embarqué, caractérisé en ce qu'il comporte les étapes suivantes : a) découpage (32) 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 (33) de points de contrôle associés à chaque point io de cheminement, c) exécution (34) normale du programme, d) lorsqu'une erreur est détectée : - recherche du point de cheminement correspondant à une fonction défaillante, 15 - recherche (41) d'un état d'exécution de départ du programme, - régénération (42) de cet état d'exécution de départ, - correction (44) de l'erreur dans la fonction défaillante, et - ré-exécution du programme. 2 ù Procédé selon la revendication 1, caractérisé en ce que 20 l'exécution normale du programme comporte une capture (36) de l'état d'exécution du programme à l'emplacement de chaque point de cheminement. 3 ù Procédé selon la revendication 2, caractérisé en ce que un seul état d'exécution est mémorisé simultanément dans une mémoire de donnée. 25 4 ù Procédé selon la revendication 3, caractérisé en ce que la mémorisation d'un état d'exécution entraîne une suppression de l'état d'exécution précédemment mémorisé. 5 ù Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, après exécution normale d'une fonction, le point de 30 cheminement correspondant à cette fonction passe d'un état désactivé à un état activé. 6 ù Procédé selon la revendication 5, caractérisé en ce que la recherche de la fonction défaillante consiste à rechercher le dernier point de cheminement activé.7 ù Procédé selon la revendication 5 ou 6, caractérisé en ce que qu'une liste des points de cheminement avec leur état est mémorisée. 8 ù 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é selon l'une quelconque des revendications 1 à 7. 9 ù Dispositif selon la revendication 8, caractérisé en ce qu'il comporte une mémoire de données (4) apte à mémoriser un état d'exécution du programme. ù Programme de fonctionnement pour système embarqué à bord io d'un aéronef, chargeable sur une unité de commande (1) comprenant des séquences d'instructions pour mettre en oeuvre le procédé selon l'une des revendications 1 à 7, lorsque le programme est chargé sur l'unité et y est exécuté.