Method for determining the usability of data for a traffic-related function

Abstract

The invention relates to a method (100) for determining the usability of data for a traffic-related function, said method comprising the following steps: - receiving (101), at a station (10), a message for the traffic-related function of the station, the message comprising data and metadata, the metadata comprising information about the data in relation to the traffic-related function, - analysing (102) the data for the traffic-related function based on an evaluation of the metadata, the evaluation comprising a check as to whether the received data in the message satisfies at least one requirement of the traffic-related function, - determining (103) the usability of the data for the traffic-related function based on the analysis (102).

Description

[0001] Description

[0002] title

[0003] A method for determining usability of data for a road traffic-related function

[0004] The invention relates to a method for determining the usability of data for a road traffic-related function. Furthermore, the invention relates to a station, a computer program, and a storage medium for this purpose.

[0005] State of the art

[0006] The structure of vehicle-to-everything (V2X) messages is determined by standards development organizations (SDOs), including the European Telecommunications Standards Institute (ETSI) and SAE International. Certain V2X messages, such as CAM (Cooperative Awareness Message, ETSI), VAM (VRU Awareness Message, ETSI), CPM (Collective Perception Message, ETSI), and BSM (Basic Safety Message, SAE), have already been standardized.

[0007] Currently, V2X data can often originate from swarm-sourced information. The driver remains responsible for reacting to the V2X information and determining the need for an action, such as gradually reducing speed based on a collision warning. Due to the absence of robust safety attributes, vehicles cannot directly use V2X data for safety-critical driving actions, such as initiating abrupt braking (Automatic Emergency Braking, AEB) or steering maneuvers. The development of safe CAD (Cooperative Automated Driving) systems primarily revolves around creating a comprehensive system in which safety is embedded in the overall concept. This system could manifest itself as a safe "closed-world" environment in which both sender and receiver adhere to the same safety concept and homologation.It could be tailored to a specific use case. An example of such a system is automated valet parking (AVP), which may currently be in the standardization phase at ETSI. Unfortunately, every time a new vehicle is developed, a completely new homologation may be required for all conceivable AVP garage / vehicle pairings to ensure security across all possible combinations.

[0008] US2021219139 A describes a method for increasing the trust in the received V2X data by including metadata on the sender side in the V2X message, such as the vehicle manufacturer, the technical equipment, the vehicle age, the implementation details of hardware and software and a certification level of the sending vehicle.

[0009] WO2022 / 122450 A1 describes the inclusion of a "safety section" in V2X messages to enable their use for safety-related driving functions. The safety section may include a safety level, a failure rate, a development process indicator, validity time, a fault model, and / or confidence of the V2X data.

[0010] US20230059220 A1 describes a method for validating received V2X messages by comparing their data with the same data from another source (e.g., an object detected by on-board sensors, plausibility of the transmitter position with RSSI, previous V2X messages).

[0011] Disclosure of the invention

[0012] The stated object is achieved by a method having the features of claim 1, a station having the features of claim 9, a computer program having the features of claim 10 and a computer-readable storage medium having the features of claim 11. Further features and details of the invention are disclosed in the dependent claims, the description and the drawings. Features and details described in connection with the method according to the invention also apply to the station according to the invention, the computer program according to the invention and the storage medium according to the invention, and in any case also vice versa, so that with regard to the disclosure relating to the individual aspects of the invention, reference can always be made to one another.

[0013] The objective is achieved in particular by a method for determining the usability of data for a road traffic-related function, comprising the following steps:

[0014] Receiving, at a station, a message for the road traffic-related function of the station, the message comprising data, in particular measured and / or estimated values, and metadata, the metadata comprising information about the data relating to the road traffic-related function,

[0015] Analyzing the data for the road traffic-related function based on an evaluation of the metadata, wherein the evaluation comprises checking whether the received data of the message fulfills at least one requirement of the road traffic-related function, determining the usability of the data for the road traffic-related function based on the analysis.

[0016] This advantageously enables a more efficient evaluation of the received message. Furthermore, this potentially prevents the occurrence of hazards, for example in connection with a road traffic-related function. Furthermore, this has the advantage that the method according to the invention supports more effective decision-making, for example as to whether the data in the received message meets the requirements of a road traffic-related function performed at the receiving station. Furthermore, the method according to the invention enables the improvement of existing road traffic-related applications, for example with regard to traffic safety, driver assistance, and / or automated driving applications.It is possible for the metadata to include a confidence description for the data, providing a confidence indication of the accuracy of the data and / or a probability density function, including a best distribution type to match the distribution of the received data.

[0017] This has the advantage of significantly improving the decision-making process. The use of a confidence description and / or a probability density function advantageously enables better choices based on probabilities. For example, it can be determined whether the probability that the accuracy of the data is within a given interval or above a given value exceeds a given threshold.

[0018] It is also possible that the method includes the following further step during the analysis:

[0019] Matching the confidence description of the data with a probability density function using a probability distribution fitting, where the information provided by the metadata specifies a distribution type and a parameterization of the probability density function.

[0020] This enables easier comparison between distributions and more efficiently supports the selection of a most appropriate model for a received data set. It also allows for a detailed model of the probability density function to be described using a few parameters, resulting in a small metadata size and thus minimizing the additional channel load caused by the transmission of the V2X message.

[0021] It is conceivable that the distribution type is defined by a set of statistical parameters, which makes it possible to calculate the probability that a real value of the data lies within an arbitrary range of data.

[0022] This makes it possible to advantageously increase the use of data for the road traffic-related function.

[0023] It is possible for the metadata to comprise at least one of the following information for the road traffic-related function: information regarding an operating condition of a station (20) that has transmitted the message, in particular the V2X message, a level of data completeness of the received data in relation to the total amount of measured and / or estimated data by the station (20) that has transmitted the message, a quality of service level for a V2X communication link between at least two stations (10, 20), wherein the quality of service level relates to a property of the communication link, a data consistency value of the received data, wherein the value indicates a degree of reliability and / or probability of presence of the measured and / or estimated values ​​of the received data contained in the message.

[0024] This makes it possible to advantageously improve the performance of the road traffic-related function in terms of decision making.

[0025] It is possible that during the analysis, the evaluation further includes a check as to the extent to which the received data can be used in the road traffic-related function, the method comprising the following further step:

