Vehicle-road cooperation-oriented air interface message normative verification method and device

Abstract

The invention relates to the technical field of vehicle-road cooperation, and provides a vehicle-road cooperation-oriented air interface message normalization verification method and device. The method comprises the following steps: acquiring a log file loaded in a playback mode of a user interface and a configured test file; extracting test data required by different test types in each air interface message; classifying the extracted test data according to test strategies of different test types to obtain test targets of different test types; in response to a test request triggered by a user on the user interface, according to test strategies of different test types, carrying out normative verification on the test target of the corresponding test type and the test expectation of the corresponding test type to obtain a verification result; and displaying a verification report including the verification result through a user interface. According to the method, the comprehensiveness, the adaptability and the traceability of air interface message verification are realized through a standardized verification process, a flexible and configurable test strategy and a verification dimension covered by a full scene.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle-road cooperation, in particular to a vehicle-road cooperation air interface message specification verification method and device. BACKGROUND

[0002] With the rapid development of intelligent networked vehicles and vehicle-road cooperation technology, vehicle-to-everything (V2X) communication technology has become an important foundation for supporting intelligent transportation systems (ITS) and future autonomous driving. V2X technology realizes real-time information interaction between vehicles, road infrastructure and other traffic participants through wireless communication between vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (V2N) and vehicle-to-pedestrian (V2P), and improves traffic safety, reduces congestion and optimizes energy efficiency.

[0003] In the V2X system, the air interface message is the core carrier for realizing the interaction between the vehicle and the external environment. In order to ensure the stability, interoperability and safety of the V2X air interface message in actual application, a rigorous specification verification scheme needs to be developed. In the prior art, V2X air interface message verification focuses on message transmission accuracy, and lacks coverage of compatibility between different devices, communication delay, data security encryption and field filling specifications, and the test strategy has poor flexibility, which is difficult to adapt to the diversified needs of different users (such as vehicle manufacturers, test field owners and operation and maintenance units), and lacks a unified test process and result output mechanism, resulting in low verification efficiency and difficult problem positioning.

[0004] Therefore, there is an urgent need for a method and system that can comprehensively cover the V2X air interface message specification verification requirements, have flexible and configurable test strategies, and have standardized processes, in order to solve the problems of the prior art. SUMMARY

[0005] The purpose of the embodiments of the present application is to provide a vehicle-road cooperation air interface message specification verification method and device, which solves the problems of incomplete coverage, poor test strategy flexibility and non-standard process in the prior art V2X air interface message verification.

[0006] In a first aspect, a vehicle-road cooperation air interface message specification verification method is provided, applied to a verification device, the verification device being in communication connection with a vehicle-mounted unit and a roadside unit, and the method can include: obtaining a log file and a test file configured in a playback mode of a user interface; the log file comprises different message types of air interface messages collected in a preset collection time period; the test file comprises test strategies of different test types and corresponding test expectations; extracting test data required by different test types in each air interface message, the test data comprising message identity, vehicle dynamic data, message attribute data and device association information; classifying and processing the extracted test data according to test strategies of different test types to obtain test targets of different test types, the test targets comprising test targets in each air interface message, test targets between different air interface messages of the same message type and test targets of a global environment; in response to a test request triggered by a user in the user interface, performing normative verification on test targets of corresponding test types and test expectations of corresponding test types according to test strategies of different test types to obtain verification results; displaying a verification report comprising the verification results through the user interface.

[0007] In one possible implementation, the different message types of air interface messages comprise vehicle basic safety messages, map data messages, signal phase and timing messages, road side safety messages and road side traffic messages.

[0008] In one possible implementation, the different test types comprise a first test type between different air interface messages of the same message type, a second test type in each air interface message and a third test type of a global environment; the first test type comprises message periodicity test, data continuity test, data variability test and data constancy test; the second test type comprises position deviation test, message priority test, string encoding information test, illegal padding test, data non-padding test, vehicle volume test and data number out-of-limit test; the third test type comprises global data consistency test.

[0009] In one possible implementation, the message identity comprises a device ID of a message sending device; classifying and processing the extracted test data according to test strategies of different test types to obtain test targets of different test types, comprising: classifying other test data in the extracted test data according to message types and device IDs of message sending devices to obtain other test data corresponding to each device ID and different message types; the other test data is data other than message types and device IDs in the extracted attribute data; Based on different test types, target test data required by each test type in the other test data is extracted to obtain test targets corresponding to each test type.

[0010] In one possible implementation, the verification result includes message statistical information and failure record information. The message statistical information includes the number of received air interface messages globally and the test targets corresponding to the air interface messages. The failure record information includes the message type, test field, test type and air interface message identifier of the air interface message corresponding to the test target that fails the test.

[0011] In one possible implementation, the verification report includes failure result record information and message statistical summary; wherein the failure result record information includes: for the air interface message determined to be non-standard, recording the message type, test target, test type, failure cause and message identifier of the air interface message; and the message statistical summary includes the total number of each type of message, the number of sending devices and the message sending amount of each device.

