Method for providing information according to satisfaction of set of requirements

Abstract

A method for providing information as a function of satisfaction of a set of requirements, comprising the steps of:-providing a database for stations, where the database indicates, based on a given standard reference, which identifier for a function related to road traffic corresponds to which set of requirements, where the set of requirements indicates a rule for which identifier for a function related to road traffic corresponds to which set of requirements; the rule allows the other station to operate its function related to road traffic in a functional or non-functional manner; receiving an identifier of another station for a function related to the road traffic; analyzing the identifier based on a coordination of the received identifier with the road traffic related function and the corresponding set of requirements, and if a decision based on the coordination is that: the set of requirements is met, then the method continues the next step; providing data for a function related to the road traffic based on the set of requirements, wherein the data comprises the received identifier associated with the set of requirements.

Description

A method for providing information based on the satisfaction of a set of requirements. Technical Field

[0001] This invention relates to a method for providing information based on the fulfillment of a set of requirements. Furthermore, this invention relates to a computer program, a station, and a storage medium for this purpose. Background Technology

[0002] The structure of vehicle-to-everything (V2X) messages is defined by standards development organizations (SDOs), including the European Telecommunications Standards Institute (ETSI) and SAE International. Specific 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 been standardized.

[0003] Currently, V2X data is typically derived from cluster outsourcing. The driver remains 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 a safe CAD system (Cooperative Automated Driving) primarily revolves around creating a comprehensive system in which 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 homologation. The system can 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 in the case of ETSI. Disadvantageously, each time a new vehicle is developed, entirely new homologation may be required for all conceivable AVP pairings consisting of garages / vehicles to ensure safety across all possible combinations.

[0005] US2021219139 A describes a method for enhancing trust in received V2X data by incorporating sender-side metadata, such as vehicle manufacturer, technical equipment, vehicle age, hardware and software implementation details, and the authentication level of the sending vehicle, into V2X messages.

