FR 2906381 A1 20080328 FR 0608331 A 20060922 1 Procédé d'observation d'un calculateur temps réel La présente invention concerne un procédé d'observation d'un calculateur temps réel et notamment d'observation des traitements réalisés par un calculateur temps réel embarqué. A bord des aéronefs ou des navires de nombreuses fonctions automatisées sont assurées par des calculateurs embarqués. Ces calculateurs peuvent assurer différentes fonctions de gestion comme le suivi d'un plan de vol pour un aéronef ou d'une route maritime pour un navire, ou bien encore la gestion des différents paramètres de vol ou de navigation. Un calculateur temps réel embarqué se présente généralement sous la forme d'un boîtier comportant plusieurs modules. Chaque module peut comporter un processeur et possède une fonction propre dans le calculateur. Les calculateurs embarqués sont réalisés de manière à occuper le moins de place possible, les modules sont donc très compacts. La mise au point de ces calculateurs requiert des moyens de tests très poussés afin de détecter toute anomalie avant la mise en service et afin d'optimiser les traitements temps réels des applications s'exécutant sur les calculateurs. :20 Parmi les méthodes couramment utilisées, on connaît les moyens logiciels comme des débogueurs qui nécessitent une instrumentation complète du code source. Le code source comporte les instructions originales d'un programme, écrites dans un langage lisible par l'homme et devant être compilées, c'est à dire traduites en langage machine, afin d'être 25 exécutées par un ordinateur. Le langage machine est un langage informatique en code binaire directement compréhensible par un ordinateur. L'instrumentation d'un code source consiste à marquer les données de manière à suivre leur évolution lors du déroulement des différentes instructions. L'instrumentation complète du code source est très lourde et 30 conduit à l'impossibilité de l'exécution en temps réel des applications sur le calculateur et donc à une désynchronisation des applications entre elles. Le fonctionnement du calculateur se trouve alors dégradé et il est impossible de 2906381 2 donner un caractère déterministe aux tests mis en oeuvre. Il est dans ce cas impossible d'effectuer une quelconque mise au point du calculateur. Une autre méthode est l'utilisation de traces logicielles pour suivre le déroulement des instructions des différentes applications. Les traces 5 logicielles sont des informations textuelles permettant, en cours d'exécution d'une application, de visualiser la succession des instructions exécutées par le processeur. Cette méthode nécessite l'ajout de nombreuses lignes de code dans le code source. De plus l'écriture des traces, dans un fichier ou à l'écran pendant l'exécution des applications, consomme beaucoup du temps 10 de calcul du processeur. Ceci a donc pour effet une dégradation du fonctionnement temps réel du calculateur et donc une impossibilité d'effectuer les tests et la mise au point. Une autre méthode utilise une sonde branchée sur le processeur qui permet d'enregistrer les signaux électriques qui transitent sur un bus 15 d'adresses et sur un bus de données, reliés au processeur. Ces signaux sont ensuite traduits en langage assembleur. Le langage assembleur est un langage de programmation informatique qui représente le langage machine, sous une forme textuelle compréhensible par l'être humain. On peut ainsi suivre pas à pas toutes les instructions exécutées par le processeur. Les instructions présentées sous cette forme sont cependant difficiles à interpréter. Ceci est d'autant plus vrai lorsque plusieurs instructions sont exécutées en parallèle sur un processeur. De plus lorsque l'on dispose de plusieurs processeurs, il est nécessaire d'implanter une sonde sur chaque processeur. Il devient alors impossible d'analyser l'ensemble des instructions :25 exécutées par les différents processeurs. Ce moyen d'observation en plus d'être lourd à mettre en place, car il nécessite le démontage du boîtier, se révèle particulièrement inadapté au suivi des instructions exécutées par le calculateur. D'autres moyens d'observations du fonctionnement d'un 3o calculateur consistent à utiliser des bus usuellement mis en oeuvre à des fins de test de production électronique. Ces bus permettent uniquement de tester le fonctionnement matériel des modules et l'interconnexion de ces derniers. Ils ne permettent donc pas d'exécuter les applications en temps réel et encore moins de suivre les instructions exécutées par le processeur pas à :35 pas. 2906381 3 D'autres bus utilisés à des fins de communication et de transfert de fichiers de données nécessitent l'implantation de nombreuses couches logicielles afin d'assurer le protocole de communication, ce qui ralentit considérablement le fonctionnement du processeur. L'utilisation de ces bus 5 ne permet donc pas d'exécuter les applications en temps réel, ces types de bus ne peuvent pas non plus être employés à des fins de test et de mise au point d'un calculateur temps réel. 10 Un objectif de l'invention est notamment de pallier les inconvénients précités. A cet effet, l'invention a pour objet un procédé d'observation d'un calculateur ternps réel. Le calculateur temps réel comporte un processeur, un bus processeur sur lequel est connecté un circuit logique programmable de gestion d'un bus de sortie. 15 Le procédé selon l'invention comporte au moins les étapes suivantes : ^ une première étape transmission de données marquées, au cours de l'exécution d'applications par le processeur, vers le circuit logique programmable via le bus processeur en une instruction indivisible du processeur, 20 ^ une deuxième étape d'enrichissement de chaque donnée marquée avec une date et une identification de l'application émettrice par le circuit logique programmable, ^ une troisième étape de transmission de chaque donnée enrichie sur le bus de sortie. Le procédé selon l'invention peut comporter : ^ une étape d'instrumentation de code source des applications s'exécutant sur le calculateur, réalisant un marquage de données du code source, ^ une étape de génération d'exécutables instrumentés comportant les 30 données marquées traduites en langage machine à partir des codes source instrumentés pour chaque application. Le procédé peut comporter une étape d'acquisition et d'analyse des données collectées sur le bus de sortie par un outil d'acquisition et d'analyse. 2906381 4 Le calculateur peut être composé de plusieurs modules comportant chacun un processeur, un bus processeur, un circuit logique programmable connecté à un bus de sortie. Le procédé peut comporter une étape de synchronisation de l'outil 5 d'acquisition et d'analyse avec les différents modules du calculateur. L'outil d'acquisition et d'analyse peut effectuer une corrélation entre chaque donnée reçue du bus de sortie du calculateur et le code source. L'outil d'acquisition et d'analyse peut restituer les données reçues du bus de sortie du calculateur en temps réel. ~o L'outil d'acquisition et d'analyse peut archiver les données reçues du bus de sortie. L'outil d'acquisition et d'analyse peut : • calculer la charge du ou des processeurs, • cartographier le cheminement d'évènements dans les différentes 15 applications, • cartographier l'utilisation du calculateur par les différentes applications, • tracer le cadencement temporel du ou des processeurs. 20 Le procédé selon l'invention a notamment pour avantage de conserver un fonctionnement temps réel du calculateur tout en prélevant sur chaque processeur du calculateur les informations relatives au traitement 25 des différentes instructions. D'autres caractéristiques et avantages de l'invention apparaîtront à l'aide de la description qui suit faite en regard des dessins annexés qui 30 représentent • la figure 1 : une représentation schématique d'un dispositif mettant en oeuvre l'invention; • la figure 2 : une représentation détaillée du dispositif précédent; • la figure 3 : un synoptique d'une première partie du procédé 35 d'observation temps réel selon l'invention ; 2906381 5 • la figure 4 : un synoptique d'une deuxième partie du procédé d'observation temps réel selon l'invention ; • la figure 5 : un exemple de mise en oeuvre du procédé selon l'invention pour l'observation d'un boîtier comportant plusieurs 5 modules ; • la figure 6 : un exemple des informations obtenues grâce au procédé selon l'invention. 10 La figure 1 représente un dispositif de test et de mise au point d'un calculateur embarqué 1. Ce calculateur embarqué 1 se présente sous la forme d'un boîtier comportant plusieurs modules de traitement 2. Ces modules de traitements 2 sont chargés d'assurer une fonction déterminée au 15 sein du calculateur 1. Certains modules 2 peuvent par exemple assurer la gestion de la mémoire du calculateur 1, d'autres peuvent être dédiés à des calculs. Les modules 2 sont connectés à un boîtier d'acquisition 3 chargé de recueillir et de centraliser des données collectées sur chacun des modules 2. Le boîtier d'acquisition 3 est connecté à un ordinateur 4 utilisé comme station 20 d'observation et d'analyse des données recueillies sur chacun des modules 2. Chaque module 2 est pourvu d'une connexion 5 suffisamment compacte et accessible pour permettre de connecter le boîtier d'acquisition sans démonter les modules 2 du boîtier du calculateur 1. Ceci permet donc d'avoir un moyen d'acquisition de données résidant dans le calculateur 1. Ce moyen 25 d'acquisition peut être lui aussi embarqué simplement à bord d'un aéronef par exemple. Ce dispositif permet également de collecter les données relatives au fonctionnement du calculateur 1 quelles que soient les conditions d'utilisation comme, par exemple, en laboratoire pour la mise au point ou sur le terrain pour des essais. :30 La figure 2 représente une vue détaillée du dispositif présenté de manière générale sur la figure 1. Le calculateur 1 comporte par exemple deux modules 2 reliés entre eux par une liaison interne 31 qui leur permet d'échanger des données. Chaque module comporte une carte 21 sur laquelle 35 est connecté un processeur chargé d'assurer la fonction propre de chaque module 2. Cette carte 21 est aussi appelée carte processeur et par 2906381 6 simplification assimilée au processeur lui-même. Chaque module 2 comporte également un connecteur 5 spécifique à l'instrumentation mise en oeuvre afin de collecter des données pour l'observation des processeurs 21. La collecte des informations sur chaque processeur 21 est effectuée au moyen d'un 5 circuit logique programmable 22 connecté sur un bus processeur 23. Les données sortant ou entrant dans le processeur 21 sont collectées sur le bus processeurs 23, puis gérées par le circuit logique programmable 22 qui les dirige ensuite vers un bus de sortie 24 aussi appelé bus d'observation. Ce bus d'observation 24 permet de fournir en sortie du module 22 via le 10 connecteur 5 toutes les informations relatives aux traitements effectués par le processeur 21. Ces informations transitent ensuite sous forme de données, par l'intermédiaire d'une liaison 25, du connecteur 5 vers le boîtier d'acquisition 3. Le boîtier d'acquisition 3 comporte plusieurs cartes d'acquisition 26 chacune d'elles étant reliée à un module 2 du calculateur 1. 15 Ces cartes d'acquisition 26 sont chargées de recueillir les données issues du bus d'observation 24 puis de les diffuser sur un bus 27 interne au boîtier d'acquisition 3. Les données circulant sur le bus interne 27 sont ensuite récupérées par une carte de traitement 28 qui assure leur stockage dans une base de données 29 interne au boîtier d'acquisition 3. La carte de traitement 20 28 assure également la mise en forme et l'analyse des données collectées. Les données, une fois traitées, transitent par l'intermédiaire du bus interne 27 via une carte 30 de gestion du bus interne 27. Cette carte de gestion du bus interne 30 assure notamment l'envoi des données traitées sur une liaison externe 20 vers la station de visualisation 4. Cette liaison externe 20 peut 25 être par exemple une liaison numérique haut débit. Les données ainsi collectées par le dispositif peuvent donc soit, être visualisées en temps réel sur la station de visualisation 4, soit conservées en mémoire afin d'effectuer des traitements d'analyse et d'exploitation de ces données. La figure 3 illustre une première partie du procédé selon l'invention mis en oeuvre afin de recueillir les différentes données concernant les traitements effectués par un processeur 21 d'un module 2. Plusieurs applications 40 s'exécutent sur le processeur 21 et constituent un ensemble de couches d'applications ayant chacune une fonction propre et coopérant entre elles au sein du processeur 21. Chaque application 40 est générée à 2906381 7 partir de fichiers source 41 contenant du code source informatique relatif à l'application. Des paramètres de génération de marqueurs 42 permettent de définir des marqueurs relatifs aux données de chaque application que l'on souhaite tracer. On peut souhaiter par exemple suivre l'évolution d'une 5 donnée au cours d'un traitement particulier ou bien suivre le traitement d'un événement à travers les différentes couches d'applications. Ces marqueurs sont intégrés au code source dans une étape de génération 43 de l'instrumentation du code source. Cette génération permet donc d'obtenir des fichiers source instrumentés 44 c'est à dire comportant un marquage 10 particulier de certaines données intéressantes afin de pouvoir les tracer. Des paramètres d'exploitations 46 permettent ensuite de transcrire chaque information de marquage contenue dans le code source en une instruction à l'intention du processeur 21. Cette transcription est effectuée lors de la génération 45 des exécutables instrumentés, faite à partir des fichiers source 15 instrumentés 44. La génération 45 des exécutables instrumentés permet de transcrire l'ensemble des instructions codées dans les fichiers source instrumentés 44 en instructions en langage machine qui peuvent alors être exécutées par le processeur. La génération 45 des exécutables instrumentés permet également de fournir une table de correspondance entre un 20 marqueur particulier et l'application qui le contient. Cette correspondance se traduit par une table de paramètres de correspondance 47. Au cours de l'exécution logicielle des différentes applications, les instructions liées aux marqueurs et contenues dans les exécutables instrumentés sont exécutées par les processeurs. Ces instructions 25 permettent d'envoyer chaque donnée marquée sur le bus d'observation 24. Chaque donnée marquée est ensuite récupérée par l'outil d'acquisition et d'analyse 3. L'outil d'acquisition et d'analyse 3 fait alors le lien entre la donnée reçue et le code source grâce aux différents paramètres : ^ les paramètres de correspondance 47 qui permettent d'identifier 30 l'application émettrice, ^ les paramètres d'exploitation 46 qui permettent de retrouver le marqueur ayant donné lieu à l'envoi de la donnée, et ^ les paramètres de génération 42 qui permettent de faire le lien entre le marqueur et la donnée marquée dans le code source. 35 Ceci permet d'interpréter et d'analyser les données reçues du processeur 21. 2906381 8 La figure 4 représente une étape du procédé selon l'invention pour la génération des données marquées sur le bus d'observation 24. Le processeur 21, lorsqu'il exécute les instructions des différentes applications, 5 émet les données marquées sur le bus processeur 23. Chaque donnée marquée est ensuite recueillie par le circuit logique programmable 22 sur une adresse particulière 50 du bus processeur 23. Cette adresse dépend de l'application émettrice de la donnée marquée. Cette particularité permet au circuit logique programmable 22 de corréler la donnée marquée reçue avec 10 son application d'origine. Le circuit logique programmable 22 constitue ensuite un message comportant par exemple quatre mots de seize bits chacun constituant au final la donnée émise sur le bus d'observation 24. Ce message comporte donc la donnée reçue du bus processeur, l'adresse de réception de la donnée, et une date. Cette date est issue d'une datation 15 effectuée par le circuit logique programmable 22 lors de la réception de la donnée sur le bus processeur. Le message peut être composé de la manière suivante : ^ un premier mot comportant l'adresse sur huit bits, puis comportant sur les huit bits restant une première partie de la date, 20 ^ un deuxième mot comportant une deuxième partie de la date, ^ un troisième et un quatrième mot comportant la donnée. A partir de ce message, envoyé par le circuit logique 22 programmable sur le bus d'observation 24, l'outil d'acquisition et d'analyse 3 peut reconstituer le contexte d'envoi de la donnée marquée. En effet, il possède une information 25 permettant d'identifier l'application émettrice et une datation qui lui permet de positionner la donnée temporellement dans le déroulement des instructions de l'application. Le procédé ainsi mis en oeuvre permet de collecter les informations utiles au plus près du processeur sans toutefois lui imposer une 30 surcharge de travail. En effet, l'envoi de la donnée marquée est judicieusement effectué en une instruction indivisible par le processeur. Ceci permet de ne pas perturber le fonctionnement temps réel du processeur tout en obtenant des informations précises sur les traitements effectués par le processeur. 35 2906381 9 La figure 5 présente un exemple de mise en oeuvre du procédé selon l'invention, pour un ensemble de modules 2. Le calculateur temps réel 1 peut comprendre par exemple dix-huit modules 2. Parmi ces dix-huit modules 2 on cherche par exemple à tracer les fonctions réalisées par le 5 module 51 ainsi que par le module 52. Sachant que les modules 51, 52 peuvent coopérer à la réalisation d'une même fonction, il s'avère important de synchroniser les évènements reçus de l'un et de l'autre des modules 51, 52 afin de pouvoir suivre un événement au cours de ses traitements par les modules 51, 52. Cette synchronisation est effectuée par le boîtier 10 d'acquisition et d'analyse 3 de la manière suivante : le boîtier d'acquisition et d'analyse 3 envoie simultanément vers chacun des modules 51, 52 une requête de synchronisation 53. Sur réception de cette requête 53, chaque module 51, 52 envoie alors la date courante 54 de son horloge interne. Le boîtier d'acquisition et d'analyse 3 peut ainsi déterminer un différentiel entre 15 les dates reçues des différents modules et la date courante de son horloge interne afin de corriger la datation des données reçues sur le bus d'observation 24. Un recadrage ternporel des données reçues est alors effectué en fonction du différentiel calculé afin de corréler les instructions relatives au traitement d'un événement par les différents modules 51, 52. 20 Ceci permet de pouvoir restituer les différentes instructions, sur la station d'observation 4, dans un ordre chronologique respecté. La figure 6 représente quelques exemples d'analyse des données reçues, effectuées par l'outil d'acquisition 3 couplé à la station d'observation 25 4. On peut par exemple dresser un chronogramme 61 des différents événements 62, relatifs à chaque couche applicative 40, et traités par le processeur 21. On peut ainsi cartographier le cheminement des traitements d'un événement dans les différentes couches applicatives 40. On peut également dresser une carte 63 de l'emploi des différents services du 30 processeur afin de déterminer le niveau d'occupation de chacun des services. II est également possible de déterminer le temps d'occupation du processeur par chaque application, grâce à un histogramme 64, exprimé en pourcentage de la charge de travail du processeur. II est également possible d'effectuer une courbe d'occupation 65 du processeur en représentant 35 l'évolution de sa charge de travail au cours du temps. Ceci permet de tracer 2906381 10 le cadencement temporel du processeur afin de vérifier le respect du traitement des différents événements en temps réel. On peut également cartographier l'emploi d'un service par les différentes applications au cours du temps sur un diagramme 66. Le procédé selon l'invention permet donc 5 avantageusement d'obtenir des données précises avec un spectre d'application suffisamment large pour permettre une utilisation souple et adaptable aux besoins spécifiques à chaque phase de la mise au point ou de test du calculateur 1. 10 Ce procédé peut être avantageusement utilisé pour tout type de carte processeur ayant une application temps réelle ou non, que le processeur soit embarqué ou non. En effet, la souplesse d'utilisation du système selon l'invention permet de l'appliquer à de multiples configurations 15 de calculateur, sachant qu'il est résidant sur le module et qu'il peut être connecté de manière classique à un boîtier d'acquisition de données. Un des principaux avantages du procédé selon l'invention est qu'il 20 permet de collecter des données relatives aux traitements réalisés par le processeur 1 sans perturber le fonctionnement temps réel de ce dernier. Ceci permet donc avantageusement d'effectuer des tests déterministes sur le processeur. C'est à dire qu'il est possible de répéter à l'identique une séquence d'événements un nombre de fois illimitées. Ce qui est 25 particulièrement utile afin de pouvoir reproduire des erreurs de fonctionnement, d'identifier des problèmes de traitement ayant conduit à ces erreurs et après correction, cela permet de valider les traitements, les erreurs ne devant plus apparaître lors de la réalisation d'une séquence d'instructions identique à celle ayant donnée lieux à une erreur avant correction. 30 Conserver un fonctionnement temps réel des applications tout en obtenant des informations précises sur les instructions exécutées par le processeur permet également de détecter les problèmes de charge de calcul du processeur en identifiant les applications, et plus précisément le code source donnant lieu à une charge de calcul trop importante. 2906381 11 Le procédé selon l'invention peut avantageusement se prêter à l'espionnage d'un calculateur multiprocesseur dont les processeurs fonctionnement en parallèle sur certaines tâches ou de manière synchrone. On peut ainsi cartographier les différents traitements liés à un événement 5 particulier sur chaque processeur. REVENDICATIONS 1. Procédé d'observation d'un calculateur temps réel (1) comportant un processeur (21), un bus processeur (23) sur lequel est connecté un circuit logique programmable (22) de gestion d'un bus de sortie 5 (24), caractérisé en ce qu'il comporte au moins : ^ une première étape transmission de données marquées, au cours de l'exécution d'applications (40) par le processeur (21), vers le circuit logique programmable (22) via le bus processeur (23) en une instruction indivisible du processeur (21), 10 ^ une deuxième étape d'enrichissement de chaque donnée marquée avec une date et une identification de l'application émettrice par le circuit logique programmable (22), ^ une troisième étape de transmission de chaque donnée enrichie sur le bus de sortie (24). 15 2. Procédé selon la revendication précédente, caractérisé en ce qu'il comporte : ^ une étape d'instrumentation (43) de code source (41) des applications (40) s'exécutant sur le calculateur, réalisant un marquage de données 20 du code source (41), ^ une étape (45) de génération d'exécutables instrumentés comportant les données marquées traduites en langage machine à partir des codes source instrumentés (44) pour chaque application (40). 25 3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape d'acquisition et d'analyse des données collectées sur le bus de sortie (24) par un outil d'acquisition et d'analyse (3). 30 4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le calculateur (1) est composé de plusieurs modules (2) comportant chacun un processeur (21), un bus processeur (23), un circuit logique programmable (22) connecté à un bus de sortie (24). 2906381 13 5. Procédé selon la revendication précédente, caractérisé en ce qu'il comporte une étape de synchronisation de l'outil d'acquisition et d'analyse (3) avec les différents modules (2) du calculateur (1). 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'outil d'acquisition et d'analyse (3) effectue une corrélation entre chaque donnée reçue du bus de sortie (24) du calculateur (1) et le code source (41). 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'outil d'acquisition et d'analyse (3) restitue les données reçues du bus de sortie (24) du calculateur (1) en temps réel. 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'outil d'acquisition et d'analyse (3) archive les données reçues du bus de sortie (24). 20 9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que l'outil d'acquisition et d'analyse (3) : • calcule la charge du ou des processeurs (21), • cartographie le cheminement d'évènements dans les différentes applications (40), 25 • cartographie l'utilisation du calculateur (1) par les différentes applications (40), • trace le cadencement temporel du ou des processeurs (21). 10 15