[0012] In one possible implementation, before the log file loaded in the playback mode of the user interface and the configured test file are obtained, the method further includes: When the air interface messages of different message types are collected in a preset collection time period, if it is detected that the real-time collected air interface message meets a preset abnormal collection condition, the collection information of the air interface message is tagged to obtain tagged information and store the tagged information; the collection information includes the message type, timestamp and device ID of the message sending device; After the verification result is obtained, the method further includes: Based on the verification result and the stored tagged information, a target verification result is determined.

[0013] In a second aspect, a vehicle-road cooperation air interface message standardization verification device is provided, which is applied to a verification device in communication connection with a vehicle-mounted unit and a roadside unit, and can include: An acquisition unit is configured to acquire a log file loaded in a playback mode of a user interface and a configured test file; the log file includes air interface messages of different message types collected in a preset collection time period; and the test file includes test strategies of different test types and corresponding test expectations. An extraction unit is configured to extract test data required by different test types in each air interface message, wherein the test data includes a message identifier, vehicle dynamic data, message attribute data and device association information. The processing unit is configured to perform classified processing on the extracted test data according to the test strategies of different test types, to obtain test targets of different test types, wherein the test targets include test targets in each air interface message, test targets between different air interface messages of the same message type, and test targets of the global environment. The verification unit is configured to perform normative verification of the test targets of the corresponding test types and the test expectations of the corresponding test types according to the test strategies of different test types, in response to a test request triggered by a user on the user interface, to obtain verification results. The display unit is configured to display a verification report including the verification results through the user interface.

[0014] In a third aspect, an electronic device is provided, which includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory complete communication with each other through the communication bus. The memory is configured to store a computer program. The processor is configured to execute the program stored on the memory, to implement the method steps of any one of the first aspect.

[0015] In a fourth aspect, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the method steps of any one of the first aspect.

[0016] The method provided in the vehicle-road cooperative air interface message normative verification method and device provided in the present application loads a log file and a test file configured in a playback mode of a user interface. The log file includes air interface messages of different message types collected in a preset collection time period. The test file includes test strategies of different test types and corresponding test expectations. Test data required by different test types in each air interface message is extracted, and the test data includes message identity, vehicle dynamic data, message attribute data, and device association information. The extracted test data is classified and processed according to the test strategies of different test types, to obtain test targets of different test types. The test targets include test targets in each air interface message, test targets between different air interface messages of the same message type, and test targets of the global environment. In response to a test request triggered by a user on the user interface, the test targets of the corresponding test types are normatively verified with the test expectations of the corresponding test types according to the test strategies of different test types, to obtain verification results. A verification report including the verification results is displayed through the user interface. The method realizes the comprehensiveness, adaptability, and traceability of air interface message verification through a standardized verification process, a flexible and configurable test strategy, and verification dimensions covering all scenarios, and provides accurate and reliable normative verification support for vehicle manufacturers, test fields, and operation and maintenance units. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments of the present application. It should be understood that the following drawings only show some of the embodiments of the present application, and therefore should not be regarded as a limitation to the scope. For those skilled in the art, other related drawings can also be obtained without creative labor.

[0018] Figure 1 A structural schematic diagram of a verification system provided by the embodiments of the present application; Figure 2 A flowchart of a specification verification method for a car-road cooperation air interface message provided by the embodiments of the present application; Figure 3 A structural schematic diagram of a specification verification device for a car-road cooperation air interface message provided by the embodiments of the present application; Figure 4 A structural schematic diagram of an electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, and not all the embodiments. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of the present application. Unless otherwise defined, the technical terms or scientific terms used in the present application should be understood as the general meaning understood by those skilled in the art. The “first”, “second” and similar words used in the present application do not represent any order, number or importance, but are only used to distinguish different components. “Include” or “contain” and similar words mean that the elements or objects before the words cover the elements or objects listed after the words and their equivalents, and do not exclude other elements or objects. “Connect”, “couple” or “connected” and similar words are not limited to physical or mechanical connection, but can include electrical connection, whether direct or indirect.

[0020] For the convenience of understanding, the following will explain the terms involved in the embodiments of the present application: OBU (On-Board Unit): vehicle-mounted unit, an electronic device installed on a vehicle. It is mainly used to realize wireless communication between the vehicle and other vehicles (V2V) and between the vehicle and roadside infrastructure (V2I). In this way, OBU can receive information from roadside infrastructure (such as traffic conditions, accident warnings, etc.), and also send vehicle information to other vehicles or management systems.

[0021] RSU (Road Side Unit): A fixed communication device installed on the roadside, used to support communication between vehicles and infrastructure. RSU can be regarded as a small base station or access point, its main function is to exchange data with OBU through Dedicated Short Range Communications (DSRC) or other communication technologies (such as LTE-V, 5G-V2X, etc.) within its coverage range.

