Method for evaluating requirements for road traffic-related functions of station

Abstract

The invention relates to a method (100) for evaluating requirements for road traffic-related functions of a station (10), where the method (100) comprises the steps of:-requesting (101) model information from a registry on the basis of a model identifier extracted from a received message (701, 801), where the model information comprises metadata (810) relating to a station model; wherein the model information is stored in the registry,-analyzing (102) the data of the message (701, 801) for a road traffic-related function on the basis of an evaluation of metadata (810) contained in the model information (702, 802) wherein the evaluation comprises checking whether the data of the message meets at least one requirement of the road traffic-related function, and-analyzing (102) the data of the message (701, 801) for the road traffic-related function on the basis of the evaluation of the metadata (810) contained in the model information (702, 802). Based on the analysis (102), determining (103) the availability of the data for the road traffic-related function.

Description

Technical Field

[0001] This invention relates to a method for evaluating the requirements of road traffic-related functions for a station. Furthermore, this invention relates to a station, computer program, and storage medium for this purpose. Background Technology

[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 CAM (Cooperative Awareness Message, ETSI), VAM (VRU Awareness Message, ETSI), CPM (Collective Perception Message, ETSI), or BSM (Basic Safety Message, SAE), have been standardized.

[0003] Currently, V2X data often originates from outsourced information. The driver is also responsible for reacting to V2X information and determining the necessity of actions, such as gradually reducing speed based on a collision warning. Due to the lack of robust safety attributes, vehicles cannot 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 CAD (Cooperative Automated Driving) systems primarily revolves around creating a comprehensive system where safety is rooted in the overall concept. This system can manifest as a secure "closed-world" environment where both the sender and receiver adhere to the same safety concepts and certifications. It may be tailored to specific use cases. An example of such a system is Automated Valet Parking (AVP), which is currently likely in the standardization phase at ETSI. The downside is that whenever a new vehicle is developed, entirely new certifications are required for all foreseeable garage / vehicle AVP pairings to ensure the safety of all possible combinations.

[0005] US2021219139 A describes a method to increase trust in received V2X data by including metadata on the sender, such as vehicle manufacturer, technical equipment, vehicle age, hardware and software implementation details, and the authentication level of the sending vehicle, into the V2X message.

[0006] WO2022 / 122450 A1 describes the inclusion of a "safety section" in V2X messages to make them usable for safety-related driving functions. This safety section may include the safety level, failure rate, development process description, validity period, failure model, and / or confidence level of the V2X data.

[0007] US20230059220 A1 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., an object detected by onboard sensors, the sender's location and the plausibility of the RSSI, or a previous V2X message). Summary of the Invention

[0008] The aforementioned objective is achieved by a method having the features of claim 1, a site 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. Other features and details of the invention are disclosed in the dependent claims, the specification, and the drawings. The features and details described in conjunction with the method according to the invention also apply to the site according to the invention, the computer program according to the invention, and the storage medium according to the invention, and vice versa in each case, so that the disclosure regarding various aspects of the invention can always be cross-referenced.

[0009] This objective is achieved, in particular, through a method for assessing the requirements for road traffic-related functions at a site. The method includes the following steps: - Based on the model identifier extracted from the received message, request model information from the registry, wherein the model information includes metadata related to the site model, and wherein the model information is stored in the registry. - Based on an evaluation of the metadata contained in the model information, the message data is analyzed for use in road traffic-related functions, wherein the evaluation includes checking whether the message data meets at least one requirement of the road traffic-related functions, and - Based on this analysis, the availability of the data for road traffic-related functions is determined.

[0010] This advantageously allows for the exchange of relevant model information about a site in a simple and secure manner. Furthermore, it offers the advantage of more efficient decision-making regarding whether the received information can be safely used in its use case, such as in a driving function being performed. Additionally, it enables ensuring that security requirements defined by the application using the information received via the message are met at the receiving site. This message can be a V2X message.

[0011] The method may include the following further steps: - The method verifies the model information by checking the digital certificate of the model information using the provided public key stored at the site (where the public key involves the provider), and if the check is positive, the method proceeds to the step of providing the site's public key from the metadata of the verified model information. - The message is verified based on this verification, and if the verification result is positive, the method proceeds to the next step.

[0012] This makes it possible to ensure the protected transmission of relevant data or information in an advantageous manner based on given security methods.

[0013] A digital certificate or digital signature can be defined as a digital document used for electronic authentication and containing information about the identity of an entity, such as an individual, website, or network central entity. 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 an entity. Furthermore, a digital signature can be understood as a cryptographic mechanism used to ensure the integrity and authenticity of digital messages or documents. This involves using a private key to generate a unique digital signature attached to the message, and the recipient can verify the signature using the corresponding public key.

[0014] The method may also include at least one of the following further steps during verification: - Check the correctness and completeness of the model information content, and if the result of this check is positive, the method proceeds to the next step, and / or If the result of this check is negative, the V2X message is discarded. - The validity period of a digital certificate is checked based on a predefined time limit, which is specified based on the time since the digital certificate was issued, and if the validity period is less than the predefined limit, the method proceeds to the next step.

[0015] The method may include the following further steps during verification: - Check the correctness and integrity of the V2X message content and / or data, and if the result of this check is positive, the method proceeds to the next step, and / or If the result of this check is negative, the received V2X message is discarded.

[0016] This has the advantage of significantly improving the accuracy and security of information and / or data when using one of these evaluation steps. Furthermore, it advantageously ensures the integrity of the information content.

[0017] It is conceivable that during verification, if the check yields a positive result, the method continues based on the step of providing the site's public key using a separate public infrastructure key. This allows for a higher level of security and reliability when exchanging information or model information.

[0018] The method may include the following further steps: - Extract the model identifier from the received message, wherein the model identifier indicates the site model for each site type in the registry, wherein the site model includes model information for each site type, wherein the model information includes at least metadata, and wherein sites with the same equipment are assigned the same site model.

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

[0020] It is also possible that the registry is located at the site and / or at a central registry within the communication network.

[0021] This offers the following advantages: significantly improved uniformity and consistency in data and / or information management among network entities and / or for entities (e.g., sites). Furthermore, it allows for more efficient resource allocation and management. Additionally, it simplifies processes.

[0022] It is possible that model information is stored in the registry for each site model, and each site model includes at least one of the following: - Metadata for at least one sensor at the site, - Metadata for the site's sensor collection, - Metadata for data fusion components, and / or - Metadata for a mix of raw and fused data.

[0023] This has the following advantages: increased flexibility and efficiency in using appropriate metadata.

[0024] It can be envisioned that the station type is vehicles and / or infrastructure and / or vulnerable road users.

[0025] The advantage of this is that different types are available for different scenarios related to road traffic-related functions, and in safety-critical scenarios, this can be advantageously applied to the corresponding scenarios.

[0026] In another aspect of the invention, a station for assessing the requirements of road traffic-related functions may be provided, the station being designed to perform the method according to the invention. For example, the station includes a computer executing 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 can be read from the volatile memory by the processor for execution.

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

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

[0029] Furthermore, the method according to the present invention can be implemented as a computer-based method. Attached Figure Description

[0030] Other 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 specification may be important to the invention individually or in any combination. As shown below: Figure 1 According to embodiments of the present invention, the method, computer program, storage medium, and apparatus are as follows: Figure 2 According to the method of the present invention, Figure 3 According to the message flow method and data / metadata set adjustment of the present invention, Figure 4 The present invention provides a method for calculating data / meta-datasets and using the updated set according to embodiments thereof. Figure 5 The site metadata dataset with signatures according to embodiments of the present invention. Figure 6 According to the public key infrastructure of the present invention, Figure 7 According to an embodiment of the present invention, a signed TX site data message, Figure 8 According to an embodiment of the present invention, a TX site data message with metadata signature, Figure 9 The following is a flowchart of the verification sequence according to an embodiment of the present invention. Figure 10 According to the method flowchart of the present invention, Figure 11 According to an embodiment of the present invention, a method having a vehicle and intelligent traffic lights, Figure 12 According to an embodiment of the present invention, a method having one station and two vehicles, Figure 13 According to the method flowchart of the present invention, Figure 14 : A flowchart of a method for database version checking according to an embodiment of the present invention. Figure 15 A flowchart of a method for providing options according to an embodiment of the present invention. Figure 16 A method for having a vehicle and intelligent traffic lights according to an embodiment of the present invention. Detailed Implementation

[0031] V2X communication can stand for “vehicle-to-everything” communication. It is specifically 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. The goal of V2X communication can be to improve road safety, traffic efficiency, and the effectiveness of the entire transportation system by allowing vehicles and other entities to exchange information in real time. This technology can be applied to various other aspects of advanced driver assistance systems (ADAS), autonomous driving, traffic management, and modern transportation. Transmitting V2X messages via V2X communication can facilitate information exchange between vehicles and / or infrastructure components and / or pedestrians. This message exchange can also support the operation of current road traffic-related applications aimed at improving traffic safety, efficiency, driver comfort, and enhancing the reliability of existing driver assistance and autonomous driving applications. Illustrative examples include C-ACC (Cooperative Automated Cruise Control) and V2X-related collision warnings (e.g., due to impending traffic congestion or pedestrians crossing the road).

[0032] Metadata can refer to data that provides information about other data. It can describe various attributes of primary data, such as source, format, creation date, author, and other relevant details. Metadata can help organize, understand, and manage primary data, whether it is a document, image, 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 of a specific entity or concept. In short, while both metadata and descriptors contain description 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.

[0033] Payload data can refer to the basic information or content transmitted 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.

[0034] Road traffic-related functions are defined as specific operations or tasks directly related to traffic flow and / or traffic management on roads. These functions 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, road traffic-related functions may refer to safety-critical scenarios, such as emergency braking, obstacle avoidance maneuvers, or collision warnings.

[0035] This invention is particularly relevant to situations where at least two sites (e.g., vehicles, vulnerable road users (VRUs), or road infrastructure) participate in exchanging information via V2X communication, and at least one of these sites uses the received information for safety-critical functions such as remote driving, convoy formation, emergency braking, and autonomous driving. Because the systems may not be designed together, their safety analyses may be completely independent, and they may operate based on different assumptions and requirements.

[0036] One problem addressed by this invention is how the recipient of a V2X message determines whether the contained information can be safely used for decision-making in its use case. In order to make safety-critical responses based on received V2X data, the recipient must ensure that the received data meets the requirements of the driving function in operation. These requirements may include, for example, the accuracy of measurements or estimates, the accuracy of time sources, the maximum tolerable timeliness of the information, the minimum number of unrelated information sources, the Automotive Safety Integrity Level (ASIL) developed by the sending system, or the ability to detect perception degradation.

[0037] The following example illustrates the problem addressed by this invention. Suppose a first vehicle has a side-facing camera for a safety-critical function, covering a near-field area of ​​3 meters or less around the vehicle. This camera can now detect a pedestrian at a distance of 5 meters from the first vehicle, who is walking towards the road with a high probability. This information can be transmitted to a second vehicle via V2X. The second vehicle may follow the first vehicle and may fail to detect the pedestrian due to obstacles. The question now might be whether the second vehicle should perform emergency braking based on the information received via V2X. This question is particularly difficult for the first vehicle to answer, 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 this question because it is unaware of the characteristics of the first vehicle's camera and any other sensors possibly used in sensor fusion, and cannot determine whether the information source meets the requirements of its emergency braking system. In this case, the fact that the first vehicle's side-facing camera is part of a different safety-critical function of another vehicle with potentially very different requirements does not aid the decision-making process.

[0038] The main idea of ​​this invention is based on using a central point, such as a server or cloud, which can be accessed via means other than standardized V2X messages (such as cellular IP connections, e.g., LTE or 5G). This central point can also be called a central registry. The central registry can store metadata and distribute it to sites. For this purpose, the central registry can store metadata for, for example, 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 take the form of a digital certificate. Sites or elements with the same hardware and software equipment can be classified as the same site model and therefore can have common central registry entries. On the other hand, each sent V2X message can contain a unique identifier for the model, allowing the recipient of the V2X message to query the central registry to obtain the sender's specific metadata. Metadata can include information about the quality of the sensors used, such as deliverable information, type of information interpretation, sensor location, resolution, field of view, uncertainty, classification capability, and known defects, as well as the quality of the applied data fusion, such as deliverable information, pattern of information interpretation, individual information sources included, resolution, field of view, uncertainty, characteristics and parameterization of the sensor fusion algorithm used. Metadata can also include characteristics of the entire associated hardware, such as bit error rate, number of computation paths, error probability, known defects, and / or real-time capabilities.

[0039] The metadata stored at the central registry for each individual site model can include the following: Regarding sensor data, metadata can be provided for each sensor included in the central registry at the site. Regarding sensor ensemble data, metadata can be provided for a portion of the site (e.g., front or rear) or the entire sensor ensemble. Regarding fused data, metadata can be provided for data fusion components (e.g., algorithms and hardware). Regarding the mixing of raw and fused data, metadata can be provided for both raw data (e.g., video streams from camera, radar, or lidar point clouds) and fused data (e.g., objects perceived after sensor fusion).

[0040] Regarding the additional data on the receiving side, the following points should be noted. When data is transmitted, there may be metadata corresponding to the sensors and / or processing algorithms (e.g., sensing and / or fusion), from which the data in the central register may be derived. This allows the receiver to determine how the data point was recorded and processed. Therefore, the receiver can use this information to determine whether the received data can be safely used for a specific use case within the receiving site. When using metadata, the receiving site may also need to know its own security requirements for all input data related to all safety-critical functions of the site model. Therefore, the receiving site can deduce whether it is safe to use the received data, especially for each of its available safety-critical functions.

[0041] As described in the V2X CAM and DENM standards, the use of trust and data protection management enables message authorization and encryption. If the certificate is valid and the CAM matches its certificate, the recipient can accept an incoming signed message. For security reasons, each V2X message containing sensor information can be digitally signed, for example, using a PKI certificate. One possible implementation is that each site model can have its own set of public and private keys. The public key can be stored in a central registry, and each instance of a site model can know its private key, which can be securely stored internally and protected from misuse, for example, by using a Hardware Security Module (HSM). In this way, each site can sign V2X messages, and each recipient of a V2X message can verify that the message indeed comes from the claimed model. To prevent replay attacks, V2X messages may need to include timestamps or sequence numbers. Using this system, if a security issue is discovered post-market, the certificates of the entire model fleet can be revoked simply. For this reason, no other model can use the information provided by the aforementioned models.

[0042] Information stored in the central registry may need to be verified (“certified”) by the corresponding OEM and may need to be protected against tampering (security).

[0043] Tamper protection can be a technical solution used to provide security. Digital data stored in a central registry may also require digital signatures to prevent tampering. However, this time, the data may not need to be signed using a site-specific key, but rather a provider-specific key. Therefore, each OEM could also have a public and private key pair. Metadata can be signed using the OEM's private key, and then each site can verify the metadata using the provider's public key. The provider's public key could potentially be stored directly at each site, as there may only be a few providers. These keys can be updated wirelessly or during regular site maintenance at reseller locations.

[0044] To reduce latency and / or load on the central registry, each site can have a local copy of all content in the central registry. This copy can be updated periodically over the air to ensure it contains all new site models and has the latest version of metadata.

[0045] Figure 1 The illustrations depict a method, computer program, storage medium, and site according to embodiments of the present invention. Figure 1 A method 100 for evaluating the requirements of road traffic-related functions for site 10 is shown. The method 100 includes the following steps: In step 101, model information is requested from the registry based on the model identifier extracted from the received messages 701 and 801. This model information includes metadata 810 related to the site model. This model information is stored in the registry.

[0046] In step 102, based on the evaluation of the metadata 810 contained in model information 702 and 802, the data of messages 701 and 801 are analyzed for use in road traffic-related functions. This evaluation includes checking whether the data of the messages meets at least one requirement of the road traffic-related functions. In step 103, based on the analysis in step 102, the availability of the data for road traffic-related functions is determined.

[0047] Figure 1 Site 10 is also shown, which includes a computer 11 and a computer-readable storage medium 15. The computer-readable storage medium 15 includes a computer program 50.

[0048] according to Figure 2In the implementation shown, site 10 can perform the following steps. In step 202, metadata configuration can be calculated based on the anticipated needs determined in step 201. This calculation can be performed at any point in time before sending a message that requires metadata. This calculation can be performed periodically when any new information affecting metadata selection becomes available to site 10 or when new information is received from anywhere else, or when sending a message begins and metadata configuration is indeed required. Site 10 can anticipate the need for metadata based on potential recipients. In its basic configuration, site 10 can also use information from itself and about itself. This information may include, for example, location, speed, vehicle type, current and / or future driving tasks and / or modes (automation levels). This information may also include environmental conditions such as temperature, light and weather conditions and / or conceptual decisions and / or use cases implemented in site 10 to deduce or anticipate what requirements one or more potential recipients of site 10's V2X data might have, and what requirements site 10 can meet.

[0049] Based on this expectation, site 10 can define a metadata configuration of 201, which is used for future V2X messages sent by site 10. This configuration can be calculated as 202 and stored separately for different recipients and different message types. In steps 205a and 205b, this metadata configuration can be used when sending messages to other sites 20 and 30.

[0050] Furthermore, site 10 can use computed metadata configurations for message types and one or more addressed receivers 20, 30 to assemble configured metadata and add it to the V2X message. If multiple metadata configurations are required, i.e., for multiple use cases, message types, or receivers, site 10 can aggregate these metadata configurations before assembling the metadata. Site 10 can then send the entire V2X message (205a, 205b), including the usual header, payload data, and assembled metadata.

[0051] Figure 4According to embodiments of the present invention, these second steps are illustrated with some supplementary information. On the left side of the flowchart, it is shown that updates are received from other sites 20, 30 in step 401a. Furthermore, in step 401b, updates from site 10 itself, including the aforementioned metadata information, can be received. According to step 410, a map can be used to receive map-related data, as will be discussed in detail below. In step 402, the set of data and / or metadata is (re)calculated, which may result in a selected data and / or metadata dataset 403. In an optional step 406, if the data and / or metadata has changed, V2X message triggering and / or retransmission can be performed. On the right side of the flowchart, it is shown that step 401c is performed, according to which V2X message transmission of requests from other sites 20, 30 is performed. In the next step 404, data and / or metadata are compiled using the defined data and / or metadata dataset 403. In the next step 405, a V2X message is sent.

[0052] Figure 3 It shows Figure 2 The implementation method is modified in some ways. In steps 305a and 305b, station 10 receives a message from other stations 20 and 30. This message may be a V2X message. Then, in steps 301 and 302, adjusted data and / or metadata can be calculated based on knowledge of the other stations 20 and 30 regarding the message received in steps 305a and 30, as well as environmental knowledge regarding their specific needs. In further steps 310a and 310b, the adjusted data and / or metadata can be used to send the V2X message to the receiving stations 20 and 30.

[0053] In one implementation, station 10 can use information received from other stations 20, 30 via V2X messages, such as CAM (Cooperative Awareness Message), VAM (VRU Awareness Message), CPM (Collective Awareness Message), and / or MCM (Manoeuvre Coordination Message). Generally, any V2X message containing information about the sending station 20, 30, such as location, behavior, station type, its environment, and / or traffic participants in those environments, can be used. This information can be received and accumulated without the need for a dedicated information exchange for metadata generation. Station 10 can use this received information to understand the presence of potential recipients or potential recipient stations and to improve its anticipation of recipient needs by understanding their locations, behaviors, and driving tasks. This can also reflect the needs of the respective stations 20, 30 if station 10 uses data and metadata similar to those in the received messages when sending (back) V2X messages.

[0054] In another implementation, station 10 may use a map stored at station 10 or connected via a network to obtain semantic information about the environment, such as road type, intersections, restrictions, driving speed, connectivity with other roads, traffic lights, lane information, and information about the environment of potential receiving stations 20 and 30. This can help anticipate the driving tasks of receiving stations 20 and 30 and determine which data / metadata is needed by receiving stations 20 and 30. Whether sender 10 and receivers 20 and 30 are part of the same environment, such as whether they are on the same highway, or, for example, one on a highway and the other in a parking lot, can make a difference. Similarly, the number of stations near or located at intersections, as well as the number of stations that serve as additional information sources, can all influence the metadata configuration.

[0055] In another implementation, to compute the metadata configuration, a predefined configuration file for the relevant functions and use cases can be used. All of the above information can then be used to select a configuration file, for example, based on information about potential recipients, such as configuration file definitions and the selection of driving scenarios, such as approaching or leaving an intersection, turning right or left or going straight, and scenario complexity such as highway or urban scenarios.

[0056] In another implementation, not only metadata is configured. If the metadata configuration in this section indicates low information value, site 10 can eliminate a portion of the payload data.

[0057] A method according to one embodiment of the invention includes the following steps. Data included during the generation of a V2X message for transmission can typically be the result of measurements, such as the relative distance to a detected object measured by onboard sensors of a vehicle, or an estimate, such as 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 of all measurements or estimates in the V2X message. For each of these values, a normalized V2X message typically includes a confidence indicator representing the absolute accuracy of the estimate of the value with a 95% standard confidence level. However, this confidence indicator may be insufficient for the receiver to determine whether the V2X data can be used for road traffic-related functions, particularly safety-critical functions. An alternative could be to match a series of measurements or estimates to a probability density function (PDF) by means of probability distribution fitting. For example, this can be done during the calibration process of a vehicle measurement and / or estimation system. The PDF can be described as metadata indicating the distribution type in the V2X message and characterized by its parameterization. In this way, the receiver can gain a better understanding of the accuracy of the V2X data and can check whether this data meets the requirements of its current driving functions. For example, the receiver might require that a certain location in the V2X data is within a given lane with a minimum probability p. This condition can be checked by evaluating the PDF of the corresponding location in the received V2X data. Furthermore, the confidence interval of the parameterized PDF can be calculated.

[0058] When V2X data can be used for driver assistance or autonomous driving functions, the receiver may need to understand the set of operating conditions required for the safe operation of the system that measures or estimates the transmitted V2X data. These conditions may include environment-related, geographical, and temporal limitations, traffic and road characteristics, and the vehicle's level of automation. The receiver can then check whether these operating conditions cover its current driving conditions. In this case, the receiver can use the received V2X data for its driving functions.

[0059] During V2X message generation, not all data measured or estimated by the sender can typically be included in the V2X message. Instead, the sender can choose a subset of this data to include in the generated message, for example, using message generation rules. Metadata can be used to describe the completeness of the data included in the V2X message, i.e., the range of 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 the minimum amount required by the receiver, or whether the included V2X data contains specific data elements or areas required by the receiver.

[0060] Metadata can be used to describe the QoS level or the value of one or more QoS metrics, which is the estimated quality of service (QoS) that the receiver can expect from a V2X communication connection.

[0061] A consistency value indicates the probability that a measured or estimated piece of data is correct. A low consistency value may indicate that the data represents an incorrect estimate or invalid measurement, such as a perceived non-existent (ghost) object. A consistency value can be calculated by estimating the distance between a measured or estimated piece of data and its true value (e.g., from a map), or its value at a previous time point, or its value predicted by a Kalman filter. Algorithms such as Deep Learning (DL) and Machine Learning (ML) can also be used to predict values ​​and calculate data consistency.

[0062] The receiver can receive V2X messages and interpret their security metadata to determine whether they are suitable for its current driving function. By processing the metadata, the receiver 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 V2X data for its driving function. The V2X data can still be used, for example, as a redundancy check against data obtained from other sources.

[0063] A description of confidence values ​​for V2X data can include defining the type of probability density function best suited for measuring or estimating the data distribution. Each distribution type can be defined by a set of statistical parameters that allow the calculation of the probability that the true value falls within any range of values.

[0064] Some examples of probability density functions can be as follows: The normal or Gaussian distribution, characterized by its mean or expected value μ and its standard deviation σ. The log-normal distribution, characterized by the mean or expected value μ and standard deviation σ of the natural logarithm of the variable. The Pareto distribution, characterized by its scale parameter x. m The distribution is characterized by its shape parameter α. A continuous uniform or rectangular distribution is characterized by its minimum value A and its maximum value B. A Poisson distribution is characterized by its rate λ. An exponential distribution is characterized by its rate λ. A gamma distribution is characterized by its shape k and its scale θ. A Rayleigh distribution is characterized by its scale θ. A Rice distribution is characterized by its scale σ and the distance between its reference point and the centroid of the distribution.

[0065] Operating conditions of a system that measures or estimates transmitted V2X data may include environmental, geographical, and temporal constraints, traffic and road characteristics, and the vehicle's level of automation. Some examples of these conditions are as follows. Environmental conditions may include weather, such as sunny, cloudy, light rain, storm, snow, ice, fog, haze, and lighting, such as minimum and maximum illuminance. Geographical constraints may include specific areas, such as countries, states, school districts, yards, parking lots, etc. Temporal constraints may involve permitted operating hours, such as 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 type (passenger cars, trucks / tractors, buses, motorcycles). Road characteristics may include road type, such as street, highway, expressway, divided / undivided road, number of lanes in each direction, and road surface, such as asphalt, concrete, gravel, cobblestone, off-road. The vehicle's level of automation may include, for example, longitudinal automation, lateral automation, and driving automation levels according to SAE J3016. Equipment in physical infrastructure can include, for example, traffic lights on poles / gantry frames and sensors (video, radar, lidar).

[0066] The integrity of measured or estimated V2X data can be described in the following ways: The integrity can be described by the number of measured or estimated elements / objects contained in the message and / or the total number of elements / objects measured or estimated by the sender. The integrity can be described by (a) one or more geographic areas covered by the measured or estimated data contained in the V2X message. The integrity can also be described by (a) one or more geographic areas not covered by the measured or estimated data contained in the V2X message. The integrity can also be described by the 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.

[0067] The estimated Quality of Service (QoS) of a V2X communication connection can be described using the following metrics and mechanisms and is included in the metadata of the V2X message.

[0068] When message transmission is (semi-)periodic, the message rate can describe the frequency or range of repetitions of a V2X message. The number of repetitions can describe the number of times the message is transmitted (this may be undefined for periodic messages with indefinite transmissions).

[0069] A message counter can increment by 1 with each V2X message transmission, allowing the receiver to detect potential message loss. Error detection and / or correction codes can be added to V2X messages to enable the receiver to detect transmission errors, such as parity bits, checksums, cyclic redundancy check (CRC), cryptographic hash functions, or to correct them, such as forward error correction (FOR) or hybrid automatic repeat requests (HARQs). Transmitted messages can include their measured channel load, such as channel occupancy rate, allowing the receiver to better estimate the current channel state, which can directly impact expected V2X communication performance. Transmitted messages can include their average measured latency, the time interval between message generation and actual message transmission. This latency may primarily stem from the time required for the sender to buffer generated messages while detecting V2X channel occupancy, for example, when using CSMA / CA media access control protocols. The receiver can use the measured latency to better estimate the current channel state. Transmitted messages can also include their measured channel reliability, such as the average packet error rate of received V2X messages, allowing the receiver to better estimate the current channel state. Alternatively, or additionally, the QoS level, such as a value between 0 and 1, can be calculated from one or more of the described metrics and included in the metadata of the V2X message.

[0070] The consistency value of measured V2X data can be calculated in different ways. When a sensor detects an object outside its sensing range, the object may not exist and may have been detected due to a measurement error. In this case, the measured object may have a low (or zero) consistency value. If the detected object is detected by multiple independent sensors and / or also sensed via received V2X data (e.g., cooperative sensing messages) and is within the sensing range of all these sensors, the object may have a high probability of presence. Therefore, the measured object will have a high consistency value. If the object has been sensed for a long time, it may have a high probability of presence, and vice versa. If the data of the sensed object is within a reasonable range of the values ​​predicted by the Kalman filter, such as future position, velocity, acceleration data, direction of travel, etc., it may have a high probability of presence, and vice versa. Deep learning (DL) and machine learning (ML) can also be applied to predict values ​​and calculate data consistency by analyzing vehicle sensor data and historical records.

[0071] The following describes possible prerequisites. At the point of site commissioning, its sensor and data fusion systems can be registered in a central registry using metadata describing the quality and conditions of the provided data. Optionally, conceptual assumptions can also be stored in the metadata. For subsequent verification of authenticity, the site's public key 504 and 604 can also be included. All data contained in dataset 501 can be signed using the provider's private key, such as... Figure 5 and Figure 6 As shown in the image. Figure 5 The site's signature metadata dataset 501 shown may include a site model identifier 502, site metadata 503, and the site's public key 504.

[0072] Figure 6 A public key infrastructure 605 according to one embodiment is shown, wherein a site's public key 604 can be derived using a provider's public key 601. Figure 6 In the embodiment shown, the site's public key 604 is not included in the site's metadata 501. The site's public key 604 is provided using public key infrastructure 605.

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

[0074] Figure 8 A signed data message with metadata for a site is shown according to one embodiment. In this embodiment, with Figure 7 Conversely, the signature data message 801 includes sensor data 820, model identifier 802, and additional metadata 810.

[0075] Each site (10, 20, 30) can store a local copy (cache) of the central registry. This local copy contains all metadata signed with certificates, thus potentially eliminating the need to exchange data with the central registry for every V2X data transfer. This cache can be updated periodically.

[0076] A method according to one embodiment of the present invention may include the following steps, such as Figure 9As shown in the diagram. In step 901, the transmitting station 10 can prepare a data message by acquiring sensor data, attaching a site model identifier (model identifier), and then signing the V2X message using the station's private key. In step 902, the transmitting station 10 distributes the data message via V2X. In step 903, the receiving station 20 receives the V2X message. In step 904, the receiving station 20 extracts the model identifier of the transmitting station 10 from the received message. In step 905, the receiving station 20 retrieves the model information corresponding to the model identifier from the cached central registry. If the authenticated trust information corresponding to the transmitting station 10 is not found in the local registry, the receiving station 20 can request a current copy of the central registry. If the receiving station 20 is not within coverage, or if the certificate is not found in a new version of the registry, the receiving station 20 can reject the incoming message. In step 906, the receiving station 20 can check 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. Otherwise, receiving station 20 can reliably know the provider of transmitting station 10. Therefore, receiving station 20 can reliably obtain the correct public key of transmitting station 10. In step 908, additionally, during the verification of the model information signature, receiving station 20 can check the correctness and integrity of the content. If the model information is incomplete, altered, or incorrect, the received data message can be discarded (913). In step 909, receiving station 20 possesses the correct model information of transmitting station 10. Using the site public key of transmitting station 10, receiving station 20 can verify the received data message. In step 910, if the signature of sending station 10 cannot be verified, the received message can be discarded (913). Otherwise, receiving station 20 can reliably know the transmitting station 10. Therefore, receiving station 20 can reliably obtain the correct public key of transmitting station 10. In step 911, additionally, during the verification of the data message signature, receiving station 20 can check the correctness and integrity 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 know that the transmitting station 10 has sent data, that the data message is complete and correct, and that the receiving station 20 possesses the correct site metadata of the transmitting station 10. The receiving station 20 can now use this data and, using the site metadata of the transmitting station 10 and the security requirements of dedicated security-critical functions, verify the possible uses of the received data.

[0077] In another implementation, metadata can involve aggregations at different levels, such as point clouds and / or perceived objects.

[0078] In another implementation, an additional step can be included to check the validity of the certificate and discard the relevant data if the certificate is too old. The validity of the information can correspond to the time since the certificate was issued.

[0079] In another implementation, in addition to certifying the quality of the transmitted data, the certificate may also involve a public or private key that enables the site to sign and encrypt the data.

[0080] In another implementation, data message 801 includes additional metadata (e.g., space- or scene-related), such as... Figure 8 As shown in the image.

[0081] In another implementation, the site model identifier can point to a lookup table where multiple separate metadata (e.g., information about sensors, fusion components, hardware information, and software information) can be stored separately.

[0082] In another implementation, a Vehicle Identification Number (VIN) is used instead of a Model Identifier as the identifier.

[0083] In another implementation, a different scheme can be used to authenticate and sign messages, such as a group key.

[0084] In another implementation, if it is impractical to store all site models globally in a local cache of the registry, only a subset of the registered models can be cached locally, such as models registered in a region (e.g., the European Union).

[0085] A method according to an embodiment of the present invention, such as Figure 10 As shown, and may include the following steps: In step 1001, the first station 20 may distribute its requests for V2X information that allows it to operate its functions in a functionally safe manner. The second station 10 may receive the requests from the first station 20. In step 1002, the second station 10 may determine whether the received requests meet the required requirements based on a check, and abort if they do not. In step 1003, the second station 10 may assemble or provide information according to the requests based on the determination. 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 transmit the assembled information to the first station 20.

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

[0087] 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 an ODD (Operational Design Domain), which can describe operating conditions such as road type, speed, weather conditions, and / or relevant traffic participants. Another element may be functional requirements (e.g., accuracy of measurements or estimates (e.g., position, speed, acceleration, yaw rate, size, angle, object type, trajectory), accuracy of time sources (e.g., GPS time, Network Time Protocol), [minimum, maximum] vehicle speed). Another element may be Quality of Service (QoS) requirements (e.g., payload data in [minimum, maximum] bytes, maximum tolerable latency or data timeliness in [minimum, maximum] milliseconds, data rate in [minimum, maximum] megabits per second). Another element may be the required level of redundancy (e.g., information update rate, minimum number of unrelated information sources). Another element may be security levels and qualifications (e.g., Automotive Safety Integrity Level (ASIL) for the sender system development). Another element could be permissible failure and degradation modes (e.g., the ability to detect perception degradation, such as sensor blind spots, decalibration, or misalignment). Requirements could include degradation constraints (e.g., reduced sensing range due to adverse weather conditions).

[0088] according to Figure 11 The example shown, given vehicle 20 (the second station in this example), allows the execution of environmental model functions that need to adhere to specific requirements regarding the content of the environmental model. These specific requirements may include the following: The bounding boxes of surrounding vehicles can be within 100 meters of the station and 10 meters of the road. The centroid positions of surrounding vehicles can be within 100 meters of the station and 10 meters of the road, with an accuracy of 2 meters in a specific projection and coordinate reference system. The positions of surrounding vulnerable users can be within 100 meters of the station and 10 meters of the road, with an accuracy of 50 centimeters in a specific projection and reference system. Vegetation can be treated as points, and buildings can be treated as polygons. At station 10 (in... Figure 11 The intelligent traffic light in this implementation can perform the following functions: creating an environmental model from multiple sources and providing information with a wide range and different granularities, 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 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 layer creation. Another operation can be projection into different coordinate systems.

[0089] exist Figure 11 In step 1101 of the implementation, vehicle 20 can send its request to station 10, which is able to fulfill the request and format the information in a manner that satisfies all the requirements of vehicle 20 in step 1104. In step 1105, the formatted information can be transmitted to vehicle 20. This also has advantages in terms of channel utilization compared to simply sending raw data.

[0090] According to another Figure 12 In the embodiment shown, the first vehicle 20 can send its request in step 1201a. Station 10 can receive these requests in step 1202, examine them, and decide to satisfy them. Station 20 can format the data in step 1203 and send the data to vehicle 20 according to these requests in another step 1210a. Later, the second vehicle 30 can send its request in step 1201b. Station 10 can compare the requests of both the first and second vehicles in step 1202' and determine that the request of the first vehicle 20 is included in the request of the second vehicle 30. Station 10 can decide to satisfy the request of the second vehicle 30 in step 1203' and format the data according to the request of the second vehicle 30. Station 10 can then send the formatted data to the first vehicle 20 and the second vehicle 30 in steps 1210a and 1210b. Since the request of the first vehicle 20 is included in the request of the second vehicle 30, the functions of the first vehicle 20 can use this data, even though this data satisfies the request of the second vehicle 30.

[0091] According to one implementation (not shown), a first vehicle may send its request R1, and a second vehicle may send its request R2. A third vehicle may receive both requests R1 and R2, examine them, and determine whether both R1 and R2 are satisfied. To avoid sending two datasets (one satisfying R1 and one satisfying R2), the third vehicle may calculate a minimum set of requests R3 that satisfies both R1 and R2. If the third vehicle can satisfy request R3, it can format and send the data accordingly. The first and third vehicles can receive this V2X data and use it for their driving functions, as both of them can satisfy these requests. If the third vehicle cannot satisfy request R3 but can satisfy R1 and / or R2, it can format and send the data according to R1 and / or R2.

[0092] As an alternative to termination, if the second site cannot meet the requirements, it can send a rejection message to notify the first site. Whether the second site rejects silently or with a rejection message may depend on the given use case.

[0093] If there are different possibilities or compromises to satisfy the function, transmitting station 20 may send more than one set of requirements (optionally in a priority list). Receiving station 10 can then check whether one or more sets of requirements can be satisfied, increasing the chance that at least one set of requirements is satisfied. If the list of requirements is prioritized, station 10 can check the requirements from highest to lowest priority to find the highest-priority set that can be satisfied. Then, if at least one set of requirements from station 20 can be satisfied by station 10, station 10 can satisfy the requirements of station 20.

[0094] Transmitting station 20 can uniquely identify each set of requirements before transmission. If receiving station 10 can satisfy one or more sets of requirements, receiving station 10 can include the unique identifiers of the satisfied sets of requirements in the message sent to transmitting station 20. When transmitting station 20 receives information from receiving station 10, the included identifiers help transmitting station 20 check which requirements are satisfied. Transmitting station 20 can then forward the information and the identifiers of the satisfied requirements to this function.

[0095] A method according to an embodiment of the present invention in Figure 13 The diagram illustrates and includes the following steps. In step 1302, station 20 may transmit an identifier of its current driving function. In step 1303a, station 10 may receive the function identifier and match it with the corresponding requirement in its internal database. In step 1303b, station 10 may determine whether it can provide V2X data that meets the required requirements, and if not, abort. In step 1304, station 10 may provide data according to the requirements of station 20, and according to step 1305, transmit information related to the function identifier received from station 20, along with the requirement set, to station 20. In step 1306, station 20 may receive data and the function identifier from station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0096] Figure 14Another embodiment of the method according to the invention is shown, the method comprising the following steps. In step 1402, station 20 may transmit an identifier and database version of its current driving function. In step 1403a, station 10 may receive the function identifier and check the database version. In step 1403b, station 10 may match the function identifier with a corresponding requirement in its internal database. In a further step 1403c, station 10 may determine whether it can provide V2X data that meets the required 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, transmit information related to the function identifier received from station 20, along with a set of requirements, to station 20. In step 1406, station 20 may receive data and the function identifier from station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0097] Figure 15 Another embodiment of the method according to the invention is shown, the method comprising the following steps. In step 1502, station 20 may distribute an identifier of its current driving function along with further options. In step 1503a, station 10 may receive the function identifier and, considering the provided options, match the function identifier with a corresponding requirement in its internal database. In step 1503b, station 10 may determine whether it can provide V2X data that meets the required requirements, and if not, abort. In step 1504, station 10 may provide data according to the requirements of station 20, and, according to step 1505, transmit information related to the function identifier received from station 20, along with a set of requirements, to station 20. In step 1506, station 20 may receive the data and function identifier from station 10, check whether its requirements are met, and if so, forward the information to its current driving function.

