Method for determining need for message content for station

Abstract

The invention relates to a method (100) for a sending station for determining a need for message content, comprising the following steps:-determining (101) an expected need for message content according to one or more recipient stations, the expected need for message content being based on the need of the sending station; -calculating (102) at least one metadata configuration of the message content based on the determination (101) of an expected need for the message content,-augmenting (103) the message content based on the calculated (102, 202, 302) at least one metadata configuration, 30) and / or in accordance with the type of the message to be sent, specifying in which way the message content is adapted.

Description

Technical Field

[0001] The invention relates to a method for a station for determining a need for message content. Furthermore, the invention relates to a station, a computer program and a storage medium for this purpose. Background Art

[0002] The structure of vehicle-to-everything (V2X) messages is determined by standards development organizations (SDOs) including the European Telecommunications Standards Institute (ETSI) or SAE International. Certain V2X messages, such as cooperative awareness messages (CAM, ETSI), VRU awareness messages (VAM, ETSI), collective awareness messages (CPM, ETSI), or basic safety messages (BSM, SAE), have been standardized.

[0003] Currently, V2X data can often be derived from crowdsourced information. The driver still remains responsible for responding to V2X information, determining the necessity of action, such as, for example, gradually slowing down based on a collision warning. Due to the lack of robust safety properties, vehicles may not directly use V2X data for safety-critical driving actions, such as initiating sudden braking (automatic emergency braking, AEB) or steering maneuvers.

[0004] The development of safe cooperative automated driving (CAD) systems is centered around creating comprehensive systems where safety is embedded in the overall design. The system may appear as a safe "closed world" environment where both sender and receiver adhere to the same safety concepts and homology. It may be customized to specific use cases. An example of such a system is automated valet parking (AVP), which may currently be in the standardization stage at ETSI. The downside is that every time a new vehicle is designed, a completely new homology may be required for all conceivable AVP garage / vehicle pairings to ensure safety across all possible combinations.

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

[0006] WO2022 / 122450A1 describes including a "safety section" in a V2X message to make it available for safety-related driving functions. The safety section may include a safety level, a failure rate, an indication of the development process, a validity period, an error model and / or a confidence level for the V2X data.

[0007] US20230059220A1 describes a method for verifying a received V2X message by comparing the data of the received V2X message with the same data from another source (e.g., objects detected by onboard sensors, plausibility of sender location and RSSI, previous V2X messages). Summary of the invention

[0008] The above objects are solved by a method having the features of claim 1, a station having the features of claim 8, a computer program having the features of claim 9 and a computer-readable storage medium having the features of claim 10. Further features and details of the invention are disclosed in the respective dependent claims, the description and the drawings. Features and details described in conjunction with the method of the invention also apply to the station of the invention, the computer program of the invention and the computer-readable storage medium, and vice versa in each case, so that with regard to the disclosure relating to the various aspects of the invention, reference is always made to each other.

[0009] The object is solved in particular by a method for a sending station for determining a need for message content, the method comprising the following steps:

[0010] - determining expected needs for message content according to one or more recipient stations, wherein the expected needs regarding message content are based on needs of the sending station,

[0011] - calculating at least one metadata configuration of the message content based on the determination of the expected need of the message content,

[0012] - augmenting the message content based on at least one calculated metadata configuration, wherein the metadata configuration specifies the way in which the message content is to be adapted depending on one or more recipient stations and / or depending on the type of message to be sent.

[0013] This allows advantageously to improve a more efficient interpretation of the received data, which thus prevents potentially leading to dangers, for example in connection with safety-critical scenarios in traffic. Furthermore, this has the advantage that the method of the invention can allow faster decisions to be made at runtime, such as whether the data meets the requirements of the receiver station or the receiver, and furthermore, whether the received data is qualified for road traffic related functions. Furthermore, the method of the invention can improve existing road traffic related applications, for example with regard to traffic safety, driver assistance and / or autonomous driving applications. In this context, an anticipated need may be understood as a foreseeable requirement or necessity of a potential recipient based on requirements or situations related to vehicle movement and / or transport infrastructure and / or pedestrian movement.

[0014] Possibly, the method further comprises the following steps:

[0015] - aggregating said at least one metadata configuration according to one or more recipient stations and / or according to use cases, wherein said use cases define scenarios relevant to said stations, wherein said scenarios include sequences of actions and interactions that occur between said stations and a system to complete a task,

[0016] - assemble metadata based on the aggregated metadata configuration, and

[0017] - Sending a message content comprising at least the assembled metadata and / or payload data.

[0018] This allows for significant improvements in relation to the interpretation and / or analysis of information received from potential recipient stations.

[0019] It is also possible that, during the determination, the method comprises at least one of the following further steps:

[0020] - determining an expected need for message content according to one or more recipient stations, wherein the expected need for message content is based on information about the one or more recipient stations,

[0021] - determining expected needs for message content according to one or more recipient stations, wherein the expected needs according to one or more recipient stations are based on semantic information from the context of the sending station and / or from the context of one or more recipient stations, which is based on a map.

[0022] This has the advantage that the transmission or sending of the relevant data to the recipient station can be significantly improved with respect to its reliability, quality and / or accuracy. This allows advantageously anticipating, for example, the driving task of the station and deciding which data / metadata are necessary for the recipient. In other words: this may make a big difference if the sender and the receiver are part of the same environment, e.g. both are on the same highway, or one is on the highway and the other in a parking lot. Furthermore, this allows an improved anticipation of the needs of the recipient based on knowledge of the recipient's location, behavior and driving task.

[0023] Possibly, the method further comprises the following steps:

[0024] - generating a profile for said at least one metadata configuration,

[0025] - Selecting a profile based on requirements of the message content related to the sending station and / or based on information from one or more recipient stations and / or from the environment of one or more other stations, which is based on a map, wherein the profile specifies predefined functions of the station and / or predefined use cases of the station.