[0022] V2X air interface message specification verification is a key step to ensure the efficient and safe operation of cooperative vehicle infrastructure systems. V2X technology involves complex interactions between multiple communication scenarios and devices, and air interface messages are the main transmission medium for these interactions. The specification directly affects the reliability and interoperability of the entire system. Therefore, the specification verification of air interface messages has the following necessities: 1)Ensure interoperability V2X communication systems are usually composed of devices from different manufacturers, such as vehicle terminals and roadside units. In order to ensure that these devices can smoothly exchange information in different environments, the format and content of air interface messages must comply with uniform standards. Specification verification can ensure the consistency of message format, encoding, and transmission protocol, avoiding problems such as information unreadable or transmission failure caused by non-uniform standards.

[0023] 2)Improve communication security V2X communication is carried out in an open wireless environment and is vulnerable to external attacks (such as information tampering, forgery, and replay attacks). Through specification verification, it can be ensured that the encryption, authentication, and integrity protection mechanisms of air interface messages are correctly implemented, preventing unauthorized messages from being transmitted on the communication link, and ensuring the security of information transmission between vehicles and road infrastructure.

[0024] 3)Reduce system latency Real-time is the core requirement of cooperative vehicle infrastructure, especially in traffic safety and autonomous driving applications, message transmission delay may have serious consequences. Specification verification helps ensure the transmission efficiency of air interface messages, avoiding transmission delay problems caused by non-standard message formats or encoding errors, and ensuring the low latency characteristics of the communication system.

[0025] 4)Promote standardization and industrialization Currently, V2X technology is in a key stage of standardization and industrialization, and multiple international and domestic standardization organizations (such as IEEE, ETSI, C-V2X, etc.) have formulated a series of related standards. Through normative verification, it can be ensured that the air interface message conforms to these standards, laying a foundation for subsequent device interoperability testing, collaborative development of upstream and downstream of the industry chain, and healthy development of the industry.

[0026] 5) Improve the stability of technology application The promotion of cooperative vehicle infrastructure technology depends on the stability and reliability of the system, and the normative verification of the air interface message can timely find and solve potential problems in the system, improve the overall stability of the V2X communication system, and ensure its long-term stable operation in complex traffic environment.

[0027] The vehicle-to-road cooperative air interface message normative verification method provided by the embodiment of the application can be applied in Figure 1 The verification system as shown in Figure 1 The verification system can include a verification device with a display screen, and a vehicle-mounted unit and a roadside unit as message sending devices respectively connected in communication with the verification device.

[0028] The verification device is used to apply the GO language, collect air interface messages of different message types sent by the vehicle-mounted unit and the roadside unit, and store them as log files, and then perform normative verification on the air interface messages in the log files, that is, to execute the vehicle-to-road cooperative air interface message normative verification method.

[0029] The verification device can include a processor of i5 2.0GHz or higher, a memory of 4G or higher, and a separate graphics card of GTX960 or higher.

[0030] The vehicle-to-road cooperative air interface message normative verification can test the value change between multiple air interface messages of the same message type, the data property, the data and value rationality in a single air interface message, and the global data consistency test of whether the position reported by the same RSU in multiple air interface messages is consistent.

[0031] The preferred embodiments of the application will be described below in conjunction with the accompanying drawings. It should be understood that the preferred embodiments described herein are only used to illustrate and explain the application, and are not used to limit the application, and the embodiments in the application and the features in the embodiments can be combined with each other without conflict.

[0032] Figure 2 A flowchart of a vehicle-to-road cooperative air interface message normative verification method provided by the embodiment of the application is shown. As shown in Figure 2 The method can include: Step S210, acquire the log file loaded in the playback mode of the user interface and the configured test file.

[0033] In a specific implementation, the user clicks the file identifier of the log file to be tested in the playback mode of the user interface to acquire the log file and the pre-configured test file. The log file can include different message types of air interface messages collected in a preset collection time period; wherein the different message types of air interface messages can include: (1) Basic Safety Message (BSM), containing dynamic data such as vehicle speed, steering angle, acceleration, etc. (2) MAP, containing static road network information such as road nodes, road links, lane IDs, etc. (3) SPAT, containing traffic control data such as intersection traffic light phase, countdown time, etc. (4) RSM, containing participant (vehicle, pedestrian) information perceived by the roadside; (5) RSI, containing static / dynamic information such as traffic events (e.g. congestion, construction), traffic signs, etc.

[0034] Further, the gbdataset tool can be called to convert the collected different message types of air interface messages into corresponding structures, i.e. to obtain the structured air interface messages corresponding to different message types.

[0035] The test file can include test strategies of different test types and corresponding test expectations.

