EP4476705A1 - Procédé d'élaboration d'un horizon artificiel - Google Patents

Procédé d'élaboration d'un horizon artificiel

Info

Publication number
EP4476705A1
EP4476705A1 EP23701158.0A EP23701158A EP4476705A1 EP 4476705 A1 EP4476705 A1 EP 4476705A1 EP 23701158 A EP23701158 A EP 23701158A EP 4476705 A1 EP4476705 A1 EP 4476705A1
Authority
EP
European Patent Office
Prior art keywords
event
vehicle
field
events
motor vehicle
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.)
Pending
Application number
EP23701158.0A
Other languages
German (de)
English (en)
Inventor
Cedric BONDIER
Stefania Sesia
Nicolas SUET
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.)
Ampere SAS
Original Assignee
Ampere 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 Ampere SAS filed Critical Ampere SAS
Publication of EP4476705A1 publication Critical patent/EP4476705A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/161—Decentralised systems, e.g. inter-vehicle communication
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3679—Retrieval, searching and output of POI information, e.g. hotels, restaurants, shops, filling stations, parking facilities
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0137—Measuring and analyzing of parameters relative to traffic conditions for specific applications
    • G08G1/0141—Measuring and analyzing of parameters relative to traffic conditions for specific applications for traffic information dissemination
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/052—Detecting movement of traffic to be counted or controlled with provision for determining speed or overspeed
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/165—Anti-collision systems for passive traffic, e.g. including static obstacles, trees
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/166—Anti-collision systems for active traffic, e.g. moving vehicles, pedestrians, bikes

