Brevet FR2687236A1 — publié le 19930813

Procédé de réalisation d'automates de gestion multitâches pour systèmes de traitement de données La présente invention concerne un procédé de réalisation d'automates de gestion multitâches pour systèmes de traitement de données. Elle s'applique notamment à la réalisation d'un générateur de messages inertiels intégré pour simulateur d'environnement GPS Navstar. I1 est connu d'utiliser dans les systèmes de traitement de données des programmes dédiés du système d'exploitation pour commander l'exécution des différentes tâches en cours de traitement par les processeurs du système. Cependant, dans certaines applications, comme celles concernant par exemple le repérage de la position de mobiles sur le géoïde terrestre qui mettent en oeuvre des systèmes de navigation par satellite, l'utilisation de programmes dédiés, pour l'acquisition des messages fournis par les satellites et la commande des différents transferts de données entre récepteurs et calculateurs de navigation, est relativement compliquée et très consommatrice en temps de traitement du fait de la multiplicité des programmes du système d'exploitation mis en oeuvre pour l'identification les messages et leur transfert dans le calculateur de navigation. D'autre part, l'utilisation d'un système d'exploitation pose le problème de la certification pour les applications militaires, notamment des divers programmes nécessaires au déroulement des applications qui du fait de l'imbrication des traitements est en pratique irréalisable. Le but de l'invention est de pallier les inconvénients précités en déchargeant complètement le système d'exploitation des calculateurs des tâches d'acquisition et de transfert de données. A cet effet, l'invention a pour objet un procédé de réalisation d'automates de gestion multitâches pour système de traitement de données comprenant au moins un calculateur de traitement de données connecté à au moins une unité de périphérique caractérisé en ce qu'il consiste à partager la gestion du calculateur et des périphériques en un nombre déterminé de tâches, à construire pour chaque tâche un automate qui lui est spécifique et à affecter à chaque tâche un temps d'exécution par un automate de tâche de fond chargé de distribuer de façon cyclique un temps de gestion à chacun des automates. L'invention a pour principal avantage qu'elle permet une meilleure optimisation du temps machine des calculateurs. En effet, comme le système d'exploitation de chaque calculateur n'est plus sollicité pour synchroniser les tâches les unes par rapport aux autres ou pour passer des messages d'une tâche à l'autre, le temps machine du calculateur peut être consacré uniquement aux calculs des algorithmes utiles nécessaires à la navigation et non plus aux échanges de contexte ou de gestion de tâches qui gaspillent de la puissance de calcul inutilement. La puissance de calcul apparente du calculateur s'en trouve augmentée du fait même du rééquilibrage de ses ressources et ce, d'une façon d'autant plus importante que les tâches indépendantes sont davantage morcelées et plus nombreuses. Cela permet de gagner selon les applications entre 5 et 20% de temps machine. Comme le procédé selon l'invention consiste à effectuer une répartition du temps machine à l'aide de macro fonctions, les macro fonctions qui sont définies à travers le processeur de macro commandes ne consomment pas de temps machine du fait qu'elles résument de façon plus claire que le code source écrit en langage natif, les procédures de changement de tâches. Comme les tâches sont décrites sous la forme de fragments de code appelés séquentiellement par un programme de distribution unique, celles-ci peuvent être aisément représentées par des automates dont chaque état correspond à un fragment de code distribué. A la différence de ce qui est réalisé par les langages de programmation usuels qui opèrent tacitement la décomposition des tâches sous la forme de fonctions seulement, le procédé selon l'invention apparaît plus approprié pour résoudre certaines classes de problèmes, comme par exemple, la gestion de menus de commandes déroulants ou incrustés ou bien encore dans un autre ordre d'idées, le tri en arbre d'un compilateur ou d'un interpréteur de commande car il permet indifféremment d'écrire des tâches sous la forme usuelle de fonctions et de procédures en les découpant en fragments ou bien sous la forme d'automates ou bien suivant une combinaison appropriée des deux. De la sorte, le changement de tâches devient implicite au sens qu'il s'effectue automatiquement à la fin de chaque état d'une tâche. Le processeur chargé de l'exécution d'une tâche peut ainsi de lui-même exécuter des cycles entre les états de toutes les tâches en les distribuant séquentiellement. Cela permet au moment de l'écriture du code spécifique à une tâche de contrôler le temps que le processeur peut passer à exécuter, chacun de ses états, en modulant la longueur des états de la tâche et en utilisant le procédé de réduction d'état mis en oeuvre par l'invention. Un autre avantage est que l'allocation du temps machine est dynamiquement reconfigurable au sens qu'il est possible de passer plus de temps dans un état critique d'une tâche déterminée et moins de temps dans d'autres états de la même tâche si ceci est nécessaire. Cette possibilité offerte par l'invention est particulièrement importante pour les programmes à forte connotation temps réel par exemple, où le temps affecté à chaque tâche est primordiale. Contrairement à ce qui est réalisé par les procédés classiques, cette possibilité qui, selon l'invention, est automatique et implicite, n'est pas offerte par tous les systèmes d'exploitation multitâches et lorsqu'elle est toutefois possible, celle-ci requiert des manipulations très difficiles consistant par exemple à redéfinir dynamiquement les paramètres de travail fondamentaux du système d'exploitation ce qui est conceptuellement très dangereux car elle ne tolère aucune erreur. Grâce à l'invention, il n'est plus nécessaire de sauvegarder le contexte du traitement lorsque le système passe de l'exécution d'une tâche à une autre et cette fonction fondamentale des systèmes d'exploitation multitâches connus est de ce fait supprimée, ce qui permet d'économiser du temps machine ainsi que, de l'espace mémoire qui étaient nécessaires pour effectuer ces sauvegardes. Cette caractéristique est liée au fait que selon l'invention, c'est le programmeur qui écrit le code en même temps qu'il définit lui-même les moments de changement de tâches de sorte que ce changement ne s'effectue plus de façon imprévisible comme pour le déroulement des tâches contrôlées par un système d'exploitation dont le séquencement est effectué par une horloge externe. D'autres caractéristiques et avantages de l'invention apparaîtront ci-après à l'aide de la description qui suit faite en regard des dessins annexés qui représentent - La figure 1 un diagramme d'état d'un automate dédié à la prise en compte de messages inertiels dans un simulateur de signal GPS. - La figure 2 un format de message inertiel. - La figure 3 un schéma pour illustrer un exemple d'empilage d'automates selon l'invention. - La figure 4 un circuit pour la mise en oeuvre d'un automate selon l'invention. Deux principes fondamentaux guident la mise en oeuvre du procédé selon l'invention. Le premier vise à utiliser une structure hôte générique pour l'ensemble des automates et le deuxième vise à utiliser des conventions d'écriture définissant un métalangage de programmation utilisable par tous les automates. Selon l'invention, la structure hôte des automates est constituée par un programme principal représentant le fond de tâche de chaque processeur et par une structure commune de programme applicable à chaque automate. Cette structure est définie en même temps que les conventions du métalangage. La structure de la tâche de fond du processeur est extrêmement simple, car elle ne fait que distribuer le temps machine à toutes les autres tâches. Cette structure a la forme suivante, dans le langage de programmation "C" connu pris à titre d'exemple main ( ) while (1) tâche 1 ( ); tâche 2 ( ) tâche 3 ( ) Dans ce qui précède" main" désigne le programme principal et "while (1)" une instruction conditionnelle qui impose l'exécution des tâches 1, 2 et 3 etc suivant une boucle sans fin. Cette structure permet de ne jamais sortir de la boucle de fond de tâche et laisse la responsabilité à chaque automate qui gère une ressource de commande de programme de sortir de la boucle lorsque cela lui est demandé. Elle permet principalement d'affecter le temps machine à chacune des tâches mais elle permet également d'effectuer d'autres fonctions comme par exemple des fonctions de statistiques de charges processeurs ou de tests de matériel. En affectant à la tâche de fond uniquement la fonction d'allocation du temps machine cela donne une structure totalement générique c'est-a-dire n'impose pas de particularité autre que l'affectation de temps machine à la tâche de fond, et laisse la possibilité d'inclure la responsabilité d'exécution d'autres fonctions à l'un des automates de la machine qui est dédié à cette fonction puisque par définition chaque automate n'est invoqué qu'une seule fois à chaque cycle de la tâche de fond. Dans cette structure, le nombre de tâches n'est pas limité, de sorte que le fait d'avoir un nombre de tâches important à exécuter n'est nullement pénalisant ni en taille mémoire ni en temps d'exécution comme cela a déjà été mentionné. La définition du métalangage et de la structure commune des automates est effectuée à un niveau global dans un fichier appelé ci-après "machine. C", à compiler en même temps que le programme principal et que chacun des automates, et structuré comme suit tdefine YES 1 tdefine NO O tdefine INIT O tdefine SUSPEND 1 #define WAKE 2 tdefine QUIT 100 tdefine MACHINE {static int statue, out=YES; #define BEGIN~MACHINE do {switch(state){ tdefine STATE case tdefine END~MACHINE tdefine END }while (out==NO); tdefine DEFAULT default L'écriture d'une tâche à l'aide de ce métalangage peut alors revêtir la forme suivante tinclude "machine. c" nom~de~la~tâche (...) déclaration des paramètres passés MACHINE déclaration des variables internes à la tâche et des paramètres passés à la tâche par exemple : passage d'un paramètre d'état externe comme état interne de la tâche out = NO ; si l'automate est bouclé (doit sortir par un des états) ; sortie par return, out=YES ou exit. BEGIN~MACHINE ; DOIT ABSOLUMENT être suivi de STATE xxx: STATE O: initialisation des variables internes break STATE xxx: traitement de l'état xxx break STATE yyy: traitement de l'état yyy break DEFAULT: break s'il y a lieu END~MACHINE traitement commun à tous les états ex: définition de l'état comme variable externe END Cela permet de considérer les tâches comme des entités fonctionnelles totalement indépendantes entre elles communiquant à l'aide seulement de variables globales. Par exemple, l'état de tous les automates peut être rendu disponible comme variable globale à tous les autres automates. Ce n'est naturellement pas une obligation mais cela permet, en manipulant par exemple l'état d'un automate à partir d'un autre automate, de synchroniser des tâches différentes ou d'allouer à l'aide d'un automate gestionnaire d'une ressource déterminée, par exemple un disque dur, ladite ressource vers plusieurs automates utilisateurs comme le ferait tout système d'exploitation multitâches appolé à remplir ces fonctions. Certains états réservés des automates sont définis dans le fichier "machine. C" défini précédemment de façon identique pour tous les automates. L'état "INIT" est appelé lors du premier cycle de distribution des tâches et il doit correspondre à l'initialisation des variables des automates. L'état "SUSPEND" qui est conventionnellement un état de suspension, permet d'attendre l'allocation d'une ressource externe à l'automate ou d'attendre l'apparition d'un événement quelconque. L'état "WAKE" est réservé à une reprise d'activité d'un automate précédemment à un état "SUSPEND", enfin l'état "QUIT" est réservé à chaque dernier cycle exécuté avant de quitter un automate. "QUIT" sert typiquement à clore des fichiers, purger des écrans etc... I1 va de soi qu'il est toujours possible de définir l'utilisation d'autres états d'automates et que cela dépend des applications et des programmeurs. A ce titre, il est possible de dire que le nombre d'états d'un automate n'est pas limité. "OUT" est une variable locale utilisée pour empêcher le changement de tâche à la fin d'un état d'automate. Si la variable est "YES" ce qui est vrai par défaut, le changement de tâche a lieu. Si le changement de tâche n'a pas à avoir lieu, il est possible de cycler sur plusieurs états d'un même automate sans retourner au fond de tâche du processeur lorsque par exemple un traitement urgent de données nécessitant le traitement ininterrompu de plusieurs états doit être effectué. Cette possibilité permet également d'effectuer une réduction du nombre total d'états de l'automate en affectant à un état unique un processus commun à plusieurs états sans pour autant avoir à attendre un cycle de tâches de fond pour effectuer le traitement commun. Ce processus de réduction d'état est évidemment répété autant de fois qu'il est souhaité s'il s' avère qu'un état donné utilise plusieurs traitements communs. Tant que l'automate ne retourne pas à la tâche de fond celui-ci reste bouclé ou fermé. Dans le cas contraire, l'automate est ouvert et il faut alors attendre un cycle complet de la tâche de fond pour traiter l'état suivant de l'automate. Du fait que la variable "OUT" est locale, les automates ouverts et fermés peuvent coexister sans aucune restriction et l'ouverture ou la fermeture d'un automate est de la sorte dynamiquement configurable par l'automate lui-même. I1 est clair que dans cette description de base, un automate est fondamentalement apériodique puisque c'est l'enchaînement des états des automates successivement distribués par la tâche de fond qui définit la période de base de la même tâche de fond du processeur. Ceci n'est pas nécessairement un défaut puisque dans ces conditions, les ressources de calcul du processeur ne sont jamais inutilisées mais elles sont affectées à toutes les tâches avec la même priorité, de sorte qu'il n'est pas possible de prédire à un instant donné la tâche qui est traitée par le processeur. Cependant pour certaines applications où il est nécessaire que les tâches soient appelées avec un rythme bien défini et séquencées par une horloge externe il peut être envisagé de modifier dynamiquement les priorités des tâches en fonction d'un événement de séquencement externe par rapport au déroulement des calculs avec une tâche de priorité la plus faible qui représente réellement la tâche de fond du processeur. Pour obtenir cette caractéristique, il suffit d'échantillonner l'horloge utilisée dans l'un des automates et de retourner au programme hôte à des instants bien déterminés. Comme à chaque instant un seul automate est en cours de fonctionnement, l'automate en question, qui gère la ressource temps, représente l'automate d'état du fond du processeur et les cycles du programme hôte de fond de tâche sont automatiquement synchronisés par l'automate de fond. Les tâches de fond du processeur sont dans ce cas regroupées dans l'automate de fond. La priorité des autres tâches est alors définie implicitement par l'ordre de leur distribution à compter de la sortie de l'automate de fond. Dans un autre ordre d'idées et pour montrer la souplesse de la procédure d'écriture des automates, la finalité de chaque automate est laissée à l'appréciation du programmeur qui écrit le code et n'a pas besoin d'être normalisée dans la procédure d'écriture ellemême. Il est ainsi possible d'affecter les automates par fonction ou par ressource processeur ou même de panacher les deux types Si nécessaire. A titre d'exemple, un diagramme d'état d'un automate dédié à la prise en compte de messages inertiels dans un simulateur de signaux GPS mettant en oeuvre le métalangage décrit précédemment est montré à la figure 1. Cet automate particulier permet la prise en compte de messages inertiels GPS structurés de la façon représentée à la figure 2 comportant notamment dans une première zone 1 une entête de message, dans une deuxième zone 2 un numéro ID d'identification de bloc, dans une troisième zone 3 le nombre de mots composant le message, dans une quatrième zone 4 un drapeau de signalisation, dans une cinquième zone 5 un mot de contrôle " CK1 ", dans une sixième zone 6 les N mots de message et enfin dans une septième zone 7 un deuxième mot de contrôle Le fonctionnement d'un automate correspondant pour la prise en compte de ce message est alors entièrement décrit par le diagramme à 16 états de la figure 1 défini par les etats "INIT", "SUSPEND", "WAKE" et "QUIT" du métalangage décrit précédemment. Dans ce diagramme l'état 8 place l'automate dans l'état attente entête 9 pour attendre l'arrivée de l'entête 1 du message. L'automate passe dans l'état 10 d'attente du mot d'identification de bloc ID lorsqu'il a reçu l'entête de message 9. L'automate quitte l'état 10 pour passer à l'état 11 lorsqu'il a reçu le mot ID, pour attendre le mot indiquant le nombre de mots N du message. I1 passe ensuite de la même façon à l'état 12 d'attente du mot 4 indiquant la durée du message, puis il passe successivement aux états 13 à 16 de vérification, de collecte et de transfert des N mots du message reçu vers un autre automate. Dans ce diagramme chaque événement attendu non réalisé dans chacun des états 9 à 12 au bout d'une durée déterminée, replace automatiquement l'automate dans l'état 9, et l'automate revient automatiquement à l'état 9 lorsque le transfert des N mots de message est réalisé à la fin de l'état 16. Cet enchaînement cyclique des états d'un automate a pour avantage qu'il permet de l'enchaîner avec un autre automate à chaque fin d'état. Cela permet dans un environnement multitâches de chaîner respectivement chaque automate 171 à 17. les uns aux autres de la manière représentée à la figure 3, chaque automate restant indépendant. Un mode de réalisation d'un automate est représenté à la figure 4. Celui-ci comporte typiquement une mémoire PROM 18, couplée entre ses sorties de données D et ses entrées d'adresse AD par l'intermédiaire d'un circuit additionneur 19 et un registre 20, pour permettre un adressage automatique des états de l'automate mémorisés dans la mémoire 18. Ainsi, une application du procédé selon l'invention à la réalisation d'un générateur de messages inertiels intégré pour simulateur d'environnement GPS Navstar, comportant par exemple un microordinateur de type IBM PC AT communiquant d'une part, avec un calculateur de navigation type DEC PDP/11/70 à travers un réseau local type "token Ring PRONET" et d'autre part, avec un récepteur GPS à travers une liaison bidirectionnelle série type RS422 à 9600 bauds avec un taux global de charge de ligne d'environ 75, peut consister pour ne pas surcharger la ligne RS422 à partager la gestion du système en 5 tâches simultanées, une tâche 1 : pour la gestion d'écrans de présentation et de commandes clavier une tâche 2 : pour la gestion du réseau local PRONET une tâche 3 : pour la gestion des blocs inertiels émis par le récepteur une tâche 4 : pour la gestion de blocs instrumentés ou mesurés par le récepteur GPS et une tâche 5 : pour la gestion de l'enregistrement de données sur disque dur. La tâche 1 est en fait décomposée en 12 automates différents pour des raisons de clarté d'écriture, et par conséquent l'ensemble du programme se décompose en 16 automates fonctionnels imbriqués, qui occupent 150 Koctets de code source, en modèle de mémoire large, sans overlays. Le programme reçoit à un rythme de 5 Hz et en avance de 2 secondes des blocs de données représentant la position d'un mobile, à travers le réseau local. Il doit alors interpoler les données fournies pour pouvoir les réémettre sous forme de messages inertiels à 10 Hz vers le récepteur GPS, les présenter à l'écran, et les enregistrer. En retour, le récepteur GPS fournit différentes informations sous forme de messages RS422 à 1 Hz il convient de démoduler à l'aide de l'automate précédemment décrit ces blocs instrumentés, de les afficher, et de les enregistrer. Ces tâches sont complétées par des procédures de changement de format entre les variables en virgule flottantes DEC (utilisées par le PDP 11/70), les variables en virgule fixe (format INS), les variables flottantes IEEE 457 (format natif de l'IBM PC) et les variables en ASCII (format d'affichage des données) ainsi qu'un certain nombre de changements d'unités. Dans cet exemple, parmi les différents choix possibles, il est judicieux et plus simple vis à vis des impératifs de maintenance logicielle d'affecter chaque ressource disponible à un auto mate indépendant gérant uniquement la ressource qui lui est allouée. Pour des raisons de rapidité de réponse en temps réel, chacun de ces automates est couplé à un dispositif de commande d'interruption écrit en assembleur, qui gère l'interface de communication entre une structure de type FIFO, communiquant avec les automates dédiés, et le matériel lui-même. Ces dispositifs encore appelés "drivers" dans le langage anglo-saxon remplacent les fonctions classiques d'interface du langage C avec le système d'exploitation DOS et BIOS de la machine. A côté de ces automates gestionnaires de ressources, l'automate principal, gérant l'écran et le clavier, est réparti suivant N automates secondaires représentant fonctionnellement N écrans différents). Naturellement, d'autres applications de l'invention sont encore possibles et en particulier toutes celles mettant en oeuvre des systèmes de traitement de données. REVENDICATIONS 1. Procédé de réalisation d'automates de gestion multitâches pour système de traitement de données comprenant au moins un calculateur de traitement de données connecté à au moins une unité de périphérique caractérisé en ce qu'il consiste à partager la gestion du calculateur et des périphériques en un nombre déterminé de tâches (171 ... 17j), à construire pour chaque tâche un automate (17.) qui lui est spécifique et à affecter à chaque tâche des cycles de temps d'exécution appelés états par un programme -de tâche de fond chargé de distribuer dans une période de temps déterminée un temps de gestion à chacun des états des automates (17.). 2. Procédé selon la revendication 1 caractérisé en ce que chaque automate (17.) est défini par une machine à plusieurs états programmable à volonté. 3. Procédé selon l'une quelconque des revendications 1 et 2 caractérisé en ce que les états exécutées par chacun des automates sont lancées en série successivement les uns après les autres à l'intérieur d'un même cycle du programme de tâche de fond. 4. Procédé selon l'une quelconque des revendications 1 à 3 caractérisé en ce que chaque automate comporte une mémoire morte programmée (8) couplée entre ses sorties de données et entrées d'adresses par l'intermédiaire d'un circuit additionneur (19) et d'un registre (20) pour permettre l'adressage automatique des états de l'automate mémorisés dans la mémoire (lu). 5. Utilisation du procédé selon l'une quelconque des revendications 1 à 4 à la réalisation d'un générateur de messages inertiels pour simulateur d'environnement GPS Navstar comprenant un microordinateur communiquant d'une part, avec un calculateur de navigation à travers un réseau local et d'autre part, avec un récepteur de satellite GPS caractérisé en ce qu'il consiste à partager la gestion du générateur en une première tâche pour la gestion des écrans et clavier liés au microordjnateur, une deuxième tâche pour la gestion du réseau local ; une troisième tâche pour la gestion des blocs inertiels émis par le récepteur, une quatrième tâche pour la gestion des blocs instrumentés ou mesurés par le récepteur GPS et une cinquième tâche pour la gestion de l'enregistrement des données sur un disque dur du microordinateur.