[0026] Initiating the use of the received data in the road traffic-related function based on the result of determining usability. This has the advantage of more effective control over the use of available data.

[0027] There is a further possibility that the road traffic-related function of the station is a driving function and / or an automated driving function and / or a driver assistance function and / or a traffic management function and / or a cyclist assistance function and / or a pedestrian assistance function.

[0028] This allows such functions to be better enabled in terms of efficient and effective operation based on the data received.

[0029] It is conceivable that the procedure includes the following further step during the analysis:

[0030] Analyzing the data for the road traffic-related function based on an evaluation of the metadata, wherein the evaluation includes a check whether the received data can be used for a safety-critical scenario.

[0031] The analysis of the received data allows to better identify and select a suitable data set for the given scenario.

[0032] In another aspect of the invention, a computer program may be provided, in particular a computer program product, comprising instructions which, when executed by a computer, cause the computer to perform the method according to the invention. Therefore, the computer program according to the invention may have the same advantages as described in detail with reference to a method according to the invention.

[0033] In another aspect of the invention, a station may be provided that is configured to carry out the method according to the invention. The station may, for example, comprise a computer that executes the computer program according to the invention. The computer may comprise at least one processor that can be used to execute the computer program. Furthermore, a non-volatile data memory may be provided in which the computer program may be stored and from which a computer program may be read by the processor to be executed.

[0034] According to another aspect of the invention, a computer-readable storage medium may be provided comprising the computer program according to the invention and / or instructions which, when executed by a computer of a station, cause the computer to perform the steps of the method according to the invention. The storage medium may be embodied as a data storage device such as a hard disk and / or a non-volatile memory and / or a memory card and / or a solid-state drive. The storage medium may, for example, be integrated into the computer of the station.

[0035] Furthermore, the method according to the invention can be implemented as a computer-implemented method.

[0036] Further advantages, features, and details of the invention will become apparent from the following description, in which embodiments of the invention are described in detail with reference to the drawings. In this context, the features mentioned in the claims and in the description may be essential to the invention individually or in any combination. Shown is:

[0037] Fig. 1 : A method, computer program, a storage medium and a device according to embodiments of the invention,

[0038] Fig. 2: A method according to embodiments of the invention,

[0039] Fig. 3: A method of message flow and adaptation of a data / metadata set according to embodiments of the invention, Fig. 4: Method of calculating a data / metadata set and using the updated set according to embodiments of the invention,

[0040] Fig. 5: A signed station metadata set according to embodiments of the invention,

[0041] Fig. 6: A public key infrastructure according to embodiments of the invention,

[0042] Fig. 7: A signed TX station data message according to embodiments of the invention,

[0043] Fig. 8: A signed TX station data message with metadata according to embodiments of the invention,

[0044] Fig. 9: A flowchart of a verification sequence according to embodiments of the invention,

[0045] Fig. 10: A sequence diagram of a method according to embodiments of the invention,

[0046] Fig. 11 : A method with a vehicle and an intelligent traffic light according to embodiments of the invention,

[0047] Fig. 12: A method with one station and two vehicles according to embodiments of the invention,

[0048] Fig. 13: A sequence diagram of a method according to embodiments of the invention,

[0049] Fig. 14: A sequence diagram of a process with a

[0050] Database version check according to embodiments of the invention, Fig. 15: A sequence diagram of a method wherein options are provided, according to embodiments of the invention,

[0051] Fig. 16: A method with a vehicle and an intelligent traffic light according to embodiments of the invention.

[0052] V2X communication can stand for "vehicle-to-everything" communication. Specifically, it is a technological framework that enables communication between vehicles and various elements of the transportation ecosystem, including other vehicles (V2V), infrastructure (V2I), pedestrians (V2P), cyclists (V2C), and more. One goal of V2X communication can be to improve road safety, traffic efficiency, and the effectiveness of the transportation system as a whole by allowing vehicles and other entities to exchange information in real time. This technology can have applications in advanced driver assistance systems (ADAS), autonomous driving, traffic management, and various other aspects of modern transportation.

[0053] The transmission of V2X messages through V2X communication can facilitate the exchange of information between vehicles and / or infrastructure components and / or pedestrians. This message exchange can also support the operation of current road traffic-related applications aimed at improving traffic safety, efficiency, driver comfort, and enhancing the reliability of existing driver assistance and automated driving applications. Illustrative examples include C-ACC (Cooperative Automated Cruise Control) and V2X-linked collision warnings (e.g., due to an impending traffic jam or a pedestrian crossing a roadway).

[0054] Metadata can refer to data that provides information about other data. It can describe various attributes of the primary data, such as origin, format, creation date, authorship, and other relevant details. Metadata can help organize, understand, and manage primary data, whether it is a document, an image, a video, or any other type of information. On the other hand, a descriptor can refer to a term or label used to describe or identify a specific characteristic or quality of something. It can also be used in the context of linguistics or programming, where it represents a description or identifier for a specific entity or concept.In summary, while both metadata and descriptor contain descriptions and information, metadata specifically refers to information about other data, whereas a descriptor generally refers to a label or term used to describe a particular aspect or quality of something.

[0055] Payload can refer to essential information or content carried within a data packet or message. It represents the actual data that carries meaning or value and is distinct from additional metadata or control information.

[0056] A road traffic-related function is defined as a specific operation or task directly linked to the flow and / or management of traffic on roads. This function may include the exchange of data and information between vehicles (V2V), infrastructure (V2I), or pedestrians (V2P), enabling real-time communication to improve road safety, traffic efficiency, and / or overall transport effectiveness. In certain road traffic scenarios, a road traffic-related function may relate to a safety-critical scenario, such as an emergency braking scenario, an evasive maneuver scenario, or a collision warning scenario.

[0057] This present invention particularly addresses a situation in which at least two road users, e.g., vehicles, vulnerable road users, or road infrastructure, are involved in an exchange of information via V2X communication, and wherein at least one uses the received information for a road traffic-related function, such as remote driving, platooning, emergency braking, or the like.

[0058] One aspect addressed in the present invention is how the receiver of a V2X message can decide whether the information contained therein can be safely used for decision making in one of its use cases.

