Method for creating an artificial horizon

Abstract

The invention relates to a method for creating an artificial horizon for a motor vehicle, the method comprising the steps of: - receiving input data relating to the motor vehicle and to its surroundings; - determining different paths; and - generating messages characterising the artificial horizon, including long messages for characterising events, each long message having multiple fields including at least a first field relating to a type of attribute characterising the event and a second field indicating the value of said attribute. According to the invention, the first field can have at least two distinct values associated with a corresponding number of temporary event categories, the categories being separated according to their speeds and / or their positions relative to the motor vehicle.

Description

Description Title of the invention: Method for developing an artificial horizon. Technical field of the invention.

[0001] The present invention relates generally to interface systems that allow motor vehicles to perceive their external environments. Here, it relates to the generation of artificial horizons, that is, the data processing that allows the vehicle to construct a map of its surroundings.

[0002] The invention relates more specifically to a method for developing an artificial horizon for a motor vehicle, comprising the following steps: - receiving input data relating to the motor vehicle and its environment, - determination of different routes that can be taken by the motor vehicle, and - generation of messages characterizing said artificial horizon.

[0003] Several types of messages can be developed here, including: - vehicle positioning messages, - Positioning messages for each route, - messages characterizing each journey, - short and long messages characterizing events found on each route, each of the long messages having 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.

[0004] The invention also relates to a motor vehicle comprising software clients (among which a human-machine interface and / or a navigation system and / or driver assistance systems) and a main interface which is programmed to implement an elaboration process as described above, in order to provide each client with at least a part of the elaborated artificial horizon. State of the art

[0005] Many vehicles today are equipped with on-board driver assistance systems, which help the driver while driving, whether in dangerous driving situations or simply to improve driving comfort.

[0006] Examples of embedded systems include: the navigation system which helps the driver follow a route to get from a starting point to a destination, the driver assistance system known as "ADAS" (English acronym for "Advanced Driver Assistance System"), and the Human-Machine Interface (HMI) which displays or emits alerts while driving.

[0007] To function effectively, onboard systems must probe and analyze the vehicle's environment, both near and far. To this end, the vehicle is equipped with physical sensors that gather information about its surroundings.

[0008] To further improve its knowledge of its environment, the vehicle can also be equipped with V2X technology, through which it receives messages from transmitters located at a distance from it, for example from other vehicles (so-called V2V technology), road infrastructure (so-called V2I technology), the network (so-called V2N technology) or other road users such as pedestrians (so-called V2P technology).

[0009] 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 encountered or created during its movement (slippery road, dangerous turn, accident, traffic congestion...).

[0010] It is estimated that with the deployment of V2X technology in more and more vehicles and the development of 5G, the amount of information that will be received per second in a vehicle will be such that it will become necessary to select the most useful, otherwise there is a risk of slowing down the operation of the systems on board the vehicle or even saturating them.

[0011] In this context, several vehicle manufacturers have joined forces to create a protocol called ADASIS (Advanced Driver Assistance Systems Interface Specification). This protocol, and in particular its V2 version, is designed to describe the road geometry in front of the vehicle and characterize its environment using a large but limited number of parameters. This protocol is said to create an artificial horizon. According to this protocol, the environment is described not by road segments, but rather by paths that the vehicle can take. A main path is defined, on which the vehicle is located, along with secondary paths that originate from the main path or from other secondary paths.

[0012] 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 embedded systems (called "clients").

[0013] These types of messages are as follows: - Position messages relating to the vehicle's location, - End messages (in English, "Stub") relating to the position of the point where the path in question originates, - segment messages characterizing the main attributes of a part by- specific details of the journey in question, - short profile messages characterizing events located on each path, which can be expressed in 10 bits, - long profile messages characterizing events located on each path, which can be expressed in 32 bits, - metadata messages.

[0014] This protocol allows clients to receive accurate and easily usable environmental data, the amount of which varies from one client to another. Typically, most clients (for example, the automatic speed control system) only need data relating to the main route. Other clients, however, require more data, particularly data relating to events occurring on secondary routes (for example, to check if an emergency vehicle is approaching one of these secondary routes).

