WO2023083703A1 - Procédé et dispositif de contrôle et commande d'un moteur de véhicule - Google Patents

Procédé et dispositif de contrôle et commande d'un moteur de véhicule Download PDF

Info

Publication number
WO2023083703A1
WO2023083703A1 PCT/EP2022/080761 EP2022080761W WO2023083703A1 WO 2023083703 A1 WO2023083703 A1 WO 2023083703A1 EP 2022080761 W EP2022080761 W EP 2022080761W WO 2023083703 A1 WO2023083703 A1 WO 2023083703A1
Authority
WO
WIPO (PCT)
Prior art keywords
module
condition
command
core
command produced
Prior art date
Application number
PCT/EP2022/080761
Other languages
English (en)
Inventor
Xavier Guillaume
Jean-Luc BOYER
Original Assignee
Vitesco Technologies GmbH
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 Vitesco Technologies GmbH filed Critical Vitesco Technologies GmbH
Priority to CN202280074689.5A priority Critical patent/CN118265969A/zh
Publication of WO2023083703A1 publication Critical patent/WO2023083703A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1479—Generic software techniques for error detection or fault masking
    • G06F11/1489—Generic software techniques for error detection or fault masking through recovery blocks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/1641—Error detection by comparing the output of redundant processing systems where the comparison is not performed by the redundant processing components
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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/18—Error detection or correction of the data by redundancy in hardware using passive fault-masking of the redundant circuits
    • G06F11/187—Voting techniques
    • G06F11/188—Voting techniques where exact match is not required
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/0796—Safety measures, i.e. ensuring safe condition in the event of error, e.g. for controlling element