[0059] To enable a road-related response based on received V2X data, the receiver must ensure that the received data meets the requirements of the road-related function when executed. These requirements may include, for example, the accuracy of measured or estimated values, the accuracy of the time source, the maximum tolerable age of the V2X data, the minimum number of uncorrelated information sources, an automotive safety integrity level (ASIL) for the sender's system design, or the ability to detect sensing degradation.

[0060] One option for the receiver to verify whether its requirements are met may be to analyze the received V2X data. The data transmitted in the V2X messages can be determined using the V2X message definitions standardized by the corresponding SDO. The data transmitted in the current message definitions may not be sufficient to determine the suitability of received V2X data for road traffic-related functions.

[0061] The following example can illustrate a problem that is solved by the present invention. Let us assume that a first vehicle has a side-facing camera for a safety-critical function that secures the near field (< 3 meters) around the vehicle. This camera can now detect a pedestrian 5 meters away from the first vehicle who is (with high probability) walking towards the road. This information can then be passed on to a second vehicle via V2X. The second vehicle can follow the first vehicle and may not be able to detect the pedestrian due to obstacles. The question now could be whether the second vehicle should perform a hard braking maneuver based on the information received via V2X. This question cannot be answered by the first vehicle in particular, since it is unaware of the safety requirements of the second vehicle's emergency braking system.Unfortunately, the second vehicle may also be unable to answer the question, as it doesn't know the characteristics of the first vehicle's camera and any other sensors that may have been used in sensor fusion to determine whether the source of information meets the requirements of its emergency braking system. In this case, the fact that the first vehicle's side-facing camera is part of another safety-critical function on a different vehicle with likely very different requirements may not help the decision-making process.

[0062] The invention describes in particular which data can be contained in the V2X messages, how they can be described and how the receiver can process the received V2X data in order to determine their usability for road traffic-related, in particular safety-critical, driving functions.

[0063] Fig. 1 illustrates a method, a computer program, a storage medium, and a station according to embodiments of the invention. Fig. 1 shows a method 100 for determining the usability of data for a road traffic-related function. The method 100 comprises the following steps:

[0064] In step 101, at a station 10, a message is sent for the

[0065] Road traffic-related function of station 10 is received. The message comprises data, in particular measured and / or estimated values, and metadata, wherein the metadata comprises information about the data relating to the road traffic-related function. In step 102, the data for the road traffic-related function are analyzed based on an evaluation of the metadata. The evaluation comprises a check as to whether the received data of the message fulfill at least one requirement of the road traffic-related function. In step 103, the usability of the data for the road traffic-related function is determined based on the analysis step 102.

[0066] Fig. 1 further shows a station 10 comprising a computer 11 and a computer-readable storage medium 15. The computer-readable storage medium 15 comprises a computer program 50.

[0067] According to the embodiment shown in Fig. 2, a station 10 may perform the following steps. In step 202, a metadata configuration may be calculated based on the anticipated need determined in step 201. The calculation may be performed at any time before sending a message requiring the metadata. It may be performed periodically when any new information influencing the metadata selection becomes available from the station 10 itself or is received from some other location, or when starting to send a message and the metadata configuration is truly needed. The station 10 may anticipate the need for metadata according to possible recipients. In a basic setup, the station 10 may also use information from and about itself.This information may include, for example, a position, a speed, a vehicle type, current and / or future driving tasks, and / or modes (automation levels). The information may further include environmental conditions such as temperature, light, and weather conditions, and / or design decisions and / or use cases implemented in station 10 to derive or anticipate the requirements of one or more potential recipients of V2X data from station 10 and the requirements that station 10 can fulfill.

[0068] Based on this anticipation, station 10 can define 201 a metadata configuration to be used for future V2X messages sent by station 10. This configuration can be calculated 202 and stored separately for different recipients and for different message types. In steps 205a, 205b, the metadata configuration can be used when sending a message to another station 20, 30.

[0069] Furthermore, station 10 can use the calculated metadata configuration for the message type and the addressed recipient(s) 20, 30 to compile the configured metadata and add it to the V2X message. If multiple metadata configurations are required, i.e., for multiple use cases, message types, or recipients, station 10 can aggregate the metadata configurations before compiling the metadata. Station 10 can then send the entire V2X message 205a, 205b, comprising the usual headers, the payload, and the compiled metadata.

[0070] Fig. 4 shows these second steps with some additions according to embodiments of the invention. On the left side of the flowchart, it is shown that in step 401a, an update is received from other stations 20, 30. Furthermore, in a step 401b, an update of the station 10 itself, which includes the above-mentioned metadata information, can be received. According to a step 410, a map can be used to receive map-related data, as discussed in more detail below. In a step 402, the amount of data and / or metadata is (re)calculated, which can result in a selected amount of data and / or metadata 403. In an optional step 406, triggering and / or retransmission of V2X messages can be performed if data and / or metadata have changed.On the right side of the flowchart, it is shown that a step 401c is performed, according to which a V2X message transmits a request from other stations 20, 30. In a next step 404, data and / or metadata are compiled 403 in accordance with the defined set of data and / or metadata. In a next step 405, the V2X message is sent.

[0071] Fig. 3 shows the embodiment of Fig. 2 with some modifications. Station 10 receives a message from the other stations 20, 30 in step 305a, 305b. The message may be a V2X message. Then, in step 301, 302, an adapted amount of data and / or metadata may be calculated based on the knowledge of the other stations 20, 30 regarding the messages received in step 305a, b and the environment regarding their particular needs. In a further step 310a, 310b, the V2X message may be sent to the receiving stations 20, 30 using the adapted amount of data and / or metadata.

[0072] In one embodiment, station 10 may use information received from other stations 20, 30 via a V2X message, such as, for example, a CAM (Cooperative Awareness Message), a VAM (VRU Awareness Message), a CPM (Collective Perception Message), and / or an MCM (Maneuver Coordination Message). In general, using any V2X message, it may include information about the transmitting stations 20, 30, such as location, behavior, station type, their environments, and / or the road users in those environments. This information may be received and accumulated without requiring a dedicated information exchange for metadata generation.Station 10 can use this received information to learn about the presence of potential receivers or potential receiver stations and, knowing their position, behavior, and driving tasks, improve the anticipation of the receivers' needs. If station 10 sends (back) V2X messages with data and metadata configurations similar to the received message, this can also reflect the needs of the corresponding stations 20, 30.

