Brevet FR3156935A1 — publié le 20250620

Un procédé mis en œuvre par ordinateur de gestion des données techniques émises par un véhicule automobile comprenant les étapes exécutées dans le véhicule de : acquisition (27) en temps réel d’un flux de données provenant d’un équipement du véhicule automobile ; filtrage et correction (29) du flux de données en fonction d’un gabarit prédéterminé ; envoi (31) du flux de données filtré et corrigé vers un serveur. Un système de gestion des données techniques émises par un véhicule automobile et un véhicule automobile comprenant le système sont également décrits. Figure à publier avec l’abrégé : Fig 2 Procédé de gestion des données techniques émises par un véhicule automobile La présente invention se rapporte à un procédé de gestion des données techniques émises par un véhicule automobile, un produit-programme d’ordinateur, un système de gestion des données techniques émises par un véhicule automobile et un véhicule automobile comprenant un tel système. État de la technique La qualité des données (en anglais « data quality ») se réfère à la conformité des données aux usages prévus. Ainsi les données sont jugées de grande qualité si elles représentent correctement la réalité à laquelle elles se réfèrent. Il est donc important pour toute organisation de disposer de données de bonne qualité, afin de pouvoir baser ses décisions opérationnelles, financières ou de performance sur la réalité sous-jacente. Avec les véhicules connectés, l’industrie automobile est amenée à manipuler de nombreuses données provenant de ce parc de véhicules connectés. Elle est amenée à s’en servir pour améliorer la maintenance, par exemple, en détectant en amont d’une panne, un comportement anormal d’un équipement ou pour optimiser des fonctionnalités en fonction des usages faits par les utilisateurs. Ce ne sont que deux exemples d’utilisation des données reçues des véhicules connectés parmi une multitude. Cependant, si ces données sont de mauvaise qualité, elles vont être des sources de complication en générant de mauvaises interprétations, des résultats d’étude erronés, etc. Des traitements des données doivent alors être réalisés, une fois ces données collectées, par des spécialistes des données afin de les nettoyer et de les préparer pour les traitements suivants. Cela a l’inconvénient de consommer des ressources et également de souvent préparer les données pour un besoin particulier, obligeant à refaire une préparation des mêmes données lorsqu’un autre besoin apparait. Il existe donc un réel besoin d’un procédé et d’un système de gestion des données techniques émises par un véhicule automobile qui résolvent tout ou partie des inconvénients précités. Description de l’invention Pour résoudre un ou plusieurs des inconvénients cités précédemment, selon un premier mode de réalisation, un procédé mis en œuvre par ordinateur de gestion des données techniques émises par un véhicule automobile comprend les étapes exécutées dans le véhicule de : acquisition en temps réel d’un flux de données provenant d’un équipement du véhicule automobile ; filtrage et correction du flux de données en fonction d’un gabarit prédéterminé ; envoi du flux de données filtré et corrigé vers un serveur. Ainsi, les données issues du véhicule ont déjà subi un traitement permettant de définir leur qualité. Des caractéristiques ou des modes de réalisation particuliers, utilisables seuls ou en combinaison sont : Il comprend en outre, au niveau du serveur, les étapes d’agrégation du flux de données reçu avec des flux de données similaires reçus d’autres véhicules  ; l’étape d’agrégation comprend une étape de comparaison entre les différents flux de données permettant de détecter des flux de données statistiquement en anomalie  ; le gabarit prédéterminé est téléchargé dans le véhicule préalablement à l’étape d’acquisition  ; le gabarit prédéterminé est paramétré à distance ; et/ou le procédé comprend en outre l’acquisition d’un second flux de données et l’étape de filtrage et de correction comprend une étape de vérification de cohérence entre les deux flux de données. Dans un deuxième mode de réalisation, un produit-programme d’ordinateur comprend des instructions de code de programme pour la mise en œuvre du procédé ci-dessus lorsque le produit-programme est exécuté sur un calculateur. Dans un troisième mode de réalisation, un système de gestion des données techniques émises par un véhicule automobile comprend : un capteur adapté pour acquérir en temps réel un flux de données provenant d’un équipement du véhicule automobile  ; connecté à un calculateur adapté pour filtrer et corriger le flux de données en fonction d’un gabarit prédéterminé  ; et connecté à un transmetteur adapté pour envoyer le flux de données filtré et corrigé vers un serveur. Dans un quatrième mode de réalisation, un véhicule automobile comprend un système selon le troisième mode de réalisation. Brève description des figures L’invention sera mieux comprise à la lecture de la description qui suit, faite uniquement à titre d’exemple, et en référence aux figures en annexe dans lesquelles : FIG. 1 représente une vue de dessus d’un véhicule comprenant un système de gestion des données techniques émises selon un mode de réalisation ; et FIG. 2 représente un ordinogramme d’un procédé de gestion des données techniques émises selon un mode de réalisation. Modes de réalisation Les modes de réalisation présentés ci-après font référence à un véhicule automobile, une voiture. Cependant, l’homme du métier comprend que ceux-ci sont également utilisables avec d’autres types de véhicule tels que les camionnettes, les vans, etc. Les termes « avant », « arrière », « haut », « bas », « transverse » s’entendent par rapport au véhicule. En référence à la FIG. 1 , un véhicule automobile 1 comprend un système 3 de gestion des données techniques émises par ce véhicule automobile 1. Le système 3 comprend au moins un capteur 5 adapté pour acquérir en temps réel un flux de données provenant d’un équipement du véhicule automobile 1. Par exemple, le capteur 5 va acquérir des informations provenant du fonctionnement de la motorisation telles que le nombre de tours par minute, la consommation d’énergie à chaque instant, etc. Chaque donnée de ce flux de données est horodatée de façon à pouvoir en particulier la corréler avec d’autres données reçues par d’autres capteurs au même instant ou dans la même plage temporelle. Le système 3 comprend un calculateur 7 connecté au capteur 5. Le calculateur 7 peut, par exemple, être intégré dans le système de contrôle du véhicule 1, comme un système avancé d’aide à la conduite, communément appelé ADAS (pour « Advanced driver-assistance systems » selon la terminologie anglaise) qui prend toutes les décisions de conduite en fonction de l’environnement et de la destination programmée. Le véhicule automobile est alors qualifié de véhicule automobile autonome. Mais il peut être également un système centralisé de gestion du véhicule comprenant, ou non, des aides à la conduite. Le transfert de données entre les différents éléments est réalisé de préférence par un bus de données de type CAN (pour «  Controller Area Network   » en anglais, soit « réseau de zone de contrôleurs ») ou LIN (pour « Local Interconnect Network » en anglais, ou « Réseau interconnecté local » en français). Le calculateur 7 est adapté pour filtrer et corriger le flux de données en fonction d’un gabarit prédéterminé. Par gabarit, on entend un ensemble d’outils paramétrés, en général de type statistique, destiné à s’assurer que la donnée acquise est de bonne qualité, c’est-à-dire reflète correctement le phénomène physique sous-jacent. Par exemple, la donnée doit se trouver dans un intervalle prédéterminé. Si elle apparait à l’extérieur de cet intervalle, c’est le signe d’une anomalie qui peut provenir d’un fonctionnement anormal du véhicule ou d’un défaut du capteur. Ces outils peuvent également comprendre des outils de type corrélation entre différents flux de données permettant également de détecter des anomalies. Par exemple, une donnée de vitesse de rotation du moteur associée à une consommation d’énergie nulle indique en général une anomalie sauf si un troisième flux indique que le véhicule se déplace sur une voie en descente. On peut ainsi également définir le gabarit sous forme d’un jeu de règles, ou de contraintes que doit respecter le flux de données. Le calculateur 7 est également connecté à un transmetteur 9 adapté pour envoyer le flux de données filtré et corrigé vers un serveur 11. Typiquement, le transmetteur 9 est un module de téléphonie sans fil utilisant les normes 4G et 5G telles que définies par l’ETSI (en anglais «  European Telecommunications Standards Institute  », soit Institut européen des normes de télécommunications). Le serveur 11 comprend une base de données 13 dans laquelle est stocké le flux de données reçu du véhicule 1. Cette base de données 13 centralise également les flux de données d’un parc de véhicules connectés dont fait partie le véhicule 1. Le serveur 11 effectue une agrégation de ces flux de données consistant en particulier à faire une nouvelle étape de recherche d’anomalie par comparaison des flux provenant des différents véhicules. Par exemple, en considérant que, pour un paramètre donné, les valeurs reçues suivent une loi normale avec une moyenne et un écart-type définis, un flux de données qui s’écarte de façon significative, au sens statistique, de cette loi normale sera considéré comme étant en anomalie. La base de données 13 contient ainsi des données dont la qualité a été validée et elles pourront être utilisées pour des analyses extérieures. On notera que le fait d’avoir mis un drapeau d’anormalité sur une donnée, ou un flux de données, peut être en soi une information pertinente pour l’analyse, car pouvant signaler un problème potentiel ou un comportement non anticipé. On notera que l’anomalie peut également signifier que la donnée ne doit pas être prise en compte, car elle est absente ou corrompue. Le fonctionnement du système 3 associé au serveur 11 est le suivant, FIG. 2 . La FIG. 2 regroupe via un périmètre en trait pointillé les étapes réalisées par le système 3 et celles réalisées sur le serveur 11. Dans une étape préliminaire 21, un jeu de gabarits est défini pour le véhicule 1. Ainsi en fonction des besoins d’analyse identifiés et des données disponibles sur le véhicule 1, on définit la liste des signaux à collecter avec leurs fréquences ainsi que les gabarits à réaliser sur ces signaux tels que traitements, comparatifs ou règles qualité. Ce jeu de gabarits est décomposé en deux groupes : un premier groupe est téléchargé, étape 23, dans le véhicule 1 et un second groupe est installé, étape 25, sur le serveur 11. Le premier groupe assemble tous les gabarits s’appliquant aux flux de données d’un seul véhicule et le second groupe assemble tous les gabarits s’appliquant aux flux de données de plusieurs véhicules. Il est à noter que les gabarits peuvent être téléchargés à tout moment dans le véhicule ou bien paramétrés à distance, ce qui permet avantageusement de les adapter aux besoins au fil du temps. Lorsque le véhicule 1 est en fonctionnement et génère des flux de données, ces flux de données sont acquis, étape 27, par le capteur 5. Le calculateur 7 exécute, étape 29, le premier groupe du jeu de gabarits pour obtenir un flux de données filtré et corrigé qui est envoyé, étape 31, par le transmetteur 9 vers le serveur 11. Le serveur 11 exécute alors, étape 33, le second groupe de gabarits pour générer un ensemble de données totalement qualifié. La FIG. 1 illustre un système selon certains modes de réalisation. Le découpage présenté a un but pédagogique pour mettre en avant les différentes fonctions. Cependant, on comprend que chaque bloc peut être implémenté en utilisant différents moyens ou leurs combinaisons, tels que des composants matériels, du logiciel, un ou plusieurs calculateurs et/ou des circuits électroniques. Chacun des composants peut inclure au moins un calculateur ou une unité de contrôle-commande. Au moins une mémoire peut être comprise dans chaque composant. La mémoire peut inclure des instructions de programme d’ordinateur ou du code logiciel. Les calculateurs peuvent être réalisés par n’importe quel type de dispositif de traitement de données, tel qu’une unité centrale de calcul, un processeur de traitement de signal, un circuit intégré d’application spécifique, un réseau de portes programmable, etc. Les calculateurs peuvent être réalisés sous forme d’un unique contrôleur, ou d’une pluralité de contrôleurs ou de calculateurs. Les différents modules sont connectés entre eux par des liaisons de données adaptées à l’environnement. Celles-ci peuvent être de type filaire ou sans-fil. Pour le logiciel, l’implémentation peut comprendre des modules ou unités répartis sous forme de procédures, fonctions, etc. Les mémoires peuvent être n’importe quel type de circuit de stockage. Elles peuvent faire partie du circuit du processeur, ou en être séparées et connectées via des liaisons électriques de donnée. Cela peut être des mémoires de type non volatiles, des disques durs, des mémoires vives, des mémoires flash, etc. Le produit-programme peut être téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur. Il peut être directement exécutable par un processeur ou être sous la forme d’un langage de haut niveau nécessitant une ou des opérations intermédiaires pour être exécutable. Ainsi les instructions de programme stockées dans la mémoire et traitées par les calculateurs peuvent être n’importe quel type de code de programme, par exemple, un programme compilé ou interprété écrit dans un langage de programmation adapté. Les instructions de programme d’ordinateur stockées dans la mémoire sont telles que, quand elles sont exécutées par le calculateur, ce dernier réalise une ou plusieurs des étapes des procédés décrits ci-dessus. 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 donner à titre d’exemple et non comme limitant l’invention a cette seule description. De nombreuses variantes de réalisation sont possibles. Ainsi, la préparation des gabarits et leur téléchargement peuvent être réalisés par un serveur différent du serveur 11. Procédé mis en œuvre par ordinateur de gestion des données techniques émises par un véhicule automobile comprenant les étapes exécutées dans le véhicule de : acquisition (27) en temps réel d’un flux de données provenant d’un équipement du véhicule automobile ; filtrage et correction (29) du flux de données en fonction d’un gabarit prédéterminé ; envoi (31) du flux de données filtré et corrigé vers un serveur. Procédé selon la revendication 1, comprenant en outre, au niveau du serveur, une étape d’agrégation (33) du flux de données reçu avec des flux de données similaires reçus d’autres véhicules. Procédé selon la revendication 2, dans lequel l’étape d’agrégation comprend une étape de comparaison entre les différents flux de données permettant de détecter des flux de données statistiquement en anomalie. Procédé selon la revendication 1, 2 ou 3, dans lequel le gabarit prédéterminé est téléchargé dans le véhicule préalablement à l’étape d’acquisition. Procédé selon la revendication 4, dans lequel le gabarit prédéterminé est paramétré à distance. Procédé selon l’une quelconque des revendications précédentes, comprenant en outre l’acquisition d’un second flux de données et l’étape de filtrage et de correction comprend une étape de vérification de cohérence entre les deux flux de données. Produit-programme d’ordinateur caractérisé en ce qu’il comprend des instructions de code de programme pour la mise en œuvre du procédé selon l’une quelconque des revendications 1 à 6 lorsque le produit-programme est exécuté sur un calculateur. Système (3) de gestion des données techniques émises par un véhicule automobile (1) comprenant : un capteur (5) adapté pour acquérir en temps réel un flux de données provenant d’un équipement du véhicule automobile  ; connecté à un calculateur (7) adapté pour filtrer et corriger le flux de données en fonction d’un gabarit prédéterminé  ; et connecté à un transmetteur (9) adapté pour envoyer le flux de données filtré et corrigé vers un serveur (11). Véhicule automobile comprenant un système selon la revendication 8.