Brevet FR3086407A1 — publié le 20200327

Procédé d'identification d'anomalie pour véhicule Domaine de /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 oeuvre 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 oeuvre 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 oeuvre une pluralité d'applications logicielles est importante et, lorsqu'une anomalie se produit, il est parfois difficile de la 15 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 oeuvre dans un véhicule, qu'une telle anomalie soit le signe d'un dysfonctionnement, d'une mauvaise utilisation ou d'une tentative d'intrusion. 20 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. 25 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 30 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 35 débarquées, en différé, lors d'un diagnostic faisant suite à une panne par exemple. 2 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 5 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 10 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 20 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. 25 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 30 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 35 la durée écoulée depuis le démarrage du véhicule, 3 l'enregistrement centralisé (El ), 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) 5 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. 10 Grâce à l'invention, il est possible de détecter des anomalies de façon non intrusive dans un véhicule mettant en oeuvre une pluralité d'applications. Selon un mode de réalisation, les logs automatiques générés ne sont 15 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 oeuvre. Selon un mode de réalisation préféré, l'analyse du fichier commun de logs 25 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. 30 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, 35 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. 4 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 5 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 !invention 10 L'invention est envisagée principalement en vue d'une mise en oeuvre dans un véhicule automobile. Cependant, d'autres applications, en particulier la mise en oeuvre du système et du procédé selon l'invention dans tout type de moyen de transport de passagers, est également visée. 15 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 20 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 oeuvre, en continu. A cette fin, chaque log automatique généré par chaque application logicielle 30 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 oeuvre est continu et systématique. 5 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 5 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 10 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 15 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. 20 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 25 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, 30 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. 35 A cette fin, des motifs représentatifs sont définis. 6 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. 5 Autrement dit, des motifs (c 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 oeuvre 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 10 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 oeuvre. 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. 15 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 20 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 25 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. 7 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 oeuvre, le ralentissement étant notamment mesuré par l'analyse de l'horodatage de chacun des logs automatiques 5 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 10 consommation de ressources matérielles sur le véhicule. En outre, toujours pour minimiser l'impact de la mise en oeuvre 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é 15 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 20 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. 25 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 30 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. REVENDICATIONS1. 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, 5 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é (El ), dans un fichier commun, des logs automatiques générés par un ensemble d'applications mises en oeuvre, ledit enregistrement étant 10 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 15 commun de logs automatiques enregistrés durant des phases de fonctionnements d'intérêt du véhicule. 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 20 d'intérêt du véhicule. 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. 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. 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. 25 30 35 9 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 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. 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.