CN115802317A

CN115802317A - Real-time simulation method and system based on V2X simulation

Info

Publication number: CN115802317A
Application number: CN202310044414.3A
Authority: CN
Inventors: 杰里米·吉尔·弗雷德里克·帕瓦热; 梁标; 肖佐仁; 李月
Original assignee: Suzhou Zhixing Zhongwei Intelligent Technology Co ltd
Current assignee: Suzhou Zhixing Zhongwei Intelligent Technology Co ltd
Priority date: 2023-01-30
Filing date: 2023-01-30
Publication date: 2023-03-14
Anticipated expiration: 2043-01-30
Also published as: CN115802317B

Abstract

The invention provides a vehicle running real-time simulation method and system based on V2X, comprising the following steps: step 1: building a vehicle test scene; step 2: setting a readable configuration file, setting an IP address and a port of a message packet receiver of the vehicle-mounted unit, and acquiring vehicle related information; and step 3: reading the longitude, latitude and altitude of a vehicle through a configured GPS sensor; and 4, step 4: counting the message packets through a counter, and automatically zeroing and continuously starting counting when the value reaches a preset value; and 5: defining and initializing a Windows socket interface, and sending a message to a specified IP address and port through a user datagram protocol. According to the invention, the V2X communication simulation is carried out by establishing the OBU and RSU models, so that the software and hardware can be checked without carrying out the drive test on the project, the research and development test cost can be obviously reduced, the process is safe and efficient, and the risk of the drive test traffic accident is reduced.

Description

Real-time simulation method and system based on V2X simulation

Technical Field

The invention relates to the technical field of simulation, in particular to a real-time simulation method and system based on V2X simulation.

Background

V2X, vehicle-mounted wireless communication technology, is a technology for realizing communication between a vehicle and any entity affected by the vehicle. The communication application scenes of the information intercommunication system using the vehicle as a carrier comprise: vehicle to infrastructure V2I, vehicle to vehicle V2V, etc. The deep research on V2X aims to improve road safety and traffic efficiency.

Patent document CN111405522a (application number: CN 202010289655.0) discloses a V2X test online simulation system and device based on vehicle-road cooperation, which includes the following steps: the method comprises the following steps: the method comprises the following steps of establishing a V2X actual measurement environment for verifying vehicle-to-vehicle, vehicle-to-infrastructure, vehicle-to-pedestrian communication and the like; step two: in the actual communication environment signal test, vector signal analysis software 89600VSA equipment is adopted in a test area, and the main conditions of communication signals in the test area are monitored in real time; step three: testing the shielding of the tunnel on the V2X signal, and analyzing a tunnel communication test environment in a closed test area; step four: the V2X communication environment is constructed in a simulation mode to test and verify the coping ability and the signal processing mechanism of the intelligent internet automobile in various communication environments.

Although our country has limited deployment of V2X in regions and vehicle facilities, many original equipment manufacturers OEMs and vendors at various levels have been active in this race track and have endeavored to develop vehicles that meet the V2X specifications.

Compared with the time consumption and the danger brought by the information interaction technology in the drive test inspection and verification, the research and development of the simulation tool can simulate the V2X system, so that the inspection and verification of the technology in a specific scene are more efficient and safer.

Disclosure of Invention

Aiming at the defects in the prior art, the invention aims to provide a vehicle running real-time simulation method and system based on V2X.

The invention provides a V2X-based vehicle running real-time simulation method, which comprises the following steps:

step 1: building a vehicle test scene;

step 2: setting a readable configuration file, setting an IP address and a port of a message packet receiver of the vehicle-mounted unit, and acquiring vehicle related information;

and 3, step 3: reading the longitude, latitude and altitude of a vehicle through a configured GPS sensor;

and 4, step 4: counting the message packets through a counter, automatically zeroing when the value reaches a preset value, and continuously starting counting;

and 5: defining and initializing a Windows socket interface, and sending a message to a specified IP address and port through a user datagram protocol.

