CA2697725C - Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre - Google Patents
Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre Download PDFInfo
- Publication number
- CA2697725C CA2697725C CA2697725A CA2697725A CA2697725C CA 2697725 C CA2697725 C CA 2697725C CA 2697725 A CA2697725 A CA 2697725A CA 2697725 A CA2697725 A CA 2697725A CA 2697725 C CA2697725 C CA 2697725C
- Authority
- CA
- Canada
- Prior art keywords
- execution
- program
- state
- waypoint
- function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
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 (32) du chemin d'exécution dudit pro-gramme de fonctionnement en intervalles fonctionnels en po-sitionnant des points de cheminement à chaque fonction du programme; b) mise en place (33) de points de contrôle asso-cié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; 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.
Description
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...
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...
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-
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-
3 PCT/FR2008/051647 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.
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.
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 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 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 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 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, - 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 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 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 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.
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.
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 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 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.
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 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 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 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 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, - 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 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 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 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.
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.
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 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 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.
Claims (12)
1 ¨ Procédé de traitement d'un volume d'informations manipulé durant une phase de débogage d'un programme d'un logiciel de fonctionnement d'un système embarqué, comportant les étapes suivantes :
a) découpage d'un 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 dans une fonction défaillante du programme:
- recherche du point de cheminement correspondant au dernier état d'exécution mémorisé, - recherche d'un état d'exécution de départ correspondant audit dernier état d'exécution mémorisé, - régénération de cet état d'exécution de départ, - correction de l'erreur dans la fonction défaillante du programme, et - réexécution du programme à partir dudit point de cheminement correspondant audit dernier état d'exécution mémorisé, en utilisant des données relatives à l'état d'exécution de départ.
a) découpage d'un 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 dans une fonction défaillante du programme:
- recherche du point de cheminement correspondant au dernier état d'exécution mémorisé, - recherche d'un état d'exécution de départ correspondant audit dernier état d'exécution mémorisé, - régénération de cet état d'exécution de départ, - correction de l'erreur dans la fonction défaillante du programme, et - réexécution du programme à partir dudit point de cheminement correspondant audit dernier état d'exécution mémorisé, en utilisant des données relatives à l'état d'exécution de départ.
2 ¨ Procédé selon la revendication 1, dans lequel un seul état d'exécution est mémorisé simultanément dans une mémoire de donnée.
3 ¨ Procédé selon la revendication 1 ou 2, dans lequel, après exécution normale d'une fonction, le point de cheminement correspondant à cette fonction passe d'un état désactivé à un état activé.
4 ¨ Procédé selon la revendication 3, dans lequel la recherche du point de cheminement correspondant au dernier état d'exécution mémorisé consiste à rechercher le dernier point de cheminement activé.
¨ Procédé selon la revendication 3 ou 4, dans lequel une liste des points de cheminement avec leur état est mémorisée.
6 ¨ Dispositif de traitement d'un volume d'informations manipulé durant une phase de débogage d'un programme d'un logiciel de fonctionnement d'un système embarqué, comportant:
a) des moyens de découpage d'un chemin d'exécution dudit programme de fonctionnement en intervalles fonctionnels en positionnant des points de cheminement à chaque fonction du programme, b) des moyens de mise en place de points de contrôle associés à
chaque point de cheminement, c) des moyens d'exécution normale du programme comportant:
- des moyens de 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înant 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 dans une fonction défaillante du programme:
- des moyens de recherche du point de cheminement correspondant au dernier état d'exécution mémorisé, - des moyens de recherche d'un état d'exécution de départ correspondant audit dernier état d'exécution mémorisé, - des moyens de régénération de cet état d'exécution de départ, - des moyens de correction de l'erreur dans la fonction défaillante du programme, et - des moyens de réexécution du programme à partir dudit point de cheminement correspondant audit dernier état d'exécution mémorisé, en utilisant des données relatives à
l'état d'exécution de départ.
a) des moyens de découpage d'un chemin d'exécution dudit programme de fonctionnement en intervalles fonctionnels en positionnant des points de cheminement à chaque fonction du programme, b) des moyens de mise en place de points de contrôle associés à
chaque point de cheminement, c) des moyens d'exécution normale du programme comportant:
- des moyens de 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înant 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 dans une fonction défaillante du programme:
- des moyens de recherche du point de cheminement correspondant au dernier état d'exécution mémorisé, - des moyens de recherche d'un état d'exécution de départ correspondant audit dernier état d'exécution mémorisé, - des moyens de régénération de cet état d'exécution de départ, - des moyens de correction de l'erreur dans la fonction défaillante du programme, et - des moyens de réexécution du programme à partir dudit point de cheminement correspondant audit dernier état d'exécution mémorisé, en utilisant des données relatives à
l'état d'exécution de départ.
7 ¨ Dispositif selon la revendication 6, dans lequel les moyens de mémorisation comportent une mémoire de données apte à mémoriser un état d'exécution du programme.
8 ¨ Dispositif selon la revendication 7, dans lequel un seul état d'exécution est mémorisé simultanément dans la mémoire de donnée.
9 ¨ Dispositif selon l'une quelconque des revendications 6 à 8, comprenant des moyens pour faire passer, après exécution normale d'une fonction, le point de cheminement correspondant à cette fonction d'un état désactivé à un état activé.
¨ Dispositif selon la revendication 9, dans lequel les moyens de recherche du point de cheminement correspondant au dernier état d'exécution mémorisé effectuent une recherche du dernier point de cheminement activé.
11 ¨ Dispositif selon la revendication 6, dans lequel les moyens de mémorisation mémorisent une liste des points de cheminement avec leur état.
12 ¨ Produit informatique comprenant une mémoire lisible par un processeur et sur laquelle sont emmagasinées des séquences d'instructions qui, lorsqu'exécutées par le processeur, effectuent les étapes du procédé
selon l'une quelconque des revendications 1 à 5.
selon l'une quelconque des revendications 1 à 5.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0757600 | 2007-09-14 | ||
| FR0757600A FR2921171B1 (fr) | 2007-09-14 | 2007-09-14 | Procede de minimisation du volume d'informations requis pour le debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre |
| PCT/FR2008/051647 WO2009047433A2 (fr) | 2007-09-14 | 2008-09-12 | 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 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2697725A1 CA2697725A1 (fr) | 2009-04-16 |
| CA2697725C true CA2697725C (fr) | 2015-11-17 |
Family
ID=39145012
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2697725A Expired - Fee Related CA2697725C (fr) | 2007-09-14 | 2008-09-12 | Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US20100299559A1 (fr) |
| EP (1) | EP2188724A2 (fr) |
| JP (1) | JP2010539577A (fr) |
| CN (1) | CN101802793A (fr) |
| BR (1) | BRPI0816978A2 (fr) |
| CA (1) | CA2697725C (fr) |
| FR (1) | FR2921171B1 (fr) |
| RU (1) | RU2451990C2 (fr) |
| WO (1) | WO2009047433A2 (fr) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8880668B2 (en) * | 2011-02-28 | 2014-11-04 | Verizon Patent And Licensing Inc. | Method and system for integrating data from multiple sources |
| US8776029B2 (en) | 2011-03-23 | 2014-07-08 | Zerodee, Inc. | System and method of software execution path identification |
| US8755612B2 (en) | 2011-12-15 | 2014-06-17 | Hewlett-Packard Development Company, L.P. | Identifying truncated character strings |
| FR2989794B1 (fr) * | 2012-04-24 | 2014-04-04 | Thales Sa | Procede et dispositif de capture du besoin pour un systeme de pilotage automatique pour aeronef |
| US9921859B2 (en) * | 2014-12-12 | 2018-03-20 | The Regents Of The University Of Michigan | Runtime compiler environment with dynamic co-located code execution |
| CN106371991A (zh) * | 2016-08-31 | 2017-02-01 | 重庆四联测控技术有限公司 | 一种程序故障的监控方法及系统 |
| FR3072475B1 (fr) * | 2017-10-17 | 2019-11-01 | Thales | Procede de traitement d'une erreur lors de l'execution d'une procedure avionique predeterminee, programme d'ordinateur et systeme de detection et d'alerte associe |
| CN111427327A (zh) * | 2019-12-27 | 2020-07-17 | 湖北航天飞行器研究所 | 一种飞行器控制软件异常重启的保护方法 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH03225533A (ja) * | 1990-01-31 | 1991-10-04 | Fujitsu Ltd | コピーオンライト逆実行チェックポイント方式 |
| JPH103403A (ja) * | 1996-06-18 | 1998-01-06 | Toshiba Corp | 計算機システムおよびデバッグ方法 |
| JPH10198578A (ja) * | 1998-01-29 | 1998-07-31 | Toshiba Corp | デバッグ方式およびデバッグ方法 |
| US6748583B2 (en) * | 2000-12-27 | 2004-06-08 | International Business Machines Corporation | Monitoring execution of an hierarchical visual program such as for debugging a message flow |
| JP2002207611A (ja) * | 2001-01-11 | 2002-07-26 | Mitsubishi Heavy Ind Ltd | ソフトウェアワーキングベンチ |
| IL151251A0 (en) * | 2002-08-14 | 2003-04-10 | Elta Systems Ltd | Parallel processing platform with synchronous system halt-resume |
| CA2408457A1 (fr) * | 2002-10-17 | 2004-04-17 | Ibm Canada Limited-Ibm Canada Limitee | Collecte et detection de differences entre les valeurs d'expressions/variables dans le debogage d'un processus informatique |
| RU2215668C1 (ru) * | 2002-11-11 | 2003-11-10 | ОАО "ОКБ им. А.С. Яковлева" | Комплекс бортового радиоэлектронного оборудования легкого многоцелевого самолета |
| US20040199786A1 (en) * | 2002-12-02 | 2004-10-07 | Walmsley Simon Robert | Randomisation of the location of secret information on each of a series of integrated circuits |
| FR2864655B1 (fr) * | 2003-12-31 | 2006-03-24 | Trusted Logic | Procede de controle d'integrite de programmes par verification d'empreintes de traces d'execution |
| RU42303U1 (ru) * | 2004-06-08 | 2004-11-27 | Открытое акционерное общество "Раменское приборостроительное конструкторское бюро" | Имитатор бортового радиоэлектронного оборудования |
| US7543278B2 (en) * | 2004-10-15 | 2009-06-02 | Microsoft Corporation | System and method for making a user interface element visible |
| US7849450B1 (en) * | 2005-01-28 | 2010-12-07 | Intel Corporation | Devices, methods and computer program products for reverse execution of a simulation |
| US20080155216A1 (en) * | 2005-02-17 | 2008-06-26 | Dov Shoham | Protection and Recovery System for Automatic Disk Recovery |
| US7492186B2 (en) * | 2005-07-15 | 2009-02-17 | Tabula, Inc. | Runtime loading of configuration data in a configurable IC |
| WO2008097912A2 (fr) * | 2007-02-06 | 2008-08-14 | Progress Software Corporation | Configuration de processus basé sur un événement |
| US20080307397A1 (en) * | 2007-06-08 | 2008-12-11 | Bill Angell | Program Analysis by Partial Emulation |
-
2007
- 2007-09-14 FR FR0757600A patent/FR2921171B1/fr not_active Expired - Fee Related
-
2008
- 2008-09-12 US US12/678,144 patent/US20100299559A1/en not_active Abandoned
- 2008-09-12 EP EP08836916A patent/EP2188724A2/fr not_active Withdrawn
- 2008-09-12 BR BRPI0816978 patent/BRPI0816978A2/pt not_active IP Right Cessation
- 2008-09-12 CA CA2697725A patent/CA2697725C/fr not_active Expired - Fee Related
- 2008-09-12 RU RU2010114708/08A patent/RU2451990C2/ru not_active IP Right Cessation
- 2008-09-12 JP JP2010524556A patent/JP2010539577A/ja active Pending
- 2008-09-12 CN CN200880106873A patent/CN101802793A/zh active Pending
- 2008-09-12 WO PCT/FR2008/051647 patent/WO2009047433A2/fr active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| WO2009047433A3 (fr) | 2010-03-18 |
| US20100299559A1 (en) | 2010-11-25 |
| RU2451990C2 (ru) | 2012-05-27 |
| RU2010114708A (ru) | 2011-10-20 |
| EP2188724A2 (fr) | 2010-05-26 |
| BRPI0816978A2 (pt) | 2015-03-24 |
| JP2010539577A (ja) | 2010-12-16 |
| FR2921171A1 (fr) | 2009-03-20 |
| WO2009047433A2 (fr) | 2009-04-16 |
| CN101802793A (zh) | 2010-08-11 |
| FR2921171B1 (fr) | 2015-10-23 |
| CA2697725A1 (fr) | 2009-04-16 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2697725C (fr) | Procede de traitement du volume d'informations manipule durant une phase de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre | |
| FR2921172A1 (fr) | Procede de debogage d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef et dispositif de mise en oeuvre | |
| US10990504B2 (en) | Time travel source code debugger incorporating future prediction | |
| FR2921170A1 (fr) | Procede de generation automatique de programmes de test d'un logiciel de fonctionnement d'un systeme embarque a bord d'un aeronef, et dispositif de mise en oeuvre | |
| US9043761B2 (en) | Fault localization using condition modeling and return value modeling | |
| US20080244325A1 (en) | Automated software support system with backwards program execution and debugging | |
| US9256417B2 (en) | Automatic quality assurance for software installers | |
| EP1593982B1 (fr) | Contrôle de la robustesse d'une modélisation d'un système physique | |
| US7185235B2 (en) | Test and verification framework | |
| EP2150897B1 (fr) | Procede de simulation d'un systeme embarque a bord d'un aeronef pour tester un logiciel de fonctionnement et dispositif pour la mise en oeuvre de ce procede | |
| EP4042277A1 (fr) | Procédé de simulation parallèle reproductible de niveau système électronique mis en oeuvre au moyen d'un système informatique multi-coeurs de simulation à événements discrets | |
| FR3012636A1 (fr) | Procede de non-regression d'un outil de conception d'un systeme de surveillance de moteur d'aeronef | |
| FR2958427A1 (fr) | Procede d'agencement d'un logiciel d'application sur le materiel informatique d'un equipement reel ou virtuel et architecture de commande de l'equipement comprenant un tel logiciel | |
| WO2015158742A1 (fr) | Procédé d'analyse du fonctionnement d'un programme exécutable binaire et installation pour la mise en oeuvre de ce procédé | |
| US10956304B2 (en) | Dynamic diagnostic code instrumentation over a historic program execution | |
| FR3035984A1 (fr) | Procede de detection d'un logiciel malveillant | |
| Finnigan | Radiation belt storm probes (rbsp) flight software stress testing: Case study and lessons learned | |
| Magritte | Conclusion et perspectives |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |
Effective date: 20200914 |