[0015] But even with this protocol, the amount of data to be processed by the vehicle's computers remains very large, so the problem of slowing down or saturation remains.

[0016] Furthermore, this protocol is designed to transmit only data relating to permanent events (sign, intersection, etc.), so it provides limited information. Presentation of the invention

[0017] In order to remedy the aforementioned drawbacks of the prior art, the present invention proposes to supplement the aforementioned ADASIS protocol (version 2) to add an additional dynamic layer to transmit information relating to temporary "events" (objects or circumstantial situations) which are relevant to customers, distinguishing events according to their nature.

[0018] More in particular, the invention proposes a method for developing 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 (i.e. transient, non-permanent) events, said categories being distinguished according to the speed of the temporary event and / or the position of the temporary event relative to the motor vehicle.

[0019] Thus, the invention proposes to leverage the long messages of the ADASIS protocol to transmit data encoded in a specific way. In particular, the first field (related to the attribute type) can take a first value to indicate that the second field (attribute value) will contain data relating to dynamic temporary events, or a second value to indicate that the The first field will contain data relating to static or pseudo-static temporary events (i.e., considered static even though they are not exactly so). 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.).

[0020] In this way, it is possible to efficiently provide customers with only the information that is useful to them, by exploiting the data that describes the cartographic information and adding attributes to indicate the presence of particular objects.

[0021] The advantage of distinguishing between dynamic and static events is that different attributes are used to characterize these two types of events. Consequently, only the relevant attributes will be encoded in each message, since each message will be associated with only one category of events.

[0022] It should also be noted that the method used to characterize these events will be such that it will not be necessary (unlike what is generally done according to the ADASIS protocol) to send a termination message when an event is updated (for example, its position). For example, by using the event identifier, the updated version of the event can be transmitted directly, without needing to delete the previous version. This will reduce the number of messages sent.

[0023] As will be explained later in this presentation, this implementation will also avoid transmitting the same kind of information multiple times, so as not to overload the computers.

[0024] Other advantageous and non-limiting features of the manufacturing process according to the invention, taken individually or in all technically possible combinations, are as follows: - one category of events corresponds to dynamic events, one category of events corresponds to static or pseudo-static events with respect to the motor vehicle, and one category of events corresponds to traffic lights; - an event is considered dynamic when its speed is greater than a first threshold and / or when its distance to 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 the speed of the event and / or the environment; - when the speed and / or distance to the motor vehicle of an event varies over time, the value of the first field may change; - at least one of the following events is considered dynamic: B an emergency vehicle responding to an incident, B. A vehicle with an activated emergency braking system, B. A vehicle equipped with a reversible occupant restraint system. B. a person or animal on the route, "Mobile roadworks along the route," "a vehicle driving in the wrong direction," B. Mobile rescue and recovery operations are underway. 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; - at least one of the following events is considered static: B an accident, B. roadworks, B. an impassable section of the route, B. adverse weather conditions, B, an aquaplaning zone, B, a dangerous area B. A rescue and recovery work zone in progress, B. A stationary vehicle, B a dangerous traffic jam end; - each long message associated with a temporary event category has 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 issued by a third-party vehicle.

[0025] The invention also relates to a motor vehicle comprising software clients (among which a human-machine interface and / or a navigation system and / or driver assistance systems) and a main interface which is programmed to implement an elaboration process as described above, in order to provide each client with at least a part of the elaborated artificial horizon.

