FR3067830A1 - Procede de transmission d'un rapport a un vehicule - Google Patents

Procede de transmission d'un rapport a un vehicule Download PDF

Info

Publication number
FR3067830A1
FR3067830A1 FR1755518A FR1755518A FR3067830A1 FR 3067830 A1 FR3067830 A1 FR 3067830A1 FR 1755518 A FR1755518 A FR 1755518A FR 1755518 A FR1755518 A FR 1755518A FR 3067830 A1 FR3067830 A1 FR 3067830A1
Authority
FR
France
Prior art keywords
vehicle
anomaly
station
report
data
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
FR1755518A
Other languages
English (en)
Other versions
FR3067830B1 (fr
Inventor
Richard Denis
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.)
Valeo Comfort and Driving Assistance SAS
Original Assignee
Valeo Comfort and Driving Assistance 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 Valeo Comfort and Driving Assistance SAS filed Critical Valeo Comfort and Driving Assistance SAS
Priority to FR1755518A priority Critical patent/FR3067830B1/fr
Priority to PCT/EP2018/066085 priority patent/WO2018229292A1/fr
Priority to US16/615,338 priority patent/US20200205006A1/en
Publication of FR3067830A1 publication Critical patent/FR3067830A1/fr
Application granted granted Critical
Publication of FR3067830B1 publication Critical patent/FR3067830B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425Traffic logging, e.g. anomaly detection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12Detection or prevention of fraud
    • H04W12/121Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122Counter-measures against attacks; Protection against rogue devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B60VEHICLES IN GENERAL
    • B60QARRANGEMENT OF SIGNALLING OR LIGHTING DEVICES, THE MOUNTING OR SUPPORTING THEREOF OR CIRCUITS THEREFOR, FOR VEHICLES IN GENERAL
    • B60Q9/00Arrangement or adaptation of signal devices not provided for in one of main groups B60Q1/00 - B60Q7/00, e.g. haptic signalling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02Services making use of location information
    • H04W4/025Services making use of location information using location based information parameters
    • H04W4/027Services making use of location information using location based information parameters using movement velocity, acceleration information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30Services specially adapted for particular environments, situations or purposes
    • H04W4/40Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Abstract

Un procédé de transmission d'un rapport à un véhicule (10) comprend les étapes suivantes : - détection, par une station (22), d'une anomalie relative au véhicule ; - transmission au véhicule (10) d'un rapport relatif à l'anomalie détectée.

Description