[0098] These requirements can be based on public standards and, for example, can be stored in a database responsible for managing and accessing the requirement information. This database could be, for example, at sites 10, 20 and / or on a central server. Requirements associated with functional identifiers in the database can include the following: One requirement may relate to the ODD (Operational Design Domain), which describes operating conditions such as road type, speed, weather conditions, and / or relevant traffic participants. Another requirement may relate to functional requirements (e.g., accuracy of measurements or estimates (e.g., location, speed, acceleration, yaw rate, size, angle, object type, trajectory), accuracy of time sources (e.g., GPS time, Network Time Protocol), [minimum, maximum] vehicle speed). Another requirement may relate to Quality of Service (QoS) requirements (e.g., payload data in [minimum, maximum] bytes, maximum tolerable latency or data timeliness in [minimum, maximum] milliseconds, data rate in [minimum, maximum] megabits per second). Another requirement may relate to the required level of redundancy (e.g., information update rate, minimum number of unrelated information sources). Another requirement may relate to safety levels and qualifications (e.g., the Automotive Safety Integrity Level (ASIL) for sender system development). Another requirement may relate to permissible failures and degradation modes (e.g., the ability to detect perception degradation, such as sensor blind spots, decalibration, or misalignment. Requirements in this context may include degradation constraints (e.g., reduced perception range due to adverse weather conditions)).

