EP3963458A1 - Procédé de supervision d'une unité de contrôle moteur - Google Patents

Procédé de supervision d'une unité de contrôle moteur

Info

Publication number
EP3963458A1
EP3963458A1 EP20732261.1A EP20732261A EP3963458A1 EP 3963458 A1 EP3963458 A1 EP 3963458A1 EP 20732261 A EP20732261 A EP 20732261A EP 3963458 A1 EP3963458 A1 EP 3963458A1
Authority
EP
European Patent Office
Prior art keywords
application task
component
channels
calculations
during
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20732261.1A
Other languages
German (de)
English (en)
Inventor
Christophe Pierre Georges MARTIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Safran Aircraft Engines SAS
Original Assignee
Safran Aircraft Engines SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Safran Aircraft Engines SAS filed Critical Safran Aircraft Engines SAS
Publication of EP3963458A1 publication Critical patent/EP3963458A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M1/00—Analogue/digital conversion; Digital/analogue conversion
    • H03M1/10—Calibration or testing
    • H03M1/1071—Measuring or testing
    • H03M1/1076—Detection or location of converter hardware failure, e.g. power supply failure, open or short circuit
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/165—Error detection by comparing the output of redundant processing systems with continued operation after detection of the error
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G06F11/2236—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested to test CPU or processors
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1633—Error detection by comparing the output of redundant processing systems using mutual exchange of the output between the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/1629—Error detection by comparing the output of redundant processing systems
    • G06F11/1654—Error detection by comparing the output of redundant processing systems where the output of only one of the redundant processing components can drive the attached hardware, e.g. memory or I/O
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/805—Real-time
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/83—Indexing scheme relating to error detection, to error correction, and to monitoring the solution involving signatures