Preferably, the basic safety message BSM data collection is performed for each BSM [ i ]]The information, i is any integer from 0 to N, represents the vehicle number with the vehicle-mounted unit device in the scene, all relevant information is collected through SCANeRAPI interface, manual setting or formula calculation, and each vehicle has a specific BSM [ i [ ]]And finally, all the messages are gathered into a BSM message list and output as a BSM message collection, wherein the message collection formula is as follows:

thus, the formula shows that the final BSM message is the sum of all vehicle messages loaded with on board units.

Preferably, the data acquisition of the road side safety messages RSM is carried out, and the related information of each RSM [ i ] is acquired through a SCANeRAPI interface, manual setting or a formula calculation method;

carrying out data acquisition on road side information RSI, and manually setting each item of relevant information in an RSI structural formula to be a constant value;

and carrying out SPAT data acquisition on the phase and time sequence messages of the traffic lights, wherein each piece of SPAT [ i ] information is acquired by a SCANeRAPI interface or manual setting and then is filled into the SPAT structural formula.

Preferably, the RSM items are output to RSM _ UDP, and when the values of the structural formula components of RSM [ i ] are determined, the columns of the components are sequentially and respectively transmitted to RSM _ UDP [ i ], and when all RSM _ UDP [ i ] are collected and filled, the RSM _ UDPjson format messages are converted into long strings of characters, that is, RSM messages: RSM _ message;

outputting the RSI item to RSI _ UDP, when the value of each sub item in the structure formula of RSI [ i ] is determined, the sub item column is respectively transmitted to RSI _ UDP [ i ] in sequence, when all RSI _ UDP [ i ] are collected and filled, the RSI _ UDPjson format message is converted into long string character, namely RSI message: RSI _ message;

outputting the SPAT item to SPAT _ UDP, when the value of each subentry in the structural formula of SPAT [ i ] is determined, the subentry column is respectively transmitted to RSI _ UDP [ i ] in turn, when all SPAT [ i ] _ UDP are collected and filled, the SPAT _ UDP json format message is converted into a long string character, namely SPAT message: SPAT _ message;

outputting the BSM item to BSM _ UDP, when the value of each subentry in the structural formula of BSM [ i ] is determined, the subentry column is sequentially and respectively transmitted to BSM _ UDP [ i ], when all BSM [ i ] _ UDP are collected and filled, the message in BSM _ UDP json format is converted into a long string character, namely BSM message: BSM message.

Preferably, the MAP message MAP item is output to MAP _ UDP, the information related to the terrain is directly sent and filled into the MAP _ UDP [ i ] structure, and when all MAP _ UDP are collected and filled, the MAP _ UDPjson format message is converted into a long string of characters, that is, the MAP message: MAP _ message.

The invention provides a V2X-based vehicle running real-time simulation system, which comprises:

a module M1: building a vehicle test scene;

a module M2: setting a readable configuration file, setting an IP address and a port of a message packet receiver of the vehicle-mounted unit, and acquiring vehicle related information;

a module M3: reading the longitude, latitude and altitude of a vehicle through a configured GPS sensor;

a module M4: counting the message packets through a counter, automatically zeroing when the value reaches a preset value, and continuously starting counting;

a module M5: defining and initializing a Windows socket interface, and sending a message to a specified IP address and port through a user datagram protocol.

Preferably, roadside safety message RSM data acquisition is carried out, and related information of each RSM [ i ] is acquired through a SCANeRAPI interface, manual setting or a formula calculation method;

outputting the BSM items to BSM _ UDP, when the numerical value of each subentry in the structural formula of BSM [ i ] is determined, sequentially and respectively transmitting the subentry column to BSM _ UDP [ i ], when all BSM [ i ] _ UDP are collected and filled, converting the message in BSM _ UDP json format into a long string character, namely BSM message: BSM message.

Preferably, MAP message MAP items are output to MAP _ UDP, information related to terrain is directly sent and filled into MAP _ UDP [ i ] structure, and when all MAP _ UDP are collected and filled, the MAP _ UDPjson format message is converted into long string characters, that is, MAP message: MAP _ message.