[0099] Function identifiers can be alphanumeric identifiers.

[0100] The first example can be combined Figure 16 Give, the Figure 16 Vehicle 20 performs autonomous driving functions, which require the environment-related model to conform to specific requirements regarding its content. One specific requirement could be the bounding boxes of surrounding vehicles within 100 meters of the site and 10 meters of the road. Another specific requirement could describe the centroid positions of surrounding vehicles within 100 meters of the site and 10 meters of the road, with an accuracy of 2 meters in a specific projection and coordinate reference system. Yet another specific requirement could describe the positions of surrounding vulnerable users within 100 meters of the site and 10 meters of the road, with an accuracy of 50 centimeters in a specific projection and reference system. According to yet another specific requirement, vegetation can be described as points, and buildings can be described as polygons. On entity 10, for example... Figure 16The intelligent traffic light shown in the diagram can perform the following functions: creating high-definition maps from multiple sources, providing information over a wide range with varying granularities, and performing the following operations: One operation could be LiDAR point cloud acquisition. Another operation could be image acquisition from front, rear, and side cameras. Another operation could be radar measurement. Another operation could be data fusion of sensor measurements and perceived objects. Another operation could be object detection and classification. Another operation could be layer creation. Another operation could be projection onto different coordinate systems.

[0101] according to Figure 16 In the embodiment shown, vehicle 20 may transmit a function identifier, such as an intelligent traffic light, to entity 10 in step 1602. 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.