Definitions

  • the present invention generally relates to interfacing systems allowing motor vehicles to apprehend their external environments. It concerns here the generation of artificial horizons, i.e. the processing of data allowing the vehicle to build a map of its environment.
  • the invention thus relates more specifically to a method for producing an artificial horizon for a motor vehicle, comprising the steps of:
  • each of the long messages comprising several fields, including at least a first field relating to a type of attribute characterizing the event and a second field indicating the value of this attribute.
  • the invention also relates to a motor vehicle comprising software clients (among which a man-machine interface and/or a navigation system and/or driving assistance systems) and a main interface which is programmed to implement a method of elaboration as mentioned above, in order to provide each client with at least part of the artificial horizon produced.
  • the following on-board systems are known: the navigation system which helps the driver to follow a route to get from a starting point to a finishing point, the driving aid system called " ADAS” (English acronym for “Advanced Driver Assistance System”), or the Man-Machine Interface (HMI) which displays or emits alerts while driving.
  • ADAS Advanced Driver Assistance System
  • HMI Man-Machine Interface
  • the vehicle can also be equipped with V2X technology thanks to which it receives messages from transmitters located at a distance from it, for example from other vehicles ( so-called V2V technology), road infrastructures (so-called V2I technology), the network (so-called V2N technology) or even other road users such as pedestrians (so-called V2P technology).
  • V2V technology so-called V2V technology
  • V2I technology road infrastructures
  • V2N technology the network
  • V2P technology even other road users such as pedestrians
  • the messages received from these transmitters contain various information such as: the absolute position (in GPS coordinates) of the transmitter, the reliability of this position, the speed of movement of the transmitter, the acceleration of the transmitter and/or its direction of movement, or even the dangers that the transmitter has encountered or created during its movement (slippery road, dangerous bend, accident, traffic congestion, etc.).
  • ADASIS Advanced Driver Assistance Systems Interface Specification
  • V2 Vehicle to Vehicle
  • This protocol and in particular its V2 version, is designed to describe the geometry of the road in front of the vehicle and to characterize its environment by a high but limited number of parameters.
  • This protocol is then said to allow the creation of an artificial horizon.
  • the environment is described not by sections of road, but rather by routes that the motor vehicle can take. It is thus defined a main route on which the vehicle is located, and secondary routes that originate on the main route or on other secondary routes.
  • This protocol is then designed so that the artificial horizon provider (which operates according to this protocol) can send six types of messages to the on-board systems (called “clients”).
  • This protocol makes it possible to provide customers with data on the environment which are precise and easily exploitable, and the number of which varies from one customer to another.
  • clients e.g. cruise control system
  • Other customers need more data, in particular data relating to events present on the secondary routes (to check, for example, whether a priority vehicle is arriving on one of these secondary routes).
  • this protocol is designed to only transmit data relating to permanent events (panels, crossings, etc.), so that it provides limited information.
  • the present invention proposes to supplement the aforementioned ADASIS protocol (version 2) to add an additional dynamic layer in order to transmit information relating to temporary "events" ( objects or circumstantial situations) that are relevant for customers, distinguishing events according to their nature.
  • a method for producing an artificial horizon as defined in the introduction in which the first field of a long message can take at least two distinct values respectively associated with a corresponding number of predefined categories of temporary events (i.e. transient, non-permanent), said categories being distinguished according to the speed of the temporary event and/or the position of the temporary event relatively to the motor vehicle.
  • predefined categories of temporary events i.e. transient, non-permanent
  • the invention proposes to take advantage of the long messages of the ADASIS protocol in order to transmit coded data in a particular way.
  • the first field relating to the type of attribute
  • the second field value of the attribute
  • the second field can then itself be coded to receive not simply a value, but a juxtaposition of data characterizing several aspects of the temporary event (its speed, its position on the traffic lanes, etc.).
  • one event category corresponds to dynamic events, one event category corresponds to static or pseudo-static events with respect to the motor vehicle, and one event category corresponds to traffic lights;
  • an event is considered to be dynamic when its speed is greater than a first threshold and/or when its distance from the motor vehicle is greater than a second threshold;
  • the first threshold and/or the second threshold is a function of the speed of the motor vehicle and/or of the speed of the event and/or of the environment;
  • the value of the first field may change; - at least one of the following events is considered to be dynamic: B an emergency vehicle in intervention,
  • B a vehicle at least one third slower than the maximum authorized speed, B a vehicle generating a risk of collision, B a vehicle violating the highway code, B a dangerous situation;
  • B an area where salvage and recovery work is in progress
  • B a stationary vehicle
  • each long message associated with a category of temporary event includes two fields allowing each event to be identified in two distinct ways;
  • the input data is at least partly derived from a decentralized event notification message and/or a cooperative warning message sent by a third party vehicle.
  • the invention also relates to a motor vehicle comprising software clients (among which a man-machine interface and/or a navigation system and/or driving assistance systems) and a main interface which is programmed to implement a method of elaboration as mentioned above, in order to provide each client with at least part of the artificial horizon produced.
  • this threshold is lower than the distance over which the customer receives information on the map
  • the input data provided to the motor vehicle by the surrounding vehicles are also provided to the customer via the long-size messages, without even detecting a possible dangerous situation;
  • a dynamic event is identified thanks to the route index field of the ADAS IS standard interface as well as thanks to the "ID" field,
  • the values of the ID field make it possible to follow dynamic events as long as they belong to the same road segment and make it possible to update its position without ending the event;
  • this attribute represents time with a precision of 10 ms covering 10 seconds
  • this specific attribute indicates on which lane the dynamic event is located (lane number, or emergency lane);
  • a static event is identified using the path index field of the ADAS IS standard interface as well as using the "ID" field;
  • - 7 bits are used to discriminate static events in the path index and a particular value is reserved to indicate that all values of the ID field are used.
  • a specific value is used to indicate that more than 127 objects are present in the specific index and that an overflow situation occurs;
  • the value 0 is used to indicate that the event has no length while the values from 1 to 62 are used to indicate the length of the static event;
  • - lengths from 0 to 100 meters are coded considering a step of 4 meters, while a step of 16 m is used for lengths between 100 and 500, a step of 128 m is used for lengths between 500 and 1908 m and the value 62 is used to indicate lengths greater than 1908 m;
  • the value 63 is used to invalidate or suppress the static event
  • channel start an attribute called channel start, described on 5 bits, indicates the first channel number for which the static event is valid
  • an attribute called end of channel indicates the last channel number for which the static event is valid
  • current phase another field called “current phase”, located on 3 bits, indicates the color of the current phase
  • next phase another field called “next phase”, also filled in on 3 bits, indicates the next color of the next phase
  • time of the next phase indicates the time at which the next phase will occur, preferably with a step of 100 ms;
  • the value 36001 is the value if the next phase is in more than 1 hour;
  • start of channel indicates the number of the first channel for which this phase is valid
  • end of channel indicates the number of the last channel for which this phase is valid
  • the lane number 0 is used for the off-road lanes, the number 1 for the hard shoulder, and the other numbers for the other lanes, starting the numbering at 2 for the far right lane.
  • FIG.l is a view of a motor vehicle and part of its environment.
  • FIG.l there is shown a motor vehicle 10 adapted to implement the invention.
  • this motor vehicle 10 conventionally comprises a passenger compartment in which includes a seat for the driver of the vehicle, a powertrain, a braking system and a steering system to turn the vehicle.
  • the steering system includes an electronically controllable power steering actuator
  • the powertrain includes an electronically controllable motor control actuator
  • the braking system includes an electronically controllable brake actuator.
  • This motor vehicle 10 is also equipped with at least one man-machine interface. In practice, it includes here a touch screen coupled to speakers.
  • the motor vehicle 10 also comprises an electronic processing unit which comprises several computers (microprocessors or microcontrollers), memories and input and output interfaces.
  • the electronic processing unit is suitable for receiving various input data, which come from sensors, third-party computers, or third-party entities (other vehicles, road equipment, pedestrians, network, etc.). These input data relate to the motor vehicle (speed, etc.) and to its environment (position on the road, map, etc.). V2X technology is particularly used in this respect.
  • these input data come, for example, from decentralized event notification messages (better known by the English acronym DENM for “Decentralized Event Notification Message”) and from common warning messages. (better known by the English acronym CAM for “Cooperative Awareness Message”) emitted by third-party vehicles located in the environment of the motor vehicle 10.
  • the electronic processing unit is suitable for controlling the man-machine interface in order to provide the driver with information. It is also suitable for controlling F power steering actuator, F engine control actuator, and F braking actuator so as to control the motor vehicle 10 autonomously or semi-autonomously.
  • the electronic processing unit memorizes a computer application, consisting of computer programs (or "software") comprising instructions whose execution by the computers allows the implementation of the method described above. -After.
  • ADAS software for aiding the driving of the vehicle (automatic regulation of the speed of the vehicle, keeping the vehicle in the center of its lane, etc.). He is also provided for HMI software ensuring the display of information on the touch screen and the emission of sound messages via the speakers and navigation software which memorizes a map of a region and which is able in particular to determine the position of the motor vehicle 10 in this map, to calculate the best route to follow to reach a particular destination, and to control the display of the position of the vehicle and of the route on the touch screen.
  • Each of these pieces of software forms a “client”. Each client needs to receive only part of the input data in order to be able to perform the function for which it was designed.
  • a main interface is then provided between the input interface which receives the input data and these clients.
  • This main interface also called artificial horizon provider, is then programmed to filter the input data so as to generate an artificial horizon representative of the environment of the motor vehicle 10, and to transmit this artificial horizon. on the vehicle network.
  • the vehicle network on which the customers are connected, is here of the CAN BUS type.
  • the main interface can send messages on this network at regular intervals, here every 100ms.
  • Each client is then able to retrieve all or part of the information contained in this artificial horizon from the network.
  • each client comprises a software component called a “reconstructor” which is able to read the information required for the client to perform its function.
  • the artificial horizon can be defined as a set of computer data making it possible to characterize part of the environment of the vehicle (in particular the events whose knowledge is useful for driving the motor vehicle 10).
  • the processing carried out by the main interface is divided into a generic pre-processing which filters the input data in a coarse manner and a post-processing which performs a more precise filtering, taking into account the topology of the streets where are the relevant "events" (vehicles, objects, circumstantial situations).
  • This filtering makes it possible to offer customers an artificial horizon which suits them, that is to say data which sufficiently describes the vehicle and its environment but which are sufficiently limited in number so that the computing power of the customers enough to process this data.
  • the main interface operates in accordance with the ADASIS protocol, in version 2.0 or later.
  • This protocol proposes to represent the artificial horizon by paths (see [Fig.1]).
  • main path 102 for example the one that follows the route taken initially
  • secondary paths 101, 103, 104, 105 which originate on the main path 102 or on other secondary paths .
  • each secondary path by an end (which indicates the position of its junction with the main or secondary path where it originates) and attributes (which characterize this path).
  • the ADASIS protocol proposes to consider only a limited number of journeys (here 56) located at the front of the vehicle. He also proposes to consider only a limited length of each trip, here about 8 km. These limitations ensure that the vehicle's computers are not overloaded. Thus, the artificial horizon has a limited range.
  • This protocol is then designed so that the main interface can send on the CAN BUS (to customers) six types of messages. These types of messages are:
  • Such a long message is sent on the CAN BUS when an event relevant to the driving of the vehicle 10 is detected on one of the routes, in a geographical area considered relevant.
  • Such a message includes several data defined by the following table. [0065] [Tables 1]
  • a long message is therefore coded in 64 bits.
  • the first 3 bits characterize the type of message, the following two are a cycle counter...
  • Each long message therefore comprises several parts.
  • the “field” column thus indicates what each part of the message corresponds to.
  • the “length” column indicates the number of bits each part takes in the message.
  • the “range of values” column indicates the values that each part of the message can take.
  • the “path index” field presents a value that makes it possible to identify the path where the event is located.
  • the "deviation" field presents a value which makes it possible to locate the event on the route.
  • the “type of profile” field makes it possible to characterize the event by a particular type. Thus, if its value is equal to 1, the event is a longitude, if it is equal to 2, it is a latitude, if it is equal to 3, it is an altitude , if it is 8, it is a traffic sign, if it is 9, it is a speed limit for heavy goods vehicles. It will be noted that in the ADASIS protocol, the values 11 to 15 are reserved for standard types, and that the values 16 to 31 are reserved for specific types.
  • the "value” field is used to store the data corresponding to the type of profile (the value of the longitude, the type of panel, the value of the speed limit).
  • the “type of profile” field indicates what the data stored in the “value” field applies to. It thus designates a type of attribute characterizing the event (latitude, longitude, sign, speed limit).
  • An “attribute” will be defined here as a characteristic of an event.
  • the invention proposes to use three of the values 16 to 31 reserved for specific types, in order to define three new types of attributes, namely the attributes of static or pseudo-static temporary events, the attributes dynamic temporary events and traffic light event attributes.
  • a static event is an immobile event.
  • a pseudo static event is an event that moves little, given its speed and/or its position relative to the vehicle.
  • a speed threshold for example 5 km/h
  • a distance threshold for example 1000 meters
  • each of these thresholds can be fixed or can be a function of the speed of the motor vehicle 10 and/or of the speed of the event and/or of the environment.
  • the thresholds may be larger or smaller depending on the type of urban, motorway or rural environment in which the vehicle is moving.
  • An example of a temporary static or pseudo-static event is a stationary vehicle on the route considered, or the end of a dangerous queue on this route.
  • a dynamic event is defined as opposed to the aforementioned events. It is for example an emergency vehicle in intervention.
  • a traffic light event attribute makes it possible to provide, for example, the current phase of the traffic light (typically its color) and the time remaining before this phase changes.
  • the dynamic temporary events are associated with the value 28.
  • the 32-bit “value” field is thus encoded in several parts of 2 to 10 bits, which are defined in the following table. [0086] [Tables?]
  • the “compressed dynamic event” field will be detailed below. It allows to categorize the dynamic event.
  • the "ID" field is used to identify the dynamic temporary event by a number between 0 and 62.
  • the number 63 is reserved in case all the other numbers are taken. The main interface releases this number 63 as soon as this is no longer the case.
  • a dynamic event such as a rolling intervention vehicle could be coded in the artificial horizon by successively sending updated long messages.
  • the rebuilder of each customer will be able to understand that these messages are associated with the same vehicle in intervention, whose speed and position are changing, without it being necessary to send him cancellation messages for this purpose. previous messages.
  • the “age” field corresponds to the time that has passed since the event was created, 10 ms close. It covers a duration of 10s. To fully understand what this field refers to,
  • the "channel” field indicates the channel to which the event applies. This field applies to the vehicle's traffic lanes (those that the vehicle can take given the direction in which it is traveling). Thus, the events located outside these lanes are associated with the value 0, the events located in the emergency lane are associated with the value 1, and the events located on the traffic lanes are associated with values between 2 and 14 (2 corresponding to the leftmost lane, 3 to the lane immediately next to it).
  • the "direction" field indicates the direction in which the event is flowing. It takes the value 0 if the event is traveling in the same direction as vehicle 10 and the value 1 otherwise.
  • the "value” field is used to code the speed of the event. This is an approximate value.
  • Each value corresponds to a speed interval, as defined in the ADASIS v2.0.4 protocol, in table 12. By way of example, the following values may correspond:
  • this “value” field can take the value 31 in a very particular case.
  • the message means that the message sent previously about this same event (identified by the ID field) must be deleted.
  • the "compressed dynamic event” field indicates the type of dynamic event to which the message refers.
  • ETSI which is the organization in charge of standards relating to V2X technology, has already created a table listing the different types of events. This table distinguishes between major categories (causes) and subcategories. categories (sub-causes).
  • This table corresponds to the first four fields of the following table.
  • each cause is defined by a first code (second column) and each sub-cause is defined by a second code (fourth column).
  • This classification provides for leaving many cause codes free (thus going directly from 3 to 12), so that storing the cause values requires a large number of bits (in this case, 7 would be needed) .
  • the 32-bit “value” field is thus encoded in several parts of 2 to 7 bits, which are defined in the following table.
  • compressed event and “sub-cause” fields will be detailed below. They allow to categorize the static or pseudo-static event.
  • the "ID" field is used to identify the event by a number between 0 and 126.
  • the number 127 is reserved in case all the other numbers are taken.
  • the main interface is programmed to release this number as soon as it is no longer the case and to select the nearest events before those which are furthest away when the all the numbers are taken.
  • the "value” field is used to code the length L of the event. It takes the value 0 if the length is not known. Otherwise, it takes a value between 1 and 62. Its value then depends on the length of the event. Its value is coded here as follows:
  • this “value” field can take the value 63 in a very specific case.
  • the value 63 will indicate that the message relates to a static event that must be deleted, thus freeing the identifier from the "ID" field used.
  • the "departure channel” field indicates the first channel to which the event applies. This field is coded in the same way as the aforementioned “channel” field.
  • the “arrival route” field indicates the last route on which the event applies. This field is coded in the same way as the "departure track” field.
  • the “confidence” field indicates the level of confidence in the detection of the event, the value 0 indicating a minimum level of confidence and 3 indicating a maximum level of confidence.
  • the “compressed event” field is coded on 5 bits.
  • ETSI has already created a table listing the different types of static events that a vehicle can encounter. This table distinguishes major categories (the causes) and subcategories (the sub-causes).
  • the "sub-cause” field takes the numbers assigned by ETSI without modifying them, while the "compressed event” field takes numbers different from those assigned by ETSI.
  • Traffic light events are associated with the value 30.
  • the “type of profile” field is equal to 30, this means that the “value” field will comprise a juxtaposition of data characterizing the state of a traffic light.
  • the 32-bit “value” field is thus encoded in several parts of 2 to 16 bits, which are defined in the following table.
  • the “Traffic light direction” field indicates which traffic lane the event is associated with. It takes the value 0 if it is associated with the initial direction (straight), the value 1 to turn left, the value 2 to turn right and the value 3 for all directions.
  • the “current phase” field indicates the current phase of the traffic light. It takes the value 1 if it is green, 2 if it is red, 3 if it is orange, 4 if it is between orange and red, 5 if it is flashing red, 6 s' it flashes orange and 7 if it is dark.
  • the “next phase” field indicates the next phase of the traffic light. Its value is defined in the same way as for the current phase field.
  • the “time before next phase” field indicates, as a function of UTC universal time, the time at which the next phase will occur.
  • the "departure channel” field indicates the first channel to which the event applies. This field is coded in the same way as the aforementioned “channel” field.
  • the "arrival route” field indicates the last route on which the event applies. This field is coded in the same way as the "departure track” field.
  • the “time before next phase” field could more precisely be coded as follows.
  • this field takes the value 36001 in the case where the next phase is in more than one hour (and the value 65535 in the event of cancellation of the traffic lights). Otherwise, it takes a value between 0 and 36000. Note that the values 36002 to 65534 will not be used.
  • the messages are sent over the CAN BUS network, which allows the customer to acquire a relevant part of the artificial horizon and to correctly perform the function for which it was designed. .
  • the navigation system will be able to select a route which best avoids traffic jams
  • the ADAS driving assistance system will be able to regulate the speed of the vehicle so as to take into account the phases of traffic lights and patches of ice
  • the Human-Machine Interface HMI can display alerts on the dashboard to draw the driver's attention to dangers.
  • filtering can be carried out in order to send only long messages related to events located near the vehicle, for example within a range of less than 2 km from the latter.
  • this filtering may consist of sending the long messages corresponding to static events only on condition that the event is located at a distance from the vehicle 10 below a first threshold, which first threshold is below the range over which the client receives information relating to the map.
  • It may also consist of sending the long messages corresponding to dynamic events only on condition that the event is located at a distance from the vehicle 10 less than a second threshold, which second threshold is less than the first threshold.
  • This filtering may also consist in transmitting only long messages associated with events which are located either on the main path 102, or on secondary paths but less than 200 m from their junction with the main path 102 .
  • a traffic light event could not be used. Conversely, we could plan to distinguish a greater number of categories temporary events (near statics, distant statics, close dynamics, distant dynamics, etc.).

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Chemical & Material Sciences (AREA)
  • Analytical Chemistry (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Automation & Control Theory (AREA)
  • Traffic Control Systems (AREA)
  • Navigation (AREA)

Abstract

L'invention concerne un procédé d'élaboration d'un horizon artificiel pour un véhicule automobile, comprenant des étapes de : - réception de données d'entrée relatives au véhicule automobile et à son environnement, - détermination de différents trajets, et - génération de messages caractérisant ledit horizon artificiel, dont des messages longs de caractérisation d'évènements, chaque message long comportant plusieurs champs, dont au moins un premier champ relatif à un type d'attribut caractérisant l'évènement et un second champ indiquant la valeur de cet attribut. Selon l'invention, le premier champ peut prendre au moins deux valeurs distinctes associées à un nombre correspondant de catégories d'évènements temporaires, lesdits catégories étant dissociées en fonction de leurs vitesses et/ou de leurs positions relatives au véhicule automobile.

Description

Description
Titre de l'invention : Procédé d’élaboration d’un horizon artificiel Domaine technique de l'invention
[0001] La présente invention concerne de manière générale les systèmes d’interfaçage permettant aux véhicules automobiles d’appréhender leurs environnements extérieurs. Elle concerne ici la génération d’horizons artificiels, c’est-à-dire le traitement de données permettant au véhicule de construire une carte de son environnement.
[0002] L’invention porte ainsi plus spécifiquement sur un procédé d’élaboration d’un horizon artificiel pour un véhicule automobile, comprenant des étapes de :
- réception de données d’entrée relatives au véhicule automobile et à son envi- ronnement,
- détermination de différents trajets empruntables par le véhicule automobile, et
- génération de messages caractérisant ledit horizon artificiel.
[0003] Ici, plusieurs types de messages peuvent être élaborés, dont :
- des messages de positionnement du véhicule automobile,
- des messages de positionnement de chaque trajet,
- des messages de caractérisation de chaque trajet,
- des messages courts et longs de caractérisation d’évènements se trouvant sur chaque trajet, chacun des messages longs comportant plusieurs champs, dont au moins un premier champ relatif à un type d’attribut caractérisant l’évènement et un second champ indiquant la valeur de cet attribut.
[0004] L’invention concerne aussi un véhicule automobile comprenant des clients logiciels (parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite) et une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration tel que précité, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.
Etat de la technique
[0005] De nombreux véhicules sont aujourd’hui équipés de systèmes d’assistance à la conduite embarqués, qui permettent d’assister le conducteur lors de sa conduite, que ce soit lors de situations de conduite dangereuse ou simplement pour améliorer le confort de conduite.
[0006] On connaît par exemple les systèmes embarqués suivants : le système de navigation qui aide le conducteur à suivre un itinéraire pour se rendre d’un point de départ à un point d’arrivée, le système d’aide à la conduite dit « ADAS » (acronyme anglais pour « Advanced Driver Assistance Système »), ou encore l’interface Homme-Machine (IHM) qui affiche ou émet des alertes lors de la conduite. [0007] Pour fonctionner efficacement, les systèmes embarqués doivent sonder et analyser l’environnement plus ou moins lointain du véhicule. A cet effet, le véhicule est équipé de capteurs physiques qui récoltent des informations sur ce qui entoure le véhicule.
[0008] Pour améliorer encore la connaissance de son environnement, le véhicule peut aussi être équipé de la technologie V2X grâce à laquelle il reçoit des messages en provenance d’émetteurs situés à distance de lui, par exemple de la part d’autres véhicules (technologie dite V2V), d’infrastructures routières (technologie dite V2I), du réseau (technologie dite V2N) ou encore d’autres usagers de la route tels que les piétons (technologie dite V2P).
[0009] Les messages reçus de la part de ces émetteurs contiennent des informations diverses telles que : la position absolue (en coordonnées GPS) de l’émetteur, la fiabilité de cette position, la vitesse de déplacement de l’émetteur, l’accélération de l’émetteur et/ou sa direction de déplacement, ou encore les dangers que l’émetteur a rencontrés ou créés lors de son déplacement (route glissante, virage dangereux, accident, encombrement du trafic...).
[0010] On estime ainsi qu’avec le déploiement de la technologie V2X dans de plus en plus de véhicules et le développement de la 5G, la quantité d’informations qui viendra à être reçue par seconde dans un véhicule sera telle qu’il deviendra nécessaire de sé- lectionner les plus utiles, au risque, sinon, de ralentir le fonctionnement des systèmes embarqués dans le véhicule voire de les saturer.
[0011] Dans ce cadre, plusieurs constructeurs de véhicules se sont associés pour créer un protocole nommé ADASIS (de l’anglais « Advanced Driver Assistance Systems Interface Specification »). Ce protocole, et notamment sa version V2, est conçu pour décrire la géométrie de la route à l’avant du véhicule et caractériser son environnement par un nombre élevé mais limité de paramètres. On dit alors de ce protocole qu’il permet de créer un horizon artificiel. Selon ce protocole, l’environnement est décrit non pas par portions de route, mais plutôt par trajets empruntables par le véhicule au- tomobile. Il est ainsi défini un trajet principal sur lequel se trouve le véhicule, et des trajets secondaires qui prennent naissance sur le trajet principal ou sur d’autres trajets secondaires.
[0012] Ce protocole est alors conçu de manière à ce que le fournisseur d’horizon artificiel (qui fonctionne selon ce protocole) puisse envoyer aux systèmes embarqués (appelés « clients ») six types de messages.
[0013] Ces types de messages sont les suivants :
- des messages de position relatifs à la position du véhicule,
- des messages de bout (en anglais « Stub ») relatifs à la position du point où le trajet concerné prend naissance,
- des messages de segment caractérisant les attributs principaux d’une partie par- ticulière du trajet concerné,
- des messages de profil courts caractérisant les évènements situés sur chaque trajet qui peuvent être exprimés en 10 bits,
- des messages de profil longs caractérisant les évènements situés sur chaque trajet qui peuvent être exprimés en 32 bits,
- des messages de métadonnées.
[0014] Ce protocole permet de fournir aux clients des données sur l’environnement qui sont précises et facilement exploitables, et dont le nombre varie d’un client à l’autre. Ty- piquement, la plupart des clients (par exemple le système de régulation automatique de vitesse) n’a besoin de données relatives qu’au trajet principal. D’autres clients ont en revanche besoin de davantage de données, en particulier des données relatives aux évènements présents sur les trajets secondaire (pour vérifier par exemple si un véhicule prioritaire arrive sur l’un de ces trajets secondaires).
[0015] Mais même avec ce protocole, le nombre de données à traiter par les calculateurs du véhicule reste très important, si bien que le problème de ralentissement ou de sa- turation demeure.
[0016] En outre, ce protocole est conçu pour ne transmettre que des données relatives à des évènements permanents (panneau, croisement.. .), si bien qu’il fournit des informations limitées.
Présentation de l'invention
[0017] Afin de remédier aux inconvénients précités de l’état de la technique, la présente invention propose de compléter le protocole ADASIS (version 2) précité pour ajouter une couche dynamique supplémentaire afin de transmettre des informations relatives à des « évènements » temporaires (objets ou situations circonstancielles) qui sont per- tinentes pour les clients, en distinguant les évènements selon leur nature.
[0018] Plus particulièrement, on propose selon l’invention un procédé d’élaboration d’un horizon artificiel tel que défini dans l’introduction, dans lequel le premier champ d’un message long peut prendre au moins deux valeurs distinctes respectivement associées à un nombre correspondant de catégories prédéfinies d’évènements temporaires (c’est-à-dire passagers, non permanents), lesdites catégories étant distinguées en fonction de la vitesse de l’évènement temporaire et/ou de la position de l’évènement temporaire relativement au véhicule automobile.
[0019] Ainsi, l’invention propose de tirer parti des messages longs du protocole ADASIS afin de transmettre des données codées de manière particulière. En particulier, le premier champ (relatif au type d’attribut) peut prendre une première valeur pour indiquer que le second champ (valeur de l’attribut) comportera des données relatives à des évènements temporaires dynamiques, ou une seconde valeur pour indiquer que le champ comportera des données relatives à des évènements temporaires statiques ou pseudo-statiques (c’est-à-dire considérés comme statiques bien qu’ils ne le soient pas exactement). Le second champ pourra alors lui-même être codé pour recevoir non pas simplement une valeur, mais une juxtaposition de données caractérisant plusieurs aspects de l’évènement temporaire (sa vitesse, sa position sur les voies de cir- culation...).
[0020] De cette façon, il est possible de fournir de manière efficace aux clients les seules in- formations qui leurs sont utiles, en exploitant les données qui décrivent les in- formations cartographiques et en ajoutant des attributs pour indiquer la présence d'objets particuliers.
[0021] L’intérêt de distinguer les évènements dynamiques des évènements statiques est que pour caractériser ces deux types d’évènements, on n’emploie pas les mêmes attributs. Par conséquent, seuls les attributs pertinents seront codés dans chaque message, puisque chaque message sera associé à une catégorie seulement d’évènements.
[0022] On notera par ailleurs que la façon employée pour caractériser ces évènements sera telle qu’il ne sera pas nécessaire (contrairement à ce qui est fait en général selon le protocole ADASIS) d’envoyer un message de terminaison lorsqu’un évènement sera mis à jour (par exemple sa position). A titre d’exemple, en utilisant l’identifiant de l’évènement, on pourra directement transmettre la version mise à jour de l’évènement, sans avoir besoin d’effacer la version précédente. Ceci permettra de réduire le nombre de messages envoyés.
[0023] Comme cela sera bien expliqué dans la suite de cet exposé, cette implémentation évitera en outre de transmettre plusieurs fois le même genre d’information, afin de ne pas surcharger les calculateurs.
[0024] D’autres caractéristiques avantageuses et non limitatives du procédé d’élaboration conforme à l’invention, prises individuellement ou selon toutes les combinaisons tech- niquement possibles, sont les suivantes :
- une catégorie d’événements correspond à des évènements dynamiques, une catégorie d’événements correspond à des évènements statiques ou pseudo-statiques vis-à-vis du véhicule automobile, et une catégorie d’évènement correspond à des feux de circulation ;
- un évènement est considéré comme dynamique lorsque sa vitesse est supérieure à un premier seuil et/ou lorsque sa distance au véhicule automobile est supérieure à un second seuil ;
- le premier seuil et/ou le second seuil est une fonction de la vitesse du véhicule au- tomobile et/ou de la vitesse de l'événement et/ou de l'environnement ;
- lorsque la vitesse et/ou la distance au véhicule automobile d’un évènement varie dans le temps, la valeur du premier champ peut changer ; - l’un au moins de évènements suivants est considéré comme dynamique : B un véhicule d'urgence en intervention,
B un véhicule dont un système de freinage d'urgence est activé,
B un véhicule dont un système de retenue réversible des occupants est activé,
B une personne ou un animal sur le trajet,
» des travaux routiers mobiles sur le trajet,
» un véhicule roulant à contresens,
B des travaux mobiles de sauvetage et de récupération en cours,
B un véhicule au moins un tiers plus lent que la vitesse maximum autorisée, B un véhicule générant un risque de collision, B un véhicule violant le code de la route, B une situation dangereuse ;
- l’un au moins de évènements suivants est considéré comme statique : B un accident,
B des travaux routiers,
B une portion de trajet impraticable,
B des conditions météorologiques défavorables,
B une zone d’ aquaplaning,
B une zone dangereuse,
B une zone de travaux de sauvetage et de récupération en cours, B un véhicule à l’arrêt,
B une fin de file d’embouteillage dangereuse ;
- chaque message long associé à une catégorie d’évènement temporaire comporte deux champs permettant d’identifier de deux façons distinctes chaque évènement ;
- les données d’entrée sont au moins en partie issues d’un message de notification d’évènement décentralisé et/ou d’un message d’avertissement coopératif émis par un véhicule tiers.
[0025] L’invention concerne aussi un véhicule automobile comprenant des clients logiciels (parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite) et une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration tel que précité, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.
[0026] D’autres caractéristiques préférentielles du procédé d’élaboration conforme à l’invention sont les suivantes :
- seuls les évènements qui sont situés sur un trajet principal (également appelé trajet le plus probable au sens du protocole ADASIS), à une distance du véhicule inférieure à un seuil, sont considérés dans les messages émis vers les clients (ce qui permettra de réduire la quantité d’informations envoyées, et donc la bande passante nécessaire à cet envoi) ;
- ce seuil est inférieur à la distance sur laquelle le client reçoit des informations sur la cartographie ;
- les données d’entrée fournies au véhicule automobile par les véhicules environnants sont également fournies au client via les messages de taille longue, sans même que ne soit détecté une éventuelle situation dangereuse ;
Evènements dynamiques :
- un événement dynamique est identifié grâce au champ d'index de trajet de l'interface standard ADAS IS ainsi que grâce au champ « ID »,
- 6 bits sont utilisés afin de discriminer les événements dynamiques dans l'index de trajet et une valeur particulière est utilisée pour indiquer que toutes les valeurs possibles du champ ID sont utilisées ;
- les valeurs du champ ID sont sélectionnées dans un ordre croissant ;
- les valeurs du champ ID permettent de suivre les événements dynamiques tant qu'ils appartiennent à un même segment de route et permettent de mettre à jour sa position sans mettre fin à l'événement ;
- il est prévu d’envoyer un message spécifique lorsque l'événement dynamique n'appartient plus à l'index de trajet initialement identifié, libérant ainsi la valeur du champ ID correspondante ;
- une valeur spécifique est utilisée afin d'indiquer que plus de 63 objets sont présents dans l'index de trajet ;
- dans un tel cas dit de débordement, lorsqu'un nouvel événement dynamique doit être livré au client, la décision sur quel événement prioriser est prise en fonction de la distance entre l’évènement et le véhicule ;
- ainsi, si le nouvel évènement est plus éloigné du véhicule que l'ensemble des évènements déjà transmis, alors le nouvel évènement est rejeté, sinon l’évènement le plus éloigné est rejeté et le nouvel évènement est utilisé en utilisant la valeur du champ ID ainsi libéré ;
- des attributs spécifiques qui décrivent la cause et la sous-cause de l'événement dynamique sont décrits sur 7 bits ;
- un attribut spécifique qui représente l'âge de l'événement dynamique est décrit sur 10 bits ;
- cet attribut représente le temps avec une précision de 10 ms couvrant 10 secondes ;
- un attribut spécifique qui représente la voie est décrit sur 4 bits ;
- cet attribut spécifique indique sur quelle voie l'événement dynamique est situé (numéro de voie, ou bande d'arrêt d'urgence) ;
- un attribut spécifique qui représente la direction est décrit sur 2 bits ;
- cet attribut indique si l'événement dynamique avance ou recule ; - un attribut spécifique qui est appelé « valeur » représente la vitesse de l'événement dynamique, il est décrit sur 5 bits ;
- un attribut qui indique la cause et la sous-cause est décrit en 9 bits, dont 5 bits pour la cause ;
Evènements statiques (ou pseudo-statiques) :
- un événement statique est identifié grâce au champ d'index de trajet de l'interface standard ADAS IS ainsi que grâce au champ « ID » ;
- 7 bits sont utilisés afin de discriminer les événements statiques dans l'index de trajet et une valeur particulière est réservée pour indiquer que toutes les valeurs du champ ID sont utilisées.
- les valeur du champ ID sont sélectionnés dans un ordre croissant ;
- ces valeurs permettent de suivre les événements statiques tant qu'ils appartiennent au même segment de trajet et permettent de mettre à jour leurs positions sans mettre fin à l'événement ;
- il est prévu de supprimer un message spécifique lorsque l'événement statique n'appartient plus à l'index de trajet initialement identifié, libérant ainsi la valeur du champ ID correspondante ;
- une valeur spécifique est utilisée afin d'indiquer que plus de 127 objets sont présents dans l'index spécifique et qu'une situation de débordement se produit ;
- le cas de débordement est traité de la même façon que pour les évènements dy- namiques ;
- un attribut appelé « valeur » est utilisé pour indiquer la durée de l'événement statique
- la valeur 0 est utilisée pour indiquer que l'événement n'a pas de longueur tandis que les valeurs de 1 à 62 sont utilisées pour indiquer la longueur de l'événement statique ;
- la longueur n'est pas codée uniformément et la précision est dégradée pour des longueurs croissantes ;
- les longueurs de 0 à 100 mètres sont codées en considérant un pas de 4 mètres, tandis qu'un pas de 16 m est utilisé pour les longueurs comprises entre 100 et 500, un pas de 128 m est utilisé pour les longueurs comprises entre 500 et 1908 m et la valeur 62 est utilisée pour indiquer les longueurs supérieures à 1908 m ;
- la valeur 63 est utilisée pour invalider ou supprimer l'événement statique ;
- un attribut appelé début de voie, décrit sur 5 bits, indique le premier numéro de voie pour lequel l'événement statique est valable ;
- les événements statique hors route sont associés à un début de voie égal à 0 tandis que la bande d'arrêt d'urgence est associée à une voie numéro 1 et les voies sont comptées à partir de la voie 2 jusqu'à la voie 31 ;
- un attribut appelé fin de voie, décrit sur 5 bits, indique le dernier numéro de voie pour lequel l'événement statique est valable ;
Evénements feux de circulation :
- les événements feux de circulation sont associés aux changements de phases des feux;
- un champ du message lié à un tel évènement est appelé « manœuvre de circulation », cartographié sur 2 bits, il indique si la phase renseignée est valable pour aller tout droit, tourner à gauche ou à droite ;
- un autre champ appelé « phase courante », localisé sur 3 bits, indique la couleur de la phase courante ;
- un autre champ appelé « phase suivante », renseigné sur 3 bits également, indique la prochaine couleur de la phase suivante ;
- encore un autre champ appelé « heure de la phase suivante », utilisant 16 bits, indique l'heure à laquelle la phase suivante se produira, de préférence avec un pas de 100 ms ;
- dans ce champ, la plage de valeurs va de 0 à 36000 ;
- la valeur 36001 est la valeur si la phase suivante est dans plus de 1 heure ;
- la valeur 65535 est utilisée en cas d’extinction des feux de circulation ;
- un autre champ appelé « début de voie », utilisant 4 bits, indique le numéro de la première voie pour laquelle cette phase est valable ;
- un autre champ appelé « fin de voie », utilisant 4 bits, indique le numéro de la dernière voie pour laquelle cette phase est valable ;
- dans ces deux derniers champs, le numéro de voie 0 est utilisé pour les voies hors route, le numéro 1 pour la bande d'arrêt d'urgence, et les autres numéros pour les autres voies, en commençant la numérotation à 2 pour la voie la plus à droite.
[0027] Bien entendu, les différentes caractéristiques, variantes et formes de réalisation de l'invention peuvent être associées les unes avec les autres selon diverses combinaisons dans la mesure où elles ne sont pas incompatibles ou exclusives les unes des autres.
Description détaillée de l'invention
[0028] 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.
[0029] Sur l’unique dessin annexé :
[0030] [Fig.l] est une vue d’un véhicule automobile et d’une partie de son environnement.
[0031] Sur la [Fig.l], on a représenté un véhicule automobile 10 adapté à mettre en œuvre l’invention.
[0032] Il s’agit ici d’une voiture. En variante, il pourrait s’agir d’un autre type de véhicule (camion, moto, bus.. .).
[0033] Ici, ce véhicule automobile 10 comporte classiquement un habitacle dans lequel se trouve notamment un siège pour le conducteur du véhicule, un groupe motopropulseur, un système de freinage et un système de direction permettant de faire tourner le véhicule. Classiquement, le système de direction comporte un actionneur de direction assistée pilotable électroniquement, le groupe motopropulseur comporte un actionneur de commande de moteur pilotable électroniquement, et le système de freinage comporte un actionneur de freinage pilotable électroniquement.
[0034] Ce véhicule automobile 10 est en outre équipé d’au moins une interface homme- machine. En pratique, il comporte ici un écran tactile couplé à des enceintes.
[0035] Il est également équipé, ici, d’un système de retenue réversible des occupants, ty- piquement d’un système de blocage commandé de la ceinture de sécurité.
[0036] Le véhicule automobile 10 comporte par ailleurs une unité électronique de traitement qui comporte plusieurs calculateurs (microprocesseurs ou microcontrôleurs), des mémoires et des interfaces d'entrée et de sortie.
[0037] Grâce à ses interfaces d'entrée, l’unité électronique de traitement est adaptée à recevoir différentes données d’entrée, qui proviennent de capteurs, de calculateurs tiers, ou d’entités tierces (autres véhicules, équipements routiers, téléphones de piétons, réseau...). Ces données d’entrée sont relatives au véhicule automobile (vitesse...) et à son environnement (position sur la route, cartographie...). La technologie V2X est en particulier employée à cet égard.
[0038] On notera que ces données d’entrée sont par exemple issues de messages de noti- fication d’évènement décentralisé (plus connus sous l’acronyme anglais DENM pour « Decentralised Event Notification Message ») et de messages d’avertissement co- opératif (plus connus sous l’acronyme anglais CAM pour « Cooperative Awareness Message ») émis par des véhicules tiers situés dans l’environnement du véhicule au- tomobile 10.
[0039] Grâce à ses interfaces de sortie, l’unité électronique de traitement est adaptée à commander l’interface homme-machine afin de fournir au conducteur des in- formations. Elle est également adaptée à commander F actionneur de direction assistée, F actionneur de commande de moteur, et F actionneur de freinage de façon à piloter le véhicule automobile 10 de façon autonome ou semi-autonome.
[0040] Grâce à ses mémoires, l’unité électronique de traitement mémorise une application informatique, constituée de programmes d’ordinateur (ou « logiciels ») comprenant des instructions dont l’exécution par les calculateurs permet la mise en œuvre du procédé décrit ci-après.
[0041] Dans la suite de cet exposé, on considérera que chaque « logiciel » permet de mettre en œuvre une « fonction » particulière.
[0042] Il est ainsi prévu des logiciels ADAS d’aide à la conduite du véhicule (régulation au- tomatique de la vitesse du véhicule, maintien du véhicule au centre de sa voie...). Il est aussi prévu de logiciels IHM assurant l’affichage d’informations sur l’écran tactile et l’émission de messages sonores via les enceintes et un logiciel de navigation qui mémorise une cartographie d’une région et qui est en mesure notamment de déterminer la position du véhicule automobile 10 dans cette cartographie, de calculer le meilleur trajet à suivre pour atteindre une destination particulière, et de commander l’affichage de la position du véhicule et du trajet sur l’écran tactile.
[0043] Chacun de ces logiciels forme un « client ». Chaque client nécessite de recevoir une partie seulement des données d’entrée afin d’être en mesure d’exécuter la fonction pour laquelle il a été conçu.
[0044] Il est alors prévu une interface principale entre l’interface d’entrée qui reçoit les données d’entrée et ces clients.
[0045] Cette interface principale, également appelée fournisseur d’horizon artificiel, est alors programmée pour filtrer les données d’entrée de manière à générer un horizon ar- tificiel représentatif de l’environnement du véhicule automobile 10, et pour émettre cet horizon artificiel sur le réseau du véhicule.
[0046] Le réseau du véhicule, sur lequel sont branchés les clients, est ici de type BUS CAN. Ainsi, l’interface principale peut émettre sur ce réseau des messages à intervalles réguliers, ici tous les 100ms.
[0047] Chaque client est alors en mesure de récupérer sur le réseau tout ou partie des in- formations contenues dans cet horizon artificiel.
[0048] Chaque client comporte pour cela un composant-logiciel appelé « reconstructeur » qui est en mesure de lire les informations requises pour que le client puisse assurer sa fonction.
[0049] On notera que l’horizon artificiel pourra être défini comme un ensemble de données informatiques permettant de caractériser une partie de l’environnement du véhicule (notamment les évènements dont la connaissance est utile pour piloter le véhicule au- tomobile 10).
[0050] Le traitement exécuté par l’interface principale se divise en un pré-traitement générique qui filtre les données d’entrée de manière grossière et un post- traitement qui réalise un filtrage plus précis, en tenant compte de la topologie des rues où se trouvent les « évènements » pertinents (véhicules, objets, situations circonstancielles).
[0051] Ce filtrage permet d’offrir aux clients un horizon artificiel qui leur convient, c’est-à-dire des données qui décrivent suffisamment le véhicule et son environnement mais qui sont en nombre suffisamment restreint pour que la puissance de calcul des clients suffise à traiter ces données.
[0052] Pour cela, l’interface principale fonctionne conformément au protocole ADASIS, dans une version 2.0 ou ultérieure.
[0053] Ce protocole propose de représenter l’horizon artificiel par trajets (voir [Fig.1]). [0054] Ainsi, compte tenu des différents embranchements de la route, l’interface principale est en mesure de déterminer tous les trajets que le véhicule est susceptible d’emprunter.
[0055] Il est prévu de distinguer un trajet principal 102 (par exemple celui qui suit la route empruntée initialement), et des trajets secondaires 101, 103, 104, 105 qui prennent naissance sur le trajet principal 102 ou sur d’autres trajets secondaires.
[0056] Il est en outre prévu de définir chaque trajet secondaire par un bout (qui indique la position de sa jonction avec le trajet principal ou secondaire où il prend naissance) et des attributs (qui caractérisent ce trajet).
[0057] Sur chaque trajet se trouvent des évènements dont les positions par rapport au bout sont définies par un écart.
[0058] Des évènements sont permanents (panneau, dos d’âne...), tandis que d’autres sont temporaires.
[0059] Parmi ces évènements temporaires, on peut distinguer les objet (véhicule...) et les si- tuations circonstancielles (position de fin d’embouteillage, alerte...).
[0060] Le protocole ADASIS propose de ne considérer qu’un nombre limité de trajets (ici 56) se trouvant à l’avant du véhicule. Il propose en outre de ne considérer qu’une longueur limitée de chaque trajet, ici d’environ 8 km. Ces limitations permettent ne pas surcharger les calculateurs du véhicule. Ainsi, l’horizon artificiel présente une portée limitée.
[0061] Ce protocole est alors conçu de manière à ce que l’interface principale puisse envoyer sur le BUS CAN (à destination des clients) six types de messages. Ces types de messages sont les suivants :
- des messages de position relatifs à la position du véhicule 10,
- des messages de bout relatifs à la position du début du trajet concerné,
- des messages de segment caractérisant les attributs principaux d’une partie du trajet,
- des messages courts caractérisant les évènements sur le trajet qui peuvent être exprimés en 10 bits,
- des messages longs caractérisant les évènements sur le trajet qui peuvent être exprimés en 32 bits,
- des messages de métadonnées.
[0062] Dans le cadre de la présente invention, on s’intéressera uniquement aux messages longs.
[0063] Un tel message long est envoyé sur le BUS CAN lorsqu’un évènement pertinent pour la conduite du véhicule 10 est détecté sur l’un des trajets, dans une zone géographique considérée comme pertinente.
[0064] Un tel message comprend plusieurs données définies par le tableau suivant. [0065] [Tableaux 1]
[0066] Un message long est donc codé en 64 bits. On comprend sur ce tableau que les 3 premiers bits caractérisent le type de message, les deux suivants sont un compteur de cycle... Chaque message long comporte donc plusieurs parties.
[0067] Dans ce tableau, la colonne « champ » indique ainsi à quoi correspond chaque partie du message. La colonne « longueur » indique le nombre de bits que prend chaque partie dans le message. La colonne « intervalle de valeurs » indique les valeurs que chaque partie du message peut prendre.
[0068] L’élaboration d’un tel message est bien connue de l’Homme du métier, via le protocole ADASIS. Elle ne sera donc pas ici décrite en détail.
[0069] On pourra seulement préciser que le champ « type de message » présentera ici une valeur qui est toujours la même puisqu’on ne s’intéressera dans la suite qu’aux messages longs.
[0070] Le champ « index de trajet » présente une valeur qui permet d’identifier le trajet où l’évènement est localisé.
[0071] Le champ « écart » présente une valeur qui permet de localiser l’évènement sur le trajet.
[0072] Le champ « type de profile » permet de caractériser l’évènement par un type par- ticulier. Ainsi, si sa valeur est égale à 1, l’évènement est une longitude, s’il est égal à 2, il s’agit d’une latitude, s’il est égal à 3, il s’agit d’une altitude, s’il est égal à 8, il s’agit d’un panneau de signalisation, s’il est égal à 9, il s’agit d’une limite de vitesse pour poids lourds. On notera que dans le protocole ADASIS, les valeurs 11 à 15 sont réservées pour des types standards, et que les valeurs 16 à 31 sont réservés pour des types spécifiques.
[0073] Le champ « valeur » permet quant à lui de stocker les données correspondant au type de profile (la valeur de la longitude, le type de panneau, la valeur de la limite de vitesse...).
[0074] En résumé, le champ « type de profile » indique à quoi la donnée stockée dans le champ « valeur » s’applique. Il désigne ainsi un type d’attribut caractérisant l’évènement (latitude, longitude, panneau, limite de vitesse).
[0075] Un « attribut » sera ici défini comme une caractéristique d’un évènement.
[0076] L’invention propose d’utiliser trois des valeurs 16 à 31 réservés pour des types spé- cifiques, afin de définir trois nouveaux types d’attributs, à savoir les attributs d’évènements temporaires statiques ou pseudo-statique, les attributs d’évènements temporaires dynamiques et les attributs d’évènements feux de circulation.
[0077] Un évènement statique est un évènement immobile.
[0078] Un évènement pseudo statique est un évènement qui bouge peu, compte tenu de sa vitesse et/ou de sa position par rapport au véhicule. Ainsi, un évènement dont la vitesse est inférieure à un seuil de vitesse (par exemple 5 km/h) ou dont la position est distante du véhicule au-delà d’un seuil de distance (par exemple 1000 mètres) est considéré comme pseudo statique.
[0079] On notera ici que chacun de ces seuils peut être fixe ou peut être une fonction de la vitesse du véhicule automobile 10 et/ou de la vitesse de l'événement et/ou de l'environnement. A titre d’exemple, les seuils pourront être plus ou moins grand selon le type d’environnement urbain, autoroutier ou rural dans lequel évolue le véhicule.
[0080] Un exemple d’évènement temporaire statique ou pseudo-statique est un véhicule à l’arrêt sur le trajet considéré, ou la fin d’une file d’attente dangereuse sur ce trajet.
[0081] Un évènement dynamique est défini par opposition aux évènements précités. Il s’agit par exemple d’un véhicule d’urgence en intervention.
[0082] Un attribut d’évènement feux de circulation permet de fournir par exemple la phase courante du feu de circulation (typiquement sa couleur) et le temps restant avant que cette phase change.
[0083] Ici, les événements temporaires dynamiques sont associés à la valeur 28.
[0084] En d’autres termes, lorsque le champ « type de profil » est égal à 28, cela signifie que le champ « valeur » va comporter une juxtaposition de plusieurs données caractérisant par différents aspects un évènement temporaire dynamique.
[0085] Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 10 bits, qui sont définies dans le tableau suivant. [0086] [Tableaux?]
[0087] Le champ « évènement dynamique compressé » sera détaillé ci-après. Il permet de catégoriser l’évènement dynamique.
[0088] Le champ « ID » permet d’identifier l’évènement temporaire dynamique par un numéro compris entre 0 et 62. Le numéro 63 est réservé au cas où tous les autres numéros sont pris. L’interface principale libère ce numéro 63 dès que ce n’est plus le cas.
[0089] On pourra ici noter que si on atteint le nombre maximum d’évènements dynamiques (63), il sera possible de se contenter d’avertir le constructeur d’horizon qu’un trop- plein est survenu. En variante, il sera possible de comparer le nouvel évènement avec ceux déjà classés. Si le plus éloigné d’entre eux (par rapport au véhicule) est plus éloigné que le nouvel évènement, il sera possible de libérer son ID et de le remplacer par celui du nouvel évènement. Dans le cas contraire, le nouvel évènement ne sera pas pris en compte.
[0090] On notera ici qu’un évènement dynamique sera identifié deux fois, d’une part par ce champ « ID », mais aussi par le champ « index de trajet » utilisé dans la table 1.
[0091] Grâce à cette double identification, lorsque deux messages associés à un même évènement sont envoyés successivement (par exemple parce que la position et/ou la vitesse de cet évènement a changé), il sera implicite que le message le plus ancien est obsolète puisqu’il est remplacé par le nouveau message. De cette manière, il ne sera pas nécessaire d’envoyer un message d’annulation d’un évènement dynamique.
[0092] A titre d’exemple, un évènement dynamique tel qu’un véhicule d’intervention roulant pourra être codé dans l’horizon artificiel en envoyant successivement des messages longs mis à jour. Dans cette configuration, le reconstructeur de chaque client pourra comprendre que ces messages sont associés à un même véhicule en in- tervention, dont la vitesse et la position évoluent, sans qu’il ne soit nécessaire de lui envoyer pour cela des messages d’annulation des messages précédents.
[0093] Le champ « âge » correspond au temps passé depuis que l’évènement a été élaboré, à 10 ms près. Il couvre une durée de 10s. Pour bien comprendre à quoi ce champ réfère,
11 faut rappeler que dans ce mode de réalisation, un message est transmis toute les 100 ms sur le BUS CAN. Quant plusieurs évènements se produisent simultanément, plusieurs messages vont donc être élaborés et ces messages vont être transmis succes- sivement les uns après les autres. Il peut donc arriver qu’un message soit transmis plusieurs centaines de millisecondes voire plusieurs secondes après avoir été élaboré. Dans cette éventualité, le champ « âge » va permettre d’indiquer depuis combien de temps le message a été élaboré.
[0094] Le champ « voie » indique la voie sur laquelle l’évènement s’applique. Ce champ s’applique aux voies de circulation du véhicule (celles que le véhicule peut emprunter compte tenu du sens selon lequel il circule). Ainsi, les évènements situés en dehors de ces voies sont associés à la valeur 0, les évènements situés dans la bande d’arrêt d’urgence sont associés à la valeur 1, et les évènements situés sur les voies de cir- culation sont associés à des valeurs comprises entre 2 et 14 (2 correspondant à la voie la plus à gauche, 3 à la voie immédiatement à côté...).
[0095] Le champ « direction » indique la direction selon laquelle l’évènement circule. Il prend la valeur 0 si l’évènement circule dans le même sens que le véhicule 10 et la valeur 1 sinon.
[0096] Le champ « valeur » est utilisé pour coder la vitesse de l’évènement. Il s’agit d’une valeur approximative. Chaque valeur correspond à un intervalle de vitesses, comme cela est défini dans le protocole ADASIS v2.0.4, à la table 12. A titre d’exemple, les valeur suivantes peuvent correspondre :
- « 1 » : une vitesse inférieure à 5 km/h,
- « 2 » : une vitesse comprise entre 5 et 7 km/h,
- « 2 » : une vitesse comprise entre 7 et 10 km/h,
- « 4 » : une vitesse comprise entre 10 et 15 km/h
- « 28 » : une vitesse comprise entre 140 et 150 km/h,
- « 29 » : une vitesse supérieure à 150 km/h.
[0097] On notera que ce champ « valeur » peut prendra la valeur 31 dans un cas bien par- ticulier. Lorsque ce champ prend la valeur 31, le message signifie que le message envoyé précédemment au sujet de ce même évènement (identifié par le champ ID) doit être effacé.
[0098] Le champ « évènement dynamique compressé » indique le type d’évènement dynamique auquel le message réfère.
[0099] On peut rappeler à ce sujet que l’ETSI, qui est l’organisme en charge des normes relatives à la technologie V2X, a déjà créé un tableau répertoriant les différents types d’évènements. Ce tableau distingue des grandes catégories (les causes) et des sous ca- tégories (les sous-causes).
[0100] Ce tableau correspond aux quatre premiers champs du tableau suivant.
[0101] [Tableaux3]
[0102] On notera sur ce tableau que chaque cause est définie par un premier code (seconde colonne) et chaque sous-cause est définie par un second code (quatrième colonne).
[0103] Cette classification prévoie de laisse libre de nombreux codes de cause (on passe ainsi directement de 3 à 12), si bien que stocker les valeurs de causes nécessite un grand nombre de bits (en l’occurrence, il en faudrait 7).
[0104] Ici, l’idée consiste à remplacer le code de la cause par un code cause compressé, indiqué par la dernière colonne du tableau ci-dessus. Ainsi, il est possible de coder le code cause compressé et le code sous cause en un nombre restreints de bits, ici en 5 bits. Ces deux codes sont alors stockés dans le champ « évènement dynamique compressé ».
[0105] Ici, les événements temporaires statiques ou pseudo-statiques sont associés à la valeur 29.
[0106] En d’autres termes, lorsque le champ « type de profil » est égal à 29, cela signifie que le champ « valeur » va comporter une juxtaposition de plusieurs données caractérisant par différents aspects un évènement temporaire statique ou pseudo-statique.
[0107] Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 7 bits, qui sont définies dans le tableau suivant.
[0108] [Tableaux4]
[0109] Les champs « évènement compressé » et « sous-cause » seront détaillés ci-après. Ils permettent de catégoriser l’évènement statique ou pseudo-statique.
[0110] Le champ « ID » permet d’identifier l’évènement par un numéro compris entre 0 et 126. Le numéro 127 est réservé au cas où tous les autres numéros sont pris. Comme pour le même champ dans le cas d’un évènement dynamique, l’interface principale est programmée pour libérer ce numéro dès que ce n’est plus le cas et pour sélectionner les évènements les plus proches avant ceux qui sont les plus éloignés lorsque l’ensemble des numéros sont pris.
[0111] Ici encore, un évènement statique ou pseudo-statique sera identifié deux fois, d’une part par ce champ « ID », mais aussi par le champ « index de trajet » utilisé dans la table 1. Grâce à cette double identification, il deviendra implicite qu’un évènement statique s’annule et est remplacé par les informations contenues dans un nouveau message.
[0112] Le champ « valeur » est utilisé pour coder la longueur L de l’évènement. Il prend la valeur 0 si la longueur n’est pas connue. Il prend sinon une valeur comprise entre 1 et 62. Sa valeur dépend alors de la longueur de l’évènement. Sa valeur est ici codée de la manière suivante :
- si la longueur est comprise entre 0 et 100 m, sa valeur est égale à la valeur entière de L/4,
- si la longueur est comprise entre 100 et 500 m, sa valeur est égale à la valeur entière de (L - 100) / 16 + 25,
- si la longueur est comprise entre 500 et 1908 m, sa valeur est égale à la valeur entière de (L - 500) / 128 + 50,
- si la longueur est supérieure à 1098 m, sa valeur est égale à 62.
[0113] On notera que ce champ « valeur » peut prendra la valeur 63 dans un cas bien par- ticulier. La valeur 63 indiquera que le message est relatif à un évènement statique qui doit être effacé, libérant ainsi l’identifiant du champ « ID » utilisé.
[0114] Le champ « voie de départ » indique la première voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie » précité.
[0115] Le champ « voie d’arrivée » indique la dernière voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie de départ ».
[0116] Le champ « confiance » indique le niveau de confiance dans la détection de l’évènement, la valeur 0 indiquant un niveau de confiance minimum et 3 indiquant un niveau de confiance maximum.
[0117] Le champ « évènement compressé » est codé sur 5 bits.
[0118] Pour définir ce champ, on peut noter que l’ETSI a déjà créé un tableau répertoriant les différents types d’évènements statiques qu’un véhicule peut rencontrer. Ce tableau distingue des grandes catégories (les causes) et des sous catégories (les sous-causes).
[0119] Si les sous-causes sont ici encore codés par des entiers naturels de valeurs réduites (ce qui nécessite peu de bits pour les coder), il n’en va pas de même pour les causes.
[0120] Ainsi, le champ « sous-cause » reprend les numéros affectés par l’ETSI sans les modifier, tandis que le champ « évènement compressé » prend des numéros différents de ceux affectés par l’ETSI.
[0121] Le tableau suivant permet d’indiquer la correspondance entre les numéros de l’ETSI et les numéros ici employés afin de le coder en un nombre réduit de bits.
[0122] [Tableaux5]
[0123] A ce stade, on pourra noter qu’un évènement statique devienne dynamique ou vis- versa. Dans cette éventualité, un nouveau message long correspondant à la nouvelle catégorie de l’évènement sera envoyé sur le BUS CAN.
[0124] Les événements feux de circulation sont associés à la valeur 30. [0125] En d’autres termes, lorsque le champ « type de profil » est égal à 30, cela signifie que le champ « valeur » va comporter une juxtaposition de données caractérisant l’état d’un feu de circulation.
[0126] On notera que si le feu de circulation est situé à un croisement, un message distinct peut être émis pour chaque direction dans le croisement, même si le même feu et la même phase sont valables pour aller tout droit et pour tourner à droite ou à gauche.
[0127] Le champ « valeur » de 32 bits est ainsi codé en plusieurs parties de 2 à 16 bits, qui sont définies dans le tableau suivant.
[0128] [Tableauxô]
[0129] Le champ « Direction de feu tricolore » indique vers quelle voie de circulation l’évènement est associé. Il prend la valeur 0 s’il est associé à la direction initiale (tout droit), la valeur 1 pour tourner à gauche, la valeur 2 pour tourner à droite et la valeur 3 pour toutes les directions.
[0130] Le champ « phase actuelle » indique la phase courante du feu de circulation. Il prend la valeur 1 s’il est au vert, 2 s’il est au rouge, 3 s’il est orange, 4 s’il est entre le orange et le rouge, 5 s’il clignote en rouge, 6 s’il clignote en orange et 7 s’il est sombre.
[0131] Le champ « phase suivante » indique la prochaine phase du feu de circulation. Sa valeur est définie de la même manière que pour le champ phase actuelle.
[0132] Le champ « temps avant phase suivante » indique, en fonction du temps universel UTC, l'heure à laquelle la phase suivante interviendra.
[0133] Le champ « voie de départ » indique la première voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie » précité.
[0134] Le champ « voie d’arrivée » indique la dernière voie sur laquelle l’évènement s’applique. Ce champ est codé de la même manière que le champ « voie de départ ».
[0135] Le champ « temps avant phase suivante » pourra plus précisément être codé de la manière suivante.
[0136] L’heure exacte extraite du système UTC ne peut pas être codée en 16 bits. L’idée est alors de faire en sorte que ce champ code l’heure UTC avec une précision de 100 ms seulement, modulo une heure.
[0137] Ici, ce champ prend la valeur 36001 dans le cas où la phase suivante est dans plus d'une heure (et la valeur 65535 en cas d'annulation des feux de circulation). Sinon, il prend une valeur comprise entre 0 et 36000. On notera que les valeurs 36002 à 65534 ne seront pas utilisés.
[0138] On peut alors donner l’exemple suivant.
[0139] S’il est 14h00 et que la phase suivante interviendra dans moins d’une heure, à 14h40mn52s300ms, alors le champ prendra la valeur : 40*60*10+52*10+3=24523 (soit 0x5FCB).
[0140] A ce stade, on pourra noter que les messages sont envoyés sur le réseau CAN BUS, ce qui permet au client d’acquérir une partie pertinente de l’horizon artificiel et d’assurer correctement la fonction pour laquelle il a été conçu.
[0141] De cette façon et à titre d’exemple non limitatif, le système de navigation pourra sé- lectionner un itinéraire qui évite au mieux les bouchons, le système d’aide à la conduite ADAS pourra réguler la vitesse du véhicule de façon à tenir compte des phases des feux et des plaques de verglas, et l’interface Homme-Machine (IHM) pourra afficher sur le tableau de bord des alertes pour attirer l’attention du conducteur sur des dangers.
[0142] On pourra ici noter qu’une partie seulement des messages pourront être envoyés sur le réseau. Ainsi, un filtrage pourra être effectué afin d’envoyer uniquement les messages longs liés à des évènements situés à proximité du véhicule, par exemple à une portée de moins de 2 km de ce dernier.
[0143] Plus précisément ici, ce filtrage pourra consister à envoyer les messages longs cor- respondant à des évènements statiques qu’à condition que l’évènement se situe à une distance du véhicule 10 inférieure à un premier seuil, lequel premier seuil est inférieur à la portée sur laquelle le client reçoit des informations relatives à la cartographie.
[0144] Il pourra en outre consister à envoyer les messages longs correspondant à des évènements dynamiques qu’à condition que l’évènement se situe à une distance du véhicule 10 inférieure à un second seuil, lequel second seuil est inférieur au premier seuil.
[0145] Ce filtrage pourra en outre consister à ne transmettre que les messages longs associés à des évènements qui sont situés soit sur le trajet principal 102, soit sur des trajets se- condaires mais à moins de 200m de leur embranchement avec le trajet principal 102.
[0146] La présente invention n’est nullement limitée au mode de réalisation décrit et re- présenté, mais l’homme du métier saura y apporter toute variante conforme à l’invention.
[0147] A titre d’exemple, on pourrait ne pas utiliser d’évènement feu de circulation. A contrario, on pourrait prévoir de distinguer un plus grand nombre de catégorie d’évènements temporaires (statiques proches, statiques éloignés, dynamiques proches, dynamiques éloignés...).