Compared with the prior art, the invention has the following beneficial effects:

(1) The simulation engineer can carry out V2X communication simulation by establishing an OBU model and an RSU model, so that the project can inspect software and hardware without carrying out drive test, the research and development test cost can be obviously reduced, the process is safe and efficient, and the risk of drive test traffic accidents is reduced;

(2) The method can provide repeatability tests for the FCW and GLOSA scenes guided by the green wave vehicle speed for early warning of the front collision, and the user can set the same or different initial conditions for the FCW and the GLOSA scenes in the simulation software SCANER.

Drawings

Other features, objects and advantages of the invention will become more apparent upon reading of the detailed description of non-limiting embodiments with reference to the following drawings:

FIG. 1 is a schematic diagram of the operation of a main V2X system;

FIG. 2 is a functional relationship diagram of a V2X simulation tool and SCANeR;

FIG. 3 is a schematic view of an FCW scenario;

FIG. 4 is a schematic view of a GLOSA scene;

FIG. 5 is a GPS information code diagram;

fig. 6 is an example RSM message packet in json format;

FIG. 7 is a diagram of RSM message content and structure under the requirement of a regulatory document YDT _3709_2020 format;

FIG. 8 is a diagram of the structure and identity of the RSI message under the definition of the YDT _3709 \2020file;

FIG. 9 is the SPAT message content and structure diagram defined by YDT _3709 \2020file;

FIG. 10 is a diagram of the contents and structure of a MAP message as defined in the YDT _3709 \2020file;

FIG. 11 is a BSM message content and structure diagram as defined by the YDT _3709 \ "2020 file;

FIG. 12 is a code diagram showing the initial value of the counter and its auto-counting function;

FIG. 13 is a code diagram of Winsock's definition and initialization process;

FIG. 14 is a code diagram for constructing the OBU _ message _ UDP;

FIG. 15 is a code diagram of an item to which an OBU _ message _ UDP subset is sent over UDP;

fig. 16 is an example BSM _ configuration.

Fig. 17 is a BSM message example;

FIG. 18 is an RSI message example;

FIG. 19 is an example RSM message;

FIG. 20 is an example SPAT message;

fig. 21 is a MAP message example.

Detailed Description

The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the invention, but are not intended to limit the invention in any way. It should be noted that it would be obvious to those skilled in the art that various changes and modifications can be made without departing from the spirit of the invention. All falling within the scope of the present invention.

Example (b):

starting from the perspective of the host vehicle (i.e., the vehicle carrying the on-board unit), fig. 1 shows the operating principle of the V2X system in detail. The vehicle-mounted unit can be regarded as a message receiving and transmitting device of the main vehicle, and the unit can receive related messages of other peripheral entities and transmit messages of the main vehicle, and the messages are collectively called basic safety messages BSM. And after receiving all the messages, the vehicle-mounted unit converts the messages into a specific format and transmits the specific format to the inter-process communication IPC.

An OBU: onBoard Unit, on-board Unit;

UDP: user datagram Protocol, user datagram Protocol;

IPC: inter-processor communication, interprocess communication;

RSU: roadSide Unit, roadSide Unit;

v2l: a Vehiclo lnfrastructure, the vehicle communicating with the infrastructure;

V2V: vehicle-to-vehicle communication;

V2P: the Vehicleto Pedestrian bus communicates.

The simulation tool developed by IAE is used for realizing repeated simulation of V2V and V2I in the context of FCW (Front Collision Warning) and GLOSA (green light Optimal Speed Advisory) in the scannerspathio, and now supports operation in the software of the scannerstudio version 2021. The technology can realize repeated simulation of information interaction behaviors of the OBU and the RSU in a scene.

The information sent by the RSU includes four parts: RSM (RoadSafety Message), RSI (RoadSide Information), SPAT (Signal phase Timing Message), MAP (MAP), which are four Message packets (i.e., V2I Message types) that are received by the OBU of the host vehicle.