[0102] Figure 16 In particular, an example of vehicle 20 is shown, which sends its function identifier to intelligent traffic light 10, which can format its environment-related model data to meet the requirements of vehicle 20 and send the formatted environment-related model to vehicle 10.

[0103] Public or published standards can be implemented when all requirements are collected in a database, especially mapping functionality to its requirements. Here is an example excerpt from a database example: Function identifier Mapping requirements Mapping Required Value ... AD80 Vehicle BB zero AD80 The accuracy of the centroid position of surrounding vehicles (in meters). 2 AD80 Center of mass reference frame RD / 83

[0104] RD / 83, ETRS89, and 42 / 83 can be three available German reference standards. Vehicle 20 can simply send AD80 (an exemplary function, which could be autonomous driving version 80) as an identifier for its function identifier. Upon receiving this identifier, entity 10 can query the database for requirements and inspect them. Entity 10 can then fulfill the requirements and compile information for vehicle 20. Figure 16 This example illustrates the point.

[0105] In another implementation, public standards can list multiple options for each function in a database. In step 1502, references to the options can be distributed along with identifiers, such as according to... Figure 15 The implementation method shown.

[0106] Multiple options can be selected by vehicle 20, either as a combination (AND) or as a selection (OR). If entity 10 receives an option as a selection (OR), it can select a set of requirements and continue processing using that set. Preferably, these options are labeled, which allows entity 10 to indicate which requirements it must meet when sending compliance information to vehicle 20.