[0026] This allows for faster and better use of metadata configuration for more customized utilization of the recipient's data.

[0027] It is conceivable that the method further comprises the following steps:

[0028] - eliminating at least a portion of the payload data based on the calculated at least one metadata configuration, wherein the calculated at least one metadata configuration indicates a low information value of the payload data.

[0029] This allows for more efficient and faster sending of message content based on the adapted payload.

[0030] Possibly, the method further comprises the following steps:

[0031] - Storing at least one metadata configuration according to one or more recipient stations and / or according to the type of message to be sent.

[0032] The benefit is that storing different metadata configurations can adapt to different requirements and conditions without the need for frequent modification or adjustment. By maintaining different metadata configurations, specific settings can be easily accessed and applied as needed, facilitating efficient adaptation to different scenarios. In addition, this allows for enhanced flexibility and enables rapid response to changing situations while maintaining precision and consistency in operation.

[0033] It is also possible that the message type is a vehicle-to-everything message.

[0034] The utilization of vehicle-to-everything (V2X) messaging allows for facilitating comprehensive and accurate communications within the context of road traffic.

[0035] V2X messages can enable seamless communication between vehicles, infrastructure, pedestrians, and other elements within the traffic environment. Furthermore, this allows for improved situational awareness and safety. Furthermore, the use of V2X messages advantageously provides real-time data on traffic conditions, road hazards, weather, and other relevant factors, allowing vehicles to make informed decisions quickly. Furthermore, V2X messages can improve the performance of advanced driver assistance systems (ADAS) and / or autonomous driving capabilities. This means that V2X messages can advantageously warn drivers of potential collisions, thereby reducing accidents and improving road safety.

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

[0037] In another aspect of the invention, a station may be provided, which is configured to perform a method according to the invention. For example, as a station, a device like a computer may be provided, which executes a computer program according to the invention. The computer may include 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 the processor may read the computer program for execution.

[0038] According to another aspect of the invention, a computer-readable storage medium may be provided, comprising a computer program and / or instructions according to the invention, which, when executed by a computer of a station, causes the computer to perform the steps of the method according to the invention. The storage medium may be formed 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. For example, the storage medium may be integrated into the computer of the station.

[0039] Furthermore, the method according to the present invention may be realized as a computer-implemented method. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] 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 accompanying 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. It is shown that:

[0041] Figure 1 : According to the method, computer program, storage medium and device of the embodiments of the present invention,

[0042] Figure 2 : According to the method of an embodiment of the present invention,

[0043] Figure 3 : A message flow and an adaptation method of a data / metadata set according to an embodiment of the present invention,

[0044] Figure 4 : A method for calculating a data / metadata set and using an updated set according to an embodiment of the present invention,

[0045] Figure 5 : A signature station metadata set according to an embodiment of the present invention,

[0046] Figure 6 : According to the public key infrastructure of the embodiment of the present invention,

[0047] Figure 7 : A signed TX station data message according to an embodiment of the present invention,

[0048] Figure 8: A signed TX station data message with metadata according to an embodiment of the present invention,

[0049] Fig. 9 : A flowchart of a verification sequence according to an embodiment of the present invention,

[0050] Fig.10 : A sequence diagram of a method according to an embodiment of the present invention,

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

[0052] Fig.12 : A method with a station and two vehicles according to an embodiment of the present invention,

[0053] Fig.13 : A sequence diagram of a method according to an embodiment of the present invention,

[0054] Fig.14 : A sequence diagram of a method with database version checking according to an embodiment of the present invention,

[0055] Fig.15 : A sequence diagram of a method in which options are provided according to an embodiment of the present invention,

[0056] Fig.16 : A method with a vehicle and an intelligent traffic light according to an embodiment of the present invention. DETAILED DESCRIPTION

[0057] V2X communication may stand for "vehicle to everything" communication. It is, in particular, a technical framework that enables communication between vehicles and various elements of the transportation ecosystem, including other vehicles (V2V), infrastructure (V2I), pedestrians (V2P), cyclists (V2C), etc. One goal of V2X communication may be to improve road safety, traffic efficiency, and overall transportation system efficiency by allowing vehicles and other entities to exchange information in real time. The technology can be applied to advanced driver assistance systems (ADAS), autonomous driving, traffic management, and various other aspects of modern transportation. Sending V2X messages via V2X communication may facilitate information exchange between vehicles and / or infrastructure components and / or pedestrians. The message exchange can also enhance the operational capabilities of current road traffic-related applications, aiming to improve traffic safety, efficiency, and driver comfort, and enhance the reliability of existing driver assistance and autonomous driving applications. The examples shown include cooperative automatic cruise control (C-ACC) and V2X-linked collision warnings (e.g., due to upcoming traffic jams or pedestrians crossing the road).

[0058] Metadata can refer to data that provides information about other data. It can describe various properties of raw data, such as its source, format, creation date, authorship, and other relevant details. Metadata can help organize, understand, and manage raw data, whether it is documents, images, videos, 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 feature or quality of something. It can also be used in the context of linguistics or programming, where it represents a description or identifier of a specific entity or concept. In summary, while both metadata and descriptors involve descriptions and information, metadata specifically refers to information about other data, while descriptors generally refer to labels or terms used to describe a specific aspect or quality of something.

[0059] Payload data can refer to the necessary information or content conveyed within a packet or message. It represents the actual data that carries meaning or value, as distinct from any attached metadata or control information.

[0060] Road traffic related functions are defined as specific operations or tasks directly associated with traffic flow and / or management on roads. The functions may include data and information exchange between vehicles (V2V), infrastructure (V2I) or pedestrians (V2P) to facilitate real-time communication to improve road safety, traffic efficiency and / or overall transportation efficiency. In certain road traffic scenarios, road traffic related functions may be related to safety-critical scenarios, such as emergency braking scenarios or avoidance maneuvers or collision warning scenarios.