The OBU also receives BSM messages (V2V for this communication) sent by other target vehicle OBUs. After receiving the new message, the OBU sends an updated message packet (BSM + { RSM, RSI, SPAT, MAP }) to the IP address of the user-specified port in the json format (received by IPC)

Fig. 2 is a simple example of a V2X simulation tool in the SCANeR software.

The complete technical solution consists of 3 main parts: 1) scenario, 2) primary tool, 3) a configuration file.

1) Scene

The following 2 examples are FCW and GLOSA scenarios, both built in the software of scannersutio 2021 and complying with the scenario building requirements specified by CSAE _53 _2020.

The FCW type scene is used for testing a 'front collision early warning' scene case. The scene is composed of a main vehicle and a front target vehicle which are positioned on the same lane. The target vehicle is in a stationary state and the host vehicle has a longitudinal trajectory with a speed of 40 km/h. If the host vehicle and the target vehicle collide in the scene or the scene running time exceeds 40 seconds, the scene automatically stops running, as shown in fig. 3. In the scene, a V2V information interaction simulation function can be performed.

The GLOSA scene built in SCANeR Studio2021 version software is suitable for predicting the state of the traffic light. The scene is composed of a main vehicle and an intersection which is about to pass through the main vehicle, as shown in figure 4. The scenario is also provided with an RSU required for V2I communication emulation.

Both FCW and glos scenarios are assigned boolean logic values to distinguish between the scenario and the sending of a message. The boolean logic value is 0 in the FCW scenario and 1 in the GLOSA scenario. The boolean logic value may be defined in the MICE script, i.e., using the programming language to embed the desired concept in the scene, i.e., its english: MICE-MyInterface for Creation and Edition.

2) Main tool

The V2X simulation tool is the core of this invention and, like the other functional modules of scannersutio, it can be used only after it has been set up using a configuration file named "BSM configuration.

The V2X simulation tool is essentially an executable file compiled via C + + code in the format of. Exe. The code structure of the V2X simulation tool is explained in detail as follows:

A. json function introduction to the configuration file BSM configuration

The role of this readable profile is to pinpoint the location (user-defined IP address and port) of the OBU message packet recipient for the V2X simulation tool. In addition, the V2X simulation tool can read various relevant information such as vehicle id, vehicle SCANeRid, OBU effective range, vehicle model, combustion improver type, hazardous materials and the like in the configuration file, so that various information is perfected and the functions of the information in a simulation scene are realized.

B. GPS information acquisition feedback process

In order to realize the OBU function of the vehicle in a SCANeR Studio scene, a GPS sensor is required to be equipped for the OBU function. The V2X simulation tool can read GPS related information (latitude and longitude and altitude) in each vehicle equipped with a GPS sensor. FIG. 5 shows GPS acquisition information read by the V2X simulation tool, which may be transmitted to the GPS framework.

C. UTC time function (UTC: universal time Coordinate, world Standard time)

The UTC time function is used to calculate the number of seconds in the past of a day, and the calculation process can be implemented using a C + + time API. This calculation can be implemented using the following equation:

the coordinated Universal Time (UTC) is a Time measurement system that coordinates universal Time, also called universal Time, universal standard Time, and international coordinated Time, and is close to universal Time as much as possible in Time based on the length of atomic Time-seconds. UTCTime is the sum of hours hourselap converted to minutes minutelap and then to total seconds secondelap.