[0107] In another example, each function may have options, as shown in the exemplary database excerpt below. Function identifier Options Mapping requirements Mapping Required Value ... AD80 Vehicle BB zero AD80 Centroid accuracy (in meters) 2 AD80 1 Center of mass reference frame RD / 83 AD80 2 Center of mass reference frame ETRS89 AD80 3 Center of mass reference frame 42 / 83

[0108] The functionality of vehicle 20 may require RD / 83 as a reference standard. As a result, vehicle 20 can send option 1 along with its identifier in the first step 1502, such as... Figure 15 As shown in the image.

[0109] In another implementation, there may be no request from the first site 20. Entity 10 can select a set of requests in the database that matches its data, and can then distribute the data along with an identifier that references that set of requests in the database. A potential recipient can then determine whether the requests satisfied by entity 10 and referenced in the V2X message are consistent with its own response, and whether the data can subsequently be used.

[0110] In another implementation, standardized requirements may not be associated with functional identifiers, but rather each requirement may have a unique identifier. A site can select its requirements from a database and then reference a set of individual requirements in its transmission, with or without the requirements.

[0111] In similar circumstances, a site may select a single requirement, as illustrated in the following example database excerpt. Require# Mapping requirements Mapping Required Value 1 2 Vehicle BB zero 3 Centroid accuracy (in meters) 2 4 Center of mass reference frame RD / 83 5 Center of mass reference frame ETRS89 6 Center of mass reference frame 42 / 83 13 Vehicle speed >20 km / h 14 Vehicle speed <130 km / h

