Method for evaluating a requirement of a traffic-related function for a station

Abstract

The invention relates to a method (100) for evaluating a requirement of a traffic-related function for a station (10), the method (100) comprising the following steps: - requesting (101) model information from a register based on a model identifier extracted from a received message (701, 801), the model information comprising metadata (810) associated with a station model and the model information being stored in the register, - analysing (102) the data in the message (701, 801) for a traffic-related function based on an evaluation of the metadata (810) contained in the model information (702, 802), the evaluation comprising a check as to whether the 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] Procedure for evaluating a requirement for a road traffic-related function for a station

[0004] The invention relates to a method for evaluating a request for a road traffic-related function for a station. 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 10, a computer program having the features of claim 11 and a computer-readable storage medium having the features of claim 12. 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 evaluating a requirement for a road traffic-related function for a station. The method comprises the following steps:

[0014] - Requesting model information from a register based on a model identifier extracted from a received message, wherein the model information comprises metadata related to a station model and wherein the model information is stored in the register,

[0015] - analyzing the data of the message for a road traffic-related function based on an evaluation of the metadata contained in the model information, wherein the evaluation includes a check as to whether the data of the message fulfills at least one requirement of the road traffic-related function, and

[0016] - Determining the usability of the data for the road traffic-related function based on the analysis.

[0017] This advantageously allows for a simple and secure way of exchanging relevant model information regarding a station. Furthermore, it has the advantage of more effective decision-making regarding whether the received information can be used safely in one of its use cases, such as a driving function currently being executed. Furthermore, it makes it possible to ensure compliance with the safety requirements at the receiving station defined by the application using the information received via the message. It is possible for the message to be a V2X message.

[0018] It is possible that the procedure includes the following additional steps:

[0019] - Validating the model information by checking a digital certificate of the model information using a provided public key stored at the station, wherein the public key refers to a provider, and if the result of the check is positive, the method proceeds to the step of providing a public key of the station from the metadata of the validated model information,

[0020] - Verify the message based on the validation, and if the result of the verification is positive, the process proceeds to the next step.

[0021] This makes it possible to advantageously ensure a protected transmission of relevant data or information based on the given security procedure.

[0022] A digital certificate or digital signature can be defined as a digital document that serves as electronic credentials and contains information about the identity of an entity, such as an individual, a station, or a central entity of a network. This can be issued by a trusted third party, also known as a certificate authority (CA), and can be used to verify the authenticity and identity of the entity. Furthermore, a digital signature can be understood as a cryptographic mechanism used to ensure the integrity and authenticity of a digital message or document. This involves using a private key to generate a unique digital signature that is attached to the message, and the recipient can verify the signature using the corresponding public key.

[0023] It is further possible that the method comprises at least one of the following further steps during validation: - checking the correctness and completeness of the content of the model information, and if the result of this check is positive, the method continues with the next step, and / or if the result of this check is negative, the V2X message is discarded,

[0024] - Checking the age of the digital certificate of the model information based on a predefined time limit, wherein the time limit is specified based on a time since the digital certificate was issued, and if the age is less than the predefined limit, the method proceeds to the next step.

[0025] It is possible that the verification process may include the following additional step:

[0026] - Checking the correctness and completeness of the content and / or data of the V2X message, and if the result of this check is positive, the procedure continues with the next step, and / or if the result of this check is negative, the received V2X message is discarded.

[0027] This has the advantage of significantly increasing the accuracy and security of the information and / or data using one of these evaluation steps. Furthermore, it advantageously guarantees the integrity of the information content.

[0028] It is conceivable that, while validating whether the result of the check is positive, the process proceeds with the step of providing a station's public key based on the use of an independent public infrastructure key. This allows for a higher level of security and reliability when exchanging information or model information.

[0029] It is possible that the method comprises the following further step: - extracting the model identifier from the received message, wherein the model identifier indicates a station model for each type of station in the register, wherein the station model comprises the model information for each type of station, wherein the model information comprises at least metadata and wherein stations comprising the same equipment are assigned to the same station model.

[0030] This advantageously simplifies the exchange of this information in terms of speed, effectiveness and security.

[0031] It is also possible that the register is located at the station and / or at a central register of a communication network.

[0032] This has the advantage of significantly increasing uniformity and consistency in data and / or information management between the entities in the network and / or for the entity, such as the station. Furthermore, it allows for more efficient allocation and management of resources. Furthermore, it has the advantage of streamlining the process.

[0033] It is possible that the model information for each station model is stored at the register, and each comprises at least one of the following:

[0034] - Metadata for at least one sensor of the station,

[0035] - Metadata for a sensor set of the station,

[0036] - Metadata for a data fusion component and / or

[0037] - Metadata for a mix of raw and fused data.

[0038] This has the advantage of increasing flexibility and efficiency in the use of appropriate metadata.

[0039] It is conceivable that the type of station is a vehicle and / or an infrastructure and / or a vulnerable road user.

[0040] This has the advantage that different types are available for different scenarios related to a road traffic-related function in a safety-critical scenario, and this can advantageously be used for the corresponding scenario. In another aspect of the invention, a station for evaluating a request for a road traffic-related function may be provided, which is designed to carry out the method according to the invention. For example, the station comprises a computer executing 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 can be stored and from which a computer program can be read by the processor to be executed.

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

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

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

[0044] 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:

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

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

[0047] Fig. 3: A method of a message flow and an adaptation of a data / metadata set according to embodiments of the invention,

[0048] Fig. 4: Method of calculating a data / metadata set and using the updated set according to embodiments of the invention,

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

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

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

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

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

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

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

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

[0057] Fig. 14: A sequence diagram of a method with a database version check according to embodiments of the invention,

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

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

[0060] 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. 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-related applications aimed at improving traffic safety, efficiency, driver comfort, and 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).

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

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

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

[0064] This invention particularly addresses the situation where at least two stations, e.g., vehicles, vulnerable road users (VRU), or road infrastructure, are involved in exchanging information via V2X communication, and where at least one uses the received information for a safety-critical function, such as remote driving, platooning, emergency braking, automated driving, etc. Since the systems may not have been designed together and therefore their safety analyses may be completely independent of each other, they may operate based on different assumptions and requirements.

[0065] One problem addressed in the present invention is how the receiver of a V2X message can decide whether the contained information can be safely used for decision-making in one of its use cases. To enable a safety-critical response based on received V2X data, the receiver must ensure that the received data meets the requirements of the driving 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 information, 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.

[0066] The following example can illustrate a problem solved by the present invention. Assume that a first vehicle has a side-facing camera for a safety-critical function that secures the near field at 3 meters or less around the vehicle. This camera can now detect a pedestrian 5 meters away from the first vehicle who is most likely walking towards the road. This information can be passed to a second vehicle via V2X. The second vehicle may be following the first vehicle and may not be able to detect the pedestrian due to obstacles. The question now might be whether the second vehicle should perform a hard braking maneuver based on the information received via V2X.In particular, this question CANNOT be answered by the first vehicle, as 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 lacks the characteristics of the first vehicle's camera and any other sensors used in sensor fusion to decide 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 of a different vehicle, with likely very different requirements, may not help the decision-making process.

[0067] The main idea of ​​this invention is based on the use of a central point, such as a server or cloud, which can be reached via means other than standardized V2X messages, such as a cellular IP connection (e.g., LTE or 5G). The central point can also be referred to as a central registry. The central registry can store metadata and distribute it to the stations. To this end, the central registry can hold metadata for, e.g., each model (vehicle, infrastructure, VRU), each sensor, each fusion component, and each software version. Each element can have a unique identifier assigned to it, which can also be in the form of a digital certificate. Stations or elements with the same hardware and software configuration can be grouped together as a single station model and can therefore share a common central registry entry.On the other hand, the model's unique identifier can be included in each sent V2X message, allowing the recipient of the V2X message to query the central registry for the sender's specific metadata. Metadata can include information regarding the quality of the sensors used, e.g., deliverable information, the type of information interpretation, sensor position, resolution, field of view, uncertainties, classification capabilities, and known deficiencies, as well as the quality of the applied data fusion, e.g., deliverable information, mode of information interpretation, individual information sources included, resolution, field of view, uncertainties, properties, and parameterization of the sensor fusion algorithm used.The metadata may further include properties of all hardware involved, such as bit error rates, number of computation paths, probability of errors, known deficiencies, and / or real-time capabilities.

[0068] The metadata stored at the central repository for each individual station model may include the following. Regarding sensor data, there may be metadata for each sensor contained in the station in the central repository. Regarding sensor set data, there may be metadata for a partial, e.g., front or rear, or entire sensor set of the station. Regarding fused data, there may be metadata for the data fusion component, such as algorithms and hardware. Regarding a mixture of raw and fused data, there may be metadata of raw data, e.g., a video stream from a camera, radar, or lidar point cloud, and fused data, e.g., perceived objects after sensor fusion.

