Brevet FR2960664A1 — publié le 20111202

L'invention concerne un procédé et un dispositif de simulation d'un logiciel à exécuter dans un système. Il est fréquent que les logiciels exécutés dans un système (et qui mettent ainsi en oeuvre un procédé de commande du système) fassent intervenir un compteur dans le but de lancer (c'est-à-dire de commander) la mise en oeuvre d'une action à l'expiration du compteur. On cherche par ailleurs, en particulier dans le domaine aéronautique, à tester les différents systèmes utilisés dans une même installation (tel qu'un avion) et leurs interactions, avant leur mise en oeuvre réelle dans l'installation, au moyen notamment de systèmes de simulation du comportement réel de l'installation. On comprend que l'on a alors intérêt à utiliser lors de la simulation des systèmes, et des logiciels équipant ces systèmes, aussi proches que possible que ceux qui sont mis en oeuvre dans l'installation lors du fonctionnement normal. Ceci implique toutefois, pour les systèmes où des compteurs sont utilisés comme déjà mentionné, d'attendre l'expiration du compteur pour pouvoir vérifier complètement le fonctionnement du système concerné, ce qui peut se révéler très long dans certains cas, comme celui des pannes de classe 4 dont certains effets peuvent être masqués pendant plus de 1000 heures (jusqu'à près de 12 000 heures en pratique pour certains types de panne), et qui prolonge donc de manière conséquente la durée des campagnes de test. Dans ce contexte, l'invention propose un procédé de simulation d'un logiciel apte à être exécuté dans un système et à commander au moins une action à l'expiration d'un compteur du système, caractérisé par la mise en oeuvre d'étapes du fait de l'exécution d'instructions du logiciel, ainsi que par la mise en oeuvre d'une étape distincte des étapes mises en oeuvre du fait de l'exécution du logiciel et résultant en une exécution anticipée de ladite action. On peut ainsi raccourci le temps de simulation en conservant toutefois des parties communes au fonctionnement réel et à la simulation. Selon un premier mode de réalisation envisagé, ladite étape distincte peut comprendre l'écriture forcée dans le compteur d'une valeur provoquant son expiration anticipée. Il s'agit d'une manière pratique de provoquer l'exécution anticipé de l'action, qui permet en outre de vérifier le mécanisme de déclenchement de l'action à l'expiration du compteur lorsque la valeur d'expiration est atteinte. On peut prévoir qu'une étape mise en oeuvre du fait de l'exécution d'instructions du logiciel prévoie une réinitialisation du compteur à une valeur correspondant à un temps supérieur à 100 heures et que la valeur provoquant l'expiration anticipée corresponde alors à un temps inférieur à une heure. L'invention est particulièrement intéressante dans ce type de contexte, mais n'y est pas limitée. Ladite action comprend par exemple l'affichage d'une information sur un écran du système, comme dans l'exemple présenté plus loin. Selon un second mode de réalisation envisagé, éventuellement en combinaison avec le premier comme décrit ci-après, ladite étape distincte comprend la mise en oeuvre anticipée de ladite action. Il s'agit d'une technique particulièrement efficace pour obtenir une exécution très rapide, voire immédiate, de l'action concernée. Cette action comprend par exemple l'émission d'une information d'expiration à destination d'un module du système, tel qu'un module de maintenance. L'invention propose également un dispositif de simulation d'un logiciel apte à être exécuté dans un système et à commander au moins une action à l'expiration d'un compteur du système, caractérisé par des moyens aptes à mettre en oeuvre des étapes par l'exécution d'instructions du logiciel, et des moyens aptes à mettre en oeuvre une étape distincte des étapes mises en oeuvre du fait de l'exécution du logiciel et résultant en une exécution anticipée de ladite action. Ce dispositif peut éventuellement présenter les caractéristiques optionnelles mentionnées ci-dessus en termes de procédé. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description qui suit, faite en référence aux dessins annexés dans lesquels : - les figures 1 à 3 illustrent le fonctionnement envisagé pour trois calculateurs dont l'un commande une action à l'expiration d'au moins un compteur ; - les figures 4 à 7 illustrent un exemple de réalisation d'un procédé de simulation conforme aux enseignements de l'invention et appliqué à la simulation du système des figures 1 à 3. On a représenté en figure 1 les trois modules suivants d'un avion : - un calculateur ATAXX susceptible d'émettre lors de son fonctionnement des informations de panne P, notamment des pannes de classe 4 qui seront traitées comme décrit dans la suite ; - un calculateur de maintenance CMS qui reçoit l'information de panne P émise par le calculateur ATAXX ; - un calculateur de pannes qui reçoit également l'information de panne P émise par le calculateur ATAXX. On dénomme ici de manière identique, par souci de simplification, les informations de panne destinées respectivement au calculateur de maintenance et au calculateur de pannes. Il pourrait naturellement s'agir en pratique d'informations distinctes (qui représentent toutefois un même état du calculateur ATAXX). Chaque calculateur est par exemple mis en oeuvre au moyen d'un processeur qui exécute des instructions d'un logiciel embarqué sur le calculateur concerné afin que le calculateur mette en oeuvre les fonctionnalités qui lui sont dédiées. Chaque calculateur dispose également de mémoire afin de stocker les différentes informations nécessaires à son fonctionnement et comprend des moyens d'échange (tels que des moyens de connexion à un réseau local) afin d'échanger des informations avec les autres calculateurs. Le calculateur de pannes FWS comprend ainsi notamment un processeur destiné à exécuter un logiciel L mémorisé dans le calculateur de pannes FWS. Le calculateur de pannes FWS comprend par ailleurs deux compteurs CI, C2, réalisés par exemple de manière logicielle et utilisés comme décrit à présent. Lorsque le calculateur de pannes FWS reçoit une information de panne P indicative d'une panne de classe 4 associée aux compteurs précités, il réinitialise le premier compteur CI à une première valeur prédéterminée N représentative d'un temps compris entre 200 et 11700 heures pour les pannes de classe 4. A ce même moment (c'est-à-dire à réception de l'information P indicative d'une panne de classe 4), le second compteur C2 est initialisé à une seconde valeur prédéterminée t (par exemple représentative d'une durée de l'ordre d'une heure). Les deux compteurs CI, C2 sont périodiquement décrémentés, ici toutes les 60 ms tant que le calculateur de pannes FWS continue à recevoir l'information de panne P. Lorsque le second compteur C2 arrive à expiration (c'est-à-dire dans l'exemple montré à la figure 2 lorsque le second compteur C2 a une valeur nulle), le calculateur de pannes FWS envoie au calculateur de maintenance CMS la valeur instantanée du premier compteur CI, comme représenté en figure 2. Le module de maintenance (associé au calculateur de maintenance CMS) peut ainsi signaler aux opérateurs chargés de la maintenance d'une part que la panne P de classe 4 est survenue (à l'instant représenté en figure 1) et d'autre part indiquer le temps restant (représenté par la valeur du premier compteur CI) avant affichage de la panne P sur l'écran du pilote comme expliqué ci-après. Lorsque le second compteur C2 a expiré et déclenché le mécanisme qui vient d'être décrit en référence à la figure 2, il est remis à la seconde valeur prédéterminée t et permet ainsi l'émission périodique de la valeur du premier compteur CI du calculateur de pannes FWS au calculateur de maintenance CMS. Lorsque le premier compteur CI arrive à expiration (c'est-à-dire à la valeur nulle dans l'exemple représenté en figure 3), une interruption est générée et un branchement à un endroit prédéterminé du logiciel L permet à celui-ci de déclencher l'affichage sur un écran (par exemple destiné au pilote de l'avion) d'une information désignant la panne P, comme représenté en figure 3. On comprend que le rôle du premier compteur CI est ainsi de retarder (comme indiqué ci-dessus, d'une durée supérieure à 100 heures, voire à 1000 heures) la signalisation de la panne P au pilote par rapport au moment où le calculateur ATAXX a émis cette panne. Les pannes pour lesquelles ce fonctionnement est utilisé sont naturellement des pannes sans conséquence sur la sécurité de l'appareil, et qui sont normalement résolues par la maintenance avant apparition de la signalisation sur l'écran du pilote (les opérateurs de maintenance étant comme vu ci-dessus informés de la panne à la première maintenance subséquente à l'émission de la panne P par le calculateur ATAXX). On a représenté aux figures 4 à 7 un exemple de procédé de simulation de ces différentes fonctionnalités telles que proposées par 20 l'invention. Les calculateurs ATAXX et de maintenance CMS sont par exemple identiques à ceux décrits précédemment en vue de leur simulation. Le calculateur de pannes FWS' est quant à lui un calculateur de simulation : il simulera le fonctionnement du calculateur de pannes FWS, vis-à- 25 vis notamment des calculateurs ATAXX et CMS. On prévoit ici (sans que cela ne soit limitatif) que le calculateur de simulation FWS' soit réalisé sur la base d'un processeur différent du calculateur de pannes FWS. Toutefois, la quasi-totalité du code source du logiciel L utilisé sur le calculateur de pannes FWS est reprise en tant que code source pour le 30 calculateur de simulation FWS'. Comme visible en figure 4, on y ajoute toutefois deux portions de code source L', L" dont les fonctionnalités respectives seront décrites ci-après. (Les compilations sont toutefois différentes dans le cas de calculateur de pannes FWS et du calculateur de simulation FWS' du fait des différents processeurs utilisés.) La portion de logiciel (ou fonction) L' permet de déclencher, soit de manière automatique, soit du fait d'une requête d'un utilisateur mettant en oeuvre la simulation (par exemple par action sur un écran interactif), l'émission par le calculateur de simulation FWS' à destination du calculateur de maintenance CMS de la valeur du premier compteur CI. Ceci permet de tester les conséquences de l'émission de cette information au niveau du calculateur de maintenance CMS sans avoir à attendre l'expiration du second compteur C2, comme dans le cas du fonctionnement normal représenté en figure 2. La seconde portion de logiciel L" permet, également de manière automatique ou sur commande d'un opérateur, d'écrire dans le premier compteur CI une valeur particulièrement faible n (c'est-à-dire de forcer le premier compteur CI à cette valeur n), représentant un temps typiquement inférieur à une heure, par exemple une minute ou moins (comme représenté en figure 6), de sorte que l'expiration du premier compteur CI (et ses conséquences dont l'affichage de la panne P sur l'écran du pilote comme représenté en figure 7) interviendra très peu de temps après la mise en oeuvre de cette fonction L" par l'opérateur de la simulation. On peut ainsi tester en très peu de temps le déclenchement et les conséquences associées à l'expiration du premier compteur CI. Les modes de réalisation qui précèdent ne sont que des exemples possibles de mise en oeuvre de l'invention, qui ne s'y limite pas.25 REVENDICATIONS1. Procédé de simulation d'un logiciel apte à être exécuté dans un système et à commander au moins une action à l'expiration d'un compteur (C2 ; CI) du système, caractérisé par : - la mise en oeuvre d'étapes du fait de l'exécution d'instructions du logiciel (L), - la mise en oeuvre d'une étape (L' ; L") distincte des étapes mises en oeuvre du fait de l'exécution du logiciel et résultant en une exécution anticipée de ladite action. 2. Procédé de simulation selon la revendication 1, caractérisé en ce que ladite étape distincte (L") comprend l'écriture forcée dans le compteur (CI) d'une valeur (n) provoquant son expiration anticipée. 3. Procédé de simulation selon la revendication 2, caractérisé en ce qu'une étape mise en oeuvre du fait de l'exécution d'instructions du logiciel prévoit une réinitialisation du compteur (CI) à une valeur (N) correspondant à un temps supérieur à 100 heures et en ce que la valeur (n) provoquant l'expiration anticipée correspond à un temps inférieur à une heure. 4. Procédé de simulation selon la revendication 2 ou 3, caractérisé en ce que ladite action comprend l'affichage d'une information sur un écran du système. 5. Procédé de simulation selon la revendication 1, caractérisé en ce que ladite étape distincte (L') comprend la mise en oeuvre anticipée de ladite action.25 6. Procédé de simulation selon la revendication 5, caractérisé en ce que ladite action comprend l'émission d'une information d'expiration (CI) à destination d'un module (CMS) dudit système. 7. Dispositif de simulation d'un logiciel apte à être exécuté dans un système et à commander au moins une action à l'expiration d'un compteur (C2 ; CI) du système, caractérisé par : - des moyens aptes à mettre en oeuvre des étapes par l'exécution d'instructions du logiciel (L) ; - des moyens aptes à mettre en oeuvre une étape (L' ; L") distincte des étapes mises en oeuvre du fait de l'exécution du logiciel et résultant en une exécution anticipée de ladite action. 8. Dispositif de simulation selon la revendication 7, caractérisé en ce que ladite étape distincte (L") comprend l'écriture forcée dans le compteur (CI) d'une valeur (n) provoquant son expiration anticipée. 9. Dispositif de simulation selon la revendication 8, caractérisé en ce que ladite action comprend l'affichage d'une information sur un écran du 20 système. 10. Dispositif de simulation selon la revendication 7, caractérisé en ce que ladite étape distincte (L') comprend la mise en oeuvre anticipée de ladite action et en ce que ladite action comprend l'émission d'une information 25 d'expiration (CI) à destination d'un module (CMS) dudit système.