[0006] WO2022 / 122450 A1 describes incorporating a “safety segment” into a V2X message to enable its availability for safety-related driving functions. This safety segment may include safety level, failure rate, development process indications, effective time, failure model, and / or confidence level of 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 other sources (e.g., objects detected by onboard sensors, the reasonableness of the sender's location using RSSI, and previous V2X messages). Summary of the Invention

[0008] The aforementioned objective is achieved by a method having the features of claim 1, a station having the features of claim 9, a computer program having the features of claim 10, and a computer-readable storage medium having the features of claim 11. Further features and details of the invention are disclosed in the dependent claims, the specification, and the drawings. The features and details described in conjunction 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 vice versa in each case, so that disclosures relating to various aspects of the invention can always be cross-referenced.

[0009] This objective is achieved, in particular, by a method for providing information based on the satisfaction of a set of requirements. The method includes the following steps: - providing a database for a station, wherein the database, based on a given standard reference, specifies which identifier corresponds to which set of requirements for a road traffic-related function, wherein the set of requirements specifies rules that allow another station to operate its road traffic-related functions in a functional or non-functional manner; - receiving identifiers from another station for road traffic-related functions; - analyzing the received identifiers based on a coordination between the road traffic-related function and the corresponding set of requirements, and if the decision based on the coordination is that the set of requirements is satisfied, the method proceeds to the next step; - providing data for the road traffic-related function based on the set of requirements, wherein the data includes the received identifiers associated with the set of requirements.

[0010] This offers several advantages: it avoids transmitting complete sets of requests. Furthermore, by utilizing very compact identifiers involving databases, it allows for reduced message complexity and channel load. It also allows stations and / or vehicles and / or infrastructure components to advantageously exchange information with each other. This advantageously enables performance improvements in road traffic-related applications, particularly safety-critical applications. Furthermore, it advantageously improves traffic safety and efficiency and / or driver comfort, and significantly enhances the reliability of driver assistance and / or autonomous driving applications. Moreover, it allows for open and more flexible vendor-agnostic V2X systems. Additionally, it offers the advantage of eliminating the need for centralized entities or standards to make decisions regarding various formats, and eliminating the need for transformations through third parties.

[0011] Possibly, the database includes one or more sets of requirements for road traffic-related functions, wherein during reception, the method includes the additional steps of: - receiving information regarding references to one or more sets of requirements corresponding to the road traffic-related functions, and - wherein during analysis, the method includes the additional steps of: - coordinating the received information with the coordinated set of requirements for the road traffic-related functions based on the references, and if the decision based on the coordination is that at least one set of the referenced requirements of the set of requirements is satisfied, the method proceeds to the next step, wherein information based on at least one set of the set of requirements is provided, and wherein the data further includes the received information for reference.

[0012] Possibility exists: the information used for citation includes indications of citations relative to a single corresponding group and / or combinations of corresponding groups, wherein during analysis, the method includes the additional steps of: - coordinating the received information with one or more sets of requirements for coordinated road traffic-related functions based on the citation, and if the decision based on coordination is that at least one set of the requirements cited by the one or more sets is satisfied, the method proceeds to the next step, wherein the requirements cited by the one or more sets are provided.

[0013] By using references, it is possible to avoid transmitting the entire request group. Furthermore, this has the advantage of reducing message complexity and channel load due to referencing.

[0014] It is conceivable that the method includes the following additional steps: - providing a database for the station based on a given standard reference, the database having a description of which identifier corresponds to one or more requirements; - analyzing the received at least one identifier based on the coordination of at least one identifier with one or more corresponding requirements, and if the decision based on the coordination is that all requirements are met, the method proceeds to the next step.

[0015] This has the advantage of improving the selection of specific requirements from the database. Requirements do not necessarily have to be associated with a function identifier, but each requirement has a unique identifier. A station can advantageously select its requirements from the database and then reference a group of individual requirements in its transmitted messages.

[0016] Possibly, the database used for the station includes a version indicator of the database stored at the station, wherein the method includes the following additional steps: - receiving a version indicator relating to a version of a database at another station; - verifying the similarity between the two version indicators, and if the comparison is positive, the method proceeds to the next step.

[0017] In addition, the method may include the following additional steps during the verification process: - verifying the similarity between the two version indicators, and if the stored version indicator is lower than the received version indicator, the method proceeds to the next step: - providing data for road traffic-related functions based on a set of requirements related to information in the station's database.

[0018] This ensures compatibility between the site's databases.

[0019] The following possibility exists: the method includes at least one of the following steps: - querying a matching set of requirements from the database based on the received identifier, - sending the provided data to the other station via a message, particularly a V2X message.

[0020] This makes it possible to optimize the performance of the method according to the invention. Furthermore, it has the advantage that stations can advantageously exchange information with each other in a more efficient manner.

[0021] Another possibility exists: requiring the group to describe the content of the model based on the identifier relating to the environmental model, wherein the environmental model is based on information about the surrounding landscape and / or on information about the bounding boxes of surrounding stations and / or infrastructure and / or similar features.

[0022] This has the advantage of allowing decisions to be made based on relevant information about the environment.

[0023] In another aspect of the invention, a computer program, particularly a computer program product, can 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 described in detail with reference to the method according to the invention.

[0024] In another aspect of the invention, a station for providing information based on the fulfillment of a set of requirements may be provided, the station being designed to implement the method according to the invention. For example, a computer may be provided as the station, the computer implementing 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 which can be read from the non-volatile data memory by the processor for execution.

[0025] 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 station, 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. For example, the storage medium can be integrated into a computer at a station.

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

[0027] Further advantages, features, and details of the invention will become apparent from the following description, in which embodiments of the invention are described in detail with reference to the accompanying drawings. In this context, features mentioned in the claims and in the specification may be important to the invention individually or in any combination. Figure 1 illustrates a method, computer program, storage medium, and apparatus according to an embodiment of the present invention; Figure 2 illustrates a method according to an embodiment of the present invention; Figure 3 illustrates a method for message flow and matching of data / metadata groups according to an embodiment of the present invention; Figure 4 illustrates a method for calculating data / metadata groups and using updated groups according to an embodiment of the present invention; Figure 5 illustrates a signed station metadata group according to an embodiment of the present invention; Figure 6 illustrates a public key infrastructure according to an embodiment of the present invention; Figure 7 illustrates a signed TX station data message according to an embodiment of the present invention; Figure 8 illustrates a signed TX station data message with metadata according to an embodiment of the present invention; Figure 9 illustrates a flowchart of a verification sequence according to an embodiment of the present invention; Figure 10 illustrates a sequence diagram of a method according to an embodiment of the present invention; Figure 11 illustrates a method with vehicles and intelligent traffic lights according to an embodiment of the present invention; Figure 12 illustrates a method with stations and two vehicles according to an embodiment of the present invention; Figure 13 illustrates a sequence diagram of a method according to an embodiment of the present invention; Figure 14 illustrates a sequence diagram of a method with database version verification according to an embodiment of the present invention; Figure 15 illustrates a sequence diagram of a method according to an embodiment of the present invention, wherein options are provided; Figure 16 illustrates a method with vehicles and intelligent traffic lights according to an embodiment of the present invention. Detailed Implementation

[0028] 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 so on. One objective of V2X communication is to improve overall road safety, traffic efficiency, and the effectiveness of transportation systems by allowing vehicles and other entities to exchange information in real time. This technology can be applied in Advanced Driver Assistance Systems (ADAS), autonomous driving, traffic management, and various other aspects of modern transportation. The transmission of V2X messages via V2X communication facilitates 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 road safety, efficiency, driver comfort, and enhancing the reliability of existing driver assistance and autonomous driving applications. Examples illustrated include C-ACC (Cooperative Automated Cruise Control) and V2X-related collision warnings (e.g., based on impending traffic congestion or pedestrians crossing the lane).

[0029] Metadata can refer to data that provides information about other data. This metadata can describe various attributes of the original data, such as its source, format, creation date, author, and other relevant details. Metadata can help organize, understand, and manage raw data, whether it is a document, image, video, or any other type of information. On the other hand, descriptors can refer to terms or signs used to describe or identify a specific characteristic or quality of something. Descriptors can also be used in the context of linguistics or programming, where they represent descriptions or identifiers for specific entities or concepts. In short, both metadata and descriptors contain descriptions and information; metadata, in particular, relates to information about other data, while descriptors typically involve signs or terms used to describe a specific aspect or quality of something.

[0030] The payload (Nutzdaten) can involve important information or content transmitted within a data packet or message. The payload represents actual data that carries meaning or value and is distinct from additional metadata or control information.

[0031] Road traffic-related functions are defined as specific operations or tasks directly associated with the flow and / or management of traffic on roads. These functions can involve the exchange of data and information between vehicles (V2V), infrastructure (V2I), or pedestrians (V2P), enabling real-time communication to improve overall road safety, traffic efficiency, and / or transport effectiveness. In specific road traffic scenarios, road traffic-related functions may involve safety-critical scenarios such as emergency braking, evasive maneuvers, or collision warning.

[0032] One aspect of the invention explores scenarios where at least two stations, such as vehicles, pedestrians, or road infrastructure, exchange information via V2X, and at least one of these stations uses the received information for safety-critical functions, such as remote-controlled driving, queuing formation, emergency braking, and autonomous driving. Because these systems may not be designed in a common way, they may operate based on different assumptions and requirements. One problem explored in the context of this invention is how to satisfy a recipient's requirements using information received from a third party. Another problem explored is how a recipient can decide whether its requirements are met.

[0033] Stations operating safety-critical functions can distribute a function identifier to one or more stations via V2X communication. This identifier can be sent as a broadcast (to all), a geocast (in a specific area), a groupcast (to members of a specific group of stations), or a unicast (to a single station). The mechanism according to embodiments of the invention does not necessarily limit the communication mode used. Due to prior standardization efforts, the function identifier can be reconciled with sets of requirements and assumptions found in the corresponding standards. In this way, each station receiving the function identifier can be capable of reconciling the function identifier with the standard and can decide whether the station can and wants to meet the function requirements, and if so, provide the transmitted information according to those requirements.

[0034] Alternatively, a station can transmit V2X data along with the identifier of its associated function. Each station receiving the V2X data and function identifier can then determine whether the received V2X data meets the requirements of its(multiple) current security-related functions(s). The clear advantage of this solution compared to existing technologies is that it eliminates the need for a centralized entity or standard to make decisions regarding a single format, and also eliminates the need for transformations by a third party. Additionally, it eliminates the need to transmit the complete set of requirements, which could increase message complexity and channel load; instead, stations can rely on standardized function sets with corresponding requirements and assumptions, using only very compact identifiers related to these standards.

[0035] Figure 1 illustrates a method, computer program, storage medium, and station according to an embodiment of the present invention. Figure 1 illustrates a method 100 for providing information based on the satisfaction of a set of requirements. Method 100 includes the following steps: In step 101, a database for a station is provided. The database describes, based on a given standard reference, which identifier for a road traffic-related function corresponds to which set of requirements. The set of requirements describes rules that allow another station to operate its road traffic-related functions in a functional or non-functional manner. In step 102, an identifier for a road traffic-related function for another station is received. Then, in step 103, the identifier is analyzed based on the coordination between the received identifier and the road traffic-related function and the corresponding set of requirements. And if the decision based on the coordination is that the set of requirements is satisfied, the method continues to the next step. In step 104, data for the road traffic-related function is provided based on the set of requirements, wherein the data includes the received identifier associated with the set of requirements.

[0036] Figure 1 further illustrates station 10, which includes computer 11 and computer-readable storage medium 15. Computer-readable storage medium 15 includes computer program 50.

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

[0038] Based on this expectation, station 10 can define a metadata configuration 201, which is 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 and 205b, this metadata configuration can be used when sending messages to other stations 20 and 30.

[0039] Furthermore, station 10 can use the computed metadata configuration for message types and one or more addressed receivers 20, 30 to orchestrate 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 receivers, station 10 can aggregate the metadata configurations before orchestrating the metadata. Station 10 can then send all V2X messages 205a, 205b, which include the usual header, payload, and orchestrated metadata.

[0040] Figure 4 illustrates these second steps, along with some additions, according to an embodiment of the invention. On the left side of the flowchart, it is shown that in step 401a, updates are received from other stations 20, 30. Furthermore, in step 401b, updates from station 10 itself can be received, including the metadata information mentioned above. 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 data group and / or metadata group are (re)calculated, which can produce the selected group of data and / or metadata 403. In an optional step 406, if the data and / or metadata have 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 stations 20, 30 is performed. In the next step 404, the data and / or metadata are orchestrated 403 in a manner consistent with the defined data group and / or metadata group. In the next step 405, the V2X message is sent.

[0041] Figure 3 illustrates an embodiment of Figure 2 with several modifications. 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, a matched data set and / or metadata set can be calculated in terms of its specific necessities based on the message received in steps 305a and 30 and the environmental knowledge about other stations 20 and 30. In another step 310a and 310b, the V2X message can be sent to receiving stations 20 and 30 using the matched data set and / or metadata set.

[0042] In one implementation, station 10 can use information already received from other stations 20 and 30 via V2X messages, such as CAM (Cooperative Awareness Message), VAM (VRU Awareness Message), CPM (Collective Perception Message), and / or MCM (Manoeuvre Coordination Message). Typically, any V2X message is used, which includes information about the sending stations 20 and 30, such as location, behavior, station type, their environment, and / or traffic participants in those environments. This information can be received and accumulated without the need for 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 improve its anticipation of receiver necessities by understanding their location, behavior, and driving tasks. If station 10 sends (returns) a V2X message with similar data and metadata configuration to the received message, this can also reflect the necessities of the corresponding station 20 or 30.

[0043] In another implementation, station 10 may use a map, which may be 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 helps anticipate the driving tasks of receiving stations 20 and 30 and decide 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 whether one is on a highway while the other is in a parking lot, can make a difference. Similarly, the number of stations near or at intersections, as well as the number of stations that may be other information sources, can affect metadata configuration.

[0044] In another implementation, a predefined profile for the relevant functions and use cases can be used to compute the metadata configuration. The profile can then be selected using all the information mentioned above, such as information about the possible recipients, like the profile definition, and driving scenario selection, such as approaching or leaving an intersection, turning right or left, or driving straight, scenario complexity, such as highway or urban scenarios.

[0045] In another implementation, not only is metadata configured, but station 10 can also eliminate portions of the payload if the metadata configuration indicates a low information value for that portion.

[0046] A method according to one embodiment of the invention includes the following steps. The data included during the generation of a V2X message for transmission can typically be the result of a measurement, such as the relative distance to an object detected by the vehicle's onboard sensors, or an estimate, such as the absolute position estimated by the sender through its positioning unit. In addition to this data, the sender can add safety metadata to the generated message. The metadata can include a confidence description of all measured or estimated data 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 with a standard confidence level of 95%. However, this confidence indicator may be insufficient for the receiver to decide whether the V2X data can be used for road traffic-related functions, particularly safety-critical functions. An alternative is to reconcile a range of measured or estimated values ​​with a probability density function (PDF) using probability distribution fitting. This can, for example, 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 acquire much better knowledge about the accuracy of the V2X data and can verify whether that accuracy meets the requirements of its current driving capabilities. For example, the receiver might require that a certain location 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 location in the received V2X data. Furthermore, confidence intervals for the parameter PDF can be calculated.

[0047] Where V2X data can be used for driver assistance or autonomous driving functions, the receiver may require knowledge of a set of operating conditions under which the system measuring or estimating the transmitted V2X data operates reliably. These conditions may include environment-related, geographical, and time-specific limitations, traffic and lane characteristics, and the vehicle's level of automation. The receiver can then verify whether these operating conditions encompass its current driving conditions. In this case, the receiver can use the received V2X data for its driving functions.

[0048] Typically, not all data measured or estimated by the sender can be included in the V2X message during its generation. Instead, the sender can, for example, use message generation rules to select a subset of this data that should be included in the generated message. Metadata can be used to describe the completeness of the data included in the V2X message, that is, the size of the included data relative to the total amount of data measured or estimated by the sender. The receiver can then verify whether the amount of included V2X data exceeds the minimum amount requested by the receiver, or whether the included V2X data includes specific data elements or areas requested by the receiver.

[0049] Metadata can be used to describe the QoS level or value of one or more QoS metrics regarding the estimated Quality of Service (QoS) that a receiver can expect from a V2X communication connection.

[0050] A consistency value indicates the probability that measured or estimated 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. Consistency values ​​can be calculated by estimating the distance between the measured or estimated data and its true value, such as a value from a map or a previous time point, or a value 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.

[0051] The receiver can receive V2X messages and interpret their security metadata to determine their suitability for its current driving functions. By processing the metadata, the receiver can determine whether the received V2X data meets the requirements of its current driving functions and can therefore be used as input for those functions. Otherwise, the receiver cannot rely solely on V2X data for its driving functions. V2X data can still be used, for example, by appending it to data already obtained from other sources for redundancy checks.

[0052] The description of confidence values ​​for V2X data can include a definition of the probability density function type that best matches the distribution of the measured or estimated data. 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.

[0053] Some examples of probability density functions can be as follows: A normal or Gaussian distribution, characterized by its mean or expected value µ and its standard deviation σ. A log-normal distribution, characterized by the mean or expected value µ and standard deviation σ of the natural logarithm of the variable. A Pareto distribution, characterized by its scale parameter x. mAnd its shape parameter α. 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 λ. A gamma distribution, characterized by its shape k and its scale θ. A Rayleigh distribution, characterized by its scale θ. A Rice distribution, characterized by its scale σ and the distance between its reference point and the centroid of the distribution.

[0054] The operating conditions of a system that has measured or estimated the transmitted V2X data can include environmental, geographical, and time-specific constraints, traffic and lane characteristics, and the vehicle's level of automation. Here are some examples of these conditions. Environmental conditions can include weather, such as sunny, cloudy, light rain, storm, snow, ice, fog, and cloud cover, as well as lighting, such as minimum and maximum illuminance. Geographical constraints can include specific areas, such as countries, states, school zones, courtyards, parking lots, etc. Time-specific constraints can relate to permitted operating hours, such as from 8:00 AM to 6:00 PM, or specific times, such as sunrise, sunset, or night. Traffic characteristics can include traffic density (vehicles / km / lane) and / or vehicle type (passenger cars, trucks / tractors, buses, motorcycles). Lane characteristics can include lane type, such as street, ordinary road, highway, divided / undivided road, number of lanes per direction, and lane surface, such as asphalt, concrete, gravel, cobblestone, or rough terrain. The level of vehicle automation can include, for example, longitudinal automation, lateral automation, and the driving automation level according to SAE J3016. The equipment of the physical infrastructure can include, for example, traffic lights at poles / mounts, and sensors (video, radar, lidar).

[0055] 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 included in the message and / or by the total number of elements / objects measured or estimated by the sender. The integrity can be described by (a) one or more geographical areas covered by the measured or estimated data included in the V2X message. The integrity can also be described by (a) one or more geographical areas not covered by the measured or estimated data included in the V2X message. The integrity can also be described by the ratio between the amount of measured or estimated data included in the V2X message and the total amount of data measured or estimated by the sender.

[0056] 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: Message rate, which describes the frequency or range of repetitions of the transmitted V2X message in the case of (semi-)periodic message transmission. The number of repetitions describes the number of times the message is transmitted (which may be undefined for periodically transmitted messages). For each transmitted V2X message, a message counter can be incremented by one, allowing the receiver to detect possible message loss. Error detection and / or error correction codes can be added to the V2X message to enable the receiver to detect transmission errors, such as parity bits, checksums, cyclic redundancy checks, cryptographic hash functions, or to correct such errors, such as forward error correction or hybrid automatic repeat requests. The transmitted message may include its measured channel load, such as channel occupancy, allowing the receiver to better estimate the current channel state, which may have a direct impact on the expected V2X communication performance. The transmitted message may include its average measured latency, i.e., the time interval between message generation and actual message transmission. This latency primarily likely stems from the time required for the sender to buffer messages during periods when the V2X channel is detected as occupied, for example, when using a CSMA / CA media access control protocol. The receiver can use the measured latency to better estimate the current channel state. The transmitted message may also include its measured channel reliability, such as the average packet error rate of the received V2X messages, allowing the receiver to better estimate the current channel state. Alternatively or additionally, the QoS level can be calculated from one or more of the described metrics, for example, a value between 0 and 1, and included in the metadata of the V2X message.

[0057] The consistency value of measured V2X data can be calculated in different ways. If a sensor detects an object outside its sensing range, the object may not exist and may have been detected due to measurement error. In this case, the measured object may have a low (or zero) consistency value. If the perceived object is detected by multiple unrelated sensors, and / or also by received V2X data, such as Cooperative Awareness 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 perceived for a long time, the object may have a high probability of presence, and vice versa. If the data of the perceived object is within a reasonable range of values ​​predicted by a Kalman filter, such as future position, speed, acceleration data, direction of travel, etc., the object may have a high probability of presence, and vice versa. Deep learning (DL) and machine learning (ML) can also be applied by analyzing data from vehicle sensors and historical records to predict values ​​and calculate data consistency.

[0058] Possible preconditions are described below. At the point of delivery and use of the station, the station's sensors and data fusion system can be registered with a central registry as metadata describing the quality and conditions of the data provided. 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 data set 501 can be signed using the vendor's private key, as shown in Figures 5 and 6. The signed metadata set 501 of the station shown in Figure 5 can include the station's station pattern identifier 502, station metadata 503, and public key 504.

[0059] Figure 6 illustrates a public key infrastructure 605 according to one embodiment, wherein a vendor's public key 601 can be used to derive a station's public key 604.

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

[0061] Figure 7 illustrates a signed data message 701 of station 10 according to one embodiment. The signed data message 701 includes sensor data 720 and a pattern identifier 702. According to this embodiment, station 10 prepares the data message 701 by obtaining sensor data 720, attaching a station pattern identifier (pattern identifier) ​​702, and signing the V2X message 701 using the station's private key.

[0062] Figure 8 illustrates a signed data message of a station with metadata according to one embodiment. In this embodiment, unlike Figure 7, the signed data message 801 includes sensor data 820, a pattern identifier 802, and additional metadata 810.

[0063] Each of stations 10, 20, and 30 can store a local copy of the central registry (intermediate storage). This local copy contains all metadata, which has been signed using certificates, making it possible to avoid exchanging data with the central registry with every V2X data transfer. The intermediate storage can be updated periodically.

[0064] A method according to one embodiment of the present invention may include the following steps, illustrated in FIG. 9. In step 901, transmitting station 10 can prepare a data message by obtaining sensor data and an additional station pattern identifier (pattern identifier), and can then sign the V2X message using the station's private key. In step 902, transmitting station 10 can distribute the data message via V2X. In step 903, receiving station 20 can receive the V2X message. In step 904, receiving station 20 can extract the pattern identifier of transmitting station 10 from the received message. In step 905, receiving station 20 can obtain pattern information (Modellinformationen) corresponding to the pattern identifier from an intermediately stored central registry. If no authenticated and trustworthy information corresponding to transmitting station 10 is found in the local registry, receiving station 20 can request an up-to-date copy of the central registry. If receiving station 20 is outside the coverage area, or if no certificate is found in the new version of the registry, receiving station 20 can refuse access to the information. In step 906, receiving station 20 can verify the pattern information using the supplier's public key (either stored intermediately or available online). In step 907, if the supplier's signature cannot be verified, the message received in step 913 can be rejected. Otherwise, receiving station 20 can reliably obtain the supplier of transmitting station 10. Therefore, receiving station 20 can reliably obtain the correct public key for transmitting station 10. In step 908, additionally, during the signature verification of the pattern information, receiving station 20 can verify the correctness and integrity of the content. If the pattern information is incomplete, altered, or incorrect, the data message received in step 913 can be rejected. In step 909, receiving station 20 can have the correct pattern information for the model of transmitting station 10. Receiving station 20 can verify the received data message using the station public key of transmitting station 10. In step 910, if the signature of transmitting station 10 cannot be verified, the message received in step 913 can be rejected. Otherwise, receiving station 20 can reliably obtain the information of transmitting station 10. Therefore, receiving station 20 can reliably obtain the correct public key for 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 at step 913 can be rejected. In step 912, receiving station 20 can now reliably know that transmitting station 10 has sent data, the data message is complete and correct, and that receiving station 20 has the correct station metadata of transmitting station 10. Receiving station 20 can now use the data and, using the station metadata of transmitting station 10 and the security requirements of dedicated security-critical functions, verify the possible uses of the received data.

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

[0066] In another implementation, there may be an additional step to verify the validity of the certificate, and to reject the relevant data if the certificate is too old. The validity of the information may correspond to the time since the certificate was issued.

[0067] In another implementation, the certificate may involve a public key or a private key that enables the station to sign and encrypt data in addition to authenticating the quality of the data being sent.

[0068] In another embodiment, data message 801 includes additional, such as spatial or scene-related metadata, as shown in Figure 8.

[0069] In another implementation, the station pattern identifier can point to a lookup table where multiple individual metadata items, such as information about sensors, fusion components, hardware information, and software information, can be stored separately.

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

[0071] In another implementation, another scheme, such as a group key, can be used for message authentication and signing.

[0072] In another implementation, if it is impractical to keep all station models worldwide in a local intermediate storage in the registry, then only a subset of the registered models can be stored locally, such as the registered models in a region (e.g., EU).

[0073] The method according to an embodiment of the invention is shown in FIG. 10 and may include the following steps. In step 1001, a first station 20 may distribute its request for V2X information, the request allowing the first station to operate its functions in a manner compliant with functional safety. A second station 10 may receive the request from the first station 20. In step 1002, the second station 10 may decide, based on a study of the received request, whether the second station meets the requested requirement, and if not, to abort. In step 1003, the second station 10 may orchestrate or provide information according to the request based on the decision. In another optional step, the second station 10 may add a mark to the information to indicate that the second station meets the requirement (not shown). In step 1005, the second station 10 may transmit the orchestrated information to the first station 20.

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

[0075] Furthermore, requirements sent by the first station 20 and verified 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., the accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, size, angle, object type, trajectory), the accuracy of time sources (e.g., GPS time, Network Time Protocol), and [min, max] vehicle speed). Another element may be Quality of Service (QoS) requirements (e.g., payload in [min, max] bytes, maximum tolerable latency or data availability in [min, max] ms, and data rate in [min, max] Mbps). Another element may be the required level of redundancy (e.g., information update rate, minimum number of unrelated information sources). Another element may be security levels and qualifications (e.g., the Automotive Safety Integrity Level (ASIL) developed for the sender's system). Another element could be permissible failure and degradation modes (e.g., the ability to detect degradation such as sensor blindness, miscalibration, or misalignment). Requirements may also include limitations on variation (e.g., reduced sensing range due to adverse weather conditions).

[0076] Based on the example shown in Figure 11, given vehicle 20 (the second station in this example), functions requiring an environmental model can be implemented on the vehicle, the environmental model conforming to specific requirements regarding its content. These specific requirements may include the following: The bounding boxes of surrounding vehicles can be within 100 m of the station and within 10 m of the road. The positions of the centers of gravity of surrounding vehicles can be within 100 m of the station and within 10 m of the road in a specific projection and coordinate reference system with an accuracy of 2 m. The positions of potentially endangered users in the surrounding area can be within 100 m of the station and within 10 m of the road in a specific projection and reference system with an accuracy of 50 cm. Vegetation can be considered as points, and buildings can be considered as polygons. Functions can be implemented on station 10, i.e., the intelligent traffic light in the embodiment of Figure 11, that create an environmental model from numerous sources and are capable of providing a wide range of information with varying granularities, and perform the following operations: One operation can be lidar point cloud detection. Another operation can be image detection from front, rear, and side cameras. Another operation can be radar measurement. Another operation can be data fusion of sensor measurements and sensed objects. Another operation could be object detection and classification. Another operation could be creating layers. Another operation could be projection into different coordinate systems.

[0077] In step 1101 of the embodiment from Figure 11, vehicle 20 may send its request to station 10, which may be capable of fulfilling the request, and in step 1104, the information is formatted in a manner that satisfies all the requests of vehicle 20. In step 1105, the formatted information may be transmitted to vehicle 20. There may also be advantages in channel utilization compared to simply sending raw data.

[0078] According to another embodiment shown in Figure 12, the first vehicle 20 may send its request in step 1201a. Station 10 may receive these requests in step 1202, examine them, and decide whether to satisfy them. In step 1203, station 20 may format the data and send it to vehicle 20 in another step 1210a according to the request. Subsequently, the second vehicle 30 may send its request in step 1201b. Station 10 may compare the two requests from the first and second vehicles in step 1202' and determine that the request of the first vehicle 20 is contained within the request of the second vehicle 30. In step 1203', station 10 may decide to satisfy the request of the second vehicle 30 and format the data according to the request of the second vehicle 30. Then, in steps 1210a and 1210b, station 10 may send the formatted data to the first vehicle 20 and the second vehicle 30. Since the request of the first vehicle 20 is contained within the request of the second vehicle 30, the function of the first vehicle 20 can use the data, even though it satisfies the request of the second vehicle 30.

[0079] According to one implementation (not shown), a first vehicle can send its request R1, and a second vehicle can send its request R2. A third vehicle can receive both requests R1 and R2, examine these requests, and decide to satisfy not only R1 but also R2. To avoid sending two sets of data (one satisfying R1 and the other satisfying R2), the third vehicle can calculate the minimum set of requests R3 that satisfy both R1 and R2. If the third vehicle can satisfy request R3, then the third vehicle can format and send the data accordingly. The first and third vehicles can receive and use the V2X data for their driving functions because they can satisfy both requests. If the third vehicle cannot satisfy request R3 but can satisfy R1 and / or R2, then the third vehicle can format and send the data according to R1 and / or R2.

[0080] If the second station cannot meet the requirements, it can instead abort and send a rejection message to notify the first station. Whether the second station implicitly rejects the request or rejects it with a rejection message depends on the given use case.

[0081] If different possibilities or trade-offs exist to satisfy the function, transmitting station 20 may send more than one set of requests (optionally in a priority-sorted list). Receiving station 10 can then check whether one set of requests or another set of requests can be satisfied, which increases the chance that at least one set of requests is satisfied. If the list of request sets is priority-sorted, station 10 can check the request sets from highest to lowest priority to find the highest priority set of requests that can be satisfied. If at least one set of requests from station 20 can be satisfied by receiving station 10, then station 10 can satisfy the request from station 20.

[0082] Before sending each set of requests, transmission station 20 can uniquely identify the set. If receiving station 10 is able to satisfy one or more sets of requests, receiving station 10 can include the unique identifier of the satisfied request set in the message addressed to transmission station 20. When transmission station 20 receives information from receiving station 10, the included identifier helps transmission station 20 verify which requests have been satisfied. Transmission station 20 can then forward the information and identifier of the satisfied requests to the relevant function.

[0083] A method according to an embodiment of the present invention is shown in FIG. 13 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 reconcile the function identifier with a corresponding request in its internal database. In step 1303b, station 10 may decide whether it can provide V2X data according to the requested request, and if not, abort. In step 1304, station 10 may provide data according to the request of station 20 and transmit this information, along with the function identifier received from station 20 and a set of requests, to station 20 according to step 1305. In step 1306, station 20 may receive the data and function identifier from station 10, verify whether its request has been met, and if so, forward the information to its current driving function.

[0084] Figure 14 illustrates another embodiment of the method according to the invention, which includes 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 verify the database version. In step 1403b, station 10 may reconcile the function identifier with the corresponding request in its internal database. In another step 1403c, station 10 may decide whether it can provide V2X data according to the requested request, and if not, abort. In step 1404, station 10 may provide data according to the request of station 20, and transmit the information, along with the function identifier received from station 20 and a set of requests, to station 20 according to step 1405. In step 1406, station 20 may receive the data and function identifier from station 10, verify whether its request is met, and if so, forward the information to its current driving function.

[0085] Figure 15 illustrates another embodiment of the method according to the invention, which includes the following steps. In step 1502, station 20 may distribute an identifier of its current driving function along with additional options. In step 1503a, station 10 may receive the function identifier and, considering the provided options, reconcile the function identifier with a corresponding request in its internal database. In step 1503b, station 10 may decide whether it can provide V2X data according to the requested request, and if not, abort. In step 1504, station 10 may provide data according to the request of station 20, and transmit the information, along with the function identifier received from station 20 and a set of requests, to station 20 according to step 1505. In step 1506, station 20 may receive the data and function identifier from station 10, verify whether its request is met, and, if so, forward the information to its current driving function.

[0086] Requirements may be based on public standards and may be stored, for example, in a database that manages and accesses the requirement information. This database may reside, for example, at stations 10 and 20 and / or on a central server. In connection with the functional identifiers in the database, the requirements may include the following: One requirement may relate to an ODD (Operational Design Domain), which may describe operating conditions such as road type, speed, weather conditions, and / or relevant traffic participants. Another requirement may relate to functional requirements (e.g., the accuracy of measured or estimated values ​​(e.g., position, speed, acceleration, yaw rate, size, angle, object type, trajectory), the accuracy of time sources (e.g., GPS time, Network Time Protocol), and [minimum, maximum] or vehicle speed). Another requirement may relate to Quality of Service (QoS) requirements (e.g., payload in [minimum, maximum] bytes, maximum tolerable latency or data availability in [minimum, maximum] ms, and data rate in [minimum, maximum] Mbps). Yet 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) developed for the sender's system). Another requirement may relate to permissible failure and degradation modes (e.g., the ability to detect degradation such as sensor blindness, miscalibration, or misalignment). Requirements in this context may also include limitations on degradation (e.g., reduced perception range due to adverse weather conditions).