[0069] Regarding additional data on the receiving side, the following can be noted. When sending data, there may be metadata corresponding to the sensor and / or processing algorithm, e.g., sensing and / or fusion, from which the data in the central registry may have been derived. This can allow the receiver to determine how this data point was recorded and processed. Therefore, the receiver can use this information to determine whether the received data can be safely used for specific use cases at the receiving station. When using metadata, the receiving station may also need to know its own security requirements for all input data with regard to all safety-critical functions of the station model.Therefore, the receiving station can deduce whether it is safe to use the received data or not, especially for each of its available safety-critical functions.

[0070] As described in the V2X CAM and DENM standards, the use of trust and privacy management can enable the authorization and encryption of messages. An incoming signed message can be accepted by the recipient if the certificate is valid and the CAM is consistent in its certificate. For security reasons, each V2X message containing sensor information can be digitally signed, for example, using PKI certificates. One possible implementation of this could be for each station model to have its own set of public and private keys. The public key can be stored at a central registry, and each instance of a station model can know the model's private key, which can be securely stored inside the station and protected against misuse, for example, by using a hardware security module (HSM).In this way, any station can sign V2X messages, and any recipient of a V2X message can verify that the message actually originates from the claimed model. To prevent replay attacks, the V2X message may need to include a timestamp or sequence number. Using this system, a certificate for an entire model fleet can be easily revoked if security concerns are discovered after market launch. No other model can use information provided by a previously mentioned model.

[0071] The information stored in the central register may need to be confirmed ("certified") by the relevant OEM and may need to be secure against tampering (security).

[0072] Tamper-evident security can be a technical solution for providing security. The digital data stored in the central registry may also need to be digitally signed to protect against tampering. However, this time, the data may not need to be signed with the station model-specific key, but rather with vendor-specific keys. Therefore, each OEM may also have a pair of public and private keys.

[0073] Metadata can be signed using OEM private keys, which in turn can be verified by each station using the vendors' public keys. Vendor public keys may be stored directly at each station, as there may only be a small number of vendors. These keys can be updated over the air or during regular station maintenance at the dealer.

[0074] To reduce latency and / or load on the central registry, each station can maintain a local copy of all central registry contents. This copy can be regularly updated over the air to ensure it contains all new station models and has a current version of the metadata.

[0075] 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 evaluating a request for a road traffic-related function for a station 10. The method 100 comprises the following steps:

[0076] In step 101, model information is requested from a registry based on an extracted model identifier from a received message 701, 801. The model information includes metadata 810 related to a station model. The model information is stored at the registry.

[0077] In step 102, the data of the message 701, 801 is analyzed for a road traffic-related function based on an evaluation of the metadata 810 contained in the model information 702, 802. The evaluation includes a check to determine whether the data of the message fulfills 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.

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

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

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

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

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

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

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

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

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

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

[0088] 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 driving function.

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

[0090] In the case where the V2X data can be used for driver assistance or automated driving functions, the receiver 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 receiver can then check whether these operating conditions encompass its current driving conditions. In this case, it can use the received V2X data for its driving function.

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

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

[0093] A consistency value can indicate the probability that the measured or estimated data is correct. A low consistency value can indicate that the data may represent an erroneous estimate or an invalid measurement, such as a perceived, nonexistent (ghost) object. The consistency value 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 point, 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.

[0094] The receiver can receive the V2X message and interpret its security metadata to determine its suitability for its current driving function. By processing the metadata, it can 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 cannot rely solely on the V2X data for its driving function. The V2X data can still be used, for example, as a redundancy check in addition to data received from another source.

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

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

[0097] 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. 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 constraints may include specific regions, such as countries, states, school zones, yards, parking lots, and the like. Time-of-day constraints may 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 may include traffic density (vehicles / km / lane) and / or vehicle types (cars, trucks / tractors, buses, motorcycles).Road characteristics can include road types, e.g., street, highway, divided / undivided road, number of lanes per direction, and road surfaces, e.g., asphalt, concrete, gravel, cobblestone, off-road. A vehicle's automation level can include, e.g., longitudinal automation, lateral automation, and the level of driving automation according to SAE J3016. Physical infrastructure equipment can include, e.g., traffic lights on a pole / structure, sensors (video, radar, LiDAR).

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

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

[0100] 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).

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

[0102] 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) consistency value. If a detected object is detected by multiple independent sensors and / or also by received V2X data, such as a Cooperative Awareness Message, and is within the detection 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 detected 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.

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

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

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

[0106] Fig. 7 shows a signed data message 701 of 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. Fig. 8 shows a signed data message of 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.