Definitions

  • TITLE Supervision method of an engine control unit
  • the invention relates to turbomachines, such as a turbojet or an aircraft turboprop, and more particularly the control units of such turbomachines.
  • control units capable of piloting and regulating the turbomachines, during the various phases of the aircraft's flight.
  • control units include on-board electronic computers, communicating with each other, and performing calculations in parallel, from the same input data, for example from sensors, in order to establish the controls for the various components of the turbomachine.
  • a first task called an OS (Operating System) task, consists of starting the operating system, that is to say all the programs managing the use of resources by application tasks.
  • a second so-called application task or AS consists of performing the calculations necessary to determine the commands for controlling and regulating the turbomachines.
  • the execution time of the AS task represents 80 to 90% of the time required for a calculation cycle.
  • a third task closes the calculation cycle. This is the same OS task as the first task.
  • FIG. 1 illustrates the sequencing of tasks and self-tests, as known in the prior art.
  • a single self-test 26 is launched during the OS task at the start of the calculation cycle 24.
  • component malfunctions can occur at the level of the components of the computers during the application tasks. Such malfunctions can thus be the source of disturbances in the engine control unit. It is possible by a post-processing analysis, from the disturbances, to go back to the faulty component and therefore to the faulty computer. This then makes it possible to isolate the faulty computer.
  • the invention aims in particular to provide a simple, efficient and economical solution to the drawbacks of the current technique described above.
  • a second component able to store data
  • the application task executed by the first channel and the application task executed by the second channel being able to communicate with each other, the method comprising the following steps during a current execution cycle j of the application task in each channel: a) Detect a latency period;
  • Such a method thus enables each computer to perform self-tests during application tasks, in particular during latency periods, so as to be able to determine, without waiting for the end of a calculation cycle, the state of the various components included. in the calculator.
  • it is possible to detect a faulty computer without waiting for the end of a calculation cycle, and to isolate it suitably at the end of the cycle.
  • This also makes it possible to carry out a diagnosis for maintenance by increasing the number of self-tests, to subsequently facilitate maintenance operations on the ground.
  • the given application task can be the application task executed by the first channel and the application task executed by the second channel.
  • the first and second channels can execute the same given application task.
  • steps a) to c) can be carried out following the following step:
  • the supervision method makes it possible to trigger self-tests of components as soon as a symptom, resulting from a failure of components, is detected.
  • the self-tests are triggered as needed, on the appearance of symptoms identified in advance and resulting from component failures in the ECU computers.
  • the invention therefore makes it possible to link component failures to unwanted events and / or behaviors of an engine control unit. This thus makes it possible to obtain a correspondence table linking symptoms to failures of the on-board electronic equipment, in other words of the components.
  • the symptoms detected are recorded in a non-volatile memory, as well as various environmental information, for example thermal and / or vibratory, so as to facilitate maintenance operations.
  • the symptom may be a difference in signature between the two channels and / or a loss of communication between the two computers.
  • the two channels can each be made up of a computer
  • the detection can be carried out during an execution cycle j-1 which precedes a current execution cycle j.
  • the run cycle d-1 is called the "previous run cycle” or "previous cycle”.
  • the difference in signature may consist in comparing, at the end of cycle j and in parallel on the two channels, the sum of the calculations of the application task which are carried out during the current execution cycle j.
  • the detection can be performed during the current execution cycle j.
  • instructions for performing the test in step b) can be sent by the application task.
  • the application task initiates the operating status tests at the correct frequency and during the latency period so that the operating status of the components can be established regularly, without impacting the calculations of the application task.
  • the first component can be a reprogrammable integrated circuit or FPGA.
  • the second component can be dynamic random access memory.
  • FIG. 1 represents the sequencing of tasks and operating state tests during a calculation cycle according to the prior art
  • FIG. 2 represents a simplified flowchart of the method according to the invention
  • FIG. 3 shows a hardware architecture of an example of an engine control unit with two separate channels
  • FIG. 4 illustrates the sequencing of tasks and operating state tests during a calculation cycle according to the method according to the invention
  • FIG. 5 illustrates a flowchart of an embodiment of the method according to the invention.
  • the supervision method 1 aims to supervise an engine control unit 2 with at least two distinct channels 4, 6, an example of the architecture of which is illustrated in FIG. 3.
  • a two-channel engine control unit 2 4, 6 thus comprises, as can be seen in FIG. 3, two channels 4, 6, that is to say two computers. This redundancy of the computers 4, 6 makes it possible to ensure resistance to a possible failure that could affect one of the computers 4, 6. Although the two computers 4, 6 perform in parallel, the same calculations from the same data. inputs (that is to say, execute the same application task), only one of the computers 4 controls and regulates the turbomachine by calculating the commands. Thus, the redundant computer 6, also qualified as passive, does not send any command to the components of the turbomachine.
  • the computers 4, 6 of the engine control unit 2 shown have the same architecture.
  • each computer 4, 6 includes means for executing a given application task. These means are distributed in the digital heart 8 of the computer and the communication card 10.
  • the digital core 8 comprises, among other things, a microprocessor 12.
  • the communication card 10, participating in the inter-computer communication comprises a first and a second component 14, 16.
  • the first component 14, capable of performing the calculations of said application task. from input data is in this example an FPGA, but can also be a reprogrammable integrated circuit.
  • the second component 16, suitable for storing data is a memory, preferably a dynamic random access memory.
  • the application task AS consisting in part of a plurality of calculations executed successively between which periods of latency elapse, makes it possible in particular to calculate, from input data originating from sensors for example, the control currents intended for 'actuators of mobile components constituting the turbomachine.
  • Such actuators include, for example, electro-hydraulic servo valves associated with jacks or other devices.
  • the AS application task is thus executed simultaneously in parallel on each of the computers 4, 6 of the engine control unit 2.
  • the AS application task executed on the first channel 4 and the AS application task executed on the second channel 6 are able to communicating with each other, through a first 18, second 20 and third 22 bus.
  • the first bus 18 is used to exchange addresses of data memories to be recovered.
  • the second bus 20 allows data to be exchanged, such as, for example, input data from a sensor. These may, for example, be measurements such as acquisitions of engine temperature values.
  • the results of the intermediate and final calculations pass through the second bus 20, from the digital core 8, carrying out the calculations, to the communication card 10, emitting the calculated currents for example.
  • the third bus is used to exchange commands calculated from the input data. This is a so-called control bus making it possible to control the read and write authorizations on the first bus 18 and the second bus 20 and that for each of the computers 4, 6. This control bus thus makes it possible to sequence the exchanges and manage the priorities of read, write and exchange operations.
  • the supervision method 1 is executed at each execution cycle 24 on each of the channels, as illustrated in Figure 4.
  • the first step A of method 1 consists in detecting a symptom resulting from a failure of at least one of the components 14, 16 of the two channels 4, 6.
  • Symptoms of component 14, 16 failure on one of the two channels 4, 6 are as follows:
  • - Erroneous data the AS application task awaiting input data (resulting from a previous calculation or from a sensor) receives erroneous data to carry out the rest of the calculations, leading to erroneous calculations.
  • - Data stored at the wrong address on receipt of a piece of data, it is stored at an address of the second component 16, a dynamic random access memory.
  • the first consequence is that the failure observed corresponds to a signature difference on the two channels 4, 6, that is to say that for a given AS application task, the calculations carried out on each of the computers 4, 6 result in different results.
  • the second consequence is that the observed failure consists of a disruption of inter-computer communication (the data exchanged is erroneous or missing).
  • the detection of these symptoms reflects the failure of at least one component 14, 16 of at least one of the computers 4, 6.
  • the second step B of the method then consists in detecting a latency period of the application task AS.
  • the AS application task consists of a plurality of calculations from several input data, there are latency periods between the calculations during which the AS application task is waiting for data to perform the next calculation.
  • the resources of channels 4, 6, that is, the first 4 and second 6 components are not used. These latency periods can thus be exploited to perform operating condition tests to determine which of the first 14 and second 16 components of the first 4 and second 6 computer is faulty and is the cause of the identified symptom (s).
  • the third step C of method 1 then consists in performing, during this latency period, an operating state test of at least one of the first 14 and second 16 components.
  • This operating condition test is preferably carried out on each of the components 14, 16 in parallel on the two channels 4, 6, that is to say for the two computers.
  • the sequencing of the operating state tests is moreover visible in FIG. 4. Thus, several operating tests are triggered during the latency times of the application task, in addition to that triggered at the start of the cycle during the OS task.
  • Self-tests are so-called March type tests. Self-tests are used to test the write and read capacity of each component. To do this, a message of type AAAA then 5555 is written successively in hexadecimal respectively to addresses of type 5555 then AAAA in hexadecimal. Writing content to these two addresses automatically triggers read tests.
  • the application task AS sends instructions, respectively to each of the components 14, 16, for an operating state test 26 to be carried out.
  • the health tests 26 are called by the application task AS so as to be executed during the latency times.
  • the tests performed do not impact the calculation time of the AS application task.
  • the fourth step D of method 1 consists in determining a state of the component (s) 14, 16 for which an operating state test 26 has been carried out.
  • the state can be either a failed state or a healthy state.
  • the computer comprising the faulty component is isolated.
  • the computer comprising a detected and proven fault no longer executes the application task AS during the following cycles and does not therefore no longer communicates with the computer considered healthy.
  • the engine control unit 2 then becomes single-channel, the AS application task being executed only on a single computer considered to be healthy.
  • FIG. 5 illustrates, by means of a flowchart, another example of the method 28 according to the invention.
  • the overall strategy of the system is to trigger self-tests 26 on the appearance of a symptom of the control unit 2.
  • the first step consists in detecting, as detailed previously, a following failure symptom during cycle j.
  • Symptoms may be:
  • the signature difference consists in comparing, at the end of the previous cycle j-1 and in parallel on the two channels 4, 6, the sum of the calculations of the application task AS carried out during the previous cycle j -1.
  • steps B to D of method 1 are carried out during the current cycle j.
  • the AS application task increases the number of autotest launches 26 during latency periods in order to identify component failures that may be causing the symptom.
  • the self-tests 26 are thus launched until the end of the current execution cycle j.
  • the possible failures of the first component 14, the FPGA are as follows:
  • Microcrack in one of the welds of one of the 16 branches of component 14 some microcracks may be non-impacting, except when the microcrack impacts the weld of a corresponding low-weight bit branch;
  • the possible failures of the second component 16, the DPRAM are as follows:
  • Internal memory fault which can be of the following three types: short circuit, coupling fault and sticking fault.
  • the channel on which the failure is observed is secured, in other words the channel is isolated.
  • the failure, as well as contextual information relating to the state of the control unit such as for example the temperature, the vibratory state, the engine speeds, the attitudes of the airplane, the state of health of the engine, flight number and date of failure, are recorded in a non-volatile memory to facilitate maintenance operations.
  • a safety lock is provided for by the supervision method 28.
  • the safety of a computer consists in ensuring that than :
  • control currents are no longer calculated and therefore no longer emitted by this computer. Redundancy is then lost.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Hardware Redundancy (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Testing And Monitoring For Control Systems (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

L'invention concerne un procédé (1, 28) de supervision d'une unité de contrôle moteur (2) à au moins deux voies distinctes (4, 6), chacune desdites deux voies (4, 6) comprenant au moins : - des moyens d'exécution d'une tâche applicative AS donnée, la tâche applicative AS consistant en partie en une pluralité de calculs exécutés successivement entre lesquels s'écoulent des périodes de latence; - un premier composant (14) aptes à réaliser les calculs; - un second composant (16) apte à stocker des données; les tâches applicatives AS des voies (4) étant aptes à communiquer, le procédé comprenant les étapes suivantes: a) Détecter une période de latence; b) Exécuter, lors de cette période de latence, un test d'état de fonctionnement (26) d'au moins l'un des composants (14, 16); c) Déterminer un état dudit composant (14, 16) correspondant à un état de défaillance ou un état sain.

Description

DESCRIPTION
TITRE : Procédé de supervision d’une unité de contrôle moteur Domaine technique de l’invention
L’invention concerne les turbomachines, tel qu'un turboréacteur ou un turbopropulseur d'aéronef, et plus particulièrement les unités de contrôle de telles turbomachines.
Etat de la technique antérieure
Le fonctionnement des turbomachines des aéronefs est contrôlé par le biais d’unités de contrôle, aptes à piloter et réguler les turbomachines, lors des différentes phases de vol de l’aéronef.
Ces unités de contrôle comprennent des calculateurs électroniques embarqués, communiquant entre eux, et réalisant des calculs en parallèles, à partir de mêmes données d’entrées provenant par exemple de capteurs, afin d’établir les commandes pour les différents organes de la turbomachine.
Lors d’un cycle de calcul d’un calculateur, trois tâches sont réalisées. Une première tâche, appelée tâche OS (de l'anglais Operating System), consiste à lancer le système d’exploitation, c’est-à-dire l’ensemble des programmes gérant l'utilisation des ressources par des tâches applicatives. Une seconde tâche dite applicative ou AS (acronyme provenant de l'anglais Applicative System), consiste à réaliser des calculs nécessaires pour déterminer les commandes pour piloter et réguler les turbomachines. Le temps d’exécution de la tâche AS représente 80 à 90 % du temps nécessaire à un cycle de calcul. Une troisième tâche clôture le cycle de calcul. Il s’agit d’une tâche OS identique à la première tâche.
Ces calculateurs, comprenant de nombreux composants, réalisent des autotests, afin de vérifier qu’aucun de leurs composants ne présente un dysfonctionnement majeur. Ces autotests sont réalisés lors des tâches OS, c’est-à-dire en début et fin de cycles de calculs. La figure 1 illustre le séquencement des tâches et des autotests, comme cela est connu dans l’art antérieur. Un unique autotest 26 est lancé lors de la tâche OS du début du cycle de calcul 24. Néanmoins, des dysfonctionnements de composants peuvent survenir au niveau des composants des calculateurs lors des tâches applicatives. De tels dysfonctionnements peuvent ainsi être à l’origine de perturbations au niveau de l’unité de contrôle moteur. Il est possible par une analyse post traitement, à partir des perturbations, de remonter au composant défaillant et donc au calculateur défaillant. Cela permet alors d’isoler le calculateur défaillant.
Il est nécessaire que cette isolation soit réalisée le plus rapidement possible, afin de réduire l’impact du dysfonctionnement sur le pilotage et la régulation des turbomachines. L’invention a notamment pour but d’apporter une solution simple, efficace et économique aux inconvénients de la technique actuelle exposée ci-dessus.
Résumé de l’invention
A cette fin, il est proposé un procédé de supervision d’une unité de contrôle moteur à au moins deux voies distinctes comprenant chacune un calculateur, chacune desdites deux voies comprenant au moins :
- des moyens d’exécution d’une tâche applicative donnée, la tâche applicative consistant en partie en une pluralité de calculs exécutés successivement entre lesquels s’écoulent des périodes de latence ;
- un premier composant apte à réaliser les calculs de ladite tâche applicative, à partir de données d’entrée ;
- un second composant apte à stocker des données ;
la tâche applicative exécutée par la première voie et la tâche applicative exécutée par la seconde voie étant aptes à communiquer l’une avec l’autre, le procédé comprenant les étapes suivantes lors d’un cycle d’exécution courant j de la tâche applicative dans chaque voie : a) Détecter une période de latence ;
b) Exécuter, lors de cette période de latence, un test d’état de fonctionnement d’au moins l’un des premier et second composants;
c) Déterminer un état dudit composant correspondant à un état de défaillance ou un état sain.
Un tel procédé permet ainsi à chaque calculateur d’effectuer des autotests lors des tâches applicatives, en particulier lors des périodes de latence, de sorte à pouvoir déterminer, sans attendre la fin d’un cycle de calcul, l’état des différents composants compris dans le calculateur. Ainsi, grâce à un tel procédé, il est possible de détecter un calculateur défaillant sans attendre la fin d’un cycle de calcul, et de l’isoler convenablement, à la fin du cycle.
Cela permet en outre, de réaliser un diagnostic pour la maintenance en augmentant le nombre d’autotests, pour faciliter par la suite les opérations de maintenances au sol.
La tâche applicative donnée peut être la tâche applicative exécutée par la première voie et la tâche applicative exécutée par la seconde voie. Ainsi, les première et seconde voies peuvent exécuter une même tâche applicative donnée.
Egalement, les étapes a) à c) peuvent être réalisées suite à l’étape suivante :
Détecter un symptôme résultant d’une défaillance d’au moins un des composants des deux voies.
Ainsi, le procédé de supervision permet de déclencher des autotests de composants dès lors qu’un symptôme, résultant d’une défaillance de composants, est détecté. Ainsi, les autotests sont déclenchés au besoin, sur apparition de symptômes identifiés au préalable et résultant de défaillances de composants des calculateurs de l’unité de contrôle moteur.
L’invention permet donc de relier des défaillances de composants à des évènements et /ou des comportements non souhaités d’une unité de commande moteur. Cela permet ainsi d’obtenir une table de correspondance reliant des symptômes à des défaillances du matériel électronique embarqué, en d’autres termes des composants.
Lors de chaque cycle, les symptômes détectés (ainsi que les pannes en résultant) sont enregistrés dans une mémoire non volatile, ainsi que différentes informations sur l’environnement, par exemple thermique et/ou vibratoire, de sorte à faciliter les opérations de maintenance.
En outre, le symptôme peut être une différence de signature entre les deux voies et/ou une perte de communication entre les deux calculateurs.
Il s’agit d’identifier les symptômes d’une panne touchant les calculateurs. Ces symptômes pouvant être liés à une différence de signature entre les deux voies exécutant la même tâche applicative, c’est-à-dire à une différence entre les résultats de calculs effectués par chacun des calculateurs de la première voie et de la seconde voie au terme de la tâche applicative, ou pouvant être liés à des données non arrivées empêchant alors la réalisation de calculs de la tâche applicative sur au moins une des voies.
Les deux voies peuvent être constituées chacune par un calculateur
De plus, si le symptôme détecté est une différence de signature entre les deux voies alors la détection peut être réalisée lors d’un cycle d’exécution j-1 qui précède un cycle d’exécution courant j. Le cycle d’exécution j-1 est appelé « cycle d’exécution précédent » ou « cycle précédent ».
La différence de signature peut consister à comparer, à l’issue du cycle j et en parallèle sur les deux voies, la somme des calculs de la tâche applicative qui sont réalisés lors du cycle d’exécution courant j.
Si le symptôme détecté est une perte de communication entre les calculateurs, alors la détection peut être réalisée lors du cycle d’exécution courant j.
Selon une autre caractéristique, des instructions pour l’exécution du test de l’étape b) peuvent être envoyées par la tâche applicative.
Ainsi, la tâche applicative enclenche les tests d’état de fonctionnement à la bonne fréquence et lors de période de latence de sorte à pouvoir établir l’état de fonctionnement des composants régulièrement, sans impacter les calculs de la tâche applicative.
Selon une autre caractéristique, le premier composant peut être un circuit intégré reprogrammable ou FPGA.
De plus, le deuxième composant peut être une mémoire vive dynamique. Brève description des figures
[Fig. 1] représente le séquencement de tâches et des tests d’état de fonctionnement lors d’un cycle de calcul selon l’art antérieur ;
[Fig. 2] représente un logigramme simplifié du procédé selon l’invention;
[Fig. 3] représente une architecture matérielle d’un exemple d’unité de contrôle moteur à deux voies distinctes ;
[Fig. 4] illustre le séquencement de tâches et des tests d’état de fonctionnement lors d’un cycle de calcul d’après le procédé selon l’invention ;
[Fig. 5] illustre un logigramme d’un mode de réalisation du procédé selon l’invention.
Description détaillée de l’invention
Le procédé de supervision 1 , dont le logigramme est illustré à la figure 2, vise à superviser une unité de contrôle moteur 2 à au moins deux voies distinctes 4, 6, dont un exemple d’architecture est illustré la figure 3.
Une unité de contrôle moteur 2 à deux voies 4, 6, comprend ainsi, comme on peut le voir sur la figure 3, deux voies 4, 6, c’est-à-dire deux calculateurs. Cette redondance des calculateurs 4, 6 permet d’assurer une résistance à une éventuelle panne pouvant toucher l’un des calculateurs 4, 6. Bien que les deux calculateurs 4, 6 effectuent en parallèle, les mêmes calculs à partir des mêmes données d’entrées (c’est-à-dire, exécutent une même tâche applicative), seul un des calculateurs 4 pilote et régule la turbomachine en calculant les commandes. Ainsi, le calculateur redondant 6, également qualifié de passif, n’envoie aucune commande aux organes constitutifs de la turbomachine.
Les calculateurs 4, 6 de l’unité de contrôle moteur 2 illustrée, présentent une même architecture.
Premièrement, chaque calculateur 4, 6 comprend des moyens d’exécution d’une tâche applicative donnée. Ces moyens sont répartis dans le cœur numérique 8 du calculateur et la carte de communication 10.
Le cœur numérique 8 comprend entre autres un microprocesseur 12. La carte de communication 10, participant à la communication inter-calculateur, comprend un premier et un deuxième composants 14, 16. Le premier composant 14, apte à réaliser les calculs de ladite tâche applicative à partir de données d’entrée est dans cet exemple un FPGA, mais peut également être un circuit intégré reprogrammable. Le deuxième composant 16, apte à stocker des données, est une mémoire, de préférence une mémoire vive dynamique.
Le premier composant 14, dans l’exemple un FPGA (en anglais Field-Programmable Gâte Array), permet de cadencer les échanges entre les deux calculateurs 4, 6. Le deuxième composant 16, de préférence une DPRAM (en anglais Dual Ported Random Access Memory signifiant mémoire vive à double accès), reçoit des signaux du premier composant 14 et stocke des données telles que par exemple des données d’entrée provenant de capteurs, ainsi que des résultats intermédiaires de calculs.
La tâche applicative AS, consistant en partie en une pluralité de calculs exécutés successivement entre lesquels s’écoulent des périodes de latence, permet notamment de calculer, à partir de données d’entrée provenant de capteurs par exemple, les courants de commande à destination d’actionneurs d’organes mobiles constitutifs de la turbomachine. De tels actionneurs comprennent par exemple des servovalves électrohydrauliques associées à des vérins ou autres dispositifs. La tâche applicative AS est ainsi exécutée simultanément en parallèle sur chacun des calculateurs 4, 6 de l’unité de commande moteur 2. La tâche applicative AS exécutée sur la première voie 4 et la tâche applicative AS exécutée sur la seconde voie 6 sont aptes à communiquer l’une avec l’autre, par le biais d’un premier 18, deuxième 20 et troisième 22 bus. Le premier bus 18 permet d’échanger des adresses de mémoires de données à récupérer. Le deuxième bus 20 permet d’échanger des données, telles que par exemple des données d’entrées provenant de capteur. Il peut s’agir par exemple de mesures telles que des acquisitions de valeurs de température du moteur. Les résultats des calculs intermédiaires et finaux transitent à travers le deuxième bus 20, du cœur numérique 8, effectuant les calculs, vers la carte de communication 10, émettant les courants calculés par exemple. Le troisième bus permet d’échanger les commandes calculées à partir des données d’entrée. Il s’agit d’un bus dit de contrôle permettant de contrôler les autorisations en lecture et en écriture sur le premier bus 18 et le deuxième bus 20 et cela pour chacun des calculateurs 4, 6. Ce bus de contrôle permet ainsi de séquencer les échanges et de gérer les priorités des opérations de lecture, écriture et d’échange.
Le procédé de supervision 1 est exécuté à chaque cycle d’exécution 24 sur chacune des voies, comme cela est illustré sur la figure 4.
La première étape A du procédé 1 consiste à détecter un symptôme résultant d’une défaillance d’au moins un des composants 14, 16 des deux voies 4, 6.
Les symptômes d’une défaillance de composants 14, 16 sur l’une des deux voies 4, 6 sont les suivants :
- Données non arrivées : la tâche applicative AS en attente d’une donnée d’entrée (issue d’un calcul précédent ou d’un capteur) ne reçoit pas la donnée pour réaliser la suite des calculs.
- Données erronées : la tâche applicative AS en attente d’une donnée d’entrée (issue d’un calcul précédent ou d’un capteur) reçoit une donnée erronée pour réaliser la suite des calculs, entraînant la réalisation de calculs erronés. - Données stockées à la mauvaise adresse : à la réception d’une donnée, celle-ci est stockée à une adresse du deuxième composant 16, une mémoire vive dynamique.
Lorsque l’adresse à laquelle la donnée est stockée est erronée, il peut y avoir deux conséquences :
- donnée non arrivée : à l’adresse à laquelle devait être stockée la donnée, il n’y a aucune donnée utilisable pour les calculs de la tâche applicative AS.
- donnée erronée : à l’adresse à laquelle devait être stockée la donnée, une
donnée qui y était précédemment stockée est alors utilisée pour la suite des calculs de la tâche applicative AS.
Ces symptômes peuvent avoir deux conséquences. La première conséquence est que la panne observée correspond à une différence de signature sur les deux voies 4, 6, c’est-à-dire que pour une tâche applicative AS donnée, les calculs réalisés sur chacun des calculateurs 4, 6 aboutissent à des résultats différents. La deuxième conséquence est que la panne observée consiste en une perturbation de la communication inter-calculateurs (les données échangées sont erronées ou manquantes).
Ainsi, la détection de ces symptômes traduit la défaillance d’au moins un composant 14, 16 d’au moins un des calculateurs 4, 6.
La deuxième étape B du procédé consiste alors à détecter une période de latence de la tâche applicative AS. En effet, la tâche applicative AS consistant en une pluralité de calculs à partir de plusieurs données d’entrée, il existe des périodes de latence entre les calculs lors desquelles la tâche applicative AS est en attente de données pour réaliser le calcul suivant. Pendant ces périodes de latence, les ressources des voies 4, 6, c’est-à-dire les premier 4 et second 6 composants, ne sont pas utilisés. Ces périodes de latences peuvent ainsi être exploitées pour réaliser des tests d’état de fonctionnement pour déterminer lequel des premier 14 et second 16 composants du premier 4 et second 6 calculateur est défaillant et est à l’origine du/des symptômes identifiés.
La troisième étape C du procédé 1 consiste alors à exécuter, lors de cette période de latence, un test d’état de fonctionnement d’au moins l’un des premier 14 et second 16 composants. Ce test d’état de fonctionnement est de préférence réalisé sur chacun des composants 14, 16 parallèlement sur les deux voies 4, 6, c’est-à-dire pour les deux calculateurs. Le séquencement des tests d’état de fonctionnement est d’ailleurs visible à la figure 4. Ainsi, plusieurs tests de fonctionnement sont déclenchés lors de des temps de latences de la tâche applicative, en outre de celui déclenché en début de cycle lors de la tâche OS.
Les autotests sont des tests dit de type March. Les autotests permettent de tester la capacité en écriture et en lecture de chaque composant. Pour cela, il est écrit successivement un message de type AAAA puis 5555 en hexadécimal respectivement à des adresses de type 5555 puis AAAA en hexadécimal. L’écriture de contenus à ces deux adresses déclenche automatiquement les tests de lecture.
Ces autotests sont réalisés pendant les temps de latence (c’est-à-dire des temps libres) et quasi simultanément à chaque échange sur le bus.
Ainsi, la tâche applicative AS envoie des instructions, respectivement à chacun des composants 14, 16, pour qu’un test d’état de fonctionnement 26 soit réalisé. En d’autres termes, les tests d’état de fonctionnement 26 sont appelés par la tâche applicative AS de sorte à être exécutés lors des temps de latence. Ainsi, les tests réalisés n’impactent pas le temps de calculs de la tâche applicative AS.
La quatrième étape D du procédé 1 consiste à déterminer un état du ou des composants 14, 16 pour lesquels un test d’état de fonctionnement 26 a été réalisé. L’état peut être soit un état de défaillance soit un état sain. Ainsi, si, pendant le même cycle ou deux cycles consécutifs, un symptôme est observé et qu’un état défaillant d’un des composants 14, 16 est avéré, alors une corrélation entre le/les symptômes détectés et la/les défaillances du/des composants relevées est faite.
Afin de limiter les impacts du composant défaillant identifié, le calculateur comprenant le composant défaillant est isolé. En d’autres termes, suite à un test d’état de fonctionnement ou autotest 26, qui est lancé par la tâche applicative AS, le calculateur comportant une panne détectée et avérée n’exécute plus la tâche applicative AS lors des cycles suivants et ne communique donc plus avec le calculateur considéré comme sain. L’unité de commande moteur 2 devient alors monovoie, la tâche applicative AS n’étant exécutée que sur un seul calculateur considéré comme sain.
Suite à cette isolation, pour éviter des arrêts moteur en vol (en anglais In Flight Shutdown - IFSD), lorsqu’une des deux voies 4, 6 est isolée, le lancement des autotests 26 par la tâche applicative AS est suspendu. Ainsi, aucun autotest 26 n’est réalisé sur le calculateur restant, mis à part les autotests 26 réalisés par la tâche OS en début et en fin de cycle.
La figure 5 illustre par le biais d’un logigramme un autre exemple de procédé 28 selon l’invention. La stratégie globale du système est de déclencher des autotests 26 sur apparition d’un symptôme de l’unité de contrôle 2. La première étape consiste à détecter, comme détaillé précédemment, un symptôme de défaillance suivant lors du cycle j. Les symptômes peuvent être les suivants :
- Donnée non arrivée : lorsque la tâche applicative AS attend une donnée de manière active, lors d’une période de latence, une donnée non arrivée est détectée dès lors que le temps d’attente de la donnée par la tâche applicative dépasse un temps d’attente maximum. Le temps d’attente maximum est d’au moins 3 ms.
- Ecart de signature entre la première voie 4 et la seconde voie 6 : il s’agit, à la fin de la tâche applicative AS, de comparer la somme des résultats des calculs effectués par la tâche applicative AS sur les deux voies 4, 6. Cela permet de vérifier que les deux voies 4, 6 réalisent les mêmes calculs. Si la somme est différente sur les deux voies 4, 6, cela signifie qu’il existe, sur au moins l’une des deux voies 4, 6, une utilisation d’une donnée d’entrée de calculs erronée. Etant donné que la somme est réalisée à la fin de la tâche applicative AS, c’est-à- dire d’un cycle, la détection de ce symptôme est effectuée lors du cycle précédent j-1 , pour que les autotests 26 soient lancés lors du cycle j. En d’autres termes, la différence de signature consiste à comparer, à l’issue du cycle précédent j-1 et en parallèle sur les deux voies 4, 6, la somme des calculs de la tâche applicative AS réalisés lors du cycle précédent j-1. Dans le cas d’une détection d’écart de signature lors du cycle précédent j-1 , les étapes B à D du procédé 1 (du logigramme de la figure 2) sont réalisées lors du cycle courant j.
Lorsque l’un des symptômes ci-dessus est identifié, la tâche applicative AS augmente le nombre de lancements d’autotests 26 lors des périodes de latence afin d’identifier les défaillances des composants pouvant être à l’origine de ce symptôme. Les autotests 26 sont ainsi lancés jusqu’à la fin du cycle d’exécution courant j.
Ainsi, en augmentant le nombre d’autotests et en les répartissent lors des périodes de latence du cycle de calcul, la couverture des autotests par conséquent augmentée.
Les défaillances possibles du premier composant 14, le FPGA, sont les suivantes :
Microfissure d’une des soudures d’une des 16 branches du composant 14 : certaines microfissures peuvent être non impactantes, excepté lorsque la microfissure impacte la soudure d’une branche correspondante à bit de poids faible ;
Données non mises à jour ;
Défaillances lors de l’accès à la mémoire en lecture et/ou en écriture.
Les défaillances possibles du deuxième composant 16, la DPRAM, sont les suivantes :
Stockage d’une donnée à une mauvaise adresse de la mémoire ;
Non stockage d’une donnée ;
Défaillance interne à la mémoire pouvant être des trois types suivants : court-circuit, faute de couplage et faute de collage.
Dès lors qu’une défaillance est identifiée par le biais des autotests 26, la voie sur laquelle la défaillance est constatée est mise en sécurité, en d’autres termes la voie est isolée. Egalement, la défaillance, ainsi que des informations contextuelles relatives à l’état de l’unité de contrôle tel que par exemple la température, l’état vibratoire, les régimes moteurs, les attitudes de l’avion, l’état de santé du moteur, le numéro de vol et la date de la panne, sont enregistrées dans une mémoire non volatile afin de faciliter les opérations de maintenance. Dans le cas où aucune défaillance composant n’est identifiée, une mise en sécurité est prévue par le procédé de supervision 28. La mise en sécurité d’un calculateur consiste à faire en sorte que :
la tâche OS n’appelle plus la tâche applicative AS,
les courants de commande ne sont plus calculés et donc plus émis par ce calculateur. La redondance est alors perdue.

