FR3086407A1 - Procede d'identification d'anomalie pour vehicule - Google Patents

Procede d'identification d'anomalie pour vehicule Download PDF

Info

Publication number
FR3086407A1
FR3086407A1 FR1858609A FR1858609A FR3086407A1 FR 3086407 A1 FR3086407 A1 FR 3086407A1 FR 1858609 A FR1858609 A FR 1858609A FR 1858609 A FR1858609 A FR 1858609A FR 3086407 A1 FR3086407 A1 FR 3086407A1
Authority
FR
France
Prior art keywords
automatic
vehicle
logs
common
file
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
Application number
FR1858609A
Other languages
English (en)
Other versions
FR3086407B1 (fr
Inventor
Jean-Philippe Boyer
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Continental Automotive GmbH
Continental Automotive France SAS
Original Assignee
Continental Automotive GmbH
Continental Automotive France SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Continental Automotive GmbH, Continental Automotive France SAS filed Critical Continental Automotive GmbH
Priority to FR1858609A priority Critical patent/FR3086407B1/fr
Publication of FR3086407A1 publication Critical patent/FR3086407A1/fr
Application granted granted Critical
Publication of FR3086407B1 publication Critical patent/FR3086407B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, 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/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • 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
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Debugging And Monitoring (AREA)

Abstract

La présente invention a pour objet un procédé de détection d'anomalie pour un véhicule, ledit véhicule mettant en œuvre, lors de son fonctionnement, une pluralité d'applications générant des enregistrements automatiques de données d'exécution, désignés « logs » automatiques, ledit procédé comprenant : - l'enregistrement centralisé (E1), dans un fichier commun, des logs automatiques générés par un ensemble d'applications mises en œuvre, ledit enregistrement étant réalisé dans une mémoire volatile du véhicule, - quand le véhicule dispose d'un lien de télécommunication, le téléchargement (E2) du fichier comprenant les log automatiques à destination d'un serveur d'analyse distant, et - l'analyse (E3) du fichier commun de logs automatiques sur le serveur d'analyse distant.

Description

Procédé d’identification d’anomalie pour véhicule
Domaine de l'invention
L’invention se rapporte au domaine des systèmes de détection d’anomalie pour véhicule.
La présente invention concerne plus précisément un procédé prévoyant l’analyse débarquée de données enregistrées automatiquement, autrement dit des « logs >> automatiques d’applications mises en œuvre par un véhicule afin d’identifier d’éventuelles anomalies.
Etat de la technique
Aujourd’hui, les véhicules embarquent de plus en plus d’applications logicielles, mises en œuvre par des calculateurs, et disposent de moyens de connectivité, c’est-à-dire qu’ils se connectent à des réseaux de communication de données sans fil.
La complexité d’un tel système mettant en œuvre une pluralité d’applications logicielles est importante et, lorsqu’une anomalie se produit, il est parfois difficile de la détecter.
Dans ce contexte, la problématique générale concerne la détection d’anomalie lors du fonctionnement combiné d’une pluralité d’applications logicielles, en particulier mises en œuvre dans un véhicule, qu’une telle anomalie soit le signe d’un dysfonctionnement, d’une mauvaise utilisation ou d’une tentative d’intrusion.
Il est précisé que l’on entend par « anomalie >> le fait qu’un fonctionnement anormal est détecté ; un tel fonctionnement anormal peut être dû à un bug ou être le fruit d’une exécution non conforme d’une application.
Par « intrusion >>, on entend une tentative d’agir ou d’accéder par exemple à une donnée, d’une manière qui est interdite par le système.
Selon l’état de l’art, il est connu que les applications logicielles génèrent des enregistrements automatiques - des logs - retraçant les séquences d’opérations réalisées par lesdites applications. Par exemple, pour une application logicielle contrôlant un système multimédia comprenant un récepteur radio, un changement de fréquence, l’utilisation d’une fonction de recherche pour réaliser un balayage d’une bande de fréquences, etc. susciterait l’écriture d’un enregistrement automatique, comprenant éventuellement plusieurs opérations, dans un fichier de logs de la ou des application(s) logicielle(s) concernée(s).
Selon l’état de l’art, les enregistrements sont horodatés, ce qui permet de mesurer le temps écoulé entre deux enregistrements.
De tels fichiers de logs peuvent le cas échéant faire l’objet d’analyses manuelles débarquées, en différé, lors d’un diagnostic faisant suite à une panne par exemple.
Ainsi, pour détecter des anomalies « à chaud », les véhicules actuels mettent en oeuvre une application de supervision dédiée, qui ausculte le comportement du système au moyen d’une pluralité de capteurs. Lesdits capteurs enregistrent des signaux électriques ou analyse le trafic sur les bus logiciels ou matériels internes au système, et l’application de supervision est configurée pour détecter des anomalies à partir de ces signaux électriques générés par des capteurs, autrement dit par des moyens physiques, ou par l’analyse des messages transitant sur les bus logiciels entre les applications.
Autrement dit, le comportement des différents calculateurs et des applications logicielles qu’ils mettent en oeuvre sont observés par l’intermédiaire de ladite application de supervision. Par ailleurs, l’analyse directe des calculateurs du véhicule par des applications de supervision dédiées peut s’avérer intrusif.
En tout état de cause, les techniques connues basées sur la mise en oeuvre d’une application de supervision dédiée présentent au moins l’inconvénient d’être hautement consommatrices de ressources matérielles.
En outre, l’augmentation du nombre et de la complexité des applications logicielles mises en oeuvre dans les véhicules actuels augmente l’impact d’un tel inconvénient.
Il existe donc un besoin pour un procédé de détection d’anomalie au sein d’un véhicule mettant en oeuvre une pluralité d’applications logicielles et disposant d’une connectivité à un réseau de communication de données, qui soit peu intrusif et peu consommateur de ressources matérielles.
A cette fin, la présente invention propose de tirer parti de la connectivité croissante des véhicules, d’une part, et de l’augmentation des capacités de calcul débarquées dans le contexte de techniques d’analyse de type « big data », d’autre part.
Ainsi, l’invention propose la génération de logs automatiques centralisés dans un fichier unique, ledit fichier étant téléchargé de façon régulière ou non à un serveur d’analyse distant effectuant une analyse débarquée des logs automatiques enregistrés dans ledit fichier unique.
Exposé de l'invention
Plus précisément, l’invention a pour objet un procédé de détection d’anomalie pour un véhicule, ledit véhicule mettant en oeuvre, lors de son fonctionnement, une pluralité d’applications générant des enregistrements automatiques de données d’exécution, désignés « logs » automatiques, ledit procédé comprenant :
- la détermination de phases de fonctionnement d’intérêt, notamment en fonction de la durée écoulée depuis le démarrage du véhicule,
- l’enregistrement centralisé (E1), dans un fichier commun, des logs automatiques générés par un ensemble d’applications mises en œuvre, ledit enregistrement étant réalisé dans une mémoire volatile du véhicule,
- quand le véhicule dispose d’un lien de télécommunication, le téléchargement (E2) du fichier commun de logs automatiques à destination d’un serveur d’analyse distant, et
- l’analyse (E3), sur le serveur d’analyse distant, de logs automatiques du fichier commun de logs automatiques enregistrés durant des phases de fonctionnements d’intérêt du véhicule.
Grâce à l’invention, il est possible de détecter des anomalies de façon non intrusive dans un véhicule mettant en œuvre une pluralité d’applications.
Selon un mode de réalisation, les logs automatiques générés ne sont enregistrés dans le fichier commun que pendant lesdites phases de fonctionnement d’intérêt du véhicule.
Avantageusement, en l’absence d’un lien de télécommunication disponible, le stockage du fichier commun comprenant l’enregistrement des logs automatiques dans une mémoire persistante du véhicule.
Avantageusement, l’enregistrement des logs automatiques dans le fichier commun est réalisé dans l’ordre chronologique dans lequel lesdits logs automatiques sont générés par lesdites applications mises en œuvre.
Selon un mode de réalisation préféré, l’analyse du fichier commun de logs automatiques comprend la comparaison du fichier commun de logs automatiques à des motifs prédéfinis correspondant à des séquences de logs connues, pour identifier une anomalie
Par exemple, une anomalie est ainsi détectée lorsqu’une séquence de logs automatiques inconnue est relevée dans le fichier commun.
Selon un mode de réalisation, les phases de fonctionnement d’intérêt du véhicule correspondent à des phases de fonctionnement du véhicule pour lesquelles un ensemble d’un nombre fini de motifs prédéfinis sont connus, une anomalie étant identifiée dès lors qu’un motif n’appartenant pas audit ensemble d’un nombre fini de motifs prédéfinis connus est identifié dans le fichier commun de logs automatiques lors de l’étape d’analyse, sur le serveur d’analyse distant, de logs automatiques du fichier commun de logs automatiques enregistrés durant lesdites phases de fonctionnements d’intérêt du véhicule.
Avantageusement, le téléchargement du fichier commun de logs automatiques peut être réalisé uniquement lors de l’arrêt du véhicule.
D’autres caractéristiques et avantages de l’invention apparaîtront lors de la description qui suit faite en regard de la figure annexée donnée à titre d’exemple non limitatif.
Brève description du dessin
La figure 1 représente un schéma-bloc du procédé selon l’invention.
Description détaillée de modes de réalisation de l’invention
L'invention est envisagée principalement en vue d’une mise en œuvre dans un véhicule automobile. Cependant, d’autres applications, en particulier la mise en œuvre du système et du procédé selon l’invention dans tout type de moyen de transport de passagers, est également visée.
Comme décrit précédemment, il est rappelé que le contexte est celui d’un véhicule comprenant des calculateurs embarqués exécutant une pluralité d’applications logicielles. Ces applications logicielles génèrent des logs automatiques correspondant à des enregistrements automatiques de données - paramètres, commandes, opérations pour chacune desdites applications logicielles. Les logs automatiques sont copiés dans un fichier associé à chacune desdites applications logicielles et sauvegardés dans une mémoire, volatile ou non, de chaque calculateur embarqué concerné. Généralement, le moment auquel est généré chaque log automatique est sauvegardé avec ledit log automatique. Autrement dit, chaque log automatique est normalement horodaté et l’horodatage associé est sauvegardé avec chaque log automatique.
En référence à la figure 1, le procédé selon l’invention comprend l’enregistrement centralisé E1, dans un fichier commun, de la somme des logs automatiques générés par l’ensemble des applications logicielles mises en œuvre, en continu.
A cette fin, chaque log automatique généré par chaque application logicielle concernée est écrit et enregistré dans ledit fichier commun de logs automatiques. Le véhicule comprend, notamment dans un calculateur, une mémoire volatile dans laquelle est sauvegardé le fichier commun.
Selon un mode de réalisation, l’enregistrement des logs automatiques de l’ensemble des applications logicielles mises en œuvre est continu et systématique.
Alternativement, l’enregistrement des logs automatiques de l’ensemble des applications logicielles mises en oeuvre est réalisé à intervalles de temps.
En outre, de manière préférée, l’enregistrement des logs automatiques de l’ensemble des applications logicielles mises en oeuvre n’est pas systématique. Dans ce cas, l’enregistrement des logs automatiques de l’ensemble des applications logicielles mises en oeuvre n’est réalisé que durant des phases de fonctionnement identifiées comme pertinentes ou « d’intérêt >>. Autrement dit, selon ce mode de réalisation, seuls les logs automatiques générés durant des phases de fonctionnement - également désignés cycles de vie - du véhicule, considérées comme représentatives, sont enregistrés dans le fichier commun. Notamment, les phases de fonctionnement représentatives sont définies en fonction de l’état démarré du moteur, du temps écoulé depuis le démarrage, du fait que le véhicule se trouve dans une phase de roulage ou non, etc. Ainsi, les phases de fonctionnement transitoires, telles que le démarrage ou l’arrêt du moteur, ne sont pas considérées comme représentatives et les logs automatiques générés durant ces phases peuvent ne pas être enregistrés dans le fichier commun.
Selon un mode de réalisation, les logs automatiques générés par la totalité des applications logicielles mises en oeuvre sont enregistrés dans le fichier commun. Alternativement, seuls les logs automatiques générés par une partie des applications logicielles sont enregistrés dans le fichier commun.
Notamment, les logs automatiques générés par les applications logicielles mises en oeuvre sont enregistrés dans le fichier commun dans l’ordre chronologique dans lequel ils sont générés par lesdites applications logicielles.
Ensuite, le procédé selon l’invention comprend une étape de téléchargement E2 du fichier commun à un serveur d’analyse distant.
Le téléchargement E2 peut être effectué, notamment en continu, tant que ou à chaque fois que le véhicule dispose d’une liaison à un réseau de communication de données auquel est également connecté ledit serveur d’analyse distant.
Alternativement, le téléchargement E2 peut être effectué à intervalles de temps, réguliers ou non, ou lors de l’arrêt du véhicule par exemple.
Selon l’invention, sur le serveur d’analyse distant, le fichier commun est comparé E3 à des motifs de logs automatiques prédéterminés, de manière à permettre l’identification d’une anomalie.
A cette fin, des motifs représentatifs sont définis.
La comparaison E3 entre le fichier commun et les motifs représentatifs prédéfinis permet de détecter un écart, une déviation, entre une séquence de logs automatiques contenue dans le fichier commun et une séquence de logs automatiques attendue.
Autrement dit, des motifs (« patterns >> en langue anglaise) de logs automatiques sont définies au préalable. Ces motifs correspondent à des enregistrements centralisés dans un fichier commun de séquences de logs automatiques générés par différentes applications logicielles mises en œuvre lors d’actions identifiées, telles qu’un changement de la fréquence de réception radio, un changement de source pour un système multimédia, etc. Lors de ces actions identifiées, les logs automatiques enregistrés dans le fichier commun correspondent à des suites d’opérations réalisées par les différentes applications logicielles mises en œuvre.
Ces logs automatiques ne sont pas spécifiques au procédé selon l’invention ; il s’agit des logs automatiques nominaux générés par toute application logicielle.
Grâce à des tests réalisés au préalable, on identifie ainsi un ou plusieurs motifs caractéristiques de logs automatiques correspondant à une action particulière.
En comparant le fichier commun généré lors de l’utilisation du véhicule à un ensemble de motifs prédéfinis, on identifie un écart éventuel entre une séquence de logs automatiques enregistrés et une séquence de logs automatiques attendus selon le ou les motifs prédéfinis possibles pour une action donnée.
Par exemple, une telle séquence de logs automatiques va comprendre la modification d’un paramètre, l’inscription de la nouvelle valeur du paramètre dans une base de données, la notification de la nouvelle valeur du paramètre à différentes applications logicielles tierces, etc. Si, par exemple, une application logicielle tierce censée être informée de cette modification de la valeur dudit paramètre ne l’est pas, le procédé selon l’invention permettra de le détecter car le log automatique généré par ladite application et mentionnant la réception de l’information relative à la modification de la valeur du paramètre sera absente du fichier commun généré alors qu’elle sera présente dans le motif caractéristique correspondant. Une anomalie est ainsi détectée.
Durant les phases de fonctionnement d’intérêt du véhicule, un nombre connu de motifs prédéfinis est ainsi attendu dans le fichier commun de logs automatiques. Si un motif n’appartenant pas à cet ensemble de motifs attendu se retrouve dans le fichier commun, alors une anomalie est détectée.
Il est en outre possible, grâce à l’invention, de détecter une anomalie même lorsque l’action souhaitée est réalisée de façon nominale ; il s’agit alors par exemple de détecter un ralentissement d’une application logicielle mise en œuvre, le ralentissement étant notamment mesuré par l’analyse de l’horodatage de chacun des logs automatiques formant un motif lié à l’action considérée.
Lors de l’utilisation du procédé, l’analyse du fichier commun comprenant l’enregistrement centralisé des logs automatiques est réalisé, comme indiqué précédemment, sur un serveur distant, ce qui présente l’avantage de ne pas engendrer de consommation de ressources matérielles sur le véhicule.
En outre, toujours pour minimiser l’impact de la mise en œuvre du procédé sur les ressources matérielles du véhicule, ainsi que sur la bande passante de la liaison de données à laquelle est connectée le véhicule, il peut être prévu que le téléchargement du fichier commun à destination du serveur d’analyse distant soit effectué avec une priorité basse.
Selon un mode de réalisation, si, lors de l’arrêt du véhicule, un fichier commun n’a pas pu être téléchargé au serveur d’analyse distant, par exemple en l’absence d’une liaison à un réseau de communication de données à l’endroit où se trouve le véhicule, le fichier commun est sauvegardé, avant l’arrêt total des calculateurs du véhicule, dans une mémoire persistante d’un calculateur, par exemple une mémoire flash.
Dans ce cas, le fichier commun peut être téléchargé en différé, après le redémarrage du véhicule.
Un avantage de l’invention réside en outre dans le fait que, l’analyse du fichier commun étant réalisée à distance, autrement dit de façon débarquée, il est possible d’ajouter de nouvelles applications logicielles dans le véhicule. Une simple mise à jour des motifs caractéristiques prédéfinis sur le serveur d’analyse permet au procédé selon l’invention de continuer à être exécuté de la même manière et de détecter d’éventuelles anomalies, y compris dans le fonctionnement des nouvelles applications logicielles installées, sans nécessiter de modifications du système embarqué.
Il est précisé, en outre, que la présente invention n’est pas limitée aux exemples décrits ci-dessus et est susceptible de variantes accessibles à l’homme de l’art.

Claims (7)

  1. REVENDICATIONS
    1. Procédé de détection d’anomalie pour un véhicule, ledit véhicule mettant en oeuvre, lors de son fonctionnement, une pluralité d’applications générant des enregistrements automatiques de données d’exécution, désignés « logs >> automatiques, ledit procédé comprenant :
    - la détermination de phases de fonctionnement d’intérêt, notamment en fonction de la durée écoulée depuis le démarrage du véhicule,
    - l’enregistrement centralisé (E1), dans un fichier commun, des logs automatiques générés par un ensemble d’applications mises en oeuvre, ledit enregistrement étant réalisé dans une mémoire volatile du véhicule,
    - quand le véhicule dispose d’un lien de télécommunication, le téléchargement (E2) du fichier commun de logs automatiques à destination d’un serveur d’analyse distant, et
    - l’analyse (E3), sur le serveur d’analyse distant, de logs automatiques du fichier commun de logs automatiques enregistrés durant des phases de fonctionnements d’intérêt du véhicule.
  2. 2. Procédé selon la revendication 1, dans lequel les logs automatiques générés ne sont enregistrés dans le fichier commun que pendant lesdites phases de fonctionnement d’intérêt du véhicule.
  3. 3. Procédé selon l’une des revendications précédentes, comprenant, en l’absence d’un lien de télécommunication disponible, le stockage du fichier commun comprenant l’enregistrement des logs automatiques dans une mémoire persistante du véhicule.
  4. 4. Procédé selon l’une des revendications précédentes, dans lequel l’enregistrement (E2) des logs automatiques dans le fichier commun est réalisé dans l’ordre chronologique dans lequel lesdits logs automatiques sont générés par lesdites applications mises en oeuvre.
  5. 5. Procédé selon l’une des revendications précédentes, dans lequel l’analyse du fichier commun de logs automatiques comprend la comparaison du fichier commun de logs automatiques à des motifs prédéfinis correspondant à des séquences de logs connues, pour identifier une anomalie.
  6. 6. Procédé selon la revendication précédente, dans lequel les phases de fonctionnement d’intérêt du véhicule correspondent à des phases de fonctionnement du véhicule pour lesquelles un ensemble d’un nombre fini de motifs prédéfinis sont connus, une anomalie étant identifiée dès lors qu’un motif n’appartenant pas audit ensemble d’un 5 nombre fini de motifs prédéfinis connus est identifié dans le fichier commun de logs automatiques lors de l’étape d’analyse, sur le serveur d’analyse distant, de logs automatiques du fichier commun de logs automatiques enregistrés durant lesdites phases de fonctionnements d’intérêt du véhicule.
  7. 10 7. Procédé selon l’une des revendications précédentes, dans lequel le téléchargement (E3) du fichier commun de logs automatiques est réalisé uniquement lors de l’arrêt du véhicule.
FR1858609A 2018-09-21 2018-09-21 Procede d'identification d'anomalie pour vehicule Active FR3086407B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1858609A FR3086407B1 (fr) 2018-09-21 2018-09-21 Procede d'identification d'anomalie pour vehicule

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1858609A FR3086407B1 (fr) 2018-09-21 2018-09-21 Procede d'identification d'anomalie pour vehicule

Publications (2)

Publication Number Publication Date
FR3086407A1 true FR3086407A1 (fr) 2020-03-27
FR3086407B1 FR3086407B1 (fr) 2021-08-13

Family

ID=63963254

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1858609A Active FR3086407B1 (fr) 2018-09-21 2018-09-21 Procede d'identification d'anomalie pour vehicule

Country Status (1)

Country Link
FR (1) FR3086407B1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114419756A (zh) * 2022-01-30 2022-04-29 重庆长安汽车股份有限公司 一种动态捕获整车异常场景的方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120053778A1 (en) * 2010-08-27 2012-03-01 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis
EP2680534A1 (fr) * 2012-06-28 2014-01-01 Harman Becker Automotive Systems GmbH Journalisation pour systèmes télématiques
US20150355957A1 (en) * 2014-06-09 2015-12-10 Northrop Grumman Systems Corporation System and method for real-time detection of anomalies in database usage
WO2016108963A1 (fr) * 2014-12-30 2016-07-07 Battelle Memorial Institute Détection d'anomalie temporelle sur des réseaux automobiles

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120053778A1 (en) * 2010-08-27 2012-03-01 Zonar Systems, Inc. Method and apparatus for remote vehicle diagnosis
EP2680534A1 (fr) * 2012-06-28 2014-01-01 Harman Becker Automotive Systems GmbH Journalisation pour systèmes télématiques
US20150355957A1 (en) * 2014-06-09 2015-12-10 Northrop Grumman Systems Corporation System and method for real-time detection of anomalies in database usage
WO2016108963A1 (fr) * 2014-12-30 2016-07-07 Battelle Memorial Institute Détection d'anomalie temporelle sur des réseaux automobiles

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114419756A (zh) * 2022-01-30 2022-04-29 重庆长安汽车股份有限公司 一种动态捕获整车异常场景的方法及系统
CN114419756B (zh) * 2022-01-30 2023-05-16 重庆长安汽车股份有限公司 一种动态捕获整车异常场景的方法及系统

Also Published As

Publication number Publication date
FR3086407B1 (fr) 2021-08-13

Similar Documents

Publication Publication Date Title
EP3250974B1 (fr) Procédé, système et programme d'ordinateur pour phase d'apprentissage d'une analyse acoustique ou vibratoire d'une machine
US8381036B2 (en) Systems and methods for restoring machine state history related to detected faults in package update process
CA2813556A1 (fr) Systeme de surveillance d'un banc d'essai de moteur
FR3052273A1 (fr) Prediction de pannes dans un aeronef
EP3215903B1 (fr) Outil de validation d'un système de surveillance d'un moteur d'aéronef
EP1960652B1 (fr) Procede de memorisation d'informations concernant un defaut de fonctionnement d'un dispositif
CN102957550A (zh) 基于日志检测的告警方法及系统
US11429574B2 (en) Computer system diagnostic log chain
FR3086407A1 (fr) Procede d'identification d'anomalie pour vehicule
KR20160062259A (ko) 차량 이상 상태를 관리하기 위한 방법, 시스템 및 컴퓨터 판독 가능한 기록매체
FR3069086A1 (fr) Procede d'evaluation d'un taux de variation d'une panne
FR2990547A1 (fr) Systeme de maintenance centralisee parametrable destine a un aeronef
US20210011793A1 (en) Determining root-cause of failures based on machine-generated textual data
FR3088909A1 (fr) Procédé et système de sécurisation d’un aéronef contre les cyberattaques
FR2964280A1 (fr) Procede de centralisation d’evenements pour systeme d’information hierarchique multi-niveaux
FR2920895A1 (fr) Procede de gestion de defaillances avec memorisation de ces defaillances pour un vehicule automobile.
WO2016055750A1 (fr) Procede d'ajustement dynamique d'un niveau de verbosite d'un composant d'un reseau de communications
CN115391224A (zh) 一种流量回放方法、装置、计算机设备及可读存储介质
CN112882892A (zh) 数据处理方法和装置、电子设备及存储介质
FR2868177A1 (fr) Procede et dispositif de supervision de l'usage d'un terminal mobile
FR3028973A1 (fr) Systeme et methode de test de performances d'une infrastructure informatique
FR3103219A1 (fr) Procédé de gestion des anomalies sporadiques d’un système de motorisation d’un véhicule automobile
FR2819322A1 (fr) Procede et dispositif d'evaluation de la securite d'un systeme informatique
FR2876814A1 (fr) Systeme d'enregistrement d'un contexte d'incident dans un vehicule automobile
EP3839450B1 (fr) Procede et dispositif d'analyse des vibrations d'un element

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200327

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6