[0073] In another embodiment, station 10 may use a map, which may be stored in station 10 or connected via a network, to obtain semantic information about an environment, such as road type, intersections, restrictions, driving speeds, connectivity with other roads, traffic lights, lane information, and about a vicinity of possible receiver stations 20, 30. This may help anticipate the driving tasks of receiver stations 20, 30 and decide which data / metadata is necessary for receiver 20, 30. It may make a difference whether a transmitter 10 and a receiver 20, 30 are part of the same environment, for example, whether both are on the same highway, or whether, for example, one is on the highway and the other is in a parking lot.In the same way, stations near or at intersections and the number of stations, which can be additional sources of information, can influence metadata configurations.

[0074] In another embodiment, profiles predefined for relevant functions and use cases can be used to calculate the metadata configuration. The selection of a profile can then be performed using all of the above-mentioned information, e.g., based on the information about possible recipients, e.g., profile definition and selection of a driving scenario, such as approaching or leaving an intersection, turning right or left, or driving straight ahead, and scenario complexity, such as a highway or urban scenario.

[0075] In another embodiment, not only the metadata is configured. Station 10 can eliminate portions of the payload if the metadata configuration indicates low information value for that portion.

[0076] A method according to an embodiment of the invention comprises the following steps. The data included during the generation of a V2X message for transmission can often be a result of a measurement, e.g., a relative distance to a detected object via the vehicle's on-board sensors, or an estimate, e.g., the absolute position of the sender, estimated by its positioning unit. In addition to this data, the sender can add security metadata to the generated message. The metadata can include a confidence description for any measured or estimated data in the V2X message. For each of these values, the standardized V2X messages can typically include a confidence indication representing the estimated absolute accuracy of the value with a default confidence level of 95%.However, this confidence indication may not be sufficient for the receiver to decide whether the V2X data can be used for a road-related function, especially a safety-critical function. An alternative may be to fit a set of measured or estimated values ​​to a probability density function (PDF) using a probability distribution fit. This can be done, for example, during the calibration process of the vehicle's measurement and / or estimation systems. The PDF can be described by indicating the distribution type as metadata in the V2X message and is characterized by its parameterization. In this way, the receiver can gain much better knowledge of the accuracy of the V2X data and can verify whether it meets the requirements of its current road-related function.For example, the receiver may require that a certain position in the V2X data be within a given lane with a minimum probability p. This condition can be verified by evaluating the PDF of the corresponding position in the received V2X data. Furthermore, confidence intervals for parametric PDFs can be calculated.

[0077] In the case where the V2X data can be used for driver assistance or automated driving functions, the recipient may require knowledge of the set of operating conditions under which the system measuring or estimating the transmitted V2X data operates safely. These may include environmental, geographical, and time-of-day constraints, traffic and roadway characteristics, and the vehicle's automation level. The recipient can then verify whether these operating conditions encompass its current driving conditions. In this case, it can use the received V2X data for its road-traffic-related function.

[0078] During the generation of a V2X message, typically not all data measured or estimated by the sender can be included in the V2X message. Instead, the sender can select a subset of this data to be included in the generated message, e.g., using message generation rules. Metadata can be used to describe the completeness of the included data in the V2X message, i.e., the extent of the included data relative to the total amount of data measured or estimated by the sender. The receiver can then check whether the amount of included V2X data exceeds a minimum amount required by the receiver, or whether the included V2X data includes specific data elements or regions required by the receiver.

[0079] Regarding information about the estimated quality of service (QoS) that the receiver can expect from the V2X communication link, metadata can be used to describe a QoS level or the value of one or more QoS metrics.

[0080] A consistency score can indicate the probability that the measured or estimated data is correct. A low consistency score can indicate that the data may represent an erroneous estimate or an invalid measurement, e.g., a perceived, nonexistent (ghost) object. The consistency score can be calculated by estimating the distance between the measured or estimated data and its true value, e.g., from a map, the value of a previous time, or values ​​predicted by a Kalman filter. Algorithms such as deep learning (DL) and machine learning (ML) can also be applied to predict values ​​and calculate data consistency. The receiver can receive the V2X message and interpret its safety metadata to determine suitability for its current road-related function.By processing the metadata, it can determine whether the received V2X data meets the requirements of its current function and can therefore be used as input for that function. Otherwise, the receiver cannot rely solely on the V2X data for its road traffic-related function. The V2X data can still be used, e.g., as a redundancy check in addition to data received from another source.

[0081] Describing confidence values ​​for V2X data may include defining a probability density function type that best fits the distribution of the measured or estimated data. Each distribution type can be defined by a set of statistical parameters that can allow calculating the probability that the real value lies within an arbitrary range of values.

[0082] Some examples of probability density functions can be the following: A normal or Gaussian distribution, characterized by its mean or expected value p and its standard deviation o. A log-normal distribution, characterized by the mean or expected value p and the standard deviation o of the natural logarithm of the variable. A Pareto distribution, characterized by its scaling parameter x. mand its shape parameter a. A continuous uniform or rectangular distribution, characterized by its minimum value A and its maximum value B. A Poisson distribution, characterized by its rate . An exponential distribution, characterized by its rate X. A gamma distribution, characterized by its shape k and its scale 0. A Rayleigh distribution, characterized by its scale 0. A Rice distribution, characterized by its scale o and the distance between its reference point and the centroid of the distribution. The operating conditions of the system that measured or estimated the transmitted V2X data may include environmental, geographical and time of day constraints, traffic and roadway characteristics, and the vehicle's automation level. Some examples of these conditions are the following. The environmental conditions may include weather, e.g., sunny, cloudy, light rain, storm, snow, ice, fog, haze, and lighting, e.g.,minimum and maximum illuminance. Geographical restrictions may include specific regions, such as countries, states, school districts, courtyards, parking lots, and the like.

[0083] Time-of-day restrictions can refer to permitted operating hours, e.g., from 8:00 a.m. to 6:00 p.m., or specific moments, e.g., sunrise, sunset, or night. Traffic characteristics can include traffic density (vehicles / km / lane) and / or vehicle types (cars, trucks / tractors, buses, motorcycles). Roadway characteristics can include roadway types, e.g., street, rural road, highway, divided / undivided road, number of lanes per direction, and road surfaces, e.g., asphalt, concrete, gravel, cobblestone, or off-road. A vehicle's automation level can include, e.g., longitudinal automation, lateral automation, or the level of driving automation according to SAE J3016. Physical infrastructure equipment can include, e.g., traffic lights on a pole / gantry, sensors (video, radar, LiDAR).