[0107] Each station 10, 20, 30 can 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 during every V2X data transfer. The cache can be updated regularly.

[0108] The method according to an embodiment of the invention may include the following steps, which are 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 signing 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 register.If the certified trust information corresponding to the transmitting station 10 is not found in the local registry, the receiving station 20 can 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 can reject the incoming information. In step 906, the receiving station 20 can 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 can 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.Additionally, in step 908, while verifying the signature of the model information, the receiving station 20 may check the correctness and completeness of the content. If the model information is incomplete, altered, 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 transmitting station 10. Using the station's public key of the transmitting station 10, the receiving station 20 may 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.Additionally, in step 911, 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 can be discarded 913. In step 912, the receiving station 20 can now reliably learn that the transmitting station 10 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 security requirements of the dedicated safety-critical function.

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

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

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

[0112] In another embodiment, the data message 801 contains additional, e.g., spatial or scene-dependent, metadata, which is shown in Fig. 8.

[0113] In another embodiment, the station model identifier may point to a lookup table where several individual metadata about e.g.

[0114] Sensors, fusion components, hardware information, software information can be stored separately.

[0115] In another embodiment, the vehicle identification number (VIN) is used as the identifier instead of the model identifier.

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

[0117] 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).

[0118] A method according to embodiments of the invention is illustrated in Fig. 10 and may include 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 not. 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.

[0119] The first station 20 can receive the information from the second station 20, check whether the information meets its requirement, and, if so, forward the information to its function.

[0120] Furthermore, the requirements sent by the first station 20 and checked by the second station 10 may include the following elements. One element may be ODD (Operational Design Domain), which may describe operating conditions such as road types, speeds, weather conditions, and / or relevant road users. Another element may 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 permitted failure and degradation modes (e.g., an ability to detect sensing degradation, such as sensor blindness, decalibration, or misalignments. A requirement may include degraded constraints (e.g., a reduced sensing range due to adverse weather conditions). According to an example shown 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.

[0121] 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 such a way that all of the vehicle 20's requests are met. In step 1105, the formatted information may be transmitted to the vehicle 20. There may also be an advantage in terms of channel utilization compared to sending only raw data. 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 requests of the first and second vehicles 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 in step 1203' to satisfy the requests of the second vehicle 30 and format the data according to the requests of the second vehicle 30. The station 10 may then send the formatted data to the first vehicle 20 and the second vehicle 30 in step 1210a, 1210b. Since the requests of the first vehicle 20 are included in the requests of the second vehicle 30, the function of the first vehicle 20 may use the data even though it satisfies the requests of the second vehicle 30.

[0122] 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 driving 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.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.

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

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

[0125] 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 driving 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 together with the function identification received from the station 20 in conjunction with the set of requirements according to step 1305 to the station 20.In step 1306, 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 driving function.

[0126] Fig. 14 shows another embodiment of a method according to the invention, comprising the following steps. In step 1402, a station 20 can transmit the identification of its current driving function and a database version. In step 1403a, a station 10 can receive the function identification and check the database version. In step 1403b, the station 10 can match the function identification with the corresponding requirements in its internal database. In a further step 1403c, 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 1404, 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 1405.In step 1406, 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 driving function.

[0127] 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 driving 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 together with the function identification received from the station 20 in conjunction with the set of requirements to the station 20 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 driving function.

[0128] The requirements can be based on a public standard and can, for example, be stored in a database responsible for managing and accessing the requirement information. This database can, for example, be located at station 10, 20, and / or on a central server. The requirements, in conjunction with the functional identification in the database, can include the following: One requirement can concern ODD (Operational Design Domain), which can describe operating conditions such as road types, speeds, weather conditions, and / or relevant road users. Another requirement can concern functional requirements (e.g., an accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, dimension, angle, object type, trajectory), an accuracy of the time source (e.g., GPS time, network time protocol), [min, max], or a 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). Another requirement may concern required redundancy levels (e.g., information update rate, minimum number of uncorrelated information sources). Another requirement may concern safety levels and qualifications (e.g., an Automotive Safety Integrity Level (ASIL) for the system development of the transmitter). Another requirement may concern allowed failure and degradation modes (e.g., a capability to detect sensing degradation, such as sensor blindness, decalibration, or misalignments). Requirements in this context may include degraded constraints (e.g.,a reduced range of perception due to bad weather conditions)).

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

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

[0131] According to the embodiment shown in Fig. 16, in step 1602, vehicle 20 may transmit a functional identifier to entity 10, for example, a smart traffic light. In step 1603, entity 10 may check a database. In step 1604, entity 10 formats its data to meet the requirements of vehicle 20. In step 1605, entity 10 sends the formatted data to vehicle 20.