[0036] Different test types can include a first test type between different air interface messages of the same message type, a second test type within each air interface message, and a third test type of the global environment; wherein the first test type includes message periodicity test, data continuity test, data variability test, and data constancy test; the second test type includes position deviation test, message priority test, string encoding information test (string encoding test, string length test), illegal padding test, data not filled test, vehicle volume test, and data number out-of-limit test; and the third test type includes global data consistency test.

[0037] The test strategies of different test types can include: (1) Message periodicity test strategy: Calculate the message sending interval and compare it with the expected period; Collect the timestamps of the same type of messages sent by the same device (such as OBU, RSU), calculate the message sending interval, and verify whether it meets the protocol specified period (such as BSM period 100ms, MAP period 1000ms). Key logic: Group by message type (BSM / MAP / SPAT, etc.), compare the actual period with the expected period deviation, and exceed the threshold to determine failure.

[0038] (2) Data continuity test strategy: Check the continuity of msgCnt or SPAT timing, i.e. verify the continuity of key data such as message counter (msgCnt), traffic light countdown, etc., to avoid data jump or loss. Key logic: For msgCnt: Group by device ID, check if the counter is incremented in a cycle of "0→1→2→…→127→0" (step 1), jump to determine failure. For SPAT timing: Verify the continuity of traffic light countdown time (such as whether the countdown changes within 1 second are within the range of 1.99-4.01 seconds).

[0039] (3) Data change / constancy test strategy: Verify the reasonableness of data based on scene conditions (such as vehicle position should change when moving, RSU reference position should be constant). Key logic: Data change (such as BSM position): When vehicle speed > 0, check if the position of consecutive messages has valid changes, no change is determined as failure. Data constant (such as RSM reference position): The reference position of RSU should remain consistent in multiple messages, change is determined as failure.

[0040] (4) Position deviation test strategy: Verify whether the distance between the device's own position and the target position is within a reasonable range (such as the position deviation between OBU and roadside participant is not more than 1200 meters); Key logic: Calculate the distance between two points by the DistancePoint2Point function (based on the latitude and longitude distance formula of the earth's radius), exceed the expected threshold to determine failure.

[0041] (5) Message priority test strategy: Verify whether the priority field of the message meets the protocol requirements (such as MAP message priority is 208, SPAT message priority is 176); Key logic: Match the expected priority according to message type and scene (such as BSM normal / event triggered, RSI static / dynamic event), actual value does not match to determine failure.

[0042] (6) The test strategy of data quantity over-limit test is to verify the uniqueness of key IDs (such as node ID, lane ID, and participant ID) in the verification message to avoid duplication or quantity over-limit. The key logic is to count the number of occurrences of IDs through a hash table, such as "the number of repeated node IDs exceeds 1", and "the number of RSM participants exceeds 3", which is judged as failed.

[0043] (7) The test strategy of string encoding information test is to compare the encoding format (such as UTF-8) and length (such as device ID not exceeding 60 bytes) of string fields (such as RSI event description and device ID) to check for compliance. The key logic is to check whether the string contains illegal characters and whether the length exceeds the expected threshold, and if not, it is judged as failed.

[0044] (8) The test strategy of global data consistency test is to report and compare the positions of the same RSU in multiple messages (RSM / RSI) to avoid position confusion caused by device failure. The key logic is to collect all reference positions of the same RSU and check whether there is a deviation exceeding the threshold, and if not, it is judged as failed.

[0045] The test expectation of different test types refers to the qualified standard of each test type defined, which provides a basis for test logic. For example, "the BSM message cycle is expected to be 100ms ± 20ms", and "the maximum position deviation is not more than 1200 meters".

[0046] Step S220, extract the test data required by different test types in each air interface message.

[0047] In specific implementation, the ReadFile() function of Read.go is embedded, the log file message is traversed, and the test data is collected, including: According to different test types, test data is extracted from different message types of air interface messages (i.e. BSM, MAP, SPAT, RSM, RSI), which can include message identity, vehicle dynamic data, message attribute data, and device association information. Among them: Message identity can include: message unique identifier (including msgCnt, 0-127 cyclically increasing; device ID of message sending device, such as unique identifier of OBU-device ID), and timestamp (accurate time of message generation and sending, such as "2025.03.04 16:36:00"), which can be used for data continuity test (verifying msgCnt without jump), and message periodicity test (calculating timestamp interval).

[0048] The vehicle dynamic data can include speed, steering wheel angle, longitudinal / lateral acceleration, vehicle position, etc. The vehicle dynamic data can be used in the position deviation test to verify whether the distance between the vehicle position and the target position meets the requirements, in the data change test to verify the change of the position when the speed is greater than 0, and in the data validity test to verify whether the acceleration / steering angle is within a reasonable range.

[0049] The message attribute data can include priority (transmission priority of the BSM message, such as normal scene priority and event triggered priority), vehicle volume (length, width and height, which need to meet the requirements of “width≤1023 cm, length≤4095 cm, and height≤635 cm”), and string field (such as device description information, which needs to meet the requirements of UTF-8 encoding and length≤60 bytes). The message attribute data can be used in the message priority test to verify whether the priority meets the protocol requirements, in the vehicle volume test to prevent the volume data from exceeding the limit, and in the string encoding / length test to avoid illegal encoding or length overflow.