[0084] The completeness of measured or estimated V2X data can be described in the following ways. It can be described by a number of measured or estimated elements / objects contained in the message and / or a total number of measured or estimated elements / objects by the sender. It can be described by (a) one or more geographical regions covered by the measured or estimated data contained in the V2X message. It can further be described by (a) one or more geographical regions not covered by the measured or estimated data contained in the V2X message. It can also be described by a ratio between the amount of measured or estimated data contained in the V2X message and the total amount of data measured or estimated by the sender.

[0085] The estimated quality of service (QoS) of a V2X communication connection can be described using the following metrics and mechanisms and included in the metadata of the V2X message.

[0086] A message rate can describe a repetition frequency or frequency range at which the V2X message is transmitted in the case of (semi-)periodic message transmission. A number of repetitions can describe the number of times the message is transmitted (may be undefined for periodic messages that are transmitted indefinitely).

[0087] A message counter can be incremented by one for each transmitted V2X message, allowing the receiver to detect possible message losses. Error detection and / or correction codes can be added to the V2X message to enable the receiver to detect transmission errors, e.g., parity bits, checksum, cyclic redundancy check, cryptographic hash function, or to correct them, e.g., forward error correction, hybrid automatic retry request. The transmitted message can include its measured channel load, e.g., channel occupancy ratio, allowing the receiver to better estimate the current channel state, which can have a direct impact on the expected V2X communication performance. The transmitted message can include its average measured latency, i.e., the time interval between the message generation and the actual transmission of the message.This latency may primarily result from the time the sender needs to buffer the generated message while the V2X channel is detected as busy, e.g., using the CSMA / CA media access control protocol. The receiver may use the measured latency to better estimate the current channel state. The transmitted message may also include its measured channel reliability, e.g., the average packet error rate of received V2X messages, allowing the receiver to better estimate the current channel state. Instead, or additionally, a QoS level, e.g., a value between 0 and 1, may be calculated from one or more of the described metrics and included in the V2X message metadata.

[0088] The consistency value of measured V2X data can be calculated in different ways. If a sensor detects an object outside its detection range, the object may not be present and may have been detected due to a measurement error. In this case, the measured object may have a low (or N u II)

[0089] ) consistency value. If a perceived object is detected by multiple independent sensors and / or also perceived by received V2X data, such as a Cooperative Awareness Message, and is within the perception range of all these sensors, the object may have a high probability of presence. Therefore, the measured object would have a high consistency value. If an object has been perceived for a long time, it may have a high probability of presence, and vice versa. If the data of a perceived object is within a plausible range of values ​​predicted by the Kalman filter, e.g., future position, speed, acceleration data, heading, etc., it may have a high probability of presence, and vice versa.By analyzing data from vehicle sensors and historical records, deep learning (DL) and machine learning (ML) can also be applied to predict values ​​and calculate data consistency.

[0090] Possible prerequisites are described below. At the time of a station's commissioning, its sensors and data fusion systems can be registered with the central registry with metadata describing the quality and conditions of the provided data. Optionally, design assumptions can also be stored in the metadata. For later verification of authenticity, the station's public key 504, 604 can also be included. All data contained in the data set 501 can be signed using a provider's private key, as shown in Fig. 5 and Fig. 6. The signed station metadata set 501 shown in Fig. 5 can include a station model identifier 502, station metadata 503, and a station public key 504.

[0091] Fig. 6 shows a public key infrastructure 605 according to an embodiment in which the public key 601 of a provider can be used to derive the public key 604 of a station.

[0092] In this embodiment shown in Figure 6, the station's public key 604 is not included in the station's metadata set 501. The station's public key 604 is provided using the public key infrastructure 605.

[0093] Figure 7 shows a signed data message 701 from a station 10 according to one embodiment. The signed data message 701 includes sensor data 720 and a model identifier 702. According to this embodiment, the station 10 prepares a data message 701 by obtaining the sensor data 720, appending the station model identifier (model identifier) ​​702, and signs the V2X message 701 using the station's private key.

[0094] Fig. 8 shows a signed data message from the station with metadata according to one embodiment. In this embodiment, in contrast to Fig. 7, the signed data message 801 includes the sensor data 820, the model identifier 802, and additional metadata 810.

[0095] Each station 10, 20, 30 may store a local copy (cache) of the central registry containing all metadata signed using a certificate, so it may not be necessary to exchange data with the central registry for each V2X data transfer. The cache may be updated regularly. The method according to an embodiment of the invention may comprise the following steps, illustrated in Fig. 9. In step 901, a transmitting station 10 may prepare a data message by obtaining the sensor data, appending the station model identifier (model identifier), and then sign the V2X message using the station's private key. In step 902, the transmitting station 10 may distribute the data message via V2X. In step 903, a receiving station 20 may receive the V2X message.In step 904, the receiving station 20 may extract the model identifier of the transmitting station 10 from the received message. In step 905, the receiving station 20 may obtain the model information corresponding to the model identifier from the cached central registry. If the certified trust information corresponding to the transmitting station 10 is not found in the local registry, the receiving station 20 may request a current copy from the central registry. If the receiving station 20 is out of coverage, or if the certificate is not found in the new version of the registry, the receiving station 20 may reject the incoming information. In step 906, the receiving station 20 may verify the model information using the provider's public key (cached or available online).In step 907, if the provider's signature cannot be verified, the received message may be discarded 913. Otherwise, the receiving station 20 can reliably learn the provider of the transmitting station 10. Therefore, the receiving station 20 can reliably obtain the correct public key for the transmitting station 10. In step 908, additionally, while verifying the signature of the model information, the receiving station 20 can check the correctness and completeness of the content. If the model information is incomplete, modified, or incorrect, the received data message may be discarded 913. In step 909, the receiving station 20 may have the correct model information for the model of the transmitting station 10. Using the station's public key of the transmitting station 10, the receiving station 20 can verify the received data message.In step 910, if the signature of the transmitting station 10 could not be verified, the received message may be discarded 913. Otherwise, the receiving station 20 can reliably know the transmitting station 10. Therefore, the receiving station 20 can reliably obtain the correct public key for the transmitting station 10. In step 911, additionally, while verifying the signature of the data message, the receiving station 20 can check the correctness and completeness of the content. If the data message is incomplete, altered, or incorrect, the received data message may be discarded 913. In step 912, the receiving station 20 can now reliably learn that the transmitting station 10 has sent the data, that the data message is complete and correct, and that the receiving station 20 has the correct station metadata of the transmitting station 10.The receiving station 20 can now use the data and validate the possible use of the received data using the station metadata of the transmitting station 10 and the safety requirements of the dedicated safety-critical function.