[0061] Figure 1 A method, a computer program, a storage medium and a station according to embodiments of the invention are described. Figure 1 A method 100 for determining a need for message content is shown for a sending station 10. The method 100 comprises the following steps:

[0062] In step 101, an expected need for message content according to one or more recipient stations 20, 30 is determined. The expected need regarding the message content is based on the needs of the sending station 10. In step 102, based on the determination step 101 of the message content, at least one metadata configuration of the message content is calculated. Then, in step 103, the message content is augmented based on the at least one metadata configuration calculated 102. The metadata configuration specifies in which way the message content is to be adapted according to one or more recipient stations 20, 30 and / or according to the type of message to be sent.

[0063] In another embodiment ( Figure 1 ), the expectations required can be based on a set of recipients, such as the number of recipients, vehicle types, manufacturers, traffic behavior, separation of traffic flows, map information, and / or possible use cases.

[0064] Figure 1 Also shown is 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.

[0065] according to Figure 2 In the illustrated embodiment, the station 10 may perform the following steps. In step 202, a metadata configuration may be calculated based on the expected needs determined in step 201. The calculation may be done at any time before sending a message requiring metadata. It may be run periodically, when any new information affecting the metadata selection is available from the station 10 itself or received from elsewhere, or when a message is started and metadata configuration is indeed needed. The station 10 may anticipate the need for metadata based on possible recipients. In a basic setting, the station 10 may also use information from and about itself. This information may include, for example, location, speed, vehicle type, current and / or upcoming driving tasks, and / or mode (automation level). This information may also include environmental conditions, such as temperature, light and weather conditions and / or design decisions or use cases implemented in the station 10 to derive or anticipate what requirements one or more possible recipients of the station 10's V2X data may have and what requirements the station 10 may meet.

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

[0067] Furthermore, the station 10 may assemble the configured metadata using the metadata configuration calculated for the message type and the addressed recipient(s) 20, 30 and add it to the V2X message. If multiple metadata configurations are required, i.e., for multiple use cases, message types, or recipients, the station 10 may aggregate the metadata configurations before assembling the metadata. The station 10 may then send 205a, 205b the entire V2X message, which includes the usual header, payload data, and the assembled metadata.

[0068] Figure 4These two steps and some additions according to an embodiment of the present invention are shown. On the left side of the flowchart, it is described that in step 401a, updates are received from other stations 20, 30. In addition, in step 401b, updates of the station 10 itself including the above-mentioned metadata information can be received. According to step 410, the map can be used to receive map-related data, which will be discussed in more detail below. In step 402, a set of data and / or metadata is (re)calculated, which can produce a selected set 403 of data and / or metadata. In optional step 406, if the data and / or metadata have changed, triggering and / or retransmission of a V2X message can be performed. On the right side of the flowchart, it is described to perform step 401c, according to which a V2X message sends a request from the other stations 20, 30. In a next step 404, the data and / or metadata are assembled according to the defined set 403 of data and / or metadata. In a next step 405, a V2X message is sent.

[0069] Figure 3 shows a Figure 2 Embodiment. The station 10 receives a message from other stations 20, 30 in steps 305a, 305b. The message may be a V2X message. Then, in steps 301, 302, an adapted set of data and / or metadata may be calculated based on knowledge about other stations 20, 30 regarding the messages received in steps 305a, b and regarding the environment in which they determine the need. In further steps 310a, 310b, the V2X message may be sent to the receiving station 20, 30 using the adapted set of data and / or metadata.

[0070] In one embodiment, the station 10 may use information received from other stations 20, 30 via V2X messages such as, for example, cooperative awareness messages (CAMs), VRU awareness messages (VAMs), collective awareness messages (CPMs), and / or maneuver coordination messages (MCMs). In general, any V2X message that includes information about the sending station 20, 30, such as, for example, location, behavior, station type, their environment, and / or traffic participants in these environments, is used. This information may be received and accumulated without a dedicated information exchange for metadata generation. The station 10 may use this received information to learn about the presence of potential recipients or potential recipient stations and improve anticipation of the recipient's needs, thereby knowing their location, behavior, and driving tasks. If the station 10 sends (back) a V2X message with a data and metadata configuration similar to the received message, it may also reflect the needs of the corresponding station 20, 30.

[0071] In another embodiment, the station 10 may use a map that may be stored in the station 10 or connected via a network to have semantic information about the environment, such as road types, intersections, restrictions, driving speeds, connectivity to other roads, traffic lights, lane information, and information about the environment of the possible receiver stations 20, 30. This may help to anticipate the driving tasks of the receiver stations 20, 30 and decide which data / metadata the receiver 20, 30 needs. This may be different if the sender 10 and the receiver 20, 30 are part of the same environment, such as if both are on the same highway, or for example one is on the highway and the other is in a parking lot. In the same way, the number of stations near or on the intersection and which stations may be a source of further information may affect the metadata configuration.

[0072] In another embodiment, to calculate the metadata configuration, predefined profiles for relevant functions and use cases can be used. All the information mentioned above can then be used to make the selection of the profile, for example, based on information about possible recipients, such as profile definitions and selections about driving scenarios, such as approaching or leaving an intersection, right or left turn or straight ahead, scenario complexity, such as highway or city scenarios.

[0073] In another embodiment, not only metadata is configured. If the metadata configuration of the payload data portion indicates a low information value, the station 10 may eliminate the data portion.