Claims

REVENDICATIONS
1 . Procédé (1 , 28) de supervision d’une unité de contrôle moteur (2) à au moins deux voies distinctes (4, 6) comprenant chacune un calculateur, chacune desdites deux voies (4, 6) comprenant au moins :
- des moyens d’exécution d’une tâche applicative (AS) donnée, la tâche applicative (AS) consistant en partie en une pluralité de calculs exécutés successivement entre lesquels s’écoulent des périodes de latence ;
- un premier composant (14) apte à réaliser les calculs de ladite tâche applicative (AS), à partir de données d’entrée ;
- un second composant (16) apte à stocker des données ;
la tâche applicative (AS) exécutée par la première voie (4) et la tâche applicative (AS) exécutée par la seconde voie (6) étant aptes à communiquer l’une avec l’autre, le procédé comprenant les étapes suivantes lors d’un cycle d’exécution courant (j) de la tâche applicative (AS) pour chaque voie (4, 6) :
a) Détecter une période de latence ;
b) Exécuter, lors de cette période de latence, un test d’état de fonctionnement (26) d’au moins l’un des premier (14) et second (16) composants;
c) Déterminer un état dudit composant (14, 16) correspondant à un état de défaillance ou un état sain.
2. Procédé (1 , 28) selon la revendication 1 , dans lequel les étapes a) à c) sont réalisées suite à l’étape suivante :
- Détecter un symptôme résultant d’une défaillance d’au moins un des composants (14, 16) des deux voies (4, 6).
3. Procédé selon la revendication 2, dans lequel le symptôme est une différence de signature entre les deux voies et/ou une perte de communication entre les deux calculateurs (4, 6).
4. Procédé selon la revendication 3, dans lequel, si le symptôme détecté est une différence de signature entre les deux voies (4, 6), la détection est réalisée lors d’un cycle d’exécution précédent ( j-1 ) qui précède le cycle d’exécution courant (j).
5. Procédé selon la revendication 3 ou 4, dans lequel la différence de signature consiste à comparer, à l’issue du cycle d’exécution courant (j) et en parallèle sur les deux voies (4, 6), la somme des calculs de la tâche applicative (AS) réalisés lors du cycle d’exécution courant (j).
6. Procédé selon la revendication 3, dans lequel, si le symptôme détecté est une perte de communication entre les deux calculateurs (4, 6), la détection est réalisée lors du cycle d’exécution courant (j).
7. Procédé selon l’une des revendications précédentes, dans lequel des instructions pour l’exécution du test de l’étape b) sont envoyées par la tâche applicative (AS).
8. Procédé selon l’une des revendications précédentes, dans lequel le premier composant (14) est un circuit intégré reprogrammable ou FPGA.
9. Procédé selon l’une des revendications précédentes, dans lequel le deuxième composant
(16) est une mémoire vive dynamique.
EP20732261.1A 2019-05-03 2020-04-30 Procédé de supervision d'une unité de contrôle moteur Pending EP3963458A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1904675A FR3095705B1 (fr) 2019-05-03 2019-05-03 Procédé de supervision d’une unité de contrôle moteur
PCT/FR2020/050732 WO2020225507A1 (fr) 2019-05-03 2020-04-30 Procédé de supervision d'une unité de contrôle moteur

