Brevet FR3025617A1 — publié le 20160311

Architecture bi-voies DOMAINE TECHNIQUE GENERAL L'invention concerne le domaine des systèmes de contrôle de vol d'aéronef. Elle a plus particulièrement pour objet un procédé de commutation entre deux unités de traitement ou calculateurs constituant une architecture bi-voies d'un tel système. ETAT DE LA TECHNIQUE Les systèmes de contrôle de vol embarqués équipant les aéronefs tels que les avions ou les hélicoptères existants exécutent des fonctions de commande et de régulation du moteur de l'aéronef assurant le bon fonctionnement de celui-ci. De telles fonctions sont critiques pour la sécurité des passagers. De tels systèmes doivent donc être résistants aux pannes. Pour cela, les systèmes de contrôle de vol existants comprennent généralement deux unités de traitement ou calculateurs, chacune capable d'assurer le bon fonctionnement du moteur. Un tel système constitue ainsi une architecture à deux voies dans laquelle chaque voie est capable d'assurer l'exécution desdites fonctions critiques en cas de panne de l'autre voie. Parmi ces deux voies, le contrôle du moteur est généralement confié à la voie présentant le meilleur état de santé, c'est-à-dire le moins de pannes ou les pannes présentant le degré de gravité le plus faible. Cette voie est appelée voie active. Afin d'exécuter des fonctions de commande et de régulation du moteur, chacune des voies est susceptible de commander au moins un actionneur. Ces actionneurs peuvent tomber en panne. Lorsqu'un ou plusieurs actionneurs de la voie active sont en panne, celle-ci peut ne plus être capable d'assurer correctement le contrôle du moteur. Si l'autre voie, dite passive, est dans un état de santé moins bon que celui de la voie active, elle n'est alors pas non plus en mesure d'assurer correctement le contrôle du moteur. Ainsi aucune des deux 2 3025617 voies n'étant capable d'assurer correctement le contrôle du moteur, les fonctions critiques du système de vol peuvent alors ne plus être assurées. Il existe donc un besoin d'un procédé permettant à la voie active d'assurer correctement le contrôle du moteur malgré la défaillance d'au moins un de ses 5 actionneurs. PRESENTATION DE L'INVENTION La présente invention se rapporte ainsi selon un premier aspect à un 10 procédé de commutation mis en oeuvre par une première unité de traitement, dite unité de traitement locale, d'un système de contrôle de vol d'un aéronef comprenant au moins un moteur, ladite unité de traitement locale étant configurée pour commander au moins un actionneur, dit actionneur local, de sorte à contrôler le moteur de l'aéronef, et 15 étant susceptible d'être connectée à au moins un capteur local et à une deuxième unité de traitement, dite unité de traitement opposée, configurée pour commander au moins un actionneur opposé et être connectée à au moins un capteur opposé, ledit procédé comprenant des étapes de : 20 - envoi à l'unité de traitement opposée de données d'acquisitions relatives à l'au moins un capteur local et de données d'actionneur relatives à l'au moins un actionneur local, - réception en provenance de l'unité de traitement opposée de données d'acquisitions relatives à l'au moins un capteur opposé et de données 25 d'actionneur relatives à l'au moins un actionneur opposé, - réception d'une donnée de santé relative à l'état de santé de l'unité de traitement opposée, dite donnée de santé opposée, - détermination d'une donnée de santé relative à la santé de ladite unité de traitement locale, dite donnée de santé locale, 30 - commutation de ladite unité de traitement locale d'un premier état à un deuxième état, en fonction de ladite donnée de santé opposée reçue et de ladite donnée de santé locale déterminée, lesdits états étant parmi un état actif dans lequel l'unité de traitement locale assure le contrôle du moteur de l'aéronef, un état passif dans lequel l'unité de 3 3025617 traitement locale n'assure pas le contrôle du moteur de l'aéronef et un état esclave dans lequel l'unité de traitement locale cède à l'unité de traitement opposée la commande desdits actionneurs locaux pour le contrôle du moteur de l'aéronef. 5 Un tel procédé permet à chaque unité de traitement d'avoir une image complète du système global, y compris des actionneurs et capteurs connectés à l'unité de traitement opposée, afin de pouvoir assurer correctement le contrôle du moteur malgré la défaillance d'un actionneur local. Une unité de traitement incapable de contrôler le moteur de l'aéronef peut ainsi donner un accès à ses 10 actionneurs à l'autre unité de traitement qui est dans un état actif, afin que le système de contrôle de vol puisse assurer le contrôle du moteur malgré une ou plusieurs défaillances des actionneurs de l'unité de traitement active. L'unité de traitement opposée et l'unité de traitement locale étant connectées par l'intermédiaire d'une part d'une première liaison numérique 15 bidirectionnelle et d'autre part d'une deuxième liaison numérique bidirectionnelle et l'unité de traitement opposée transmettant une donnée de santé opposée sur chacune des liaisons, l'étape de réception d'une donnée de santé opposée du procédé selon le premier aspect peut comprendre une étape de réception d'une première donnée de santé 20 opposée sur la première liaison et d'une deuxième donnée de santé opposée redondante sur la deuxième liaison, une étape de vérification de la cohérence desdites première et deuxième données de santé reçues, et une étape de détermination de ladite donnée de santé opposée transmise en fonction de ladite étape de vérification. 25 Ceci permet de renforcer la capacité de détection par le système des altérations des données échangées entre les unités de traitement et minimise ainsi la probabilité de défaillance du système de contrôle de vol. L'étape de détermination de la donnée de santé opposée transmise peut comprendre, lorsque lesdites première et deuxième données de santé reçues ne 30 sont pas cohérentes, une étape de consolidation au cours de laquelle la donnée de santé opposée transmise est déterminée à partir des données reçues sur au moins deux trames successives. Ceci permet de minimiser le risque d'erreur lors de la détermination de la donnée de santé opposée transmise lorsque les données transmises sur les 4 3025617 deux liaisons sur une première trame sont pas cohérentes et ne permettent pas de déterminer la donnée de santé transmise de manière sûre. Afin de s'assurer que les données reçues n'ont pas été corrompues au cours de leur transmission, l'étape de réception de donnée de santé opposée du 5 procédé selon le premier aspect peut comprendre une étape de vérification de l'intégrité de ladite donnée de santé reçue. L'étape de détermination d'une donnée de santé locale du procédé selon le premier aspect peut comprendre une étape de diagnostic de l'état de santé relatif au matériel (« hardware ») et au logiciel (« software ») de ladite unité de 10 traitement locale. Ceci permet d'obtenir une donnée de santé permettant de diagnostiquer l'ensemble des pannes pouvant affecter la capacité de l'unité de traitement locale à assurer le contrôle du moteur. L'étape de commutation du procédé selon le premier aspect peut 15 comprendre : - une étape de détermination, à partir de la donnée de santé locale, d'une donnée d'état relative à l'état de ladite unité de traitement locale et d'une donnée de statut de santé de l'unité de traitement locale relative à la capacité de l'unité de traitement locale à assurer le contrôle du moteur, et 20 - une étape de commutation de ladite unité de traitement locale dans l'état esclave : - lorsque la donnée d'état indique que l'unité de traitement locale est dans un état passif et, - lorsque la donnée de statut de santé indique un statut dans 25 lequel : ^ l'unité de traitement locale est capable de communiquer avec l'unité de traitement opposée, par exemple si au moins une des deux liaisons numériques bidirectionnelles permet d'assurer des communications entre l'unité de 30 traitement locale et l'unité de traitement opposée, ^ l'unité de traitement locale est incapable d'assurer le contrôle du moteur, ^ et l'unité de traitement locale est capable de commander les actionneurs locaux. 5 3025617 Ceci permet de s'assurer, avant de passer dans l'état esclave, que l'unité de traitement n'est pas en train d'assurer le contrôle du moteur, qu'elle n'est pas capable d'assurer le contrôle du moteur à la place de l'autre unité de traitement, et que les pannes qui l'affectent ne l'empêchent pas de donner accès à ses 5 actionneurs à l'autre unité de traitement. Selon une caractéristique avantageuse et non limitative, l'étape de commutation du procédé selon le premier aspect comprend : - une étape de détermination, dans laquelle ladite unité de traitement locale détermine à partir desdites données de santé locale et opposée que son état de 10 santé est meilleur que celui de l'unité de traitement opposée, - une étape d'attente dans laquelle ladite unité de traitement locale attend que l'unité de traitement opposée passe dans l'état passif, - une étape de commutation de l'unité de traitement locale dans l'état actif. Ceci permet d'éviter que le système de contrôle de vol ne se retrouve 15 dans une situation dans laquelle les deux unités de traitement seraient actives en même temps et risqueraient de transmettre des ordres contradictoires à leurs actionneurs. La présente invention se rapporte selon un deuxième aspect à un produit programme d'ordinateur comprenant des instructions de code pour l'exécution 20 d'un procédé de commutation selon le premier aspect lorsque ce programme est exécuté par un processeur. La présente invention se rapporte selon un troisième aspect à une unité de traitement d'un système de contrôle de vol d'un aéronef comprenant au moins un moteur et configurée pour commander au moins un actionneur, dit actionneur 25 local, de sorte à contrôler le moteur de l'aéronef, ladite unité de traitement, dite unité de traitement locale étant susceptible d'être connectée à au moins un capteur local et à une deuxième unité de traitement, dite unité de traitement opposée, étant configurée pour commander au moins un actionneur opposé et être connectée à au moins un capteur opposé, et étant 30 caractérisée en ce qu'elle comprend : - des moyens pour envoyer à l'unité de traitement opposée des données d'acquisitions relatives à l'au moins un capteur local et des données d'actionneur relatives à l'au moins un actionneur local, 6 3025617 - des moyens pour recevoir en provenance de l'unité de traitement opposée des données d'acquisitions relatives à l'au moins un capteur opposé et des données d'actionneur relatives à l'au moins un actionneur opposé, - des moyens pour recevoir une donnée de santé relative à l'état de santé de 5 l'unité de traitement opposée, dite donnée de santé opposée, - des moyens pour déterminer une donnée de santé relative à la santé de ladite unité de traitement locale, dite donnée de santé locale, - des moyens pour commuter ladite unité de traitement locale d'un premier état à un deuxième état, en fonction de ladite donnée de santé opposée reçue et de 10 ladite donnée de santé locale déterminée, lesdits états étant parmi un état actif dans lequel l'unité de traitement locale assure le contrôle du moteur de l'aéronef, un état passif dans lequel l'unité de traitement locale n'assure pas le contrôle du moteur de l'aéronef et un état esclave dans lequel l'unité de traitement locale cède à l'unité de traitement 15 opposée la commande desdits actionneurs locaux pour le contrôle du moteur de l'aéronef. La présente invention se rapporte selon un quatrième aspect à un système de contrôle de vol comprenant deux unités de traitement selon le troisième aspect. 20 De tels produit programme d'ordinateur, unité de traitement et système de contrôle de vol présentent les mêmes avantages que ceux évoqués pour le procédé selon le premier aspect. Les deux unités de traitement peuvent être connectées par l'intermédiaire d'une part d'une première liaison numérique bidirectionnelle et d'autre part d'une 25 deuxième liaison numérique bidirectionnelle, ladite deuxième liaison étant redondante avec la première liaison, et lesdites première et deuxième liaisons étant susceptibles d'être actives de façon concomitante. Un tel système présente une forte résistance aux pannes grâce à la redondance de ses unités de traitement et de ses moyens de communications 30 ainsi que par la minimisation du nombre de liaisons de communication, tout en réduisant son encombrement. Les première et deuxième liaisons peuvent être des liaisons CCDL (« Cross Channel Data Link »). 7 3025617 Une telle liaison permet notamment aux unités de traitement d'échanger des informations de santé plus complexes que celles échangées par l'intermédiaire des liaisons analogiques discrètes des systèmes connus tout en limitant le volume de câblage. 5 En cas de défaillances des première et deuxième liaisons, le système de contrôle de vol selon le quatrième aspect peut comprendre des moyens de communication de sauvegarde permettant d'assurer des échanges de données entre l'unité de traitement locale et l'unité de traitement opposée. Ceci permet d'éviter un aveuglement total du système bi-voies et une 10 coupure des communications entre les deux unités de traitement. Selon une variante de réalisation, les moyens de communication de sauvegarde du système de contrôle selon le quatrième aspect peuvent comprendre un réseau de capteurs ou d'actionneurs. Selon une autre variante de réalisation, les moyens de communication de 15 sauvegarde du système de contrôle selon le quatrième aspect peuvent comprendre un réseau sécurisé embarqué pour l'avionique, par exemple un réseau Ethernet redondant du type AFDX (« Avionics Full DupleX switched ethernet ») ou pAFDX. L'utilisation de tels réseaux pour échanger des informations entre les 20 unités de traitement permet d'augmenter le niveau de redondance des moyens de communication entre les unités de traitement et d'assurer la sûreté de fonctionnement du système de contrôle de vol sans pour autant nécessiter la mise en place de moyens de communication supplémentaires dédiés uniquement à la communication entre les unités de traitement. 25 PRESENTATION DES FIGURES D'autres caractéristiques et avantages apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation. Cette description sera donnée 30 en référence aux dessins annexés dans lesquels : - la figure 1 illustre schématiquement un système de contrôle de vol selon un mode de réalisation de l'invention; 8 3025617 - la figure 2 illustre schématiquement des moyens matériels destinés à établir deux liaisons CCDL entre deux unités de traitement d'un système de contrôle de vol selon un mode de réalisation de l'invention ; - la figure 3 illustre schématiquement la ségrégation physique de modules 5 CCDL de chaque unité de traitement d'un système de contrôle de vol selon un mode de réalisation de l'invention; - la figure 4 illustre schématiquement la ségrégation des moyens matériels d'une unité de traitement destinés à établir deux liaisons CCDL selon un mode de réalisation de l'invention ; 10 - la figure 5 représente le graphe des états des unités de traitement du système de contrôle de vol selon un mode de réalisation de l'invention. DESCRIPTION DETAILLEE 15 Un mode de réalisation de l'invention, concerne un procédé de commutation mis en oeuvre par une première unité de traitement 1, dite unité de traitement locale, d'un système de contrôle de vol, représenté en figure 1, d'un aéronef comprenant au moins un moteur. Le système de contrôle de vol comporte également une deuxième unité 20 de traitement 2, dite unité de traitement opposée. L'unité de traitement locale est susceptible d'être connectée à au moins un capteur local et à l'unité de traitement opposée, elle-même connectée à au moins un capteur opposé. Ces deux unités de traitement sont redondantes et peuvent chacune exécuter les fonctions de commande et de régulation du moteur de l'aéronef. Pour cela 25 chaque unité de traitement est configurée pour commander au moins un actionneur, de sorte à contrôler le moteur de l'aéronef. Les actionneurs pilotables par l'unité de traitement locale 1 sont appelés actionneurs locaux. Les actionneurs pilotables par l'unité de traitement opposée sont appelés actionneurs opposés. Le système tel qu'illustré en figure 1 constitue ainsi une architecture bi- 30 voies comprenant une voie A et une voie B. Les unités de traitement 1 et 2 peuvent être des processeurs d'un même système informatique multiprocesseurs comportant plusieurs processeurs. Afin de renforcer la résistance du système de contrôle de vol aux agressions externes et d'éviter qu'un unique évènement localisé ne puisse mettre hors service les 9 3025617 deux unités de traitements 1 et 2, les deux voies peuvent être installées à distance l'une de l'autre dans des boitiers séparés. Dans une telle configuration, les unités de traitement ne sont pas des coeurs d'exécution intégrés au sein d'un unique processeur. 5 Le système comprend également des moyens de communication permettant de connecter les deux unités de traitement pour permettre l'échange de données essentielles au bon fonctionnement de chacune des unités de traitement telles que des informations sur l'état de santé de l'unité de traitement opposée. 10 Dans une variante de réalisation, ces moyens de communication sont configurés pour établir une première liaison numérique bidirectionnelle 3 et une deuxième liaison numérique bidirectionnelle 4 entre la première unité de traitement 1 et la deuxième unité de traitement 2. Un tel système ne comporte aucun lien discret entre les deux unités de traitement, ce qui permet de limiter la 15 complexité de son câblage et la probabilité qu'un des liens de communication tombe en panne. La deuxième liaison 4 est redondante avec la première liaison 3 afin d'assurer la communication entre les deux unités de traitement en cas de défaillance de la première liaison 3, et réciproquement. Une telle redondance 20 garantit, du point de vue de l'échange d'informations entre les deux unités de traitement, un bon niveau de sûreté. De plus lesdites première et deuxième liaisons sont susceptibles d'être actives de façon concomitante. Ainsi, contrairement aux systèmes dans lesquels la liaison redondante n'est utilisée qu'en cas de défaillance de la première 25 liaison, le système de contrôle de vol peut utiliser la première liaison 3 et la deuxième liaison 4 en même temps en fonctionnement normal, c'est-à-dire en l'absence de défaillance d'une des deux liaisons, et peut mettre à profit l'utilisation concomitante de ces deux liaisons pour vérifier l'absence de corruption des données échangées entre les deux unités de traitement. 30 Les première et deuxième unités de traitement 1 et 2 peuvent utiliser un protocole pour communiquer entre elles par l'intermédiaire des deux liaisons 3 et 4, par exemple parmi les protocoles Ethernet IEEE 802.3, HDLC, SDLC, ou tout autre protocole disposant d'une fonction de détection ou correction d'erreur. Une liaison Ethernet permet notamment d'assurer de hautes performances, une 10 3025617 grande robustesse environnementale, notamment vis-à-vis de la résistance à la foudre et de la Compatibilité Electro-Magnétique (« CEM ») et une haute robustesse fonctionnelle grâce à la mise en oeuvre de mécanismes de contrôle d'intégrité de données et de contrôle de flux. De plus le protocole Ethernet est un 5 standard industriel cohérent avec les technologies de communication avionique, tel que AFDX (« Avionics Full DupleX switched ethernet ») ou pAFDX, et de maintenance. Les première et deuxième liaisons peuvent être des liaisons CCDL (« Cross Channel Data Link »). Une telle liaison permet de synchroniser chaque 10 applicatif avec une précision inférieure à cent microsecondes. Une telle liaison permet également, au lieu d'échanger des discrets comme dans les systèmes connus, d'échanger des informations de santé construites par le matériel (« hardware ») ou le logiciel (« software »), des informations utiles au système (acquisition, statuts,...) et des données fonctionnelles de système d'exploitation 15 (OS) ou de système d'application (AS). De telles liaisons CCDL entre les deux unités de traitement A et B sont représentées en figure 2. Chaque unité de traitement 1,2 comprend un système 5a, 5b, comportant un premier module CCDL (CCDLA) 6a, 6b pour établir la première liaison CCDL 3 et un deuxième module CCDL (CCDLB) 7a, 7b pour 20 établir la deuxième liaison CCDL 4. Un tel système peut se présenter sous la forme d'un système sur puce (SoC, « system on a chip ») ou être constitué d'un microprocesseur et de périphériques implémentés dans des boitiers séparés ou dans une carte FPGA. Chaque module CCDL est relié à l'interface entrée/sortie de son boitier par une couche physique. Une telle couche peut par exemple 25 comprendre une interface matérielle Phy 8a, 8b, 8c, 8d et un transformateur 9a, 9b, 9c, 9d tel que représenté en figure 2. Comme illustré en figure 3, les modules CCDL de chaque unité de traitement peuvent être ségrégés physiquement en étant disposés sur le système 5a, 5b en des localisations distinctes et éloignées les unes des autres, par 30 exemple en les disposant chacun à un coin d'un système sur puce. Ceci permet de réduire la probabilité de panne commune en cas d'altération de type SEU (« Single Event Upset ») ou MBU (« Multiple Bit Upset »). Selon une première variante chaque système 5a, 5b est alimenté par une alimentation séparée. Selon une deuxième variante le système comprend une 11 3025617 alimentation 15 (« power supply ») commune à l'ensemble du système sur puce. Chaque système sur puce peut être alimenté par deux signaux d'horloges distincts 11 et 12, comme représenté en figure 4. Ainsi, bien qu'ils ne soient pas alimentés de manière indépendante, les modules CCDL de chaque unité de 5 traitement peuvent être alimentés par des horloges indépendantes, ce qui renforce la résistance aux pannes du système sur puce en empêchant qu'une panne d'horloge d'un des modules CCDL puisse affecter l'autre module CCDL. Les modules CCDL de chaque unité de traitement peuvent être synchronisés grâce à un mécanisme d'horloge temps réel local (HTR ou RTC 10 « Real time clock ») 10a, 10b tel que représenté en figure 2 et à un mécanisme de synchronisation tel qu'un mécanisme à fenêtre de synchronisation. Ainsi en cas de perte de la synchronisation, chaque unité de traitement fonctionne grâce à son horloge locale puis se synchronise à nouveau à la réception d'un signal valide. Le mécanisme d'horloge local est programmable par l'applicatif et sa 15 programmation est protégée contre les altérations de type SEU (« Single Event Upset ») ou MBU (« Multiple Bit Upset »). Les liaisons CCDL peuvent néanmoins continuer à fonctionner même en l'absence de synchronisation ou en cas de perte d'une horloge. Le système peut en outre comprendre des moyens de communication de 20 sauvegarde permettant d'assurer des échanges de données entre les première et deuxième unités de traitement et utilisés uniquement en cas de défaillances des première et deuxième liaisons, pour éviter une coupure des communications entre les unités de traitement. Dans un premier mode de réalisation illustré en figure 1, ces moyens de 25 communications de sauvegarde peuvent comprendre un réseau de capteurs ou d'actionneurs 13. Un tel réseau de capteurs ou d'actionneurs peut à titre d'exemple être un réseau de capteurs ou actionneurs intelligents (« smartsensor, smart-actuator »). Chaque unité de traitement peut alors être connectée à ce réseau 13 par l'intermédiaire d'un bus du type RS-485 permettant de 30 transmettre des informations non plus de manière analogique mais numérique. Dans un second mode de réalisation illustré en figure 1, ces moyens de communication de sauvegarde comprennent un réseau sécurisé embarqué pour l'avionique 14. Un tel réseau sécurisé embarqué peut à titre d'exemple être un réseau Ethernet redondant tel qu'AFDX (« Avionics Full DupleX switched 12 3025617 ethernet ») ou pAFDX. Un tel réseau fournit des moyens de partage des ressources, de ségrégation des flux ainsi que le déterminisme et la disponibilité requise pour les certifications aéronautiques. Les signaux numériques transmis entre les unités de traitement pouvant 5 être sensibles à des perturbations, des mécanismes de contrôle d'intégrité et de contrôle de cohérence des données transmises entre les deux unités de traitement distantes peuvent être mis en place. Ainsi chaque unité de traitement peut comprendre des moyens pour vérifier l'intégrité des données reçues. 10 Afin de vérifier l'intégrité des données reçues, les différents champs de chaque trame reçue peuvent être vérifiés, notamment dans le cas d'une liaison Ethernet les champs relatifs à l'adresse de destination, à l'adresse source, au type et à la longueur de la trame, aux données MAC et aux données de bourrage. Une trame peut être considérée comme non valide si la longueur de 15 cette trame n'est pas cohérente avec la longueur spécifiée dans le champ longueur de la trame ou si les octets ne sont pas entiers. Une trame peut également être considérée comme non valide si le contrôle de redondance (CRC, « Cyclic Redundancy Check ») calculé à la réception de la trame ne correspond pas au CRC reçu en raison d'erreurs dues par exemple, aux 20 interférences lors de la transmission. De plus, lorsque l'unité de traitement locale et l'unité de traitement opposée sont connectées par l'intermédiaire de deux liaisons bidirectionnelles, chaque unité de traitement peut comprendre des moyens pour vérifier suite à la transmission d'une donnée à la fois sur la première liaison et sur la deuxième 25 liaison, la cohérence des données reçues sur les deux liaisons qui doivent véhiculer les mêmes informations en l'absence de panne ou de corruption des trames transmises, et pour déterminer la donnée réellement transmise. Lorsque les données reçues sur les deux liaisons ne sont pas cohérentes, l'unité de traitement peut mettre en oeuvre une étape de consolidation au cours de laquelle 30 la donnée réellement transmise est déterminée à partir des données reçues sur au moins deux trames successives, éventuellement sur trois trames. Une telle consolidation peut également être réalisée en allongeant la période de temps qui sépare la réception de deux paquets de données Ethernet successifs, par exemple en fixant la longueur de cette période de temps à une durée plus grande 13 3025617 que la durée d'une perturbation électomagnétique. Ceci peut être mis en oeuvre en ajoutant un paramètre (« Inter Frame Gap ») fixant une telle période entre les paquets émis. Une telle mise en oeuvre peut permettre par exemple d'éviter la corruption de deux paquets Ethernet transmis de façon redondée. 5 Chacune des unités de traitement du système de contrôle de vol peut se trouver dans un état parmi les états suivants, tel que représenté dans le graphe d'état en figure 5 : ^ un état actif (« ACTIVE ») 15 dans lequel l'unité de traitement assure le contrôle du moteur de l'aéronef, 10 ^ un état passif (« PASSIVE ») 16 dans lequel l'unité de traitement n'assure pas le contrôle du moteur de l'aéronef mais exécute d'autres fonctions, par exemple de diagnostic, et peut éventuellement communiquer avec l'autre unité de traitement du système de contrôle, ^ un état de remise à zéro (« RESET ») 17 dans lequel l'unité de traitement 15 est inactive et n'exécute aucune fonction, ^ un état esclave (« SLAVE ») 18 dans lequel l'unité de traitement cède à l'autre unité de traitement la commande de ses actionneurs pour le contrôle du moteur de l'aéronef. Afin que chaque unité de traitement dispose d'une image complète du 20 système global, y compris des actionneurs et capteurs connectés à l'unité de traitement opposée, pour pouvoir assurer correctement le contrôle du moteur malgré la défaillance d'un actionneur local, le procédé de commutation mis en oeuvre par une unité de traitement locale comprend des étapes de : - envoi à l'unité de traitement opposée de données d'acquisitions relatives à 25 l'au moins un capteur local et de données d'actionneur relatives à l'au moins un actionneur local, - réception en provenance de l'unité de traitement opposée de données d'acquisitions relatives à l'au moins un capteur opposé et de données d'actionneur relatives à l'au moins un actionneur opposé. 30 De telles données d'acquisition relatives à un capteur peuvent à titre d'exemple dans le cas de capteurs de températures comprendre la température mesurée par le capteur. 14 3025617 De plus, afin de permettre à l'unité de traitement locale 1 de changer d'état parmi les quatre états décrits ci-dessus, le procédé de commutation comprend des étapes de : - réception d'une donnée de santé, tel qu'un statut, relative à l'état de 5 santé de l'unité de traitement opposée 2, dite donnée de santé opposée, - détermination d'une donnée de santé relative à la santé de ladite unité de traitement locale 1, dite donnée de santé locale, - commutation de ladite unité de traitement locale 1 d'un premier état à un deuxième état, en fonction de ladite donnée de santé opposée reçue et 10 de ladite donnée de santé locale déterminée, lesdits premier et deuxième états étant parmi les états actif, passif, remise à zéro et esclave décrits ci-dessus. La donnée de santé opposée reçue pouvant être sujette à des perturbations, l'étape de réception d'une donnée de santé opposée peut 15 comprendre une étape de vérification de l'intégrité de la donnée reçue. Par ailleurs des mécanismes de vérification de cohérence peuvent également être mis en oeuvre, la donnée de santé opposée pouvant être transmise de façon redondante sur les deux liaisons bidirectionnelles. L'étape de réception d'une donnée de santé opposée comprend alors une étape de 20 réception d'une première donnée de santé opposée sur la première liaison et d'une deuxième donnée de santé opposée redondante sur la deuxième liaison, une étape de vérification de la cohérence desdites première et deuxième données de santé reçues, et une étape de détermination de ladite donnée de santé opposée transmise en fonction de ladite étape de vérification. En variante, 25 la première donnée de santé opposée reçue sur la première liaison et la deuxième donnée de santé opposée reçue sur la deuxième liaison peuvent faire l'objet d'une vérification d'intégrité avant la vérification de leur cohérence. En cas d'incohérence des données reçues sur les deux liaisons, l'unité de traitement locale peut ignorer cette donnée de santé et attendre la transmission 30 d'une nouvelle donnée de santé opposée. En cas de réception de données incohérentes sur les deux liaisons lors de deux transmissions successives ou plus, l'unité de traitement locale peut retenir de manière conservative comme donnée de santé opposée la donnée reçue indiquant le plus mauvais état de santé de l'unité de traitement opposée si les données reçues lors de la première 15 3025617 transmission sont identiques à celles reçues lors des transmissions ultérieures. Sinon, la dernière donnée de santé reçue de manière cohérente est conservée tant qu'aucune nouvelle donnée de santé n'a été reçue de manière cohérente. Pour déterminer une donnée de santé locale ou opposée, l'unité de 5 traitement concernée réalise un diagnostic de l'état de santé relatif à ses éléments matériels et logiciels. Un tel diagnostic peut être établi à partir d'informations obtenues de différents moyens de surveillance (« monitoring ») ou de plusieurs registres. A titre d'exemple, un registre permet d'obtenir l'état de santé du matériel de l'unité de traitement et un autre registre permet d'obtenir 10 l'état de santé du logiciel de l'unité de traitement. Les données de santé déterminées en local ou transmises par l'unité de traitement opposée sont ainsi des données permettant la sélection d'une voie et l'établissement d'un diagnostic système complet. Elles peuvent notamment être des données de diagnostics CCDL, des données de statuts du système 15 d'exploitation ou des applicatifs, des données de diagnostics du matériel, notamment de capteurs ou d'actionneurs, des données de diagnostics fonctionnels réalisés par le logiciel, .... A partir d'une donnée de santé locale ou opposée, l'unité de traitement locale peut déterminer une donnée d'état indiquant l'état, actif, passif, esclave ou 20 remise à zéro, dans lequel se trouve l'unité de traitement locale ou opposée correspondante, et une donnée de statut de santé relative à la capacité de l'unité de traitement locale ou opposée à assurer le contrôle du moteur. Selon un mode de réalisation, chaque unité de traitement peut présenter un statut de santé parmi les quatre statuts suivants : 25 ^ un statut « GOOD » dans lequel l'unité de traitement ne présente aucune panne, ^ un statut « ACCEPTABLE » dans lequel l'unité de traitement présente certaines pannes qui ne l'empêcheraient cependant pas d'assurer correctement le contrôle du moteur, par exemple la casse d'un 30 transformateur d'une liaison CCDL ou la perte du signal d'horloge d'une seule liaison CCDL, ^ Un statut « SLAVE » dans lequel l'unité de traitement présente des pannes trop graves pour lui permettre d'assurer correctement le contrôle du moteur, par exemple une panne processeur, mais ne présente pas de 16 3025617 pannes matérielles qui l'empêcheraient de piloter ses actionneurs ou de communiquer avec l'unité de traitement opposée, ^ Un statut « BAD » dans lequel l'unité de traitement est incapable d'assurer correctement le contrôle du moteur et présente au moins une 5 panne matérielle empêchant l'unité de traitement de piloter ses actionneurs, par exemple une panne d'alimentation ou d'horloge affectant l'ensemble de l'unité de traitement ou une panne des deux liaisons CCDL. L'unité de traitement locale exécute à intervalle de temps régulier les étapes décrites ci-dessus de réception d'une donnée de santé opposée et de 10 détermination d'une donnée de santé locale. Afin de déterminer si elle doit changer d'état, l'unité de traitement locale détermine, à partir de la donnée de santé locale, une donnée d'état locale indiquant son état et une donnée de statut locale indiquant son statut de santé. De même l'unité de traitement locale détermine, à partir de la donnée de santé opposée, une donnée d'état opposée 15 indiquant l'état de l'unité de traitement opposée, et une donnée de statut opposée indiquant le statut de l'unité de traitement opposée. L'unité de traitement locale réalise ensuite une comparaison de son état de santé, indiqué par la donnée de statut locale, avec celui de l'unité de traitement opposée, indiqué par la donnée de statut opposée. 20 Si l'unité de traitement locale est dans un état actif et que son état de santé reste meilleur que celui de l'autre unité de traitement (CTL_REQ=1), l'unité de traitement reste dans un état actif et continue à assurer le contrôle du moteur. A titre d'exemple, l'état de santé de l'unité de traitement locale est meilleur que celui de l'unité de traitement opposée lorsque : 25 - l'unité de traitement locale présente le statut GOOD et l'unité de traitement opposée présente un statut parmi les statuts ACCEPTABLE, SLAVE et BAD, - l'unité de traitement locale présente le statut ACCEPTABLE et l'unité de traitement opposée présente un statut parmi les statuts SLAVE et BAD. Si l'unité de traitement locale est dans un état actif et que son état de 30 santé devient moins bon que celui de l'autre unité de traitement (CTL_REQ=O), l'unité de traitement locale commute dans un état passif et cesse d'assurer le contrôle du moteur qui est alors assuré par l'unité de traitement opposée. A titre d'exemple, l'état de santé de l'unité de traitement locale est moins bon que celui de l'unité de traitement opposée lorsque : 17 3025617 - l'unité de traitement locale présente le statut ACCEPTABLE et l'unité de traitement opposée présente le statut GOOD, ou - l'unité de traitement locale présente le statut SLAVE et l'unité de traitement opposée présente un statut parmi les statuts GOOD et ACCEPTABLE, ou 5 - l'unité de traitement locale présente le statut BAD et l'unité de traitement opposée présente un statut parmi les statuts GOOD et ACCEPTABLE. Si l'unité de traitement locale est dans un état passif et que son état de santé reste moins bon que celui de l'unité de traitement opposée (CTL_REQ=O), l'unité de traitement reste dans un état passif. 10 Si l'unité de traitement locale est dans un état passif et que son état de santé devient meilleur que celui de l'unité de traitement opposée (CTL_REQ=1), l'unité de traitement locale commute dans un état actif afin d'assurer le contrôle du moteur à la place de l'unité de traitement opposée. La commutation d'un état passif à un état actif peut passer par un état d'attente 19 dans laquelle l'unité de 15 traitement locale attend que l'unité de traitement opposée passe dans l'état passif (OPP_CH_STATE=O) avant de passer dans l'état actif et de prendre la main sur le contrôle du moteur. Ceci permet d'éviter que le système de contrôle de vol ne se retrouve dans une situation dans laquelle les deux unités de traitement seraient actives en même temps et risqueraient de transmettre des 20 ordres contradictoires à leurs actionneurs. L'unité de traitement peut rester dans un tel état d'attente 19 tant que l'unité de traitement opposée est active (OPP_CH_STATE=1). Depuis cet état, l'unité de traitement locale peut même retourner dans un état passif si l'état de santé de l'unité de traitement opposée est redevenu meilleur que l'état de santé de l'unité de traitement locale 25 (CTL_REQ=O) avant que celle-ci ne soit passée en état actif. Si l'unité de traitement locale est dans un état passif et que la donnée de statut locale indique que l'unité de traitement présente un statut de santé « SLAVE » (Remote Req=1), l'unité de traitement locale peut commuter dans l'état esclave décrit ci-dessus. Selon une variante, la commutation dans l'état 30 esclave est également conditionnée à la réception d'un signal de demande d'accès aux actionneurs de l'unité de traitement locale en provenance de l'unité de traitement opposée. Depuis l'état esclave, l'unité de traitement peut retourner à l'état passif lorsque la donnée de statut local n'indique plus que l'unité de traitement présente un statut de santé « SLAVE » (Remote Req=O) 18 3025617 Si la donnée de statut local indique un statut de santé « BAD », l'unité de traitement locale commute en état de remise à zéro quel que soit son état courant. Une fois la remise à zéro effectuée avec succès (HRESET_N rising edge), l'unité de traitement peut repasser dans l'état passif. 5 Dans le cas où l'unité de traitement locale et l'unité de traitement opposée présentent le même statut de santé, GOOD ou ACCEPTABLE, chaque unité de traitement peut selon une première variante rester dans son état courant, actif ou passif. Selon une deuxième variante, il est possible de prévoir de confier le contrôle du moteur à une unité de traitement par défaut, par exemple la première 10 unité de traitement 1, auquel cas les deux unités de traitement restent dans leur état courant si l'unité de traitement par défaut est déjà dans un état actif, ou bien passent d'état passif à actif et inversement si l'unité de traitement par défaut était précédemment dans un état passif. Une unité de traitement peut passer de statut ACCEPTABLE au statut 15 GOOD si elle recouvre les fonctions qu'elle avait précédemment perdues mais une unité de traitement présentant un statut SLAVE ou BAD ne peut pas repasser dans un statut ACCEPTABLE ou GOOD, à moins d'une remise à zéro. Ainsi la voie passive du système de contrôle peut passer dans un état lui permettant de mettre ses actionneurs à disposition de la voie active, qui est dans 20 un meilleur état de santé, pour que le système de contrôle de vol puisse continuer à assurer le contrôle du moteur de l'aéronef malgré une panne affectant la capacité de la voie active à piloter ses propres actionneurs. 19 REVENDICATIONS1. Procédé de commutation mis en oeuvre par une première unité de traitement (1,2), dite unité de traitement locale, d'un système de contrôle de vol d'un aéronef comprenant au moins un moteur, ladite unité de traitement locale (1,2) étant configurée pour commander au moins un actionneur, dit actionneur local, de sorte à contrôler le moteur de l'aéronef, et étant susceptible d'être connectée à au moins un capteur local et à une deuxième unité de traitement (2,1), dite unité de traitement opposée, configurée pour commander au moins un actionneur opposé et être connectée à au moins un capteur opposé, ledit procédé comprenant des étapes de : - envoi à l'unité de traitement opposée de données d'acquisitions relatives à l'au moins un capteur local et de données d'actionneur relatives à l'au moins un actionneur local, - réception en provenance de l'unité de traitement opposée de données d'acquisitions relatives à l'au moins un capteur opposé et de données d'actionneur relatives à l'au moins un actionneur opposé, - réception d'une donnée de santé relative à l'état de santé de l'unité de traitement opposée (2,1), dite donnée de santé opposée, - détermination d'une donnée de santé relative à la santé de ladite unité de traitement locale (1,2), dite donnée de santé locale, - commutation de ladite unité de traitement locale (1,2) d'un premier état à un deuxième état, en fonction de ladite donnée de santé opposée reçue et de ladite donnée de santé locale déterminée, lesdits états étant parmi un état actif (15) dans lequel l'unité de traitement locale (1,2) assure le contrôle du moteur de l'aéronef, un état passif (16) dans lequel l'unité de traitement locale (1,2) n'assure pas le contrôle du moteur de l'aéronef et un état esclave (18) dans lequel l'unité de traitement locale (1,2) cède à l'unité de traitement opposée (2,1) la commande desdits actionneurs locaux pour le contrôle du moteur de l'aéronef. 20 3025617 2. Procédé selon la revendication 1, dans lequel l'unité de traitement opposée (2,1) et l'unité de traitement locale (1,2) étant connectées par l'intermédiaire d'une part d'une première liaison numérique bidirectionnelle (3) et d'autre part d'une deuxième liaison 5 numérique bidirectionnelle (4), et l'unité de traitement opposée (2,1) transmettant une donnée de santé opposée sur chacune des liaisons (3,4), l'étape de réception d'une donnée de santé opposée comprend une étape de réception d'une première donnée de santé opposée sur la première 10 liaison (3) et d'une deuxième donnée de santé opposée redondante sur la deuxième liaison (4), une étape de vérification de la cohérence desdites première et deuxième données de santé reçues, et une étape de détermination de ladite donnée de santé opposée transmise en fonction de ladite étape de vérification. 15 3. Procédé selon la revendication précédente, dans lequel l'étape de détermination de la donnée de santé opposée transmise comprend, lorsque lesdites première et deuxième données de santé reçues ne sont pas cohérentes, une étape de consolidation au cours de laquelle la 20 donnée de santé opposée transmise est déterminée à partir des données reçues sur au moins deux trames successives. 4. Procédé selon l'une quelconque des revendications précédentes, dans lequel l'étape de réception de donnée de santé opposée comprend une 25 étape de vérification de l'intégrité de ladite donnée de santé reçue. 5. Procédé selon l'une des revendications précédentes, dans lequel l'étape de détermination d'une donnée de santé locale comprend une étape de diagnostic de l'état de santé relatif au matériel (« hardware ») et au 30 logiciel (« software ») de ladite unité de traitement locale (1,2). 6. Procédé selon l'une des revendications précédentes, dans lequel l'étape de commutation comprend : 21 3025617 - une étape de détermination, à partir de la donnée de santé locale, d'une donnée d'état relative à l'état de ladite unité de traitement locale (1,2) et d'une donnée de statut de santé de l'unité de traitement locale relative à la capacité de l'unité de traitement locale à assurer le contrôle du moteur, 5 et - une étape de commutation de ladite unité de traitement locale (1,2) dans l'état esclave (18) : - lorsque la donnée d'état indique que l'unité de traitement locale (1) est dans un état passif (16) et, 10 - lorsque la donnée de statut de santé indique un statut dans lequel : ^ l'unité de traitement locale est capable de communiquer avec l'unité de traitement opposée, ^ l'unité de traitement locale (1,2) est incapable d'assurer le 15 contrôle du moteur, ^ et l'unité de traitement locale (1,2) est capable de commander les actionneurs locaux. 7. Procédé selon l'une des revendications précédentes, dans lequel l'étape 20 de commutation comprend : - une étape de détermination, dans laquelle ladite unité de traitement locale (1,2) détermine à partir desdites données de santé locale et opposée que son état de santé est meilleur que celui de l'unité de traitement opposée (2,1), 25 - une étape d'attente dans laquelle ladite unité de traitement locale (1,2) attend que l'unité de traitement opposée (2,1) passe dans l'état passif (16), - une étape de commutation de l'unité de traitement locale (1,2) dans l'état actif (16). 30 8. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé de commutation selon l'une quelconque des revendications précédentes lorsque ce programme est exécuté par un processeur. 22 3025617 9. Unité de traitement (1,2) d'un système de contrôle de vol d'un aéronef comprenant au moins un moteur et configurée pour commander au moins un actionneur, dit actionneur local, de sorte à contrôler le moteur de l'aéronef, 5 ladite unité de traitement (1,2), dite unité de traitement locale étant susceptible d'être connectée à au moins un capteur local et à une deuxième unité de traitement (2,1), dite unité de traitement opposée, étant configurée pour commander au moins un actionneur opposé et être connectée à au moins un capteur opposé, et étant caractérisée en ce 10 qu'elle comprend : - des moyens pour envoyer à l'unité de traitement opposée des données d'acquisitions relatives à l'au moins un capteur local et des données d'actionneur relatives à l'au moins un actionneur local, - des moyens pour recevoir en provenance de l'unité de traitement 15 opposée des données d'acquisitions relatives à l'au moins un capteur opposé et des données d'actionneur relatives à l'au moins un actionneur opposé, - des moyens pour recevoir une donnée de santé relative à l'état de santé de l'unité de traitement opposée (2,1), dite donnée de santé opposée, 20 - des moyens pour déterminer une donnée de santé relative à la santé de ladite unité de traitement locale (1,2), dite donnée de santé locale, - des moyens pour commuter ladite unité de traitement locale (1,2) d'un premier état à un deuxième état, en fonction de ladite donnée de santé opposée reçue et de ladite donnée de santé locale déterminée, 25 lesdits états étant parmi un état actif (15) dans lequel l'unité de traitement locale (1,2) assure le contrôle du moteur de l'aéronef, un état passif (16) dans lequel l'unité de traitement locale (1,2) n'assure pas le contrôle du moteur de l'aéronef et un état esclave (18) dans lequel l'unité de traitement locale (1,2) cède à l'unité de traitement opposée (2,1) la 30 commande desdits actionneurs locaux pour le contrôle du moteur de l'aéronef. 10. Système de contrôle de vol comprenant deux unités de traitement (1,2) selon la revendication précédente. 23 3025617 11 Système de contrôle de vol selon la revendication précédente, dans lequel les deux unités de traitement (1,2) sont connectées par l'intermédiaire d'une part d'une première liaison numérique bidirectionnelle (3) et d'autre part d'une deuxième liaison numérique 5 bidirectionnelle (4), ladite deuxième liaison (4) étant redondante avec la première liaison (3), et lesdites première et deuxième liaisons (3,4) étant susceptibles d'être actives de façon concomitante. 12. Système de contrôle de vol selon la revendication 11, dans lequel les 10 première et deuxième liaisons (3,4) sont des liaisons CCDL (« Cross Channel Data Link »). 13. Système de contrôle de vol selon l'une des revendications 11 ou 12, comprenant des moyens de communication de sauvegarde (13,14) 15 permettant d'assurer des échanges de données entre l'unité de traitement locale (1,2) et l'unité de traitement opposée (2,1) en cas de défaillances des première et deuxième liaisons (3,4). 14. Système de contrôle de vol selon la revendication précédente, dans 20 lequel les moyens de communication de sauvegarde comprennent un réseau de capteurs ou d'actionneurs (13). 15. Système de contrôle de vol selon l'une des revendications 13 ou 14, dans lequel les moyens de communication de sauvegarde comprennent un 25 réseau sécurisé embarqué pour l'avionique (14). 16. Système de contrôle de vol selon la revendication 15, dans lequel le réseau sécurisé embarqué (14) est un réseau Ethernet redondant du type AFDX (« Avionics Full DupleX switched ethernet ») ou pAFDX.