[0026] Other preferred characteristics of the manufacturing process according to the invention are as follows: - Only events located on a primary route (also called the most probable route in the ADASIS protocol), at a distance from the vehicle below a certain threshold, are considered in messages sent to clients (which will reduce the amount of information sent, and therefore the bandwidth required for this sending) ; - this threshold is less than the distance over which the customer receives information on the mapping; - the input data provided to the motor vehicle by surrounding vehicles is also provided to the customer via long messages, without any possible dangerous situation being detected; Dynamic events: - A dynamic event is identified using the ADAS IS standard interface's route index field as well as the "ID" field. - 6 bits are used to discriminate dynamic events in the path index and a special value is used to indicate that all possible values ​​of the ID field are used; - the values ​​in the ID field are selected in ascending order; - the values ​​of the ID field allow tracking of dynamic events as long as they belong to the same road segment and allow updating its position without ending the event; - it is planned to send a specific message when the dynamic event no longer belongs to the initially identified path index, thus releasing the value of the corresponding ID field; - a specific value is used to indicate that more than 63 objects are present in the path index; - in such a so-called overflow case, when a new dynamic event has to be delivered to the customer, the decision on which event to prioritize is made based on the distance between the event and the vehicle; - thus, if the new event is further from the vehicle than all the events already transmitted, then the new event is rejected, otherwise the most distant event is rejected and the new event is used using the value of the ID field thus freed; - specific attributes that describe the cause and sub-cause of the dynamic event are described on 7 bits; - a specific attribute that represents the age of the dynamic event is described on 10 bits; - this attribute represents the time with an accuracy of 10 ms covering 10 seconds; - a specific attribute that represents the channel is described on 4 bits; - this specific attribute indicates on which lane the dynamic event is located (lane number, or emergency stopping lane); - a specific attribute that represents the direction is described on 2 bits; - this attribute indicates whether the dynamic event moves forward or backward; - a specific attribute which is called "value" represents the speed of the dynamic event, it is described on 5 bits; - an attribute that indicates the cause and sub-cause is described in 9 bits, of which 5 bits are for the cause; Static (or pseudo-static) events: - a static event is identified using the path index field of the standard ADAS IS interface as well as the "ID" field; - 7 bits are used to discriminate static events in the path index and a special value is reserved to indicate that all values ​​of the ID field are used. - the values ​​in the ID field are selected in ascending order; - these values ​​allow us to track static events as long as they belong to the same path segment and allow us to update their positions without ending the event; - It is planned to delete a specific message when the static event no longer belongs to the initially identified path index, thus freeing the value of the corresponding ID field; - a specific value is used to indicate that more than 127 objects are present in the specific index and that an overflow situation is occurring; - the case of overflow is treated in the same way as for dynamic events; - an attribute called "value" is used to indicate the duration of the static event - 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; - the length is not coded uniformly and the accuracy is degraded for increasing lengths; - lengths from 0 to 100 meters are coded using 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 delete the static event; - an attribute called start of track, described on 5 bits, indicates the first track number for which the static event is valid; - Static off-road events are associated with a lane start of 0 while the emergency stopping lane is associated with lane number 1 and lanes are counted from lane 2 to lane 31; - an attribute called end of lane, described on 5 bits, indicates the last lane number for which the static event is valid; Traffic light events: - traffic light events are associated with changes in the phases of the lights; - a field of the message linked to such an event is called "traffic maneuver", mapped on 2 bits, it indicates whether the phase entered is valid for going straight, turning left or right; - another field called "current phase", located on 3 bits, indicates the color of the current phase; - another field called "next phase", also filled in with 3 bits, indicates the next color of the following phase; - yet another field called "next phase time", using 16 bits, indicates the time at which the next phase will occur, preferably with a step of 100 ms; - in this field, the range of values ​​goes from 0 to 36000; - the value 36001 is the value if the next phase is in more than 1 hour; - the value 65535 is used in case of traffic lights going out; - another field called "start of track", using 4 bits, indicates the number of the first track for which this phase is valid; - another field called "end of track", using 4 bits, indicates the number of the last track for which this phase is valid; - in these last two fields, lane number 0 is used for off-road lanes, number 1 for the emergency stopping lane, and the other numbers for the other lanes, starting the numbering at 2 for the rightmost lane.

[0027] Of course, the different features, variants and embodiments of the invention can be combined with each other in various ways as long as they are not incompatible or mutually exclusive. Detailed description of the invention

[0028] The description that follows, with regard to the attached drawings, given by way of non-limiting examples, will make it clear what the invention consists of and how it can be carried out.

[0029] On the single attached drawing:

[0030] [Fig.1] is a view of a motor vehicle and part of its surroundings.

[0031] Figure 1 shows a motor vehicle 10 adapted to implement the invention.

[0032] This refers to a car. Alternatively, it could be another type of vehicle (truck, motorcycle, bus...).