D. MOY function (Minuteof the Year's past minutes)

The MOY function is used to calculate the number of minutes elapsed in the year, and the MOY calculation can also be performed using the C + + time library. This calculation can be implemented using the following equation:

MOY is the minutes calculation equation. MOY represents the number of minutes in the past of a year, with the year as the node. Therefore, the calculation method of the value of MOY should be: days translate to minutes and hours translate to the sum of minutes.

E. RSM data in json format

This section mainly shows the RSM message package in json format, as shown in fig. 6. The struct mapping library may be selected to create this json data format, and the json format requirements for RSM structures are detailed in the regulatory document YDT _ 3709/2020 and explained in fig. 7.

F. RSI data in json format

Like RSM, the json data format of RSI can also be created using struct mapping library, and the content and structural formula of the RSI message package are defined as shown in fig. 8 based on the relevant specification of the file YDT _3709 \2020.

G. SPAT data in json format

Like RSM and RSI, a struct mapping library may be used to create a json data format for SPAT, and based on the relevant specification of file YDT _3709 \2020, the content and structural formula of the SPAT message package are defined as shown in fig. 9.

H. MAP data in json format

Like RSM, RSI, and SPAT, the struct mapping library may be used to create the json data format of MAP, and the content and structural formula of the MAP message package are defined as shown in fig. 10 based on the relevant specification of the file YDT _3709 \2020.

I. BSM data in json format

The same method as the RSU information package (RSM, RSI, space, and MAP) format setting method, BSM messages collected by an OBU end may also define the json data format thereof through a struct _ mapping library, and based on the relevant specification of the file YDT _3709_2020, the content and structural format of the BSM message package are defined as shown in fig. 11.

J. Counter value initialization

Each message packet has a counter to record the duration. The counter value is any integer between 0 and 127 in the initial state of the scene. When the scene starts to run, the counter is increased by 1 along with the simulation step length, and when the value reaches 127, the counter is automatically reset to zero and continues to count.

The random number and its automatic counting function can be created using the C + + stdlib library. The code for the foregoing functional introduction is shown in fig. 12.

K. Creation of Windows socket API

This section mainly introduces the definition and initialization process of Windows SocketAPI (also known as Winsock) interface. The WinsockAPI interface is used to send the final message over UDP to the specified IP address and user defined port. The code is selected from open source software. The code details for Winsock initialization are listed in fig. 13.

L, traffic light signal lamp timing sequence description

The traffic light definition is mainly related to the V2I scene (the present example takes the GLOSA scene). The relative timing, phase sequence and real-time status are defined in the scene. When the scene runs, the V2X simulation tool can calculate the total time spent in phase cycle of each period, and further calculate the time relation between any time point and the phase period in the scene.

The state of the traffic light is represented as 0 when it is off and 1 when it is on, and the signal light is composed of red, yellow and green. The concrete representation method is as shown in the figure: { {1,0,0}, {0,1,0}, {0,0,1} } denotes { { red _ on, yellow _ off, green _ off }, { red _ off, yellow _ on, green _ off }, { red _ off, yellow _ off, green _ on } }. The timing scheme is represented as red _ time, yellow _ time, green _ time, one phase cycle time: total time = red light time + yellow light time + green light time.

If the actual time Actualtime of a scene is discussed in the concept of the signal phase period, it can be expressed by the following formula:

the actual time is expressed as actual time, i.e. the ratio of the scene time scenariioclock to the total time totaltime, where totaltime refers to the total time of one phase cycle. The actual time actualcomm is the scene time scenariioclock divided by the total elapsed time for one phase of the traffic light.

Here, by way of example:

Actualtime=(235mod22)=15(whichcorresponds to22*10+15=235)

here, by way of example: assuming that the scene time is 235 seconds and the time taken for one phase period is 22 seconds (red =10 seconds, yellow =2 seconds, green =10 seconds), the actual time is equal to 22 + 10+15 (10 is the number of phase periods elapsed in the scene time and 15 is the remaining constant value after the number of cycles is subtracted) by dividing the total scene time of 235 seconds by the phase period time of 22 seconds.

M, BSM data acquisition

For each BSM [ i ]]Messages (i: any integer from 0 to N, representing the vehicle number with the OBU device in the scene), all item related information listed in fig. 11 are collected through the scanera interface, manual settings, or through formula calculations. Each vehicle has a specific BSM [ i ]]And finally, all the messages are gathered into a BSM message list and output as a BSM message collection, wherein the message collection formula is as follows:

thus, the formula shows that the final BSM message is the sum of all OBU-loaded vehicle messages. .

N, RSM data acquisition