[0074] The method according to an embodiment of the present invention comprises the following steps. The data included during the generation of a V2X message for transmission may typically be the result of a measurement (e.g., the relative distance to an object detected via an onboard sensor of a vehicle), or the result of an estimation (e.g., the absolute position of the sender estimated by its positioning unit). In addition to this data, the sender may add security metadata to the generated message. The metadata may include a description of the confidence level of each measurement or estimation data in the V2X message. For each of these values, a standardized V2X message may typically include a confidence indication, indicating the estimated absolute accuracy of the value with a default confidence level of 95%. However, this confidence indication may not be sufficient for the recipient to decide whether the V2X data can be used for road traffic-related functions, in particular safety-critical driving functions. An alternative may be to match a series of measurements or estimates to a probability density function (PDF) by probability distribution fitting. This can be done, for example, during a calibration process of a vehicle measurement and / or estimation system. In a V2X message, the PDF may be described as metadata, which is characterized by indicating the type of distribution and parameterizing it. In this way, the receiver can better understand the accuracy of the V2X data and check whether it meets the requirements of its current driving function. For example, the receiver may require that a certain position in the V2X data is within a given lane with probability at least p. This condition can be checked by evaluating the PDF of the corresponding position in the received V2X data. Furthermore, confidence intervals can be calculated for the parameterized PDF.

[0075] If the V2X data can be used for driver assistance or automated driving functions, the recipient may require knowledge of a set of operating conditions for safe operation of the system that measures or estimates the transmitted V2X data. These may include environmental, geographic and time constraints, traffic and road characteristics, and vehicle automation levels. The recipient can then check whether these operating conditions include its current driving conditions. In this case, it can use the received V2X data for its driving functions.

[0076] During the generation of a V2X message, not all data measured or estimated by the transmitter is typically included in the V2X message. Instead, the sender may select a subset of this data to include in the generated message, for example, through message generation rules. Metadata may be used to describe the completeness of the data included in the V2X message, i.e., the extent of the included data relative to the total amount of data measured or estimated by the transmitter. The receiver may then check whether the amount of included V2X data exceeds the minimum amount required by the receiver, or whether the included V2X data includes specific data items or areas required by the receiver.

[0077] Regarding information related to the estimated quality of service (QoS) that a recipient may expect from the V2X communication link, the metadata may be used to describe the QoS level, or the value of one or several QoS metrics.

[0078] The consistency value may indicate the probability that the measured or estimated data is correct. A low consistency value may indicate that the data may represent an erroneous estimate or invalid measurement, such as a perceived non-existent (ghost) object. The consistency value may be calculated by estimating the distance between the measured or estimated data and its true value, such as from a map, or a value at a previous time, or a Kalman filter prediction. Algorithms such as deep learning (DL) and machine learning (ML) may also be applied to predict values ​​and calculate data consistency.

[0079] A receiver may receive a V2X message and interpret its security metadata in order to determine suitability for its current driving function. By processing the metadata, it may determine whether the received V2X data meets the requirements of its current driving function and can therefore be used as input for that function. Otherwise, the receiver may not be able to rely on the V2X data alone for its driving function. In addition to data obtained from different sources, the V2X data may still be used as a redundancy check, for example.

[0080] The description of confidence values ​​for V2X data may include the definition of the type of probability density function that most closely matches the distribution of the measured or estimated data. Each distribution type may be defined by a set of statistical parameters, which may allow the calculation of the probability that the true value is within an arbitrary range of values.

[0081] Some examples of probability density functions are as follows. A normal or Gaussian distribution is characterized by its mean or expected value μ and its standard deviation σ. A lognormal distribution is characterized by the mean or expected value μ and the standard deviation σ of the natural logarithm of the variable. A Pareto distribution is characterized by its scale parameter x m and its shape parameter α. The continuous uniform or rectangular distribution is characterized by its minimum value A and its maximum value B. The Poisson distribution is characterized by its rate λ. The exponential distribution is characterized by its rate λ. The gamma distribution is characterized by its shape k and its scale θ. The Rayleigh distribution is characterized by its scale θ. The Rice (or Rician) distribution is characterized by its scale σ and the distance between its reference point and the center of the distribution.

[0082] The operating conditions of the system that measures or estimates the transmitted V2X data may include environmental, geographic and time constraints, traffic and road characteristics, and vehicle automation levels. Below are some examples of these conditions. Environmental conditions may include weather (e.g., sunny, cloudy, light rain, storm, snow, ice, fog, smog) and lighting (e.g., minimum and maximum illumination levels). Geographical constraints may include specific areas, such as countries, states, school zones, construction sites, yards, parking lots, etc. Time of day restrictions may refer to permitted operating times, for example, from 8:00 to 18:00 or specific times, such as sunrise, sunset, night. Traffic characteristics may include traffic density (vehicles / km / lane) and / or vehicle types (cars, trucks / tractors, buses, motorcycles). Road characteristics may include road types (e.g., streets, rural roads, highways, divided / undivided roads), the number of lanes in each direction, and the road surface (e.g., asphalt, concrete, gravel roads, cobblestones, off-road). Vehicle automation levels may include, for example, longitudinal automation, lateral automation, and levels of driving automation that comply with SAE J3016. The equipment of physical infrastructure may include, for example, traffic lights, sensors (video, radar, LiDAR) on poles / stands.

[0083] The integrity of the measured or estimated V2X data may be described in the following ways. It may be described by the number of measured or estimated items / objects included in the message and / or the total number of items / objects measured or estimated by the sender. It may be described by the geographical area covered by the measured or estimated data included in the V2X message. It may also be described by the geographical area not covered by the measured or estimated data included in the V2X message. It may also be described by the ratio between the amount of measured or estimated data included in the V2X message and the total amount of data measured or estimated by the sender.

[0084] The estimated quality of service (QoS) of the V2X communication link may be described using the following metrics and mechanisms and included in the V2X message metadata.

[0085] The message rate may describe the repetition frequency or frequency range over which the V2X message is sent, in the case where the message transmission is (semi-)periodic. The repetition count may describe the number of times the message is sent (may be undefined for periodic messages that are sent indefinitely).