[0033] Here, this motor vehicle 10 typically includes a passenger compartment in which It includes, among other things, a seat for the vehicle's driver, a powertrain, a braking system, and a steering system for turning the vehicle. Typically, the steering system includes an electronically controlled power steering actuator, the powertrain includes an electronically controlled engine control actuator, and the braking system includes an electronically controlled brake actuator.

[0034] This motor vehicle 10 is also equipped with at least one human-machine interface. In practice, this includes a touchscreen coupled with speakers.

[0035] It is also equipped here with a reversible occupant restraint system, typical of a controlled locking system for the seat belt.

[0036] The motor vehicle 10 also includes an electronic processing unit which includes several computers (microprocessors or microcontrollers), memories and input and output interfaces.

[0037] Thanks to its input interfaces, the electronic processing unit is adapted to receive various input data from sensors, third-party computers, or other entities (other vehicles, road equipment, pedestrian phones, networks, etc.). This input data relates to the motor vehicle (speed, etc.) and its environment (position on the road, mapping, etc.). V2X technology is specifically used for this purpose.

[0038] It should be noted that this input data comes, for example, from decentralized event notification messages (better known by the English acronym DENM for "Decentralised Event Notification Message") and cooperative warning messages (better known by the English acronym CAM for "Cooperative Awareness Message") issued by third-party vehicles located in the environment of the motor vehicle 10.

[0039] Thanks to its output interfaces, the electronic processing unit is adapted to control the human-machine interface in order to provide the driver with information. It is also adapted to control the power steering actuator, the engine control actuator, and the braking actuator in order to drive the motor vehicle autonomously or semi-autonomously.

[0040] Thanks to its memories, the electronic processing unit stores a computer application, consisting of computer programs (or "software") including instructions whose execution by the computers allows the implementation of the process described below.

[0041] In the remainder of this presentation, we will consider that each "software" allows the implementation of a particular "function".

[0042] ADAS software to assist vehicle driving is therefore planned (automatic speed regulation, keeping the vehicle centered in its lane, etc.). Also planned are 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 the route on the touch screen.

[0043] Each of these software programs forms a "client". Each client only needs to receive a portion of the input data in order to perform the function for which it was designed.

[0044] A main interface is then planned between the input interface that receives the input data and these clients.

[0045] This main interface, also called the artificial horizon provider, is then programmed to filter the input data in order to generate an artificial horizon representative of the environment of the motor vehicle 10, and to emit this artificial horizon on the vehicle network.

[0046] The vehicle's network, to which the clients are connected, is of the CAN bus type. Thus, the main interface can send messages on this network at regular intervals, here every 100ms.

[0047] Each client is then able to retrieve from the network all or part of the information contained in this artificial horizon.

[0048] Each client includes a software component called a "reconstructor" which is able to read the information required for the client to perform its function.

[0049] It should be noted that the artificial horizon can be defined as a set of computer data allowing to characterize a part of the environment of the vehicle (in particular the events whose knowledge is useful for piloting the motor vehicle 10).

[0050] The processing performed by the main interface is divided into a generic pre-processing which coarsely filters the input data and a post-processing which performs a more precise filtering, taking into account the topology of the streets where the relevant "events" are located (vehicles, objects, circumstantial situations).

[0051] This filtering makes it possible to offer customers an artificial horizon that suits them, that is to say, data that sufficiently describes the vehicle and its environment but which is limited in number so that the computing power of the customers is sufficient to process this data.

[0052] For this purpose, the main interface operates in accordance with the ADASIS protocol, in version 2.0 or later.

[0053] This protocol proposes to represent the artificial horizon by paths (see [Fig.1]).

[0054] Thus, taking into account the different branches of the road, the main interface is able to determine all the routes that the vehicle is likely to take.

[0055] It is planned to distinguish a main route 102 (for example the one which follows the road initially taken), and secondary routes 101, 103, 104, 105 which originate on the main route 102 or on other secondary routes.

[0056] It is also planned to define 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).

[0057] On each path there are events whose positions relative to the end are defined by a gap.

[0058] Some events are permanent (sign, speed bump...), while others are temporary.

[0059] Among these temporary events, we can distinguish objects (vehicles...) and circumstantial situations (end of traffic jam position, alert...).