As with the BSM data collection method, referring to the RSM structural formula, each RSM [ i ] item listed in FIG. 7 will also be collected via SCANeRAPI interface, manual setup or via formula calculation. Through the information acquisition step, the related structure information listed in the file YDT _3709 \2020can be completely collected and filled in.

O, RSI data acquisition

Currently, as shown in fig. 8, each item of relevant information in the RSI structural formula has been manually set to a constant value.

P, SPAT data acquisition

In the same way as the BSM and RSM data collection, referring to the SPAT structure shown in fig. 9, each piece of SPAT [ i ] information is collected by the scanera interface or manual setting and then filled into the SPAT structure.

Q, RSM project output to RSM _ UDP

As shown in sequence n above, when the values of the various elements of the structure of RSM [ i ] are determined, the element columns are sequentially and respectively transmitted to RSM _ UDP [ i ], and the structure is shown in e above. The reason for transmitting the information items according to the levels is that the BSM _ UDP structure itself has limitations (e.g., cannot receive specific information values collected, etc.).

Here, by way of example:

if the velocity confidence for RSM [1] is 0.01m, as specified by the file YDT _3709_2020, then in the speedCfd column shown in fig. 7, this value is represented using "prec0_01 ms":

participants1.motionCfd.speedCfd =prec0_01ms

the velocity confidence equation for one of the motion confidence levels (motionCfd) of the top row, denoted speedCfd, is expressed as prec0_01ms (i.e., 0.01 meters per second) for the exact initial value of the first-appearing traffic participant (participants 1).

The speed confidence of RSM [1], i.e., scene participant "1", is sent to RSM _ UDP [1], as follows: partitionantudp 1.Motioncfd. Speed cfd = partitionants 1.Motioncfd. Speed cfd;

the equation in the upper row is expressed in the same way as the speed confidence, except that its format is adapted to a UDP structure. Therefore, under the UDP format, the first-appearing traffic participant is denoted as partilipentaudp 1.

When all RSM _ UDP [ i ] are collected and filled, the RSM _ UDPjson formatted message will be converted into a long string of characters, i.e. RSM message: RSM _ message.

R, RSI item output to RSI _ UDP

As shown in sequence number o above, when the values of the various elements of the structure of RSI [ i ] are determined, the columns of elements are sequentially transmitted to RSI _ UDP [ i ], respectively, the structure being shown in f above. When all RSI _ UDP [ i ] are collected and filled, the RSI _ UDPjson formatted message will be converted into a long string of characters, i.e. RSI message: RSI _ message.

S, SPAT entry output to SPAT _ UDP

As shown in sequence number p, when the numerical value of each element in the structural formula of SPAT [ i ] is determined, the element column is sequentially and respectively transmitted to RSI _ UDP [ i ], and the structure is shown in g. When all the SPAT [ i ] _ UDP messages are collected and filled, the messages in the SPAT _ UDP json format are converted into long strings of characters, namely, the SPAT messages: SPAT _ message.

T, MAP project output to MAP _ UDP

The terrain-related information will be sent directly and filled into the MAP _ UDP [ i ] structure (the same terrain used for the GLOSA and FCW scenarios). When all MAP _ UDP is collected and filled, the MAP _ UDPjson format message is converted into a long string, i.e. a MAP message: MAP _ message.

U, BSM project output to BSM _ UDP

As shown in sequence number m, when the numerical value of each sub-item in the structural formula of BSM [ i ] is determined, the sub-item row is sequentially and respectively transmitted to BSM _ UDP [ i ], and the structure is shown in I.

When all BSM [ i ] _ UDP is collected and filled, the BSM _ UDPjson format message will be converted into long strings of characters, i.e. BSM message: BSM message.

V, OBU message construction sent to IPC

The OBU message consists of 5 subset elements in the OBU _ message _ UDP, the initial state of which is shown below:

const char*OBU_message_UDP[5]={}；

the upper row of code represents the OBU _ message _ UDP array, and the array can only accommodate 5 subset elements, the initial array is empty.