[0096] In another embodiment, the metadata may refer to different levels of aggregation, for example, point clouds and / or perceived objects.

[0097] In another embodiment, there may be an additional step to check the age of the certificate and discard the associated data if the certificate is too old. The age of the information may correspond to the time since the certificate was issued.

[0098] In another embodiment, the certificate may refer to a public or private key that allows the station to sign and encrypt the data, in addition to certifying the quality of the data sent.

[0099] In another embodiment, the data message 801 contains additional, e.g., spatial or scene-dependent, metadata, which is shown in Fig. 8. In another embodiment, the station model identifier may point to a lookup table where multiple individual metadata about, e.g., sensors, fusion components, hardware information, software information may be stored separately.

[0100] In another embodiment, the model identifier may correspond to the vehicle identification number (VIN).

[0101] In another embodiment, a different approach to authenticating and signing messages may be used, such as group keys.

[0102] In another embodiment, if it is not practical to keep all station models worldwide in the registry's local cache, only a subset of registered models can be cached locally, such as the registered models in a region (e.g., EU).

[0103] A method according to embodiments of the invention is illustrated in Fig. 10 and may comprise the following steps. In step 1001, a first station 20 may distribute its requests for V2X information that allows it to operate its function in a functional safety compliant manner. A second station 10 may receive the requests from the first station 20. In step 1002, the second station 10 may decide, based on an examination of the received requests, whether it conforms to the requested requirements and abort if this is not the case. In step 1003, the second station 10 may compile or provide the information according to the requirements based on a decision. In a further optional step, the second station 10 may add a flag to the information to indicate that it meets the requirements (not shown).In step 1005, the second station 10 may transmit the compiled information to the first station 20.

[0104] The first station 20 can receive the information from the second station 20, check whether the information meets its requirements, and, if so, forward the information to its function. Furthermore, the requirements sent by the first station 20 and checked by the second station 10 can include the following elements. One element can be ODD (Operational Design Domain), which can describe operating conditions such as road types, speeds, weather conditions, and / or relevant road users. Another element can be functional requirements (e.g., accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, dimension, angle, object type, trajectory), accuracy of the time source (e.g., GPS time, network time protocol), [min, max] vehicle speed).Another element may be Quality of Service (QoS) requirements (e.g., payload in [min, max] bytes, maximum tolerable delay or data age in [min, max] ms, data rate in [min, max] Mbps). Another element may be required redundancy levels (e.g., information update rate, minimum number of uncorrelated information sources). Another element may be safety levels and qualifications (e.g., Automotive Safety Integrity Level (ASIL) for the system design of the transmitter). Another element may be allowed failure and degradation modes (e.g., a capability to detect sensing degradation, such as sensor blindness, decalibration, or misalignment). A requirement may include degraded limitations (e.g., a reduced sensing range due to adverse weather conditions).

[0105] According to an example illustrated in Fig. 11, a vehicle 20 (in this example, the second station) is given on which a function can be performed that requires an environmental model that follows specific requirements regarding the content of the environmental model. The specific requirements may include the following aspects. A bounding box of the surrounding vehicles may be within 100 m of the station and within 10 m of a road. A position of the center of gravity of the surrounding vehicles may be within 100 m of the station and within 10 m of a road with an accuracy of 2 m in a specific projection and coordinate reference system. A position of the surrounding vulnerable user may be within 100 m of the station and within 10 m of a road with an accuracy of 50 cm in a specific projection and reference system.Vegetation can be viewed as points, and buildings can be viewed as polygons. At a station 10, a smart traffic light in the embodiment of Fig. 11, a function can be executed that creates an environmental model from many sources and is capable of providing a wide range of information with different granularity and performing the following operations. One operation can be LiDAR point cloud acquisition. Another operation can be image acquisition from front, rear, and side cameras. Another operation can be radar measurements. Another operation can be data fusion of sensor measurements and perceived objects. Another operation can be object detection and classification. Another operation can be layer creation. Another operation can be projection into different coordinate systems.

[0106] In step 1101 of the embodiment of Fig. 11, the vehicle 20 may send its requests to the station 10, which may be able to fulfill the request and format the information in step 1104 in a manner that satisfies all of the vehicle 20's requirements. In step 1105, the formatted information may be transmitted to the vehicle 20. There may also be a channel utilization advantage over sending only raw data.

[0107] According to another embodiment, illustrated in Fig. 12, a first vehicle 20 may send its requests in step 1201a. A station 10 may receive these requests in step 1202, examine the requests, and decide to fulfill the requests. The station 20 may format the data in step 1203 and send it to the vehicle 20 according to the requests in a further step 1210a. Later, a second vehicle 30 may send its requests in step 1201b. The station 10 may compare both the requests of the first and the second vehicle in step 1202' and determine that the requests of the first vehicle 20 are included in the requests of the second vehicle 30. The station 10 may decide to fulfill the requests of the second vehicle 30 in step 1203' and format the data according to the requirements of the second vehicle 30.Station 10 can then, in step 1210a, 1210b, send the formatted data to first vehicle 20 and second vehicle 30. Since the requirements of first vehicle 20 are included in the requirements of second vehicle 30, the function of first vehicle 20 can use the data even though it meets the requirements of second vehicle 30.

[0108] According to one embodiment (not shown), a first vehicle can send its requirements R1, and a second vehicle can send its requirements R2. A third vehicle can receive both requirements R1 and R2, examine them, and decide to satisfy both R1 and R2. To avoid sending two sets of data (one that satisfies R1 and one that satisfies R2), the third vehicle can calculate the minimum set of requirements R3 that satisfies both R1 and R2. If the third vehicle can satisfy requirements R3, it can format and send the data accordingly. The first vehicle and the third vehicle can receive the V2X data and use it for their road-related functions, since they can satisfy both requirements. If the third vehicle cannot satisfy requirements R3 but can satisfy R1 and / or R2, it can format and send the data according to R1 and / or R2.