[0087] Function identifiers can be alphanumeric identifiers.

[0088] A first example can be given in conjunction with Figure 16, featuring a vehicle 20 implementing an autonomous driving function that requires: an environment-related model to comply with specific requirements in its content. One specific requirement could be: the bounding boxes of surrounding vehicles are within 100 m of the station and within 10 m of the road. Another specific requirement could be describing the position of the center of gravity of surrounding vehicles in a specific projection and coordinate reference system with an accuracy of two meters within 100 m of the station and within 10 m of the road. Another specific requirement could be describing the position of potentially dangerous users in the surrounding area in a specific projection and reference system with an accuracy of 50 cm within 100 m of the station and within 10 m of the road. According to another specific requirement, vegetation can be described as points, and buildings can be described as polygons. Functions can be implemented at station 10, i.e., the intelligent traffic light illustrated in Figure 16, that create HD maps from numerous sources and can be capable of providing a wide range of information with different granularities, and perform the following operations: One operation could be lidar point cloud detection. Another operation could be image detection from front, rear, and side cameras. Another operation could be radar measurement. Another operation could be the fusion of sensor measurements and perceived object data. Another operation could be object detection and classification. Another operation could be the creation of layers. Another operation could be projection into different coordinate systems.

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

[0090] Figure 16 specifically illustrates an example of vehicle 20, which sends its functional 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.