[0050] The device association information can include the type of the sending device (clearly OBU, which is different from the RSM / RSI message sent by the RSU) and the device position (the installation position of the OBU, which is used for global data consistency verification). The device association information can be used in the global data consistency test to verify that the position of the same OBU in multiple messages is consistent, and in the test device information statistics to display the ID and position of the OBU on the report details page.

[0051] In step S230, the extracted test data is classified and processed according to the test strategies of different test types, to obtain test targets of different test types.

[0052] The present application relates to five types of air interface messages (BSM, MAP, SPAT, RSM and RSI), and the field structures and test types of each type of message are completely different (for example, BSM needs to test vehicle speed / steering angle, and MAP needs to test road node / lane ID). If the messages are not classified by type, the field data of different messages will be mixed, and it is not possible to match the corresponding test strategy (for example, it is not possible to filter out only the vehicle size data containing BSM messages for “vehicle volume test”).

[0053] In specific implementation, the other test data in the extracted test data is classified according to the message type and the device ID of the message sending device, to obtain other test data corresponding to each device ID and different message types; the other test data is data in the extracted test data except the message type and the device ID; and the test data required by each test type in the other attribute data is extracted based on the test strategies of different test types, to obtain test targets corresponding to each test type.

[0054] In one example, first, 5 types of air interface messages (BSM, MAP, SPAT, RSM, RSI) can be respectively split into data pools storing corresponding message types. For example, all BSM messages sent by OBU are filtered into the BSM data pool, and all MAP messages sent by RSU are filtered into the MAP data pool, ensuring that the field data of different messages are not mixed (such as the vehicle speed field of BSM and the lane ID field of MAP belong to different data pools).

[0055] Secondly, for each message type data pool, further subdivide by device ID to obtain message type-device ID sub-pool. For example, in the BSM data pool, split by the unique ID of OBU into A214100A-BSM sub-pool and A214101B-BSM sub-pool; in the RSM data pool, split by the ID of RSU into D234202K-RSM sub-pool, to ensure that subsequent tests are carried out on the message data of the same device (such as calculating the period of BSM sent by a certain OBU, which needs to be based on all BSM messages of the OBU).

[0056] Then, for each message type-device ID sub-pool, extract key fields according to the test strategies of different test types configured, and arrange them into standardized test targets. For example, for A214100A-BSM sub-pool, if position deviation test is to be performed, extract the device's own position and vehicle position fields of each BSM message to construct a point-to-point position deviation test target; if data continuity test is to be performed, extract msgCnt (message counter) and timestamp fields to construct a multi-message data continuity test target.

[0057] Among them, the test target can include the test target in each air interface message, the test target between different air interface messages of the same message type, and the test target of the global environment.

[0058] Step S240, in response to the test request triggered by the user on the user interface, according to the test strategies of different test types, the test targets of the corresponding test types and the test expectations of the corresponding test types are standardized verified, and the verification results are obtained.

[0059] In response to the test request triggered by the user on the user interface, start the standardization verification function, according to the test strategies of the first test type, the second test type and the third test type in each air interface message, the test targets of the corresponding test types and the test expectations of the corresponding test types are standardized verified, and the verification results are obtained. Among them, the verification result can include message statistical information and failure record information; among them, the message statistical information can include the number of global received air interface messages and the test target corresponding to the corresponding air interface message; the failure record information can include the message type, test field, test type and air interface message identification of the air interface message corresponding to the test target that does not pass the test.

[0060] In one example, (1) the specification verification process of the test in each air interface message is to verify the filling specification, value range, format legality, etc. of the field in a single message. For example: Position deviation test: for BSM message, calculate the actual distance between the device's own position and the vehicle's position (based on the latitude and longitude of the earth radius distance formula), if it exceeds the expected test of 1200 meters, it is determined to be not standardized; Illegal filling test: for the path history initial position field of BSM, check if there is a null pointer or invalid value (such as latitude and longitude exceeding a reasonable range), if there is, it is determined to be not standardized; String encoding test: for the event description field of RSI, check if it conforms to the UTF-8 encoding format, if it contains illegal characters (such as garbled characters), it is determined to be not standardized.

[0061] (2) The specification verification process of the test between different air interface messages of the same message type is to verify the timing and data correlation, that is, for multiple messages of the same type sent by the same device, verify the timing continuity, periodicity, conditional correlation, etc. of the data. For example: Message periodicity test: for BSM messages of a certain OBU, calculate the timestamp interval between adjacent two messages, if the expected period is 100ms±20ms, the message whose interval exceeds the range of 80ms-120ms is determined to be not standardized; Data continuity test: for SPAT messages of a certain RSU, check if the countdown time of the traffic light is continuously decreasing (such as the countdown time of the previous message is 10 seconds, the next message should be about 9 seconds), if there is a jump (such as from 10 seconds directly to 7 seconds), it is determined to be not standardized; Data change test: for BSM messages of a certain OBU, if the vehicle speed is greater than 0 (indicating that the vehicle is running), check if the vehicle position changes over time, if the position does not change for a long time (exceeding a reasonable error range), it is determined to be not standardized.