[0109] Instead of aborting, a second station, if it cannot fulfill the requirements, can alternatively send a rejection message to inform the first station. Whether the second station rejects silently or with a rejection message may depend on a given use case.

[0110] The transmitting station 20 may send more than one set of requests (optionally in a prioritized list) if there are different possibilities or trade-offs for fulfilling the function. The receiving station 10 may then check whether one or another set of requests can be satisfied, increasing the chance that at least one set of requests will be satisfied. If the list of request sets is prioritized, station 10 may check the request sets from highest to lowest priority to find the set of requests with the highest priority that can be satisfied. Station 10 may then satisfy the requests of station 20 if at least one set of requests from station 20 can be satisfied by station 10.

[0111] The transmitting station 20 can identify each set of requirements with a unique label before sending it. If the receiving station 10 can satisfy one or more sets of requirements, the receiving station 10 can include the unique labels of the satisfied request sets in the message for the transmitting station 20. When the transmitting station 20 receives the information from the receiving station 10, the included labels can help the transmitting station 20 verify which requirements are satisfied. The transmitting station 20 can forward the information and the label of the satisfied requirements to the function.

[0112] A method according to an embodiment of the invention is shown in Fig. 13 and comprises the following steps. In step 1302, a station 20 may transmit the identification of its current road traffic-related function. In step 1303a, a station 10 may receive the function identification and match it with the corresponding requirements in its internal database. In step 1303b, the station 10 may decide whether it is able to provide V2X data according to the requested requirements and abort if this is not the case. In step 1304, the station 10 may provide the data according to the requirements of the station 20 and transmit the information to the station 20 together with the function identification received from the station 20 in conjunction with the set of requirements according to step 1305.In step 1306, station 20 may receive the data and the function identification from station 10, check whether its requirements are met, and, if so, forward the information to its current road traffic-related function. Fig. 14 shows another embodiment of a method according to the invention, comprising the following steps: In step 1402, station 20 may transmit the identification of its current road traffic-related function and a database version. In step 1403a, station 10 may receive the function identification and check the database version. In step 1403b, station 10 may match the function identification with the corresponding requirements in its internal database. In a further step 1403c, station 10 may decide whether it is able to provide V2X data according to the requested requirements and abort if this is not the case.In step 1404, station 10 may provide the data according to the requirements of station 20 and transmit the information to station 20 along with the function identification received from station 20 in conjunction with the set of requirements according to step 1405. In step 1406, station 20 may receive the data and the function identification from station 10, check whether its requirements are met, and, if so, forward the information to its current road traffic-related function.

[0113] Fig. 15 shows another embodiment of a method according to the invention, comprising the following steps. In step 1502, a station 20 can distribute the identification of its current road traffic-related function with further options. In step 1503a, a station 10 can receive the function identification and, taking into account the provided options, match it with the corresponding requirements in its internal database. In step 1503b, the station 10 can decide whether it is able to provide V2X data according to the requested requirements and abort if this is not the case. In step 1504, the station 10 can provide the data according to the requirements of the station 20 and transmit the information to the station 20 together with the function identification received from the station 20 in conjunction with the set of requirements according to step 1505.In step 1506, station 20 may receive the data and function identification from station 10, check whether its requirements are met, and, if so, forward the information to its current road traffic-related function. The requirements may be based on a public standard and may, for example, be stored in a database responsible for managing and accessing the requirement information. This database may, for example, be in station 10, 20 and / or in a central server. The requirements associated with the function identification in the database may include the following: A requirement may concern ODD (Operational Design Domain), which may describe operating conditions such as road types, speeds, weather conditions, and / or relevant road users.A further requirement may concern functional requirements (e.g., accuracy of measured or estimated values ​​(e.g., position, velocity, acceleration, yaw rate, dimension, angle, object type, trajectory), accuracy of the time source (e.g., GPS time, network time protocol), [min, max], or vehicle speed). A further requirement may concern Quality of Service (QoS) requirements (e.g., payload in [min, max] bytes, maximum tolerable delay or data age in [min, max] ms, data rate in [min, max] Mbps). A further requirement may concern required redundancy levels (e.g., information update rate, minimum number of uncorrelated information sources). A further requirement may concern safety levels and qualifications (e.g., an automotive safety integrity level (ASIL) for the system development of the transmitter).A further requirement may concern permissible failure and degradation modes (e.g., an ability to detect sensing degradation such as sensor blindness, decalibration, or misalignment. Requirements in this context may include degraded limitations (e.g., a reduced sensing range due to adverse weather conditions)).

[0114] The identification of the function can be an alphanumeric identifier.

[0115] A first example can be given in connection with Fig. 16, with a vehicle 20 on which an automated driving function is performed, which requires an environment-related model to follow specific requirements regarding its content. One specific requirement can be a bounding box of the surrounding vehicles within 100 m of the station and within 10 m of a road. Another specific requirement can describe a position of the center of gravity of the surrounding vehicles within 100 m of the station and within 10 m of a road with an accuracy of 2 m in a specific projection and coordinate reference system. Another specific requirement can describe a position of the surrounding vulnerable user within 100 m of the station and within 10 m of a road with an accuracy of 50 cm in a specific projection and reference system.According to a further specific requirement, vegetation can be described as a point and buildings as polygons. On an entity 10, for example, a smart traffic light in the illustration of Fig. 16, a function can be executed that creates HD maps from many sources and can be capable of providing a wide range of information with different granularity and performing the following operations. One operation can be LiDAR point cloud acquisition. Another operation can be image acquisition from front, rear, and side cameras. Another operation can be radar measurements. Another operation can be data fusion of sensor measurements and perceived objects. Another operation can be object detection and classification. Another operation can be layer creation.Another operation can be a projection into different coordinate systems.

[0116] According to the embodiment shown in Fig. 16, in step 1602, the vehicle 20 may transmit a functional identifier to the entity 10, for example, a smart traffic light. In step 1603, the entity 10 may check a database. In step 1604, the entity 10 formats its data to meet the requirements of the vehicle 20. In step 1605, the entity 10 sends the formatted data to the vehicle 20. In particular, Fig. 16 shows an example of a vehicle 20 sending its functional identifier to a smart traffic light 10, which may format its environment-related model data to meet the requirements of the vehicle 20 and send a formatted environment-related model to the vehicle 10.