Publications (1)

Publication Number Publication Date
EP3963458A1 true EP3963458A1 (fr) 2022-03-09

Family

ID=67262757

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20732261.1A Pending EP3963458A1 (fr) 2019-05-03 2020-04-30 Procédé de supervision d'une unité de contrôle moteur

Country Status (6)

Country Link
US (1) US12119837B2 (fr)
EP (1) EP3963458A1 (fr)
JP (1) JP7522764B2 (fr)
CN (1) CN113785276A (fr)
FR (1) FR3095705B1 (fr)
WO (1) WO2020225507A1 (fr)

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH061402B2 (ja) 1987-03-20 1994-01-05 住友電気工業株式会社 多重系制御回路
US5144230A (en) * 1990-11-26 1992-09-01 The Boeing Company Method and system for testing integrated circuits by cycle stealing
US6615366B1 (en) 1999-12-21 2003-09-02 Intel Corporation Microprocessor with dual execution core operable in high reliability mode
JP4357373B2 (ja) 2004-06-23 2009-11-04 株式会社日立製作所 高信頼性制御装置
DE102004054231B4 (de) 2004-11-10 2017-05-11 Dr. Ing. H.C. F. Porsche Aktiengesellschaft Verfahren zur Fehlererkennung in der Motorsteuerung bei Brennkraftmaschinen mit wenigstens zwei Steuergeräten
DE102006057743B4 (de) 2006-12-07 2015-07-30 Continental Automotive Gmbh Verfahren zur Überwachung der Funktionssoftware von Steuergeräten in einem Steuergeräteverbund
US20080234919A1 (en) * 2007-03-16 2008-09-25 Curtis Paul Ritter Performing application review validation testing for an engine as installed in an application
US7865770B2 (en) * 2008-01-10 2011-01-04 Advanced Micro Devices, Inc. Processor including efficient signature generation for logic error protection
DE102008005154B4 (de) 2008-01-18 2023-01-26 Robert Bosch Gmbh Verfahren und Vorrichtung zur Überwachung einer Motorsteuereinheit
CN101910856B (zh) * 2008-01-29 2014-06-18 立维腾制造有限公司 自测试故障电路中断器装置和方法
FR2929056B1 (fr) * 2008-03-19 2010-04-16 Alstom Transport Sa Dispositif de detection a seuil securitaire d'un systeme ferroviaire
JP2012529595A (ja) * 2009-06-10 2012-11-22 スネクマ 始動時の過速度からターボ機械を保護するシステムの試験方法
JP2011123545A (ja) 2009-12-08 2011-06-23 Toshiba Corp 比較冗長型情報処理装置
US8566633B2 (en) * 2011-02-10 2013-10-22 GM Global Technology Operations LLC Method of dynamic allocation on a statically allocated and embedded software architecture
US8799713B2 (en) * 2011-03-01 2014-08-05 Texas Instruments Incorporated Interruptible non-destructive run-time built-in self-test for field testing
FR2989488B1 (fr) * 2012-04-13 2015-02-20 Commissariat Energie Atomique Dispositif pour generer une signature a l'execution d'une tache de programme et methode de comparaison de flots d'execution
CN105550067B (zh) * 2015-12-11 2018-05-08 中国航空工业集团公司西安航空计算技术研究所 一种机载计算机双通道选择方法
JP2017151496A (ja) * 2016-02-22 2017-08-31 ルネサスエレクトロニクス株式会社 安全監視装置、ネットワークシステム、安全監視方法