[0062] (3) The specification verification process of the global environment test is to verify the global consistency of the associated data of different devices in the entire test environment. For example: For RSM and RSI messages sent by a RSU, extract the reference position field of the same RSU, check if the position of the RSU in different messages is consistent (such as the position of a RSU reported in RSM is “40.0148811,116.3476181”, in RSI it should be the same position), if the deviation exceeds the threshold, it is determined to be not standardized (affecting the accuracy of multi-device cooperation).

[0063] Step S250, display the verification report including the verification result through the user interface.

[0064] After the test execution is completed, the verification result is structured and processed to form a traceable and interpretable verification report, which is displayed on the user interface. The verification report can include failure result record information and message statistics summary; The failure result record information can include the message type (such as BSM), test target and field (such as data and the location of the data), test type (such as position deviation test), failure cause (such as distance out of limit), and message identification (such as msgCnt = 5, device ID = A214100A) of the air interface message determined to be non-standard, and other key information to ensure that the problem can be located.

[0065] The message statistics summary can include the total number of each type of message, the number of sending devices, and the message sending amount of each device (such as 100 BSMs from 5 OBUs, of which A214100A sends 25), providing data support for overall evaluation of the test environment.

[0066] In some embodiments, before obtaining the log file loaded in the playback mode of the user interface and the configured test file, the air interface messages of different message types can be collected within a preset collection time period. If it is detected that the real-time collected air interface message meets the preset abnormal collection condition, the collection information of the air interface message is labeled to obtain labeled information and store it. The collection information can include the message type, timestamp, and device ID of the message sending device. The real-time collected air interface message meeting the preset abnormal collection condition can include that the BSM message of a certain OBU has no change in position within 5 seconds (speed > 0), the device is temporarily offline, resulting in a too long message sending interval, the number of participants sending RSM messages suddenly increases, etc.

[0067] Then, based on the verification result and the stored labeled information, the target verification result is determined, specifically: (1) When the verification result contains information of verification anomaly, and the information of verification anomaly is directly related to the labeled information, the preset abnormal collection condition met by the labeled information is used to perfect the verification result to obtain the target verification result, specifically: When the labeled information and the verification result point to the same abnormal root cause, the preset abnormal collection condition met by the labeled information is used to supplement the verification result to obtain the target verification result. For example, if the real-time collection is due to "device temporary offline resulting in too long message sending interval" (labeled information), and the verification result shows that "the BSM message cycle of the device is not up to standard", it is determined that the same source anomaly: at this time, the original "cycle not up to standard" conclusion in the target verification result is supplemented to "cycle anomaly due to device offline", and the abnormal level is improved (such as from "warning" to "error") to clarify the abnormal reason.

[0068] When the tagging information is used to explain the rationality of the verification result, the preset abnormality collection condition met by the tagging information is used to correct the verification result to obtain a target verification result. For example, when the real-time collection is triggered by "vehicle emergency braking triggers emergency message (priority is raised)" (tagging information), and the verification result shows that "the priority of the BSM message does not match the normal value", it is determined that there is a reasonable deviation; at this time, the original "priority is not standard" conclusion in the target verification result is corrected to "priority is adjusted in an emergency scenario, which meets special rules", and the misjudgment is excluded.

[0069] (2) When the verification result contains information of a verification exception, and the information of the verification exception is not directly related to the tagging information, the preset abnormality collection condition met by the tagging information and the verification result are recorded respectively to form a target verification result. For example, if the tagging information is "the RSM message of a certain RSU is marked due to 'participant number surge'", and the verification result shows that "the MAP message node ID of the RSU is repeated", the two types of exceptions are recorded respectively in the target verification result without correction.

[0070] (3) When the verification result does not contain information of a verification exception, and there is a tested air interface message corresponding to the timestamp in the tagging information, which indicates that the verification result is abnormal, the test expectation corresponding to the test type of the tested air interface message collected in the preset collection time period is adjusted, and the tested air interface message is re-verified based on the adjusted test expectation to obtain a re-verified target verification result. For example, the verification result does not find any abnormality, but the tagging information shows that "the BSM message of a certain OBU has no position change (speed>0) within 5 seconds", which is determined to be a verification omission: at this time, the reason for "data change test not triggered" in the original verification is associated, such as unreasonable test expectation setting, and after adjusting the test expectation, the re-verification is performed to obtain a target verification result.