[0117] A public or published standard that can be implemented if the database collects all requirements, specifically mapping the function to its requirement. The following is an example excerpt from the database:

[0118] RD / 83, ETRS89, and 42 / 83 may be three German reference standards that can be used. Vehicle 20 can only send AD80, an exemplary function, which may be an autonomous driving version 80, as its function identifier. Upon receiving this identifier, entity 10 can query the database for the requirements and verify the requirements. Entity 10 may be able to fulfill the requirements and compile the information for vehicle 20. Figure 16 illustrates this example.

[0119] In another embodiment, the public standard may list multiple options for each function in the database. In step 1502, the reference to the option may be distributed along with the identification, according to the embodiment illustrated in Figure 15. Multiple options may be selected by the vehicle 20, either as a combination (AND) or a selection (OR). When the entity 10 receives options as a selection (OR), it may select a requirement set and continue the process with that set. Preferably, the options are labeled, which may allow the entity 10 to indicate which requirements it meets when the qualifying information is sent to the vehicle 20.

[0120] In another example, each function can have options, as shown in the following sample database extract.

[0121] The function of vehicle 20 may require RD / 83 as the reference standard. As a result, vehicle 20 may transmit Option 1 along with its identifier in the first step 1502, as shown in Fig. 15.

[0122] In another embodiment, there may be no request from a first station 20. Entity 10 may select the set of requests in the database that matches its data and may then distribute the identifier referencing this set of requests in the database along with the data. A potential receiver may then be able to decide whether the requests are satisfied by entity 10 and referenced in the V2X message to satisfy its own responses, and whether the data can then be used. In another embodiment, the standardized requests may not be associated with a function identification, but have unique identifications for each request. Stations may cherry-pick their requests from the database and then reference sets of individual requests in their transmission, with or without requests.

[0123] In a situation similar to the one described above, stations can pick out individual requirements, as shown in the sample database extract below.

[0124] For example, the vehicle's function may require 20 RD / 83 as the gravity reference standard, and the ego vehicle's speed may need to be between 20 and 130 km / h. As a result, it can select request identifications 4, 13, and 14 and send them via V2X communication.

[0125] In another embodiment, the identification can be sent along with a version number of the database to which it refers. This can ensure compatibility between the stations' databases. This is shown in Fig. 14.

[0126] Receiving station 10 may have last been updated in 2020, while transmitting station 20 may have last been updated in 2023. Version 17.2 of the standard may have been released in 2020. A new version 18 may have been released in 2023.

[0127] The transmitting station 20 can therefore refer to version 18 when distributing its functional identifier. The receiving station 10 can receive this identifier along with the version in use and determine that the versions are incompatible. It can therefore abort the process.

[0128] An alternative may be to respond with the version of receiving station 10, allowing transmitting station 20 to analyze whether it would be able to accept the requests stored in the lower version (17.2) in our example. The process can then continue with the lower database version.

[0129] The above explanation of the embodiments describes the present invention in the context of examples. Of course, individual features of the embodiments can be freely combined with each other, provided this is technically feasible, without departing from the scope of the present invention.

Claims

Claims 1 . A method (100) for determining the usability of data for a road traffic-related function, comprising the following steps: Receiving (101), at a station (10), a message for the road traffic-related function of the station, the message comprising data and metadata, the metadata comprising information about the data relating to the road traffic-related function, analyzing (102) the data for the road traffic-related function based on an evaluation of the metadata, wherein the evaluation comprises a check as to whether the received data of the message fulfills at least one requirement of the road traffic-related function, Determining (103) the usability of the data for the road traffic-related function based on the analysis (102).

2. The method (100) according to claim 1, characterized in that the metadata comprises a confidence description for the data, which indicates a confidence indication for the accuracy of the data and / or indicates a probability density function, comprising a best distribution type for tuning the distribution of the received data.

3. Method (100) according to claim 2, characterized in that the method comprises the following further step during the analysis (102): Matching the confidence description of the data with a probability density function using a probability distribution fitting, where the information provided by the metadata specifies a distribution type and a parameterization of the probability density function.

4. The method (100) according to claim 3, characterized in that the distribution type is defined by a set of statistical parameters, which makes it possible to calculate the probability that a real value of the data lies within an arbitrary range of data.

5. Method (100) according to one of the preceding claims, characterized in that the metadata comprise at least one of the following information for the road traffic-related function: information regarding an operating condition of a station (20) that transmitted the message, a level of data completeness of the received data in relation to the total amount of measured and / or estimated data by the station (20) that transmitted the message, a quality of service level for a communication link between at least two stations (10, 20), wherein the quality of service level relates to a property of the communication link, a data consistency value of the received data, wherein the value indicates a degree of reliability and / or probability of presence of the measured and / or estimated values of the received data contained in the message.

6. Method (100) according to one of the preceding claims, characterized in that during the analysis (102) the evaluation further comprises a check as to the extent to which the received data can be used in the road traffic-related function, the method (100) comprising the following further step: Initiating the use of the received data in the road traffic-related function based on the result of determining (103) the usability.

7. Method (100) according to one of the preceding claims, characterized in that the function of the station related to road traffic is a driving function and / or an automated driving function and / or a driver assistance function and / or a traffic management function and / or a cyclist support function and / or a pedestrian support function.

8. Method (100) according to one of the preceding claims, characterized in that the method (100) comprises the following further step during the analysis (102): Analyzing the data for the road traffic-related function based on an evaluation of the metadata, wherein the evaluation includes a check whether the received data can be used for a safety-critical scenario.

9. Station (10) for determining a usability of data for a road traffic-related function, the station comprising means for carrying out the method (100) according to any one of the preceding claims.

10. A computer program (50) comprising instructions which, when the computer program (50) is executed by a computer (11) of a station (10), cause the computer (11) to carry out the method (100) according to any one of claims 1 to 8.

11. A computer-readable storage medium (15) comprising instructions which, when executed by a computer (11) of a station (10), cause the computer (11) to perform the steps of the method (100) according to any one of claims 1 to 8.

Images