Brevet FR2712712A1 — publié le 19950524

La présente invention concerne des systèmes informatisés de commande et, plus particulièrement mais non exclusivement, des ordinateurs de commande de vol pour avion. Selon un aspect de la présente invention, on prévoit un système informatique de commande pour commander une multitude de servomoteurs, par exemple une série de servomoteurs de commande de vol à bord d'un avion, le système informatique de commande comprenant une multitude d'unités d'entraînement de servomoteurs et de contrôle pour former des signaux afin de commander des servomoteurs et de contrôler leur fonctionnement, et un système informatique connecté de manière à recevoir une information de contrôle en provenance des unités d'entraînement et de contrôle, pour en commander le fonctionnement, le système informatique comportant une multitude de modules informatiques pouvant fonctionner pour exécuter les fonctions respectives des lois de commande associées i une commande correcte des servomoteurs, par exemple les calculs de l'attitude de l'avion tels que les calculs de tangage, de roulis et de lacet, chaque module de cette sorte comprenant un ensemble de transmission de données connecté à une ligne respective d'émission en série de données qui est à son tour connectée à un ensemble respectif de réception de données dans chaque autre module, d'où il résulte qu'une communication entre modules est obtenue par l'un quelconque des messages de données asynchrones de diffusion des modules sur sa ligne de diffusion de données pour que ce message de données soit reçu par n importe quel autre module en ayant besoin. La présente invention sera bien comprise lors de la description suivante faite en liaison avec les dessins ci-joints dans lesquels La figure 1 est un schéma sous forme de blocs d'un système informatique de commande de vol; La figure 2 est un schéma sous forme de blocs d'un ordinateur utilisé dans le système de la figure 1; La figure 3 est un schéma sous forme de blocs d'une unité d'entraînement et de contrôle de servomoteurs utilisée dans le système de la figure 1; La figure 4 est un schéma simplifié de circuit d'une unité d'interface utilisée dans l'ordinateur de la figure 2; La figure 5 est un schéma simplifié de circuit d'un premier module de calcul utilisé dans l'ordinateur de la figure 2; La figure 6 est un schéma simplifié de circuit d'un second module de calcul utilisé dans l'ordinateur de la figure 2; La figure 7 est un schéma simplifié de circuit d'un module d'entraînement de servomoteurs utilisé dans l'ordinateur de la figure 2 et Les figures 8 à 14 sont des diagrammes respectifs permettant d'illustrer le fonctionnement des modules utilisés dans l'ordinateur de la figure 2. La description suivante concerne un ordinateur de commande de vol basé sur les techniques des multiprocesseurs asynchrones. On utilise un système à contre-contrôle quadruplex, chaque branche marchant de manière asynchrone. Chaque branche de calcul comprend dix modules indépendants de traitement, marchant en parallèle de façon asynchrone. La tâche des lois de commande est répartie entre sept processeurs alors que deux sont spécialisés pour la surveillance d'un servomoteur et un pour un test pré-vol. Le module de traitement est basé sur le processeur de signaux dit TMS 320. Une stratégie commune est utilisée pour les communications entre modules et entre branches. I1 s'agit d'un fonctionnement numérique sériel multiplex à 10 Mbits/sec. Chaque liaison est à source unique, multiterminaux récepteurs de données, autonome et entièrement asynchrone à l'émetteur et aux récepteurs, tamponnée avec des mémoires à point d'accès double. La taille de bloc peut être choisie jusqu'à 128 mots. Des liaisons par fibre optique peuvent être utilisées entre branches et entre ordinateurs et unités d'entraînement de servomoteurs (UES) (si celles-ci sont des'unités séparées). La gestion des défaillances est basée sur les méthodes normalement acceptées de contre-contrôle de détecteurs et de consolidation. On suppose un servomoteur quadruplex et celui-ci est également soumis à un contre-contrôle. Des dispositifs supplémentaires de test automatique sont inclus pour le test pré-vol et à des fins de maintenance et pour certains pour des fonctions de surveillance du vol. L'architecture du système permet à l'électronique d'entraînement des servomoteurs d'être conditionnée soit à l'intérieur des ordinateurs de commande de vol, soit sous forme d'une ou de deux unités séparées d'entraînement de servomoteurs. On suppose un système quadruplex - détecteurs, ordinateurs et servomoteurs - à l'exception de certains détecteurs et servomoteurs qui sont à un niveau de redondance plus faible. I1 est prévu douze servocerrndes par branche. Un terminal de bus de données dit DEY TAN 0018 est inclus dans chaque ordinateur; on suppose que deux d'entre eux feront l'interface avec les bus des circuits avioniques et deux avec les bus des services généraux. Tous les ordinateurs sont identiques en matière de matériel et de logiciel, toute dépendance de branche étant commandée par le câblage de l'avion. La conception est basée sur un certain nombre de modules identiques de traitement par microprocesseur, chacun communiquant avec d'autres éléments du système en utilisant une transmission numérique sérielle asynchrone. Chaque module de traitement est un ordinateur autonome fonctionnant en parallèle avec les autres, mais de façon asynchrone par rapport à eux. La tâche totale de calcul est partagée entre les processeurs; celle-ci couvre les lois de commande, le contrôle des détecteurs, le contrôle des servomoteurs et le test automatique (TA). Un matériel supplémentaire est prévu pour les interfaces avec les détecteurs, l'entraînement des servomoteurs et les interfaces des bus de données DEF STAN 0018. L'ordinateur comprend trois sections distinctes : une section principale de calcul et deux sections d'entraînement de servomoteurs. La section de calcul reçoit toutes les données des détecteurs, exécute la surveillance du dispositif de décision en redondance majoritaire et des lois de commande, et sort les demandes de position des gouvernes pour les sections d'entraînement des servomoteurs. Elle comprend également les fonctions du test pré-vol (TPV) et d'interface avec les bus de données. Chaque section de servomoteur fournit l'entratne- ment du servomoteur , la fermeture de boucle et la surveillance jusqu'd six servomoteurs. Chaque section comporte ses propres communications entre branches, et n'a que des communications assez limitées avec les autres sections. Cela permet aux sections d'entraînement des servomoteurs d'être séparées des ordinateurs de commande de vol (OCV) et d'être reconditionnées sous forme d'une ou de deux unités d'entraînement de servomoteurs (UES) (si la configuration de la cellule de l'avion l'impose) sans impact sur la conception du système. On se reportera à la figure 1. La section de calcul comprend (a) Une unité côté avant (UCA) I1 s'agit-d'un noeud de communications pour les informations de tous les détecteurs entrant dans l'ordina teur et aussi pour toutes les informations renvoyées par les UES. Toute donnée associée à cette branche (à partir des unités de détecteurs des mouvements de l'avion, des centrales de bord aérodynamiques, et les détecteurs, les dispositifs d'apparition et les aiguillages discrets) est en interface avec 1'UCA et combinée dans un seul train sériel de données. Celui-ci est acheminé jusqu'à toutes les autres branches et est également disponible pour tous les modules dans sa propre section de calcul. (b) Modules de traitement Huit modules de traitement sont disponibles dans la sec tion de calcul. L'un sera spécialisé aux fonctions TPV, alors que les autres exécutent les calculs des lois de commande, dont le dispositif de décision en redondance majoritaire/moniteurs. Chaque processeur fait une itéra tion de son propre programme à la vitesse maximum, sans corrélation avec l'un quelconque des autres modules. Les tâches des lois de commande sont partagées entre les modu les de façon que les tâches les plus déterminantes en matière de temps soient exécutées par des processeurs fai blement chargés et donc au taux d'itération les plus rapides. Chaque module peut avoir accès aux sorties de l'un quelcon que des autres modules et à la donnée des détecteurs de l'ensemble du système (les quatre branches). Dans le cas où cela est approprié, les sorties d'un module comprennent des demandes des gouvernes; en plus de leur acheminement normal, les sorties de ces modules sont prélevées pour les entraînements des servomoteurs. Voir figure 2. (c) Module DEF STAN 0018 Ce module à accès à toutes les données de la même façon que les modules de traitement. Cette donnée est disponi ble pour être sortie sur le bus de données et la donnée provenant du bus est mise à la disposition de tous les modules via l'UCA. Les sections d'entraînement de servo moteurs comprennent chacune (a) Six servocommandes Celles-ci reçoivent les demandes des gouvernes en prove nance de la section de calcul, font l'interface des si gnaux des convertisseurs de position des servomoteurs et des gouvernes et fournissent une fermeture analogique de boucle des réactions des premier et second étages. Les de mandes et signaux des convertisseurs sont transmis au module du moniteur. Voir figure 3. (b) Module de moniteur I1 s'agit d'un module standard de traitement. I1 reçoit les demandes des gouvernes et les données des convertis seurs provenant des servocommandes, les échanges avec les trois autres branches et exécute un contre-contrôle à hau te vitesse des sorties de l'ordinateur, des servomoteurs et des convertisseurs de signaux. I1 commande la soupape de coupure des servomoteurs et renvoie l'information d'état à la section de calcul via 1'UCA. Une méthode commune de communication est utilisée dans tout le système. I1 s'agit d'un procédé numérique sériel à 10 Mbits/sec. Chaque liaison est à source unique, multi terminaux récepteurs de données, et est entièrement asyn chrone, à l'émetteur et aux récepteurs, mise en mémoire tampon en utilisant des mémoires à point d'accès dou ble (MPAD). Demanière à satisfaire les différents besoins des diverses liaisons, la taille des blocs peut être choi sie par le matériel jusqu'd 128 mots. Conception de l'ordinateur Système de communications Le format choisi pour les communications est commun à toutes les liaisons de communications dans le système de commande de vol. I1 a été conçu pour satisfaire toutes les formes de communications entre branches et entre modules, dictées par le choix de l'architecture et la répartition des lois de commande. Une caractéristique importante des communications est la solution de la diffusion avec terminal récepteur de données, source unique, permettant la souplesseSde conception et l'extension du système (si nécessaire) sans changement du format et avec une modification minimale du matériel pour augmenter la longueur des données. Le format choisi est une transmission sérielle numérique asynchrone marchant à 10 Mbits/sec avec codage par retour à zéro, avec tampon aux deux extrémités par mémoire à point d'accès double. La technologie des boucles numériques à verrouillage de phase est utilisée pour récupérer l'horloge de transmission et une séquence unique au commencement de chaque mot de données permet la resynchronisation de l'horloge récupérée avant le rythmage d'une donnée quelconque dans le registre à décalage du récepteur et la bascule de données.La technologie BNVP impose que les circuits de réception fonctionnent à 40 MHz. Pour maintenir les temps de débit au minimum, le format des communications est adapté à chaque besoin en préréglant la longueur des données (bloc) à 16, 32, 64 ou 128 mots, avant recyclage. Un mot a une longueur de 27 bits avec l'organisation suivante 2 bits Nouvelle séquence de mot 7 bits Code d'adresse 1 bit Parité d'adresses 16 bits Donnée 1 bit Parité des données L'inclusion d'un codage d'adresse à l'intérieur du mot annule la nécessité de la synchronisation des blocs et simplifie la tâche de l'utilisateur pré-établissant le cycle des données. De plus, l'intégrité des communications est améliorée, et la possibilité d'un chargement incorrect des données dans la mémoire MPAD est réduite. Les erreurs de parité détectées empêcheront une sur-écriture des données dans la MPAD. Les communications inter-branches peuvent utiliser une longueur de 128 mots et les communications entre modules une longueur de 16, 32 ou 64 mots. Le caractère asynchrone du système nécessite un tamponnage des communications par la MPAD. Cela nécessite à son tour des affectations de priorités en cas où il se produirait des encombrements. L'agencement du système d'horloge dans le système de transmission nécessite des données mises facilement à disposition par conséquent, l'émetteur des communications aura toujours la priorité sur un ordre d'écriture du microprocesseur dans la MPAD encombrée. L'unité côté avant (figure 4) Cette unité agit en noeud de communications pour chaque branche du système. Pour obtenir des données provenant du monde extérieur, il y a cinq récepteurs à fibre optique recevant des trains de données numériques en provenance des unités de détection du mouvement de l'avion (UDMA), des centrales aérodynamiques (CA1 et 2) et des UES1 et UES2. De plus, il y a huit entrées analogiques provenant des commandes du pilote qui sont multiplexées pour utiliser le convertisseur analogique/numérique unique. Enfin, seize entrées discrètes (huit isolées optiquement) complètent les récepteurs du monde extérieur. Tous ces signaux de données sont entrés dans une mémoire à point d'accès double et lus selon nécessité par le circuit de commande des communications inter-branches. Celui-ci comprend un réseau logique programmable (RLP) de réception avec la remise à zéro de compteur interne, réglée à 128. Au lieu que le bus d'adresses adresse directement la MPAD comme dans le cas de la stratégie standard de communications, il est utilisé pour adresser séquentiellement la mémoire morte programmable "en vol". La donnée maintenue à chaque emplacement de cette mémoire morte programmable contient la sous-adresse de la mémoire à point d'accès double et le code de sélection de puce de chaque mot de donnée devant être inclus dans le trafic inter-branches. Ainsi, toute reconfiguration nécessaire du trafic des données inter-branches s'obtient facilement en, par exemple, programmant cette mémoire morte programmable. Une donnée supplémentaire en branche devant sortir comme trafic inter-branches est fournie par un groupe de neuf RLP d'émission pour communications inter-modules et mémoires associées à point d'accès double. Huit d'entre eux sont connectés aux modules de calcul d'ordre général de la branche et le restant à la carte du bus de données. Ainsi, par une programmation appropriée de la mémoire morte programmable "en vol", tout mot de donnée provenant du réseau des communications inter-modules peut également être sorti comme donnée interbranches. La donnée inter-branches est alors appliquée à trois émetteurs à fibre optique, avec un émetteur pour les branches 2, 3 et 4. La donnée inter-branches d'entrée est reçue par trois récepteurs à fibre optique'et appliquée au fond de panier comme transmissions de données sérielles numériques en même temps que sa propre donnée inter-branches sous forme I/L1, I/L21 I/L3 et I/L4- Dans le mode avec test de première ligne, la mémoire morte programmable en vol est remplacée par une autre mémoire morte programmable qui peut être programmée pour permettre la substitution des données aérodynamiques et des ordres du pilote par une donnée synthétisée qui est sortie par la carte TPV et acheminée sur le trafic inter-branches dans les secteurs appropriés par cette mémoire morte programmable. Cela permet un test dynamique, et un test automatique de la réponse des gouvernes selon nécessité pour les tests de première ligne. Module de traitement (figure 5) Celui-ci est configuré en carte d'ordinateur autonome. La section de calcul constituée d'un microprocesseur (dit TMS 32010) et d'un circuit principal, d'une mémoire morte programmable effaçable 16K x 16 contenant la mise en tension TPV et un loqiciel~réi.4zn; Sus Jlei.hal l et une mémoire à accès direct de travail (RAM) 2K x 16. L'horloge de panneau est un oscillateur à quartz de 80 MHz avec le circuit diviseur suivant 2 2 = 40 bEz pour faire fonctionner les RLP de réception . 4 = 20 MHz pour faire fonctionner le TMS 320 . 8 = 10 MHz pour faire fonctionner les RLP d'émission. I1 y a huit RLP de réception et la mémoire associée à point d'accès double, commandés par la répartition des lois de commande. Dans la plupart des cas, la correction de programme du fond de panier de ces récepteurs (voir en figure 2, l'architecture OCV) est configurée sous forme de quatre récepteurs inter-branches et quatre récepteurs inter-modules, bien que l'un quelconque puisse se comporter en inter-modules ou inter-branches sans modifications à bord. De plus,il y a huit entrées discrètes et huit sorties discrètes, dont l'appîi- cationvarie avec la fonction du module. La donnée calculée est transmise du tableau par une configuration standard RLP émetteur et MPAD, et acheminée jusqu'aux autres modules nécessitant la donnée. La sélection à bord de la remise à zéro du compteur d'adresses instaure la taille des blocs de données et assure des temps de cycle minimum de la transmission pour les communications inter-modules. Le circuit de gestion des défaillances sur le module incorpore une minuterie de contrôleur de séquence afin de détecter l'horloge du système et la défaillance du processeur. La minuterie comprend un compteur 16 bits commandé par une horloge indépendante de 1 MHz, donnant un temps de séquencement de 65,536 ms dans des pas de 1 As. La minuterie est remise à l'état initial par l'écriture par le microprocesseur dans une adresse spécifique (CS13) à la fin de chaque cycle du programme. La sortie de ce compteur est appliquée à un comparateur d'amplitude qui la compare au code opération de la mémoire morte (ROM) 16 x 1 contenant le temps de cycle correct programmé en As. Si le comptage de la minuterie dépasse la valeur de la mémoire morte, le compteur est inhibé et une condition de défaillance de module est instaurée. Une ligne extérieure de remise à l'état initial est prévue pour agir en sauvegarde contre le blocage ou la mise sous tension et fournit la commande TPV du circuit. Une défaillance pour mise en sommeil de l'horloge de la minuterie du contrôleur de séquence peut être évitée en utilisant le microprocesseur pour lire le compteur à deux instants différents d'un cycle du programme. L'interrogation de ces deux valeurs par le processeur produira un signal discret de défaillance de module si les valeurs sont identiques, indiquant une défaillance de l'horloge de la minuterie du contrôleur de séquence. Celui-ci sera également instauré si le test de contrôle par totalisation de la mémoire morte est défaillant au cours d'un TPV ou en vol. Module Def. Stan. 0018 (figure 6) Ce module permet de recueillir une information sur l'état et les défaillances; il est en interface avec un bus de données Def. Stan. 0018 et avec des voyants d'état sur les panneaux de commande du pilote. Une information du moniteur/dispositif de décision en redondance majoritaire et sur l'état du test automatique est reçue par les récepteurs de module standard et la mémoire à point d'accès double en provenance des quatre liaisons interbranches. Les signaux discrets sur les défaillances de module en provenance de leurs minuteries de contrôleur de séquence sont reçus dans une bascule à 16 bits. L'information est recueillie par un processeur et le circuit de support afin de produire une information sur les défaillances qui peut être transmise sur le bus associé de données via une interface appropriée et/ou utilisée pour commander des voyants d'alarme dans le poste de pilotage (via une bascule à 16 bits), le cas échéant. La donnée provenant du bus de données est transmise à 1 'unité UCA pour être placée sur le trafic inter-branches par un émetteur de module standard. Entraînement des servomoteurs (figure 7) Chaque module d'entraînement des servomoteurs fournit au système une interface avec deux servomoteurs de gouvernes. Le module d'entraînement reçoit les signaux de demande de position des gouvernes à partir d'un module unique de traitement via un récepteur asynchrone de même conception que celui utilisé sur les modules de traitement. Le train de données comporte la sortie totale du module de traitement et le module d'entraînement des servomoteurs comprend le moyen permettant la sélection de la donnée correcte. Les deux adresses (une pour chaque signal potentiel d'entraînement) sont maintenues dans deux mémoires mortes programmables à octet. L'adresse d'entrée est comparée aux adresses stockées dans deux comparateurs à octet; si la donnée reçue est valable et que l'adresse est adaptée, alors elle est déclenchée et transformée en forme analogique. Le module fournit l'excitation et la démodulation des signaux de position des servomoteurs des gouvernes et servosoupapes. Les signaux des servomoteurs et de la position des gouvernes sont additionnés avec le signal de demande des gouvernes dans l'amplificateur d'entraînement des servomoteurs afin de donner une fermeture de boucle analogique. Les signaux démodulés de réaction, ainsi que les signaux sur la position des servosoupapes et de demandes des gouvernes, des deux entraînements sont multiplexés à l'entrée d'un convertisseur analogique/numérique unique. Les sorties numérisées sont transmises par une liaison asynchrone standard au module du moniteur des servomoteurs. Le module d'entraînement contient également la logique et le tampon pour commander les vannes à solénoïde des servomoteurs, commandées par des sorties discrètes en provenant ce du module du moniteur. Tout signal de défaillance des servomoteurs en provenance du moniteur pnnzxgEGa l'isolement du servomoteur concerné; un signal de défaillance du moniteur provoquera l'isolement des deux servomoteurs. Gestion des défaillances Le système est conçu pour présenter les caractéristiques suivantes (a) possibilité de survie à deux défaillances; (b) indication au pilote des défaillances qui réduisent la redondance ou affectent les performances; (c) indication de tous les défauts à un système centralisé d'enregistrement des données de maintenance. La gestion des défaillances est basée sur un contrecontrôle et celui-ci est effectué à deux points distincts pendant le traitement.Les défaillances des détecteurs, transducteurs et gouvernes seront détectées par les algorithmes du moniteur du dispositif de décision en redondance majoritaire (M/DDRM) qui fait partie du logiciel résidant en vol dans les divers modules du processeur. Les sorties du processeur, les signaux des servomoteurs et les sorties des convertisseurs de signaux des servomoteurs sont contrôlés par le module du moniteur des servomoteurs. Toute information sur les défauts sera acheminée jusqu'au module du bus de données pour distribution. Détecteurs et gouvernes Chaque signal de détecteur et de commande est acheminé jusqu'd un seul OCV. Les entrées sont reçues par l'unité UCA, formatées et retransmises aux autres branches. Le module approprié de traitement dans chaque OCV accède ainsi aux quatre branches de données des détecteurs et peut exécuter les fonctions (M/DDRM). Ces fonctions sont réparties entre les modules de traitement, un détecteur particulier étant traité dans le processeur qui utilise ce signal de détecteur. Les M/DDRM sont déterminants pour le processus de gestion des défaillances et sont discutées plus en détail ci-après. Comme l'unité UCA et les modules de traitement à l'intérieur d'un OCV sont largement indépendants, un grand nombre de défaillances indépendantesdifférentes peuvent survivre. En particulier, aucune défaillance dans un autre module ne peut éviter que l'unité UCA fournisse des entrées de détecteur aux autres branches. Lors de l'identification d'une panne par un M/DDRM, l'entrée défectueuse sera sortie. Des signaux consolidés, basés sur de bonnes entrées survivantes, seront utilisés à des fins de commande. Les indications de défaillance seront sorties par le module de traitement pour action par le module du bus de données. Certaines données des détecteurs seront pré-traitées avant d'atteindre 1'OCV, par exemple les données UDMA et CA. Les processeurs dans les UDMA et CA comprendront TA et produiront une information d'état. En vol, cette donnée ne sera pas utilisé; activement pour la gestion des défaillances mais sera enregistrée . (Une exception éventuelle concerne la centrale aérodynamique où une combinaison d'un contre-contrôle et d'une information TA peut être utilisée). Toutes défaillances à l'intérieur d'un OCV sera détectée ailleurs dans le système, soit dans d' autres branches soit dans son propre module de moniteur de servomoteur. Certaines fonctions TA sont incluses dans certains modules, par exemple, le moniteur d'alimentation, la minuterie du contrôleur de séquence. En cas de détection d'un défaut,celles-ci peuvent compcn-ter une action locale poor arrêter le module irdividuel mais la gestion des défaillances de l'ensemble du système est basée sur une détection de la défaillance à un autre endroit. L'information TA est utilisée à des fins de maintenance. Moniteur des servomoteurs On suppose qu'il y a des servomoteurs quadruplex, ne comportant aucune possibilité d'isolement pour défaillance mécanique. Une seule défaillance de matériel pourrait permettre la survie, mais de manière à survivre à deux défaillances, il est nécessaire d'isoler électriquement une branche défaillante. Cela est obtenu en utilisant des soupapes à solénoïde commandées par le module du moniteur des servomoteurs. Pour l'intégrité, chaque branche sera capable de n'isoler qu'elle-même. Chaque module de moniteur recevra une demande des gouvernes et les réactions des servomoteurs en provenance de sa propre carte d'entraînement de servomoteur, et une donnée similaire concernant les trois autres branches en provenance de leurs modules de moniteur via des liaisons spécialisées de données interbranches. Les algorithmes M/DDRM détecteront des défaillances dans des branches individuelles. Les défaillances dans la propre branche d'un module de moniteur, dues soit à une défaillance de servomoteur soit à une défaillance OCV auront pour effet qu'il provoquera la désexcitation de la soupape à solénoide appropriée. Toutes les branches signaleront la défaillance à leur propre OCV. Les défaillances des modules eux-mêmes du moniteur seront identifiées par un test automatique (par exemple, un contrôle par totalisation de mémoire morte) et une minuterie de contrôleur de séquence) et provoqueront la désexcitation de tous les solénoides commandés par ce moniteur. Algorithmes du moniteur du dispositif de décision en redondance majoritaire Les algorithmes du moniteur du dispositif de déc i- sion de redondance majoritaire ont un rôle central pour la gestion des défaillances. Ils doivent détecter et isoler les pannes et produire des sorties consolidéres à partir des "bonnes" entrées survivantes. Leur conception doit minimaliser les transitoires de défaillances à leur sortie et dans la réponse de l'avion. Certaines considérations sur la conception du moniteur de dispositif de décision en redondance majoritaire (MDDRM) sont les suivantes (a) Fonctionnement asynchrone des branches. Les (M/DDRM) doivent accepter les divergences dues aux effets de désalignement sur les données d'entrée, provenant du fonctionnement asynchrone. Ces divergences s'additionneront aux tolérances normales des variations mesurées. Les seuils de détection des défàillances seront déterminés par ce qui suit (A) Tolérances des détecteurs/transducteurs fonctionnant correctement. (B) Vitesse maximum de changement de chaque en trée en fonctionnement normal. (C) Amplitude des désalignements dans le temps. (b) Compromis/sophistication/vitesse L'amplitude de la réponse de l'avion à un transitoire de défaillance dépendra (entre autres choses) de l'amplitude du transitoire de défaillance sur le signal de sortie M/DDRM et de la vitesse d' itération du M/DDRM. Un algorithme sophistiqué peut réduire le transitoire de sortie mais demandera plus de temps, c'est-d-dire que la vitesse d'itération sera réduite et que le transitoire persistera plus longtemps. Ainsi, il y a un compromis entre sophistication M/DDRM et vitesse de fonctionnement. (c) Attente avant déconnexion Les déconnexions fâcheuses peuvent être réduites en attendant un ou plusieurs cycles du M/DDRM, au cours desquels une entrée défectueuse doit rester défectueuse, avant la coupure de l'entrée. Malheureusement un transitoire de défaillance existera à la sortie pendant la sortie de la période d'attente. Si une seconde défaillance identique se produit pendant la période d'attente, une situation deux-contre-deux peut se développer. Pour cette raison, il est souhaitable de réduire au minimum les périodes d'attente. Les pérodes d'attente D/DDRM doivent être optimalisées afin de résister aux déconnexions fâcheuses, tout en réduisant au minimum la probabilité d'une situation deux-contre-deux. (d) Ré instaurations Les réinstaurations par le pilote d'une première défaillance seront permises. Les réinstaurations de secondes défaillances ne seront pas autorisées : celles-ci pourraient se traduire par une situation deuFcontre-deux aux M/DDRM. (On notera que l'utilisation des mots d'état du test automatique pour la résolution d'une situation deux-contre-deux peut être envisagée). (e) Algorithmes Des algorithmes séparés peuvent être nécessaires pour traiter des cas à quatre, trois et deux entrées. En variante, on pourrait utiliser un algorithme auto-adaptatif. Un type différent de processus de consolidation sera nécessaire pour des entrées discrètes. (f) Mise sous tension Les M/DDRM doivent apporter de bonnes entrées en ligne pendant la mise sous tension. Si la chaîne de pilotage doit survivre à des interruptions en vol de l'alimentation, on doit prévoir que les M/DDRM reconnectent de bonnes entrées lors de la reprise du système. Une annexe indique une mise en oeuvre typique d'un moniteur/dispositif de décision en redondance majoritaire. Indication des défaillances L'indication des défaillances doit être indiquée au pilote et au système central des données de maintenance. Cette fonction sera exécutée par le module du bus de données dans chaque OCV. Les moniteurs des dispositifs de décision en redondance majoritaire produiront des mots d'état défaillant, identifiant la défaillance, qui seront communiqués au module du bus de données, via le système de communications intermodules. Les mots d'état de test automatique pour les UDMA etc. seront également reçus par le module du bus de données. La minuterie du contrôleur de séquence sur le module à objet général produira un signal discret de défaillance qui sera appliqué directement au module. Le module traitera lies diverses indications de défaillance et les sortira sur son bus de données, et de là au système des données de maintenance (et éventuellement à un en-registreur des données sur les accidents). Les circuits d'attaque des dispositifs de visualisation multi-fonctions recevront également les indications de défaillance et feront en sorte que l'affichage approprié du diagnostic soit mis à la disposition du pilote. Les données sur l'état de la chaîne de pilotage et d'avertissement doivent être à la disposition du pilote même en cas de perte complète du système de bus de données. Cela sera obtenu avec des voyants spécialisés, des voyants sur le panneau d'avertissement de la cabine de pilotage, et par un getter de danger principal. Tous ces voyants seront éclairés par un cablage spécialisé à partir du module. La logique des modules provoquera l'éclairage des voyants appropriés. La logique du matériel associée aux voyants d'avertissement assurera qu'ils ne sont pas éclairés par un module de bus de données, défectueux, unique. Chaque OCV comporte un module de bus de données, deux chaînes de pilotage sont en interface avec le bus de données aéro-électronique et deux avec le bus des services d'utilité. I1 y a typiquement un échange de données entre les circuits aéro-électroniques et les bus des services d'utilité : ainsi les indications de défaillance continueront à être disponibles sur les deux. bus même après défaillance de deux modules Des voyants ambres et rouges seront fournis. Les voyants ambres indiquent une perte de redondance; les voyants rouges indiquent une seconde panne identique, et peuvent être accompagnés d'un avertissement sonore. Les défaillances non déterminantes pour la sécurité, par exemple les volets de bord d'attaque, provoqueront un avertissement ambre. Test automatique Les fonctions de détection des défaillances, de l'isolement et d'indication en vol constituent une partie normale du fonctionnement du système multiplex. Elles sont basées largement sur un contre-contrôle et sont mises en oeuvre dans les algorithmes du dispositif de décision en redondance majoritaire-moniteur dans le logiciel résidant en Vol (LRV). Le test automatique (TA) est inclus dans le système principalement pour assurer la possibilité de service du système avant le vol (test de pré-vol TPV) et pour aider à l'entretien. Celui-ci est traité ci-après.Cependant, certaines fonctions TA s'effectuent continuellement pendant le vol; elles sont décrites ci-dessous. Détecteurs Les UDMA et CA comprendront probablement leur propre traitement et exécuteront des routines de test automatique pendant le vol. Des mots d'état seront sortis qui seront mis à la disposition de l'OCV. La sortie d'une information sur un défaut des UDMA ne sera pas destinée à une action de la part de 1'ODV car toutes les défaillances seront détectées et isolées par les moniteurs du dispositif de décision en redondance majoritaire. L'OCV utilisera probablement une combinaison de l'information d'état provenant des centrales aérodynamiques et les techniques de contre-contrôle pour choisir la meilleure information sur les données aérodynamiques. Modules de calcul Les modules de calcul à vocation multiple contiendront une petite quantité de matériel TA sous forme d'une minuterie de contrôleur de séquence. Cela est dicté par la nécessité de se protéger contre les défaillances dormantes du moniteur. Si la minuterie du contrôleur de séquence détecte un mauvais fonctionnement du processeur, alors la soupape à solénol- de sera abandonnée, d'où une erreur passagère des servomoteurs. Les défaillances détectées par les minuteries du contrôleur de séquence des autres modules des OCV se traduiront par le passage au module d'un signal discret de défaillance. Aucune autre action n'est prise par la minuterie du contrôleur de séquence : les sorties du module défectueux seront éliminées dans les moniteurs de dispositifs de décision en redondance majoritaire en aval ou déconnectées par le module du moniteur. Les minuteries des contrôleurs de séquence des modules individuels seront pré-programmées aux instants nominaux du passage du logiciel de ces modules. Les tests du logiciel des modules seront strictement limités : un fonctionnement correct du module sera vérifié avant le vol et sera ensuite laissé aux M/DDRM des autres modules pour détecter une défaillance particulière de modules. Des contrôles par totalisation en mémoire morte peuvent être mis en oeuvre pour exécution pendant le passage du LRV,mais ralentiront son exécution.Cependant,ils peuvent être justifiés dans certains modules individuels,par exemple dans le module du moniteur des servcmoteurs. Module de bus de données Les données passant entre les OCV et les bus de données de l'avion (dans les deux directions) seront vérifiées quant aux contrôles de parité. Les mots d'état seront également contrôlés. Les deux tests seront exécutés dans les modules de bus de données. Les modules à vocation multiple dans les OCV utiliseront la donnée provenant des bus de données 1553B seulement si elle a été acceptée par le module. Des divergences auront pour effet que les OCV ignoreront la donnée et la sécurité positive. Deux modules quelconques devront allumer les voyants d'avertissement de la chaîne de pilotage. Ainsi, de faux avertissements n'apparaîtront qu'après certaines pannes identiques de deux modules. Unité d'alimentation L'unité d'alimentation consolidera les deux ou plusieurs alimentations indépendantes de l'avion et les conditionnera pour utilisation par les autres modules dans les OCV. Une perte des alimentations individuelles ne provoquera pas la défaillance de l'OCV, mais la défaillance doit être signalée (tout au moins pour une action d'entretien), Dans le cas d'une défaillance d'une seule alimentation, l'unité d'alimentation produira un signal discret qui sera reçu par le module. Une défaillance totale des alimentations dans un OCV se traduira naturellement par la perte de cet OCV. L'unité d'alimentation excitera les transducteurs d'entrée du pilote et autres commandes. Une défaillance sera détectée ici comme une perte d'entrée, mais le test automatique TA doit assurer que la défaillance est recherchée auprès de l'unité correcte (c'est-à-dire auprès de l'OCV au lieu des transducteurs dans le cas présent). Les tests automatiques de l'alimentationseront tous exécutés par le matériel. Tests de pré-vol Stratégie Le test de pré-vol est un minimum fondamental des tests requis pour montrer que la chaîne de pilotage peut être l'objet d'un service en vol. Bien que pour des opérations en temps de pai. la "possibilité de service" signifie que 100 % des éléments de l'OCV déterminants pour le vol sont pleinement opérationnels, en temps de guerre, il peut s'avérer nécessaire de pouvoir voler avec des défaillances connues. Comme le test TPV comprend des tests "actifs" de détecteurs, servomoteurs, etc. il doit être isolé avec soin pendant le vol. Cela sera obtenu par une combinaison de verrouillages et de logiciel qui ne peut être entrée que lors de la mise sous tension. Un objectif est que les modifications du logiciel résidant en 'vol nécessite un minimum de modification des routines TPV. La stratégie adoptée pour TPV est la suivante (a) Contrôler le fonctionnement de chaque processeur, (b) Contrôler la présence de la totalité du logiciel, (c) Contrôler le fonctionnanit de toutes les liaisons de communications. (d) Tabler sur le TA local pour UDMA, Centrale Automatique, etc. (e) Exercice des servomoteurs. (f) Surveillance des commandes du pilote )interactif (g) Contrôle de l'alimentation par )avec le consolidation )pilote I1 n'y a aucune intention de vérifier le fonctionnement correct du logiciel de gestion des défaillances pendant TPV Cela sera validé sur un banc d'essai. Un contrôle de mémoire morte pour assurer que le logiciel est présent et correct est considéré comme convenable pour TPV. Contrôles de processeur TPV sera initialisé automatiquement lors de la mise sous tension. Chaque module de traitement entrera une petite section du logiciel TPV conçu pour un test automatique du processeur. Celui-ci effectuera les vérifications suivantes (a) Contrôle de lecture/écriture en mémoire à accès direct. (b) Contrôle par totalisation de la mémoire morte. (c) Contrôle arithmétique. Contrôles des communications Le TPV continuera alors sous la commande du module TPV,qui coordonnera les tests dans le système de communication inter-modules et inter-branches. La synchronisation entre les branches sera obtenue par la sortie par chaque module TPV d'un mot pour les modules TPV des autres branches et la réception de mots identiques en provenance des autres modules TPV. Un manquement à recevoir des mots de l'un des modules ou de plusieurs modules TPV sera à l'origine de l'indication d'une défaillance. Les modules TPV maintenant synchronisés, instruiront tous les autres modules des OCV pour leur demander d'écrire des mots agréés dans tous leurs emplacements en mémoire à point d'accès double de sortie. Chaque module inspectera alors ses MPAD d'entrée : un manquement à recevoir le mot correct de données dans chaque emplacement MPAD provoquera l'arrêt des modules. Une défaillance de réception par le module TPV de signaux "OK" en provenance des autres modules sera la cause d'une signalisation d'un défaut. Test de pré-vol des UDMA et Centrales Aérodynamiques. Les UDMA et CA initialiseront leurs propres routines TA lors de la mise sous tension. L'achèvement satisfaisant de ces tests se traduira par la transmission des mots d'état aux modules et aux modules TA des ordinateurs OCV. Un manquement à recevoir les mots d'état dans un intervalle de temps alloué sera à l'origine de l'indication d'une défaillance par les OCV. Tests interactifs avec le pilote Les tests automatiques décrits ci-dessus seront suivis d'un certain nombre de tests interactifs du pilote qui seront coordonnés par les modules TPV. Le bouton TPV éclairé clignotera chaque fois qu'une action est requise de la part du pilote. Les tests interactifs comprendront (a) Contrôles de la plage des servomoteurs. La chaîne de pilotage cyclera les servomoteurs des gouvernes afin de vérifier la course de déplacement, le fonctionnement correct des transducteurs de réaction, etc. Les vitesses des servomoteurs ne seront pas testées parce que les réponses peuvent être lentes à ce stade parce que le fluide hydraulique sera froid (des tests de vitesse peuvent être effectués pendant les tests de la "première ligne"). (b) Contrôle du manche et des pédales de direction. Le pilote fera subir des cycles au manche et aux pédales alors que la chaîne de pilotage contrôle les plages complètes d'entrée. Cela sera exécuté par les modules TPV. (c) Contrôles des alimentations. Le pilote coupera les alimentations individuelles de la chaîne de pilotage une à la fois afin de tester le fonctionnement correct du matériel de consolation dans les OCV, UDMA, etc. Achèvement des tests A l'achèvement des tests interactifs du pilote, le module TPV sera coupé comme protection contre son fonctionnement en vol. Le fonctionnement du bouton de remise à zéro de la chaîne de pilotage provoquera alors l'entrée de tous les modules de calcul dans le logiciel résidant en vol (LRV). Le logiciel de test de première ligne résidera aussi avec le logiciel TPV. Le test de première ligne sera exécuté si on appuie sur le bouton TPV (à la place du bouton remise à l'état initial) à l'achèvement des tests interactifs. Choix du processeur Il y a trois options possibles pour le processeur utilisé dans les modules de calcul (a) un microprocesseur à vocation multiple tel que les microprocesseurs dits 68008 ou Z8002, etc. (b) un processeur spécialisé à haute vitesse tel que le modèle dit Texas TMS 320 ou Fujitsu MB8764. (c) un processeur personnalisé ou semi-personnalisé conçu spécifiquement. On suppose l'utilisation d'un jeu d'instructions spécialisées de commande (JIS) tel que celui décrit ultérieurement. Dans l'une ou l'autre des deux premières options, le processeur provoquera l'émulation d'un processeur JIS les lois de commande seront écrites dans le JIS qui subira une interprétation par le prpcesseur au moment du fonctionnement afin de produire des appels pour l'ensemble de routes prédéfinies du noyau. A première vue, cela apparaît impliquer un temps système important tant en matière d'impératifs de mémoire que de temps de traitement. Cependant, en général, le programme pour chaque module est suffisamment petit pour que les impératifs de mémoire soient minimaux dans tous les cas. Une certaine pénalité en matière de matériel peut être impliquée si une mémoire morte (ROM) séparée est utilisée pour les routines des jeux d'instructions : cela peut être considéré comme souhaitable pour des raisons d'intégrité. Le temps système pour la durée de traitement ne doit pas non plus être important car la majeure partie des instructions impliquent une proportion importe tante d'arithmétique. Processeurs à vocation multiple I1 existe de nombreux processeurs 16 bits à vocation multiple qu'on pourrait utiliser à l'intérieur d'un module. Leurs avantages sont leur disponibilité et la facilite d'utilisation;' cependant, is sont limités dans leurs performances. Les modèles 68008 et Z8002 sont les processeurs particuliers correspondant le mieux aux impératifs et présentent des performances très similaires pour cette application. Cependant, ces performances peuvent être tout juste convenables. Bien qu'on pourrait théoriquement partager les lois de commande en segments plus petits et utiliser davantage de modules, le gain serait compensé par les retards supplémentaires dus au plus grand nombre de communications inter-modules. Un problème soulevé par les processeurs à vocation multiple est l'intégrité. L'utilisation de versions militaires garantit la qualité de la fabrication mais non l'intégrité de la réalisation. Les processeurs comportent des jeux d'instructions puissants et il serait tentant de les utiliser pour optimiser le codage du JIS. Cependant, de manière à être capable de valider la mise en oeuvre du JIS à un niveau élevé d'intégrité, il est souhaitable d'utiliser un sous-ensemble aussi petit que possible du jeu d'instructions du processeur, évitant dans la mesure du possible les interruptions et les drapeaux qu'on considère comme les domaines les moins fiables. Processeurs à haute vitesse Un certain nombre de processeurs à haute vitesse font maintenant leur apparition sur le marché, étant conçus avant tout pour le traitement des signaux et sont plus proches de l'architecture idéale d'un processeur AMPS. Le modèle TMS 320 est un exemple particulièrement approprié. L'architecture du processeur est très semblable à celle d'un système en tranche, ayant tous les avantages mais contenu dans un ensemble supporté facilement. I1 utilise un matériel pour mettre en oeuvre de nombreuses fonctions que les microprocesseurs plus généraux à 16 bits exécutent en logiciel, c'est-à-dire que dans l'ensemble se trouve un multiplicateur de matériel capable d'exécuter les multiplications dans le cycle de 1 200 ns (+ 200 ns pour le déclenchement). Le processeur est aussi intérieurement une vraie machine à 32 bits son unité arithmétique et logique (UAL) étant tout à fait capable de supporter une arithmétique de précision double à 32 bits. Le jeu d'instructions du modèle TMS 320 doit être capable de produire une émulsion JIS qui se montera facilement dans les 3K d'une mémoire morte sur puce. Cela peut présenter le grand avantage de personnaliser la puce comme machine JIS. L'inconvénient de ce type particulier de puce est que, à cause de sa nature de spécialiste, elle n'a pas été utilisée très souvent et par conséquent, la connaissance de sa fiabilité n'est pas assurée. Processeur personnalisé/semi-personnalisé I1 y a deux variantes à l'utilisation des processeurs existants fonctionnant sur émulation JIS (a) personnaliser un processeur existant par microcodage du JIS comme jeu d'instructions. (b) Concevoir un nouveau processeur spécifiquement pour la mise en oeuvre du JIS. La solution (a) apportera quelque amélioration de la vitesse mais un modèle Z8002, personnalisé, par exemple, restera presque aussi rapide qu'un TMS 320 faisant passer une émulsion. L'un des objectifs du passage à une puce personnalisée est d'améliorer l'intégrité par une conception soignée. Dans ce cas, il y aurait une faible amélioration car l'intégrité est limitée par la conception existante. La tâche de conception sera difficile et croûteuse, avec un très faible gain. La seconde solution, soulignée en (b), est beaucoup plus prometteuse; de fait, il s'agit d'une extension naturelle du jeu personnalisé puce/puce de communications. La puce pourrait être conçue pour avoir la quantité minimum de logique nécessaire pour le passage du JIS à son mode naturel, avec la majeure partie des caractéristiques JIS (telles que la saturation) incorporées directement dans le silicium. La tâche de conception doit être plus simple en matière d'intégrité, et la possibilité de test au stade de la conception doit conduire à une intégrité élevée. La vitesse du processeur dépendra évidemment de la technologie choisie, mais elle doit être aussi bonne que celle des processeurs de signaux existants. Le coût de la fabrication d'un tel processeur sera élevé, mais il en sera de même des gains. Processeur Pour une application EFA, les processeurs courants à vocation multiple ont rarement des performances convenables. L'utilisation d'un processeur rapide de signaux augmentera la vitesse de traitement au point où elle ne domine plus les retards totaux du système; les retards dus à 1'UDMA et aux communications asynchrones étant maintenant du même ordre. En particulier, le TMS 320 a l'avantage qu'il a déjà été utilisé dans 1'UDMA, pour le système de commande EAP; cette expérience doit apporter la confiance dans son intégrité. I1 est donc recommandé au moment présent. A plus long terme, un processeur personnalisé peut apporter des avantages et a faisabilité doit être examinée. Répartition des lois de commande La répartition d'un jeu de lois de commande a été faite pour satisfaire les points suivants (a) les signaux nécessitant un retard minimum ne doivent pas être retardés par ceux pour lesquels un retard plus grand n'est pas aussi déterminant. (b) Chaque module doit contenir, si possible, un jeu simple et facilement identifiable de commandes. I1 n'est pas possible de considérer la répartition des lois de commande en l'isolant de la vitesse de traitement et des temps requis pour le débit des signaux. Les divisions représentées ici pour les modules concernent le traitement TMS 320 et un temps cible d'une durée du débit de 3 ms pour le taux de tangage entre gyro et servomoteur. Les lois de commande et les dispositifs de gestion des défaillances ont été répartis entre les modules suivants (a) Tangage (figure 8) - contient les trajets de signaux des réactions de l'axe primaire de tangage, (b) Roulis (figure 9) - contient les trajets de signaux des réactions de l'axe primaire de roulis et les sort vers les modules de tangage et de lacet pour les combiner dans les signaux d'entraînement des servomoteurs. (c) Lacet/direction du nez (figure 10) - contient les trajets de signaux des réactions de l'axe primaire de lacet. (d) Commandes du pilote (figure 11) - contient le conditionnement initial des entrées de commande du pilote avant de les appliquer au module approprié de commande d'axe. Des entrées supplémentaires qui n'ont pas un tel temps de demande et de tels critères d'itération pourraient être traitées par ce module. (e) Entrées/bord d'attaque (figure 12) - contient les trajets de tous les signaux fournissant une entrée directe pour la commande de ces surfaces. On suppose que l'angle d'entrée et du plan antérieur a été consolidé au module de moniteur (d) avant ce stade, on suppose que CAS est simplex. (f) Moniteur de réaction (figure 13) - ce module constitue une partie importante de la gestion des défaillances du système. I1 contient les processeurs de contrôle du dispositif de décision en redondance majoritaire pour les réactions des servomoteurs et fournit des réactions à boucle intérieure et extérieure consolidées sur sa propre branche. I1 signale aussi toutes les pannes détectées au module et fournit une commande à "sécurité positive" s'il détecte un défaut dans sa propre branche. (g) Données aérodynamiques/gains (figure 14) - Ce module fournit des facteurs de gain aux autres modules, au lieu des modules calculant leurs propres gains programmés. Les gains sont calculés par "tracé sur carpette" ou "tables à consulter", en travaillant à partir de données consolidées. (h) TPV - Celui-ci est utilisé pour coordonner les tests prévol et de première ligne. I1 peut également s'avérer nécessaire d'avoir un module de pilote automatique. L'architecture du système permet un vaste choix de temps de débit des signaux, en fonction de la répartition. I1 peut par conséquent s'avérer souhaitable à l'avenir de mettre les commandes du pilote sur les modules appropriés de commande d'axe dans le but d'utiliser un module de moins. Cependant, cela augmentera les temps de débit des signaux de réaction du mouvement de l'avion. Les calculs de temps sont basés sur une mise en oeuvre d'un processeur Z8002 fonctionnant à 8 MHz; un processeur en variante, le TMS 320, est supposé être plus rapide selon un facteur égal à 10. On suppose que le filtrage structurel est effectué dans 1'UDMA. Le concept JIS représente une approche matériel/logiciel intégrée pour le calcul déterminant en vol qui a pour objectif de réduire radialement le processus du logiciel en termes de codage et de validation - le problème principal des systèmes courants à intégrité élevée. La capacité supplémentaire de traitement apportée par l'architecture à un processeur multiple AMP fournit une opportunité idéale pour la spécification d'un nouveau langage de programmation qui est axé directement sur le travail des lois de commande. L'un des principaux problèmes impliqués jusqu'ici dans le logiciel des lois de commande est que, typiquement, la conception de l'algorithme fut entreprise par une équipe différente de celle faisant le codage de l'ordinateur. Cela a non seulement provoqué une augmentation importante des coûts, mais a également présenté des problèmes de calendrier lorsque le logiciel devait être. modifié. I1 y a eu aussi le problème que, pour chaque processeur nouveau utilisé dans l'environnement de commande, un nouveau groupe d'experts en logiciel fut nécessaire pour coder les lois de commande. Inhérent à tout processus global fut l'effort considérable impliqué dans la documentation et la validation. Une considération majeure dans la conception initiale du jeu d'instructios de commande (JIS) fut l'idée de limiter le rôle des experts en logiciel et de laisser aux concepteurs de commande les codages jusqu'à leurs propres algorithmes. Pour y parvenir, on a évidemment besoin de définir un langage qui est non seulement d'un niveau élevé approprié de sorte que le concepteur ne doit pas avoir un programmeur expert, mais également d'un faible niveau approprié pour être simple, pour passer rapidement, pour être facile à mettre en oeuvre sur n'importe quel microprocesseur, et éventuellement, pour former le jeu d'instructions pour un micro-ordinateur à haute intégrité, spécialisé. La modularité est un élément clé dans le concept AMPS. En particulier, il y a des cartes modulaires de calcul qui se répartissent en sous-sections fonctionnelles de traitement E/S. Toutes les connexions au processeur sont mappées en mémoire et, par conséquent, la connaissance du travail de ces zones n'est pas demandée au codeur de logiciel. En ce qui concerne le matériel, peut importe Ainsi, la philosophie à la base du JIS est la suivante 1. Simplifier le codage initial des lois de commande; 2. Réduire le calendrier impliqué dans la modification des lois à une date ultérieure; 3. Réduire le coût de la fabrication du produit final; et 4. Permettre au concepteur de commande d'écrire/ modifier son propre logiciel dans un environnement qui est indépendant de la spécification du logiciel. Le langage de c par des organigrammes continus de signaux - composés d'un petit nombre d'éléments constituants, par exemple addition, soustraction, intégration, consultation, etc. - qui peuvent être traduits directement dans le JIS par le concepteur luimême. 2. Les interactions entre chaque instruction sont minimales car aucun drapeau n'existe dans le système et, donc, le programmeur n'a qu'à se préoccuper du fonctionnement évident de chaque instruction. 3. Les branchements et les sauts àl'intérieur du logiciel ne sont pas permis. Au lieu d'exécuter certaines instructions pendant une certaine partie du temps, comme cela est normal dans les langages de haut niveau ou le code machine, le JIS exécute toujours toutes les instructions, le comportement du programme étant déterminé par la façon avec laquelle la donnée circule dans le logiciel. Cette technique facilite la vérification de toutes les fonctions nécessaires du logiciel car il n'y a aucune structure d'arbre complexe dont il faut tenir compte. A l'intérieur du JIS, il y a qu'un type de donnée, représenté par un mot à 32 bits. Celui-ci est toujours accédé indirectement par une adresse, actuellement définie comme étant de 16 bits, mais cela pourrait être étendu, le cas échéant. Une constante est traitée exactement de la même façon qu'une variable dans le logiciel, la seule différence étant que les adresses de 'constante" seront toujours maintenues en mémoire morte alors que des adresses variables le seront dans une mémoire à accès direct. Une certaine considération a été consacrée à la possibilité de fixer la longueur des blocs des instructions, mais bien que cela soit souhaitable, cela ne sera fait que si la capacité de la mémoire ne soulève pas un problème. Si cela se faisait, alors le travail d'un séquenceur de programme serait réduit à celui d'un compteur, et aucune consultation ne serait requise pour calculer son incrément. Les 32 bits utilisés pour chaque mot de donnée sont répartis comme suit 1 bit pour le signe. 15 bits pour des valeurs avant le point décimal. 16 bits pour des valeurs après le point décimal. On espère que cette technique permettra de résoudre la majorité des problèmes de bouchage impliqués dans les algorithmes de commande et, en même temps, d'augmenter la précision des calculs. Comme aucun drapeau ne se produit à l'inté- rieur du JIS, le programmeur n'a aucun moyen pour traiter des débordements, mais ce problème est surmonté en contraignant toutes les variables à saturation de la même manière que dans un système analogique. La présente invention n'est pas limitée aux exemples de réalisation qui viennent d'être décrits, elle est au contraire susceptible de modifications et de variantes qui apparaîtront à l'homme de l'art. REVENDICATIONS 1 - Système de commande informatique pour commander une multitude de servomoteurs, par exemple une série de servomoteurs de commande de vol à bord d'un avion, le système de commande informatique comprenant une multitude de servomoteurs et contrôlant le fonctionnement des servomoteurs, et un système informatique connecté de manière à recevoir une information de contrôle en provenance des unités d'entraînement et de contrôle afin d'en commander le fonctionnement, le système informatique comportant une multitude de modules pouvant exécuter les fonctions actives des lois de commande associées à la commande convenable des servomoteurs, par exemple, les calculs sur l'attitude de l'avion telle que le tangage, le roulis et le lacet, chaque module de cette sorte comprenant une unité de transmission de données connectée à une ligne respective de diffusion de données sérielles qui est à son tour connectée à une unité respective de réception de données dans chaque autre module, d'où il résulte que la communication entre les modules est obtenue par l'un quelconque des modules diffusant des messages asynchrones de données sur sa propre ligne de diffusion de données pour que ce message de données soit reçu par un autre module quelconque en ayant besoin. 2 - Système de commande informatique, en particulier système informatique de commande de vol, comprenant une série de modules informatiques fonctionnant en parallèle et de façon asynchrone pour exécuter des parties respectives d'un algorithme de commande globale pour une série d'articles à commander, chaque module informatique ayant un point de transmission de données connecté via une ligne de diffusion à un point d'entrée respectif de chaque autre module informatique de sorte que la communication entre modules s'effectue par l'un quelconque des modules diffusant des messages de données asynchrones sur la ligne de diffusion pour que les messages soient reçus par un quelconque autre module en ayant besoin.