The next level item of OBU _ message _ UDP is BSM _ message, which can be expressed by the following formula:

OBU_message_UDP[0] = BSM_message；

the line code indicates that the initial value of the OBU _ message _ UDP array is BSM _ message.

Depending on the type of GLOSA scenario or FCW scenario running in the SCANeR software, a boolean value of 1 or 0 is generated, see the scenario introduction section for details (boolean value may be set in the MICE script). If the boolean value is 0 (as seen in the FCW scenario), then the primary information (MAP, RSM, RSI, space) in all RSU packets will all be set to "NULL" (information NULL) and then converted into a string. If the boolean value is 1 (see the glos scenario), then the following information classes: MAP _ message, RSM _ message, RSI _ message and SPAT _ message are sequentially transmitted to OBU _ message _ UDP [1], OBU _ message _ UDP [2], OBU _ message _ UDP [3] and OBU _ message _ UDP [4], respectively. Fig. 14 shows conversion of the task display code and its character string for each packet based on the OBU _ message _ UDP and the boolean value (1 or 0).

W, OBU message content

And after the OBU _ message _ UDP subsets are created, the items to which each subset belongs are sequentially sent to the IP address and the port specified by the user based on the time step. The open source software used for realizing the V2X information interaction function, namely transmitting information through UPD is the same as Winsock. FIG. 15 shows the relevant code for the V2X simulation tool after compilation: OBU _ message _ UDP.

3) Configuration file

Json may be set using a profile named BSM configuration.json for the IP address and port of the recipient of the OBU packet (each packet representing a subset entry under OBU _ message _ UDP), as shown in fig. 16. The IP address and port can be found in "targetip" and "port".

The configuration file also provides the number of OBU vehicles and various types of information of each vehicle configured in the scene, and the details are as follows:

1. vehicle number: "id";

2. SCANeR number: "scanerid";

3. the OBU effective domain: "effective area";

4. vehicle class: "basicvhiclecules";

5. the fuel type: "FuelType";

6. hazardous materials: "Hazardous materials";

the IP address, port and specific values of points 3-6 above support user manual modification.

In the case of the FCW scenario, the user needs to ensure that both the host vehicle and the target vehicle are equipped with GPS sensors. The boolean value must be set to 0 in the MICE script and it is necessary to confirm that the IP address of the recipient of the host message has been set to completion before using the V2X simulation tool. When a scene runs (the scene will run for more than 40 seconds or stop running after a collision occurs), the V2X simulation tool sends an OBU message packet at a frequency specified by a user, wherein the message packet consists of an OBU message and an RSU message (since no RSU exists in the scene, the related information content is empty). The user then receives some information relating to the BSM and in json format, as shown in fig. 17.

In the case of the GLOSA scenario, the user needs to ensure that the host vehicle is equipped with a GPS sensor. The boolean value must be set to 1 in the MICE script. Before using the V2X simulation tool, the user needs to confirm that the IP address of the recipient of the host message has been set. When the scene is running (the scene will stop running after running for more than 40 seconds or a collision), the V2X simulation tool will send the OBU and RSU message package (RSI, RSM, space, MAP) at a frequency specified by the user. The user will then receive some information in json format that is related to the items. Fig. 18-21 show examples of RSI, RSM, spam, and MAP messages, respectively.

Those skilled in the art will appreciate that, in addition to implementing the systems, apparatus, and various modules thereof provided by the present invention in purely computer readable program code, the same procedures can be implemented entirely by logically programming method steps such that the systems, apparatus, and various modules thereof are provided in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Therefore, the system, the device and the modules thereof provided by the present invention can be considered as a hardware component, and the modules included in the system, the device and the modules thereof for implementing various programs can also be considered as structures in the hardware component; modules for performing various functions may also be considered to be both software programs for performing the methods and structures within hardware components.

The foregoing description of specific embodiments of the present invention has been presented. It is to be understood that the present invention is not limited to the specific embodiments described above, and that various changes or modifications may be made by one skilled in the art within the scope of the appended claims without departing from the spirit of the invention. The embodiments and features of the embodiments of the present application may be combined with each other arbitrarily without conflict.