[0112] For example, vehicle 20 might require RD / 83 as its center of gravity reference standard, and its speed might need to be between 20 and 130 km / h. Therefore, it can select requirement identifiers 4, 13, and 14 and send these requirement identifiers via V2X communication.

[0113] In another implementation, the identifier can be sent along with the version number of the database it relates to. This allows for ensuring compatibility between databases on different sites. Figure 14 As shown in the image.

[0114] Receiving site 10 may have been last updated in 2020, while transmitting site 20 may have been last updated in 2023. Standard version 17.2 may have been released in 2020. A new version 18 may have been released in 2023.

[0115] Therefore, the transmitting station 20 may refer to version 18 when distributing its function identifier. The receiving station 10 may receive this identifier along with the version being used and determine that these versions are incompatible. Therefore, the receiving station may abort the process.

[0116] An alternative could be to respond using the version of the receiving station 10, so that the transmitting station 20 can analyze whether it can accept the request stored in the lower version (17.2 in our example). The process can then continue using the lower database version.

[0117] The above explanation of the embodiments describes the invention in the context of examples. Of course, the various features of these embodiments can be freely combined with each other, provided it is technically feasible, without departing from the scope of protection of the invention.

Claims

1. A method (100) for evaluating the requirements for road traffic-related functions of a site (10), wherein the method (100) includes the following steps: - Based on the model identifier extracted from the received messages (701, 801), request (101) model information from the registry, wherein the model information includes metadata (810) related to the site model, and wherein the model information is stored in the registry. - Based on the evaluation of the metadata (810) contained in the model information (702, 802), the data of the messages (701, 801) are analyzed (102) for use in road traffic-related functions, wherein the evaluation includes checking whether the data of the messages meets at least one requirement of the road traffic-related functions. - Based on the analysis (102), determine (103) the availability of the data for the road traffic-related functions.