[0060] The ADASIS protocol proposes considering only a limited number of paths (56 in this case) located in front of the vehicle. It also proposes considering only a limited length for each path, approximately 8 km in this case. These limitations prevent overloading the vehicle's computers. Consequently, the artificial horizon has a limited range.

[0061] This protocol is designed so that the main interface can send six types of messages over the CAN bus (to clients). These message types are as follows: - Position messages relating to the position of vehicle 10, - End messages relating to the starting position of the route in question, - segment messages characterizing the main attributes of a part of the journey, - short messages characterizing events along the route, which can be expressed in 10 bits, - long messages characterizing events along the route, which can be expressed in 32 bits, - metadata messages.

[0062] Within the scope of the present invention, we will only be interested in long messages.

[0063] Such a long message is sent on the CAN BUS when an event relevant to the driving of vehicle 10 is detected on one of the journeys, in a geographical area considered relevant.

[0064] Such a message includes several pieces of data defined by the following table.

[0065] [Tables 1]

[0066] A long message is therefore coded in 64 bits. This table shows that the first 3 bits characterize the message type, the next two are a cycle counter... Each long message thus comprises several parts.

[0067] In this table, the "field" column indicates what each part of the message represents. The "length" column indicates the number of bits each part occupies in the message. The "value range" column indicates the range of values ​​each part of the message can take.

[0068] The creation of such a message is well known to those skilled in the art, via the ADASIS protocol. It will therefore not be described in detail here.

[0069] We can only specify that the "message type" field will always have the same value here, since we will only be interested in long messages in the following.

[0070] The "path index" field presents a value that allows us to identify the path where the event is located.

[0071] The "deviation" field presents a value that allows the event to be located on the path.

[0072] The "profile type" field allows you to characterize the event by a specific type. Thus, if its value is 1, the event is a longitude; if it is 2, it is a latitude; if it is 3, it is an altitude; if it is 8, it is a road sign; and if it is 9, it is a speed limit for heavy goods vehicles. Note that in the ADASIS protocol, values ​​11 to 15 are reserved for standard types, and values ​​16 to 31 are reserved for specific types.

[0073] The "value" field, on the other hand, allows you to store the data corresponding to the type profile (longitude value, sign type, speed limit value...).

[0074] In summary, the "profile type" field indicates what the data stored in the "value" field applies to. It designates a type of attribute characterizing the event (latitude, longitude, sign, speed limit).

[0075] An "attribute" will be defined here as a characteristic of an event.

[0076] 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 static or pseudo-static temporary event attributes, dynamic temporary event attributes and traffic light event attributes.

[0077] A static event is an event that remains still.

[0078] A pseudo-static event is one that moves very little, given its speed and / or position relative to the vehicle. Thus, an event whose speed is below a certain speed threshold (for example, 5 km / h) or whose position is beyond a certain distance threshold from the vehicle (for example, 1000 meters) is considered pseudo-static.

[0079] It should be noted here that each of these thresholds can be fixed or can be a function of the speed of the motor vehicle 10 and / or the speed of the event and / or the environment. For example, the thresholds may be higher or lower depending on the type of environment: urban, highway, or rural in which the vehicle is operating.

[0080] An example of a static or pseudo-static temporary event is a vehicle stopped on the route in question, or the end of a dangerous queue on that route.

[0081] A dynamic event is defined in contrast to the aforementioned events. For example, an emergency vehicle responding to an incident.

[0082] A traffic light event attribute allows you to provide, for example, the current phase of the traffic light (typically its color) and the time remaining before this phase changes.

[0083] Here, dynamic temporary events are associated with the value 28.

[0084] In other words, when the "profile type" field equals 28, it means that the "value" field will contain a juxtaposition of several data points characterizing a dynamic temporary event in different aspects.

[0085] The 32-bit "value" field is thus coded into several parts of 2 to 10 bits, which are defined in the following table.

[0086] [Paintings?]

[0087] The "compressed dynamic event" field will be detailed below. It allows the dynamic event to be categorized.

[0088] The "ID" field allows the dynamic temporary event to be identified by a number between 0 and 62. Number 63 is reserved for cases where all other numbers are taken. The main interface releases number 63 as soon as this is no longer the case.