[0086] Each time each V2X message is sent, the message counter may be incremented by 1, which enables the receiver to detect possible message loss. Error detection and / or correction codes may be added to the V2X message to enable the receiver to detect transmission errors, such as parity bits, checksums, cyclic redundancy checks, cryptographic hash functions, or to correct them, such as forward error correction, hybrid automatic repeat request. The sent message may include its measured channel load, such as the channel busy ratio, so that the receiver can better estimate the current channel state, which may have a direct impact on the expected V2X communication performance. The sent message may include its average measured latency, i.e. the time interval between message generation and actual message transmission. This latency may be mainly caused by the time the sender needs to buffer the generated message when the V2X channel is sensed to be busy, for example using the CSMA / CA media access control protocol. The receiver can use the measured latency to better estimate the current channel state. The sent message may also include its measured channel reliability, such as the average packet error rate of the received V2X messages, so that the receiver can better estimate the current channel state. Alternatively 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 may be included in the V2X message metadata.

[0087] The consistency value of the measured V2X data can be calculated in different ways. If a sensor perceives an object outside its perception area, the object may not exist and may be perceived due to a measurement error. In this case, the measured object may have a low (or zero) consistency value. If the perceived object is detected by several independent sensors and / or is also perceived through received V2X data (e.g., cooperative awareness messages), and it is located within the perception area of ​​all these sensors, the object may have a high probability of existence. Therefore, the measured object will have a high consistency value. If the object has been perceived for a long time, it may have a high probability of existence, and vice versa. If the data of the perceived object is within the plausible range of the Kalman filter predicted value, such as future position, velocity, acceleration data, heading, etc., it may have a high probability of existence, and vice versa. Deep learning (DL) and machine learning (ML) can also be applied to predict values ​​and calculate data consistency by analyzing data from vehicle sensors and historical records.

[0088] Possible prerequisites are described below. When a station is put into service, its sensors and data fusion system may be registered with a central registry, where metadata describes the quality and condition of the provided data. Optionally, design assumptions may also be stored in the metadata. For later verification of authenticity, the station's public key 504, 604 may also be included. All data included in the data set 501 may be signed using the vendor's private key, which is stored in the central registry. Figure 5 and Figure 6 as shown in . Figure 5 The signed station metadata set 501 described in may include a station model ID 502 , station metadata 503 , and a station public key 504 .

[0089] Figure 6 A public key infrastructure 605 is shown in accordance with an embodiment, where a vendor public key 601 may be used to derive a station public key 604 .

[0090] exist Figure 6 In the embodiment shown, the station's public key 604 is not included in the station metadata set 501. The station's public key 604 is transmitted using a public key infrastructure 605.

[0091] Figure 7 A signed data message 701 of the station 10 according to an embodiment is shown. The signed data message 701 includes sensor data 720 and a model ID 702. According to the embodiment, the station 10 prepares the data message 701 by acquiring the sensor data 720, attaching a station model identifier (model ID) 702, and signing the V2X message 701 using the station's private key.

[0092] Figure 8 FIG. 1 shows a signed data message of a station with metadata according to an embodiment. Figure 7 In this embodiment in contrast, the signed data message 801 includes sensor data 820 , model ID 802 , and (additionally) metadata 810 .

[0093] Each station 10, 20, 30 may store a local copy (cache) of the central registry containing all metadata signed using the certificate so that it may not have to exchange data with the central registry every time V2X data is sent. The cache may be updated periodically.

[0094] The method according to an embodiment of the present invention may include the following steps: Fig. 9As shown in . In step 901, the sending station 10 can prepare a data message by acquiring sensor data, attaching a station model identifier (model ID), and then use the station's private key to sign the V2X message. In step 902, the sending station 10 can distribute the data message through V2X. In step 903, the receiving station 20 can receive the V2X message. In step 904, the receiving station 20 can extract the model ID of the sending station 10 from the received message. In step 905, the receiving station 20 can obtain the model information corresponding to the model ID from the cached central registry. If the proven trustworthy information corresponding to the sending station 10 is not found in the local registry, the receiving station 20 can request the latest copy of the central registry. If the receiving station 20 is out of coverage, or if the certificate cannot be found in the new version of the registry, the receiving station 20 can reject the incoming information. In step 906, the receiving station 20 can use the vendor public key (cached or available online) to check the model information. In step 907, if the vendor's signature cannot be verified, the received message can be discarded 913. In another case, the receiving station 20 may reliably know the supplier of the sending station 10. Therefore, the receiving station 20 may reliably obtain the correct public key of the sending station 10. In addition, in step 908, during the verification of the signature of the model information, the receiving station 20 may check the correctness and integrity of the content. If the model information is incomplete, changed or incorrect, the received data message may be discarded 913. In step 909, the receiving station 20 may have the correct model information of the sending station 10. Using the included station public key of the sending station 10, the receiving station 20 may verify the received data message. In step 910, if the signature of the sending station 10 cannot be verified, the received message may be discarded 913. In another case, the receiving station 20 may reliably know the sending station 10. Therefore, the receiving station 20 may reliably obtain the correct public key of the sending station 10. In addition, in step 911, during the verification of the signature of the data message, the receiving station 20 may check the correctness and integrity of the content. If the data message is incomplete, changed or incorrect, the received data message may be discarded 913. In step 912, the receiving station 20 can now reliably know that the sending station 10 has sent the data, the data message is complete and correct, and the receiving station 20 can grasp the correct station metadata of the sending station 10. The receiving station 20 can now use the data and use the station metadata of the sending station 10 and the safety requirements of the dedicated safety-critical functions to verify the possible use of the received data.

[0095] In another embodiment, metadata may be associated with different levels of aggregation, such as point clouds and / or sensed objects.