Definitions

  • the invention relates to the field of the control and command of a vehicle engine and more particularly its safety, whether it is an electric, thermal or hybrid engine.
  • a control and command device typically comprises a computer C integrated in the ECU (not shown), which includes all the hardware part and at least one application or software that runs on said computer C.
  • such a control and command device is conventionally organized around a multicore computer C, and comprises a first module L1, generally an application software layer, adapted to ensure alone and nominally and completes all the vehicle engine control functions, a second module L2, also generally an application software layer, suitable for monitoring the correct operation of the first module L1 and for controlling engine safety and therefore consequently of the vehicle, in the event of detection of a failure of the first module L1, and a third module L3, generally hardware, adapted to monitor the correct operation of the computer C and to implement said safety, at the request of the second module L2 or upon detection of a failure, by its own means of detection.
  • the second module L2 evaluates the commands produced by the first module L1 for the attention of the motor. As long as these commands are consistent, the second L2 module will not detects any failure and lets these commands pass through to the motor. Failing this, the second module L2 detects a failure and performs a safety shutdown.
  • a trip can be carried out according to at least three levels as follows:
  • a first level called “degraded mode” or in English “limp-mode” authorizes all the functions of the engine, but imposes a maximum speed or speed. Thus it remains possible to move the vehicle, typically to drive it to the garage in order to repair the fault, but at limited speed, in order to limit the risk of engine failure.
  • a second level called "stop mode” stops the engine and thus immobilizes the vehicle.
  • Such a tripping is typically ordered following a failure detection carried out by the second module L2 or by the third module L3.
  • the tripping is typically controlled by the second module L2. This command is checked and, if necessary, duplicated by the third module L3 in the event of an actuation fault.
  • a third level called “reset mode” in English, for safety setting "reset mode” performs a reset of the computer C.
  • Such a safety setting is controlled by the third module L3 either on detection by its own means, or on request from the second L2 module.
  • the aim here is to attempt to remove non-remanent software errors while placing the engine and the vehicle in a secure state.
  • the subject of the invention is a method for monitoring and controlling a vehicle engine implemented in an electronic engine control unit comprising a multicore computer C, a first module L1 adapted to ensure alone and nominally and completes the vehicle engine control functions, a second module L2 suitable for monitoring the correct operation of the first module L1 and for ordering a safety shutdown in the event of detection of a failure of the first module L1, and a third module L3 adapted to monitor the correct operation of the multicore computer C and to implement said safety command, on request from the second module L2 or on detection by its own means of a failure of the first module L1.
  • the method according to the invention is remarkable in that the first module L1 is able to run on a first core C1 of the multicore computer C, in that the second module L2 is able to run on a second core C2 of the multi-core computer C, different from the first core C1, and in that the electronic engine control unit comprises a fourth module LM adapted to ensure in a redundant and simplified manner the main functions of controlling the engine of the vehicle, further adapted for s run within the framework of the second module L2 and on the second heart C2, the third module L3 ensuring the arbitration between a command produced by the first module L1 and a command produced by the fourth module LM.
  • Execution “under the second L2 module” means execution under the supervision of the second L2 module.
  • checkpoints are provided in the (soft) code of the fourth module LM, allowing the second module L2 to verify whether the code is executed in the correct order and/or according to a desired timing.
  • the execution within the framework of the second module L2 implies an execution with the same dependability criteria as the second module L2.
  • the arbitration between a command produced by the first module L1 and a command produced by the fourth module LM comprises the following steps: evaluation of a first condition T1: a command produced by the first module L1 is close to, or equal to, a command produced by the fourth module LM, evaluation of a second condition T2: the monitoring of the second module L2 by the third module L3 has not detected any error, if the first condition T1 and the second condition T2 are both true, the command produced by the first module L1 is applied to the motor, if the first condition T1 is false and the second condition T2 is true, the command produced by the fourth module LM is applied to the motor, if the first condition T1 is false and the second condition T2 is false, a lockout is commanded, if the first condition T1 is true and the second condition T2 is false, a safety shutdown is commanded.
  • the first module L1 is implemented by an application software layer
  • the second module L2 is implemented by an application software layer
  • the third module L3 is implemented by a hardware module
  • the fourth module LM is implemented by an application software layer.
  • the present invention also relates to an electronic control and command unit for a vehicle engine comprising a multi-core computer C, a first module L1 adapted to ensure alone and in a nominal and complete manner the functions of controlling the engine of the vehicle, a second module L2 adapted to monitor the correct operation of the first module L1 and to order a safety shutdown in the event of detection of a failure of the first module L1, and a third module L3 adapted to monitor the correct operation of the multicore computer C and to implement said safety control, on request from the second module L2 or on detection by its own means of a failure of the first module L1, characterized in that the first module L1 is capable of being executed on a first core C1 of the multicore computer C, in that the second module L2 is able to run on a second core C2 of the multicore computer C, different from the first core C1, and in that the electronic unit of engine control comprises a fourth module LM adapted to ensure in a redundant and simplified manner the main functions of driving the engine of the vehicle, and adapted further to
  • the first module L1 is a software layer
  • the second module L2 is a software layer
  • the third module L3 is a hardware module
  • the fourth module LM is a software layer
  • FIG. 1 schematically illustrates an organization into three modules L1, L2, L3 according to the prior art
  • FIG. 2 schematically illustrates an organization in three modules L1, L2, L3 augmented according to the invention
  • FIG. 3 schematically illustrates the arbitration between L1 and LM.
  • a control and command device for a vehicle engine which for example meets the ISO 26262 standard known to those skilled in the art, comprises a multi-core computer C (not shown), a first module L1, for example an application software module L1 adapted to run on a first core C1 of the computer C and to ensure alone and in a nominal and complete manner all the vehicle engine control functions, a second module L2, for example an application software module L2 adapted to run on a second core C2, different from the first core C1, adapted to monitor the correct operation of the first application module L1 and to control a safety shutdown in the event of detection of a failure of the first application module L1, and a third module L3, for example a hardware module L3 capable of monitoring the correct operation of the computer C and to implement said safety, on request from the second application module L2 or on detection by its own means.
  • a first module L1 for example an application software module L1 adapted to run on a first core C1 of the computer C and to ensure alone and in a nominal and complete manner all the vehicle engine control
  • a security setting for the present description has the same definition as that given above for the prior art, that is to say can be carried out according to at least three levels, in summary as follows:
  • a first level called “degraded mode” or in English “limp-mode” authorizes all the functions of the engine, but imposes a maximum speed or speed.
  • a second level called "stop mode” stops the engine and thus immobilizes the vehicle.
  • Such a tripping is typically ordered following a failure detection carried out by the second module L2 or by the third module L3.
  • the tripping is typically controlled by the second module L2. This command is checked and, if necessary, duplicated by the third module L3 in the event of an actuation fault.
  • a third level called “reset mode” in English, for safety setting "reset mode” performs a reset of the computer C.
  • Such a safety setting is controlled by the third module L3 either on detection by its own means, or on request from the second L2 module.
  • the aim here is to attempt to remove non-remanent software errors while placing the engine and the vehicle in a secure state.
  • the invention adds a fourth LM module.
  • This new fourth module LM is able to ensure in a redundant manner, relative to the first application software module L1, and in a simplified manner the main functions of controlling the engine of the vehicle.
  • the term "simplified" means that only the main functions are repeated.
  • the motor control algorithm will be simpler at the expense of performance. For example, fewer adjustable parameters will be used (less calibrations) again at the expense of performance.
  • On a heat engine it will be possible, for example, to suppress a certain number of injection strategies (regeneration, multi-injections, etc.) as already known and practiced in "limp home” mode, a "MIL” warning light (for "Malfunction Indicator Lamp” in English) which must be switched on so that the driver can quickly bring the vehicle to the garage.
  • each of the functions retained is not necessarily developed with the same level of detail as in the first application software module L1, but only so as to be able to control the motor.
  • the simplification of the strategy implemented by the fourth module LM makes it possible to circumvent a possible problem which would be implemented in the first module L1. This simplification avoids having the same software bug and above all consumes less data and computer load.
  • This strategy is executed on another core of the multicore computer of the electronic engine control unit, in a secure environment of the ISO 26262 type, for example known to those skilled in the art.
  • “Redundant” is understood to mean that the fourth module LM is capable of producing redundant motor commands relative to those produced by the first application software module L1.
  • the fourth module LM is for example an application software module, and is for operational safety reasons, able to be executed within the framework of the second application software module L2 and on the second core C2.
  • the fourth redundant module LM advantageously does not run on the same core C1 as the first application L1.
  • the invention further adds an L3D arbitration module.
  • This L3D arbitration module is integrated into the third L3 hardware module and thus enables it to provide arbitration.
  • the function of the arbitration module L3D consists either in choosing among the motor commands redundantly produced on the one hand by the first application software module L1 and on the other hand by the fourth module LM, which seem the most reliable, must be retained and are actually applied to the motor, or, in the event of an arbitration fault, when such a choice proves to be dangerous, not to apply a command but on the contrary to request a safety shutdown.
  • the arbitration between a command produced by the first application software module L1 and a command produced by the fourth module LM is carried out according to the following synopsis, more particularly illustrated in FIG. 3.
  • This synopsis comprises, more particularly illustrated in the upper part of FIG. 3, the following steps: evaluation of a first condition T1 by the second application software module L2 and evaluation of a second condition T2 by the third hardware module L3.
  • the expression “close to” used above with regard to the comparison of commands will be defined here by two corresponding data values having a negligible differential from a system effect point of view. This differential is to be quantified by calibration for each datum.
  • the first condition T1 is true when a command produced by the first application software module L1 is equal to a command produced by the fourth application software module LM.
  • the first condition T1 is true when a command produced by the first application software module L1 is equal to a command produced by the fourth application software module LM, to within a few percent, for example less than 5 %, the exact threshold being adapted to the system by calibration.
  • the second application module L2 is responsible for the comparison L1 versus LM and processes the first condition T1.
  • the third hardware module L3 is responsible for monitoring the second application module L2 and processes the second condition T2.
  • the control and command is in a nominal case as shown.
  • the first application software module L1 produces a motor command substantially identical to a motor command produced by the fourth application software module LM.
  • the monitoring of the first application software module L1 by the second application software module L2 did not detect any errors.
  • motor control from either of the redundant modules can be applied to the motor.
  • the command produced by the first application software module L1 is preferred and is applied to the motor.
  • a fourth case still related to Figure 3, if T1 is true and T2 is false as shown in Figure 3 in the fourth box down from the left, i.e. if we have T1 AND NOT T2, the second module L2 is no longer trusted, the execution of the software cannot be continued and computer C must be restarted. It is also considered here that it is not possible to carry out an arbitration. Also, a lockout is controlled by resetting the ECU.
  • T1 AND NOT T2 can translate for example a failure of the hardware power driver.
  • the invention adds, relative to the prior art, the second case as described above, in which a certain mobility is possible allowing for example to mobilize the vehicle to a garage for repair, while a setting in security with immobilization would have been decreed according to the prior art.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Safety Devices In Control Systems (AREA)
  • Combined Controls Of Internal Combustion Engines (AREA)

Abstract

L'invention concerne un procédé de contrôle d'un moteur de véhicule comprenant une unité électronique de contrôle du moteur, comprenant un calculateur multicœur (C), un premier module (L1), un deuxième module (L2), et un troisième module (L3) adapté pour mettre en œuvre une commande de mise en sécurité sur requête du deuxième module ou sur détection d'une défaillance du premier module, le premier module étant adapté pour s'exécuter sur un premier cœur (C1) du calculateur, le deuxième module étant adapté pour s'exécuter sur un deuxième cœur (C2) du calculateur, l'unité électronique de contrôle du moteur comprenant un quatrième module (LM) adapté pour assurer de manière redondante les fonctions principales de pilotage du moteur du véhicule, et pour s'exécuter sous la surveillance du deuxième module et sur le deuxième cœur, le troisième module assurant l'arbitrage entre une commande produite par le premier module et une commande produite par le quatrième module.

Description

Description
Titre de l'invention : Procédé et dispositif de contrôle et commande d’un moteur de véhicule
Domaine technique
L’invention concerne le domaine du contrôle et de la commande d’un moteur de véhicule et plus particulièrement de sa sécurité, qu’il s’agisse d’un moteur électrique, thermique ou hybride.
Technique antérieure
Il est connu de piloter toutes les fonctions, tant de commande proprement dite que de maintenance d’un moteur à partir d’un dispositif de contrôle et commande, appelé ECU (pour « Engine Control Unit » ou « Electronic Control Unit » en anglais). Pour cela, tel qu’illustré à la figure 1 , un dispositif de contrôle et commande comprend typiquement un calculateur C intégré dans l’ECU (non représenté), qui regroupe toute la partie matérielle et au moins un applicatif ou logiciel qui s’exécute sur ledit calculateur C.
Plus particulièrement utilisée dans le domaine de l’automobile, un tel dispositif de contrôle et commande est classiquement organisé autour d’un calculateur multicœur C, et comprend un premier module L1 , généralement une couche logicielle applicative, adapté pour assurer seul et de manière nominale et complète toutes les fonctions de pilotage du moteur du véhicule, un deuxième module L2, également généralement une couche logicielle applicative, adapté pour surveiller le bon fonctionnement du premier module L1 et pour commander une mise en sécurité du moteur et donc par voie de conséquence du véhicule, en cas de détection d’une défaillance du premier module L1 , et un troisième module L3, généralement matériel, adapté pour surveiller le bon fonctionnement du calculateur C et pour mettre en œuvre ladite mise en sécurité, sur requête du deuxième module L2 ou sur détection d’une défaillance, par ses propres moyens de détection.
Ainsi en permanence, lorsque le premier module L1 fonctionne, le deuxième module L2 évalue les commandes produites par le premier module L1 à l’attention du moteur. Tant que ces commandes sont cohérentes, le deuxième module L2 ne détecte aucune défaillance et laisse ces commandes transiter jusqu’au moteur. A défaut, le deuxième module L2 détecte une défaillance et réalise une mise en sécurité.
Une mise en sécurité peut être réalisée selon au moins trois niveaux comme suit :
Un premier niveau dit « mode dégradé » ou en anglais « limp-mode » autorise toutes les fonctions du moteur, mais impose un régime ou une vitesse maximale. Ainsi il reste possible de déplacer le véhicule, typiquement pour le conduire au garage afin de réparer la défaillance, mais à vitesse limitée, afin de limiter les risques de casse moteur.
Un deuxième niveau dit « mode stop » arrête le moteur et ainsi immobilise le véhicule. Une telle mise en sécurité est typiquement commandée suite à une détection de défaillance réalisée par le deuxième module L2 ou par le troisième module L3. La mise en sécurité est typiquement commandée par le deuxième module L2. Cette commande est vérifiée et le cas échéant redoublée par le troisième module L3 en cas de défaut d’actionnement.
Un troisième niveau dit « mode reset » en anglais, pour « mode réinitialisation » de mise en sécurité réalise une réinitialisation du calculateur C. Une telle mise en sécurité est commandée par le troisième module L3 soit sur une détection par ses propres moyens, soit sur requête du deuxième module L2. Le but est ici de tenter de lever les erreurs logicielles non rémanentes tout en plaçant le moteur et le véhicule dans un état sécurisé.
Une telle structure de type connue est par exemple décrite dans les documents EP1577773A1 ou WO2013164224.
Une telle approche a pour conséquence de trop privilégier une immobilisation du véhicule, alors même que dans certains cas, une certaine mobilité pourrait être conservée. La présente demande vise à pallier au moins en partie ces inconvénients. Résumé de l'invention
Pour cela, l’invention a pour objet un procédé de contrôle et commande d’un moteur de véhicule mis en œuvre dans une unité électronique de contrôle du moteur comprenant un calculateur multicœur C, un premier module L1 adapté pour assurer seul et de manière nominale et complète les fonctions de pilotage du moteur du véhicule, un deuxième module L2 adapté pour surveiller le bon fonctionnement du premier module L1 et pour commander une mise en sécurité en cas de détection d’une défaillance du premier module L1 , et un troisième module L3 adapté pour surveiller le bon fonctionnement du calculateur multicœur C et pour mettre en œuvre ladite commande de mise en sécurité, sur requête du deuxième module L2 ou sur détection par ses propres moyens d’une défaillance du premier module L1 .
Le procédé selon l’invention est remarquable en ce que le premier module L1 est apte à s’exécuter sur un premier cœur C1 du calculateur multicœur C, en ce que le deuxième module L2 est apte à s’exécuter sur un deuxième cœur C2 du calculateur multicœur C, différent du premier cœur C1 , et en ce que l’unité électronique de contrôle du moteur comprend un quatrième module LM adapté pour assurer de manière redondante et simplifiée les fonctions principales de pilotage du moteur du véhicule, adapté en outre pour s’exécuter dans le cadre du deuxième module L2 et sur le deuxième cœur C2, le troisième module L3 assurant l’arbitrage entre une commande produite par le premier module L1 et une commande produite par le quatrième module LM. L’exécution « dans le cadre du deuxième module L2 » signifie une exécution sous la surveillance du deuxième module L2. On prévoit de préférence, dans le code (soft) du quatrième module LM, des points de contrôle permettant que le deuxième module L2 vérifie si le code s’exécute dans le bon ordre et/ou selon un cadencement souhaité. De préférence, l’exécution dans le cadre du deuxième module L2 implique une exécution avec les mêmes critères de sûreté de fonctionnement que le deuxième module L2.
Selon l’invention, l’arbitrage entre une commande produite par le premier module L1 et une commande produite par le quatrième module LM comporte les étapes suivantes : évaluation d’une première condition T1 : une commande produite par le premier module L1 est proche de, ou égale à, une commande produite par le quatrième module LM, évaluation d’une deuxième condition T2 : la surveillance du deuxième module L2 par le troisième module L3 n’a détecté aucune erreur, si la première condition T1 et la deuxième condition T2 sont toutes deux vraies, la commande produite par le premier module L1 est appliquée au moteur, si la première condition T1 est fausse et la deuxième condition T2 est vraie, la commande produite par le quatrième module LM est appliquée au moteur, si la première condition T1 est fausse et la deuxième condition T2 est fausse, une mise en sécurité est commandée, si la première condition T1 est vraie et la deuxième condition T2 est fausse, une mise en sécurité est commandée.
Selon un mode de réalisation avantageux, le premier module L1 est mis en œuvre par une couche logicielle applicative, le deuxième module L2 est mis en œuvre par une couche logicielle applicative, le troisième module L3 est mis en œuvre par un module matériel, et le quatrième module LM est mis en œuvre par une couche logicielle applicative.
La présente invention se rapporte en outre à une unité électronique de contrôle et commande d’un moteur de véhicule comprenant un calculateur multicœur C, un premier module L1 adapté pour assurer seul et de manière nominale et complète les fonctions de pilotage du moteur du véhicule, un deuxième module L2 adapté pour surveiller le bon fonctionnement du premier module L1 et pour commander une mise en sécurité en cas de détection d’une défaillance du premier module L1 , et un troisième module L3 adapté pour surveiller le bon fonctionnement du calculateur multicœur C et pour mettre en œuvre ladite commande de mise en sécurité, sur requête du deuxième module L2 ou sur détection par ses propres moyens d’une défaillance du premier module L1 , caractérisée en ce que le premier module L1 est apte à s’exécuter sur un premier cœur C1 du calculateur multicœur C, en ce que le deuxième module L2 est apte à s’exécuter sur un deuxième cœur C2 du calculateur multicœur C, différent du premier cœur C1 , et en ce que l’unité électronique de contrôle du moteur comprend un quatrième module LM adapté pour assurer de manière redondante et simplifiée les fonctions principales de pilotage du moteur du véhicule, et adapté en outre pour s’exécuter dans le cadre du deuxième module L2 et sur le deuxième cœur C2, le troisième module L3 assurant l’arbitrage entre une commande produite par le premier module L1 et une commande produite par le quatrième module LM.
Selon une caractéristique avantageuse de l’unité électronique de contrôle et commande selon l’invention, le premier module L1 est une couche logicielle, le deuxième module L2 est une couche logicielle, le troisième module L3 est un module matériel, et le quatrième module LM est une couche logicielle.
Brève description des dessins
L’invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d’exemple, et en référence aux figures en annexe dans lesquelles :
[Fig. 1] illustre de manière schématique une organisation en trois modules L1 , L2, L3 selon l’art antérieur,
[Fig. 2] illustre de manière schématique une organisation en trois modules L1 , L2, L3 augmentée selon l’invention,
[Fig. 3] illustre de manière schématique l’arbitrage entre L1 et LM.
Description des modes de réalisation
En référence à la figure 1 , illustrative de l’art antérieur, un dispositif de contrôle et commande d’un moteur de véhicule, qui répond par exemple à la norme ISO 26262 connue de l’homme du métier, comprend, un calculateur multicœur C (non représenté), un premier module L1 , par exemple un module logiciel applicatif L1 adapté pour s’exécuter sur un premier cœur C1 du calculateur C et pour assurer seul et de manière nominale et complète toutes les fonctions de pilotage du moteur du véhicule, un deuxième module L2, par exemple un module logiciel applicatif L2 adapté pour s’exécuter sur un deuxième cœur C2, différent du premier cœur C1 , adapté pour surveiller le bon fonctionnement du premier module applicatif L1 et pour commander une mise en sécurité en cas de détection d’une défaillance du premier module applicatif L1 , et un troisième module L3, par exemple un module matériel L3 apte à surveiller le bon fonctionnement du calculateur C et à mettre en œuvre ladite mise en sécurité, sur requête du deuxième module applicatif L2 ou sur détection par ses propres moyens.
Une mise en sécurité pour la présente description a la même définition que celle donnée plus haut pour l’art antérieur, c’est-à-dire peut être réalisée selon au moins trois niveaux, en résumé comme suit :
Un premier niveau dit « mode dégradé » ou en anglais « limp-mode » autorise toutes les fonctions du moteur, mais impose un régime ou une vitesse maximale.
Un deuxième niveau dit « mode stop » arrête le moteur et ainsi immobilise le véhicule. Une telle mise en sécurité est typiquement commandée suite à une détection de défaillance réalisée par le deuxième module L2 ou par le troisième module L3. La mise en sécurité est typiquement commandée par le deuxième module L2. Cette commande est vérifiée et le cas échéant redoublée par le troisième module L3 en cas de défaut d’actionnement.
Un troisième niveau dit « mode reset » en anglais, pour « mode réinitialisation » de mise en sécurité réalise une réinitialisation du calculateur C. Une telle mise en sécurité est commandée par le troisième module L3 soit sur une détection par ses propres moyens, soit sur requête du deuxième module L2. Le but est ici de tenter de lever les erreurs logicielles non rémanentes tout en plaçant le moteur et le véhicule dans un état sécurisé.
De plus, tel qu’illustré à la figure 2, l’invention ajoute un quatrième module LM. Ce nouveau quatrième module LM est apte à assurer de manière redondante, relativement au premier module logiciel applicatif L1 , et de manière simplifiée les fonctions principales de pilotage du moteur du véhicule.
On entend ici par « simplifié », le fait que seules les fonctions principales sont reprises. L’algorithme du contrôle moteur sera plus simple au détriment de la performance. Par exemple, moins de paramètres ajustables seront utilisés (moins de calibrations) là encore au détriment de la performance. Sur un moteur thermique, il sera possible par exemple de supprimer un certain nombre de stratégies d’injection (régénération, multi-injections, ... ) comme déjà connu et pratiqué en mode « limp home », un témoin « MIL » (pour « Malfunction Indicator Lamp » en anglais) devant être impérativement allumé afin que le conducteur amène rapidement le véhicule au garage. De plus, chacune des fonctions retenues n’est pas nécessairement développée avec le même niveau de détail que dans le premier module logiciel applicatif L1 , mais uniquement de manière à pouvoir commander le moteur. La simplification de la stratégie mise en œuvre par le quatrième module LM permet de contourner un problème éventuel qui serait implémenté dans le premier module L1. Cette simplification évite d’avoir le même bug logiciel et surtout consomme moins de données et de charge du calculateur. Cette stratégie s’exécute sur un autre cœur du calculateur multicœur de l’unité électronique de contrôle du moteur, dans un environnement sécurisé de type ISO 26262 par exemple connu de l’homme du métier.
On entend par « redondant » que le quatrième module LM est apte à produire des commandes moteur redondantes relativement à celles produites par le premier module logiciel applicatif L1.
Le quatrième module LM est par exemple un module logiciel applicatif, et est pour des raisons de sécurité de fonctionnement, apte à s’exécuter dans le cadre du deuxième module logiciel applicatif L2 et sur le deuxième cœur C2. Ainsi, le quatrième module redondant LM ne s’exécute avantageusement pas sur le même cœur C1 que le premier applicatif L1 .
L’invention ajoute encore un module d’arbitrage L3D. Ce module d’arbitrage L3D est intégré au troisième module matériel L3 et lui permet ainsi d’assurer l’arbitrage.
La fonction du module d’arbitrage L3D consiste soit à choisir parmi les commandes moteur redondamment produites d’une part par le premier module logiciel applicatif L1 et d’autre part par le quatrième module LM, lesquelles semblent les plus fiables, doivent être retenues et sont effectivement appliquées au moteur, soit, en cas de défaut d’arbitrage, lorsqu’un tel choix s’avère dangereux, à ne pas appliquer de commande mais au contraire à demander une mise en sécurité. Selon une autre caractéristique, l’arbitrage entre une commande produite par le premier module logiciel applicatif L1 et une commande produite par le quatrième module LM est réalisé selon le synopsis suivant, plus particulièrement illustré à la figure 3.
Ce synopsis comprend, plus particulièrement illustré en partie haute de la figure 3, les étapes suivantes : évaluation d’une première condition T1 par le deuxième module logiciel applicatif L2 et évaluation d’une deuxième condition T2 par le troisième module matériel L3.
Cette première condition T1 est vraie si une commande produite par le premier module logiciel applicatif L1 est proche de, ou égale à, une commande produite par le quatrième module logiciel applicatif LM, ce que représente la case conditionnelle L1 = LM sur la figure 3. On définira ici l’expression « proche de » utilisée ci-dessus à l’égard de la comparaison de commandes, par deux valeurs correspondantes de données ayant un différentiel négligeable d’un point de vue effet système. Ce différentiel est à quantifier par calibration pour chaque donnée. De manière avantageuse pour des signaux logiques, la première conditions T1 est vraie lorsqu’une commande produite par le premier module logiciel applicatif L1 est égale à une commande produite par le quatrième module logiciel applicatif LM. De préférence, pour des signaux analogiques, la première conditions T1 est vraie lorsqu’une commande produite par le premier module logiciel applicatif L1 est égale à une commande produite par le quatrième module logiciel applicatif LM, à quelques pourcents près, par exemple moins de 5%, le seuil exact étant à adapter au système par calibration.
Dans le cas contraire, T1 est fausse comme indiqué. Le deuxième module applicatif L2 est responsable de la comparaison L1 versus LM et traite la première condition T1.
La deuxième condition T2 est vraie si la surveillance du deuxième module logiciel applicatif L2 par le troisième module matériel L3 n’a détecté aucune erreur, c’est-à- dire que le deuxième module logiciel applicatif L2 fonctionne correctement car le troisième module matériel L3 n’a pas détecté d’erreur de sa part (par exemple violation d’accès mémoire, ordonnancement et cadencement des processus... ), ce qui est représenté sur la figure 3 par la case conditionnelle L2 = OK. Dans le cas contraire T2 est fausse comme indiqué. Le troisième module matériel L3 est responsable de la surveillance du deuxième module applicatif L2 et traite la deuxième condition T2.
Ensuite, en fonction des valeurs des deux conditions T1 et T2, plusieurs cas sont possibles comme représenté en partie basse sur la figure 3. Ces cas sont pris en charge par le module d’arbitrage L3D qui est responsable de la prise de décisions selon les quatre conditions possibles entre T1 et T2 comme décrit ci-dessous.
Maintenant donc, plus particulièrement en rapport avec la partie basse de la figure 3, selon un premier cas, si T1 et T2 sont toutes deux vraies, on a donc TI ET T2 comme représenté en bas et à gauche de la figure 3, le contrôle et commande est dans un cas nominal comme indiqué. Le premier module logiciel applicatif L1 produit une commande moteur sensiblement identique à une commande moteur produite par le quatrième module logiciel applicatif LM. De plus, la surveillance du premier module logiciel applicatif L1 par le deuxième module logiciel applicatif L2 n’a détecté aucune erreur. Aussi, la commande moteur issue de l’un ou l’autre des modules redondants peut être appliquée au moteur. La commande produite par le premier module logiciel applicatif L1 est préférée et est appliquée au moteur.
Selon un deuxième cas, toujours en rapport avec la figure 3, si T1 est fausse et T2 est vraie comme représenté sur la figure 3 dans la deuxième case en bas en partant de la gauche, soit si l’on a NON T1 ET T2, le contrôle commande est dans un cas dégradé. Ici les deux commandes redondantes sont divergentes. Cependant, il est fait confiance au quatrième module logiciel applicatif LM alors que l’on considère que le premier module logiciel applicatif L1 est défaillant. Aussi, la commande produite par le quatrième module logiciel applicatif LM est appliquée au moteur. Un témoin peut avantageusement s’afficher au tableau de bord du véhicule visant à informer le conducteur, par exemple allumage du témoin lumineux appelé MIL (pour « Malfunction Indicator Lamp » en anglais). Le deuxième cas NON T1 ET T2 peut traduire par exemple une défaillance du premier module L1 .
Selon un troisième cas, toujours en rapport avec la figure 3, si T1 et T2 sont toutes deux fausses, on a donc NON T1 et NON T2, comme représenté dans la troisième case en bas de la figure 3 en partant de la gauche, les deux commandes redondantes sont divergentes. On ne fait plus confiance au deuxième module L2, on ne peut pas continuer l’exécution du logiciel et le redémarrage du calculateur C est obligatoire. Il est considéré ici qu’il n’est pas possible de réaliser un arbitrage. Aussi, une mise en sécurité est commandée par réinitialisation de l’ECU.
Selon un quatrième cas, toujours en rapport avec la figure 3, si T1 est vraie et T2 est fausse comme représenté sur la figure 3 dans la quatrième case en bas en partant de la gauche, soit si l’on a T1 ET NON T2, on ne fait plus confiance au deuxième module L2, on ne peut pas continuer l’exécution du logiciel et le redémarrage du calculateur C est obligatoire. Il est considéré ici également qu’il n’est pas possible de réaliser un arbitrage. Aussi, une mise en sécurité est commandée par réinitialisation de l’ECU. Le quatrième cas T1 ET NON T2 peut traduire par exemple une défaillance du pilote de puissance matériel.
L’invention ajoute, relativement à l’art antérieur, le deuxième cas tel que décrit ci- dessus, dans lequel une certaine mobilité est possible permettant par exemple de mobiliser le véhicule jusqu’à un garage pour réparation, alors qu’une mise en sécurité avec immobilisation aurait été décrétée selon l’art antérieur.
L’invention a été illustrée et décrite en détail dans les dessins et la description précédente. Celle-ci doit être considérée comme illustrative et donnée à titre d’exemple et non comme limitant l’invention à cette seule description. De nombreuses variantes de réalisation sont possibles.

Claims

Revendications
[Revendication 1] Procédé de contrôle et commande d’un moteur de véhicule mis en œuvre dans une unité électronique de contrôle du moteur comprenant un calculateur multicœur (C), un premier module (L1 ) adapté pour assurer seul et de manière nominale et complète les fonctions de pilotage du moteur du véhicule, un deuxième module (L2) adapté pour surveiller le bon fonctionnement du premier module (L1 ) et pour commander une mise en sécurité en cas de détection d’une défaillance du premier module (L1 ), et un troisième module (L3) adapté pour surveiller le bon fonctionnement du calculateur multicœur (C) et pour mettre en œuvre ladite commande de mise en sécurité, sur requête du deuxième module (L2) ou sur détection par ses propres moyens d’une défaillance du premier module (L1 ), caractérisé en ce que : le premier module (L1 ) est adapté pour s’exécuter sur un premier cœur (C1 ) du calculateur multicœur (C), le deuxième module (L2) est adapté pour s’exécuter sur un deuxième cœur (C2) du calculateur multicœur (C), différent du premier cœur (C1 ), l’unité électronique de contrôle du moteur comprend un quatrième module (LM), adapté pour assurer de manière redondante et simplifiée les fonctions principales de pilotage du moteur du véhicule, et adapté en outre pour s’exécuter sous la surveillance du deuxième module (L2) et sur le deuxième cœur (C2), le troisième module (L3) assurant l’arbitrage entre une commande produite par le premier module (L1 ) et une commande produite par le quatrième module (LM) ; et en ce que l’arbitrage entre une commande produite par le premier module (L1 ) et une commande produite par le quatrième module (LM) comporte les étapes suivantes : évaluation d’une première condition (T1 ) : une commande produite par le premier module (L1 ) est proche de, ou égale à, une commande produite par le quatrième module (LM), évaluation d’une deuxième condition (T2) : la surveillance du deuxième module (L2) par le troisième module (L3) n’a détecté aucune erreur, si la première condition (T1 ) et la deuxième condition (T2) sont toutes deux vraies, la commande produite par le premier module (L1 ) est appliquée au moteur, si la première condition (T1 ) est fausse et la deuxième condition (T2) est vraie, la commande produite par le quatrième module (LM) est appliquée au moteur, si la première condition (T1 ) est fausse et la deuxième condition (T2) est fausse, une mise en sécurité est commandée, si la première condition (T1 ) est vraie et la deuxième condition (T2) est fausse, une mise en sécurité est commandée.
[Revendication 2] Procédé de contrôle et commande selon la revendication 1 , dans lequel le premier module (L1 ) est mis en œuvre par une couche logicielle applicative, le deuxième module (L2) est mis en œuvre par une couche logicielle applicative, le troisième module (L3) est mis en œuvre par un module matériel, et le quatrième module (LM) est mis en œuvre par une couche logicielle applicative.
[Revendication 3] Unité électronique de contrôle et commande d’un moteur de véhicule comprenant : un calculateur multicœur (C), un premier module (L1 ) adapté pour assurer seul et de manière nominale et complète les fonctions de pilotage du moteur du véhicule, un deuxième module (L2) adapté pour surveiller le bon fonctionnement du premier module (L1 ) et pour commander une mise en sécurité en cas de détection d’une défaillance du premier module (L1 ), et un troisième module (L3) adapté pour surveiller le bon fonctionnement du calculateur multicœur (C) et pour mettre en œuvre ladite commande de mise en sécurité, sur requête du deuxième module (L2) ou sur détection par ses propres moyens d’une défaillance du premier module (L1 ), caractérisée en ce que : le premier module (L1 ) est adapté pour s’exécuter sur un premier cœur (C1 ) du calculateur multicœur (C), le deuxième module (L2) est adapté pour s’exécuter sur un deuxième cœur (C2) du calculateur multicœur (C), différent du premier cœur (C1 ), l’unité électronique de contrôle du moteur comprend un quatrième module (LM) adapté pour assurer de manière redondante et simplifiée les fonctions principales de pilotage du moteur du véhicule, et adapté en outre pour s’exécuter sous la surveillance du deuxième module (L2) et sur le deuxième cœur (C2), le troisième module (L3) assurant l’arbitrage entre une commande produite par le premier module (L1 ) et une commande produite par le quatrième module (LM), et en ce que le troisième module (L3) est configuré pour que l’arbitrage entre une commande produite par le premier module (L1 ) et une commande produite par le quatrième module (LM) comporte les étapes suivantes : évaluation d’une première condition (T1 ) : une commande produite par le premier module (L1 ) est proche de, ou égale à, une commande produite par le quatrième module (LM), évaluation d’une deuxième condition (T2) : la surveillance du deuxième module (L2) par le troisième module (L3) n’a détecté aucune erreur, si la première condition (T1 ) et la deuxième condition (T2) sont toutes deux vraies, la commande produite par le premier module (L1 ) est appliquée au moteur, si la première condition (T1 ) est fausse et la deuxième condition (T2) est vraie, la commande produite par le quatrième module (LM) est appliquée au moteur, si la première condition (T1 ) est fausse et la deuxième condition (T2) est fausse, une mise en sécurité est commandée, si la première condition (T1 ) est vraie et la deuxième condition (T2) est fausse, une mise en sécurité est commandée.
[Revendication 4] Unité de contrôle et commande selon la revendication 3, dans laquelle le premier module (L1 ) est une couche logicielle, le deuxième module (L2) est une couche logicielle, le troisième module (L3) est un module matériel, et le quatrième module (LM) est une couche logicielle.
PCT/EP2022/080761 2021-11-10 2022-11-04 Procédé et dispositif de contrôle et commande d'un moteur de véhicule WO2023083703A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202280074689.5A CN118265969A (zh) 2021-11-10 2022-11-04 用于控制和命令车辆引擎的方法和设备

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2111911 2021-11-10
FR2111911A FR3129005B1 (fr) 2021-11-10 2021-11-10 Procédé et dispositif de contrôle et commande d’un moteur de véhicule

Publications (1)

Publication Number Publication Date
WO2023083703A1 true WO2023083703A1 (fr) 2023-05-19

Family

ID=79171241

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/080761 WO2023083703A1 (fr) 2021-11-10 2022-11-04 Procédé et dispositif de contrôle et commande d'un moteur de véhicule

Country Status (3)

Country Link
CN (1) CN118265969A (fr)
FR (1) FR3129005B1 (fr)
WO (1) WO2023083703A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1577773A1 (fr) 2004-03-15 2005-09-21 Siemens Aktiengesellschaft Système multiprocesseur ayant un processeur de diagnostic pour sauver l'état du système et procédé d'exploitation d'un système multiprocesseur
WO2013164224A2 (fr) 2012-04-30 2013-11-07 Robert Bosch Gmbh Procédé et dispositif de surveillance des fonctions d'un système informatique, de préférence d'un système de commande de moteur d'un véhicule à moteur
US20140351658A1 (en) * 2013-05-22 2014-11-27 GM Global Technology Operations LLC Redundant computing architecture

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1577773A1 (fr) 2004-03-15 2005-09-21 Siemens Aktiengesellschaft Système multiprocesseur ayant un processeur de diagnostic pour sauver l'état du système et procédé d'exploitation d'un système multiprocesseur
WO2013164224A2 (fr) 2012-04-30 2013-11-07 Robert Bosch Gmbh Procédé et dispositif de surveillance des fonctions d'un système informatique, de préférence d'un système de commande de moteur d'un véhicule à moteur
US20140351658A1 (en) * 2013-05-22 2014-11-27 GM Global Technology Operations LLC Redundant computing architecture

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
JONAS FRITZSCH ET AL: "Experiences from Large-Scale Model Checking: Verification of a Vehicle Control System", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 20 November 2020 (2020-11-20), XP081981480, DOI: 10.1109/ICST49551.2021.00049 *
LI MINGLU ET AL: "Fail-Operational Steer-By-Wire System for Autonomous Vehicles", 2019 IEEE INTERNATIONAL CONFERENCE OF VEHICULAR ELECTRONICS AND SAFETY (ICVES), IEEE, 4 September 2019 (2019-09-04), pages 1 - 6, XP033664652, DOI: 10.1109/ICVES.2019.8906395 *
LUO YAPING ET AL: "An architecture pattern for safety critical automated driving applications: Design and analysis", 2017 ANNUAL IEEE INTERNATIONAL SYSTEMS CONFERENCE (SYSCON), IEEE, 24 April 2017 (2017-04-24), pages 1 - 7, XP033099964, DOI: 10.1109/SYSCON.2017.7934739 *
NÄGLER ET AL: "Standardized E-Gas Monitoring Concept for Gasoline and Diesel Engine Control Units Version 6.0", 13 July 2015 (2015-07-13), pages 1 - 57, XP055935091, Retrieved from the Internet <URL:https://nanopdf.com/downloadFile/standardized-e-gas-monitoring-concept-for-gasoline-and_pdf> [retrieved on 20220624] *

Also Published As

Publication number Publication date
FR3129005B1 (fr) 2024-03-22
CN118265969A (zh) 2024-06-28
FR3129005A1 (fr) 2023-05-12

Similar Documents

Publication Publication Date Title
EP1960243B1 (fr) Procede de controle du fonctionnement d&#39;un vehicule base sur une strategie de diagnostic embarque definissant differents types de pannes
EP2222946B1 (fr) Procede et dispositif de controle securise d&#39;un systeme a alterno-demarreur couple a un moteur thermique d&#39;un vehicule, et systeme a alterno-demarreur et liaisons filaires correspondant
FR2934549A1 (fr) Procede et systeme de diagnostic de l&#39;etat de fonctionnement d&#39;un systeme de demarrage assiste d&#39;un vehicule automobile.
FR2681302A1 (fr) Dispositif de direction assistee.
WO2017036584A1 (fr) Procédé de détection d&#39;une erreur non corrigible dans une mémoire non volatile d&#39;un microcontrôleur
FR2986398A1 (fr) Dispositif de securite pour la commande d&#39;un moteur comprenant une redondance des acquisitions d&#39;une mesure de capteurs
FR2891502A1 (fr) Procede d&#39;amelioration d&#39;un diagnostic d&#39;une eventuelle defaillance dans un vehicule
WO2023083703A1 (fr) Procédé et dispositif de contrôle et commande d&#39;un moteur de véhicule
WO2018050994A1 (fr) Procédé de détection de défaillances
EP2254791B1 (fr) Procede et systeme de desactivation d&#39;un systeme d&#39;orientation d&#39;un train d&#39;atterrissage avant d&#39;un aeronef
EP2822789A1 (fr) Procede de gestion d&#39;un dispositif thermodynamique pour vehicule automobile, systeme, programme, support d&#39;enregistrement et vehicule associe
EP3661827A1 (fr) Procede d&#39;elaboration d&#39;une consigne de pilotage d&#39;un organe de conduite d&#39;un vehicule automobile
FR3023047A1 (fr) Procede de gestion de messages de panne d&#39;un vehicule automobile
EP3513294B1 (fr) Dispositif de controle de la reinitialisation d&#39;un calculateur embarque automobile
EP2219898A1 (fr) Procede de gestion de dysfonctionnements d&#39;un systeme de controle a architecture modulaire d&#39;un groupe motopropulseur de vehicule automobile et systeme de controle correspondant
EP3058209B1 (fr) Procédé de surveillance d&#39;un système de verrouillage pour inverseur de poussée de turbomachine
FR3038659A1 (fr) Procede de gestion des pannes pour un systeme de controle moteur de vehicule
EP1660765B1 (fr) Procede de detection de la defaillance d&#39;un signal representatif de l&#39;enfoncement d&#39;une pedale d&#39;acceleration de vehicule automobile
FR2927596A3 (fr) Procede de commande d&#39;un systeme de controle d&#39;un groupe motopropulseur de vehicule et systeme de controle correspondant
WO2023083693A1 (fr) Module et procédé d&#39;aide à la conduite d&#39;un véhicule automobile
FR3033428A1 (fr) Procede de determination de l&#39;origine d&#39;un defaut de securite
FR2682201A1 (fr) Procede de discrimination temporelle de pannes dans un systeme hierarchise de traitement de donnees, et systeme hierarchise de traitement de donnees adapte a sa mise en óoeuvre.
FR3073348B1 (fr) Systeme et procede de traitement et de securisation d’un signal transmis par un capteur
WO2021001168A1 (fr) Procede de test d&#39;un dispositif de reinitialisation de calculateur
WO2022189610A1 (fr) Procédé pour l&#39;immunité contre la réinitialisation intempestive d&#39;une unité roue

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22812635

Country of ref document: EP

Kind code of ref document: A1