[0091] If the database collects all requirements, then publicly available or published standards can be implemented, specifically mapping functions to their requirements. The following is an example excerpt from the database: Function Identifier Mapping Requirement Mapping Requirement Value… AD80 Vehicle-BB Empty AD80 Center of Gravity Position of Vehicles Around the Center of Gravity in meters with precision 2 AD80 Center of Gravity Reference Frame RD / 83 Tables RD / 83, ETRS89, and 42 / 83 can be three usable German reference specifications. Vehicle 20 can simply send AD80 as an identifier for its function identifier, AD80 being an exemplary function that could be autonomous driving version 80. Upon receiving this identifier, entity 10 can query the database for requirements and verify them. Entity 10 can be capable of fulfilling requirements and orchestrating information for vehicle 20. Figure 16 illustrates this example.

[0092] In another implementation, the disclosed standard can list multiple options for each function in the database. According to the implementation shown in Figure 15, in step 1502, references to the options can be distributed along with identifiers.

[0093] Vehicle 20 can select multiple options, either as a combination (AND) or as a selection (OR). If entity 10 receives an option as a selection (OR), the entity can select a group of requirements and continue the process using that group. Preferably, the options are marked, which allows entity 10 to indicate which requirements it meets when sending eligibility information to vehicle 20.

[0094] In another example, each function can have options, as shown in the following exemplary excerpt from the database.

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