[0089] It's worth noting that if the maximum number of dynamic events (63) is reached, it will be possible to simply notify the horizon constructor that an overflow has occurred. Alternatively, it will be possible to compare the new event with those already classified. If the furthest of these (relative to the vehicle) is farther away than the new event, its ID can be freed and replaced with that of the new event. Otherwise, the new event will not be taken into account.

[0090] It should be noted here that a dynamic event will be identified twice, on the one hand by this "ID" field, but also by the "path index" field used in table 1.

[0091] Thanks to this dual identification, when two messages associated with the same event are sent successively (for example, because the position and / or speed of that event has changed), it will be implicitly assumed that the older message is obsolete since it is replaced by the newer message. In this way, it will not be necessary to send a cancellation message for a dynamic event.

[0092] For example, a dynamic event such as a moving emergency vehicle can be encoded in the artificial horizon by successively sending long, updated messages. In this configuration, each client's reconstructor will be able to understand that these messages are associated with the same emergency vehicle, whose speed and position are changing, without needing to send it messages to cancel out previous messages.

[0093] The "age" field corresponds to the time elapsed since the event was created, to To the nearest 10 ms. It covers a duration of 10 seconds. To fully understand what this field refers to, 11. It should be noted that in this implementation, a message is transmitted every 100 ms on the CAN bus. When several events occur simultaneously, several messages will be generated and transmitted successively. Therefore, a message may be transmitted several hundred milliseconds, or even several seconds, after it has been generated. In this case, the "age" field will indicate how long ago the message was generated.

[0094] The "lane" field indicates the lane to which the event applies. This field applies to the vehicle's traffic lanes (those that the vehicle can use given the direction in which it is traveling). Thus, events located outside these lanes are associated with the value 0, events located in the emergency stopping lane are associated with the value 1, and events located in 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, etc.).

[0095] The "direction" field indicates the direction in which the event travels. It takes the value 0 if the event travels in the same direction as vehicle 10 and the value 1 otherwise.

[0096] The "value" field is used to encode the event speed. This is an approximate value. Each value corresponds to a speed range, as defined in the ADASIS v2.0.4 protocol, Table 12. For example, the following values ​​might correspond to: - "1": a speed of less than 5 km / h, - "2": a speed between 5 and 7 km / h, - "2": a speed between 7 and 10 km / h, - "4": a speed between 10 and 15 km / h - "28": a speed between 140 and 150 km / h, - "29": a speed greater than 150 km / h.

[0097] Note that this "value" field can take the value 31 in a very specific case. When this field takes the value 31, the message means that the message previously sent about this same event (identified by the ID field) should be deleted.

[0098] The "compressed dynamic event" field indicates the type of dynamic event to which the message refers.

[0099] It's worth noting in this regard that ETSI, the organization responsible for V2X technology standards, has already created a table listing the different types of events. This table distinguishes between broad categories (the causes) and subcategories. categories (the sub-causes).

[0100] This table corresponds to the first four fields of the following table.

[0101] [Tables 3]

[0102] Note on this table that each cause is defined by a first code (second column) and each sub-cause is defined by a second code (fourth column).

[0103] This classification allows for many cause codes to be left free (thus going directly from 3 to 12), so storing cause values ​​requires a large number of bits (in this case, 7 would be needed).

[0104] The idea here is to replace the cause code with a compressed cause code, indicated by the last column of the table above. This allows the compressed cause code and the sub-cause code to be encoded in a limited number of bits, in this case, 5 bits. These two codes are then stored in the "compressed dynamic event" field.

[0105] Here, static or pseudo-static temporary events are associated with the value 29.

[0106] In other words, when the "profile type" field is equal to 29, it means that the "value" field will contain a juxtaposition of several data characterizing in different aspects a static or pseudo-static temporary event.

[0107] The 32-bit "value" field is thus coded into several parts of 2 to 7 bits, which are defined in the following table.

[0108] [Tables 4]

[0109] The "compressed event" and "sub-cause" fields will be detailed below. They allow us to categorize the event as static or pseudo-static.

[0110] The "ID" field identifies the event with a number between 0 and 126. Number 127 is reserved for cases where all other numbers are taken. As with the same field for a dynamic event, the main interface is programmed to release this number as soon as it is no longer in use and to select the closest events before the most distant ones when all numbers are taken.