Claims

Revendications
[Revendication 1] Procédé d’élaboration d’un horizon artificiel pour un véhicule au- tomobile (10), comprenant des étapes de :
- réception de données d’entrée relatives au véhicule automobile (10) et à son environnement,
- détermination de différents trajets (101 - 105) empruntâmes par le véhicule automobile (10), et
- génération de messages caractérisant ledit horizon artificiel, dont au moins un message long associé à un évènement se trouvant sur l’un ou l’autre des trajets (101 - 105), chaque message long comportant plusieurs champs, dont au moins un premier champ relatif à un type d’attribut caractérisant l’évènement et un second champ indiquant la valeur de cet attribut, caractérisé en ce que le premier champ peut prendre au moins deux valeurs distinctes respectivement associées à un nombre correspondant de catégories prédéfinies d’évènements temporaires, lesdites catégories étant distinguées en fonction de la vitesse de l’évènement temporaire et/ ou de la position de l’évènement temporaire relativement au véhicule automobile (10).
[Revendication 2] Procédé d’élaboration selon la revendication 1, dans lequel une catégorie d’événements correspond à des évènements dynamiques, une catégorie d’événements correspond à des évènements statiques ou pseudo-statiques vis-à-vis du véhicule automobile (10), et une catégorie d’évènement correspond à des feux de circulation.
[Revendication 3] Procédé d’élaboration selon la revendication 2, dans lequel un évènement est considéré comme dynamique lorsque sa vitesse est su- périeure à un premier seuil et/ou lorsque sa distance au véhicule au- tomobile (10) est supérieure à un second seuil.
[Revendication 4] Procédé d’élaboration selon la revendication 3, dans lequel le premier seuil et/ou le second seuil est une fonction de la vitesse du véhicule au- tomobile (10) et/ou de la vitesse de l'événement et/ou de l'environnement.
[Revendication 5] Procédé d’élaboration selon l’une des revendications 2 à 4, dans lequel, lorsque la vitesse et/ou la distance au véhicule automobile (100) d’un évènement varie dans le temps, la valeur du premier champ peut changer.
[Revendication 6] Procédé d’élaboration selon l’une des revendications 2 à 5, dans lequel l’un au moins de évènements suivants est considéré comme dynamique :
- un véhicule d'urgence en intervention,
- un véhicule dont un système de freinage d'urgence est activé,
- un véhicule dont un système de retenue réversible des occupants est activé,
- une personne ou un animal sur le trajet,
- des travaux routiers mobiles sur le trajet,
- un véhicule roulant à contresens,
- des travaux mobiles de sauvetage et de récupération en cours,
- un véhicule au moins un tiers plus lent que la vitesse maximum autorisée,
- un véhicule générant un risque de collision,
- un véhicule violant le code de la route,
- une situation dangereuse.
[Revendication 7] Procédé d’élaboration selon l’une des revendications 2 à 6, dans lequel l’un au moins de évènements suivants est considéré comme statique :
- un accident,
- des travaux routiers,
- une portion de trajet impraticable,
- des conditions météorologiques défavorables,
- une zone d’ aquaplaning,
- une zone dangereuse,
- une zone de travaux de sauvetage et de récupération en cours,
- un véhicule à l’arrêt,
- une fin de file d’embouteillage dangereuse.
[Revendication 8] Procédé d’élaboration selon l’une des revendications 1 à 7, dans lequel chaque message long associé à une catégorie d’évènement temporaire comporte deux champs permettant d’identifier de deux façons distinctes chaque évènement.
[Revendication 9] Procédé d’élaboration selon l’une des revendications 1 à 8, dans lequel les données d’entrée sont au moins en partie issues d’un message de no- tification d’évènement décentralisé (DENM) et/ou d’un message d’avertissement coopératif (CAM) émis par un véhicule tiers.
[Revendication 10] Véhicule automobile (10) comprenant des clients logiciels parmi lesquels une interface homme-machine et/ou un système de navigation et/ou des systèmes d’aide à la conduite, caractérisé en ce qu’il comporte une interface principale qui est programmée pour mettre en œuvre un procédé d’élaboration conforme à l’une des revendications précédentes, afin de fournir à chaque client une partie au moins de l’horizon artificiel élaboré.
EP23701158.0A 2022-02-07 2023-01-20 Procédé d'élaboration d'un horizon artificiel Pending EP4476705A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2201036A FR3132588B1 (fr) 2022-02-07 2022-02-07 Procédé d’élaboration d’un horizon artificiel
PCT/EP2023/051406 WO2023148023A1 (fr) 2022-02-07 2023-01-20 Procédé d'élaboration d'un horizon artificiel

