Brevet FR2852120A1 — publié le 20040910

La présente invention est relative à un procédé de correction d'erreurs d'un programme temps réel lorsque celui est exécuté par un système d'exploitation temps réel non préemptif. L'analyse d'un programme temps réel en vue de la correction d'erreur peut 5 être conduite de plusieurs manières. Elle peut être réalisée au moyen d'outils qui, en interprétant le code du programme, permettent de déceler un certain nombre d'erreurs telles que sortie des limites d'un tableau, division par zéro, interprétation des variables manipulées, ... Toutefois ces outils ont des possibilités limitées puisque le programme n'est pas exécuté. En particulier la dimension temporelle n'est pas 10 prise en compte dans ce type d'analyse. On ne sait pas prédire par exemple l'enchaînement des tâches du programme temps réel ni l'ordre d'arrivée des interruptions et leurs conséquences sur l'exécution du programme. Il existe d'autres procédés permettant de prendre en compte ces aspects temporels. Ceux-ci se basent sur un certain nombre de principes de synchronisation 15 de tâches propres à un système d'exploitation. Ils utilisent en outre souvent un langage spécifique et imposent les mécanismes de synchronisation des tâches. Or ils ne conviennent pas quand il s'agit d'analyser un programme écrit dans un langage qui ne propose pas de mécanismes de synchronisation - notamment dans le cas d'un programme de haut niveau faisant appel à des fonctions du logiciel de base écrites 20 bien souvent dans un autre langage - et que l'on est contraint d'utiliser ce langage comme c'est le cas très souvent pour les programmes destinés à être embarqués dans un calculateur donné. Ainsi le brevet US 5701439 propose un procédé permettant de générer une plate-forme de simulation capable d'intégrer différents types de processeurs, du code 25 source dans différents langages et des modèle à temps continu aussi bien qu'à temps discret. Le système est donc relativement complexe et suppose de produire des composants logiciels reproduisant les mécanismes de séquencement et synchronisation des tâches. Il implique la génération d'au moins trois composants logiciels, le premier permettant d'intercepter les commandes de synchronisation et de 30 les transmettre à un deuxième composant de type séquenceur dont le but est de séquencer correctement les commandes devant être exécutées en fonction du temps de simulation, et de les transmettre enfin à un troisième composant chargé de l'exécution des tâches en fonction des commandes reçues du séquenceur. Les mécanismes de synchronisation des tâches sont donc imposés et ne correspondent 35 pas forcément au fonctionnement du système d'exploitation sous lequel on veut tester le programme temps réel, notamment dans les cas o le programme est destiné à être embarqué dans un calculateur spécifique d'une application, par exemple un calculateur gérant en temps réel différents actionneurs d'un véhicule automobile en réponse aux données qui lui sont transmises par différents capteurs. D'autre part l'exécution de programmes temps réel implique de fortes contraintes de temps. Le système d'exploitation intègre en effet un séquenceur de tâches qui va imposer à un moment donné l'exécution d'une tâche en fonction des interruptions déclenchées et de leur niveau de priorité respectif. Ainsi lorsqu'on utilise un outil d'analyse statique pendant l'exécution d'un tel programme, on interrompt son 10 exécution au milieu d'une tâche pour que l'utilisateur puisse tenter de corriger les erreurs détectées dans cette tâche. Le programme continue toutefois de générer des interruptions sans qu'il soit possible d'exécuter les tâches devant normalement réagir à ces interruptions. Dans un tel cas de figure, lorsque l'utilisateur termine sa phase de correction d'erreur, le système déclenche l'exécution d'une tâche ultérieure, mais 15 qui n'est pas la tâche consécutive à celle ayant subi la correction et qui aurait été exécutée si la phase de correction d'erreur n'était pas intervenue. Il n'est donc pas possible de savoir par exemple quel est l'effet de la correction sur la ou les tâches normalement immédiatement consécutives à la tâche corrigée. Un procédé ne présentant pas cet inconvénient est proposé dans le brevet 20 US 5.909.577 qui propose d'opérer une transformation de l'environnement d'exécution et de test du programme consistant, par exemple, à interrompre l'exécution du programme à des instants prédéterminés et à exécuter à ces instants là des instructions spécifiques prédéfinies qui vont générer des informations sur le déroulement du programme. Ce procédé s'appuie en particulier sur les possibilités de 25 programmer les outils de test (de type débogueur). Mais pour réaliser cette programmation, il est nécessaire d'avoir préalablement défini quelles seront les modifications nécessaires sur l'environnement, et ce en fonction du type d'information désiré. Ceci n'a d'intérêt que si on a une connaissance a priori sur l'origine et/ou la localisation de l'erreur, suite à une phase d'analyse préalable visant 30 à mettre en évidence ladite erreur. La présente invention a donc pour but de proposer un procédé de correction d'erreur d'un programme temps réel ne présentant pas les inconvénients mentionnés ci-dessus de la technique antérieure. En particulier l'invention a pour but de fournir un procédé permettant de corriger les erreurs d'un programme destiné à être exécuté en 35 environnement temps réel non préemptif, ne nécessitant pas de phase d'analyse préalable et tout en respectant le séquencement de l'activation des tâches du programme temps réel. On atteint ce but de l'invention, ainsi que d'autres qui apparaîtront à la lecture de la description qui va suivre, avec un procédé de correction d'erreur d'un 5 programme temps réel, comportant un nombre donné de tâches et propre à être exécuté par un système d'exploitation temps réel non préemptif, procédé remarquable en ce que: a) on convertit ledit programme temps réel en un programme dit non temps réel, propre à s'exécuter sans contraintes de temps réel et qui 10 simule l'ordre d'exécution des tâches du programme temps réel, b) on exécute le programme non temps réel ainsi obtenu au moyen d'un outil de détection d'erreurs, c) lorsqu'une erreur est détectée, on corrige cette erreur, d) on poursuit l'exécution du programme non temps réel, e) on répète les étapes c) et d) autant de fois que nécessaire, f) on répercute dans le programme temps réel les corrections d'erreur effectuées. Suivant d'autres caractéristiques de la présente invention, l'étape de conversion du programme temps réel en un programme non temps réel, comprend 20 elle-même les étapes suivantes: ai) on crée un programme principal s'exécutant en boucle et comprenant un compteur définissant une échelle des temps pour l'exécution du programme non temps réel, a2) pour chaque tâche du programme temps réel, on crée une fonction 25 du programme non temps réel correspondant à ladite tâche, a3) pour chaque activation d'une tâche dudit programme temps réel, on crée dans pour le programme non temps réel au moins un appel via ledit programme principal à ladite fonction correspondant à ladite tâche, le mode d'appel à la fonction étant fonction du mode d'activation de la tâche 30 dans le programme temps réel. Suivant d'autres caractéristiques de la présente invention: - dans le cas o l'activation de ladite tâche est déclenchée par un événement dans le programme temps réel, le moment de l'appel à la fonction correspondante dans le programme non temps réel est définit par une fonction aléatoire associée audit compteur, - ladite fonction aléatoire est définie par référence à un modèle physique donnant une probabilité d'occurrence dudit événement, - dans le cas o l'activation de ladite tâche est périodique dans le programme temps réel, l'appel à la fonction correspondante dans ledit 10 programme non temps réel est périodique par référence audit compteur. Le procédé suivant l'invention est applicable à la correction d'erreurs éventuelles contenues dans un programme destiné à être embarqué dans un véhicule automobile. D'autres caractéristiques et avantages de la présente invention apparaîtront à 15 la lecture de la description qui va suivre et à l'examen du dessin dans lequel: - les figures 1 et 2 représentent schématiquement l'environnement d'exécution d'un programme temps réel et celui d'un programme non temps réel, - la figure 3 représente trois chronogrammes ChrA, ChrB, ChrC utiles à la 20 description du fonctionnement du procédé de correction d'erreur suivant l'invention. La figure 1 fait apparaître l'environnement d'exécution d'un programme temps réel PTR. Celui-ci s'exécute au sein d'un système d'exploitation temps réel SE. Le programme PTR comporte un nombre donné de tâches Tl, T2. Ces tâches peuvent 25 être de différentes natures. Certaines doivent être activées périodiquement. D'autres au contraire sont activées uniquement sur l'occurrence d'un événement E, qui peut être généré par le programme lui-même ou être déclenché par un élément périphérique interagissant avec le programme. Ainsi le programme à tester peut, par exemple, être une simulation d'un 30 calculateur pour la gestion du contrôle du moteur d'un véhicule automobile. Un tel calculateur reçoit en effet des informations sous forme de mesures de la part de capteurs. D'autre part il est programmé pour émettre des commandes d'actionneurs en réponse aux informations reçues. Les échanges d'information avec ces capteurs peuvent être réalisés de façon périodique de manière à suivre en permanence l'évolution de certains paramètres (par exemple, température d'eau, pression d'admission dans le moteur, régime du moteur, température du liquide de 5 refroidissement...) ou encore être déclenchés sous l'action d'un événement donné (par exemple par activation d'une commande spécifique issu du poste de pilotage, dépassement d'un seuil donné par un paramètre, " Point Mort Haut "...). Ledit système d'exploitation SE comporte un séquenceur SQ qui cadence l'exécution desdites tâches en fonction de leur mode d'activation défini au sein du 10 programme temps réel. Il est important de noter que la décision d'activer une tâche ou non dépend du séquenceur qui, en fonction des caractéristiques d'activation de chaque tâche, en fonction de l'occurrence ou non des événements d'activation des tâches et éventuellement en fonction de leurs niveaux de priorité, va imposer l'activation d'une tâche plutôt qu'une autre. La première étape nécessaire à la mise en oeuvre du procédé selon l'invention est la transformation de ce programme temps réel en un programme non temps réel qui va simuler l'ordre d'exécution des tâches du programme temps réel. Ceci va se faire par substitution d'éléments nouveaux, représentés sur la figure 2, aux différents éléments (figure 1) en présence lors de l'exécution du programme 20 temps réel. On crée d'abord un élément destiné à servir de programme principal PP au programme non temps réel. Comme décrit ci-dessous, ce programme principal se substitue, pour le programme non temps réel, audit système d'exploitation SE en ce qu'il simule l'activation des tâches pour l'exécution du programme non temps réel 25 PNTR. Il est en outre conçu de façon à pouvoir s'exécuter en boucle. Ceci permet en premier lieu d'obtenir un temps d'exécution paramétrable pour l'exécution du programme non temps réel ou encore de le laisser s'exécuter sans limitation prédéfinie de temps. En second lieu, il est ainsi possible simplement de créer, comme on va le voir plus loin, des appels périodiques de fonctions. Au sein de ce programme principal, on crée un compteur C. Ceci peut être réalisé par exemple au moyen d'une simple variable numérique. Le rôle de ce compteur est de définir pour le programme non temps réel une échelle du temps absolu qui va se substituer à l'échelle du temps absolu à laquelle le séquenceur fait référence dans le cas du programme temps réel. De cette façon, c'est le programme 35 principal qui va, de par cette échelle des temps, contrôler et imposer le séquencement des instructions exécutées par le programme non temps réel. En conséquence, une interruption d'un tel programme, par exemple lors de la détection d'une erreur par un outil d'analyse statique, va en quelque sorte arrêter le déroulement du temps pour ce programme; ce qui permettra d'une part d'avancer 5 pas à pas dans l'exécution du programme et d'autre part de reprendre le cours normal de son exécution dès que la phase de correction aura pris fin. Se pose ensuite le problème de la simulation des tâches du programme temps réel au sein du programme non temps réel. Pour ce faire on crée pour chaque tâche du programme temps réel une fonction correspondante dans le programme 10 non temps réel. Il y a correspondance entre la tâche et la fonction en ce sens qu'elles exécutent chacune les mêmes instructions. Seul leur mode de déclenchement diffère: par activation via le séquenceur du système d'exploitation dans le cas d'une tâche, par appel via le programme principal dans le cas d'une fonction. Ensuite chaque activation d'une chaque tâche au sein du programme temps réel va être 15 substituée par au moins un appel via le programme principal à la fonction correspondant à cette tâche. Puisqu'il est nécessaire que le séquencement de ces tâches soit simulé dans le programme non temps réel, l'appel aux fonctions correspondant aux tâches ne se fera pas n'importe quand. Dans ce but, on peut constater, comme évoqué 20 précédemment, qu'il existe principalement deux modes de déclenchement d'une tâche: soit de façon périodique, soit de façon non périodique, en général sur occurrence d'un événement externe ou interne au système. La réalisation du programme non temps réel se doit donc de conserver cette caractéristique fondamentale d'une tâche et en conséquence le mode d'appel à une fonction dans le 25 programme non temps réel sera directement fonction du mode d'activation de la tâche dans le programme temps réel. Plus précisément, dans le cas o une tâche est déclenchée par un événement, le moment d'appel à la fonction correspondante sera définie par une fonction aléatoire associée audit compteur. On peut ainsi couvrir toutes les situations 30 que l'on peut rencontrer dans le programme temps réel. Toutefois cela suppose la réalisation de tests pendant une durée suffisamment longue pour obtenir une couverture suffisante. Selon un mode de réalisation préféré, on pourra affiner ce procédé en définissant une probabilité d'occurrence dudit événement déclenchant la tâche de façon plus privilégiée à certains moments, et ce par référence à un modèle 35 physique et/ou une simulation du système. Enfin dans le cas o la tâche est périodique dans le programme temps réel, l'appel à la fonction sera lui aussi périodique, mais cette fois par référence audit compteur définissant l'échelle de temps du programme non temps réel. Dans la transformation telle que décrite, une erreur existant au sein d'une des 5 tâches du programme temps réel sera transformée en une erreur au sein d'une des fonctions du programme non temps réel. En conséquence, la détection d'erreur au sein des tâches du programme temps réel revient à la détection d'erreur au sein des fonctions du programme non temps réel et sera possible au moyen d'un outil d'analyse statique classique. Ce qui vient d'être décrit correspond à la première étape du procédé de corrections d'erreur suivant l'invention correspondant à la conversion du programme temps réel en un programme non temps réel. L'étape suivante est celle o l'on exécute de façon traditionnelle le programme non temps réel ainsi obtenu à l'aide d'un l'outil d'analyse statique de 15 façon à utiliser les possibilités de détection d'erreurs que celui comporte intrinsèquement. La façon dont se déroule cette étape dépendra de l'outil lui-même et ne fait pas l'objet de la présente invention dans la mesure o un tel outil est connu et ne fait pas l'objet d'une utilisation spécifique. Dans le cas o l'on détecte une erreur au moyen de cet outil, il est possible 20 d'analyser et corriger cette erreur alors que le programme est interrompu dans son exécution et de l'exécuter pas à pas sans contrainte de temps. La correction est donc possible immédiatement et ce sans limitation sur le temps qu'elle pourra prendre. Ensuite il est possible de reprendre le déroulement normal du programme non temps réel, et ceci en respectant le séquencement normal du programme non 25 temps réel, qui respecte le séquencement de l'activation des tâches tel que défini au sein du programme temps réel. Le procédé d'analyse, de détection et de correction d'erreur peut donc reprendre pour la suite du programme non temps réel aussi longtemps que jugé nécessaire. Enfin les corrections d'erreurs réalisées dans le programme non temps réel grâce aux étapes précédentes, sont répercutées très simplement sur le programme temps réel puisqu'il y a correspondance simple et directe entre les tâches du programme temps réel et les fonctions du programme non temps réel. De préférence le même code source sera utilisé pour la définition des tâches et pour celle des 35 fonctions de façon à ce que ce même code source soit dans un cas exécuté en temps réel et dans l'autre cas sans contrainte de temps réel. Par exemple, l'événement " Point Mort Haut " déclenchera un ensemble d'opérations et de traitements spécifiques de cet événement, cet ensemble sera transcrit dans un code source donné puis utilisé aussi bien dans la version temps réel et que dans la version non temps réel. L'intérêt du procédé suivant l'invention est illustré au moyen des chronogrammes d'exemple de la figure 3. Le chronogramme ChrA de la figure 3 représente le déroulement normal du programme temps réel en fonction du temps t. Une première tâche (dont les 10 occurrences sont notées T1.1, T1.2, T1.3, T1.4, ... ) y est activée de façon périodique, toutes les 10 unités de temps. Une deuxième tâche (dont les occurrences sont notées T2.1, T2.2, ...) est activée à l'occurrence d'un événement E. Le chronogramme ChrB de la figure 3 représente le déroulement du programme temps réel en fonction du temps t, lorsque celuici est exécuté à l'aide de 15 l'outil d'analyse et qu'une erreur a été détecté au sein de la tâche T2.1. La phase d'analyse et de correction A dure un temps donné pendant lequel aucune autre tâche ne peut s'exécuter. Celles-ci sont en quelque sorte perdues pour le programme. Lorsque la phase d'analyse se termine, le programme reprend sans tenir compte des tâches (T1.2 et T1.3) qui auraient dû s'exécuter pendant le temps de correction A. 20 Ainsi dans l'exemple du chronogramme ChrB de la figure 3, lorsque l'événement E déclenchant la tâche T2.2 survient, celleci est à nouveau activée par le système d'exploitation. En conséquence, il n'est pas possible de savoir quel est l'impact de la correction sur la tâche T1.2 ou sur la tâche T1.3 qui aurait dû survenir (voir figure 3, chronogramme ChrA) entre la tâche T2.1 et T2.2. Enfin le chronogramme ChrC de la figure 5 représente le déroulement du programme non temps réel, tel qu'obtenu par le procédé selon l'invention, lorsque celui-ci est exécuté avec l'outil d'analyse. Dans ce cas ce ne sont pas des tâches mais des fonctions qui sont activées. Ainsi la première fonction (dont les occurrences sont notées F1.1, F1.2, F1.3, ...) correspond à la première tâche périodique. La 30 deuxième fonction (dont les occurrences sont notées F2.1, F2.2, ...) correspond à la deuxième tâche déclenchée sur événement E. Les graduations représentent l'évolution du compteur C. Toutefois pour des raisons de facilité de comparaison avec les chronogrammes précédents, on a conservé à l'axe gradué des dimensions qui correspondent au défilement réel du temps. On constate que l'interruption du 35 programme pendant la phase d'analyse A qui permet la correction de l'erreur au sein de la fonction non périodique F2.1, correspondant à la tâche non périodique T2.1, implique une interruption du déroulement temporel du programme. En conséquence au sortir de cette fonction F2.1, la fonction périodique F1.2, correspondant à la tâche périodique T1.2 et devant être exécuté parce que le compteur donne un temps 5 multiple de 10, est effectivement exécutée. L'analyse de cette fonction est donc possible consécutivement à celle de F2.1. Il en va de même pour l'analyse de la fonction F1.3 correspondant à la tâche périodique T1.3. Les lignes verticales et obliques en pointillé de la figure 3 indiquent de quelle manière se fait la correspondance temporelle ainsi réalisée avec l'exécution du programme temps réel 10 représentée par le chronogramme ChrA. Il est important de noter que le procédé suivant l'invention s'applique spécifiquement dans le cas d'un système d'exploitation non préemptif, c'est-à-dire dans lequel une tâche termine son exécution sans être interrompue et avant qu'une autre soit activée, même si une tâche de priorité plus élevée est prête à être 15 exécutée. Il ne permet pas de prendre en compte les interruptions de tâches telles qu'elles surviennent dans un système préemptif. D'autre part, dans le programme non temps réel tel qu'obtenu par le procédé, le temps d'exécution d'une tâche n'est pas pris en compte, pas plus qu'on ne cherche à étudier le glissement des tâches l'une par rapport à l'autre ou encore leur 20 comportement temporel. Dans bien des cas l'approximation faite est suffisante, notamment dès lors que le temps d'exécution d'une tâche est négligeable vis-à-vis du temps de latence entre la capture d'une information déclenchant un événement et l'exécution de la tâche qui en résulte. L'important est de pouvoir par ce procédé détecter des erreurs - typiquement des bogues du logiciel applicatif pouvant 25 survenir lors de l'exécution d'une tâche. En outre, on ne souhaite pas étudier les tâches de bas niveau qui interfèrent avec le matériel. D'abord parce qu'elles peuvent contenir des portions écrites en assembleur, et non en langage évolué comme la partie applicative du logiciel; ensuite parce que dans l'analyse, on ne dispose pas forcément de modèle pour le 30 matériel pouvant interagir avec le programme. Dans ce cas les entrées/sorties du programme peuvent être soit simulées, soit correspondre à des enregistrements temporels réels, notamment dans le cas o on recherche une erreur que l'on a détectée avec le programme temps réel et pour laquelle on a enregistré la séquence conduisant au bogue. Enfin, les dépendances implicites entre les entrées du système à tester peuvent n'être qu'imparfaitement voire pas du tout modélisées. Ce n'est pas forcément un obstacle à l'utilisation du procédé selon l'invention. En effet s'il est possible de s'affranchir des erreurs dans le cas o les données peuvent varier 5 indépendamment les unes des autres, alors il n'y aura pas d'erreurs dans le cas réel o lesdites données sont dépendantes. Dans ce cas l'outil d'analyse peut détecter des erreurs qui ne peuvent jamais survenir dans la pratique pour des raisons physiques. Le procédé d'analyse permet de tester un système qui présente des situations couvrant donc au moins toutes les occurrences possibles du système réel 10 à tester. Il est entendu que le procédé selon l'invention ne se limite pas aux exemples donnés ci-dessus et que ceux-ci ne sont donnés qu'à titre d'illustration. La présente invention permet donc de réaliser une correction d'erreurs sur un programme temps réel en respectant le séquencement des tâches qu'il comporte. Il 15 peut être utilisé pour la correction d'erreurs éventuelles de programmes temps réels, notamment ceux destinés à être embarqués dans un véhicule automobile. Bien entendu, l'invention n'est pas limitée au mode de réalisation ou à l'utilisation décrite ci-dessus dans le domaine de la construction automobile. Elle peut trouver application dans de nombreux domaines de l'industrie o interviennent des 20 programmes destinés à être embarqués et exécutés en environnement temps réel non préemptif, comme ce peut être le cas de processus de contrôle ou de fabrication, assistés ou commandés par ordinateur. REVENDICATIONS 1. Procédé de correction d'erreur d'un programme (PTR) temps réel, comportant un nombre donné de tâches (Tl, T2) et propre à être exécuté par un système (SE) d'exploitation temps réel non préemptif caractérisé en ce que: a) on convertit ledit programme temps réel (PTR) en un programme (PNTR) dit non temps réel, propre à s'exécuter sans contraintes de temps réel et qui simule l'ordre d'exécution des tâches (Tl, T2) du programme temps réel, b) on exécute le programme non temps réel (PNTR) ainsi obtenu au moyen d'un outil de détection d'erreurs, c) lorsqu'une erreur est détectée, on corrige cette erreur, d) on poursuit l'exécution du programme non temps réel (PNTR), e) on répète les étapes c) et d) autant de fois que nécessaire, f) on répercute dans le programme temps réel (PTR) les corrections d'erreur effectuées. 2. Procédé selon la revendication 1 caractérisé en ce que l'étape a) de conversion du programme (PTR) temps réel en un programme (PNTR) non temps réel, comprend elle-même les étapes suivantes: ai) on crée un programme principal (PP) s'exécutant en boucle et comprenant un compteur (C) définissant une échelle des temps pour l'exécution du programme non temps réel (PNTR), a2) pour chaque tâche (Tl, T2) du programme temps réel (PTR), on crée une fonction (F1, F2) du programme non temps réel (PNTR) 25 correspondant à ladite tâche, a3) pour chaque activation d'une tâche dudit programme temps réel (PTR), on crée dans pour le programme non temps réel (PNTR) au moins un appel via ledit programme principal (PP) à ladite fonction correspondant à ladite tâche, le mode d'appel à la fonction étant fonction du mode d'activation de la tâche dans le programme temps réel (PTR). 3. Procédé selon la revendication 2 caractérisé en ce que dans le cas o l'activation de ladite tâche est déclenchée par un événement (E) dans le programme 5 temps réel, le moment de l'appel à la fonction correspondante dans le programme non temps réel est définit par une fonction aléatoire associée audit compteur (C). 4. Procédé selon la revendication 3 caractérisé en ce que ladite fonction aléatoire est définie par référence à un modèle physique donnant une probabilité d'occurrence dudit événement (E). 5. Procédé selon une quelconque des revendications 2 à 4 caractérisé en ce que dans le cas o l'activation de ladite tâche est périodique dans le programme temps réel, l'appel à la fonction correspondante dans ledit programme non temps réel (PNTR) est périodique par référence audit compteur (C). 6. Utilisation du procédé selon une quelconque des revendications précédentes à 15 la correction d'erreurs éventuelles contenues dans un programme destiné à être embarqué dans un équipement temps réel.