[0096] In another embodiment there may be an additional step where the age of the certificates is checked and the associated data is discarded if their certificates are too old. The age of the information may correspond to the time since the certificate was issued.

[0097] In another embodiment, the certificate may be associated with a public or private key that enables the station to sign and encrypt data in addition to certifying the quality of the transmitted data.

[0098] In another embodiment, the data message 801 contains additional, for example spatial or scene related metadata, such as Figure 8 shown.

[0099] In another embodiment, the station model ID may point to a lookup table in which several individual metadata about, for example, sensors, fusion components, hardware information, software information may be stored separately.

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

[0101] In another embodiment, another method for authentication and signing of messages may be used, such as a group key.

[0102] In another embodiment, if it is not feasible to keep all station models worldwide in a local cache of the registry, only a subset of the registered models may be cached locally like the registered models in a region (eg, EU).

[0103] The method according to an embodiment of the present invention is Fig.10 , and may include the following steps. In step 1001, the first station 20 may distribute its requirements for V2X information, which will allow it to operate its functions in a manner that complies with functional safety. The second station 10 may receive the requirements from the first station 20. In step 1002, the second station 10 may decide whether it will comply with the requested requirements based on an inspection of the received requirements, and if not, abort. In step 1003, the second station 10 may compile or provide information according to the requirements based on a positive decision. In another 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 send the compiled information to the first station 20.

[0104] The first station 20 may receive information from the second station 20, check whether the information meets its requirements, and if so, forward the information to its function.