[0132] In particular, Fig. 16 shows an example of a vehicle 20 sending its functional identifier to a smart traffic light 10 that can format its environmental model data to meet the requirements of the vehicle 20 and send a formatted environmental model to the vehicle 10.

[0133] 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:

[0134] RD / 83, ETRS89, and 42 / 83 may be three German reference standards that may be used. The vehicle 20 may only send AD80, an exemplary function, which may be an autonomous driving version 80, as the identifier of its function identifier. Upon receiving this identifier, the entity 10 may query the requirements from the database and verify the requirements. The entity 10 may be able to fulfill the requirements and compile the information for the vehicle 20. Figure 16 illustrates this example. 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 depicted in Figure 15.

[0135] Multiple options can be selected by vehicle 20, either as a combination (AND) or a selection (OR). When entity 10 receives options as a selection (OR), it can select a requirement set and continue the process with that set. Preferably, the options are labeled, which can allow entity 10 to indicate which requirements it meets when the qualifying information is sent to vehicle 20.

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

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

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

[0139] In another embodiment, the standardized requirements may not be associated with a functional identifier, but may have unique identifiers for each requirement. Stations can cherry-pick their requirements from the database and then reference sets of individual requirements in their transmission, with or without requirements.

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

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

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

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

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

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

[0146] 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 evaluating a request for a road traffic-related function for a station (10), the method (100) comprising the following steps: Requesting (101) model information from a register based on a model identifier extracted from a received message (701, 801), wherein the model information comprises metadata (810) related to a station model and wherein the model information is stored in the register, Analyzing (102) the data of the message (701, 801) for a road traffic-related function based on an evaluation of the metadata (810) contained in the model information (702, 802), wherein the evaluation comprises a check as to whether the data of the message fulfill at least one requirement of the road traffic-related function, determining (103) a usability of the data for the road traffic-related function based on the analysis (102).

2. Method (100) according to claim 1, characterized in that the method comprises the following further steps: Validating the model information (702, 802) by checking a digital certificate of the model information (702, 802) using a provided public key (601) stored at the station (10), wherein the public key (601) relates to a provider, and if the result of the check is positive, the method continues with the step of providing a public key (504, 604) of the station from the metadata (810) of the validated model information (702, 802), Verify the message based on the validation, and if the result of the verification is positive, the process proceeds to the next step.

3. Method (100) according to claim 2, characterized in that the method comprises at least one of the following further steps during the validation: Checking the correctness and completeness of the content of the model information (702, 802), and if the result of this check is positive, the method (100) continues with the next step, and / or if the result of this check is negative, the message (701, 801) is discarded (913), Checking the age of the digital certificate of the model information (702, 802) based on a predefined time limit, wherein the time limit is specified based on a time since the digital certificate was issued, and if the age is below the predefined limit, the method proceeds to the next step.

4. Method (100) according to claim 2, characterized in that the method comprises the following further step during the verification: Checking the correctness and completeness of the content and / or data of the message (701, 801) and if the result of this check is positive, the method (100) continues with the next step, and / or if the result of this check is negative, the received message (701, 801) is discarded (913).

5. The method (100) according to claim 2, characterized in that, while validating whether the result of the check is positive, the method continues with the step of providing a public key (604) of the station based on the use of an independent public infrastructure key.

6. Method (100) according to one of the preceding claims, characterized in that the method (100) comprises the following further step: Extracting the model identifier (702, 802) from the received message (701, 801), wherein the model identifier (702, 802) specifies a station model for each type of station in the register, wherein the station model Model information (702, 802) for each type of station, wherein the model information (702, 802) comprises at least metadata (810) and wherein stations comprising the same equipment are assigned to the same station model.

7. Method (100) according to one of the preceding claims, characterized in that the register is located at the station (10) and / or at a central register of a communication network.

8. Method (100) according to one of the preceding claims, characterized in that the model information (702, 802) for each station model is stored at the register and in each case comprises at least one of the following: Metadata for at least one sensor of the station, Metadata for a station's sensor set, metadata for a data fusion component, and / or metadata for a mixture of raw and fused data.

9. Method (100) according to one of the preceding claims, characterized in that the type of station is a vehicle and / or an infrastructure and / or a vulnerable road user.

10. Station (10) for evaluating a request for a road traffic-related function, comprising means for carrying out the method (100) according to any one of the preceding claims.

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

12. 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 9.

Images