Procédé de transmission d’un rapport à un véhicule
Domaine technique auquel se rapporte l'invention
La présente invention concerne les véhicules équipés de systèmes embarqués susceptibles de subir des attaques informatiques et la protection contre de telles attaques informatiques.
Elle concerne plus particulièrement un procédé d’échange de données entre un véhicule et une station.
Arriere-plan technologique
Les véhicules (notamment les véhicules automobiles) utilisent de plus en plus fréquemment de nos jours des systèmes électroniques embarqués pour assurer des fonctionnalités variées pouvant aller jusqu’à la conduite autonome du véhicule.
Ces véhicules peuvent par ailleurs échanger des données, entre eux ou avec d’autres types de stations telles que des infrastructures routières ou des dispositifs électroniques divers (par exemple un ordiphone porté par un piéton), par exemple au moyen de système de communication généralement dénommés V2X'.
De tels véhicules peuvent dès lors faire l’objet d’attaques informatiques visant leurs systèmes embarqués et on prévoit de ce fait d’équiper les véhicules d’un système de protection contre les attaques informatiques.
Objet de l’invention
Dans ce contexte, la présente invention propose un procédé de transmission d’un rapport à un véhicule, comprenant les étapes suivantes :
- détection, par une station, d’une anomalie relative au véhicule ;
- transmission au véhicule d’un rapport relatif à l’anomalie détectée (de manière directe ou indirecte par rapport à la station, comme expliqué plus loin).
Une telle anomalie, présente par exemple dans des données émises par le véhicule, peut découler d’une attaque informatique résiduelle, non détectée par le système de protection précité, ou d’une action inappropriée de ce système de protection. Le véhicule peut ainsi tenir compte de l’anomalie détectée par la station et signalée dans le rapport pour prendre les mesures nécessaires et se protéger de cette potentielle attaque résiduelle.
Selon d’autres caractéristiques envisageables à titre optionnel (et donc non limitatif) :
- le procédé comprend une étape de réception, par la station et via une communication sans fil entre la station et le véhicule, de données en provenance du véhicule ;
- l’anomalie détectée par la station est une anomalie au sein desdites données (en provenance du véhicule) ;
- l’anomalie détectée par la station est (en variante) un comportement physique anormal et/ou inhabituel et/ou suspect du véhicule, ce comportement physique étant détecté par la station ;
- le rapport est transmis via une communication sans fil entre la station et le véhicule (en pratique via la communication sans fil mentionnée plus haut ou éventuellement via une autre communication sans fil entre la station et le véhicule) ;
- le rapport est transmis au véhicule par un serveur distant ;
- le serveur distant est conçu pour émettre un message destiné au conducteur ou au propriétaire du premier véhicule et signalant l’anomalie détectée ;
- la station est conçue pour émettre un message de détection d’anomalie à destination du serveur distant ;
- le serveur distant est conçu pour traiter une pluralité de messages de détection d’anomalie reçus respectivement en provenance d’une pluralités de stations et pour en déduire le rapport ;
- le procédé comprend une étape de mise en œuvre d’une action au sein du véhicule subséquemment à la réception du rapport ;
- ladite action comprend la désactivation et/ou l’isolement (autrement dit la mise en quarantaine) d’un système embarqué affecté par une attaque ;
- ladite action comprend l’arrêt de l’émission de données via une communication sans fil (par exemple la communication sans fil entre la station et le véhicule) ;
- ladite action comprend un basculement vers une configuration sûre du système de protection contre les attaques susmentionné ;
- ladite action comprend une étape de mise à jour d’un logiciel embarqué dans le véhicule ;
- ladite action comprend un basculement d’une fonctionnalité du véhicule (par exemple une fonctionnalité de conduite autonome) dans un mode de fonctionnement sûr (ou dans un mode de fonctionnement dégradé) ;
- ladite action comprend une étape d’inhibition d’actions automatiques effectuées par le véhicule ;
- le procédé comprend une étape de transmission d’un message d’avertissement à l’intérieur du véhicule (message destiné au conducteur du véhicule et/ou à un passager du véhicule) ;
- le rapport comprend un identifiant de l’anomalie détectée ou un type de l’anomalie détectée ;
- le rapport comprend un niveau de confiance associé à l’anomalie détectée ;
- le rapport comprend une action recommandée et/ou une mesure de capacité de détection d’anomalie de la station et/ou une preuve de l’anomalie détectée et/ou des informations relatives au véhicule (véhicule affecté) ;
- la station équipe un autre véhicule ;
- la station équipe une infrastructure routière ;
- la station équipe un dispositif électronique portable (tel qu’un ordiphone ou smartphone selon l’appellation couramment utilisée), porté par exemple par un piéton.
Description detaillee d’un exemple de réalisation
La description qui va suivre en regard des dessins annexés, donnés à titre d’exemples non limitatifs, fera bien comprendre en quoi consiste l’invention et comment elle peut être réalisée.
Sur les dessins annexés :
- la figure 1 représente schématiquement un premier exemple de contexte de mise en œuvre de l’invention ;
- la figure 2 représente un exemple de procédé mis en œuvre dans le cadre de la figure 1 ;
- la figure 3 représente schématiquement un second exemple de contexte de mise en œuvre de l’invention ; et
- la figure 4 représente un exemple de procédé mis en œuvre dans le cadre de la figure 3.
La figure 1 représente un premier véhicule 10 et un second véhicule 20, qui empruntent ici une même voie de circulation.
On décrit dans la suite seulement les éléments de ces véhicules 10, 20 utiles à la compréhension de l’invention.
Le premier véhicule 10 comprend une unité de commande 12, un module de communication sans fil 14, un système de navigation 16 et un système de conduite autonome 18.
Le premier véhicule 10 comprend également un système de protection contre les attaques 11 et des capteurs 17 (par exemple des radars et/ou des caméras).
L’unité de commande 12 (réalisée par exemple en pratique par un microcontrôleur ou, en variante, répartie dans plusieurs système embarqués) est conçue pour gérer et coordonner le fonctionnement des autres équipements du véhicule, notamment comme décrit ci-après.
Le module de communication sans fil 14 est conçu pour établir des communications sans fil avec des stations avoisinantes, ces stations équipant par exemple un autre véhicule (comme décrit plus loin) ou une infrastructure routière, ou encore un dispositif électronique portable porté éventuellement par un piéton.
Le système de navigation 16 comprend quant à lui notamment un système de positionnement qui délivre des informations indicatives de la position du premier véhicule 10 (par exemple dans le référentiel terrestre), ainsi qu’éventuellement une information temporelle (temps absolu).
Le système de conduite autonome 18 est conçu pour assurer le déplacement du premier véhicule 10 sans intervention de son conducteur. Pour ce faire, le système de conduite autonome commande des organes de conduite du premier véhicule 10 (par exemple un groupe motopropulseur et/ou un système de freinage et/ou un système de commande de direction) en fonction d’informations reçus de différents capteurs équipant le premier véhicule 10 et délivrant des données descriptives de l’environnement du premier véhicule 10.
Le système de protection contre les attaques 11 (ou CDS pour CyberDefense System) permet la détection et le traitement d’attaques informatiques susceptibles de survenir au sein du premier véhicule 10, notamment du fait des échanges de données effectués avec des dispositifs extérieurs grâce au module de communication sans fil 14. En variante, ce système de protection pourrait être réparti au sein des différents éléments 12, 14, 16, 18.
Le second véhicule 20 est équipé d’une station 22 comprenant une unité de communication sans fil 24 et une unité de détection d’anomalie 26.
Une telle station 22 intègre ainsi une fonctionnalité de télécommunication sans fil avec d’autres entités, par exemple avec d’autres stations du même type. La station 22 est par exemple une station ITS (pour Intelligent Transport System) tel que définie par la norme ETSI EN 302 665.
L’unité de communication 24 est notamment apte à établir une communication sans fil avec le module de télécommunication sans fil 14 du premier véhicule 10 lorsque le premier véhicule 10 et le second véhicule 20 sont à proximité l’un de l’autre (typiquement à une distance de quelques centaines de mètre, par exemple une distance inférieure à une distance maximale comprise entre 300 m et 1 km, voire plus si la communication était relayée par des stations intermédiaires).
Comme expliqué plus en détail ci-après, l’unité de détection d’anomalie 26 analyse des données S reçues par le second véhicule 20 en provenance du premier véhicule 10 via la communication sans fil ainsi établie, vérifie la cohérence de ces données, et commande l’émission d’un rapport R à destination du premier véhicule 10 (ici toujours via la communication établie ou, en variante, via une autre communication sans fil mise en œuvre entre le premier véhicule 10 et la station 22 par des moyens de communication alternatifs) en cas de détection d’une anomalie au sein de ces données.
La figure 2 représente un exemple de procédé mis en œuvre dans le contexte qui vient d’être décrit.
Ce procédé débute à l’étape E2 par l’émission de données S par le premier véhicule 10, à destination du second véhicule 20 et via la communication établie entre le module de communication sans fil 14 et l’unité de communication sans fil 24.
Ces données S sont par exemple des données émises en fonctionnement normal par le premier véhicule 10, telles que :
- des données d’état, par exemple la position du premier véhicule 10 (telle que déterminée par le système de navigation 16) et/ou l’orientation du premier véhicule 10 (telle que déterminée par le système de navigation 16 et/ou les capteurs 11) et/ou la vitesse du premier véhicule 10 et/ou l’accélération du premier véhicule 10 et/ou l’état allumé/éteint d’au moins un dispositif d’éclairage ou de signalisation et/ou la position (typiquement l’angle) du volant du premier véhicule 10 et/ou un historique du trajet emprunté par le premier véhicule 10 et/ou l’horodatage des données précitées (cet horodatage pouvant être effectué au moyen de l’information temporelle susmentionnée fournie par le système de navigation 16) ;
- des données de signalement d’un danger, par exemple de signalement d’un accident ou d’une panne ou d’une zone dangereuse (telle que chaussée glissante) ou d’un phénomène météorologique (tel que du brouillard) ou d’une zone d’embouteillage ou d’une présence d’objet sur la chaussée.
Ces données S sont ainsi reçues par le second véhicule 20 (via l’unité de communication sans fil 24) à l’étape E4.
L’unité de détection d’anomalie 26 peut ainsi analyser à l’étape E6 ces données S afin notamment d’en vérifier la cohérence et de détecter éventuellement une anomalie.
Une telle anomalie peut notamment être causée par une attaque informatique résiduelle au sein de l’un des éléments susmentionnés 11, 12, 14, 16, 17, 18 du premier véhicule 10. On dénomme attaque informatique résiduelle une attaque informatique une attaque informatique qui n’a pas été (correctement) traitée par le système de protection mentionné plus haut. Une telle anomalie peut également être causée par une action ou une réaction inadaptée de ce système de protection.
L’unité de détection d’anomalie 26 peut ainsi par exemple détecter une anomalie (i.e. une incohérence) dans la position du premier véhicule 10 (information reçue parmi les données S) en comparant cette position aux informations de position préalablement reçues en provenance du premier véhicule 10 et/ou à la position du second véhicule 20 (telle que déterminée par des systèmes propres au second véhicule 20).
En effet, en fonctionnement normal, la position du premier véhicule 10 indiquée par les données reçues S ne devraient pas substantiellement différer (par exemple de plus de 100 km) des informations de position préalablement reçues en provenance du premier véhicule 10 ou de la position du second véhicule 20.
L’unité de détection d’anomalie 26 peut naturellement analyser et vérifier la cohérence d’autres types de données. Par exemple, l’unité de détection d’anomalie 26 peut comparer la vitesse du premier véhicule 10 indiquée dans les données reçues S avec la vitesse du premier véhicule 10 telle que mesurée par des capteurs équipant le second véhicule 20.
En variante, l’anomalie détectée pourrait être un comportement anormal (et/ou inhabituel et/ou suspect) du premier véhicule 10 (par exemple le fait de rouler très lentement sur autoroute et/ou de rouler sans lumière de nuit) détecté par la station 22.
L’unité de détection d’anomalie 26 peut alors commander à l’étape E8 l’émission, par l’unité de communication sans fil 24 et à destination du premier véhicule 10 (via la communication sans fil établie entre le module de communication sans fil 14 et l’unité de communication sans fil 24), d’un rapport R contenant certaines au moins des informations suivantes :
- une information relative au premier véhicule 10, par exemple une information identifiant le premier véhicule 10 tel qu’un identifiant du premier véhicule 10 contenu dans les données S susmentionnées et/ou un identifiant du premier véhicule 10 utilisée dans la communication sans fil (par exemple une adresse IP ou une adresse MAC) et/ou un numéro de plaque d’immatriculation du premier véhicule 10 ;
- un identifiant (ou le type) de l’anomalie détectée (indiquant par exemple quelle donnée parmi les données S est considérée anormale, i.e. incohérente) ;
- un niveau de confiance associé à la détection d’anomalie (ce niveau de confiance étant produit par l’unité de détection d’anomalie 26 en fonction des conditions qui ont conduit à la détection d’anomalie) ;
- les données ayant conduit à la détection de l’anomalie (par exemple ici les positions du premier véhicule 10 préalablement reçues et/ou la position du second véhicule 20 dont la comparaison à la donnée reçue S a conduit à la détection de l’anomalie ou, de manière similaire, la vitesse du premier véhicule 10 indiquée dans les données S dont la comparaison à la vitesse du premier véhicule 10 mesurée par des capteurs du second véhicule 20 a conduit à la détection de l’anomalie), ou preuve de l’anomalie ;
- une mesure de capacité de détection associée à l’unité de détection d’anomalie 26 (cette mesure étant par exemple liée aux types de capteurs équipant la station 22 ou le second véhicule 20).
L’unité de commande 12 équipant le premier véhicule 10 reçoit ce rapport R à l’étape E10 et peut ainsi déterminer en fonction des données contenues dans ce rapport R si une action doit être mise en place.
Dans l’affirmative, comme représenté en figure 2, une action est effectuée à l’étape E12 sous la commande de l’unité de commande 12.
Une telle action peut être une action corrective (i.e. visant à réparer le système considéré défectueux), par exemple une commande de mise à jour du logiciel du système considéré défectueux (ici le système de navigation 16).
Une telle action peut être une action préventive, par exemple une commande d’un système du véhicule (tel que le système de conduite autonome 18) dans un mode de fonctionnement sûr (ou fail-safe mode selon l’appellation parfois utilisée) ou dans un mode de fonctionne dégradé (dans lequel, par exemple, un système particulier modifie sa configuration pour ne pas avoir recours à une information donnée). À réception d’une telle commande, le système de conduite autonome 18 peut par exemple désactiver la conduite autonome, et ainsi rendre la main au conducteur (si celui-ci est disponible) ou commander l’arrêt du véhicule dans une zone protégée.
Une telle action peut également être l’inhibition de toute action automatique par les systèmes électroniques (notamment 11, 12, 14, 16, 18) du premier véhicule 10.
Une telle action peut aussi comprendre la désactivation et/ou l’isolement (autrement dit la mise en quarantaine) d’un système embarqué affecté par une attaque (tel que déterminé par exemple sur la base du rapport R susmentionné).
Une telle action peut comprendre l’arrêt de l’émission de données via une communication sans fil (par exemple via la communication sans fil susmentionnée).
Une telle action peut également comprendre un retour à une configuration sûre du système de protection 11.
Une telle action peut par ailleurs comprendre l’affichage d’une indication signalant l’anomalie détectée (mentionnée dans le rapport R) au conducteur du premier véhicule 10.
Dans l’exemple qui vient d’être décrit, la station 22 fait partie du second véhicule 20. En variante, la station 22 pourrait être intégrée à un autre type d’élément de l’environnement routier, par exemple à un élément d’infrastructure routière.
La figure 3 représente schématiquement un autre exemple de contexte dans lequel peut être mise en œuvre l’invention.
Comme dans le cas de la figure 1, un premier véhicule 110 et un second véhicule 120 empruntent une même voie de circulation.
Le premier véhicule 110 comprend une unité de commande 112, un module de communication sans fil 114, un système de protection contre les attaques 111, un système de navigation 116, des capteurs 117 et un système de conduite autonome 118. Ces éléments sont similaires à ceux décrits ci-dessus en référence à la figure 1 et ne seront donc pas décrits à nouveau.
Le second véhicule 120 est quant à lui équipé d’une station 122 comprenant une unité de communication sans fil 124 et une unité de détection d’anomalie 126. Ici encore, ces éléments sont similaires à ceux décrits ci-dessus dans le cadre de la figure 1.
Dans le contexte de la figure 3 est prévue en outre une station de base 140 apte à établir une communication sans fil avec le module de communication sans fil 114 du premier véhicule 110 ou avec l’unité de communication sans fil 124 du second véhicule 120.
La station de base 140 est par ailleurs reliée via un réseau 150 (qui inclut par exemple un réseau public tel que le réseau Internet) à un serveur distant 130. Comme cela ressortira dans la suite, ce serveur distant 130 est un gestionnaire centralisé distant des systèmes de protection contre les attaques informatiques (ou RCCM pour Remote Central CDS Manager1'). Ce serveur 130 agrège et fiabilise les rapports d’anomalie lui ayant été soumis par toutes les différentes stations ayant détecté des anomalies du premier véhicule 110.
Grâce à ces différents moyens de communication, l’unité de commande 112 du premier véhicule 110 et la station 122 équipant le second véhicule 120 peuvent chacune échanger des données avec le serveur distant 130, notamment comme expliqué ci-après en référence à la figure 4.
Par ailleurs, comme dans le cadre du mode de réalisation des figures 1 et 2, l’unité de commande 112 du premier véhicule 110 et la station 122 équipant le second véhicule 120 peuvent échanger des données entre elles via la communication établie entre le module de communication sans fil 114 et l’unité de communication sans fil 124.
La figure 4 représente un exemple de procédé mis en œuvre dans le contexte de la figure 3.
Ce procédé débute à l’étape E20 par l’émission de données S par le premier véhicule 110, à destination du second véhicule 120 et via la communication établie entre le module de communication sans fil 114 et l’unité de communication sans fil 124.
Ces données S sont par exemple des données émises en fonctionnement normal par le premier véhicule 110, telles que :
- des données d’état, par exemple la position du premier véhicule 110 (telle que déterminée par le système de navigation 116) et/ou l’orientation du premier véhicule 110 (telle que déterminée par le système de navigation 116 et/ou les capteurs 111) et/ou la vitesse du premier véhicule 110 et/ou l’accélération du premier véhicule 110 et/ou l’état allumé/éteint d’au moins un dispositif d’éclairage ou de signalisation et/ou la position (typiquement l’angle) du volant du premier véhicule 110 et/ou un historique du trajet emprunté par le premier véhicule 110 et/ou l’horodatage des données précitées (cet horodatage pouvant être effectué au moyen d’une information temporelle délivrée par le système de navigation 116) ;
- des données de signalement d’un danger, par exemple de signalement d’un accident ou d’une panne ou d’une zone dangereuse (telle que chaussée glissante) ou d’un phénomène météorologique (tel que du brouillard) ou d’une zone d’embouteillage ou d’une présence d’objet sur la chaussée.
Ces données S sont ainsi reçues par le second véhicule 120 (via l’unité de communication sans fil 124) à l’étape E22.
L’unité de détection d’anomalie 126 peut ainsi analyser à l’étape E24 ces données S afin notamment d’en vérifier la cohérence et de détecter éventuellement une anomalie.
Une telle anomalie peut notamment être causée par une attaque informatique résiduelle au sein de l’un des éléments susmentionnés 112, 114, 116, 118 du premier véhicule 110. Une telle anomalie peut également être causée par une action ou une réaction inadaptée de ce système de protection.
L’unité de détection d’anomalie 126 peut ainsi par exemple détecter une anomalie (i.e. une incohérence) dans la position du premier véhicule 110 (information reçue parmi les données S) en comparant cette position aux informations de position préalablement reçues en provenance du premier véhicule 110 et/ou à la position du second véhicule 120 (telle que déterminée par des systèmes propres au second véhicule 120).
Comme indiqué plus haut, l’unité de détection d’anomalie 126 peut naturellement analyser et vérifier la cohérence d’autres types de données.
L’unité de détection d’anomalie 126 peut alors commander à l’étape E26 l’émission, par l’unité de communication sans fil 24 et à destination du serveur distant 130 (via la station de base 140 comme expliqué ci-dessus), d’un message d’anomalie A contenant certaines au moins des informations suivantes :
- un identifiant (ou le type) de l’anomalie détectée (indiquant par exemple quelle donnée parmi les données S est considérée anormale, i.e. incohérente) ;
- un identifiant du premier véhicule 110 (véhicule émetteur des données S parmi lesquelles une anomalie est détectée), par exemple un identifiant du premier véhicule 110 contenu dans les données S susmentionnées et/ou un identifiant du premier véhicule 110 utilisé dans la communication sans fil (par exemple une adresse IP ou une adresse MAC) et/ou le numéro de la plaque d’immatriculation du premier véhicule 110 ;
- un niveau de confiance associé à la détection d’anomalie (ce niveau de confiance étant produit par l’unité de détection d’anomalie 126 en fonction des conditions qui ont conduit à la détection d’anomalie) ;
- les données ayant conduit à la détection de l’anomalie (par exemple ici les positions du premier véhicule 110 préalablement reçues et/ou la position du second véhicule 120 dont la comparaison à la donnée reçue S a conduit à la détection de l’anomalie), ou preuve de l’anomalie ;
- une mesure de capacité de détection associée à l’unité de détection d’anomalie 126 (cette mesure étant par exemple liée aux types de capteurs équipant la station 22 ou le second véhicule 20).
Le serveur distant 130 reçoit le message d’anomalie A à l’étape E28 et traite ce message d’anomalie A à l’étape E30.
Ce traitement peut impliquer par exemple la comparaison ou le recoupement de l’anomalie signalée par le message d’anomalie A avec d’autres anomalies signalées éventuellement par d’autres stations en ce qui concerne ce même véhicule (ici le premier véhicule 110).
Sur la base du traitement de l’étape E30 (qui utilise les données contenues dans le message d’anomalie A ainsi qu’éventuellement d’autres données d’anomalie relatives au véhicule identifié par l’identifiant contenu dans le message d’anomalie A), le serveur distant 130 peut décider de générer et de transmettre (étape E32) au premier véhicule 110 (concerné par l’anomalie détectée) un rapport R qui contient certaines au moins des données suivantes :
- un identifiant de l’anomalie détectée (indiquant par exemple quelle donnée parmi les données S est considérée anormale, i.e. incohérente) ;
- un niveau de confiance associé à l’anomalie détectée (ce niveau de confiance étant déterminé par le serveur distant 130, par exemple en fonction de niveaux de confiance respectivement contenus dans divers messages reçus par le serveur distant 130 et du nombre de tels message signalant cette anomalie) ;
- une description de l’origine potentielle du problème ayant produit l’anomalie (origine potentielle déterminée par le serveur distant 130) : par exemple, l’origine du problème est indiquée comme étant un des systèmes du premier véhicule 110, tel que le système de navigation 116, ayant été victime d’une attaque ;
- une action recommandée (déterminée également par le serveur distant
130).
On remarque que le serveur distant 130 peut en pratique traiter une pluralité de messages de détection d’anomalie reçus respectivement en provenance d’une pluralité de stations et déduire le rapport R sur la base de ces messages de détection d’anomalie.
Le serveur distant 130 peut en outre émettre un message destiné au conducteur du premier véhicule 110 afin de signaler à ce conducteur l’anomalie détectée. Ce message peut être un message court ou un message électronique. En variante, le message peut être adressé par courrier, par exemple par courrier recommandé. Un tel message peut être par exemple transmis et affiché sur un terminal mobile du conducteur, qui peut par exemple en prendre connaissance lorsque le premier véhicule 110 est en mode de conduite autonome. Ce message peut par exemple recommander au conducteur de désactiver le mode de conduite autonome et de reprendre en main la conduite du premier véhicule 110.
L’unité de commande 112 équipant le premier véhicule 110 reçoit le rapport R mentionné plus haut à l’étape E34 et peut ainsi déterminer en fonction des données contenues dans ce rapport R si une action doit être mise en place.
Le traitement effectué par l’unité de commande 112 peut être conforme à ce rapport R, du fait en particulier que le rapport R provient d’un serveur distant 130 et peut ainsi tenir compte de données collectées auprès d’une pluralité de stations avoisinant le premier véhicule 110.
Une action (par exemple une action recommandée contenue dans le rapport R) peut alors être effectuée à l’étape E36 sous la commande de l’unité de commande 112.
Une telle action peut être une action corrective (i.e. visant à réparer le système considéré défectueux), par exemple une commande de mise à jour du logiciel du système considéré défectueux (ici le système de navigation 116).
Une telle action peut être une action préventive, par exemple une commande d’un système du véhicule (tel que le système de conduite autonome 118) dans un mode de fonctionnement sûr (ou fail-safe mode selon l’appellation parfois utilisée) ou dans un mode de fonctionne dégradé (dans lequel, par exemple, un système particulier modifie sa configuration pour ne pas avoir recours à une information donnée). À réception d’une telle commande, le système de conduite autonome 118 peut par exemple désactiver la conduite autonome, et ainsi rendre la main au conducteur (si celui-ci est disponible) ou commander l’arrêt du véhicule dans une zone protégée.
Une telle action peut également être l’inhibition de toute action automatique par les systèmes électroniques (notamment 112, 114, 116, 118) du premier véhicule 110.
Une telle action peut aussi comprendre la désactivation et/ou l’isolement (autrement dit la mise en quarantaine) d’un système embarqué affecté par une attaque (tel que déterminé par exemple sur la base du rapport R susmentionné).
Une telle action peut comprendre l’arrêt de l’émission de données via une communication sans fil (par exemple via la communication sans fil susmentionnée).
Une telle action peut également comprendre un retour à une configuration sûre du système de protection 111.
Une telle action peut par ailleurs comprendre l’affichage d’une indication signalant l’anomalie détectée (mentionnée dans le rapport R) au conducteur du premier véhicule 110.
Dans l’exemple qui vient d’être décrit, la station 122 fait partie du second véhicule 120. En variante, la station 122 pourrait être intégrée à un autre type d’élément de l’environnement routier, par exemple à un élément d’infrastructure routière. La station 122 pourrait dans ce cas être par exemple intégrée à la station de base 140.

Claims (14)

  1. REVENDICATIONS
    1. Procédé de transmission d’un rapport (R) à un véhicule (10 ; 110), comprenant les étapes suivantes :
    - détection (E6 ; E24), par une station (22 ; 122), d’une anomalie relative au véhicule ;
    - transmission (E8 ; E32) au véhicule (10 ; 110) d’un rapport (R) relatif à l’anomalie détectée.
  2. 2. Procédé selon la revendication 1, comprenant une étape de réception (E4 ; E22), par la station (22 ; 122) et via une communication sans fil entre la station (22 ; 122) et le véhicule (10 ; 110), de données (S) en provenance du véhicule (10 ; 110), dans lequel l’anomalie détectée par la station (22 ; 122) est une anomalie au sein desdites données (S).
  3. 3. Procédé selon la revendication 1 ou 2, dans lequel le rapport (R) est transmis via une communication sans fil entre la station (22) et le véhicule (10).
  4. 4. Procédé selon la revendication 1 ou 2, dans lequel le rapport (R) est transmis au véhicule (110) par un serveur distant (130).
  5. 5. Procédé selon la revendication 4, dans lequel le serveur distant (130) est conçu pour émettre un message destiné au conducteur ou au propriétaire du premier véhicule (110) et signalant l’anomalie détectée.
  6. 6. Procédé selon la revendication 4 ou 5, dans lequel la station (122) est conçue pour émettre un message de détection d’anomalie (A) à destination du serveur distant (130).
  7. 7. Procédé selon l’une des revendications 4 à 6, dans lequel le serveur distant (130) est conçu pour traiter une pluralité de messages de détection d’anomalie reçus respectivement en provenance d’une pluralité de stations et pour en déduire le rapport (R).
  8. 8. Procédé selon l’une des revendications 1 à 7, comprenant une étape (E12 ; E36) de mise en œuvre d’une action au sein du véhicule (10; 110) subséquemment à la réception du rapport (R).
  9. 9. Procédé selon la revendication 8, dans lequel ladite action comprend une au moins des étapes suivantes :
    - mise à jour d’un logiciel embarqué dans le véhicule (10 ; 110) ;
    - basculement d’une fonctionnalité du véhicule (10 ; 110) dans un mode de fonctionnement sûr ;
    - inhibition d’actions automatiques effectuées par le véhicule (10 ; 110) ;
    - désactivation ou isolement d’un système embarqué ;
    - arrêt de l’émission de données via une communication sans fil ;
    - basculement vers une configuration sûre d’un système de protection contre les attaques informatiques.
  10. 10. Procédé selon l’une des revendications 1 à 9, comprenant une étape de transmission d’un message d’avertissement à l’intérieur du véhicule (10 ; 110).
  11. 11. Procédé selon l’une des revendications 1 à 10, dans lequel le rapport (R) comprend au moins une information parmi les informations suivantes : un identifiant de l’anomalie détectée, un type de l’anomalie détectée, un niveau de confiance associé à l’anomalie détectée, une action recommandée, une mesure de capacité de détection d’anomalie de la station (22; 122), une preuve de l’anomalie détectée, des informations relatives au véhicule (10 ; 110).
  12. 12. Procédé selon l’une des revendications 1 à 11, dans lequel la station (22 ; 122) équipe un autre véhicule (20 ; 120).
  13. 13. Procédé selon l’une des revendications 1 à 11, dans lequel la station équipe une infrastructure routière.
  14. 14. Procédé selon l’une des revendications 1 à 11, dans lequel la station équipe un dispositif électronique portable.
FR1755518A 2017-06-16 2017-06-16 Procede de transmission d'un rapport a un vehicule Active FR3067830B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR1755518A FR3067830B1 (fr) 2017-06-16 2017-06-16 Procede de transmission d'un rapport a un vehicule
PCT/EP2018/066085 WO2018229292A1 (fr) 2017-06-16 2018-06-18 Procédé de transmission d'un rapport à un véhicule
US16/615,338 US20200205006A1 (en) 2017-06-16 2018-06-18 Method for transmitting a report to a vehicle

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1755518 2017-06-16
FR1755518A FR3067830B1 (fr) 2017-06-16 2017-06-16 Procede de transmission d'un rapport a un vehicule

Publications (2)

Publication Number Publication Date
FR3067830A1 true FR3067830A1 (fr) 2018-12-21
FR3067830B1 FR3067830B1 (fr) 2023-10-06

Family

ID=60080930

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1755518A Active FR3067830B1 (fr) 2017-06-16 2017-06-16 Procede de transmission d'un rapport a un vehicule

Country Status (3)

Country Link
US (1) US20200205006A1 (fr)
FR (1) FR3067830B1 (fr)
WO (1) WO2018229292A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7251116B2 (ja) * 2018-11-21 2023-04-04 トヨタ自動車株式会社 車両、車両制御方法、及び車両制御プログラム
US11233650B2 (en) * 2019-03-25 2022-01-25 Micron Technology, Inc. Verifying identity of a vehicle entering a trust zone
US11532188B2 (en) * 2019-08-22 2022-12-20 GM Global Technology Operations LLC Architecture and methodology for state estimation failure detection using crowdsourcing and deep learning
US11695574B2 (en) * 2020-04-29 2023-07-04 Blackberry Limited Method and system for establishing trust for a cybersecurity posture of a V2X entity

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070213922A1 (en) * 2006-03-10 2007-09-13 Van Buer Darrel J Traffic notification system for reporting traffic anomalies based on historical probe vehicle data
US7421334B2 (en) * 2003-04-07 2008-09-02 Zoom Information Systems Centralized facility and intelligent on-board vehicle platform for collecting, analyzing and distributing information relating to transportation infrastructure and conditions
WO2013087514A1 (fr) * 2011-12-16 2013-06-20 Renault S.A.S. Commande du mode autonome de vehicules bi-modaux

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100023201A1 (en) * 2008-07-24 2010-01-28 David Scott Kinney Method and apparatus for obtaining vehicle data
US8909415B1 (en) * 2009-06-02 2014-12-09 Chadwick Todd Hawley Vehicle and personal service monitoring and alerting systems
US20140143839A1 (en) * 2011-11-16 2014-05-22 Flextronics Ap, Llc. On board vehicle remote control module
ITMI20131701A1 (it) * 2013-10-15 2015-04-16 Consiglio Nazionale Ricerche Sistema di acquisizione ed elaborazione di immagini subacquee
US10250689B2 (en) * 2015-08-25 2019-04-02 Robert Bosch Gmbh Security monitor for a vehicle
US9813911B2 (en) * 2015-12-08 2017-11-07 Panasonic Avionics Corporation Methods and systems for monitoring computing devices on a vehicle
US10444748B2 (en) * 2016-06-30 2019-10-15 Ge Aviation Systems Llc In-situ measurement logging by wireless communication unit for communicating engine data
US10054947B2 (en) * 2016-08-17 2018-08-21 Omnitracs, Llc Emergency stopping for autonomous commercial vehicles
US10795378B2 (en) * 2017-06-13 2020-10-06 Verizon Patent And Licensing Inc. Remote token-based control of autonomous vehicles

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7421334B2 (en) * 2003-04-07 2008-09-02 Zoom Information Systems Centralized facility and intelligent on-board vehicle platform for collecting, analyzing and distributing information relating to transportation infrastructure and conditions
US20070213922A1 (en) * 2006-03-10 2007-09-13 Van Buer Darrel J Traffic notification system for reporting traffic anomalies based on historical probe vehicle data
WO2013087514A1 (fr) * 2011-12-16 2013-06-20 Renault S.A.S. Commande du mode autonome de vehicules bi-modaux

Also Published As

Publication number Publication date
FR3067830B1 (fr) 2023-10-06
WO2018229292A1 (fr) 2018-12-20
US20200205006A1 (en) 2020-06-25

Similar Documents

Publication Publication Date Title
WO2018229292A1 (fr) Procédé de transmission d'un rapport à un véhicule
US10183677B2 (en) Ice and snow detection systems and methods
US11019084B2 (en) Controller, a context broadcaster and an alert processing device
KR102156261B1 (ko) 차량에 대한 공격의 검출 및 예방을 위한 디바이스
CA3052189C (fr) Systeme d'evaluation d'evenement de conduite
EP3948820B1 (fr) Procédé de sécurisation de franchissement d'un feu de circulation par un véhicule, ainsi que produit programme d'ordinateur correspondant
US20230019817A1 (en) Autonomous vehicle security measures in response to an attack on an in-vehicle communication network
CN107590995B (zh) 用于维护包括报告的影响交通事件的数据库的方法和系统
FR3100203A1 (fr) Procédé et dispositif d’alerte d’évènement pour véhicule
FR3046770B1 (fr) Dispositif et procede de fourniture d'informations relatives a des vehicules circulant incapables d'echanger des messages
FR3106553A1 (fr) Procédé et dispositif de traitement de données d’environnement de véhicule
WO2020260225A1 (fr) Dispositif lumineux de vehicule automobile integrant un système de detection
FR3118616A1 (fr) Procédé et dispositif d’alerte anticollision et/ou de freinage d’urgence
FR3081416A1 (fr) Procede de detection d’un defaut d’un capteur equipant un vehicule automobile partiellement ou entierement autonome.
FR3047217B1 (fr) Dispositif de determination de l'etat d'un feu de signalisation, systeme embatque comprenant un tel dispositif, vehicule comprenant un tel systeme et procede de determination associe
FR2879000A1 (fr) Procede de communication d'informations routieres a destination de vehicules automobiles
FR3098670A1 (fr) Dispositif d’attribution d’un identifiant de présence à un véhicule
US20230017962A1 (en) Denial of service response to the detection of illicit signals on the in-vehicle communication network
FR3111108A1 (fr) Procédé d'analyse d'environnement routier mis en œuvre par un véhicule
FR3073483A1 (fr) Dispositif electronique pour vehicule, systemes embarques et systeme informatique associes
FR3107875A1 (fr) Procédé et dispositif de contrôle d’activation de clignotants de véhicule
FR3094939A1 (fr) Assistance à la conduite d’un véhicule par détermination de glace, verglas ou neige sur sa portion de route
FR3115914A1 (fr) Module d’assistance à la conduite pour véhicule automobile
FR3102966A1 (fr) Procédé de suivi d’un véhicule autonome
FR3119041A1 (fr) Procédé et dispositif d’alerte à l’approche d’un élément ralentisseur

Legal Events

Date Code Title Description
PLSC Publication of the preliminary search report

Effective date: 20181221

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

PLFP Fee payment

Year of fee payment: 7