[0105] In addition, the requirements sent by the first station 20 and checked by the second station 10 may include the following elements. One element may be an operational design domain (ODD), which may describe operational conditions, such as road type, speed, weather conditions, and / or relevant traffic participants. Another element may be functional requirements (e.g., accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, size, angle, object type, trajectory), accuracy of time source (e.g., GPS time, network time protocol), [minimum, maximum] vehicle speed). Another element may be quality of service (QoS) requirements (e.g., payload in [minimum, maximum] bytes, maximum tolerable delay or data age in [minimum, maximum] msec, data rate in [minimum, maximum] Mbps). Another element may be the required level of redundancy (e.g., information update rate, minimum number of unrelated information sources). Another element may be safety level and qualification (e.g., automotive safety integrity level (ASIL) of the sender's system development). Another element may be the allowed failure and degradation modes (e.g., the ability to detect sensing degradation such as sensor blindness, decalibration, or misalignment). Requirements may include constraints on degradation (e.g., reduced sensing range due to severe / adverse weather conditions).

[0106] according to Fig.11 An example is shown of vehicle 20 (the second station in this example) which may run functions requiring an environment model that adhere to specific requirements regarding the content of the environment model. Specific requirements may include the following. The bounding box of surrounding vehicles may be within 100 meters of the station and within 10 meters of the road. The location of the center of gravity of surrounding vehicles may be within 100 meters of the station and within 10 meters of the road, in a specific projection and coordinate reference system, with an accuracy of 2 meters. The location of surrounding vulnerable users may be within 100 meters of the station and within 10 meters of the road, in a specific projection and reference system, with an accuracy of 50 centimeters. Vegetation may be considered as points, and buildings may be considered as polygons. Station 10 (in Fig.11 The smart traffic light in the embodiment of the invention can run the function of creating an environment model from many sources and can provide a wide range of information with different granularities, and perform the following operations. One operation can be lidar point cloud acquisition. Another operation can be image acquisition from front, back and side cameras. Another operation can be radar measurement. Another operation can be data fusion of sensor measurements and perceived objects. Another operation can be object detection and classification. Another operation can be creation of layers. Another operation can be projection in different coordinate systems.

[0107] exist Fig.11In step 1101 of the embodiment of the present invention, the vehicle 20 may send its requirements to the station 10, and the station 10 may be able to comply with the request and format the information in step 1104 in a way that meets all the requirements of the vehicle 20. In step 1105, the formatted information may be sent to the vehicle 20. There are also advantages in terms of channel usage compared to sending all raw data.

[0108] according to Fig.12 In another embodiment described in , the first vehicle 20 may send its requirements in step 1201a. In step 1202, the station 10 may receive these requirements, check these requirements, and decide to comply with these requirements. The station 20 may format the data in step 1203 and send it to the vehicle 20 according to the requirements in a further step 1210a. Later, the second vehicle 30 may send its requirements in step 1201b. The station 10 may compare the two requirements of the first and second vehicles in step 1202' and determine that the requirements of the first vehicle 20 are included in the requirements of the second vehicle 30. In step 1203', the station 10 may decide to comply with the requirements of the second vehicle 30 and format the data according to the requirements of the second vehicle 30. Then, in steps 1210a, 1210b, the station 10 may send the formatted data to the first vehicle 20 and the second vehicle 30, or broadcast it. Since the requirements of the first vehicle 20 are included in the requirements of the second vehicle 30, the functions of the first vehicle 20 can use the data even though it complies with the requirements of the second vehicle 30.

[0109] According to an embodiment (not shown), the first vehicle may send its requirement R1, and the second vehicle may send its requirement R2. The third vehicle may receive both requirements R1 and R2, check them, and decide to comply with R1 and R2. In order to avoid sending two sets of data (one set that satisfies R1 and one set that satisfies R2), the third vehicle may calculate the minimum set of requirements R3 that satisfies both R1 and R2. If the third vehicle can comply with requirement R3, it may format the data accordingly and send it. The first vehicle and the third vehicle may receive the V2X data and use it for their driving functions because it can comply with both of its requirements. If the third vehicle cannot comply with requirement R3, but it can comply with R1 and / or R2, it may format the data according to R1 and / or R2 and send it.

[0110] When the second station cannot meet the requirements, it may instead send a rejection message to inform the first station instead of aborting. Whether the second station rejects silently or with a rejection message may depend on the given use case.

[0111] If there are different possibilities or tradeoffs for satisfying the functions, the sending station 20 may send more than one set of requirements (optionally in a prioritized list). The receiving station 10 may then check whether one or the other set of requirements can be satisfied, thereby increasing the chances of satisfying at least one set of requirements. If the list of requirement sets is prioritized, the station 10 may check the requirement sets from highest priority to lowest priority in order to find the requirement set with the highest priority that can be satisfied. If the station 10 can satisfy at least one set of requirements from the station 20, then the station 10 may satisfy the requirements of the station 20.

[0112] The sending station 20 may tag each set of requirements with a unique tag before sending. When the receiving station 10 can meet one or more sets of requirements, the receiving station 10 may include the unique tag of the satisfied set of requirements into the message for the sending station 20. When the sending station 20 receives the information from the receiving station 10, the included tag may help the sending station 20 check which requirements are satisfied. The sending station 20 may forward the information and tags of the satisfied requirements to the function.

[0113] Fig.13 A method according to an embodiment of the present invention is shown, the method comprising the following steps. In step 1302, station 20 may send an identification of its current driving function. In step 1303a, station 10 may receive the identification of the function and match it to the corresponding requirements in its internal database. In step 1303b, station 10 may decide whether it can provide V2X data based on the requested requirements, and if not, abort. In step 1304, station 10 may provide data based on the requirements of station 20, and according to step 1305, send the information to station 20 together with the identification of the function received from station 20 associated with the set of requirements. In step 1306, station 20 may receive data and identification of the function from station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0114] Fig.14Another embodiment of a method according to the invention is shown, comprising the following steps. In step 1402, station 20 may send an identification of its current driving function and a database version. In step 1403a, station 10 may receive the identification of the function and check the database version. In step 1403b, station 10 may match the identification of the function 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 if not, abort. In step 1404, station 10 may provide data according to the requirements of station 20, and according to step 1405, send the information to station 20 together with the identification of the function received from station 20 associated with the set of requirements. In step 1406, station 20 may receive the data and the identification of the function from station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0115] Fig.15 Another embodiment of a method according to the invention is shown, comprising the following steps. In step 1502, the station 20 may distribute the identification of its current driving function with further options. In step 1503a, the station 10 may receive the identification of the function and match it with the corresponding requirements in its internal database, taking into account the options provided. In step 1503b, the station 10 may decide whether it can provide V2X data according to the requirements of the request, and if not, abort. In step 1504, the station 10 may provide the data according to the requirements of the station 20, and according to step 1505, send the information to the station 20 together with the identification of the function received from the station 20 associated with the set of requirements. In step 1506, the station 20 may receive the data and the identification of the function from the station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0116] The requirements may be based on public standards and, for example, may be stored in a database responsible for managing and accessing the requirements information. For example, the database may be in stations 10, 20 and / or in a central server. The requirements associated with the functional identification in the database may include the following. One requirement may be about an operational design domain (ODD), which may describe the operational conditions of road types, speeds, weather conditions, and / or relevant traffic participants. Another requirement may be about functional requirements (e.g., the accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, size, angle, object type, trajectory), the accuracy of a time source (e.g., GPS time, network time protocol), [minimum, maximum] or vehicle speed). Another requirement may be about quality of service (QoS) requirements (e.g., payload in [minimum, maximum] bytes, maximum allowable delay or data age in [minimum, maximum] msec, data rate in [minimum, maximum] Mbps). Another requirement may be about the required level of redundancy (e.g., information update rate, minimum number of unrelated information sources). Another requirement may be about safety levels and qualifications (e.g., the Automotive Safety Integrity Level (ASIL) for which the sender's system was developed). Another requirement may be about allowed failure and degradation modes (e.g., the ability to detect sensing degradation, such as sensor blindness, decalibration, or misalignment). In this context, the requirements may include constraints on degradation (e.g., reduced sensing range due to severe / bad weather conditions).

[0117] The identification of the function may be an alphanumeric identifier.

[0118] Can be combined Fig.16 Given a first example, a vehicle 20 operates an autonomous driving function that requires an environment model that adheres to specific requirements regarding its content. One specific requirement may describe a bounding box of surrounding vehicles within 100 meters of a station and within 10 meters of a road. Another specific requirement may describe the location of the center of gravity of surrounding vehicles within 100 meters of a station and within 10 meters of a road, in a specific projection and coordinate reference system, with an accuracy of 2 meters. Another specific requirement may describe the location of surrounding vulnerable users within 100 meters of a station and within 10 meters of a road, in a specific projection and reference system, with an accuracy of 50 centimeters. According to another specific requirement, vegetation may be described as points and buildings may be described as polygons. Entities 10 (e.g. Fig.16The smart traffic light in the illustration) can run the function of creating an HD map from many sources and can be able to provide a large range of information with different granularity and perform the following operations. One operation can be lidar point cloud acquisition. Another operation can be image acquisition from front, back and side cameras. Another operation can be radar measurement. Another operation can be data fusion of sensor measurements and perceived objects. Another operation can be object detection and classification. Another operation can be creation of layers. Another operation can be projection in different coordinate systems.

[0119] according to Fig.16 In the illustrated embodiment, in step 1602, the vehicle 20 may send a function identifier to the entity 10 (e.g., 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.

[0120] Fig.16 In particular, an example is shown in which the vehicle 20 sends its function identifier to the smart traffic lamp 10 , and the smart traffic lamp 10 can format its environment model data to meet the requirements of the vehicle 20 and send the formatted environment model to the vehicle 10 .

[0121] A public or published standard (which can be implemented as a database collecting all requirements) in particular maps functions to their requirements. An example excerpt from a database is described below:

[0122]

[0123] RD / 83, ETRS89 and 42 / 83 may be three German reference standards that may be used. Vehicle 20 may simply send an identifier of AD80 as its function identifier, which is an exemplary function that may be an autonomous driving version 80. Receiving this identifier, entity 10 may query the requirements from a database and check the requirements. Entity 10 may be able to comply with the request and compile information for vehicle 20. Fig.16 This example is shown.

[0124] In another embodiment, the common criteria may list multiple options for each function in the database. Fig.15 In the illustrated embodiment, in a first step 1502, a reference to an option may be distributed along with the identification.

[0125] The vehicle 20 may select multiple options, either as a combination (AND) or a selection (OR). When the entity 10 receives the options as a selection (OR), it may select a set of requirements and continue processing that set. Preferably, the options are labeled, which may allow the entity 10 to indicate which requirements it meets when sending qualifying information to the vehicle 20.

[0126] In another example, each feature might have options, as shown in the sample excerpt from the database below.

[0127]

[0128]

[0129] The functionality of the vehicle 20 may require RD / 83 as a reference standard. As a result, Fig.15 As shown, in a first step 1502, the vehicle 20 may send option 1 along with its ID.

[0130] In another embodiment, there may be no request from the first station 20. The entity 10 may select a set of requirements in the database that matches its data, and may then distribute an identifier that references the set of requirements in the database along with the data. The potential recipient may then decide whether the entity 10 meets these requirements and references them in the V2X message to meet its own requirements, and whether the data may be used.

[0131] In another embodiment, the standardized requirements may not be linked to a functional identification, but rather have a unique identification for each requirement. Stations may pick their requirements in a database and then reference a separate set of requirements in their transmissions, with or without requests.

[0132] In similar situations as described above, a station may pick and choose individual requirements, as shown in the example excerpt from the database below.

[0133] Require* Map Requirements Map Requirement Value 1 2 Vehicle BB null 3 Center of gravity accuracy, in meters 2 4 Barycentric Reference System RD / 83 5 Barycentric Reference System ETRS89 6 Barycentric Reference System 42 / 83 13 Ego vehicle speed >20km / h 14 Ego vehicle speed <130km / h

[0134] For example, the functionality of vehicle 20 may require RD / 83 as the center of gravity reference standard, and the ego vehicle speed may have to be between 20 and 130 km / h. Therefore, it may choose to require identifications 4, 13, and 14, and send them via V2X communication.

[0135] In another embodiment, the identification may be sent along with the version number of the database to which it refers. This can ensure compatibility between the databases of the stations. Fig.14 Shown in.

[0136] Receiving station 10 might be last updated in 2020, while sending station 20 might be last updated in 2023. In 2020, version 17.2 of the standard might have been released. In 2023, a new version 18 might have been released.

[0137] Thus, when the sending station 20 distributes its functional identifier, it may refer to version 18. The receiving station 10 may receive this identifier and the version used and realize that these versions are not compatible. Therefore, it may abort the process.

[0138] An alternative is to answer with the version of the receiving station 10 so that the sending station 20 can analyze whether it will be able to accept the requirements stored in the lower version (17.2) in our example. The process can then continue using the lower database version.

[0139] The above explanation of the embodiments describes the invention in the context of examples. Of course, the individual features of the embodiments can be freely combined with one another as long as this is technically reasonable without departing from the scope of the invention.

Claims

1. A method (100) for determining a need for message content at a sending station (10), comprising the following steps: - determining (101, 201, 301) an expected need for message content according to one or more recipient stations (20, 30), wherein the expected need regarding message content is based on the needs of the sending station (10), - calculating (102, 202, 302) at least one metadata configuration of the message content based on the determination (101, 201, 301) of the expected need for the message content, - augmenting (103) the message content based on at least one calculated (102, 202, 302) metadata configuration, wherein the metadata configuration specifies the way in which the message content is to be adapted depending on one or more recipient stations (20, 30) and / or depending on the type of message to be sent.

2. The method (100) according to claim 1, characterized in that: The method (100) further comprises the following steps: - aggregating at least one metadata configuration according to one or more recipient stations and / or according to use cases, wherein a use case defines a scenario related to a station, wherein a scenario includes a sequence of actions and interactions that occur between a station and the system to complete a task, - assembling (404) metadata based on the aggregated metadata configuration, and - Sending (205a, 205b, 310a, 310) a message content comprising at least the assembled metadata and / or payload data.

3. The method (100) according to any one of the preceding claims, characterized in that During the determining (101, 201, 301), the method (100) comprises at least one of the following further steps: - determining an expected need for message content according to one or more recipient stations, wherein the expected need for message content is based on information about the one or more recipient stations, - determining expected needs for message content according to one or more recipient stations, wherein the expected needs according to one or more recipient stations are based on semantic information from the context of the sending station and / or from the context of one or more recipient stations, which is based on a map.

4. The method (100) according to claim 3, characterized in that: The method (100) further comprises the following steps: - generating a profile for at least one metadata configuration, - Selecting a profile based on requirements of the message content related to the sending station and / or based on information from one or more recipient stations and / or from the environment of one or more other stations, which is based on a map, wherein the profile specifies predefined functions of the station and / or predefined use cases of the station.

5. The method (100) according to any one of the preceding claims, characterized in that The method (100) further comprises the following steps: - eliminating at least a portion of the payload data based on the calculated (102, 202, 302) at least one metadata configuration, wherein the calculated (102, 202, 302) at least one metadata configuration indicates a low information value of the payload data.

6. The method (100) according to any one of the preceding claims, characterized in that The method (100) further comprises the following steps: - Storing at least one metadata configuration according to one or more recipient stations and / or according to the type of message to be sent.

7. The method (100) according to any one of the preceding claims, characterized in that The message type is a vehicle-to-everything message.

8. A station (10) for determining a need for message content, comprising means for performing the method (100) of any one of the preceding claims.

9. 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 perform a method (100) according to any one of claims 1 to 7.

10. 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 7.

Images