[0096] In another implementation, there may be no request from the first station 20. Entity 10 can select a set of requests from the database that match its data, and can then distribute the data along with an identifier referencing that set of requests from the database. A possible recipient can then be one capable of making decisions about whether the request is satisfied by entity 10 and referenced in a V2X message to satisfy its own response, and whether the data can then be used.

[0097] In another implementation, standardized requirements may not be associated with functional identifiers, but each requirement has a unique identifier. A station can select its requirements from a database and then reference the individual group of requirements, along with or without requirements, in its transmission.

[0098] In situations similar to those described above, a station may select individual requirements, as illustrated in the exemplary excerpt of the database below.

[0099] For example, the functionality of vehicle 20 might require RD / 83 as a gravity reference standard, and the vehicle's speed might need to be between 20 and 130 km / h. Therefore, it could select requirement identifiers 4, 13, and 14, and transmit these requirement identifiers via V2X communication.

[0100] In another implementation, the identifier may be sent along with the database version number, the identifier relating to the version number. This allows for ensuring compatibility between databases on the site. This is illustrated in Figure 14.

[0101] Receiving station 10 was likely last updated in 2020, while transmitting station 20 was last updated in 2023. Version 17.2 of the standard may have been released in 2020. Version 18 may have been released in 2023.

[0102] Therefore, when the transmitting station 20 distributes its function identifier, the transmitting station may be related to version 18. The receiving station 10 may receive this identifier along with the version used and determine that the versions are incompatible. Therefore, the receiving station may abort the process.

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