[0111] Here again, a static or pseudo-static event will be identified twice, on the one hand by this "ID" field, but also by the "path index" field used in table 1. Thanks to this double identification, it will become implicit that a static event cancels itself out and is replaced by the information contained in a new message.

[0112] The "value" field is used to encode the length L of the event. It takes the value 0 if the length is unknown. Otherwise, it takes a value between 1 and 62. Its value then depends on the length of the event. Its value is encoded here as follows: - if the length is between 0 and 100 m, its value is equal to the integer value of L / 4, - if the length is between 100 and 500 m, its value is equal to the integer value of (L - 100) / 16 + 25, - if the length is between 500 and 1908 m, its value is equal to the integer value of (L - 500) / 128 + 50, - if the length is greater than 1098 m, its value is equal to 62.

[0113] Note that this "value" field can take the value 63 in a very specific case. The value 63 indicates that the message relates to a static event that must be deleted, thus freeing the identifier of the "ID" field used.

[0114] The "starting lane" field indicates the first lane to which the event applies. This field is coded in the same way as the aforementioned "lane" field.

[0115] The "arrival lane" field indicates the last lane to which the event applies. This field is coded in the same way as the "departure lane" field.

[0116] The "confidence" field indicates the level of confidence in the detection of the event, with a value of 0 indicating a minimum confidence level and 3 indicating a maximum confidence level.

[0117] The "compressed event" field is coded on 5 bits.

[0118] To define this field, it's worth noting that ETSI has already created a table listing the different types of static events a vehicle can encounter. This table distinguishes between broad categories (the causes) and subcategories (the sub-causes).

[0119] If the sub-causes are again coded here by natural numbers of reduced values (which requires few bits to encode), the same cannot be said for the causes.

[0120] Thus, the "sub-cause" field takes the numbers assigned by ETSI without modifying them, while the "compressed event" field takes different numbers from those assigned by ETSI.

[0121] The following table shows the correspondence between the ETSI numbers and the numbers used here to encode it in a reduced number of bits.

[0122] [Tables 5]

[0123] At this stage, it can be noted that a static event may become dynamic or vice versa. In this event, a new long message corresponding to the new category of the event will be sent on the CAN bus.

[0124] Traffic light events are associated with the value 30.

[0125] In other words, when the "profile type" field is equal to 30, it means that the "value" field will contain a juxtaposition of data characterizing the state of a traffic light.

[0126] Note that if the traffic light is located at an intersection, a separate message may be issued for each direction in the intersection, even if the same light and the same phase are valid for going straight and for turning right or left.

[0127] The 32-bit "value" field is thus coded into several parts of 2 to 16 bits, which are defined in the following table.

[0128] [Tableauxô]

[0129] 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 ahead), the value 1 for turning left, the value 2 for turning right, and the value 3 for all directions.

[0130] 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 if it is flashing orange and 7 if it is dark.

[0131] 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.

[0132] The "time to next phase" field indicates, based on UTC universal time, the time at which the next phase will occur.

[0133] The "starting lane" field indicates the first lane to which the event applies. This field is coded in the same way as the aforementioned "lane" field.

[0134] The "arrival lane" field indicates the last lane to which the event applies. This field is coded in the same way as the "departure lane" field.

[0135] The "time before next phase" field can be coded more precisely as follows.

[0136] The exact time extracted from the UTC system cannot be encoded in 16 bits. The idea is therefore to have this field encode the UTC time with an accuracy of 100 ms. only, modulo one hour.

[0137] Here, this field takes the value 36001 if the next phase is more than an hour away (and the value 65535 if the traffic lights are cancelled). Otherwise, it takes a value between 0 and 36000. Note that the values ​​36002 to 65534 will not be used.

[0138] We can then give the following example.

[0139] If it is 2:00 PM and the next phase will occur in less than an hour, at 2:40:52:30 PM, then the field will take the value: 40*60*10+52*10+3=24523 (i.e., 0x5FCB).

[0140] At this stage, it can be noted that the messages are sent over the CAN BUS network, which allows the client to acquire a relevant part of the artificial horizon and to properly perform the function for which it was designed.

