Brevet FR3122016A1 — publié le 20221021

Véhicule automobile (100) comportant un système ADAS (10), un ensemble de capteurs (30) comportant au moins une caméra (31), un ensemble de calculateurs (11 à 1n) synchronisés entre eux, dédiés au traitement des données reçues par l’ensemble des capteurs (30) en relation avec l’ensemble des services d’aide à la conduite et un organe (20) de gestion des données traitées par lesdits calculateurs (11-1n) ; lesdits calculateurs (11-1n) étant couplés à des moyens de stockage provisoires (40) des données, des moyens d’enregistrement (50) des données collectées par les capteurs (30) à la suite de la réception d’au moins un trigger, transmis par au moins un des calculateurs (11-1n) en relation avec le service déterminé ; ledit organe de gestion (20) étant agencé pour commander les enregistrements et restituer, à partir des moyens d’enregistrement (50), les données d’au moins un contexte de déclenchement du trigger autour de l’instant de déclenchement de l’enregistrement. (Figure 1) Véhicule automobile comportant un organe de gestion de données en rapport avec des services d’aide à la conduite dudit véhicule. La présente invention concerne de manière générale l’enregistrement de données associées à un véhicule automobile et concerne plus particulièrement la gestion des données enregistrées se rapportant notamment à des services d’aide à la conduite offertes par un système d’aide à la conduite dudit véhicule, également désignés par système ADAS (acronyme anglosaxon pour Advanced Driver-Assistance System). Les systèmes ADAS sont de plus en plus présents dans les véhicules automobiles et certains d’entre eux permettent d’offrir au conducteur, des services s’approchant d’une conduite semi-autonome (ou mode de conduite délégué de niveau 2) voire complétement autonome. Ces services comprennent notamment la régulation de vitesse adaptative ou « ACC » (acronyme anglosaxon pour « Adaptive Cruise Control ») désignée également par « régulation longitudinale » et le maintien du véhicule dans sa voie ou « LPA » (acronyme anglosaxon pour « Lane Positionning Assist ») désigné également par « régulation latérale ». Ces services d’aide à la conduite sont complétés par d’autres services d’aide à la conduite tels que le changement semi-automatique de voie connu sous l’acronyme anglo-saxon SALC (Semi-Automatic Change Lane), le freinage automatique d’urgence et l’alerte anti-collision désigné également par « FCW » (Forward Collision Warning), … Tous ces services permettent de contrôler la trajectoire et la vitesse du véhicule dans sa voie ou de changer de voie, sans l’intervention du conducteur. Les systèmes ADAS comportent généralement une pluralité de calculateurs appelés également ECU (Electronic Control Unit). Ces calculateurs reçoivent et traitent des données délivrées par une pluralité de capteurs embarqués dans le véhicule. Un des capteurs le plus généralement utilisé dans les systèmes ADAS est une caméra frontale, qui peut être une caméra multifonction et qui est généralement positionnée contre le pare-brise du véhicule, au niveau du rétroviseur intérieur. Les images captées par la caméra sont traitées par les calculateurs qui en relation avec d’autres données délivrées par d’autres capteurs du véhicule, commandent en autonomie différents organes du véhicule qui agissent sur le couple moteur, les freins, l’angle volant, etc. Les images captées par la caméra peuvent également servir d’éléments de preuve en cas de situations d’accident. Aujourd’hui, on connait notamment du document EP3274968A, un appareil et un procédé d’enregistrement de données associées au véhicule, en particulier des données vidéo captées par une caméra embarquée dans ledit véhicule. Les données vidéo sont enregistrées pendant une période de temps limitée débutant à partir de la détection et la validation d’un évènement déclencheur (trigger) prédéfini caractérisant un accident imminent ou en cours. L’enregistrement se poursuit tant que le trigger est considéré comme valide et s’arrête quand le trigger n’est plus considéré comme valide. Cette méthode permet de ne considérer que les événements jugés pertinents en relation avec la cause de l’accident (faute de conduite, éléments défaillants …) et de pouvoir exploiter les informations ultérieurement sans être pollué par un trop grand nombre d’informations non pertinentes. Ce document divulgue en fait une « boite noire » destinée à être exploitée par les sociétés d’assurance ainsi que, potentiellement, les services de police. Ce document ne considère que des triggers en relation avec un accident et n’ont d’autre but que de déterminer la cause et donc la responsabilité de l’accident. La présente invention propose une solution qui gère des données en relation avec des services d’aide à la conduite exploitant des triggers prédéfinis autour desquels les données environnementales collectées par les capteurs du véhicule, et notamment par une caméra, sont exploitées pour permettent d’expliquer au client (le conducteur), par des données de contexte précises, la cause du comportement de son véhicule. L’objectif de la présente invention est d’apporter une réponse simple et rapide pour analyser une réclamation d’un client dans son ressenti par rapport à un ou des services d’aide à la conduite. A cet effet, la présente invention a pour premier objet, un véhicule automobile comportant : - un système d’aide à la conduite, appelé système ADAS, offrant un ensemble de services d’aide à la conduite ; - un ensemble de capteurs comportant au moins une caméra, lesdits capteurs collectant des données en relation avec les services d’aide à la conduite ; - un ensemble de calculateurs synchronisés entre eux, dédiés au traitement des données reçues par l’ensemble des capteurs ; lesdits calculateurs étant couplés à des moyens de stockage provisoires pour stocker périodiquement les données ; - un organe de gestion couplé à l’ensemble de calculateur et agencés pour commander lesdits calculateurs ; - des moyens d’enregistrement permanent des données collectées par les capteurs à la suite de la réception d’au moins un événement déclencheur prédéterminé, appelé trigger, transmis par au moins un des calculateurs en relation avec un service déterminé ; - ledit organe de gestion étant agencé, en outre, pour commander les enregistrements des données et pour restituer, à partir des moyens d’enregistrement, les données d’au moins un contexte de déclenchement du trigger autour de l’instant de déclenchement de l’enregistrement. Selon une caractéristique, tous les calculateurs en relation avec l’événement déclencheur, sont agencés pour sauvegarder les données au moment de la transmission d’un trigger par l’un des calculateurs. Selon une autre caractéristique, les moyens de stockage provisoires sont des mémoires de type « RAM », structurées en « FIFO » : lorsque la mémoire est pleine, l’événement le plus ancien est remplacé par le nouveau. Selon une autre caractéristique, un trigger est identifié par son identifiant et son numéro d’enregistrement. Selon une autre caractéristique, les triggers en rapport avec des services d’aide à la conduite déterminés, sont prédéfinis. Selon une autre caractéristique, les triggers à enregistrer sont choisis parmi : une alerte anticollision, une demande de freinage d’urgence, une correction de l’angle volant, une information « crash ». Selon une autre caractéristique, le contexte de déclenchement est restitué entre -3 secondes et +2 secondes par rapport à l’instant de déclenchement. Selon une autre caractéristique, le contexte est restitué sous la forme d’une séquence d’images collectées par la caméra. La présente invention a pour deuxième objet, un procédé de gestion des données mis en œuvre par l’organe de gestion du véhicule tel que décrit ci-dessus, caractérisé en ce qu’il consiste : - dans une étape préalable, à définir les types d’événements à enregistrer et le nombre d’événement par type d’événement en relation avec chaque service d’aide à la conduite, et à identifier les données à enregistrer en relation avec chaque type d’événements ; - dans une première étape, à commander l’enregistrement périodique des données dans les moyens de stockage provisoires couplés aux calculateurs ; - dans une deuxième étape, lorsqu’un des calculateurs identifie un trigger, à commander la transmission du trigger, identifié par son « identifiant » et son « numéro », aux autres calculateurs ; - dans une troisième étape, à commander l’enregistrement des données reçues par tous les calculateurs ayant reçu ce trigger pendant une durée déterminée encadrant l’instant de déclenchement dans une mémoire permanente, et - dans une quatrième étape, à la suite d’une demande de restitution, à commander la restitution des données sous une forme permettant d’identifier la cause des décisions prises par les calculateurs à partir de la mémoire permanente. Enfin, la présente invention a pour troisième objet, un produit programme d’ordinateur comportant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé tel que décrit ci-dessus. La présente invention a pour principaux avantage d’être en mesure d’expliquer au client notamment par l’image, la cause de l’événement incriminé, d’identifier précisément le composant défaillant pour pouvoir le remplacer, le cas échéant, et être en mesure d’apporter la preuve grâce aux image couplées aux autres données enregistrées en rapport avec l’événement incriminé que le véhicule a réagi en respect des réglementations en vigueur en matière de conduite semi-autonome, voire autonome. D’autres avantages et caractéristiques pourront ressortir plus clairement de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif et faite en se référant au dessin dans lequel : illustre un schéma-bloc d’un véhicule automobile comportant un organe de gestion selon l’invention. La présente invention est basée sur le choix de triggers pertinents et une mémorisation contextualisée des données environnementales collectées par les capteurs présents dans le véhicule autour des triggers ainsi que la gestion des données mémorisées permettant d’identifier rapidement la cause du comportement du véhicule. Face à une multitude de services et notamment des services d’aide à la conduite semi-autonome voire autonome, le conducteur qui en quelque sorte est « spectateur » du comportement « autonome » de son véhicule, peut être parfois dérouté voire inquiété par les décisions du véhicule face à certaines situations pour lesquelles, le conducteur lui-même, dans une conduite « normale » et dans la même situation, pense qu’il aurait pris des décisions différentes. Les constructeurs automobiles doivent donc être en mesure d’apporter la preuve, et de préférence en images, que certains comportements du véhicule dictés par les services d’aide à la conduite, répondent bien au cahier des charges et aux réglementations en vigueur. Le comportement d’un véhicule est déterminé à partir d’un ensemble de données de contexte (données contextuelles) collectées par les différents capteurs présents dans le véhicule. On entend par « contexte » l’ensemble des données collectées autour d’un événement déterminé. Un certain nombre d’événements de déclenchement, appelé « triggers », sont prédéfinis en rapport avec certains services d’aide à la conduite mis en œuvre par le système ADAS dans le cadre d’une conduite semi-autonome voire autonome pour pouvoir déclencher l’enregistrement des données. Parmi les services d’aide à la conduite les plus utilisées, on citera notamment : le service de changement automatique de voie, connue également sous l’acronyme anglo-saxon « SALC » (pour Semi-Automatic Change Lane), le service « ACC » déjà évoqué, le freinage d’urgence connue également sous l’acronyme anglo-saxon « AEB » (pour Automatic Emergency Braking), l’alerte anticollision connue également sous l’acronyme anglo-saxon « FCW » (pour Forward Collision Warning), ... Il peut y avoir plusieurs « triggers » pour un même service ADAS. Chaque trigger comporte un identifiant unique et un numéro d’enregistrement. Ainsi, par exemple, en considérant la service « SALC », un premier trigger correspond à une interruption volontaire du service par le conducteur, un deuxième trigger correspond à une absence de changement de voie à la suite de l’activation de l’indicateur de changement de direction (clignotant) et un troisième trigger correspond à une absence de changement de voie à la suite d’une confirmation du conducteur. Une même donnée peut être reçue par plusieurs calculateurs qui sont synchronisés de manière à pourvoir partager la donnée qui est alors identifiée par chacun des calculateurs avec ses propres variables. Il est alors important de pouvoir déterminer si la donnée émane du calculateur dédié au service ADAS considéré ou d’un autre calculateur. Les données peuvent être organisées sous la forme d’un tableau comportant plusieurs colonnes. Dans une première colonne du tableau, on trouve tous les services ADAS. Dans une deuxième colonne, les triggers associés à chacun de ces services ADAS et dans une troisième colonne les données dites de contexte, associés à chaque trigger. Pour pouvoir retrouver toutes les données distribuées pour un même trigger, le trigger est identifié par son identifiant et son numéro d’enregistrement. On peut enregistrer plusieurs données de contexte pour un même trigger. Le nombre d’occurrence de données de contexte pour un même trigger est enregistré dans un compteur. Ce nombre est de préférence limité à 10 pour ne pas surcharger les espaces de stockage. Le concept de la présente invention est décrit ci-après en référence à la . La illustre sous la forme d’un schéma-bloc, un véhicule automobile 100 comportant un système ADAS 10, un organe de gestion de données 20 et un ensemble 30 de capteurs embarqués dans le véhicule 100, couplés au système ADAS 10. L’organe de gestion 20 est agencé pour commander les enregistrements des données et pour restituer, à partir de moyens d’enregistrement 50, les données d’au moins un contexte de déclenchement du trigger autour de l’instant de déclenchement de l’enregistrement. L’ensemble 30 de capteurs comporte des capteurs déjà présents dans le véhicule 100 parmi lesquels on trouve notamment une caméra frontale (ou multifonction) 31, un capteur de vitesse du véhicule 32, des capteurs 33 de pédales (frein, accélérateur, embrayage), un capteur d’angle volant 34 (angle de rotation du volant de direction), un capteur 35 de rapport de vitesse engagé dans la boite de vitesses, un indicateur de changement de direction (clignotant) 36, etc. Le système ADAS 10 comporte un ensemble de calculateurs 11 à 1n qui permettent de traiter les données collectées par les capteurs 31-36, notamment les images captées par la caméra 31. Toutes les données collectées sont synchronisées par les différents calculateurs 11-1n dédiés aux services ADAS offerts par le système ADAS 10. Les donnée et/ou images collectées sont enregistrées dans un ou plusieurs espaces de stockage embarqués 40 et/ou débarqués par exemple, dans une ou des mémoires vives de type RAM (Random Access Memory). Les données sont avantageusement stockées par type d’événement selon une structure FIFO (First In, First Out) : lorsque la mémoire 40 est pleine, l’événement le plus ancien est remplacé par le nouveau, pour garantir la couverture des différents cas. Le véhicule 100 comporte en outre une mémoire de stockage permanent par exemple une mémoire de type ROM 50 (Read Only Memory) pour éviter une perte de donnée en cas de coupure de contact ou suite à un accident. Cette mémoire 50 permet également de restituer ultérieurement les données sous la forme d’une séquence vidéo ou « mini-film » 60 permettant d’identifier la cause des décisions prises par les calculateurs 11-1n en retraçant/rejouant le contexte pour lequel un trigger a été déclenché. Les différentes étapes d’un procédé de gestion des données selon l’invention s’appuyant sur l’organe de gestion 20 est décrit ci-après. Dans une étape préalable, le procédé consiste à définir les types d’événements à enregistrer (exemples : alerte anticollision, demande de freinage, correction angle volant, information crash, …) et le nombre d’événements par type d’événements en relation avec chaque service d’aide à la conduite et, à identifier les données à enregistrer en relation avec chaque événement, leur fréquence d’enregistrement (exemples : la vitesse du véhicule toutes les 20ms, pour des images de 500x500 pixels en niveau de gris, toutes les 200ms, …). Il consiste également à définir en cohérence des capacités des calculateurs 11-1n, un nombre maximum d’événements enregistrables par type d’événements. Les principaux paramètres à prendre en compte sont la qualité et le nombre d’images par événement. Dans une première étape, en prenant l’exemple d’un enregistrement allant de -3s à +2s par rapport à l’événement (c’est-à-dire une période de temps commençant 3s avant la transmission d’un trigger et se terminant 2s après la transmission du trigger), le procédé consiste à commander l’enregistrement périodique des données dans la ou les RAM 40. Les calculateurs 11-1n peuvent supprimer les données de plus de 3s. Les calculateurs sont synchronisés entre eux suivant un protocole déterminé. Dans une deuxième étape, lorsque l’un des calculateurs 11-1n identifie qu’une donnée correspond à un des événements prédéfinis (par exemple : demande de freinage d’urgence), il commande la transmission d’un trigger, identifié par son « identifiant » et son « numéro » d’événement aux autres calculateurs 11-1n. Dans une troisième étape, le procédé consiste à commander l’enregistrement, avec un identifiant d’événement, les données reçues par tous les calculateurs ayant reçu ce trigger pendant une durée déterminée (de -3 à +2s) encadrant l’instant de déclenchement. La sauvegarde doit se faire au plus vite dans la ROM 50 pour éviter une perte de donnée en cas de coupure de contact ou à la suite d’un accident. Et dans une quatrième étape, suite à une demande de restitution, le procédé consiste à commander la restitution des données sous la forme d’une séquence vidéo 60 permettant d’identifier la cause de la transmission d’un trigger par les calculateurs 11-1n, à partir des données enregistrées dans la ROM 50. Le procédé de gestion implémente un produit programme d’ordinateur comportant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé. Ce programme est implémenté par exemple, par un ou plusieurs processeurs en lien avec le système ADAS 10, appartenant par exemple à un superviseur ADAS, non représenté, embarqué dans le véhicule 100 et qui est l’organe de supervision du système ADAS du véhicule 100. Le superviseur ADAS peut être lui-même en lien avec un ou plusieurs processeurs du système IVI (In-Vehicle Infotainment), non représenté, qui est l’organe central du véhicule 100 dédié au traitement des données et à la communication avec le conducteur. Un tel programme pourra être mis à jour avec possibilité d’ajout de services en utilisant une mise à jour par voie d’ondes de type OTA « Over The Air ». Enfin, l’organe de gestion 20 peut comporter un ou plusieurs calculateurs et/ou des composants logiciels dédiés à la gestion des données. Il peut être intégré soit dans le superviseur ADAS soit dans le système IVI, ou encore réparti dans le superviseur ADAS et dans le système IVI. Véhicule automobile (100) comportant : - un système d’aide à la conduite, appelé système ADAS (10), offrant un ensemble de services d’aide à la conduite ; - un ensemble de capteurs (30) comportant au moins une caméra (31), lesdits capteurs (30) collectant des données en relation avec les services d’aide à la conduite ; - un ensemble de calculateurs (11 à 1n) synchronisés entre eux, dédiés au traitement des données reçues par l’ensemble des capteurs (30) ; lesdits calculateurs (11-1n) étant couplés à des moyens de stockage provisoires (40) pour stocker périodiquement les données ; - un organe (20) de gestion couplé à l’ensemble de calculateur (11-1n) et agencés pour commander lesdits calculateurs (11-1n) ; - des moyens d’enregistrement permanent (50) des données collectées par les capteurs (30) à la suite de la réception d’au moins un événement déclencheur prédéterminé, appelé trigger, transmis par au moins un des calculateurs (11-1n) en relation avec un service déterminé ; - ledit organe de gestion (20) étant agencé, en outre, pour commander les enregistrements des données et pour restituer, à partir des moyens d’enregistrement (50), les données d’au moins un contexte de déclenchement du trigger autour de l’instant de déclenchement de l’enregistrement. Véhicule (100) selon la revendication précédente, dans lequel tous les calculateurs (11-1n) en relation avec l’événement déclencheur, sont agencés pour sauvegarder les données au moment de la transmission d’un trigger par l’un des calculateurs (10-1n). Véhicule (100) selon l’une des revendications précédentes, dans lequel les moyens de stockage provisoires (40) sont des mémoires de type « RAM », structurées en « FIFO » : lorsque la mémoire est pleine, l’événement le plus ancien est remplacé par le nouveau. Véhicule (100) selon l’une des revendications précédentes, dans lequel un trigger est identifié par son identifiant et son numéro d’enregistrement. Véhicule (100) selon l’une des revendications précédentes, dans lequel les triggers en rapport avec des services d’aide à la conduite déterminés, sont prédéfinis. Véhicule (100) selon la revendication précédente, dans lequel les triggers à enregistrer sont choisis parmi : une alerte anticollision, une demande de freinage d’urgence, une correction de l’angle volant, une information « crash ». Véhicule (100) selon l’une des revendications précédentes, dans lequel le contexte de déclenchement est restitué entre -3 secondes et +2 secondes par rapport à l’instant de déclenchement. Véhicule (100) selon l’une des revendications précédentes, dans lequel le contexte est restitué sous la forme d’une séquence d’images (60) collectées par la caméra (31). Procédé de gestion des données mis en œuvre par l’organe de gestion (20) du véhicule (100) selon l’une des revendications précédentes, caractérisé en ce qu’il consiste : - dans une étape préalable, à définir les types d’événements à enregistrer et le nombre d’événement par type d’événement en relation avec chaque service d’aide à la conduite, et à identifier les données à enregistrer en relation avec chaque type d’événements ; - dans une première étape, à commander l’enregistrement périodique des données dans les moyens de stockage provisoires (40) couplés aux calculateurs (11-1n) ; - dans une deuxième étape, lorsqu’un des calculateurs (11-1n) identifie un trigger, à commander la transmission du trigger, identifié par son « identifiant » et son « numéro », aux autres calculateurs (11-1n) ; - dans une troisième étape, à commander l’enregistrement des données reçues par tous les calculateurs (11-1n) ayant reçu ce trigger pendant une durée déterminée encadrant l’instant de déclenchement dans une mémoire permanente (50), et - dans une quatrième étape, à la suite d’une demande de restitution, à commander la restitution des données sous une forme (60) permettant d’identifier la cause des décisions prises par les calculateurs (11-1n) à partir de la mémoire permanente (50). Produit programme d’ordinateur comportant des instructions qui, lorsque le programme est exécuté par un ordinateur, conduisent celui-ci à mettre en œuvre les étapes du procédé selon la revendication précédente.