[0104] The above explanation of the embodiments describes the invention in the context of examples. Of course, provided that this is technically reasonable, the independent features of the embodiments can be freely combined with each other without departing from the scope of protection of the invention.

Claims

1. A method (100) for providing information based on the satisfaction of a set of requirements, the method comprising the steps of: - Provide (101) a database for a station, wherein the database is based on a given standard reference to specify which identifier for a road traffic-related function corresponds to which set of requirements, wherein the set of requirements specifies rules that allow another station to operate its road traffic-related functions in a functional or non-functional manner; - Receive (102) an identifier for a road traffic-related function from another station; - Analyze (103) the identifier based on the coordination of the received identifier with the road traffic-related function and the corresponding set of requirements, and if the decision based on the coordination is that the set of requirements is met, the method proceeds to the next step; - Provide (104) data for a road traffic-related function based on the set of requirements, wherein the data includes the received identifier associated with the set of requirements.

2. The method (100) according to claim 1, characterized in that, The database includes one or more sets of requirements for road traffic-related functions, wherein during the receiving (102) process, the method (100) includes the additional steps of: - receiving information for referencing a corresponding set of one or more sets of requirements for road traffic-related functions, and - wherein during the analysis (103) process, the method (100) includes the additional steps of: - coordinating the received information with the coordinated set of one or more sets of requirements for road traffic-related functions based on references, and if the decision based on the coordination is that at least one set of the referenced requirements is satisfied, the method (100) proceeds to the next step, wherein the provision (104) is based on at least one set of the set of one or more sets of requirements, and wherein the data further includes the received information for making the references.