[0141] In this way and as a non-limiting example, the navigation system will be able to select a route that best avoids traffic jams, the ADAS driver assistance system will be able to regulate the vehicle's speed to take into account traffic light phases and patches of black ice, and the Human-Machine Interface (HMI) will be able to display alerts on the dashboard to draw the driver's attention to dangers.

[0142] It should be noted here that only a portion of the messages can be sent over the network. Therefore, filtering can be implemented to send only long messages related to events located near the vehicle, for example, within a range of less than 2 km.

[0143] More specifically here, this filtering may consist of sending long messages corresponding to static events only if the event is located at a distance from the vehicle 10 less than a first threshold, which first threshold is less than the range over which the client receives information relating to the mapping.

[0144] It may also consist of sending long messages corresponding to dynamic events only if 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.

[0145] This filtering may also consist of transmitting only long messages associated with events which are located either on the main route 102, or on secondary routes but less than 200m from their junction with the main route 102.

[0146] The present invention is in no way limited to the embodiment described and re-presented, but a person skilled in the art will be able to make any variation in accordance with the invention.

[0147] For example, we could choose not to use a traffic light event. Conversely, we could plan to distinguish a larger number of categories. of temporary events (near static, far static, near dynamic, far dynamic...).

Claims

Demands

1. A method for producing an artificial horizon for a motor vehicle (10), comprising the steps of: - receiving input data relating to the motor vehicle (10) and its environment, - determination of different routes (101 - 105) taken by the motor vehicle (10), and - generation of messages characterizing said artificial horizon, of which at least one long message associated with an event on one or the other of the paths (101 - 105), each long message comprising several fields, of which at least a first field relating to a type of attribute characterizing the event and a second field indicating the value of this attribute, characterized in that the first field can take at least two distinct values ​​respectively associated with a corresponding number of predefined categories of temporary events, said categories being distinguished according to the speed of the temporary event and / or the position of the temporary event relative to the motor vehicle (10).

2. A method of production according to claim 1, wherein one category of events corresponds to dynamic events, one category of events corresponds to static or pseudo-static events with respect to the motor vehicle (10), and one category of events corresponds to traffic lights.

3. A method of development according to claim 2, wherein an event is considered dynamic when its speed is greater than a first threshold and / or when its distance to the motor vehicle (10) is greater than a second threshold.

4. A method of preparation according to claim 3, wherein the first threshold and / or the second threshold is a function of the speed of the motor vehicle (10) and / or the speed of the event and / or the environment.

5. A method of elaboration according to any one of claims 2 to 4, wherein, when the speed and / or distance to the motor vehicle (100) of an event varies over time, the value of the first field can change.

6. A method of preparation according to any one of claims 2 to 5, wherein At least one of the following events is considered dynamic: - an emergency vehicle responding to an incident, - a vehicle with an activated emergency braking system, - a vehicle equipped with an activated reversible occupant restraint system - a person or animal on the route, - mobile roadworks along the route, - a vehicle driving in the wrong direction, - Mobile rescue and recovery operations are underway, - a vehicle at least one-third slower than the maximum permitted speed, - a vehicle that poses a risk of collision, - a vehicle violating the highway code, - a dangerous situation.

7. A manufacturing process according to any one of claims 2 to 6, wherein at least one of the following events is considered static: - an accident, - roadworks, - an impassable section of the route, - adverse weather conditions, - an aquaplaning zone, - a dangerous area, - an area of ​​ongoing rescue and recovery work, - a stationary vehicle, - a dangerous end to a traffic jam.

8. A method of development according to any one of claims 1 to 7, wherein each long message associated with a temporary event category has two fields allowing each event to be identified in two distinct ways.

9. A method of development according to any one of claims 1 to 8, wherein the input data are at least partly derived from a decentralized event notification message (DENM) and / or a cooperative warning message (CAM) issued by a third-party vehicle.

10. Motor vehicle (10) comprising software clients including a human-machine interface and / or a navigation system and / or driver assistance systems, characterized in that it comprises a main interface which is programmed to implement a manufacturing process according to one of the preceding claims, in order to provide each customer with at least a part of the artificial horizon being created.

Images