Publications (1)

Publication Number Publication Date
EP4476705A1 true EP4476705A1 (fr) 2024-12-18

Family

ID=81580706

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23701158.0A Pending EP4476705A1 (fr) 2022-02-07 2023-01-20 Procédé d'élaboration d'un horizon artificiel

Country Status (5)

Country Link
US (1) US20250148916A1 (fr)
EP (1) EP4476705A1 (fr)
CN (1) CN118661216A (fr)
FR (1) FR3132588B1 (fr)
WO (1) WO2023148023A1 (fr)

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19908869A1 (de) * 1999-03-01 2000-09-07 Nokia Mobile Phones Ltd Verfahren zum Ausgeben von Verkehrsinformation in einem Kraftfahrzeug
US6405128B1 (en) * 1999-12-20 2002-06-11 Navigation Technologies Corp. Method and system for providing an electronic horizon in an advanced driver assistance system architecture
US8046162B2 (en) * 2005-11-04 2011-10-25 Honda Motor Co., Ltd. Data broadcast method for traffic information
DE102014220935A1 (de) * 2014-10-15 2016-04-21 Continental Automotive Gmbh Verfahren zur Fahrassistenz unter Berücksichtigung einer Signalanlage
US10593198B2 (en) * 2016-12-06 2020-03-17 Flir Commercial Systems, Inc. Infrastructure to vehicle communication protocol
CN110383360B (zh) * 2016-12-19 2022-07-05 斯鲁格林有限责任公司 利用数字优先级排定的连接且自适应的车辆交通管理系统
US10899348B2 (en) * 2017-12-20 2021-01-26 Here Global B.V. Method, apparatus and computer program product for associating map objects with road links
EP3756396B1 (fr) * 2018-03-16 2024-08-21 Huawei Technologies Co., Ltd. Dispositifs et procédés de communication d2d
EP3700108B1 (fr) * 2019-02-20 2023-08-09 Volkswagen Aktiengesellschaft Procédé de support d'une première station mobile afin de prédire la qualité de canal d'une communication sans fil décentralisée planifiée vers une station partenaire de communication et station mobile
DE102018005869A1 (de) * 2018-07-25 2020-01-30 Zf Active Safety Gmbh System zur Erstellung eines Umgebungsmodells eines Fahrzeugs
US10820349B2 (en) * 2018-12-20 2020-10-27 Autonomous Roadway Intelligence, Llc Wireless message collision avoidance with high throughput
WO2021182655A1 (fr) * 2020-03-10 2021-09-16 엘지전자 주식회사 Dispositif de fourniture d'itinéraire et procédé de fourniture d'itinéraire associé
WO2021223866A1 (fr) * 2020-05-07 2021-11-11 Lenovo (Singapore) Pte. Ltd. Commande de distribution de message v2x
US20210319691A1 (en) * 2021-06-25 2021-10-14 Arvind Merwaday Collaborative detection and avoidance of phantom traffic jams