Also Published As

Publication number Publication date
US12119837B2 (en) 2024-10-15
CA3137976A1 (fr) 2020-11-12
FR3095705B1 (fr) 2021-05-07
FR3095705A1 (fr) 2020-11-06
JP7522764B2 (ja) 2024-07-25
WO2020225507A1 (fr) 2020-11-12
CN113785276A (zh) 2021-12-10
JP2022531597A (ja) 2022-07-07
US20230036687A1 (en) 2023-02-02

Similar Documents

Publication Publication Date Title
CA2740280C (fr) Systeme de commande de vol et aeronef le comportant
WO2002014972A2 (fr) Systeme de maintenance pour un ensemble d'equipements
CA2619143A1 (fr) Procede de surveillance des moteurs d'avion
JP2001056701A (ja) 制御ユニットの相互監視のための方法並びに装置
CN108021505A (zh) 数据上线方法、装置和计算机设备
CN110941561A (zh) 一种飞行控制软件测评方法、装置及系统
EP3948436B1 (fr) Procédé de commande d'un moteur d'un aéronef commandé par un dispositif de commande comprenant deux voies de commande redondées
FR3012636A1 (fr) Procede de non-regression d'un outil de conception d'un systeme de surveillance de moteur d'aeronef
FR2903384A1 (fr) Systeme de commande de vol pour aeronef,et systeme de test pour tester un tel systeme de commande de vol.
FR3026882A1 (fr) Procede de determination d'au moins un equipement defaillant d'un aeronef et systeme correspondant
EP0543698B1 (fr) Dispositif d'éxploitation des informations relatives aux pannes détectées par une ou plusieurs unités centrales d'un aéronef
KR20200052129A (ko) 위성명령 절차서 자동 생성 장치 및 방법
EP3963458A1 (fr) Procédé de supervision d'une unité de contrôle moteur
US10754333B2 (en) Method for monitoring the operation of a turbomachine
EP3848934A1 (fr) Registre à triplication comportant un dispositif de sécurisation
US20220147425A1 (en) Fault location in a redundant acquisition system
CN109814517A (zh) 风机运行参数的处理方法和系统与计算机可读存储介质
FR2882165A1 (fr) Systeme et procede de traitements embarques d'essais en vol
CA3137976C (fr) Procede de supervision d'une unite de controle moteur
FR3101669A1 (fr) Dispositif, procédé et programme d’ordinateur de suivi de moteur d’aéronef
CN115599685A (zh) 一种系统测试的方法及装置
US7509552B2 (en) Multi-thread parallel segment scan simulation of chip element performance
FR3003663A1 (fr) Procede de determination automatique de causes de dysfonctionnement d'un systeme compose d'une pluralite de composants materiels ou logiciels
US20250071017A1 (en) System and method for parallel (bus) communication between multiple devices, and computer program stored on recording medium for executing the method
KR102221445B1 (ko) 비행 추진체 제어용 통신 테스트 장치

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20211123

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250124