[0071] The above is combined with real-time abnormality collection tagging information: preset abnormality collection condition and tagging of abnormal messages (including message type, timestamp, and device ID), and the abnormality root cause can be located by associating the verification result in the future, and dynamic abnormal scenarios not covered by conventional verification (such as periodic abnormalities caused by temporary offline of a device) are supplemented.

[0072] The beneficial effects of the vehicle-road cooperation air interface message specification verification method of the present application include: 1. Full-scene and multi-dimensional verification of air interface messages is realized, such as covering three-layer test dimensions of single message, multiple messages, and global environment, and being compatible with five types of core air interface messages, so as to avoid verification omission caused by differences in message types; 2. Support test strategy dynamic configuration and individualization, such as configuring different test type strategies and expectations independently in test files, without modifying the code to adjust; according to the extracted test data, automatically classify and generate test targets according to the combination of message type + device, adapt to the verification needs of different messages and devices; 3. From loading log and test file → extracting and classifying test data → generating test target → executing verification and outputting report, each step has clear input and output, ensuring process consistency in different users and different scenarios.

[0073] Corresponding to the above method, the embodiment of the application also provides a vehicle-road cooperation air interface message specification verification device, as shown in Figure 3 The device comprises: An acquisition unit 310 is configured to acquire a log file loaded in a playback mode of a user interface and a configured test file; the log file comprises air interface messages of different message types collected in a preset collection time period; and the test file comprises test strategies of different test types and corresponding test expectations. An extraction unit 320 is configured to extract test data required by different test types in each air interface message, wherein the test data comprises message identity, vehicle dynamic data, message attribute data and device association information. A processing unit 330 is configured to classify and process the extracted test data according to the test strategies of different test types, to obtain test targets of different test types, wherein the test targets comprise test targets in each air interface message, test targets between different air interface messages of the same message type, and test targets of the global environment. A verification unit 340 is configured to, in response to a test request triggered by a user in the user interface, perform specification verification on the test targets of the corresponding test type and the test expectations of the corresponding test type according to the test strategies of different test types, to obtain a verification result. A display unit 350 is configured to display a verification report comprising the verification result through the user interface.

[0074] The functions of each functional unit of the vehicle-road cooperation air interface message specification verification device provided in the above embodiments of the application can be realized through the above method steps, therefore, the specific working process and beneficial effects of each unit in the vehicle-road cooperation air interface message specification verification device provided in the embodiments of the application will not be repeated here.

[0075] The embodiment of the application further provides an electronic device, as shown in Figure 4 The electronic device comprises a processor 410, a communication interface 420, a memory 430 and a communication bus 440, wherein the processor 410, the communication interface 420 and the memory 430 complete mutual communication through the communication bus 440.

[0076] a memory 430 for storing computer programs; the processor 410 is configured to implement the following steps when executing the programs stored in the memory 430: obtain a log file and a test file configured in a playback mode of a user interface; the log file comprises different message types of air interface messages collected in a preset collection time period; the test file comprises test strategies of different test types and corresponding test expectations; extract test data required by different test types in each air interface message, the test data comprising message identity, vehicle dynamic data, message attribute data and device association information; classify the extracted test data according to the test strategies of different test types to obtain test targets of different test types, the test targets comprising test targets in each air interface message, test targets between different air interface messages of the same message type and test targets of the global environment; in response to a test request triggered by a user in the user interface, perform normative verification on the test targets of corresponding test types and the test expectations of corresponding test types according to the test strategies of different test types to obtain verification results; display a verification report comprising the verification results through the user interface.

[0077] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or only one type of bus.

[0078] The communication interface is used for communication between the electronic device and other devices.

[0079] The memory can include a Random Access Memory (RAM) and can also include a Non-Volatile Memory (NVM), such as at least one disk memory. Optionally, the memory can also be at least one storage device located away from the aforementioned processor.

[0080] The processor described above can be a general processor, including a central processing unit (CPU), a network processor (NP), etc.; can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component.

[0081] The implementation manners and beneficial effects of the electronic device in the above embodiments can be achieved by referring to the steps in the above embodiments, and thus, the specific working process and beneficial effects of the electronic device provided by the embodiments of the present application are not repeated here. Figure 2 The implementation manners and beneficial effects of the electronic device in the above embodiments can be achieved by referring to the steps in the above embodiments, and thus, the specific working process and beneficial effects of the electronic device provided by the embodiments of the present application are not repeated here.

[0082] In another embodiment provided by the present application, a computer readable storage medium is provided, and the computer readable storage medium stores instructions, when the instructions are executed on a computer, the computer executes the vehicle-road cooperation oriented air interface message specification verification method in any of the above embodiments.

[0083] In another embodiment provided by the present application, a computer program product containing instructions is provided, when the instructions are executed on a computer, the computer executes the vehicle-road cooperation oriented air interface message specification verification method in any of the above embodiments.