2. The method (100) according to claim 1, characterized in that, The method includes the following further steps: - The model information (702, 802) is verified by checking the digital certificate of the model information (702, 802) using the provided public key (601) stored at the site (10), wherein the public key (601) relates to the provider, and if the check is positive, the method proceeds to the step of providing the site's public key (504, 604) from the metadata (810) of the verified model information (702, 802). - The message is verified based on the verification, and if the verification result is positive, the method continues to the next step.

3. The method (100) according to claim 2, characterized in that, The method includes at least one of the following further steps during verification: - Check the correctness and completeness of the content of the model information (702, 802), and if the result of the check is positive, the method (100) continues to the next step, and / or if the result of the check is negative, discard (913) the message (701, 801). - Check the validity of the digital certificate of the model information (702, 802) based on a predefined time limit, wherein the time limit is specified based on the time since the digital certificate was issued, and if the validity is less than the predefined limit, the method continues to the next step.

4. The method (100) according to claim 2, characterized in that, The method includes the following further steps during verification: - Check the correctness and integrity of the content and / or data of the message (701, 801), and if the check is positive, the method (100) continues to the next step, and / or - If the result of the check is negative, discard (913) the received message (701, 801).

5. The method (100) according to claim 2, characterized in that, During verification, if the result of the check is positive, the method continues with the step of providing the site's public key (604) using a separate public infrastructure key.