Also Published As

Publication number Publication date
CN118661216A (zh) 2024-09-17
WO2023148023A1 (fr) 2023-08-10
FR3132588A1 (fr) 2023-08-11
FR3132588B1 (fr) 2024-07-19
US20250148916A1 (en) 2025-05-08

Similar Documents

Publication Publication Date Title
US10578442B2 (en) Data mining to identify locations of potentially hazardous conditions for vehicle operation and use thereof
EP2017807B1 (fr) Procédé de détermination automatique des limitations de vitesse sur une route et système associé
EP2448802B1 (fr) Procédé pour déterminer de manière prédictive des situations routières d'un véhicule
US10883834B2 (en) Data mining in a digital map database to identify insufficient superelevation along roads and enabling precautionary actions in a vehicle
EP3137355B1 (fr) Dispositif de signalisation d'objets a un module de navigation de vehicule equipe de ce dispositif
US20170327128A1 (en) Data Mining in a Digital Map Database to Identify Insufficient Merge Lanes Along Roads and Enabling Precautionary Actions in a Vehicle
US20090299624A1 (en) Data mining in a digital map database to identify speed changes on upcoming curves along roads and enabling precautionary actions in a vehicle
WO2023021162A2 (fr) Unité de routage dynamique automatisée et procédé associé
US20200135022A1 (en) Slowdown events
FR3027109A1 (fr) Determination d'une vitesse optimale pour un vehicule automobile approchant d'un feu tricolore
FR3028344A1 (fr) Determination automatique d'une limitation de vitesse sur une route
FR2863557A1 (fr) Systeme et procede de determination du degre d'eveil
WO2020174141A1 (fr) Régulation de la vitesse d'un véhicule lors d'un dépassement en virage
EP4476705A1 (fr) Procédé d'élaboration d'un horizon artificiel
EP4182199A1 (fr) Système d'assistance à la conduite
EP3472015B1 (fr) Procédé de détermination d'une classe de conduite de référence
EP3270108B1 (fr) Procédé d'assistance d'un conducteur d'un véhicule en fonction d'informations fournies par un véhicule pilote, et dispositif associé
EP4229618B1 (fr) Procede de selection d'informations a transmettre a un systeme embarque d'un vehicule et dispositif associe
FR3103891A1 (fr) Dispositif d’aide à la navigation à détermination de voie la plus probable pour un véhicule, et procédé d’assistance à la conduite associé
WO2019063734A1 (fr) Procédé et dispositif pour améliorer la sécurité en roulage d'un véhicule
WO2024110257A1 (fr) Procédé de pilotage d'une fonction de changement de voie semi-automatique de véhicule automobile
FR3028651A1 (fr) Determination automatique d'une limitation de vitesse sur une route a partir d'un systeme de navigation
FR3141911A1 (fr) Procédé et système de gestion de la vitesse longitudinale d’un véhicule
WO2024018130A1 (fr) Procédé et dispositif de contrôle d'un système salc d'un véhicule en fonction de la qualité des lignes de marquage au sol
FR2742565A1 (fr) Procede de filtrage et de restitution d'informations routieres et dispositif de mise en oeuvre du procede

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240723

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)