[0084] Those skilled in the art should understand that the embodiments in the embodiments of the present application can be provided as methods, systems or computer program products. Therefore, the embodiments in the present application can be in the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware aspects. Moreover, the embodiments in the present application can be in the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program codes.

[0085] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the

[0086] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the

[0087] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the

[0088] While the preferred embodiments in the application have been described, additional variations and modifications can be applied to those embodiments without departing from the spirit and scope of the application. Therefore, the appended claims are intended to cover all such modifications and variations as falling within the scope of the application. It is intended that each of the independent claims set forth a separate embodiment of the present application. These and other changes can be made to the application in light of the above

[0089] It will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments of the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application cover the modifications and variations of this application provided they come within the scope of the appended claims and their equivalents.

Claims

1. A method for verifying the standardization of air interface messages for vehicle-road cooperation, characterized in that, The method, applied in a verification device that is communicatively connected to both an on-board unit and a roadside unit, includes: Retrieve the log file and configured test file loaded in the playback mode of the user interface; the log file includes air interface messages of different message types collected within a preset collection time period; the test file includes test strategies and corresponding test expectations for different test types; Extract the test data required for different test types from each air interface message. The test data includes message identity identifier, vehicle dynamic data, message attribute data, and device association information. According to the test strategies of different test types, the extracted test data is classified and processed to obtain test objectives for different test types. The test objectives include test objectives within each air interface message, test objectives between different air interface messages of the same message type, and test objectives for the global environment. In response to a test request triggered by a user on the user interface, the test objectives and test expectations of the corresponding test types are verified according to the test strategies of different test types to obtain the verification results. The user interface displays a verification report including the verification results.

2. The method as described in claim 1, characterized in that, Different types of air interface messages include: basic vehicle safety messages, map data messages, signal phase and timing messages, roadside safety messages, and roadside traffic messages.

3. The method as described in claim 1, characterized in that, Different test types include the first test type between different air interface messages of the same message type, the second test type within each air interface message, and the third test type in the global environment; The first test type includes message periodicity test, data continuity test, data variability test, and data constancy test; The second test type includes position deviation test, message priority test, string encoding information test, illegal padding test, data missing test, vehicle volume test, and data number exceeding limit test; The third test type includes global data consistency testing.

4. The method as described in claim 3, characterized in that, The message identity identifier includes the device ID of the message sending device; Based on the testing strategies for different testing types, the extracted test data is categorized and processed to obtain the testing objectives for different testing types, including: According to the message type and the device ID of the device that sent the message, the other test data in the extracted test data are classified to obtain other test data corresponding to each device ID and different message types; the other test data is the extracted attribute data other than message type and device ID. Based on different test types, the target test data required for each test type in the other test data is extracted to obtain the test target corresponding to each test type.

5. The method as described in claim 1, characterized in that, The verification results include message statistics and failure log information; The message statistics include the number of air interface messages received globally and the test targets corresponding to the air interface messages; The failure record information includes the message type, test fields, test type, and air interface message identifier of the air interface message corresponding to the test target that failed the test.

6. The method as described in claim 5, characterized in that, The verification report includes failure result recording information and message statistics summary; wherein, the failure result recording information includes: for air interface messages judged to be non-standard, recording the message type, test target, test type, failure reason and message identifier of the air interface message; the message statistics summary includes statistics on the total number of various types of messages, the number of sending devices, and the number of messages sent by each device.

7. The method as described in claim 4, characterized in that, Before obtaining the log file loaded in the playback mode of the user interface and the configured test file, the method further includes: When collecting air interface messages of different message types within a preset collection time period, if a real-time collected air interface message is detected to meet the preset abnormal collection conditions, the collection information of the air interface message is tagged, the tagged information is obtained and stored; the collection information includes message type, timestamp and device ID of the message sending device; After obtaining the verification results, the method further includes: Based on the verification results and the stored tagging information, the target verification result is determined.

8. A device for verifying the standardization of air interface messages for vehicle-road cooperation, characterized in that, The device is used in a verification system, which is communicatively connected to both an on-board unit and a roadside unit. The device includes: The acquisition unit is used to acquire the log file and the configured test file loaded in the playback mode of the user interface; the log file includes air interface messages of different message types collected within a preset collection time period; the test file includes test strategies and corresponding test expectations for different test types. The extraction unit is used to extract the test data required for different test types in each air interface message. The test data includes message identity identifier, vehicle dynamic data, message attribute data, and device association information. The processing unit is used to classify and process the extracted test data according to the test strategies of different test types to obtain test targets for different test types. The test targets include test targets within each air interface message, test targets between different air interface messages of the same message type, and test targets for the global environment. The verification unit is used to respond to the test request triggered by the user on the user interface, and to perform normative verification of the test objectives and test expectations of the corresponding test type according to the test strategy of different test types, so as to obtain the verification results. The display unit is used to display a verification report including the verification results through the user interface.

9. An electronic device, characterized in that, The electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images