6. The method (100) according to any one of the preceding claims, characterized in that, The method (100) includes the following further steps: - Extract the model identifier (702, 802) from the received messages (701, 801), wherein the model identifier (702, 802) indicates a site model for each site type in the registry, wherein the site model includes model information (702, 802) for each site type, wherein the model information (702, 802) includes at least metadata (810), and includes sites with the same equipment being assigned to the same site model.

7. The method (100) according to any one of the preceding claims, characterized in that, The registry is located at the site (10) and / or at the central registry of the communication network.

8. The method (100) according to any one of the preceding claims, characterized in that, The model information (702, 802) for each site model is stored in the registry and includes at least one of the following: - Metadata for at least one sensor at the site, - Metadata for the sensor set at the site, - Metadata for data fusion components, and / or - Metadata for a mix of raw and fused data.

9. The method (100) according to any one of the preceding claims, characterized in that, The site type is vehicles and / or infrastructure and / or vulnerable road users.

10. A station (10) for assessing the requirements of road traffic-related functions, comprising means for performing the method (100) according to any one of the preceding claims.

11. A computer program (50) comprising instructions that, when the computer program (50) is executed by a computer (11) of a site (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 that, when executed by a computer (11) of a site (10), cause the computer (11) to perform the steps of the method (100) according to any one of claims 1 to 9.

Images