Claims

1. A vehicle running real-time simulation method based on V2X is characterized by comprising the following steps:

step 1: building a vehicle test scene;

and 2, step: setting a readable configuration file, setting an IP address and a port of a message packet receiver of the vehicle-mounted unit, and acquiring vehicle related information;

2. The V2X-based vehicle driving real-time simulation method according to claim 1, wherein the basic safety message BSM data collection is performed for each BSM [ i]The information, i is any integer from 0 to N, represents the vehicle number with the vehicle-mounted unit device in the scene, all relevant information is collected through SCANeRAPI interface, manual setting or formula calculation, and each vehicle has a specific BSM [ i [ ]]And finally, all the messages are gathered into a BSM message list and output as a BSM message collection, wherein the message collection formula is as follows:

3. The V2X-based vehicle driving real-time simulation method according to claim 2, characterized in that RSM data collection is performed, and related information of each RSM [ i ] is collected through a SCANeRAPI interface, manual setting or through a formula calculation method;

4. The V2X-based vehicle driving real-time simulation method according to claim 3, wherein the RSM items are output to RSM _ UDP, when the numerical value of each subentry in the structural formula of the RSM [ i ] is determined, the subentry column is sequentially and respectively transmitted to the RSM _ UDP [ i ], when all the RSM _ UDP [ i ] are collected and filled, the RSM _ UDPjson format message is converted into a long string of characters, i.e. RSM message: RSM _ message;

5. The V2X-based vehicle driving real-time simulation method according to claim 4, wherein MAP message MAP items are output to MAP _ UDP, the terrain-related information is directly transmitted and filled into the MAP _ UDP [ i ] structure, and when all MAP _ UDP is collected and filled, the MAP _ UDPjson-format message is converted into a long string of characters, i.e., MAP message: MAP _ message.

6. A V2X-based vehicle running real-time simulation system is characterized by comprising:

a module M1: building a vehicle test scene;

7. The V2X-based vehicle driving real-time simulation system according to claim 6, wherein the basic safety message BSM data collection is performed for each BSM [ i]The information, i is any integer from 0 to N, represents the vehicle number with the vehicle-mounted unit device in the scene, all relevant information is collected through SCANeRAPI interface, manual setting or formula calculation, and each vehicle has a specific BSM [ i [ ]]And finally, all the messages are gathered into a BSM message list and output as a BSM message collection, wherein the message collection formula is as follows:

8. The V2X-based vehicle driving real-time simulation system according to claim 7, wherein RSM data collection is performed, and related information of each RSM [ i ] is collected through a SCANeRAPI interface, manual setting or a formula calculation method;

and carrying out SPAT data acquisition on the traffic light phase and time sequence messages, wherein each piece of SPAT [ i ] information is acquired by a SCANERAPI interface or manual setting and then is filled into the SPAT structural formula.

9. The V2X-based vehicle driving real-time simulation system according to claim 8, wherein the RSM items are output to RSM _ UDP, and when the values of the structural components of RSM [ i ] are determined, the columns of the components are sequentially and respectively transmitted to RSM _ UDP [ i ], and when all RSM _ UDP [ i ] are collected and filled in, the RSM _ UDPjson format messages are converted into long strings of characters, i.e. RSM messages: RSM _ message;

outputting the BSM item to BSM _ UDP, when the value of each subentry in the structural formula of BSM [ i ] is determined, the subentry column is sequentially and respectively transmitted to BSM _ UDP [ i ], when all BSM [ i ] _ UDP are collected and filled, the message in BSM _ UDP json format is converted into a long string character, namely BSM message: BSM _ message.

10. The V2X-based vehicle driving real-time simulation system according to claim 9, wherein MAP message MAP items are outputted to MAP UDP, the information related to terrain is directly transmitted and filled into MAP UDP [ i ] structure, and when all MAP UDP is collected and filled, the MAP UDPjson format message is converted into long string character, MAP message: MAP _ message.