3. The method (100) according to claim 2, characterized in that, The information used for making the reference includes indications regarding references to a single corresponding group and / or a combination of corresponding groups, wherein during the analysis (103), the method (100) includes the additional steps of: - coordinating the received information with the one or more sets of requirements for the coordinated road traffic-related functions based on the information used for making the reference, and if the decision based on the coordination is that the one or more sets of referenced requirements are met, the method (100) proceeds to the next step, wherein the provision (104) is based on the one or more sets of referenced requirements.

4. The method (100) according to any one of the preceding claims, characterized in that, The method (100) includes the following additional steps: - providing a database for the station based on a given standard reference, the database having a description of which identifier corresponds to the one or more requirements; - The method analyzes the at least one identifier received by the coordination and the one or more corresponding requirements, and if the decision based on the coordination is that all requirements are met, the method continues to the next step.

5. The method (100) according to any one of the preceding claims, characterized in that, The database for the station includes a version indicator of the database stored at the station, wherein the method (100) includes the following additional steps: - receiving a version indicator of a version of a database for another station; - verifying the similarity of the two version indicators to each other, and if the comparison result is positive, the method (100) proceeds to the next step.

6. The method (100) according to claim 5, characterized in that, The method (100) includes the following additional steps during the verification process: - verifying the similarity between two version indicators, and if the stored version indicator is lower than the received version indicator, the method (100) proceeds to the next step: - providing data for road traffic-related functions based on a set of requirements related to information in the station's database.

7. The method (100) according to any one of the preceding claims, characterized in that, The method (100) includes at least one of the following steps: - querying a matching set of requirements from the database based on the received identifier, - sending the provided data to the other station via a message, particularly a V2X message.

8. The method (100) according to any one of the preceding claims, characterized in that, The group requires that the identifier relate to an environmental model, wherein the environmental model describes the content of the model based on information about the surrounding landscape and / or based on information about the bounding boxes of surrounding stations and / or infrastructure and / or similar features.

9. A station (10) for providing information based on the satisfaction of a set of requirements, comprising means for implementing the method (100) according to any one of the preceding claims.

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

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

Images