FR3098316A1 - Procédé de test d’un dispositif de réinitialisation de calculateur - Google Patents
Procédé de test d’un dispositif de réinitialisation de calculateur Download PDFInfo
- Publication number
- FR3098316A1 FR3098316A1 FR1907441A FR1907441A FR3098316A1 FR 3098316 A1 FR3098316 A1 FR 3098316A1 FR 1907441 A FR1907441 A FR 1907441A FR 1907441 A FR1907441 A FR 1907441A FR 3098316 A1 FR3098316 A1 FR 3098316A1
- Authority
- FR
- France
- Prior art keywords
- reset
- test
- computer
- duration
- sequence
- 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.)
- Granted
Links
- 238000012360 testing method Methods 0.000 title claims abstract description 103
- 238000000034 method Methods 0.000 title claims abstract description 21
- 238000012795 verification Methods 0.000 claims abstract description 35
- 238000011065 in-situ storage Methods 0.000 claims abstract description 6
- 238000003860 storage Methods 0.000 claims abstract description 6
- 238000002347 injection Methods 0.000 claims description 5
- 239000007924 injection Substances 0.000 claims description 5
- 238000002485 combustion reaction Methods 0.000 claims description 4
- 238000012217 deletion Methods 0.000 claims 1
- 230000037430 deletion Effects 0.000 claims 1
- 238000004891 communication Methods 0.000 description 7
- 239000013256 coordination polymer Substances 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 4
- 210000000056 organ Anatomy 0.000 description 3
- 238000010998 test method Methods 0.000 description 3
- 238000001514 detection method Methods 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 1
- 235000014510 cooky Nutrition 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
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/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
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/076—Error or fault detection not based on redundancy by exceeding limits by exceeding a count or rate limit, e.g. word- or bit count limit
-
- 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
- G06F11/0754—Error or fault detection not based on redundancy by exceeding limits
- G06F11/0757—Error or fault detection not based on redundancy by exceeding limits by exceeding a time limit, i.e. time-out, e.g. watchdogs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR 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/2284—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing by power-on test, e.g. power-on self test [POST]
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)
- Techniques For Improving Reliability Of Storages (AREA)
- Debugging And Monitoring (AREA)
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
Procédé de test in situ et en fonctionnement d’un dispositif de réinitialisation (1) d’un calculateur (2), comprenant une séquence d’exécution et une séquence de vérification, la séquence d’exécution étant exécutée en cours d’exécution du logiciel (L1, L2) et comprenant les étapes suivantes : - incrémentation d’un compteur de test, - stockage du compteur de test dans une mémoire non volatile (3), - déclenchement d’une réinitialisation du calculateur (2), la séquence de vérification étant exécutée au démarrage du logiciel (L1, L2) et comprenant les étapes suivantes : - lecture depuis la mémoire non volatile (3) du compteur de test, - comparaison du compteur de test, si il est égal à sa valeur initiale augmentée de 1, réinitialisation du compteur de test (CT), le résultat du test est positif, et si il est supérieur à sa valeur initiale augmentée de 1, le résultat du test est négatif. Figure d’abrégé : Figure 1
Description
L’invention concerne les calculateurs en environnement critique, tels que les calculateurs pour contrôler les moteurs, et plus particulièrement un procédé permettant de tester le bon fonctionnement d’un dispositif de réinitialisation d’un tel calculateur.
Un calculateur comprend typiquement un matériel et un logiciel. Le matériel est apte à exécuter le logiciel afin de réaliser une fonction de pilotage d’un organe. Il est connu de sécuriser un tel calculateur en lui adjoignant au moins un module matériel et/ou logiciel apte à surveiller le bon fonctionnement du calculateur et, le cas échéant, à prendre des mesures conservatoires.
Tel qu’illustré à la figure 1, montrant une organisation utilisée dans l’automobile, selon la norme VDA, un calculateur 2, tel un calculateur moteur, exécute un logiciel nominal L1 (de niveau 1 ou « level 1 » en anglais) assurant les fonctions de contrôle moteur. Un premier module de surveillance, sous la forme d’un logiciel de surveillance L2 (de niveau 2 ou « level 2 » en anglais) surveille le bon fonctionnement du logiciel L1, notamment en reproduisant certains calculs critiques et en comparant ses résultats avec ceux obtenus par le logiciel nominal L1. Lorsque L2 détecte un problème, L2 met en œuvre une stratégie conservatoire en fonction du problème. Une telle stratégie conservatoire, comprend par ordre croissant de gravité du problème : un fonctionnement en mode dégradé, un arrêt de l’injection ou une réinitialisation du calculateur 2.
Le mode dégradé suppose que le calculateur 2 et le logiciel L1 maintiennent certaines capacités de fonctionnement. Le logiciel L2 envoi un ordre de passage en mode dégradé au logiciel L1 qui l’exécute. Le mode dégradé permet un fonctionnement dégradé, par exemple imposer une vitesse réduite, du moteur, permettant de déplacer le véhicule, typiquement pour le conduire jusqu’à un garage.
L’arrêt de l’injection vise à stopper le moteur afin d’éviter un accident. Il est supposé que le calculateur 2 et/ou le logiciel L1 n’est plus assez fiable. Aussi cette commande, décidée par le logiciel L2, est réalisée par un dispositif L3 (de niveau ou « level » en anglais 3) indépendant du calculateur 2 et typiquement matériel uniquement (typiquement un circuit électronique, tel un ASIC), qui agit directement sur les injecteurs.
La réinitialisation, en dernier recours, a pour but de réinitialiser le calculateur 2 en espérant remettre, tant le calculateur 2 que le logiciel L1et le logiciel L2, dans un état nominal. La fiabilité du calculateur 2 et/ou du logiciel L1 étant questionné, cette commande, généralement décidée/déclenchée par le logiciel L2, est réalisée par le dispositif L3 indépendant du calculateur 2 qui agit directement sur le calculateur 2. Le dispositif L3 est aussi apte à réaliser certains tests de bon fonctionnement de lui-même, du calculateur 2 et/ou du moyen de communication entre lui et le calculateur 2. En cas de détection d’une défaillance, le dispositif L3 peut décider de déclencher une réinitialisation.
S’agissant d’une sécurité de niveau ultime, la réinitialisation peut être critique. Il convient de vérifier que le déclenchement d’une réinitialisation fonctionne bien. Il est connu de tester cette fonction en sortie de fabrication. Ensuite, selon l’art antérieur elle n’est généralement plus testée.
Afin de pallier cette carence, l’invention propose un procédé de test d’un dispositif de réinitialisation L3 d’un calculateur 2, avantageusement utilisable in situ et même durant le fonctionnement du calculateur 2 et de l’organe M.
Pour cela l’invention concerne un procédé de test in situ et en fonctionnement d’un dispositif de réinitialisation d’un calculateur, ledit dispositif exécutant au moins un logiciel de réinitialisation, le dit calculateur exécutant au moins un logiciel de pilotage afin de piloter un organe, ledit procédé comprenant une séquence d’exécution et une séquence de vérification, la séquence d’exécution étant exécutée en cours d’exécution du logiciel de pilotage et comprenant les étapes suivantes : - incrémentation d’un compteur de test, - stockage du compteur de test dans une mémoire non volatile, - déclenchement d’une réinitialisation du calculateur,
la séquence de vérification étant exécutée au démarrage du logiciel de pilotage et comprenant les étapes suivantes : - lecture depuis la mémoire non volatile du compteur de test, - comparaison du compteur de test, si le compteur de test est égal à sa valeur initiale il n’y a pas de résultat de test, si le compteur de test est égal à sa valeur initiale augmentée de 1, réinitialisation du compteur de test, le résultat du test est positif, et si la valeur du compteur de test est autre, création d’une erreur « réinitialisation », le résultat du test est négatif.
Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison, sont :
- la séquence d’exécution comprend encore une étape de : - stockage d’un indicateur de test dans une mémoire non volatile, et la séquence de vérification comprend encore les étapes suivantes : - vérification de la présence de l’indicateur de test dans la mémoire non volatile, réinitialisation du compteur de test seulement si l’indicateur de test est présent, suppression de l’indicateur de test.
- la séquence d’exécution comprend encore une étape de : - stockage d’un indicateur de test dans une mémoire non volatile, et la séquence de vérification comprend encore les étapes suivantes : - vérification de la présence de l’indicateur de test dans la mémoire non volatile, réinitialisation du compteur de test seulement si l’indicateur de test est présent, suppression de l’indicateur de test.
- la séquence d’exécution comprend encore une étape de : - stockage d’une date de réinitialisation dans une mémoire non volatile, et la séquence de vérification comprend encore les étapes suivantes : - lecture de la date de réinitialisation depuis la mémoire non volatile, - détermination d’une durée de réinitialisation par différence entre la date de réinitialisation et la date courante, - comparaison de la durée de réinitialisation avec un seuil maximum, si la durée de réinitialisation est supérieure au seuil maximum : création d’une erreur « durée » et le résultat du test est négatif.
- la séquence d’exécution comprend encore une étape initiale de : - vérification de l’état de l’organe, les autres étapes de la séquence d’exécution n’étant exécutées que quand l’organe est inactif.
- l’organe est un moteur à explosion, et est inactif lorsque l’injection est arrêtée.
- le procédé comprend encore une étape préalable de vérification d’une condition préalable à son exécution, ladite condition étant préférentiellement déterminée selon au moins un critère parmi : durée calendaire, durée de fonctionnement du calculateur et/ou nombre de cycles de fonctionnement de l’organe.
- le procédé comprend encore une étape de : - allumage d’au moins un témoin si le résultat du test est négatif, si l’erreur « réinitialisation » est créée et/ou si l’erreur « durée » est créée.
- l’organe est un moteur à explosion, et est inactif lorsque l’injection est arrêtée.
- le procédé comprend encore une étape préalable de vérification d’une condition préalable à son exécution, ladite condition étant préférentiellement déterminée selon au moins un critère parmi : durée calendaire, durée de fonctionnement du calculateur et/ou nombre de cycles de fonctionnement de l’organe.
- le procédé comprend encore une étape de : - allumage d’au moins un témoin si le résultat du test est négatif, si l’erreur « réinitialisation » est créée et/ou si l’erreur « durée » est créée.
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 :
Le procédé selon l’invention intervient en relation avec un calculateur 2 tel qu’illustré à la figure 1. Ce calculateur 2 exécute au moins un logiciel L1, L2, afin de piloter un organe M. L’organe peut par exemple être un moteur M à explosion et le calculateur 2 est un calculateur de contrôle moteur. Le logiciel L1 dispose de capteurs 11 afin d’observer l’état de l’organe M et d’actionneurs 10 afin d’influer sur ledit état. Du fait de la possible criticité des actions commandées par le calculateur 2, ce dernier est sécurisé. Un premier niveau de sécurité est apporté par un logiciel L2 de surveillance. Ce dernier échange des informations avec L1 au moyen de liens 13,14. Il peut encore être équipé de capteurs 12 supplémentaires. Une mémoire non volatile 3 permet d’enregistrer des informations rémanentes d’un arrêt du calculateur 2, par coupure d’alimentation ou encore par réinitialisation. Le logiciel L2 et/ou le calculateur 2 pouvant aussi être défaillants, comme décrit plus haut, le calculateur 2 est équipé d’un dispositif de réinitialisation 1, L3, apte à réinitialiser le calculateur 2 en cas de défaillance détectée. La réinitialisation a pour but, en dernier recours, de réinitialiser le calculateur 2 en espérant remettre, tant le calculateur 2 que le logiciel L1et éventuellement le logiciel L2, dans un état nominal. La fiabilité du calculateur 2 et/ou du logiciel L1 étant questionné, la réinitialisation est réalisée par le dispositif 1, L3 indépendant du calculateur 2. Ce dernier agit directement sur le calculateur 2 via le moyen 17, par exemple en agissant sur la broche reset du calculateur 2. La réinitialisation est généralement décidée par le logiciel L2 et transmise via le moyen de communication 15. Le moyen de communication 16 permet au dispositif L3, 1, d’informer L2 en retour. Le dispositif L3 est aussi apte à réaliser certains tests de bon fonctionnement de lui-même, du calculateur 2 et/ou des moyens de communication 15, 16, 17 entre lui et le calculateur 2. En cas de détection d’une défaillance, le dispositif L3 peut décider de lui-même de déclencher une réinitialisation, toujours via le moyen 17.
L’invention a pour objet de vérifier que l’exécution de la réinitialisation, depuis sa décision, jusqu’au retour du calculateur 2 à un état fonctionnel, se déroule correctement, afin que la sécurité puisse compter sur ce dispositif 1, L3 de sécurité. Pour cela, l’invention a pour objet d’exécuter une réinitialisation de test afin de vérifier qu’une décision de réinitialisation aboutit bien à une réinitialisation effective du calculateur 2. Cette réinitialisation est avantageusement réalisée in situ, le calculateur 2 étant opérationnellement installé, et en fonctionnement, le calculateur 2 et l’organe M étant en fonctionnement lors du test. Ladite réinitialisation est observée pendant son exécution afin de vérifier son bon déroulement.
Pour cela le procédé de test comprend une séquence d’exécution S1 apte à commander une réinitialisation en envoyant un ordre de réinitialisation au dispositif 1 de réinitialisation. La séquence d’exécution S1 est exécutée en cours d’exécution du logiciel L1, L2. Le cas échéant, le procédé peut choisir un moment privilégié plus propice qu’un autre.
De plus, le procédé comprend encore une séquence de vérification S2. Cette séquence est apte à observer le dispositif 1 et/ou le calculateur 2, suite à l’envoi de l’ordre de réinitialisation, afin de vérifier que ce dernier a bien été exécuté et qu’une réinitialisation du calculateur 2 fait suite au dit ordre et qu’elle se déroule correctement. Pour cela la séquence de vérification S2 est préférentiellement exécutée suite au (re)démarrage du logiciel L1, L2. Ceci permet d’exécuter la séquence de vérification S2 immédiatement après un démarrage du calculateur 2 et ainsi au plus près après un redémarrage du calculateur 2 qui suit une réinitialisation.
Tant la séquence d’exécution S1 que la séquence de vérification S2 sont avantageusement des modules logiciels. Ces modules sont fonctionnellement de niveau L3 ou de niveau L2. Ils sont exécutés par le calculateur 2 et avantageusement déclenchés par le logiciel L1.
La figure 2 illustre la séquence d’exécution S1. Le calculateur 2 voit sa mémoire effacée pendant une réinitialisation. Aussi avant de procéder à une réinitialisation, la séquence d’exécution S1 réalise une ou plusieurs étapes de stockage d’information. Ces informations sont stockées dans une mémoire non volatile 3 afin d’être persistantes. L’état de ces informations, lors de leur relecture par la séquence de vérification S2 va permettre de distinguer un démarrage nominal, un démarrage suite à un test de réinitialisation ou encore une absence de réinitialisation alors qu’un test avait été demandé et ainsi permettre de déterminer un résultat de test.
Selon une caractéristique, une étape E13 réalise une incrémentation d’un compteur de test CT. Ce compteur de test CT compte le nombre de tests de réinitialisation demandés par la séquence d’exécution S1. Il est ensuite enregistré en mémoire non volatile 3 au cours d’une étape E14. Le compteur de test CT est avantageusement stocké dans une mémoire non volatile permanente. Ensuite la séquence d’exécution S1 procède au déclenchement, lors d’une étape E17, d’une réinitialisation du calculateur 2. Ceci s’effectue en adressant une demande au dispositif 1, L3, via le moyen 15.
La séquence d’exécution S1 est avantageusement implémentée par un logiciel s’exécutant sur le calculateur 2. Aussi l’étape E17 met normalement fin à la séquence d’exécution S1, si le calculateur 2 est réinitialisé. Une étape faisant suite à E17 pourrait permettre de constater une absence de réinitialisation. Cette option n’a pas été retenue par l’invention.
Selon l’invention, la séquence de vérification S2 est en charge de détecter le bon ou le mauvais fonctionnement de la réinitialisation. Pour cela la séquence de vérification S2 est exécutée au démarrage du calculateur 2. Elle comprend les étapes suivantes illustrées à la figure 3. Selon une caractéristique, une première étape E23 consiste en une lecture, depuis la mémoire non volatile 3, du compteur de test CT. Au cours d’une étape E24 suivante, ce compteur de test CT est comparé avec ses possibles valeurs. Si le compteur de test CT est égal à sa valeur initiale, soit la valeur avant toute incrémentation E13, ceci est indicatif d’une absence d’exécution préalable de la séquence d’exécution S1. Aussi, aucun test de réinitialisation n’a encore été demandé. Aussi il ne peut y avoir de résultat de test. Il peut être mis fin à la séquence de vérification S2 en branchant vers l’étape E30 terminale. Si le compteur de test CT est égal à sa valeur initiale augmentée de 1, il peut être considéré que la séquence d’exécution S1 a été exécutée une fois et que le redémarrage en cours fait suite à la réinitialisation E17 qui a suivi. Il peut ainsi être considéré qu’un test a été demandé et qu’il s’est bien déroulé. Aussi dans ce cas, la comparaison E24 branche sur l’étape E25 qui réalise une réinitialisation du compteur de test CT, qui reprend sa valeur initiale, par exemple 0. Le test s’étant bien déroulé, la séquence de vérification S2 peut se poursuivre à l’étape E29 avec un résultat de test positif, OK. Si la valeur du compteur de test CT est autre, et notamment si elle est supérieure à la valeur initiale augmentée de 1, ceci résulte d’au moins deux opérations d’incrémentation dans une étape E13, et donc d’au moins deux exécutions de la séquence d’exécution S1 avec deux déclenchements E17 d’une réinitialisation, sans exécution en suivant d’une séquence de vérification S2. Il peut ici être déduit qu’au moins une des demandes de réinitialisation E17 qui a suivi une étape d’incrémentation E13 n’a pas été suivie d’une réinitialisation effective du calculateur 2. Sinon le compteur de test CT aurait été réinitialisé à l’étape E25. Aussi, dans ce cas, la comparaison E24 branche sur une étape E31 de création d’une erreur « réinitialisation ». La séquence de vérification S2 se poursuit et se termine à l’étape E32 avec un résultat de test négatif, NOK.
Le procédé de test peut encore comprendre d’autres caractéristiques, seules ou en combinaison, permettant autant de variantes de modes de réalisation.
Selon une autre caractéristique, la séquence d’exécution S1 comprend encore une étape d’écriture/ stockage E15 d’un indicateur de test IT dans une mémoire non volatile 3. L’indicateur de test IT est avantageusement stocké dans une mémoire non effacée lors d’une réinitialisation. Cet indicateur de test IT comprend typiquement une donnée présente ou absente ou encore une variable contenant une certaine valeur. La séquence de vérification S2 comprend encore, de manière complémentaire, les étapes suivantes. La présence dudit indicateur de test IT est vérifiée par une lecture E21 de la mémoire non volatile 3 à sa recherche. Si cet indicateur de test IT est trouvé E22, ceci confirme qu’un test de réinitialisation est en cours. Aussi une réinitialisation E25 du compteur de test CT peut être réalisée. Au cours de l’étape E25 l’indicateur de test est alors aussi supprimé. A défaut, si aucun indicateur de test IT ne peut être trouvé dans la mémoire non volatile 3, la comparaison E22 branche vers l’étape E30 qui met fin à la séquence de vérification S2. Il n’y a pas de résultat de test dans ce cas. L’utilisation d’un indicateur de test IT permet de confirmer le cas où un test a été demandé sans s’appuyer uniquement sur le compteur de test CT.
Selon une autre caractéristique, le procédé de test encore mis à profit pour tester, si la réinitialisation s’exécute, qu’elle s’exécute dans un temps suffisamment court. Pour cela, la séquence d’exécution S1 comprend encore une étape de stockage E16 d’une date de réinitialisation TR dans une mémoire non volatile 3. La date de réinitialisation TR est avantageusement stockée dans une mémoire non volatile permanente. Cette date de réinitialisation TR est suffisamment proche de la demande de réinitialisation E17 pour être considérée être la date de début de réinitialisation. La séquence de vérification S2 comprend encore, de son côté, les étapes suivantes : lecture E26 de la date de réinitialisation TR depuis la mémoire non volatile 3 et détermination E27 d’une durée de réinitialisation DR, par différence, DR = T – TR, entre la date de réinitialisation TR et la date courante T. La date courante T est suffisamment proche de l’instant où le calculateur 2 et son logiciel redeviennent opérationnels après la réinitialisation, pour être considérée être la date de fin de réinitialisation. Aussi la durée DR peut être considérée être la durée totale de réinitialisation, depuis la demande de réinitialisation E17 jusqu’au retour à un état opérationnel. La séquence de vérification S2 comprend encore avantageusement une étape de comparaison E28 de la durée de réinitialisation DR avec un seuil maximum S. Ce seuil S de durée est typiquement fixé de manière réglementaire ou législative. A titre indicatif, le seuil S est de quelques dizaines de millisecondes, préférentiellement 150 ms. Si la durée de réinitialisation DR est supérieure au seuil maximum S, la séquence de vérification S2 branche vers une étape E33 de création d’une erreur « durée ». La séquence de vérification S2 se poursuit à l’étape terminale E34 avec un résultat de test négatif, NOK. Si au contraire, la durée de réinitialisation DR est inférieure au seuil S, la séquence de vérification S2 se poursuit à l’étape terminale E29 avec un résultat de test positif.
Afin de ne pas perturber le pilotage de l’organe M, l’instant où une réinitialisation E17 est déclenchée est choisi de préférence lorsque l’organe M est inactif. Ceci garantit que le pilotage de l’organe M est peu ou pas perturbé par le test, qui peut ainsi être réalisé in situ et en cours de fonctionnement. Pour cela la séquence d’exécution S1 comprend encore une étape E12 de vérification de l’état de l’organe M. Si l’organe M est actif, la vérification E12 branche sur une étape E18 de fin de la séquence d’exécution S1. Alternativement, la séquence d’exécution S1 peut être mise en attente, jusqu’à ce que l’état de l’organe M devienne inactif. Si l’organe M est ou devient inactif la séquence d’exécution S1 se poursuit par la réalisation des autres étapes E13-E17, telles que décrites précédemment.
Dans le cas où l’organe M est un moteur à combustion interne, le moteur M est considéré inactif lorsque l’injection est coupée. Ceci correspond, par exemple, à un moteur M arrêté ou à un moteur en marche, dans une phase de décélération et/ou de relâchement de la pédale d’accélérateur. Ceci assure que le test n’est pas perçu par le conducteur ou s’il est perceptible, qu’il n’est pas gênant pour le conducteur.
La fonction de réinitialisation doit être testée de temps en temps. Il n’est cependant pas nécessaire de reproduire le test trop souvent. Aussi selon une autre caractéristique, une condition préalable CP est vérifiée au cours d’une étape E11 de la séquence d’exécution S1 avant tout déclenchement E17 d’une réinitialisation. Cette condition préalable CP peut être déterminée selon tout critère permettant de différer une exécution. Ainsi la condition préalable CP peut, par exemple, être déterminée sur un ou plusieurs critères choisis parmi : une durée calendaire, une durée de fonctionnement du calculateur 2 et/ou un nombre de cycles de fonctionnement de l’organe M.
Si le critère de durée calendaire est utilisé, la séquence d’exécution S1 d’un test de réinitialisation et donc un déclenchement d’une réinitialisation de test E17 ne pourra être exécutée que si la dernière réinitialisation de test E17 a été exécutée il y a plus que ladite durée calendaire. Une durée calendaire peut, par exemple, être une heure, 3 jours ou encore 1 mois. De même si le critère de durée de fonctionnement du calculateur 2 est utilisé, un déclenchement d’une réinitialisation de test E17 ne pourra être exécuté que si le calculateur a fonctionné au moins la durée de fonctionnement prescrite depuis la dernière réinitialisation de test E17. Une durée de fonctionnement peut, par exemple, être une heure, 3 jours ou encore 1 mois. De même si le critère de nombre de cycles de fonctionnement de l’organe M est utilisé, un déclenchement d’une réinitialisation de test E17 ne pourra être exécuté que si l’organe M a effectué au moins ledit nombre de cycles de fonctionnement depuis la dernière réinitialisation de test E17. Un nombre de cycles de fonctionnement peut, par exemple, être 100. Dans le cas où l’organe M est un moteur à combustion interne, un cycle comprend un fonctionnement compris entre un démarrage et une coupure de contact.
Deux ou plus critères peuvent être combinés par des opérateurs OU et/ou ET.
Selon une autre caractéristique, le procédé comprend encore une étape d’allumage d’au moins un témoin si le résultat du test est négatif NOK. Un témoin individualisé ou un unique témoin commun peut être allumé en cas d’erreur « réinitialisation » et/ou en cas d’erreur « durée ». Le ou les témoins peuvent être visuels et/ou sonores. Dans le cas d’un véhicule automobile le témoin est avantageusement affiché à la planche de bord de manière à alerter le conducteur.
Avantageusement un allumage d’un témoin est doublé d’un enregistrement, avantageusement daté, préférentiellement en mémoire non volatile, à l’attention des équipes de maintenance.
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.
1 : dispositif de réinitialisation, L3,
2 : calculateur,
3 : mémoire non volatile,
10, 11 : entrées/sorties de L1 avec organe,
12 : entrées de L2,
13, 14 : moyens de communication entre L1 et L2,
15, 16 : moyens de communication entre L2 et L3,
17 : moyen de communication de réinitialisation,
L1, L2 : logiciel de niveau 1, respectivement 2,
L3 : dispositif de réinitialisation, de niveau 3,
S1 : séquence d’exécution,
S2 : séquence de vérification,
E11-E18 : étapes de S1,
2 : calculateur,
3 : mémoire non volatile,
10, 11 : entrées/sorties de L1 avec organe,
12 : entrées de L2,
13, 14 : moyens de communication entre L1 et L2,
15, 16 : moyens de communication entre L2 et L3,
17 : moyen de communication de réinitialisation,
L1, L2 : logiciel de niveau 1, respectivement 2,
L3 : dispositif de réinitialisation, de niveau 3,
S1 : séquence d’exécution,
S2 : séquence de vérification,
E11-E18 : étapes de S1,
E21-E34 : étapes de S2,
M : organe,
CP : condition préalable,
CT : compteur de test,
IT : indicateur de test,
TR : temps de réinitialisation,
T : temps courant,
T : temps courant,
DR : durée de réinitialisation.
Claims (7)
- Procédé de test in situ et en fonctionnement d’un dispositif de réinitialisation (1) d’un calculateur (2), ledit dispositif exécutant au moins un logiciel (L3) de réinitialisation, le dit calculateur (2) exécutant au moins un logiciel (L1, L2) de pilotage afin de piloter un organe (M), caractérisé en ce qu ’il comprend une séquence d’exécution (S1) et une séquence de vérification (S2), la séquence d’exécution (S1) étant exécutée en cours d’exécution du logiciel (L1, L2) de pilotage et comprenant les étapes suivantes :
- incrémentation (E13) d’un compteur de test (CT),
- stockage (E14) du compteur de test (CT) dans une mémoire non volatile (3),
- déclenchement (E17) d’une réinitialisation du calculateur (2),
la séquence de vérification (S2) étant exécutée au démarrage du logiciel (L1, L2) de pilotage et comprenant les étapes suivantes :
- lecture (E23) depuis la mémoire non volatile (3) du compteur de test (CT),
- comparaison (E24) du compteur de test (CT), si le compteur de test (CT) est égal à sa valeur initiale il n’y a pas de résultat de test, si le compteur de test (CT) est égal à sa valeur initiale augmentée de 1, réinitialisation (E25) du compteur de test (CT), le résultat (E29) du test est positif (OK), et si la valeur du compteur de test (CT) est autre, création (E31) d’une erreur « réinitialisation », le résultat (E32) du test est négatif (NOK). - Procédé selon la revendication 1, où la séquence d’exécution (S1) comprend encore une étape de :
- stockage (E15) d’un indicateur de test (IT) dans une mémoire non volatile (3),
et la séquence de vérification (S2) comprend encore les étapes suivantes :
- vérification (E21, E22) de la présence de l’indicateur de test (IT) dans la mémoire non volatile (3), réinitialisation (E25) du compteur de test (CT) seulement si l’indicateur de test (IT) est présent, suppression (E25) de l’indicateur de test (IT). - Procédé selon l’une quelconque des revendications 1 ou 2, où la séquence d’exécution (S1) comprend encore une étape de :
- stockage (E16) d’une date de réinitialisation (TR) dans une mémoire non volatile (3),
et la séquence de vérification (S2) comprend encore les étapes suivantes :
- lecture (E26) de la date de réinitialisation (TR) depuis la mémoire non volatile (3),
- détermination (E27) d’une durée de réinitialisation (DR) par différence entre la date de réinitialisation (TR) et la date courante (T),
- comparaison (E28) de la durée de réinitialisation (DR) avec un seuil maximum (S), si la durée de réinitialisation (DR) est supérieure au seuil maximum (S) : création (E33) d’une erreur « durée » et le résultat (E34) du test est négatif (NOK). - Procédé selon l’une quelconque des revendications 1 à 3, où la séquence d’exécution (S1) comprend encore une étape initiale de :
- vérification (E12) de l’état de l’organe (M), les autres étapes de la séquence d’exécution (S1) n’étant exécutées que quand l’organe (M) est inactif. - Procédé selon la revendication 4, où l’organe (M) est un moteur à explosion, et est inactif lorsque l’injection est arrêtée.
- Procédé selon l’une quelconque des revendications 1 à 4, comprenant encore une étape (E11) préalable de vérification d’une condition préalable (CP) à son exécution, ladite condition étant préférentiellement déterminée selon au moins un critère parmi : durée calendaire, durée de fonctionnement du calculateur (2) et/ou nombre de cycles de fonctionnement de l’organe (M).
- Procédé selon l’une quelconque des revendications 1 à 5, comprenant encore une étape de :
- allumage d’au moins un témoin si le résultat du test est négatif (NOK), si l’erreur « réinitialisation » est créée et/ou si l’erreur « durée » est créée.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1907441A FR3098316B1 (fr) | 2019-07-04 | 2019-07-04 | Procédé de test d’un dispositif de réinitialisation de calculateur |
| PCT/EP2020/067077 WO2021001168A1 (fr) | 2019-07-04 | 2020-06-19 | Procede de test d'un dispositif de reinitialisation de calculateur |
| US17/618,645 US11687394B2 (en) | 2019-07-04 | 2020-06-19 | Method for testing a computer reset device |
| CN202080048903.0A CN114144766A (zh) | 2019-07-04 | 2020-06-19 | 计算机的重新初始化装置的测试方法 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1907441A FR3098316B1 (fr) | 2019-07-04 | 2019-07-04 | Procédé de test d’un dispositif de réinitialisation de calculateur |
| FR1907441 | 2019-07-04 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3098316A1 true FR3098316A1 (fr) | 2021-01-08 |
| FR3098316B1 FR3098316B1 (fr) | 2021-05-28 |
Family
ID=68138497
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1907441A Active FR3098316B1 (fr) | 2019-07-04 | 2019-07-04 | Procédé de test d’un dispositif de réinitialisation de calculateur |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US11687394B2 (fr) |
| CN (1) | CN114144766A (fr) |
| FR (1) | FR3098316B1 (fr) |
| WO (1) | WO2021001168A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014019416A (ja) * | 2012-07-24 | 2014-02-03 | Hitachi Automotive Systems Ltd | 車両制御装置 |
| US20160117132A1 (en) * | 2013-06-06 | 2016-04-28 | Continental Automotive France | Method for optimizing the use of a non-volatile memory in a motor vehicle computer for monitoring a functional member |
| US20190188084A1 (en) * | 2016-09-13 | 2019-06-20 | Psa Automobiles Sa | Device for controlling the reinitialization of a computer on board an automobile |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6647301B1 (en) | 1999-04-22 | 2003-11-11 | Dow Global Technologies Inc. | Process control system with integrated safety control system |
| JP2001063492A (ja) | 1999-08-27 | 2001-03-13 | Nec Corp | 車両安全制御装置の電子制御装置 |
| US9043078B2 (en) * | 2010-08-13 | 2015-05-26 | Deere & Company | Method and system for performing diagnostics or software maintenance for a vehicle |
| US9823296B2 (en) | 2012-06-07 | 2017-11-21 | Nxp Usa, Inc. | Built-in self test system, system on a chip and method for controlling built-in self tests |
| US10018267B2 (en) * | 2016-03-11 | 2018-07-10 | Ford Global Technologies, Llc | Vehicle transmission control module reset detection and mitigation |
-
2019
- 2019-07-04 FR FR1907441A patent/FR3098316B1/fr active Active
-
2020
- 2020-06-19 WO PCT/EP2020/067077 patent/WO2021001168A1/fr active Application Filing
- 2020-06-19 CN CN202080048903.0A patent/CN114144766A/zh active Pending
- 2020-06-19 US US17/618,645 patent/US11687394B2/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014019416A (ja) * | 2012-07-24 | 2014-02-03 | Hitachi Automotive Systems Ltd | 車両制御装置 |
| US20160117132A1 (en) * | 2013-06-06 | 2016-04-28 | Continental Automotive France | Method for optimizing the use of a non-volatile memory in a motor vehicle computer for monitoring a functional member |
| US20190188084A1 (en) * | 2016-09-13 | 2019-06-20 | Psa Automobiles Sa | Device for controlling the reinitialization of a computer on board an automobile |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3098316B1 (fr) | 2021-05-28 |
| US11687394B2 (en) | 2023-06-27 |
| WO2021001168A1 (fr) | 2021-01-07 |
| CN114144766A (zh) | 2022-03-04 |
| US20220358004A1 (en) | 2022-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2894548A1 (fr) | Procede de controle du fonctionnement d'un vehicule base sur une strategie de diagnostic embarque definissant differents types de pannes | |
| FR2681302A1 (fr) | Dispositif de direction assistee. | |
| WO2017036584A1 (fr) | Procédé de détection d'une erreur non corrigible dans une mémoire non volatile d'un microcontrôleur | |
| WO2007042695A1 (fr) | Procede d'amelioration d'un diagnostic d'une eventuelle defaillance dans un vehicule | |
| WO2014195012A1 (fr) | Procédé d'optimisation de l'utilisation de la mémoire non volatile d'un calculateur de véhicule automobile pour la surveillance d'un organe fonctionnel | |
| FR3098316A1 (fr) | Procédé de test d’un dispositif de réinitialisation de calculateur | |
| FR2958060A1 (fr) | Procede et dispositif de detection d'une defaillance electrique affectant un systeme electrique de commande d'un actionneur hydraulique de geometries variables d'un moteur d'aeronef. | |
| WO2018050994A1 (fr) | Procédé de détection de défaillances | |
| FR3105595A1 (fr) | Procédé de charge d’une batterie électrique de véhicule | |
| FR3006384A1 (fr) | Procede et dispositif d'arbitrage entre plusieurs organes de (re)demarrage lors d'une anomalie (re)demarrage moteur thermique | |
| FR3010554A1 (fr) | Procede de detection et de prevention de panne de composant de vehicule automobile | |
| EP3711203B1 (fr) | Système et procédé de datation d'un événement détecté dans un véhicule automobile | |
| FR2785389A1 (fr) | Procede de controle de capteurs analogiques | |
| FR2972029A1 (fr) | Dispositif d'inhibition d'une commande d'arret/redemarrage automatique d'un moteur thermique | |
| EP2296950B1 (fr) | Procede et dispositif de diagnostic d'un systeme de controle d'un vehicule automobile | |
| FR2897650A1 (fr) | Procede de commande d'un moteur de vehicule pour le declenchement d'une phase de regeneration d'un filtre a particules | |
| FR3089315A1 (fr) | Procédé de détection d’une disparition de tache | |
| WO2023083703A1 (fr) | Procédé et dispositif de contrôle et commande d'un moteur de véhicule | |
| FR2964747A1 (fr) | Procede et systeme de supervision de fonctions electroniques d'un vehicule, vehicule comprenant un systeme de supervision de fonctions electroniques | |
| EP1069299B1 (fr) | Dispositif d'injection pour moteur à combustion interne | |
| WO2020053208A1 (fr) | Procédé de détection d'une disparition de tâche | |
| FR3072778B1 (fr) | Procede de diagnostic d’un capteur de presence d’eau dans un circuit de carburant de vehicule | |
| WO2021001131A1 (fr) | Procede de controle moteur pour la protection d'un moteur a combustion interne lors de la rotation en sens inverse | |
| FR3097986A1 (fr) | Calculateur de contrôle moteur pour véhicule automobile | |
| FR2877750A1 (fr) | Procede d'activation/desactivation d'une fonction de pilotage d'un organe fonctionnel d'un vehicule automobile |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20210108 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| TP | Transmission of property |
Owner name: VITESCO TECHNOLOGIES, DE Effective date: 20210629 |
|
| CA | Change of address |
Effective date: 20220103 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |
|
| PLFP | Fee payment |
Year of fee payment: 5 |
|
| PLFP | Fee payment |
Year of fee payment: 6 |