WO2022237866A1 - 一种车路协同系统、模拟仿真方法、车载设备和路侧设备 - Google Patents

一种车路协同系统、模拟仿真方法、车载设备和路侧设备 Download PDF

Info

Publication number
WO2022237866A1
WO2022237866A1 PCT/CN2022/092424 CN2022092424W WO2022237866A1 WO 2022237866 A1 WO2022237866 A1 WO 2022237866A1 CN 2022092424 W CN2022092424 W CN 2022092424W WO 2022237866 A1 WO2022237866 A1 WO 2022237866A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
data
simulation
roadside
equipment
Prior art date
Application number
PCT/CN2022/092424
Other languages
English (en)
French (fr)
Inventor
李森
马坤
裴俊龙
Original Assignee
中移智行网络科技有限公司
中移(上海)信息通信科技有限公司
中国移动通信集团有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中移智行网络科技有限公司, 中移(上海)信息通信科技有限公司, 中国移动通信集团有限公司 filed Critical 中移智行网络科技有限公司
Publication of WO2022237866A1 publication Critical patent/WO2022237866A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0112—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from the vehicle, e.g. floating car data [FCD]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/20—Design optimisation, verification or simulation
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0108—Measuring and analyzing of parameters relative to traffic conditions based on the source of data
    • G08G1/0116—Measuring and analyzing of parameters relative to traffic conditions based on the source of data from roadside infrastructure, e.g. beacons
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/01—Detecting movement of traffic to be counted or controlled
    • G08G1/0104—Measuring and analyzing of parameters relative to traffic conditions
    • G08G1/0125—Traffic data processing

Definitions

  • the embodiments of the present application relate to the field of computer technology, and in particular refer to a vehicle-road coordination system, a simulation method, vehicle-mounted equipment, and roadside equipment.
  • V2X Vehicle to Everything
  • vehicle-road coordination aims to avoid traffic accidents, improve road safety, alleviate congestion, reduce energy consumption, and reduce environmental pollution, and meet the needs of vehicle-assisted driving and automatic driving. Necessary input for other businesses.
  • RSU Raad Side Unit, roadside unit
  • OBU On-Board Unit, vehicle-mounted unit
  • the business logic of the roadside or vehicle-mounted equipment is considered simplistically, the equipment communication protocol and equipment behavior logic are not standardized and complex and changeable, and the centralized server design does not consider the multi-level cloud and multiple Different types of equipment cooperate with each other, resulting in the existing vehicle-road coordination system, the communication process is lengthy and full of noise, and the cost of development and verification is relatively high.
  • an embodiment of the present application provides a vehicle-road coordination system, including:
  • the edge cloud is used to collect the first data of the roadside equipment and the second data of the on-board equipment, and perform the simulation of the vehicle-road collaborative environment according to the configuration information, the first data and the second data, and obtain the simulation results ;
  • the roadside device is configured to establish communication with the edge cloud, provide the first data for the edge cloud, and make a behavioral decision based on the simulation result;
  • the in-vehicle device is configured to establish communication with the edge cloud, provide the second data for the edge cloud, and make a behavioral decision based on the simulation result;
  • the simulated vehicle-road collaborative environment simulated on the edge cloud includes simulated roadside equipment and simulated vehicle-mounted equipment; SDK (Software Development Kit, software development kit), the vehicle-mounted device adopts the vehicle-mounted SDK consistent with the behavior and communication mode of the simulated vehicle-mounted device.
  • SDK Software Development Kit, software development kit
  • the vehicle-road coordination system further includes:
  • SPAT Signal phase timing message, traffic light phase and timing message
  • RSI Road Side Information, roadside information
  • RSM Radio Safety Message, roadside safety message
  • the second data includes at least one of the following:
  • BSM Basic Safety Message, basic safety message
  • the edge cloud simulates the vehicle-road collaborative environment according to the configuration information, the first data and the second data, including:
  • the first simulation data of the simulated roadside equipment includes simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data of the simulated vehicle equipment wherein, the second simulation data includes simulated vehicle BSM and simulated vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • the edge cloud is also used for:
  • the verifying the business capability of the vehicle-infrastructure coordination system according to the simulation results includes:
  • the edge cloud is also used to collect the configuration information
  • the configuration information includes:
  • the edge cloud collects the device metadata, including:
  • the device initial metadata is stored in the database as the device metadata.
  • the device initial metadata includes at least one of the following:
  • Vehicle-end metadata includes vehicle information data and corresponding vehicle-mounted equipment data
  • Roadside metadata including roadside equipment information and local area map information
  • Simulation event metadata includes GPS (Global Positioning System, Global Positioning System) points manually collected on the map, equipment attributes, running or driving status and simulation events.
  • GPS Global Positioning System, Global Positioning System
  • verifying the initial metadata of the device includes:
  • the initial metadata of the device is the vehicle-side metadata
  • uniqueness verification is performed on the vehicle information data in the vehicle-side metadata
  • verifying the initial metadata of the device includes:
  • the initial metadata of the equipment is roadside metadata, setting the scope of action of the roadside traffic equipment in the roadside equipment information;
  • the roadside equipment information is related information of roadside traffic equipment
  • the roadside traffic equipment includes at least one of the following: RSU, traffic lights, laser radar, millimeter wave radar, high-definition camera and temperature and humidity sensors.
  • condition that the road-end metadata satisfies the first preset condition includes the following three items:
  • the roadside equipment information and the local area map information are accurate;
  • verifying the initial metadata of the device includes:
  • the initial metadata of the device is metadata of a simulated event
  • select the device associated with the simulated event wherein, the device includes the roadside device, the vehicle-mounted device, the simulated roadside device, and the Describe the simulated vehicle equipment;
  • the simulation event has no conflict based on the mutual exclusion conditions
  • the parameters include event level, execution time, cycle, location and value.
  • the situation that the simulation event satisfies the second preset condition includes at least the following three items:
  • the edge cloud collects the scene metadata, including at least one of the following:
  • the first scripted data is scripted data formed after screening and processing the third data uploaded by the roadside device and the vehicle-mounted device;
  • the third data includes vehicle behavior data and roadside equipment data related to said vehicle;
  • the fourth data includes all Vehicles and roadside equipment data associated with said vehicles;
  • the first scripted data, the second scripted data and the third scripted data are all scripted data conforming to the operation of the simulation scenario.
  • the edge cloud collects the path metadata, including:
  • the edge cloud divides road segments on the route, including at least one of the following:
  • Segment road segments based on angle and acceleration.
  • the edge cloud performs scene orchestration, including:
  • the edge cloud sets scene events on the path according to the path metadata and the scene metadata, including:
  • the scene events in the queue to be stored are stored.
  • the edge cloud verifies the scene event, including:
  • the simulation scenarios include historical playback fixed scenarios and interactive fusion simulation scenarios.
  • the edge cloud executing the simulation scenario includes:
  • API Application Programming Interface, application programming interface
  • the simulation scenario is executed.
  • the edge cloud initializes the scene execution engine, including at least one of the following:
  • the edge cloud executes the simulation scenario, including:
  • the equipment includes the roadside equipment, the vehicle equipment, the simulated roadside equipment and the simulated vehicle equipment;
  • the historical scene metadata includes equipment operation data and scene recording data
  • the execution of the simulation scenario by the edge cloud includes:
  • the scene metadata includes device basic information and regional traffic road relationship network;
  • the device includes the roadside device, the vehicle-mounted device, the simulated road side equipment and the simulated vehicle equipment;
  • one simulation scene is bound to at least one simulation device, and one simulation device is only bound to one simulation scene; wherein, the simulation device includes the simulation vehicle-mounted device and the simulation roadside device.
  • the edge cloud is also used for:
  • establishing communication between the on-vehicle device and the edge cloud includes:
  • the on-vehicle device provides the second data for the edge cloud, including:
  • the SDK configuration pull the corresponding scripted data from the edge cloud, and according to the SDK configuration, connect to the corresponding roadside device, and receive the first message from the roadside device after the connection is successful;
  • the vehicle-mounted device executes the script, and executes the following steps in a loop:
  • each time the on-vehicle device completes the execution of a script it sends a script execution path to the edge cloud; and, every time it completes a scene event processing, it sends a scene event processing to the edge cloud result.
  • the roadside equipment is also used for:
  • the list of vehicle-mounted devices within the second preset range and the communication address corresponding to each vehicle-mounted device are periodically obtained, and an association relationship is established with traffic road network or other device metadata.
  • the roadside equipment is further configured to perform the following steps cyclically within a preset period:
  • the warning event is broadcast to vehicles within a third preset range.
  • the roadside equipment is also used for:
  • the alarm event is discarded.
  • the embodiment of the present application provides a simulation method applied to the edge cloud, including:
  • Collect the first data of the roadside equipment and the second data of the on-vehicle equipment and perform a simulation of the vehicle-road collaborative environment according to the configuration information, the first data, and the second data, and obtain a simulation result.
  • the simulation of the vehicle-infrastructure collaborative environment is performed according to the configuration information, the first data and the second data, and the simulation results are obtained, including:
  • the first simulation data of the simulated roadside equipment wherein, the first simulated data comprises simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data includes simulation vehicle BSM and simulation vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • the simulation method also includes:
  • the embodiment of the present application provides a simulation method applied to the core cloud, including:
  • the simulation method also includes:
  • the embodiments of the present application provide a simulation method applied to roadside equipment, including:
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the simulation method also includes:
  • the list of vehicle-mounted devices within the second preset range and the communication address corresponding to each vehicle-mounted device are periodically obtained, and an association relationship is established with traffic road network or other device metadata.
  • the simulation method also includes:
  • the warning event is broadcast to vehicles within a third preset range.
  • the embodiments of the present application provide a simulation method, which is applied to vehicle-mounted equipment, including:
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • establishing communication with the edge cloud includes:
  • the providing the second data for the edge cloud includes:
  • the SDK configuration pull the corresponding scripted data from the edge cloud, and according to the SDK configuration, connect to the corresponding roadside device, and receive the first message from the roadside device after the connection is successful;
  • an embodiment of the present application provides an edge cloud, including a processor; wherein the processor is used to collect the first data of the roadside equipment and the second data of the vehicle equipment, and according to the configuration information, the The first data and the second data are simulated in a vehicle-road collaborative environment to obtain a simulation result.
  • the embodiment of the present application provides a core cloud, including: a processor; wherein the processor is used to provide routing information for roadside devices and vehicle-mounted devices in each area to access the edge cloud.
  • an embodiment of the present application provides a vehicle-mounted device, including: a transceiver and a processor; wherein, the transceiver is used to establish communication with an edge cloud, and provide second data for the edge cloud;
  • the processor is used to make behavioral decisions according to the simulation results of the edge cloud
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • an embodiment of the present application provides a roadside device, including a processor and a transceiver, including: a transceiver and a processor;
  • the transceiver is used to establish communication with the edge cloud, and provide the first data for the edge cloud;
  • the processor is used to make behavioral decisions according to the simulation results of the edge cloud
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the embodiment of the present application provides a simulation device applied to the edge cloud, including:
  • the simulation module is used to collect the first data of the roadside equipment and the second data of the on-board equipment, and perform the simulation of the vehicle-road collaborative environment according to the configuration information, the first data and the second data, and obtain the simulation result .
  • an embodiment of the present application provides a simulation device, which is applied to the core cloud, including:
  • the routing module is used to provide routing information for roadside devices and vehicle-mounted devices in each region to access the edge cloud.
  • the embodiment of the present application provides a simulation device, which is applied to roadside equipment, including:
  • the first communication module is configured to establish communication with the edge cloud, and provide the first data for the edge cloud;
  • a first decision-making module configured to make behavior decisions according to the simulation results of the edge cloud
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the embodiment of the present application provides a simulation device, which is applied to vehicle-mounted equipment, including:
  • the second communication module is configured to establish communication with the edge cloud, and provide second data for the edge cloud;
  • a second decision-making module configured to make behavior decisions according to the simulation results of the edge cloud
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • the embodiment of the present application provides a communication device, including a transceiver, a processor, a memory, and a program or instruction stored in the memory and operable on the processor; the processor executes When the program or instruction implements the simulation method applied to the edge cloud as above, or realizes the simulation method applied to the core cloud as above, or realizes the simulation method applied to roadside equipment as above, or realizes the simulation method applied to vehicle equipment as above simulation method.
  • the embodiments of the present application provide a readable storage medium, on which are stored programs or instructions, and when the programs or instructions are executed by the processor, the above steps in the simulation method applied to the edge cloud are realized, Or implement the above steps in the simulation method applied to the core cloud, or implement the steps in the above simulation method applied to roadside equipment, or implement the above steps in the simulation method applied to vehicle equipment.
  • the vehicle-road coordination system of the embodiment of the present application implements a cloud device simulation environment on the MEC edge cloud, so as to provide the vehicle-road coordination platform with simulation interaction of roadside equipment and vehicle-mounted equipment close to the real environment.
  • 5G NR New Radio, new air interface
  • FIG. 1 is a schematic diagram of a data flow of a vehicle-road coordination system according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of the overall architecture of the vehicle-road coordination system according to the embodiment of the present application.
  • FIG. 3 is a schematic flow diagram of edge cloud collecting vehicle-side metadata in an embodiment of the present application.
  • FIG. 4 is a schematic flow diagram of edge cloud collecting roadside metadata according to an embodiment of the present application.
  • FIG. 5 is a schematic flow diagram of an edge cloud collecting simulation event metadata according to an embodiment of the present application.
  • FIG. 6 is a schematic flow diagram of collecting scene metadata by an edge cloud according to an embodiment of the present application.
  • FIG. 7 is a schematic flow diagram of an edge cloud collecting path metadata according to an embodiment of the present application.
  • FIG. 8 is a schematic flow diagram of setting scene events according to an embodiment of the present application.
  • FIG. 9 is a schematic diagram of a scene device binding process according to an embodiment of the present application.
  • FIG. 10 is a schematic diagram of a scenario execution flow in an embodiment of the present application.
  • Fig. 11 is a schematic diagram of the workflow of the vehicle-mounted SDK in the embodiment of the present application.
  • Fig. 12 is a schematic diagram of the roadside SDK workflow of the embodiment of the present application.
  • Fig. 13 is a flow chart of the simulation method of the embodiment of the present application.
  • FIG. 14 is a flowchart of a simulation method according to another embodiment of the present application.
  • FIG. 15 is a flowchart of a simulation method according to another embodiment of the present application.
  • FIG. 16 is a flowchart of a simulation method according to yet another embodiment of the present application.
  • FIG. 17 is a structural diagram of a simulation device according to an embodiment of the present application.
  • FIG. 18 is a structural diagram of a simulation device according to another embodiment of the present application.
  • Fig. 19 is a structural diagram of a simulation device according to another embodiment of the present application.
  • FIG. 20 is a structural diagram of a simulation device according to yet another embodiment of the present application.
  • FIG. 21 is a structural diagram of an edge cloud according to an embodiment of the present application.
  • FIG. 22 is a structural diagram of a vehicle-mounted device according to an embodiment of the present application.
  • FIG. 23 is a structural diagram of an edge cloud according to another embodiment of the present application.
  • FIG. 24 is a structural diagram of a vehicle-mounted device according to another embodiment of the present application.
  • sequence numbers of the following processes do not mean the order of execution, and the execution order of each process should be determined by its functions and internal logic, and should not be implemented in this application.
  • the implementation of the examples constitutes no limitation.
  • system and “network” are often used interchangeably herein.
  • B corresponding to A means that B is associated with A, and B can be determined according to A.
  • determining B according to A does not mean determining B only according to A, and B may also be determined according to A and/or other information.
  • a vehicle-road coordination system in the embodiment of the present application includes:
  • the edge cloud is used to collect the first data of the roadside equipment and the second data of the on-board equipment, and perform the simulation of the vehicle-road collaborative environment according to the configuration information, the first data and the second data, and obtain the simulation results .
  • the edge cloud is further used for: verifying the service capability of the vehicle-road coordination system according to the simulation result.
  • the edge cloud (that is, the MEC edge cloud platform) includes a vehicle-road collaboration platform and a cloud simulation environment, which can be used to collect data and perform simulations, etc.
  • the vehicle-road collaboration platform and the details of the cloud simulation environment can be described in detail as follows:
  • Vehicle-road collaboration platform that is, the vehicle-road collaboration platform in edge cloud nodes, which can involve multiple functions such as traffic information fusion perception, real-time calculation and analysis, data storage and opening, resource scheduling, and collaborative computing.
  • the vehicle-road coordination edge node supports low-latency, high-bandwidth, and mass-device connection services in the edge range, and can process or generate five types of basic information (including BSM, SPAT, MAP, RSI, and RSM).
  • the relevant functions of the vehicle-road coordination platform may include:
  • the roadside traffic equipment data collected by real roadside equipment units (that is, roadside equipment) within the edge cloud range, the reported local map MAP information, and the SPAT status of intersection signal lights are collected through the roadside communication module for subsequent use.
  • edge cloud computing
  • the simulated traffic data of the simulated roadside equipment units within the scope of the edge cloud, as well as the simulated MAP, SPAT and other information are collected to verify the vehicle-road collaborative business capability in the edge cloud;
  • the BSM information collected by the real vehicle-mounted equipment units within the range of the edge cloud including the vehicle's geographic location and driving status, and the data collected by various sensors are used for subsequent edge cloud computing;
  • the calculated dynamic perception map is sent to the simulated (or real) on-board equipment unit within the edge cloud through the vehicle-end communication module, which can be used for information on advanced assisted driving and automatic driving.
  • the first data includes at least one of the following: roadside traffic equipment data; map message MAP; traffic light phase and timing message SPAT; roadside traffic time message; roadside information RSI; roadside safety message RSM.
  • the second data includes at least one of the following: geographic location information of the vehicle; basic safety message BSM of the driving state of the vehicle; vehicle sensor data.
  • first data of the roadside device and the second data of the vehicle-mounted device collected by the edge cloud include but are not limited to the data types listed in the foregoing embodiments.
  • the cloud simulation environment (that is, the cloud device simulation environment), which may include device data collection, simulation scene arrangement, roadside equipment simulation and vehicle equipment simulation.
  • the cloud simulation environment analyzes and calculates the data from the simulation input (or real equipment) by simulating the network link, message data transmission and collection and storage in the entire vehicle-road collaborative environment, and generates perception events for people, vehicles or roads. And simulate the decision-making behavior of the equipment, simulate the driving behavior and emergency decision-making of real vehicles in the corresponding scene, as well as the early warning, scheduling and emergency decision-making of roadside traffic equipment in the corresponding scene.
  • the cloud simulation environment can perform cloud scene simulation, which refers to the simulation of roadside equipment and vehicle equipment in edge cloud nodes.
  • the device simulation data in the edge cloud can provide rapid device verification for the vehicle-road collaboration platform, and provide a corresponding range of traffic simulation data for the regional cloud and the global core cloud.
  • the simulated roadside equipment can simulate the behavior of the roadside unit (RSU), realize the management of communication with the vehicle-road collaboration platform and the vehicle-mounted equipment unit, equipment registration and login, data sending and receiving, protocol conversion, RSI, RSM, SPAT , MAP message life cycle management, codec, forwarding, storage of communication messages, parameter configuration, security management and other functions.
  • the simulated roadside equipment (that is, the simulated roadside equipment) can perform scene verification together with other real or simulated roadside equipment and vehicle-mounted equipment.
  • the simulated on-board equipment can simulate the behavior of the on-board communication unit (OBU), realize the decision-making behavior of the vehicle in specific scenarios, display warnings, prompt messages, manage communication with the vehicle-road collaboration platform and roadside units, device registration and login, Data sending and receiving, protocol conversion, BSM, RSI, RSM, SPAT, MAP message life cycle management, communication message encoding, decoding, forwarding, storage, parameter configuration, security management and other functions.
  • the simulated on-board equipment (that is, the simulated on-board equipment) can perform scene verification together with other real or simulated roadside equipment and on-board equipment.
  • the simulation of the vehicle-road collaborative environment through the cloud simulation environment can solve the problem that a large number of real devices need to be involved in the development process of the conventional vehicle-road collaborative platform, and it takes a lot of debugging time and cost to ensure that the simulation environment has High availability, easy expansion, wide application, flexible expansion, and low cost are advantages that other simulation simulators do not have, and realize the pluggable and switching functions between simulated devices and real devices, so that testers and developers can use In the overall development and verification process, it is more convenient to verify the corresponding platform functions and obtain the corresponding required data.
  • the vehicle-road coordination system also includes:
  • the roadside device is configured to establish communication with the edge cloud, provide the first data for the edge cloud, and make a behavioral decision based on the simulation result;
  • the in-vehicle device is configured to establish communication with the edge cloud, provide the second data for the edge cloud, and make a behavioral decision based on the simulation result;
  • the simulated vehicle-road collaborative environment simulated on the edge cloud includes simulated roadside equipment and simulated vehicle-mounted equipment;
  • a software development kit SDK the vehicle-mounted device adopts a vehicle-mounted SDK consistent with the behavior and communication mode of the simulated vehicle-mounted device.
  • the roadside device (referring to the real roadside device here) can inherit the ability to realize the simulated roadside device; In-vehicle equipment) can inherit the ability to simulate on-vehicle equipment; in-vehicle equipment and roadside equipment can quickly access the edge cloud vehicle-road collaboration platform through the SDK to verify vehicle-road collaboration scenarios.
  • the roadside SDK (that is, the roadside SDK) can be used to provide real roadside equipment, inheriting the ability to realize the simulated roadside unit (that is, to simulate the roadside equipment).
  • the real roadside equipment integrates this roadside SDK, it can realize most of the vehicle-road coordination business functions, including: simulation scenario capability, that is, it can inherit and reuse the vehicle-road coordination related business scenarios that have been realized in the roadside simulation;
  • Edge cloud communication capability that is, it can inherit the communication capability realized in the multiplexing roadside simulation, and select the corresponding edge cloud node for communication according to the range of roadside units (that is, roadside equipment) managed in the edge cloud;
  • Broadcast capability that is, it can inherit the communication capability realized in the multiplexing roadside simulation, and wirelessly broadcast RSI, RSM, SPAT, MAP and other messages to vehicles connected to the edge cloud;
  • message life cycle management capability that is, it can inherit the multiplexing road Capabilities such as encoding and decoding, forwarding, storage, and status
  • the vehicle-mounted SDK can be used to provide real vehicle-mounted smart devices (ie, vehicle-mounted equipment), and inherit the ability to implement simulated vehicle-mounted units (ie, simulate vehicle-mounted equipment).
  • vehicle-mounted equipment unit that is, the real vehicle-mounted equipment
  • the real vehicle-mounted equipment unit integrates this SDK, it can realize most of the vehicle-road coordination business functions, including: simulation scene capabilities, that is, it can inherit the vehicle-road coordination related functions that have been realized in the multiplexing vehicle-side simulation.
  • the improved algorithm model after machine learning training in the simulation environment will continue to Improve the decision-making ability of on-board equipment; the edge cloud communication ability, that is, it can inherit the communication ability realized in the multiplexing roadside simulation, and select the corresponding edge cloud node for communication according to the range of vehicles managed in the edge cloud.
  • Vehicles can be equipped with 5G communication modules to reduce communication delays, and use enhanced bandwidth to enrich the type and quantity of data transmitted.
  • the V2X platform (that is, the vehicle-road collaboration platform) in the edge cloud can also access a large number of vehicles or equipment; roadside equipment Communication capability, that is, it can inherit the communication capability that has been realized in the simulation of multiplexed vehicles, and receive messages such as RSI, RSM, SPAT, and MAP broadcast by roadside equipment; The realized communication message encoding/decoding, forwarding, storage, state maintenance and other capabilities; parameter configuration capability, that is, it can inherit the device parameter configuration capability that has been realized in the vehicle-end simulation.
  • roadside equipment Communication capability that is, it can inherit the communication capability that has been realized in the simulation of multiplexed vehicles, and receive messages such as RSI, RSM, SPAT, and MAP broadcast by roadside equipment
  • parameter configuration capability that is, it can inherit the device parameter configuration capability that has been realized in the vehicle-end simulation.
  • an SDK that is consistent with the behavior and communication mode of the simulated device is provided on the real roadside device and vehicle-mounted device, which can avoid the problem of lengthy communication process in the vehicle-road coordination system, thereby saving development and verification costs;
  • Real devices can realize 17 typical application scenarios of vehicle-road coordination defined by the national standard, enabling real devices to quickly access multi-edge cloud, regional cloud, and centralized core cloud fusion infrastructure with vehicle-road coordination vehicle networking capabilities, and quickly apply 5G NR -Information infrastructure such as V2X and artificial intelligence are quickly deployed in innovative infrastructure such as industrial technology innovation bases and autonomous driving test sites, avoiding the impact of overly complex network environments and hardware requirements, and better solving the vehicle road simulation system Cost issues in various aspects of the life cycle.
  • the vehicle-road coordination system further includes: a core cloud, configured to provide routing information for the roadside equipment and the vehicle-mounted equipment in each area to access the edge cloud, and to communicate with the entire area
  • the edge cloud establishes communication, and conducts big data comprehensive analysis and prediction on traffic conditions in the whole region to guide traffic infrastructure planning.
  • the core cloud (that is, the regional/core cloud platform) can provide a corresponding range of edge collaborative computing scheduling, multi-level computing capacity scheduling and other functions in the regional and global scope.
  • simulating (or real) equipment accessing the traffic events generated by the edge cloud and performing fusion calculations it is possible to realize the analysis and prediction of traffic business scenarios with relatively low business delay requirements, so as to guide traffic infrastructure planning.
  • the edge cloud is further configured to: send the first data, the second data, and the road condition data calculated by the edge cloud to the core cloud.
  • the MEC edge cloud in the multi-regional scope collects the device data and the road condition data calculated by the MEC edge cloud, it can report and synchronize to the core cloud.
  • the simulation platform (that is, the cloud simulation environment) runs on a single edge cloud, providing cloud services for roadside equipment and driving vehicles within the jurisdiction of the edge cloud. access and simulation services, and then provide equipment operation data input for the V2X vehicle-road collaboration platform and external platforms of the edge cloud; on the other hand, multiple edge clouds distributed in different geographic Provide access and simulation services for roadside and vehicle-mounted devices within its jurisdiction, and then filter, preprocess, summarize, and encode the simulation data of the multi-access edge cloud, and provide horizontal expansion of a wider geographical range for vehicle-road collaborative devices , and provide integrated data uplink input for the centralized core cloud, and provide downlink management channels for road-side on-board equipment (that is, roadside equipment and on-board equipment) connected to the edge cloud under the unified management and control of the core cloud.
  • road-side on-board equipment that is, roadside equipment and on-board equipment
  • a multi-level simulation system of device, edge, and cloud is established, which supports the hierarchical design of device-side data collection, side-side small-grain area scene simulation, and cloud large-grain global scene simulation. It has the advantage of being easy to expand.
  • the server cluster running in a single edge cloud has the advantage of vertical expansion, and the simulation platform has the advantage of horizontal expansion running in multi-access edge cloud.
  • the edge cloud simulates the vehicle-road collaborative environment according to the configuration information, the first data and the second data, including:
  • the first simulation data of the simulated roadside equipment includes simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data of the simulated vehicle equipment wherein, the second simulation data includes simulated vehicle BSM and simulated vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • a collaborative processing method is proposed to support the entry, arrangement, execution process, construction of simulation and real data (SDK) of scene metadata of mixed simulation and real equipment, and based on machine learning, depth Learning and other methods to establish multi-dimensional simulation libraries such as infrastructure, road ends, and vehicle ends, such as simulated vehicle model libraries, meteorological road surface model libraries, etc., so that complex and diverse smart traffic scenarios can be flexibly supported, and real roadside equipment and vehicle-mounted equipment Provide an SDK that is consistent with the behavior and communication methods of the simulated device.
  • SDK simulation and real data
  • scenario design, communication protocol, and communication method in this application all adopt predetermined scenarios and definitions, which standardize the development and design guidelines to a certain extent, and can make multilateral serial development into parallel development , greatly improving efficiency and saving costs in all aspects.
  • the verifying the business capability of the vehicle-infrastructure coordination system according to the simulation results includes:
  • the edge cloud is also used to collect the configuration information
  • the configuration information includes: device metadata; scene metadata; path metadata.
  • the edge cloud collects the device metadata, including:
  • the device initial metadata is stored in the database as the device metadata.
  • the device initial metadata includes at least one of the following:
  • Vehicle-end metadata includes vehicle information data and corresponding vehicle-mounted equipment data
  • Roadside metadata including roadside equipment information and local area map information
  • Simulation event metadata includes manually collected GPS points on the map, device attributes, running or driving status and simulation events.
  • roadside metadata mainly includes two types of static metadata: roadside equipment information in traffic infrastructure and local area map information.
  • real and simulated metadata can be supported at the same time, and real and simulated metadata of roadside equipment and maps can also be entered in combination, not limited to all real equipment or all simulated equipment.
  • roadside equipment information is mainly used for roadside communication, traffic control, and detection and monitoring of basic information of real (or simulated) equipment such as pedestrians, vehicles, and the environment on the road.
  • logo information of real or simulated metadata RSU, traffic lights, laser or millimeter-wave radar, high-definition camera, temperature and humidity sensor device name, device number, device initialization status, angle, location, communication address, frequency band and other parameters.
  • Local area map information that is, real or simulated metadata sign information, roads, lanes, phases, intersections, location points, and other road traffic network information in the area-wide map that the MEC edge cloud is responsible for.
  • verifying the initial metadata of the device includes: in the case that the initial metadata of the device is the metadata of the vehicle end, verifying the uniqueness of the vehicle information data in the metadata of the vehicle end Verification; if the vehicle information data is unique, the verification is passed.
  • the vehicle metadata is mainly divided into vehicle information data and corresponding on-board equipment data.
  • vehicle information data contains the necessary information for simulating the vehicle, such as the frame number and license plate number, as well as the vehicle length and width.
  • Driving assistance information the necessary information of vehicle equipment includes equipment number, equipment type and other data information used in communication transmission.
  • the entry of vehicle metadata mainly refers to the entry of necessary basic information of vehicles and on-board equipment, so that data and message packaging and arrangement can be performed in the subsequent simulation and simulation process.
  • the uniqueness verification of the vehicle information data in the vehicle-side metadata mainly refers to the uniqueness verification of the vehicle's frame number and vehicle-mounted equipment number during the entry process. Information needs to be unique to determine vehicle identity.
  • verifying the initial metadata of the device includes:
  • the initial metadata of the equipment is roadside metadata, setting the scope of action of the roadside traffic equipment in the roadside equipment information;
  • the roadside equipment information is related information of roadside traffic equipment
  • the roadside traffic equipment includes at least one of the following: RSU, traffic lights, laser radar, millimeter wave radar, high-definition camera and temperature and humidity sensors.
  • the entry of road end metadata mainly includes the following steps:
  • S401 Enter the basic metadata of the roadside equipment, for example, enter the above roadside equipment information and local area map information;
  • S402 Set the scope of equipment, that is, set the scope of action of some roadside traffic equipment, for example, set the range of the laser radar scanning area, the area range of the temperature sensor to detect the temperature, etc.;
  • S403 Set the geographic location of the equipment, that is, set the position of some roadside traffic equipment on the map, or the positional relationship with the road network layer on the map;
  • S404 Verify the road-end metadata, that is, judge that the road-end metadata meets the first preset condition, which may specifically include checking whether the entered roadside equipment and map information of the area are accurate, and whether there is a logical error in the association relationship , or whether there is a conflict with the information that has been entered in history; if the verification is passed, execute S405; if the verification fails, it needs to be re-entered, that is, execute S401;
  • condition that the road-end metadata satisfies the first preset condition includes the following three items:
  • the roadside equipment information and the local area map information are accurate;
  • verifying the initial metadata of the device includes:
  • the initial metadata of the device is metadata of a simulated event
  • select the device associated with the simulated event wherein, the device includes the roadside device, the vehicle-mounted device, the simulated roadside device, and the Describe the simulated vehicle equipment;
  • the simulated events mainly refer to traffic events generated or associated by road traffic participants expected in the vehicle-road coordination scenario, corresponding to typical scenarios of vehicle-road coordination. For example, events such as road congestion, construction, accidents or hazards. It should be noted that the simulated events can work together with real events occurring on real devices (ie, roadside devices and vehicle-mounted devices) to create vehicle-road coordination scenarios. For example, in an area, multiple intersection traffic congestion events may be generated through data collected by real roadside lidar and cameras, and at the same time, gale danger warning events may be generated through simulation. These two kinds of time work together for autonomous vehicles. Urges cars to avoid this area.
  • the edge cloud can collect vehicle-side metadata, road-side metadata, simulation event metadata, path metadata, and scene metadata; wherein,
  • the vehicle metadata includes vehicle information data and corresponding vehicle equipment data
  • the roadside metadata includes roadside equipment information and local area map information, which are used for roadside communication, traffic control, and detection and monitoring of basic information of real (or simulated) equipment such as pedestrians, vehicles, and the environment on the road. It should be noted that the monitored basic information may form a corresponding simulation event.
  • the metadata of the simulation event includes GPS points manually collected on the map, device attributes, running or driving status, and simulation events; wherein, the manual collection of GPS points on the map may include continuous GPS points on the vehicle driving path ; Device properties can include the frequency of traffic lights changing; running or driving status can include vehicle speed, direction angle, etc.; simulation events can include road construction events. It should be noted that the GPS points, device attributes, running or driving status, etc. manually collected on the map can form corresponding simulation events;
  • the path metadata is used as basic information for simulating vehicle operation to generate a pre-planned path
  • the scene metadata is used to set specific scenes that need to be executed on the generated path; the specific scenes are formed by free combination of basic scenes, and the basic scenes can be defined by national standard scenes 17 basic scenarios such as forward collision warning, intersection collision warning, left turn assistance, etc.
  • simulation events do not conflict based on the mutually exclusive conditions. That is, there cannot be behavioral mutual exclusion between simulation events; or, there cannot be behavioral mutual exclusion within independent simulation events.
  • the simulated vehicle runs according to a pre-planned path, which includes road section 1, road section 2, and road section 3; among them, road section 1 is set with simulated events such as wet and slippery roads. Events, road section 2 is set with simulated events such as construction events, traffic lights indicating yellow events, and weather events with strong wind level 7, and road section 3 is set with simulated events such as road congestion events, traffic lights indicating green events, green wave guidance event.
  • simulation events need not conflict based on the mutually exclusive conditions. From the first aspect, it means that there cannot be mutual exclusion of behaviors between simulation events. Specifically, there cannot be mutual exclusion of behaviors between the event that the weather in road section 2 is a windy level 7 event and the construction event, that is to say, in It is impossible for two simulated events to occur at the same time at the same location; there cannot be behavioral mutual exclusion between the road congestion event in section 3 and the event that the traffic light indicates green, that is, the same event at the same location. No simultaneous occurrence between two simulated events at a moment is possible. From another aspect, it means that there cannot be mutual exclusion of behaviors within independent simulation events.
  • the event that the weather is a strong wind of level 7 and the event that the weather is a strong wind of level 0 cannot have mutual exclusion of behaviors. That is to say, there cannot be two simulation events of the same type set at the same time at the same location; at the same time in section 3, the road congestion event and the smooth road event cannot have mutually exclusive behaviors, that is, in There cannot be two simulation events of the same type set at the same time at the same location.
  • S501 select the equipment or equipment group associated with the simulation event, the equipment includes roadside equipment, vehicle-mounted equipment, simulated roadside equipment and simulated vehicle-mounted equipment; for example, a group of traffic lights in an area are associated with SPAT event information;
  • S502 Select the event type (that is, the type of simulation event) to correspond to a specific scene; for example, congestion, construction, accident, danger, forward collision, speed limit, etc.;
  • S503 Set the parameters of the event, including event level, execution time, period, location, value or other trigger conditions; Ice thickness is 15mm;
  • S504 Set mutually exclusive conditions for events; for example, road icing hazard events and high temperature hazard events should not occur in the same area within the same time range;
  • S505 Verify the simulation event, that is, check whether the simulation event is accurate, whether there is a logical error in the relationship with the equipment or the area map, or whether there is a conflict with the information that has been entered in history; if the verification is passed, execute S506; if the verification fails, it needs to be re-entered, that is, execute S501;
  • the parameters include event level, execution time, cycle, location and value.
  • the situation that the simulation event satisfies the second preset condition includes at least the following three items:
  • the ways of entering scripts can be divided into template import, online recording of device data, and online metadata formulation.
  • the edge cloud collects the scene metadata, including at least one of the following:
  • step shown in line a in Figure 6 receive the first scripted data uploaded manually; wherein, the first scripted data is the third data uploaded by the roadside equipment and the vehicle-mounted equipment Scripted data formed after screening and processing; the third data includes vehicle behavior data and roadside equipment data related to the vehicle.
  • scripts can be entered by importing templates.
  • the data uploaded by real devices can be screened by time period, summarized and formatted according to device types, and then formed in line with the operation of the vehicle-road coordination system scenario.
  • Scripted data the user manually uploads data scripts online to import, and the data content must include the behavior data of the vehicle to be entered and all roadside equipment data involved in the vehicle.
  • the script can be entered through online recording of device data.
  • the simulation service side requests the V2X platform to obtain data of a specific device through various settings, and the V2X platform forwards the data of the real device to the simulation side.
  • the scripted data conforming to the operation of the vehicle-road coordination system is formed and entered.
  • the data content must include all vehicles and related roadside equipment data.
  • scripts can be entered in the form of online metadata formulation.
  • scripted data that conforms to the operation of the vehicle-road coordination system scenario can be manually edited and entered on the visual operation interface, that is, the route or location that the vehicle is going to travel.
  • this type of data can only be used as metadata in the scene arrangement process, and executable script data will be generated according to the path metadata in the scene arrangement process.
  • the first scripted data, the first scripted data and the first scripted data are all scripted data conforming to the operation of the simulation scenario.
  • scripts it can be divided into two execution modes: replaying the historical behavior of real equipment (including roadside equipment and vehicle equipment), wherein equipment data is recorded online and The metadata imported by the template can only be used in this scene; the custom input script data (that is, the script entered in the way of online metadata formulation) can only be used as the supporting metadata of the scene, which is used to plan and design the running route of the on-board equipment in the scene, as The underlying supporting data in the scene.
  • the edge cloud can collect simulation data of roadside equipment and vehicle-mounted equipment, and the simulation data can be obtained from real equipment data in three ways.
  • the real device data comes from the real devices on the road side and the car side of the vehicle collaboration platform, which are obtained through automatic data collection, data filtering, standardized encoding, transcoding, and forwarding through the simulation SDK when the real roadside devices and vehicle-mounted devices are running.
  • the data; the editing and entry method comes from manually collecting GPS points on the map (for example, continuous GPS points on the vehicle driving path), inputting equipment attributes (for example, the frequency of traffic signal light state changes), operating or driving status ( For example, information such as vehicle speed, direction angle, etc.), simulation events (such as road construction events), and then perform standardized encoding and transcoding consistent with the reporting method of real equipment data; real equipment data and editing
  • the input data of the simulated equipment is fused to realize the free combination of real equipment and simulated equipment (for example, the combination of real roadside equipment and simulated vehicle equipment, or the combination of simulated roadside equipment and real vehicle equipment), and verifies a large number of
  • the vehicle-road coordination capability of road-side equipment and vehicle-mounted equipment provides an efficient and flexible practical solution, and can also reduce the investment of real equipment in specific scenarios, thereby saving costs.
  • the edge cloud collects the path metadata, including:
  • Route metadata is the basic information for simulating vehicle operation. After the route metadata is generated, it is necessary to bind the route metadata and vehicles one-to-many as needed.
  • the online metadata entry function can enter one or more path metadata at one time to provide the necessary support for matching specific vehicle scenarios.
  • the starting point and the starting point of the segmented road section can be set manually by selecting points on the visual map page, and the strategy information for driving at the two points can be selected. For example, information such as the time of the start point and end point, speed, direction angle, and the granularity of the preset segmentation.
  • the process of collecting the path metadata by the edge cloud (that is, the simulation process of the meta-route driving point) is shown in Figure 7:
  • S702 Segment the road segment on the path, that is, segment the road segment according to key points, and classify the road segment into types;
  • the driving behavior of the vehicle may change intelligently and in real time according to the scene events. If there are no other external factors, the vehicle should be simulated and run according to the path metadata.
  • the simulation basic route metadata (ie route metadata) is intelligently added to the simulated driving position information points through an algorithm, which can make the vehicle running behavior more smooth and real.
  • the edge cloud divides road segments on the path, including at least one of the following:
  • Segment road segments based on angle and acceleration.
  • the edge cloud performs scene orchestration, including:
  • the edge cloud sets scene events on the path according to the path metadata and the scene metadata, including:
  • S803 Set scene events on the path; wherein, the scene events are formed by free combination of basic scenes;
  • S806 Determine whether the input is completed; if completed, execute S807; otherwise, execute S803;
  • the key point scene event setting that is, key point behavior weaving, setting scene events on the path
  • can only be used for interactive fusion simulation scenes mainly refers to setting the scene behavior that needs to be executed on the planned path metadata
  • the process has the following characteristics: it contains 17 basic standard national standard scene behavior events; multiple national standard scene behaviors can be freely combined to a certain extent on the metadata of the interactive simulation path; it has road planning and scope for the occurrence of specified scenes; real equipment and Simulated devices can be mixed in scenarios.
  • real roadside devices can provide simulated vehicles with data support for automatic driving or behavior decision-making.
  • simulated roadside devices can also provide dynamic, credible and standard data for real V2X road test vehicles. supporting data.
  • the edge cloud verifies the scenario event, including: judging whether there is behavior mutual exclusion between the scenario events and between the scenario event and the path metadata; if there is no behavior mutual exclusion If it is rejected, the verification passes; otherwise, the verification fails.
  • scene events cannot have mutually exclusive behaviors, such as road construction events and traffic light interactions
  • scene events and path metadata cannot have mutually exclusive behaviors, such as left-turn assistance cannot be performed on the through lane.
  • the scene simulation engine is used to report and formulate the SDK from the online device (that is, online recording of device data), formulate self-defined metadata (that is, formulate online metadata), and import template data (that is, import templates).
  • the formulated data is compiled into a scene script suitable for simulation equipment through a certain degree of manual combination, setting and automatic generation of algorithms in accordance with the 17 basic scenarios defined by the national standard scene, such as forward collision warning, intersection collision warning, and left turn assistance. , realizing the simulation scene arrangement of roadside equipment and on-board equipment, which is used to verify the capabilities of the vehicle-road coordination system, roadside equipment, and on-board equipment.
  • events and conditions that are not easy to create in the real world can be provided, such as congestion events, vehicle out-of-control warning events, road construction events, and road weather hazards such as strong winds, heavy fog, and icy roads, so as to avoid scene verification
  • the conditions for event generation cannot be realized at the time, which improves the efficiency of scene verification.
  • the simulation scene can directly generate dangerous events, it avoids the danger caused by real vehicles to drivers, pedestrians, roads, etc. in order to verify the simulation scene while driving.
  • an algorithm model can be further constructed, and algorithms such as machine learning can be used to provide algorithm training functions for automatic driving behaviors in specific scenarios, which can be applied to edge cloud assisted driving
  • algorithms such as machine learning
  • the deployment of a large number of real equipment can be reduced to reduce costs, and can Create scene conditions that are difficult to achieve in the real world.
  • the main vehicle host vehicle, HV
  • a simulated vehicle remote vehicle, RV
  • the real roadside lidar detects a For pedestrians
  • the main vehicle should slow down at this time, instead of overtaking from the left as preset in the scene.
  • this application can be used alternately with real and simulated equipment, is easy to expand, and is superior in subsequent data value-added, application versatility, machine learning data diversity, and versatility, and solves the problems in the prior art.
  • the simulation scenarios include historical playback fixed scenarios and interactive fusion simulation scenarios.
  • simulation scenarios can be divided into two types: fixed scenarios for history playback and simulation scenarios for interactive integration.
  • the historical playback fixed scene mainly refers to replaying the operation status of an actual vehicle-road coordination area in the past, which is often used for display and exhibition;
  • the interactive fusion scene mainly refers to the integration of real equipment (that is, roadside equipment and vehicle equipment) and The simulation equipment (that is, the simulation roadside equipment and the simulation vehicle equipment) is weaved, so that the real equipment and the simulation equipment can run together in a specific circuit, so as to obtain the feedback data of the vehicle's behavior strategy or the interaction result of the roadside equipment.
  • the edge cloud executes the simulation scenario, including:
  • S1002 Determine the type of the simulation scenario according to parameter configuration or API call; execute the simulation scenario according to the type. Wherein, when the simulation scene is a fixed scene of historical playback, perform S1003; when the simulation scene is an interactive fusion simulation scene, perform S1004.
  • scenario execution i.e. execution of simulation scenarios
  • scenario execution aims to run the programmed vehicle-side metadata, road-side metadata and simulation event metadata in specific scenarios of Vehicle-end transportation infrastructure and vehicles verify their communication capabilities and data processing capabilities under the vehicle-road synergy, as well as the behavioral decision-making capabilities of vehicle-end and road-end computing devices enhanced by artificial intelligence algorithms.
  • simulation scenarios are jointly executed at the same time period.
  • the real devices When checking and accepting real devices related to vehicle-road coordination and autonomous driving (i.e. vehicle-mounted devices and roadside devices), the real devices are connected to the vehicle-road collaboration platform of the edge cloud, and the metadata and simulation of simulated devices that are not easy to implement in the real world
  • the event metadata together execute the preset scene of vehicle coordination in the same time period.
  • the simulation environment can provide events and conditions that are not easy to create in the real world for the realization of vehicle-road collaboration scenarios, reducing the cost and risk of scenario operation.
  • the simulation library is the basic supporting data for artificial intelligence's decision-making ability. It is attached to the V2X platform and conducts autonomous learning through the behavior data generated by real vehicle equipment and roadside equipment during operation, so as to be able to make decisions for the same scene behavior. ability to make decisions.
  • the edge cloud can establish a thread pool to create threads for the main tasks such as broadcasting driving data, event reception, driving planning, time processing, and data reporting network communication at the vehicle end (i.e., vehicle equipment), and set the thread between threads.
  • the data sharing and synchronization mechanism starts each thread and reads and executes the vehicle driving path script according to a fixed frequency; the edge cloud can also establish a thread pool to broadcast RSI and MAP from the vehicle-road collaboration platform for the road end (that is, roadside equipment) , SPAT messages or scene events, the roadside actively generates RSM alarms, maintains the status of alarm messages within the validity period, broadcasts events and other main tasks to create threads, set up data sharing and synchronization mechanisms between threads, start each thread and specify according to the simulation scene Frequency reading, execution of roadside equipment (such as traffic lights) scripts.
  • roadside equipment such as traffic lights
  • the vehicle will decode the script data, establish associations with the traffic road network or other device metadata and other preprocessing; if the scene event causes If the car has to change its driving route, the car end plans a new driving route (including GPS points, steering angle, driving speed, etc.) that is different from the preset script through simulation; use algorithms to process scene events, for example, using deep learning , reinforcement learning and other methods to continuously improve the optimal solution of event processing.
  • the roadside device will decode the script data, establish associations with the traffic road network or other device metadata, and other preprocessing.
  • the edge cloud initializes the scene execution engine, including at least one of the following:
  • the scenario execution engine when the scenario execution starts, the scenario execution engine is initialized. For example, initialize the program space required for operation, load operation parameters, connect to local databases, caches, message queues and other middleware, load necessary vehicle-side metadata, road-side metadata and simulation event metadata, and initialize necessary network communication links , edge cloud routing network address, etc.
  • the edge cloud executes the simulation scenario, including:
  • the equipment includes the roadside equipment, the vehicle equipment, the simulated roadside equipment and the simulated vehicle equipment;
  • the historical scene metadata includes equipment operation data and scene recording data
  • the type is a fixed scene of historical playback, that is, the execution of the historical scene
  • the data is broadcast to roadside equipment and on-board equipment.
  • the vehicle-road collaboration platform can monitor the current dynamic driving state of the vehicle and the decision-making behavior in historical scenarios on the edge cloud.
  • the execution of the simulation scenario by the edge cloud includes:
  • the scene metadata includes device basic information and regional traffic road relationship network;
  • the device includes the roadside device, the vehicle-mounted device, the simulated road side equipment and the simulated on-vehicle equipment;
  • the type is an interactive fusion simulation scene
  • the instruction obtained by the scene engine is not an execution history scene, but an interactive fusion simulation scene
  • load the associated scene metadata according to the current vehicle equipment and roadside equipment equipment types , including the basic information of the device, the regional traffic road relationship network, and the scripted data matching the device.
  • one simulation scene is bound to at least one simulation device, and one simulation device is only bound to one simulation scene; wherein, the simulation device includes the simulation vehicle-mounted device and the simulation roadside device.
  • the scene is used as the basic support data for simulating on-board equipment, simulating roadside equipment, and interaction between devices.
  • a scene can Bind multiple simulated devices (i.e. simulated vehicle equipment and simulated roadside equipment), but one simulated device can only be bound to one scene.
  • the edge cloud is further configured to: send a dynamic perception map to the vehicle-mounted device and/or the simulated vehicle-mounted device within coverage of the edge cloud according to a simulation result.
  • establishing communication between the vehicle-mounted device and the edge cloud includes: receiving the network address of the edge cloud sent by the core cloud; The first edge cloud corresponding to the network address, and establish a connection with the first edge cloud.
  • the on-board SDK in the real car or the scene engine in the simulated car can select the nearest edge cloud (namely the first edge cloud) and establish a connection according to the edge cloud network address in the area obtained during initialization. After the connection is established, you can cycle Obtain the list of RSUs and communication addresses within close proximity.
  • the on-vehicle device provides the second data for the edge cloud, including:
  • the SDK configuration pull the corresponding scripted data from the edge cloud, and according to the SDK configuration, connect to the corresponding roadside device, and receive the first message from the roadside device after the connection is successful;
  • S1103 Cache the scripts, and execute them one by one, one by one, according to the execution order and frequency of the scripts;
  • S1105 Determine whether the connection is successful; if the connection is successful, execute S1104; if the connection fails, you need to re-enter, that is, execute S1106;
  • the SDK can trigger national standard 17 basic demonstration scenarios (such as forward collision warning, intersection collision prediction, and forward congestion reminder scenarios) according to the parameter configuration interface.
  • Location selection switches the strategy of the nearest edge cloud.
  • the event and early warning data of the simulated or real roadside equipment used for demonstration can be obtained to complete the verification of equipment capabilities.
  • the simulation platform and the vehicle-road collaboration platform running in the edge cloud display the simulation scene, they need to obtain the data of the vehicle equipment in this scene according to the standardized coding format, communication frequency, communication method and scene processing behavior.
  • Road collaboration scenarios define consistent program standard processes and behaviors, enabling a large number of different types of vehicle-mounted devices to serve the vehicle-road collaboration platform with standardized scene processing capabilities, reducing the complexity brought by different types of equipment, and reducing the cost of the vehicle-road collaboration platform. At the same time, it can provide a standardized and rapid verification entry for verifying the vehicle-road coordination ability or automatic driving ability of the vehicle.
  • the vehicle-mounted device executes the script, and executes the following steps in a loop:
  • the following steps can be executed cyclically: receiving scenario events broadcast by remote vehicles (ie other vehicle-mounted devices) or roadside devices and encapsulated into messages such as RSI and RSM, and simulating dynamic event driving data; Events are processed; driving data and event processing results are reported.
  • scenario events broadcast by remote vehicles (ie other vehicle-mounted devices) or roadside devices and encapsulated into messages such as RSI and RSM, and simulating dynamic event driving data; Events are processed; driving data and event processing results are reported.
  • each time the on-vehicle device completes the execution of a script it sends a script execution path to the edge cloud; and, every time it completes a scene event processing, it sends a scene event processing to the edge cloud result.
  • the on-vehicle device every time the on-vehicle device completes the execution of a driving script and processes a scene event, it will asynchronously send the path of executing the script or the result of scene event processing through the thread.
  • the roadside device is further configured to: select the second edge cloud corresponding to the network address closest to the location of the roadside device through the built-in or configured network address of the edge cloud, and communicate with The second edge cloud establishes a connection; periodically obtains a list of vehicle-mounted devices within a second preset range, and a communication address corresponding to each of the vehicle-mounted devices, and establishes an association relationship with traffic road network or other device metadata .
  • the real roadside SDK or the scene engine in the simulated roadside unit can select the nearest edge cloud and establish a connection according to the edge cloud network address in the area obtained during initialization; after the connection is established, it can periodically obtain the edge cloud Range of car listings and mailing addresses.
  • the roadside equipment is also configured to perform the following steps cyclically within a preset period:
  • the warning event is broadcast to vehicles within a third preset range.
  • the roadside device can perform the following steps through the main thread cycle: receive the alarm event from the vehicle-road collaboration platform in the edge cloud or generate an alarm event independently; determine the validity period of the event, and mark it as deleted if it expires ; broadcast event to vehicles within proximity.
  • the roadside device is further configured to: periodically check the validity of the warning event; and discard the warning event when the warning event has expired.
  • S1201 The SDK is bootloaded when the roadside equipment unit is powered on, and the internal initialization of the SDK is performed. For example, operation space allocation, storage space inspection, roadside equipment unit communication module inspection, etc.;
  • S1202 The SDK continues bootloading according to the built-in parameters, or modifies the running parameters according to the remote interface configuration. For example, perform a soft reset through the interface configuration to clear the stored messages, and configure the edge cloud node parameters to set the address and login authentication information of the edge cloud vehicle-road collaboration V2X platform that needs to be connected;
  • the SDK can trigger national standard 17 basic demonstration scenarios according to the parameter configuration interface, for example, road danger warning, speed limit warning, green wave speed guidance and other scenarios);
  • the SDK collects events and data of roadside traffic facilities through the device communication module of the roadside device unit, such as the status of traffic lights, signage information, camera data, temperature and humidity meter data, etc.; and temporarily stores them in the device storage space to prepare Report to the V2X platform;
  • SDK selects the routing strategy of the nearest edge cloud according to the built-in edge cloud communication address table, and connects the V2X vehicle-road collaboration platform in the edge cloud with the simulation or real vehicle used for demonstration;
  • S1206 The SDK tries to connect to the V2X platform in the edge cloud node through the built-in or configured edge cloud connection address and authentication information; if the connection is unsuccessful, retry after N seconds to reconnect, that is, execute S1205; if the connection is successful, execute S1207, and periodically report heartbeat data packets to keep the device online;
  • S1207 The SDK reports the collected data from the roadside traffic facilities to the edge cloud V2X platform within close range;
  • the SDK receives event reminder messages (RSI) and security messages (RSM) from the V2X platform through the established connection with the edge cloud, and caches them in the device memory space after message parsing;
  • RSS event reminder messages
  • RSS security messages
  • vehicle-road collaboration platform generates road event or warning information after calculation, and finally pushes it to the vehicle-mounted equipment to complete the verification of the roadside equipment capabilities.
  • S1209 Periodically check the validity of the message; if valid, execute S1210; if invalid, discard the message; for example, whether the intersection congestion event has expired, etc., if it has expired, discard the message;
  • the SDK periodically broadcasts the cached message to nearby vehicles through the wireless network after encoding the message. If the vehicle has received the message, it reports the message to the V2X platform, so that the V2X platform can receive the message, Statistical analysis of utilization rate, etc.;
  • the simulation platform and the vehicle-road collaboration platform running in the edge cloud display the simulation scene, they need to obtain the data of the roadside equipment in the scene according to the standardized coding format, communication frequency, communication method and scene processing behavior.
  • the roadside SDK defines a consistent program standard process and behavior, so that a large number of different types of roadside devices serve the vehicle-road collaboration platform with standardized scene processing capabilities, reducing the complexity caused by different types of equipment It reduces the cost of implementing the vehicle-road coordination platform, and also provides a standardized and fast verification entry for verifying the vehicle-road coordination capability of roadside equipment or assisting in the verification of autonomous vehicles.
  • the roadside equipment can continuously optimize the efficiency of sending information to the vehicle-road collaboration platform in the edge cloud and the driving vehicle event.
  • the detection, tracking and monitoring of traffic participants at the roadside can be optimized through deep learning algorithms, and the delay in judging scene events such as road congestion and danger can be reduced.
  • edge-cloud collaboration and vehicle-road collaboration are realized, and a device simulation environment is implemented on the MEC edge cloud to provide the vehicle-road collaboration platform with simulation interactions of roadside devices and vehicle-mounted devices that are close to the real environment.
  • edge-cloud collaboration adopts the MEC multi-access edge cloud operation simulation environment close to roadside equipment and vehicle equipment, and can interact with roadside equipment and vehicle equipment at high speed with BSM, MAP, SPAT, RSI and RSM and other messages, if combined with 5G NR technology, can support millions of real device access and message processing capabilities on the edge cloud.
  • Vehicle-road collaboration, MEC multi-access edge cloud provides shared infrastructure for equipment and vehicle-road collaboration applications within the region, as well as configuration information and simulation behavior libraries required for simulation; access simulation on the MEC edge cloud based on configuration information (or real) equipment data, design and run the simulation scene, dynamically load according to the scene configuration during operation and simulate the corresponding behavior in the simulation behavior library to verify the vehicle equipment, roadside equipment, vehicle-road collaborative platform, and three-party platform Data collection capabilities, communication capabilities, data fusion processing capabilities, behavioral decision-making capabilities, and collaboration capabilities with different platforms or applications in various scenarios of vehicle-road collaboration.
  • the embodiment of the present application supports collaborative data processing between simulated and real devices, provides elastic expansion, distributed clusters, caching, artificial intelligence, and big data processing capabilities, enhances support for local and local services, and can effectively reduce network delays. To better carry out smart transportation business provides a certain degree of help and support.
  • the system's multilateral and multiple dependencies are layered, and a complete closed-loop business logic and multi-device SDK are provided for various external dependencies that can be segmented, simulated, and interacted in real solution.
  • the business entities that any party relies on can be embedded in the overall vehicle-road coordination system through single or all simulations to ensure the stable operation of the system, thereby solving all problems in project development, deployment, and testing.
  • the problems encountered are too long links, complex data sources, different data formats, difficult positioning problems, and strong dependence on external environments and conditions, which solve the communication noise in the process of connecting devices.
  • the decoupling of all levels in the overall environment of vehicle-road collaboration enables rapid development, data transparency, high customization, and high availability.
  • the embodiment of the present application provides a simulation method applied to the edge cloud, including:
  • S1301 Collect the first data of the roadside equipment and the second data of the on-vehicle equipment, and perform a simulation of the vehicle-road collaborative environment according to the configuration information, the first data, and the second data, and obtain a simulation result.
  • the simulation method of this embodiment by collecting data from roadside equipment and vehicle-mounted equipment, simulates the vehicle-road collaborative environment on the edge cloud, which can provide events and conditions that are not easy to create in the real world, and can solve the problem of conventional vehicle-road During the development process of the collaboration platform, it is necessary to intervene in a large number of real device docking issues, thereby saving debugging time and costs.
  • the simulation method further includes: sending the first data, the second data, and the road condition data calculated through the edge cloud to a core cloud.
  • the first data includes at least one of the following:
  • the second data includes at least one of the following:
  • the simulation of the vehicle-infrastructure collaborative environment is performed according to the configuration information, the first data and the second data, and the simulation results are obtained, including:
  • the first simulation data of the simulated roadside equipment wherein, the first simulated data comprises simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data includes simulation vehicle BSM and simulation vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • the simulation method further includes: sending the first data, the second data, and the road condition data calculated through the edge cloud to the core cloud.
  • the simulation method further includes: verifying the service capability of the vehicle-infrastructure coordination system according to the simulation result.
  • the verifying the business capability of the vehicle-infrastructure coordination system according to the simulation results includes:
  • the simulation method further includes: collecting the configuration information
  • the configuration information includes:
  • the edge cloud collects the device metadata, including:
  • the device initial metadata is stored in the database as the device metadata.
  • the device initial metadata includes at least one of the following:
  • Vehicle-end metadata includes vehicle information data and corresponding vehicle-mounted equipment data
  • Roadside metadata including roadside equipment information and local area map information
  • Simulation event metadata includes manually collected GPS points on the map, device attributes, running or driving status and simulation events.
  • verifying the initial metadata of the device includes:
  • the initial metadata of the device is the vehicle-side metadata
  • uniqueness verification is performed on the vehicle information data in the vehicle-side metadata
  • verifying the initial metadata of the device includes:
  • the initial metadata of the equipment is roadside metadata, setting the scope of action of the roadside traffic equipment in the roadside equipment information;
  • the roadside equipment information is related information of roadside traffic equipment
  • the roadside traffic equipment includes at least one of the following: RSU, traffic lights, laser radar, millimeter wave radar, high-definition camera and temperature and humidity sensors.
  • condition that the road-end metadata satisfies the first preset condition includes the following three items:
  • the roadside equipment information and the local area map information are accurate;
  • verifying the initial metadata of the device includes:
  • the initial metadata of the device is metadata of a simulated event
  • select the device associated with the simulated event wherein, the device includes the roadside device, the vehicle-mounted device, the simulated roadside device, and the Describe the simulated vehicle equipment;
  • the simulation event has no conflict based on the mutual exclusion conditions
  • the parameters include event level, execution time, cycle, location and value.
  • the situation that the simulation event satisfies the second preset condition includes at least the following three items:
  • collecting the scene metadata includes at least one of the following:
  • the first scripted data is scripted data formed after screening and processing the third data uploaded by the roadside device and the vehicle-mounted device;
  • the third data includes vehicle behavior data and roadside equipment data related to said vehicle;
  • the first scripted data, the first scripted data and the first scripted data are all scripted data conforming to the operation of the simulation scenario.
  • collecting the path metadata includes:
  • segmenting road segments on the path includes at least one of the following:
  • Segment road segments based on angle and acceleration.
  • perform scene choreography including:
  • the edge cloud sets scene events on the path according to the path metadata and the scene metadata, including:
  • the scene events in the queue to be stored are stored.
  • verifying the scene event includes:
  • the simulation scenarios include historical playback fixed scenarios and interactive fusion simulation scenarios.
  • executing the simulation scenario includes:
  • the simulation scenario is executed.
  • perform scenario execution engine initialization including at least one of the following:
  • executing the simulation scene includes:
  • the equipment includes the roadside equipment, the vehicle equipment, the simulated roadside equipment and the simulated vehicle equipment;
  • the historical scene metadata includes equipment operation data and scene recording data
  • executing the simulation scenario includes:
  • the scene metadata includes device basic information and regional traffic road relationship network;
  • the device includes the roadside device, the vehicle-mounted device, the simulated road side equipment and the simulated on-vehicle equipment;
  • one simulation scene is bound to at least one simulation device, and one simulation device is only bound to one simulation scene; wherein, the simulation device includes the simulation vehicle-mounted device and the simulation roadside device.
  • the simulation method further includes: according to the simulation result, sending a dynamic perception map to the vehicle-mounted device and/or the simulated vehicle-mounted device within the coverage of the edge cloud.
  • the simulation method of this embodiment implements a device simulation environment on the edge cloud to provide the vehicle-road collaboration platform with simulation interactions of roadside devices and vehicle-mounted devices that are close to the real environment, and supports simulation and real device collaboration data. Processing can provide events and conditions that are not easy to create in the real world for the realization of vehicle-road coordination scenarios, reducing the cost and risk of scenario operation.
  • the embodiment of the present application provides a simulation method applied to the core cloud, including:
  • S1401 Provide routing information for roadside devices and vehicle-mounted devices in each region to access the edge cloud.
  • the simulation method of this embodiment can provide routing information, so that the roadside equipment and the on-board equipment can quickly access the edge cloud nearby.
  • the simulation method also includes:
  • the simulation method of this embodiment establishes communication with the edge cloud, and can provide a corresponding range of edge collaborative computing scheduling, multi-level computing capacity scheduling and other functions in the regional and global scope.
  • the analysis and prediction of traffic business scenarios with relatively low business delay requirements can be realized, thereby guiding traffic infrastructure planning.
  • the embodiment of the present application provides a simulation method applied to roadside equipment, including:
  • S1501 Establish communication with the edge cloud, and provide the first data for the edge cloud
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the roadside equipment can inherit the ability to realize the simulated roadside equipment, and can act according to the simulation results of the edge cloud decision making.
  • the first data includes at least one of the following:
  • the simulation method also includes:
  • the list of vehicle-mounted devices within the second preset range and the communication address corresponding to each vehicle-mounted device are periodically obtained, and an association relationship is established with traffic road network or other device metadata.
  • the simulation method also includes:
  • the warning event is broadcast to vehicles within a third preset range.
  • the simulation method also includes:
  • the alarm event is discarded.
  • the simulation method of this embodiment by adopting the roadside SDK consistent with the behavior and communication mode of the simulated roadside equipment, enables the roadside equipment to inherit the ability to realize the simulated roadside equipment, for example, the simulation scene capability , edge cloud communication capabilities, and vehicle-side broadcast capabilities, etc., thus solving the problem of long and noisy communication processes due to the large number of participants in the common vehicle-road collaborative system design and development process, which can save development costs and development cycles.
  • the embodiment of the present application provides a simulation method applied to vehicle-mounted equipment, including:
  • S1601 Establish communication with the edge cloud, provide the second data for the edge cloud, and make behavioral decisions according to the simulation results of the edge cloud;
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • the simulation method of this embodiment uses a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device, so that the vehicle-mounted device can inherit the ability to simulate the vehicle-mounted device, and can make behavior decisions based on the simulation results of the edge cloud.
  • the second data includes at least one of the following:
  • establishing communication with the edge cloud includes:
  • the providing the second data for the edge cloud includes:
  • the SDK configuration pull the corresponding scripted data from the edge cloud, and according to the SDK configuration, connect to the corresponding roadside device, and receive the first message from the roadside device after the connection is successful;
  • the vehicle-mounted device executes the script, and executes the following steps in a loop:
  • each time the on-vehicle device completes the execution of a script it sends a script execution path to the edge cloud; and, every time it completes a scene event processing, it sends a scene event processing to the edge cloud result.
  • the simulation method of this embodiment by using the vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device, enables the vehicle-mounted device to inherit the capabilities of the simulated vehicle-mounted device, such as the ability to simulate scenarios, early warning decision-making capabilities, etc. , which can ensure that the real equipment can realize the 17 typical application scenarios of vehicle-road collaboration defined by the national standard, avoid overly complex network environment influences and hardware requirements, and better solve the cost problems in all aspects of the life cycle of the vehicle-road simulation system.
  • the embodiment of the present application provides a simulation device applied to the edge cloud, including:
  • the simulation module 1701 is configured to collect the first data of the roadside equipment and the second data of the on-board equipment, and perform a simulation of the vehicle-road collaborative environment according to the configuration information, the first data, and the second data, to obtain a simulated result.
  • the simulation device also includes:
  • the first sending module is configured to send the first data, the second data and the road condition data calculated by the edge cloud to the core cloud.
  • the first data includes at least one of the following:
  • the second data includes at least one of the following:
  • the simulation module 1701 includes:
  • the scene arrangement sub-module is used to perform scene arrangement according to the configuration information, the first data and the second data to form a simulation scene;
  • the scenario execution submodule is used to execute the simulation scenario to obtain at least one of the following:
  • the first simulation data of the simulated roadside equipment wherein, the first simulated data comprises simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data includes simulation vehicle BSM and simulation vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • the simulation device also includes:
  • the second sending module is configured to send the first data, the second data and the road condition data calculated by the edge cloud to the core cloud.
  • the simulation device also includes:
  • the verification module is configured to verify the service capability of the vehicle-road coordination system according to the simulation results.
  • the verification module includes:
  • the verification submodule is used to compare whether the first data in the same simulation scenario is the same as the first simulation data, and compare whether the second data in the same simulation scenario is the same as the second simulation data, Verify the business capability of the vehicle-road coordination system.
  • the simulation device also includes:
  • a collection module configured to collect the configuration information
  • the configuration information includes:
  • the collection module includes:
  • the first collection submodule is used to collect initial metadata of the device
  • the first verification sub-module is configured to verify the initial metadata of the device
  • the first storage submodule is configured to store the initial metadata of the device as the metadata of the device in the database when the verification is passed.
  • the device initial metadata includes at least one of the following:
  • Vehicle-end metadata includes vehicle information data and corresponding vehicle-mounted equipment data
  • Roadside metadata including roadside equipment information and local area map information
  • Simulation event metadata includes manually collected GPS points on the map, device attributes, running or driving status and simulation events.
  • the collection module also includes:
  • the second verification sub-module is used to verify the uniqueness of the vehicle information data in the vehicle-end metadata when the initial metadata of the device is the vehicle-end metadata;
  • the result determination sub-module is used to pass the verification if the vehicle information data is unique.
  • the first syndrome module includes:
  • a first setting unit configured to set the scope of action of the roadside traffic equipment in the roadside equipment information when the initial metadata of the equipment is roadside metadata
  • the second setting unit is used to set the global positioning system GPS coordinates of the roadside traffic equipment, or set the positional relationship between the roadside traffic equipment and the road on the map;
  • a first verification unit configured to verify the road-end metadata
  • the first result determination unit is configured to pass the verification if the road-end metadata meets the first preset condition
  • the roadside equipment information is related information of roadside traffic equipment
  • the roadside traffic equipment includes at least one of the following: RSU, traffic lights, laser radar, millimeter wave radar, high-definition camera and temperature and humidity sensors.
  • condition that the road-end metadata satisfies the first preset condition includes the following three items:
  • the roadside equipment information and the local area map information are accurate;
  • the first syndrome module also includes:
  • the first selection unit is configured to select the device associated with the simulation event when the initial metadata of the device is the simulation event metadata; wherein the device includes the roadside device, the vehicle-mounted device, the The simulated roadside equipment and the simulated vehicle-mounted equipment;
  • the second selection unit is used to select the type of simulation event; wherein, different types of the simulation event correspond to different simulation scenarios;
  • a setting unit configured to set parameters and mutual exclusion conditions of the simulation event; the simulation event has no conflict based on the mutual exclusion conditions;
  • a second checking unit configured to check the simulation event
  • the second result determining unit is configured to pass the verification when the simulation event satisfies a second preset condition.
  • the parameters include event level, execution time, cycle, location and value.
  • the situation that the simulation event satisfies the second preset condition includes at least the following three items:
  • the first collection submodule includes at least one of the following:
  • the first collection unit is configured to receive manually uploaded first scripted data; wherein, the first scripted data is formed by filtering and processing the third data uploaded by the roadside device and the vehicle-mounted device scripted data; the third data includes vehicle behavior data and roadside equipment data related to the vehicle;
  • the second collection unit is used to obtain the fourth data of the roadside device and the vehicle-mounted device through the vehicle-road collaboration platform on the edge cloud, and process the second scripted data formed after processing; wherein, the The fourth data includes all vehicles and roadside equipment data related to the vehicles;
  • the third collection unit is used to edit and enter the third scripted data on the visual operation interface
  • the first scripted data, the first scripted data and the first scripted data are all scripted data conforming to the operation of the simulation scenario.
  • the first collection submodule also includes:
  • the loading unit is used to load custom dynamic path metadata and display the planned path through the map interface
  • the segmentation unit is used to segment the road section on the path to form a running point
  • the fourth collection unit is configured to collect and summarize the operating points and store them to form path metadata.
  • segmenting road segments on the path includes at least one of the following:
  • Segment road segments based on angle and acceleration.
  • the scene layout sub-module includes:
  • a first setting unit configured to set a scene event on a path according to the path metadata and the scene metadata
  • the third selection unit is configured to select a simulated vehicle, and bind the path metadata with the simulated vehicle.
  • the first setting unit includes:
  • the first processing subunit is used to load custom dynamic route metadata and display the planned route through the map interface;
  • the second processing subunit is configured to set scene events on the path; wherein, the scene events are formed by free combination of basic scenes;
  • a verification subunit configured to verify the scene event
  • the result confirmation subunit is used to add the scene event to the queue to be stored if the verification is successful;
  • the storage subunit is configured to store the scene events in the queue to be stored after the entry of the scene events on the path is completed.
  • verifying the scene event includes:
  • the simulation scenarios include historical playback fixed scenarios and interactive fusion simulation scenarios.
  • the scenario execution submodule includes:
  • the initialization unit is used to initialize the scene execution engine
  • a judging unit configured to judge the type of the simulation scene according to parameter configuration or application program interface API call
  • An execution unit configured to execute the simulation scenario according to the type.
  • perform scenario execution engine initialization including at least one of the following:
  • the execution unit includes:
  • a selection subunit configured to select equipment that needs to execute the simulation scenario; the equipment includes the roadside equipment, the vehicle-mounted equipment, the simulated roadside equipment, and the simulated vehicle-mounted equipment;
  • the first loading subunit is used to load stored historical scene metadata from the database; wherein, the historical scene metadata includes equipment operation data and scene recording data;
  • a sending subunit configured to send the scene recording data to the device.
  • the execution unit further includes:
  • the second loading subunit is used to load associated scene metadata according to the current device type; wherein, the scene metadata includes device basic information and regional traffic road relationship network; the device includes the roadside device, the The vehicle-mounted equipment, the simulated roadside equipment and the simulated vehicle-mounted equipment;
  • the matching subunit is used to match scripted data for the device.
  • one simulation scene is bound to at least one simulation device, and one simulation device is only bound to one simulation scene; wherein, the simulation device includes the simulation vehicle-mounted device and the simulation roadside device.
  • the simulation device also includes:
  • the third sending module is configured to send a dynamic perception map to the vehicle-mounted device and/or the simulated vehicle-mounted device within the coverage of the edge cloud according to the simulation result.
  • This device implements a device simulation environment on the edge cloud to provide the vehicle-road collaboration platform with simulation interactions of roadside equipment and vehicle-mounted equipment that are close to the real environment. Events and conditions that are not easy to create in the real world reduce the cost and risk of running scenarios.
  • the simulation device provided by the embodiment of the present application can realize each process realized by the method embodiment in FIG. 13 and can achieve the same technical effect. To avoid repetition, details are not repeated here.
  • an embodiment of the present application provides a simulation device applied to the core cloud, including:
  • the routing module 1801 is used to provide routing information for roadside devices and vehicle-mounted devices in each area to access the edge cloud.
  • the simulation device also includes:
  • the first processing module is used to establish communication with the edge cloud in the whole region, and perform big data comprehensive analysis and prediction on traffic conditions in the whole region.
  • the device by establishing communication with the edge cloud, can provide a corresponding range of edge collaborative computing scheduling, multi-level computing capacity scheduling and other functions in the regional and global scope.
  • edge collaborative computing scheduling multi-level computing capacity scheduling and other functions in the regional and global scope.
  • the simulation device provided by the embodiment of the present application can realize each process realized by the method embodiment in FIG. 14 , and can achieve the same technical effect. To avoid repetition, details are not repeated here.
  • the embodiment of the present application provides a simulation device, which is applied to roadside equipment, including:
  • the first communication module 1901 is configured to establish communication with the edge cloud, and provide the first data for the edge cloud;
  • the first decision-making module 1902 is configured to make behavioral decisions according to the simulation results of the edge cloud
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the first data includes at least one of the following:
  • the simulation device also includes:
  • the second processing module is configured to use the built-in or configured network address of the edge cloud to select the second edge cloud corresponding to the network address closest to the location of the roadside device, and communicate with the second edge cloud establish connection;
  • the third processing module is configured to periodically acquire a list of vehicle-mounted devices within the second preset range, and a communication address corresponding to each of the vehicle-mounted devices, and establish an association relationship with traffic road network or other device metadata.
  • the simulation device also includes:
  • the execution module is used to perform the following steps cyclically within the preset period:
  • the warning event is broadcast to vehicles within a third preset range.
  • the simulation device also includes:
  • a detection module configured to periodically check the validity of the alarm event
  • the fourth processing module is configured to discard the alarm event when the alarm event has expired.
  • This device by adopting the roadside SDK that is consistent with the behavior and communication mode of the simulated roadside equipment, enables the roadside equipment to inherit the capabilities of the simulated roadside equipment, such as simulation scene capabilities, edge cloud communication capabilities, and vehicle-side broadcast capabilities etc., so as to solve the problem of long and noisy communication process due to the large number of participants in the common vehicle-road collaborative system design and development process, which can save development costs and development cycles.
  • the simulation device provided by the embodiment of the present application can realize each process realized by the method embodiment in FIG. 15 , and can achieve the same technical effect. To avoid repetition, details are not repeated here.
  • the embodiment of the present application provides a simulation device, which is applied to vehicle-mounted equipment, including:
  • the second communication module 2001 is configured to establish communication with the edge cloud, and provide the second data for the edge cloud;
  • the second decision-making module 2002 is configured to make behavioral decisions according to the simulation results of the edge cloud
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • the second data includes at least one of the following:
  • the second communication module 2001 includes:
  • a receiving submodule configured to receive the network address of the edge cloud sent by the core cloud
  • the first processing sub-module is configured to select, from the network addresses, a first edge cloud corresponding to the network address closest to the vehicle-mounted device, and establish a connection with the first edge cloud.
  • the second communication module 2001 also includes:
  • the second processing submodule is used to pull corresponding scripted data from the edge cloud according to the SDK configuration, and connect to the corresponding roadside device according to the SDK configuration, and receive the first step from the roadside device after the connection is successful. a message;
  • the third processing submodule is used to decode the scripted data, and sequentially execute the first message and the script according to the execution order and frequency of the scripts;
  • the uploading submodule is configured to upload the second data to the edge cloud according to the first message.
  • the following steps are cyclically executed:
  • each time the on-vehicle device completes the execution of a script it sends a script execution path to the edge cloud; and, every time it completes a scene event processing, it sends a scene event processing to the edge cloud result.
  • This device by adopting the vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted equipment, enables the vehicle-mounted equipment to inherit the capabilities of the simulated vehicle-mounted equipment, such as simulation scene capabilities, early warning decision-making capabilities, etc., and can ensure that the real equipment can achieve the national standard definition. 17 typical application scenarios of vehicle-road coordination, avoiding the influence of overly complicated network environment and hardware requirements, and better solving the cost problems in all aspects of the life cycle of the vehicle-road simulation system.
  • the simulation device provided by the embodiment of the present application can realize each process realized by the method embodiment in FIG. 16 , and can achieve the same technical effect. To avoid repetition, details are not repeated here.
  • an embodiment of the present application provides a communication device, which is an edge cloud 2100 and includes a processor 2110; wherein, the processor 2110 is used to collect the first data of the roadside device and the on-board The second data of the device, and according to the configuration information, the first data and the second data, perform a simulation of the vehicle-infrastructure collaborative environment to obtain a simulation result.
  • a transceiver 2120 is also included, and the transceiver 2120 is configured to: send the first data, the second data, and the road condition data calculated through the edge cloud to the core cloud.
  • the first data includes at least one of the following:
  • the second data includes at least one of the following:
  • the processor 2110 is specifically configured to:
  • the first simulation data of the simulated roadside equipment wherein, the first simulated data comprises simulated traffic data, simulated MAP, simulated SPAT, simulated roadside traffic time message, simulated RSI and simulated RSM;
  • the second simulation data includes simulation vehicle BSM and simulation vehicle sensor data;
  • the third simulation data of the vehicle, the third simulation data includes road event and/or warning information.
  • the transceiver 2120 is further configured to: send the first data, the second data, and the road condition data calculated through the edge cloud to the core cloud.
  • the processor 2110 is further configured to: verify the service capability of the vehicle-road coordination system according to the simulation result.
  • the processor 2110 is verifying the service capability of the vehicle-road coordination system according to the simulation result, specifically for:
  • the processor 2110 is further configured to: collect the configuration information
  • the configuration information includes:
  • processor 2110 when used for cloud collection of the device metadata, it is specifically used for:
  • the device initial metadata is stored in the database as the device metadata.
  • the device initial metadata includes at least one of the following:
  • Vehicle-end metadata includes vehicle information data and corresponding vehicle-mounted equipment data
  • Roadside metadata including roadside equipment information and local area map information
  • Simulation event metadata includes manually collected GPS points on the map, device attributes, running or driving status and simulation events.
  • the package is specifically used to:
  • the initial metadata of the device is the vehicle-side metadata
  • uniqueness verification is performed on the vehicle information data in the vehicle-side metadata
  • processor 2110 when used to verify the initial metadata of the device, it is specifically used to:
  • the initial metadata of the equipment is roadside metadata, setting the scope of action of the roadside traffic equipment in the roadside equipment information;
  • the roadside equipment information is related information of roadside traffic equipment
  • the roadside traffic equipment includes at least one of the following: RSU, traffic lights, laser radar, millimeter wave radar, high-definition camera and temperature and humidity sensors.
  • condition that the road-end metadata satisfies the first preset condition includes the following three items:
  • the roadside equipment information and the local area map information are accurate;
  • processor 2110 when used to verify the initial metadata of the device, it is specifically used to:
  • the initial metadata of the device is metadata of a simulated event
  • select the device associated with the simulated event wherein, the device includes the roadside device, the vehicle-mounted device, the simulated roadside device, and the Describe the simulated vehicle equipment;
  • the simulation event has no conflict based on the mutual exclusion conditions
  • the parameters include event level, execution time, cycle, location and value.
  • the situation that the simulation event satisfies the second preset condition includes at least the following three items:
  • processor 2110 when used to collect the scene metadata, it includes at least one of the following:
  • the first scripted data is scripted data formed after screening and processing the third data uploaded by the roadside device and the vehicle-mounted device;
  • the third data includes vehicle behavior data and roadside equipment data related to said vehicle;
  • the fourth data includes all Vehicles and roadside equipment data associated with said vehicles;
  • the first scripted data, the first scripted data and the first scripted data are all scripted data conforming to the operation of the simulation scenario.
  • processor 2110 when used to collect the path metadata, it includes:
  • processor 2110 when used to segment the road segment on the route, it includes at least one of the following:
  • Segment road segments based on angle and acceleration.
  • processor 2110 when used for scene editing, it includes:
  • the processor 2110 when used to set a scene event on a route according to the route metadata and the scene metadata, it includes:
  • the scene events in the queue to be stored are stored.
  • processor 2110 when used to verify the scene event, it includes:
  • the simulation scenarios include historical playback fixed scenarios and interactive fusion simulation scenarios.
  • processor 2110 when used to execute the simulation scenario, it includes:
  • the simulation scenario is executed.
  • processor 2110 when used to initialize the scenario execution engine, it includes at least one of the following:
  • processor 2110 when configured to execute the simulation scenario when the type is a history playback fixed scenario, it includes:
  • the equipment includes the roadside equipment, the vehicle equipment, the simulated roadside equipment and the simulated vehicle equipment;
  • the historical scene metadata includes equipment operation data and scene recording data
  • the processor 2110 is configured to execute the simulation scenario when the type is an interactive fusion simulation scenario, including:
  • the scene metadata includes device basic information and regional traffic road relationship network;
  • the device includes the roadside device, the vehicle-mounted device, the simulated road side equipment and the simulated on-vehicle equipment;
  • one simulation scene is bound to at least one simulation device, and one simulation device is only bound to one simulation scene; wherein, the simulation device includes the simulation vehicle-mounted device and the simulation roadside device.
  • the processor 2110 is further configured to: according to a simulation result, send a dynamic perception map to the vehicle-mounted device within the coverage of the edge cloud and/or the simulated vehicle-mounted device.
  • the communication device implements a device simulation environment on the edge cloud to provide the simulation interaction of roadside equipment and vehicle-mounted equipment close to the real environment for the vehicle-road collaboration platform, supports the collaborative data processing of simulation and real equipment, and can realize Provides events and conditions that are not easy to create in the real world, reducing the cost and risk of running scenarios.
  • An embodiment of the present application provides a communication device, which is a core cloud and includes a processor; wherein the processor is used to provide routing information for roadside devices and vehicle-mounted devices in each area to access the edge cloud.
  • the processor is also used for:
  • the structure of the core cloud in this embodiment is similar to the structure of the edge cloud shown in FIG. 21 .
  • the communication device establishes communication with the edge cloud, and can provide a corresponding range of edge collaborative computing scheduling, multi-level computing capacity scheduling and other functions in the regional and global scope.
  • an embodiment of the present application provides a communication device
  • the communication device is a vehicle-mounted device 2200, including: a transceiver 2210 and a processor 2220;
  • the transceiver 2210 is used to establish communication with the edge cloud, and provide the second data for the edge cloud;
  • the processor 2220 is configured to make behavioral decisions according to the simulation results of the edge cloud
  • the vehicle-mounted device adopts a vehicle-mounted SDK that is consistent with the behavior and communication mode of the simulated vehicle-mounted device on the edge cloud.
  • the second data includes at least one of the following:
  • processor 2220 when used to establish communication with the edge cloud, it includes:
  • processor 2220 when used to provide the second data for the edge cloud, it includes:
  • the SDK configuration pull the corresponding scripted data from the edge cloud, and according to the SDK configuration, connect to the corresponding roadside device, and receive the first message from the roadside device after the connection is successful;
  • processor 2220 when used to execute the script, execute the following steps in a loop:
  • each time the on-vehicle device completes the execution of a script it sends a script execution path to the edge cloud; and, every time it completes a scene event processing, it sends a scene event processing to the edge cloud result.
  • the communication device adopts the vehicle-mounted SDK that is consistent with the behavior and communication method of the simulated vehicle-mounted device, so that the vehicle-mounted device can inherit the capabilities of the simulated vehicle-mounted device, such as simulation scene capabilities, early warning decision-making capabilities, etc., to ensure that the real device can achieve the definition of the national standard
  • the 17 typical application scenarios of vehicle-road coordination avoid the influence of overly complicated network environment and hardware requirements, and better solve the cost problems in all aspects of the life cycle of the vehicle-road simulation system.
  • An embodiment of the present application provides a communication device, the communication device is a roadside device, including a processor and a transceiver;
  • the transceiver is used to establish communication with the edge cloud, and provide the first data for the edge cloud;
  • the processor is used to make behavioral decisions according to the simulation results of the edge cloud
  • the roadside device adopts a roadside SDK consistent with the behavior and communication mode of the emulated roadside device on the edge cloud.
  • the first data includes at least one of the following:
  • the processor is also used for:
  • the list of vehicle-mounted devices within the second preset range and the communication address corresponding to each vehicle-mounted device are periodically obtained, and an association relationship is established with traffic road network or other device metadata.
  • the processor is also used for:
  • the warning event is broadcast to vehicles within a third preset range.
  • the processor is also used for:
  • the alarm event is discarded.
  • the communication device by adopting the roadside SDK that is consistent with the behavior and communication mode of the simulated roadside device, enables the roadside device to inherit the capabilities of the simulated roadside device, such as simulation scene capabilities, edge cloud communication capabilities, and car-end broadcasting capabilities, etc., thus solving the problem of long and noisy communication due to the large number of participants in the common design and development process of vehicle-road coordination systems, which can save development costs and development cycles.
  • the structure of the roadside device in this embodiment is similar to that of the vehicle-mounted device shown in FIG. 22 .
  • the embodiments of the present application provide a readable storage medium, on which are stored programs or instructions, and when the programs or instructions are executed by the processor, the above steps in the simulation method applied to the edge cloud are realized, Or implement the above steps in the simulation method applied to the core cloud, or implement the steps in the above simulation method applied to roadside equipment, or implement the above steps in the simulation method applied to vehicle equipment.
  • the edge cloud includes a transceiver 2310, a processor 2300, a memory 2320, and programs or instructions stored in the memory 2320 and operable on the processor 2300; When the processor 2300 executes the program or instruction, the above-mentioned simulation method applied to the edge cloud is realized.
  • the transceiver 2310 is used for receiving and sending data under the control of the processor 2300 .
  • the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by the processor 2300 and various circuits of the memory represented by the memory 2320 are linked together.
  • the bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, etc., which are well known in the art and therefore will not be further described herein.
  • the bus interface provides the interface.
  • Transceiver 2310 may be a plurality of elements, including a transmitter and a receiver, providing a means for communicating with various other devices over transmission media.
  • the processor 2300 is responsible for managing the bus architecture and general processing, and the memory 2320 can store data used by the processor 2300 when performing operations.
  • the structure of the core cloud in another embodiment of the present application is similar to that of the edge cloud shown in FIG.
  • the transceiver 2310 is used for receiving and sending data under the control of the processor 2300 .
  • the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by the processor 2300 and various circuits of the memory represented by the memory 2320 are linked together.
  • the bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, etc., which are well known in the art and therefore will not be further described herein.
  • the bus interface provides the interface.
  • Transceiver 2310 may be a plurality of elements, including a transmitter and a receiver, providing a means for communicating with various other devices over transmission media.
  • the processor 2300 is responsible for managing the bus architecture and general processing, and the memory 2320 can store data used by the processor 2300 when performing operations.
  • a vehicle-mounted device includes a transceiver 2410, a processor 2400, a memory 2420, and a program or Instructions; when the processor 2400 executes the programs or instructions, the above-mentioned simulation method applied to vehicle-mounted equipment is implemented.
  • the transceiver 2410 is used for receiving and sending data under the control of the processor 2400 .
  • the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by the processor 2400 and various circuits of the memory represented by the memory 2420 are linked together.
  • the bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, etc., which are well known in the art and therefore will not be further described herein.
  • the bus interface provides the interface.
  • Transceiver 2410 may be a plurality of elements, including a transmitter and a receiver, providing a means for communicating with various other devices over transmission media.
  • the user interface 2430 may also be an interface capable of connecting externally and internally to required equipment, and the connected equipment includes but not limited to a keypad, a display, a speaker, a microphone, a joystick, and the like.
  • the processor 2400 is responsible for managing the bus architecture and general processing, and the memory 2420 can store data used by the processor 2400 when performing operations.
  • a roadside device has a structure similar to that of the vehicle-mounted device shown in FIG.
  • the transceiver 2410 is used for receiving and sending data under the control of the processor 2400 .
  • the bus architecture may include any number of interconnected buses and bridges, specifically one or more processors represented by the processor 2400 and various circuits of the memory represented by the memory 2420 are linked together.
  • the bus architecture can also link together various other circuits such as peripherals, voltage regulators, and power management circuits, etc., which are well known in the art and therefore will not be further described herein.
  • the bus interface provides the interface.
  • Transceiver 2410 may be a plurality of elements, including a transmitter and a receiver, providing a means for communicating with various other devices over transmission media.
  • the user interface 2430 may also be an interface capable of connecting externally and internally to required equipment, and the connected equipment includes but not limited to a keypad, a display, a speaker, a microphone, a joystick, and the like.
  • the processor 2400 is responsible for managing the bus architecture and general processing, and the memory 2420 can store data used by the processor 2400 when performing operations.
  • a readable storage medium on which programs or instructions are stored, and when the programs or instructions are executed by a processor, the steps in the above-mentioned simulation method can be realized, and the same technical effect can be achieved, To avoid repetition, details are not repeated here.
  • the computer-readable storage medium is, for example, a read-only memory (Read-Only Memory, ROM for short), a random access memory (Random Access Memory, RAM for short), a magnetic disk or an optical disk, and the like.
  • terminals described in this manual include but are not limited to smartphones, tablet computers, etc., and many of the described functional components are called modules, in order to more particularly emphasize the independence of their implementation.
  • the modules may be implemented by software so as to be executed by various types of processors.
  • An identified module of executable code may, by way of example, comprise one or more physical or logical blocks of computer instructions which may, for example, be structured as an object, procedure, or function. Notwithstanding, the executable code of an identified module need not be physically located together, but may include distinct instructions stored in different bits which, when logically combined, constitute the module and implement the specified Purpose.
  • a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs and across multiple memory devices.
  • operational data may be identified within modules, and may be implemented in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed in different locations (including on different storage devices), and may exist, at least in part, only as electronic signals on a system or network.
  • the hardware circuit includes conventional very large scale integration (VLSI) circuits or gate arrays as well as existing semiconductors such as logic chips, transistors, or other discrete components.
  • VLSI very large scale integration
  • a module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Analytical Chemistry (AREA)
  • Chemical & Material Sciences (AREA)
  • General Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Remote Sensing (AREA)
  • Data Mining & Analysis (AREA)
  • Traffic Control Systems (AREA)

Abstract

本申请实施例提供一种车路协同系统、模拟仿真方法、车载设备和路侧设备，涉及计算机技术领域。车路协同系统包括：边缘云，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、第一数据和第二数据，进行车路协同环境的模拟仿真，得到仿真结果；路侧设备，用于与边缘云建立通信，为边缘云提供第一数据，并根据仿真结果作出行为决策；车载设备，用于与边缘云建立通信，为边缘云提供第二数据，并根据仿真结果作出行为决策；路侧设备采用与仿真路侧设备的行为和通信方式一致的路侧SDK，车载设备采用与仿真车载设备的行为和通信方式一致的车载SDK。上述方案能够解决传统车路协同系统沟通过程冗长且充满噪音，开发及验证成本较大的问题。

Description

一种车路协同系统、模拟仿真方法、车载设备和路侧设备
相关申请的交叉引用
本申请基于申请号为202110517707.X、申请日为2021年05月12日的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此以全文引入的方式引入本申请。
技术领域
本申请实施例涉及计算机技术领域，特别是指一种车路协同系统、模拟仿真方法、车载设备和路侧设备。
背景技术
车路协同作为车联网V2X(Vehicle to Everything，车辆到万物)业务的基础能力，旨在避免交通事故、提升道路安全、缓解拥堵、降低能耗以及降低环境污染，并满足车辆辅助驾驶、自动驾驶等业务的必要输入。
RSU(Road Side Unit，路侧单元)与OBU(On-Board Unit，车载单元)作为车联网车路协同的重要设备环节，通过无线或有线通信管道，可以为车路协同平台云端提供必要的信息输入、接收云端或其他设备端的信息。
目前，我国正大力发展智慧交通、智能驾驶等产业技术创新园区，积极推进5G(the 5th Generation mobile communication technology，第五代移动通信技术)、MEC(Mobile Edge Computing，移动边缘计算)边缘云的建设和应用。但是，目前的车载终端和路侧设备的制造商众多，通信协议换人设备行为尚未达到完全统一，而由于车路协同系统中的主要场景都会涉及多种外部终端设备和多种通讯协议以及设备之间的相互通讯，导致在系统的调试、优化、开发方面具备的不可见风险、不可调节因素众多。
传统车路协同设备仿真方案中，单一化考虑路侧或车载设备的业务逻辑，设备通信协议以及设备行为逻辑未标准化而复杂多变，集中式服务端设计未考虑真实场景下多级云和多类型设备相互协作，导致现有的车路协 同系统中，沟通过程冗长且充满噪音，开发及验证的成本较大。
发明内容
本申请的目的是提供一种车路协同系统、模拟仿真方法、车载设备和路侧设备，解决了现有技术中车路协同系统的沟通过程冗长且充满噪音，开发及验证的成本较大的问题。
为达到上述目的，本申请的实施例提供一种车路协同系统，包括：
边缘云，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果；
所述路侧设备，用于与所述边缘云建立通信，为所述边缘云提供所述第一数据，并根据所述仿真结果作出行为决策；
所述车载设备，用于与所述边缘云建立通信，为所述边缘云提供所述第二数据，并根据所述仿真结果作出行为决策；
其中，在所述边缘云上模拟仿真出的车路协同环境中，包括仿真路侧设备和仿真车载设备；所述路侧设备采用与所述仿真路侧设备的行为和通信方式一致的路侧SDK(Software Development Kit，软件开发工具包)，所述车载设备采用与所述仿真车载设备的行为和通信方式一致的车载SDK。
可选地，所述车路协同系统还包括：
核心云，用于为各区域范围内的所述路侧设备和所述车载设备接入所述边缘云提供路由信息，以及与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测。
可选地，所述边缘云还用于：
将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至所述核心云。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
MAP(MAP，地图消息)；
SPAT(Signal phase timing message，交通灯相位与时序消息)；
路侧交通时间消息；
RSI(Road Side Information，路侧信息)；
RSM(Road Safety Message，路侧安全消息)。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的BSM(Basic Safety Message，基础安全消息)；
车辆传感器数据。
可选地，所述边缘云根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，包括：
根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
执行所述仿真场景，得到以下至少一项：
所述仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
所述仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
可选地，所述边缘云还用于：
根据所述仿真结果，验证所述车路协同系统的业务能力。
可选地，所述根据所述仿真结果，验证所述车路协同系统的业务能力，包括：
通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
可选地，所述边缘云还用于收集所述配置信息；
其中，所述配置信息包括：
设备元数据；
场景元数据；
路径元数据。
可选地，所述边缘云收集所述设备元数据，包括：
收集设备初始元数据；
对所述设备初始元数据进行校验；
在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库。
可选地，所述设备初始元数据包括以下至少一项：
车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS(Global Positioning System，全球定位系统)点位、设备属性、运行或行驶状态和仿真事件。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为车端元数据的情况下，对所述车端元数据中的所述车辆信息数据进行唯一性验证；
若所述车辆信息数据是唯一的，则验证通过。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为路端元数据的情况下，对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
对所述路端元数据进行校验；
若所述路端元数据满足第一预设条件，则校验通过；
其中，所述路侧设备信息为路侧交通设备的相关信息；
所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器。
可选地，所述路端元数据满足第一预设条件的情况，包括以下三项：
所述路侧设备信息和所述局部区域地图信息准确；
所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件无冲突；
对所述仿真事件进行校验；
在所述仿真事件满足第二预设条件的情况下，校验通过。
可选地，所述参数包括事件级别、执行时间、周期、地点和数值。
可选地，所述仿真事件满足第二预设条件的情况，至少包括以下三项：
所述仿真事件准确；
所述仿真事件与所述设备、地图的关联关系无逻辑错误；
所述仿真事件与所述数据库中的设备元数据之间无冲突。
可选地，所述边缘云收集所述场景元数据，包括以下至少一项：
接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧设备数据；
通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据；
通过在可视化操作界面上编辑并录入的第三脚本化数据；
其中，所述第一脚本化数据、所述第二脚本化数据和所述第三脚本化数据均为符合所述仿真场景运行的脚本化数据。
可选地，所述边缘云收集所述路径元数据，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上对路段进行切分，形成运行点；
收集汇总所述运行点并存储，形成路径元数据。
可选地，所述边缘云在路径上对路段进行切分，包括以下至少一项：
根据距离对路段进行均分；
根据加速度对路段进行切分；
根据角度对路段进行切分；
根据角度和加速度对路段进行切分。
可选地，所述边缘云进行场景编排，包括：
根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
可选地，所述边缘云根据所述路径元数据与所述场景元数据，在路径上设置场景事件，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
对所述场景事件进行校验；
若校验成功，则将所述场景事件加入待存储队列；
在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的所述场景事件。
可选地，所述边缘云对所述场景事件进行校验，包括：
判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；
若不存在行为互斥，则校验通过；否则，校验失败。
可选地，所述仿真场景包括历史回放固定场景和互动融合模拟场景。
可选地，所述边缘云执行所述仿真场景，包括：
进行场景执行引擎初始化；
根据参数配置或API(Application Programming Interface，应用程序接 口)调用，判断所述仿真场景的类型；
根据所述类型，执行所述仿真场景。
可选地，所述边缘云进行场景执行引擎初始化，包括以下至少一项：
初始化运行所需的程序空间；
加载运行参数；
连接本地数据库、缓存或消息队列；
加载设备元数据；
初始化网络通讯链接。
可选地，在所述类型为历史回放固定场景的情况下，所述边缘云执行所述仿真场景，包括：
选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
从数据库中加载已存储的历史场景元数据；其中，所述历史场景元数据包括设备运行数据和场景录制数据；
将所述场景录制数据发送给所述设备。
可选地，在所述类型为互动融合模拟场景的情况下，所述边缘云所述执行所述仿真场景，包括：
根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
为所述设备匹配脚本化数据。
可选地，一个仿真场景与至少一个仿真设备绑定，一个仿真设备只与一个仿真场景绑定；其中，所述仿真设备包括所述仿真车载设备和所述仿真路侧设备。
可选地，所述边缘云还用于：
根据仿真结果，向所述边缘云覆盖范围内所述车载设备和/或所述仿真车载设备发送动态感知地图。
可选地，所述车载设备与所述边缘云建立通信，包括：
接收所述核心云发送的所述边缘云的网络地址；
从所述网络地址中，选择与所述车载设备所在位置最近的网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
可选地，所述车载设备为所述边缘云提供所述第二数据，包括：
根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
根据所述第一报文，向所述边缘云上传所述第二数据。
可选地，所述车载设备执行所述脚本，循环执行以下步骤：
接收其他车载设备或路侧设备播发的场景事件；
对所述场景事件进行处理；
向所述边缘云发送车辆的行驶数据和所述场景事件的处理结果。
可选地，所述车载设备每完成一条脚本的执行时，向所述边缘云发送一次执行脚本的路径；以及，每完成一次一次场景事件处理时，向所述边缘云发送一次场景事件的处理结果。
可选地，所述路侧设备还用于：
通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；
周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
可选地，所述路侧设备还用于在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
可选地，所述路侧设备还用于：
周期性地检查所述告警事件的有效性；
在所述告警事件已过期的情况下，丢弃所述告警事件。
为达到上述目的，本申请的实施例提供一种模拟仿真方法，应用于边缘云，包括：
收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
可选地，所述根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果，包括：
根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
执行所述仿真场景，得到以下至少一项：
仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
可选地，模拟仿真方法还包括：
将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
为达到上述目的，本申请的实施例提供一种模拟仿真方法，应用于核心云，包括：
为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
可选地，所述模拟仿真方法还包括：
与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测。
为达到上述目的，本申请的实施例提供一种模拟仿真方法，应用于路侧设备，包括：
与边缘云建立通信，为所述边缘云提供第一数据；
根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
可选地，所述模拟仿真方法还包括：
通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；
周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
可选地，所述模拟仿真方法还包括：
在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
为达到上述目的，本申请的实施例提供一种模拟仿真方法，应用于车载设备，包括：
与边缘云建立通信，为所述边缘云提供第二数据，并根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
可选地，所述与边缘云建立通信，包括：
接收核心云发送的所述边缘云的网络地址；
从所述网络地址中，选择与所述车载设备所在位置最近的所述网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
可选地，所述为所述边缘云提供第二数据，包括：
根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
根据所述第一报文，向所述边缘云上传所述第二数据。
为达到上述目的，本申请的实施例提供一种边缘云，包括处理器；其中，所述处理器用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
为达到上述目的，本申请的实施例提供一种核心云，包括：处理器；其中，所述处理器用于为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
为达到上述目的，本申请的实施例提供一种车载设备，包括：收发机和处理器；其中，所述收发机用于与边缘云建立通信，为所述边缘云提供第二数据；
所述处理器用于根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
为达到上述目的，本申请的实施例提供一种路侧设备，包括处理器和收发器，其中，包括：收发机和处理器；
所述收发机用于与边缘云建立通信，为所述边缘云提供第一数据；
所述处理器用于根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
为达到上述目的，本申请的实施例提供一种模拟仿真装置，应用于边缘云，包括：
仿真模块，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
为达到上述目的，本申请的实施例提供一种模拟仿真装置，应用于核心云，包括：
路由模块，用于为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
为达到上述目的，本申请的实施例提供一种模拟仿真装置，应用于路侧设备，包括：
第一通信模块，用于与边缘云建立通信，为所述边缘云提供第一数据；
第一决策模块，用于根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
为达到上述目的，本申请的实施例提供一种模拟仿真装置，应用于车载设备，包括：
第二通信模块，用于与边缘云建立通信，为所述边缘云提供第二数据；
第二决策模块，用于根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
为达到上述目的，本申请的实施例提供一种通信设备，包括收发器、处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令；所述处理器执行所程序或指令时实现如上应用于边缘云的模拟仿真方法，或者实现如上应用于核心云的模拟仿真方法，或者实现如上应用于路侧设备的模拟仿真方法，或者实现如上应用于车载设备的模拟仿真方法。
为达到上述目的，本申请的实施例提供一种可读存储介质，其上存储有程序或指令，所述程序或指令被处理器执行时实现如上应用于边缘云的模拟仿真方法中的步骤，或者实现如上应用于核心云的模拟仿真方法中的步骤，或者实现如上应用于路侧设备的模拟仿真方法中的步骤，或者实现如上应用于车载设备的模拟仿真方法中的步骤。
本申请的上述技术方案的有益效果如下：
本申请实施例的车路协同系统，在MEC边缘云上实现了云端设备仿真环境，以对车路协同平台提供接近真实环境的路侧设备、车载设备的仿真交互。通过在真实的路侧设备、车载设备端上提供与仿真设备行为、通信方式一致的SDK，保证了真实设备能够实现国标定义的17种车路协同典型和基础应用场景，使得真实设备能够快速接入具有车路协同车联网能力的多边缘云、区域云、集中式核心云融合基础设施，能够快速应用5G NR(New  Radio，新空口)-V2X、人工智能等信息基础设施，能够快速部署在产业技术创新基地、自动驾驶试验场这样的创新基础设施中，同时为真实设备提供了与仿真设备一致的开发、测试、运维低成本方案。
附图说明
图1为本申请实施例的车路协同系统的数据流示意图；
图2为本申请实施例的车路协同系统的总体架构示意图；
图3为本申请实施例的边缘云收集车端元数据的流程示意图；
图4为本申请实施例的边缘云收集路端元数据的流程示意图；
图5为本申请实施例的边缘云收集仿真事件元数据的流程示意图；
图6为本申请实施例的边缘云收集场景元数据的流程示意图；
图7为本申请实施例的边缘云收集路径元数据的流程示意图；
图8为本申请实施例的设置场景事件的流程示意图；
图9为本申请实施例的场景设备绑定流程示意图；
图10为本申请实施例的场景执行流程示意图；
图11为本申请实施例的车载SDK工作流程示意图；
图12为本申请实施例的路侧SDK工作流程示意图；
图13为本申请实施例的模拟仿真方法的流程图；
图14为本申请另一实施例的模拟仿真方法的流程图；
图15为本申请又一实施例的模拟仿真方法的流程图；
图16为本申请再一实施例的模拟仿真方法的流程图；
图17为本申请实施例的模拟仿真装置的结构图；
图18为本申请另一实施例的模拟仿真装置的结构图；
图19为本申请又一实施例的模拟仿真装置的结构图；
图20为本申请再一实施例的模拟仿真装置的结构图；
图21为本申请一实施例的边缘云的结构图；
图22为本申请一实施例的车载设备的结构图；
图23为本申请另一实施例的边缘云的结构图；
图24为本申请另一实施例的车载设备的结构图。
具体实施方式
为使本申请要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。
应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。
在本申请的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
另外，本文中术语“系统”和“网络”在本文中常可互换使用。
在本申请所提供的实施例中，应理解，“与A相应的B”表示B与A相关联，根据A可以确定B。但还应理解，根据A确定B并不意味着仅仅根据A确定B，还可以根据A和/或其它信息确定B。
如图1至图2所示，本申请实施例的一种车路协同系统，包括：
边缘云，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。可选地，所述边缘云还用于：根据所述仿真结果，验证所述车路协同系统的业务能力。
作为本申请一可选实施例，边缘云(即MEC边缘云平台)上包括有车路协同平台和云端仿真环境，可分别用于收集数据和进行模拟仿真等，具体的，车路协同平台和云端仿真环境的具体情况可详述如下：
(一)车路协同平台，即边缘云节点中的车路协同平台，其可涉及交通信息融合感知、实时计算与分析、数据存储与开放、资源调度和协同计算等多种功能。车路协同边缘节点支撑边缘范围低时延、高带宽、海量设备连接的业务，能够处理或产生5大类基础信息(包括BSM、SPAT、MAP、RSI和RSM)。
如图2所示，本申请实施例中，车路协同平台的相关作用可包括：
通过路侧通信模块收集边缘云范围内真实的路侧设备单元(即路侧设备)采集的路侧交通设备数据、上报的局部地图MAP信息，以及路口信号灯的SPAT状态等信息，用以后续的边缘云计算；
通过路侧通信模块收集边缘云范围内仿真的路侧设备单元的仿真交通数据，以及仿真MAP、SPAT等信息，用以边缘云中车路协同业务能力的验证；
通过路侧通信模块向边缘云范围内仿真的(或真实的)路侧设备单元发送经过计算得出的路侧交通时间消息、交通标志牌信息(RSI)以及路侧安全消息(RSM)；
通过车端通信模块收集边缘云范围内真实的车载设备单元采集的包括车辆地理位置、行驶状态的BSM信息，以及各种传感器收集的数据，用以后续边缘云计算；
通过车端通信模块收集边缘云范围内仿真的车载设备单元产生的车辆BSM数据，以及各种仿真车辆传感器数据，用以边缘云中车路协同业务能力的验证；
通过车端通信模块向边缘云范围内仿真的(或真实的)车载设备单元发送经过计算出的动态感知地图，可用于高级辅助驾驶和自动驾驶的信息。
可选地，所述第一数据包括以下至少一项：路侧交通设备数据；地图消息MAP；交通灯相位与时序消息SPAT；路侧交通时间消息；路侧信息RSI；路侧安全消息RSM。所述第二数据包括以下至少一项：车辆地理位置信息；车辆行驶状态的基础安全消息BSM；车辆传感器数据。
需要说明的是，边缘云所收集的路侧设备的第一数据以及车载设备的第二数据，包括但不限于上述实施例中所列举的数据类型。
(二)云端仿真环境(即云端设备仿真环境)，可以包括设备数据收集、仿真场景编排、仿真路侧设备和仿真车载设备。云端仿真环境通过模拟整个车路协同环境下的网络链路、消息数据传递和收集存储，对来自与仿真输入(或真实设备)的数据进行分析计算，产生对人、车或路的感知事件，并仿真出设备的决策行为，模拟实现真实的车辆在对应的场景中的驾驶行 为和应急决策，以及路侧交通设备在对应场景的预警、调度和应急决策。
云端仿真环境可以进行云端场景仿真，这里指边缘云节点中的路侧设备、车载设备的仿真。边缘云中的设备仿真数据能够为车路协同平台提供快速设备验证，并为区域云、全局核心云中提供相应范围的交通仿真数据。
其中，仿真路侧设备可以仿真路侧单元(即RSU)的行为，实现与车路协同平台和车载设备单元之间通信的管理、设备注册登录、数据的收发、协议转换，RSI、RSM、SPAT、MAP的消息生命周期管理，通信消息的编解码、转发、存储，以及参数配置、安全管理等功能。仿真路侧设备(即仿真的路侧设备)可以与其他真实或仿真的路侧设备、车载设备共同进行场景验证。
仿真车载设备可以仿真车载通信单元(即OBU)的行为，实现车辆在特定场景下的决策行为、展示预警、提示消息、与车路协同平台和路侧单元之间通信的管理、设备注册登录、数据的收发、协议转换，BSM、RSI、RSM、SPAT、MAP的消息生命周期管理，通信消息的编解码、转发、存储，以及参数配置、安全管理等功能。仿真车载设备(即仿真的车载设备)可以与其他真实或仿真的路侧设备、车载设备共同进行场景验证。
这样，通过云端仿真环境进行车路协同环境的模拟仿真，能够解决常规车路协同平台在开发过程中就需要介入大量真实设备的对接，并需花费大量调试时间成本的问题，保证了仿真环境具有高可用、易扩展、广应用、弹性扩容和低成本等这些其他仿真模拟器不具备的优势，实现了模拟设备和真实设备之间的可插拔、切换的功能，让测试和开发人员能够在整体的开发、验证过程中更加便利地验证相应的平台功能，以及获取对应所需的数据。
车路协同系统还包括：
所述路侧设备，用于与所述边缘云建立通信，为所述边缘云提供所述第一数据，并根据所述仿真结果作出行为决策；
所述车载设备，用于与所述边缘云建立通信，为所述边缘云提供所述第二数据，并根据所述仿真结果作出行为决策；
其中，在所述边缘云上模拟仿真出的车路协同环境中，包括仿真路侧 设备和仿真车载设备；所述路侧设备采用与所述仿真路侧设备的行为和通信方式一致的路侧软件开发工具包SDK，所述车载设备采用与所述仿真车载设备的行为和通信方式一致的车载SDK。
这样，通过将路侧SDK提供给路侧设备，可以使得路侧设备(这里指真实的路侧设备)能够继承实现仿真路侧设备的能力；通过将车载SDK提供给车载设备(这里指真实的车载设备)能够继承实现仿真车载设备的能力；车载设备、路侧设备可通过SDK快速接入边缘云车路协同平台，进行车路协同场景验证。
具体的，在本申请其中一可选实施例中，路侧SDK与车载SDK的作用详述如下：
路侧SDK(即路侧SDK)，可以用于提供给真实路侧设备，继承实现仿真路侧单元(即仿真路侧设备)的能力。例如，真实路侧设备集成此路侧SDK后，即可实现大部分的车路协同业务功能，包括：仿真场景能力，即可以继承复用路侧仿真中已实现的车路协同相关业务场景；边缘云通信能力，即可以继承复用路侧仿真中已实现的通信能力，并根据边缘云中管理的路侧单元(即路侧设备)的范围，选择对应的边缘云节点进行通信；车端广播能力，即可以继承复用路侧仿真中已实现的通信能力，将RSI、RSM、SPAT、MAP等消息无线广播给连接到边缘云的车辆；消息生命周期管理能力，即可以继承复用路侧仿真中已实现的通信消息的编解码、转发、存储、状态维护等能力；参数配置能力，即可以继承复用路侧仿真中已实现的设备参数配置能力。
车载SDK，可以用于提供给真实车载智能设备(即车载设备)，继承实现仿真车载单元(即仿真车载设备)的能力。例如，真实车载设备单元(即真实的车载设备)集成此SDK后即可实现大部分车路协同业务功能，包括：仿真场景能力，即可以继承复用车端仿真中已实现的车路协同相关业务场景编辑、生成和运行的能力；预警决策能力，即可以继承复用车端仿真中V2V、V2I事件的预警和决策能力，需要说明的是，仿真环境中经过机器学习训练改进算法模型将持续改进车载设备的决策能力；边缘云通信能力，即可以继承复用路侧仿真中已实现的通信能力，并根据边缘云中管理的车 辆范围，选择对应的边缘云节点进行通信，需要说明的是，车辆可搭载5G通信模块，降低通信时延、利用增强带宽丰富传输数据的类型和数量，边缘云中的V2X平台(即车路协同平台)也可以接入海量的车辆或设备；路侧设备通信能力，即可以继承复用车端仿真中已实现的通信能力，接收路侧设备广播的RSI、RSM、SPAT、MAP等消息；消息生命周期管理能力，即可以继承复用车端仿真中已实现的通信消息的编解码、转发、存储、状态维护等能力；参数配置能力，即可以继承车端仿真中已实现的设备参数配置能力。
本申请实施例中，在真实的路侧设备、车载设备上提供与仿真设备行为、通信方式一致的SDK，能够避免车路协同系统中沟通过程冗长的问题，从而节省开发及验证成本；能够保证真实设备能够实现国标定义的17种车路协同典型应用场景，使得真实设备能够快速接入具有车路协同车联网能力的多边缘云、区域云、集中式核心云融合基础设施，快速应用5G NR-V2X、人工智能等信息基础设施，快速部署在产业技术创新基地、自动驾驶试验场这样的创新基础设施中，避免过于复杂的网络环境影响和硬件需求，更好的解决了车路仿真模拟系统生命周期中各方面的成本问题。此外，可以为真实设备提供与仿真设备一致的开发、测试低成本方案，为车路协同、智慧交通等车联网的实现搭上我国新型基础设施建设的快车提供关键环节上的设计方案。解决了常见的车路协同系统设计开发过程中，由于参与方众多，沟通过程冗长且充满噪音的问题；能够按照需要准确、稳定且快速地获取相关多边数据，极大地节约了开发成本和开发周期。
可选地，所述车路协同系统还包括：核心云，用于为各区域范围内的所述路侧设备和所述车载设备接入所述边缘云提供路由信息，以及与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测，以指导交通基础设施规划。
需要说明的是，本申请实施例中，核心云(即区域/核心云平台)，可以在区域、全局范围里提供相应范围的边缘协同计算调度、多级计算能力调度等功能。通过仿真(或真实)设备接入边缘云所产生的交通事件，进行融合计算，能够实现对业务时延要求相对较低的交通业务场景分析和预测， 从而指导交通基础设施规划。
可选地，所述边缘云还用于：将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至所述核心云。
本申请实施例中，多区域范围内的MEC边缘云在收集到所辖范围的设备数据和在MEC边缘云计算后的路况数据后，可以向核心云上报和同步。
需要说明的是，MEC多接入边缘云应用时，一方面，仿真平台(即云端仿真环境)运行在单一的边缘云，为该边缘云所辖范围内的路侧设备和行驶的车辆提供云端接入和仿真服务，继而为该边缘云的V2X车路协同平台、外部平台提供设备运行数据输入；另一方面，多个分布在不同地理位置的边缘云同时运行仿真平台，为各边缘云所辖范围的路端、车载设备提供接入和仿真服务，进而对多接入边缘云的仿真数据进行过滤、预处理、汇总、编码，为车路协同的设备提供对更广阔地理范围的水平扩展，并为集中化的核心云提供融合数据上行输入，为核心云统一管控的边缘云中接入的路端车载设备(即路侧设备和车载设备)提供下行管理通道。
本申请实施例中，基于边云协同架构，建立了端、边、云多级模拟仿真体系，支持端侧数据收集、边侧小颗粒区域场景模拟、云端大颗粒全局场景模拟的分层设计。具有易于扩展的优势，仿真平台运行在单边缘云中的服务器集群具有纵向扩展优势，运行在多接入边缘云具有水平扩展优势。
可选地，所述边缘云根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，包括：
根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
执行所述仿真场景，得到以下至少一项：
所述仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
所述仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
需要说明的是，本申请实施例中，提出了支持混合模拟和真实设备的场景元数据的录入、编排、执行流程、构建模拟和真实数据(SDK)的协同处理方法，并基于机器学习、深度学习等方法建立基建、路端、车端等多维模拟库，例如，模拟车辆模型库、气象路面模型库等，这样，可以灵活支撑复杂多元的智慧交通场景，在真实的路侧设备、车载设备上提供与仿真设备行为、通信方式一致的SDK。
还需要说明的是，本申请中的场景设计、通讯协议和通讯方式均采用了预先确定的场景和定义，在一定程度上规范了开发和设计的准则，能够使得多边串型开发变成并行开发，极大地提升了效率，并节约了各方面的成本。
可选地，所述根据所述仿真结果，验证所述车路协同系统的业务能力，包括：
通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
可选地，所述边缘云还用于收集所述配置信息；
其中，所述配置信息包括：设备元数据；场景元数据；路径元数据。
可选地，所述边缘云收集所述设备元数据，包括：
收集设备初始元数据；
对所述设备初始元数据进行校验；
在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库。
可选地，所述设备初始元数据包括以下至少一项：
车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件。
这里，路端元数据主要包括两类静态元数据：交通基础设施中的路侧 设备信息和局部区域地图信息。本申请实施例中，可以同时支持真实和仿真的元数据，路侧设备和地图的真实和仿真元数据也可以组合录入，不限于全部真实设备或全部模拟设备。
其中，路侧设备信息主要用以进行路侧通信、交通管控，以及检测、监控路面行人、车辆、环境等真实(或仿真)设备的基础信息。例如，真实或仿真元数据的标志信息、RSU、交通信号灯、激光或毫米波雷达、高清摄像头、温湿度传感器的设备名、设备编号、设备初始化状态、角度、位置、通信地址、频段等参数。
局部区域地图信息，即MEC边缘云负责的区域范围地图中的真实或仿真元数据的标志信息、道路、车道、相位、路口、位置点位等道路交通关系网的信息。
本申请实施例中，基于车路协同架构，建立了车端、路端多源数据收集、融合处理及场景模拟的设计，支持国标、非标及融合感知数据。
可选地，对所述设备初始元数据进行校验，包括：在所述设备初始元数据为车端元数据的情况下，对所述车端元数据中的所述车辆信息数据进行唯一性验证；若所述车辆信息数据是唯一的，则验证通过。
这里，车端元数据主要分为车辆信息数据和相应的车载设备数据，其中，车辆信息数据包含模拟车辆的必要性信息，例如，车架号和车牌号等，还包含车辆长宽等有益于辅助驾驶的信息；车载设备的必要信息包括设备号、设备类型等应用于通讯传输方面的数据信息。
如图3所示，车端元数据录入，主要指录入车辆以及车载设备的必要基础信息，以便在后续模拟、仿真过程进行数据、报文的封装和编排。其中，对所述车端元数据中的所述车辆信息数据进行唯一性验证，主要是指在录入的过程中会对车辆的车架号、车载设备号进行唯一性校验，车辆的这类信息需要具备唯一性，以确定车辆身份信息。
具体的，收集车端元数据的流程图如图3所示：
S301：录入车辆信息；
S302：对车辆信息进行校验；
S303：判断当前信息是否可用；
S304：在校验通过的情况下，将信息存储入数据库。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为路端元数据的情况下，对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
对所述路端元数据进行校验；
若所述路端元数据满足第一预设条件，则校验通过；
其中，所述路侧设备信息为路侧交通设备的相关信息；
所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器。
如图4所示，路端元数据录入时主要包括如下步骤：
S401：录入路侧设备基础元数据，例如录入上述路侧设备信息和局部区域地图信息；
S402：设定设备作用域，即设定部分路侧交通设备的作用范围，例如，设定激光雷达扫描的区域范围、温度传感器检测温度的区域范围等；
S403：设定设备的地理位置，即设定部分路侧交通设备在地图上的位置，或与地图上道路网络层的位置关系；
S404：对所述路端元数据进行校验，即判断路端元数据满足第一预设条件，具体可以包括检查录入的路侧设备与区域的地图信息是否准确、关联关系上是否有逻辑错误、或者与历史已录入的信息是否有冲突；若校验通过，则执行S405；若校验不通过，则需要重新录入，即执行S401；
S405：如果校验通过，存储入数据库，结束处理。
可选地，所述路端元数据满足第一预设条件的情况，包括以下三项：
所述路侧设备信息和所述局部区域地图信息准确；
所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件不冲突；
对所述仿真事件进行校验；
在所述仿真事件满足第二预设条件的情况下，校验通过。
这里，仿真事件主要是指在车路协同场景中预计的道路交通参与者产生或关联的交通事件，与车路协同典型场景相对应。例如，道路拥堵、施工、事故或危险等事件。需要说明的是，仿真事件可以与真实设备(即路侧设备和车载设备)上发生的真实事件共同作用与车路协同场景。例如，一个区域范围内可能通过真实的路端激光雷达和摄像头采集到数据产生多个路口交通拥堵事件，同时也可以通过仿真产生的大风危险告警事件，这两种时间共同对自动驾驶汽车作用，促使汽车避开此区域。
本申请实施例中，可以应用于车路协同场景。在车路协同场景中，所述边缘云可以收集车端元数据、路端元数据和仿真事件元数据、路径元数据、场景元数据；其中，
所述车端元数据，包括车辆信息数据及其相对应的车载设备数据；
所述路端元数据，包括路侧设备信息和局部区域地图信息，用于进行路侧通信、交通管控，以及检测、监控路面行人、车辆、环境等真实(或仿真)设备的基础信息。需要说明的是，监测的基础信息可以形成对应的仿真事件。
所述仿真事件元数据，包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件；其中，人工在地图上采集GPS点位可以包括车辆行驶路径上的连续GPS点位；设备属性可以包括交通信号灯灯态变化的频率；运行或行驶状态可以包括车速、方向角等；仿真事件可以包括道路施工事件。需要说明的是，人工在地图上采集的GPS点位、设备属性、 运行或行驶状态等均可以形成对应的仿真事件；
所述路径元数据，作为仿真车辆运行的基础信息，用于生成预先规划的路径；
所述场景元数据，作为场景脚本数据，用于在生成的路径上设置需要执行的具体场景；所述具体场景是利用基础场景进行自由组合形成的，所述基础场景可以是指国标场景定义的前向碰撞预警、交叉路口碰撞预警、左转辅助等17种基础场景。
需要说明的是，所述仿真事件基于所述互斥条件不冲突。也就是说，仿真事件之间不能存在行为互斥；或者，独立仿真事件内部不能存在行为互斥。
举例来说，以车路协同场景为自动驾驶场景为例，仿真车辆按照预先规划的路径运行，该路径包括路段1、路段2、路段3；其中，路段1中设置有仿真事件如道路湿滑事件，路段2中设置有仿真事件如施工事件、交通信号灯指示黄色的事件、天气为大风7级的事件，路段3中设置有仿真事件如道路拥堵事件、交通信号灯指示绿色的事件、绿波引导事件。
需要说明的是，上述仿真事件需要基于所述互斥条件不冲突。从第一个方面来说，是指仿真事件之间不能存在行为互斥，具体地，路段2中的天气为大风7级的事件和施工事件之间不能存在行为互斥，也就是说，在同一个位置的同一个时刻两个仿真事件之间不可能同时发生；路段3中的道路拥堵事件和交通信号灯指示绿色的事件之间不能存在行为互斥，也就是说，在同一个位置的同一时刻两个仿真事件之间不可能同时发生。从另一个方面来说，是指独立仿真事件内部不能存在行为互斥，具体地，在路段2的同一时刻，天气为大风7级的事件和天气为大风0级的事件不能存在行为互斥，也就是说，在同一个位置的同一个时刻设置的同一个类型的仿真事件不能有两个；在路段3的同一时刻，道路拥堵事件和道路顺畅事件不能存在行为互斥，也就是说，在同一个位置的同一个时刻设置的同一个类型的仿真事件不能有两个。
如图5所示，仿真事件元数据录入时主要经历如下主要步骤：
S501：选择关联仿真事件的设备或设备组，设备包括路侧设备、车载 设备、仿真路侧设备和仿真车载设备；例如，一个区域的一组交通信号灯关联SPAT事件信息；
S502：选择事件类型(即仿真事件的类型)以对应具体的场景；例如，拥堵、施工、事故、危险、前向碰撞、限速等；
S503：设置事件的参数，包括事件级别、执行时间、周期、地点、数值或其他触发条件；例如，区域内某一个路段预计在某个时间点发生道路结冰危险事件，级别为三、路面结冰厚度为15mm；
S504：设置事件的互斥条件；例如，道路结冰危险事件不应与高温危险事件在同一时间范围内发生在同一区域范围；
S505：对所述仿真事件进行校验，即检查仿真事件是否准确、与设备或区域地图的关联关系上是否有逻辑错误、或者与历史已录入的信息是否有冲突；若校验通过，则执行S506；若校验不通过，则需要重新录入，即执行S501；
S506：如果校验通过，存储入数据库，结束处理。
可选地，所述参数包括事件级别、执行时间、周期、地点和数值。
可选地，所述仿真事件满足第二预设条件的情况，至少包括以下三项：
所述仿真事件准确；
所述仿真事件与所述设备、地图的关联关系无逻辑错误；
所述仿真事件与所述数据库中的设备元数据之间无冲突。
如图6所示，本申请实施例中，录入脚本的方式可以分为模版导入、设备数据在线录制和在线元数据制定。
可选地，所述边缘云收集所述场景元数据，包括以下至少一项：
(一)如图6中a线路所示步骤，接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧设备数据。
也就是说，可以通过模版导入的方式录入脚本，具体的，可以将真实设备上传的数据按时间段进行经过筛选后，按照设备类型进行汇总、格式化后形成的符合车路协同系统场景运行的脚本化数据，用户通过人工在线 上传数据脚本导入，数据内容需包含需录入车辆的行为数据和该车辆涉及的所有路侧设备数据。
(二)如图6中b线路所示步骤，通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据。
也就是说，可以通过设备数据在线录制的方式录入脚本，具体的，仿真服务侧通过各种设置向V2X平台请求获取特定设备的数据，真实设备的数据V2X平台转发至仿真模拟器侧，仿真模拟器通过采集、汇总、格式化后形成的符合车路协同系统场景运行的脚本化数据并录入，数据内容需包含全部的车辆和涉及的路侧设备数据。
(三)如图6中c线路所示步骤，通过在可视化操作界面上编辑并录入的第三脚本化数据。
也就是说，可以通过在线元数据制定的方式录入脚本，具体可以通过人工在可视化操作界面上编辑并录入符合车路协同系统场景运行的脚本化数据，即车辆拟定行驶的路线或经过的地点。需要说明的是，该类数据只可作为场景编排过程中的元数据，在场景编排过程中才会根据路径元数据生成可以执行的脚本数据。
其中，所述第一脚本化数据、所述第一脚本化数据和所述第一脚本化数据均为符合所述仿真场景运行的脚本化数据。
需要说明的是，本申请实施例中，按照脚本类型的不同，可以分为两种执行方式：对真实设备(包含路侧设备、车载设备)的历史行为进行重放，其中设备数据在线录制和模版导入的元数据只可用于该场景；自定义录入脚本数据(即在线元数据制定的方式录入的脚本)只可作为场景支撑元数据，用于规划、设计场景中车载设备的运行路线，作为场景中底层支撑数据。
本申请实施例中，边缘云可以进行路侧设备、车载设备的仿真数据收集，仿真数据来源于真实设备数据可以通过三种方式获得。其中，真实设备数据来源于经过车辆协同平台中路端、车端的真实设备通过仿真SDK在 真实路侧设备、车载设备运行时进行自动化的数据采集、数据过滤，以及标准化编码与转码、转发所获取的数据；编辑录入方式来源于人工在地图上采集GPS点位(例如，车辆行驶路径上的连续GPS点位)、录入设备属性(例如，交通信号灯灯态变化的频率)、运行或行驶状态(例如，车速、方向角等)、仿真事件(例如，道路施工事件)等信息，再做与真实设备数据上报方式中一致的标准化编码与转码；车路协同场景仿真时对真实设备数据与编辑录入的仿真设备数据进行融合，实现真实设备与仿真设备的自由组合(例如，真实路端设备与仿真车载设备组合，或仿真路端设备与真实车载设备的组合)，为车路协同平台验证大量路端设备和车载设备的车路协同能力提供了高效灵活的实践方案，还可以在特定场景下减少真实设备的投入，从而节省了成本。
可选地，所述边缘云收集所述路径元数据，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上对路段进行切分，形成运行点；
收集汇总所述运行点并存储，形成路径元数据。
路径元数据作为仿真车辆运行的基础信息，当路径元数据生成完成以后，需要按需将路径元数据和车辆进行一对多的绑定。
需要说明的是，在线元数据录入功能可以一次性录入一至多条路径元数据，为匹配特定的车辆场景提供必要的支持。
如图7所示，在设置自定义路径元数据的时候，需按路径规划设想进行人工切分。具体的，可以通过人工在可视化地图页面选点的方式设置切分路段的开始点和起始点，并选择两点行驶的策略信息。例如，开始点、结束点的时间、速度、行向角以及预设切分的粒度等信息。
本申请一实施例中，边缘云收集所述路径元数据的流程(即元路径行驶点模拟流程)如图7所示：
S701：加载自定义的动态路径元数据；
S702：在路径上对路段进行切分，即按照关键点切分路段，并分类型；
S703：判断路段类型；
若为直线变化，则结合速度分析，按加速度切分，或者按距离切分； 若为弧形变化，则结合速度分析，按速度、角度切分，或者按角度切分；
S704：收集汇总运行点；
S705：存储运行点，形成路径元数据。
在计算完成了整段脚本后，收集所有的模拟点以及各段路的开始结束点，存入数据库，则完成了一次路径元数据的录入。
需要说明的是，在场景中，车辆的行驶行为可能会根据场景事件进行智能、实时的变化，如果没有其他外界因素影响，则车辆应该按照路径元数据进行仿真运行。
本申请一实施例中，仿真基础路径元数据(即路径元数据)是通过算法智能的加入模拟的行驶位置信息点，可以使车辆运行行为能够更加顺畅、真实。
可选地，所述边缘云在路径上对路段进行切分，包括以下至少一项：
根据距离对路段进行均分；
根据加速度对路段进行切分；
根据角度对路段进行切分；
根据角度和加速度对路段进行切分。
具体的，如图7所示，可以按照速度变化和角度变化分为以下四种切分方式：
(一)按两点距离均分：假定车辆为直线行驶，以及假定车辆是匀速行驶，可以计算输入时间经过两点之间距离的速度和两点之间直线相对正北为0的角度，然后按照设置的切分粒度，等分当前路段，并根据距离和角度计算出等分点的经纬度。
(二)按加速度切分：假定车辆直线行驶，且开始、结束位置点信息中车辆速度不同，可根据速度差和时间计算出加速度，根据设置的切分粒度、加速度、时间、两点之间直线相对正北的角度，按照行驶距离进行计算，得出每一个模拟点的经纬度，直至结束点。
(三)按角度切分：假定车辆速度不变，可以按照当前点的航向角度和结束点的航向角度，得出两点在行驶过程中角度的变换；以两点为虚拟圆上两点，两点间的距离作为圆直径，按照设置切分粒度等分相差角度和 相差距离，计算出圆弧上等分点经纬度，这种方法可适用于模拟车辆匀速转弯的场景。
(四)按角度、加速度切分：假定速度变化(即开始点和结束点速度信息不一致)，可以获取两点时间差，并计算加速度；按照当前点的航向角度和结束点的航向角度，以两点为虚拟圆上两点，两点间的距离作为圆直径，按照设置切分粒度、加速度、等分角，计算出圆弧上行驶点经纬度，这种方法可适用于模拟车辆变速转弯的场景。
可选地，所述边缘云进行场景编排，包括：
根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
如图8所示，可选地，所述边缘云根据所述路径元数据与所述场景元数据，在路径上设置场景事件，包括：
S801：加载自定义的动态路径元数据；
S802：通过地图界面展示规划路径；
S803：在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
S804：对所述场景事件进行校验；
S805：若校验成功，则将所述场景事件加入待存储队列；
S806：判断是否录入完成；完成，则执行S807；否则，执行S803；
S807：在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的所述场景事件。
需要说明的是，关键点场景事件设置，即关键点行为编织，在路径上设置场景事件，只可用于互动融合模拟场景，主要是指在规划好的路径元数据上设置需要执行的场景行为，该过程具备以下特点：包含17种基础标准国标场景行为事件；多个国标场景行为可在互动仿真路径元数据上进行一定程度上的自由组合；具备指定场景发生的道路规划和范围；真实设备与模拟设备可以在场景中混合使用，例如，真实路侧设备可以为模拟车辆提供自动驾驶或者行为决策的数据支撑，反之，模拟路侧设备亦可为真实V2X道路测试车辆提供动态、可信和标准的支撑数据。
可选地，所述边缘云对所述场景事件进行校验，包括：判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；若不存在行为互斥，则校验通过；否则，校验失败。
也就是说，需满足以下约束：场景事件之间不能存在行为互斥，例如道路施工事件和交通灯交互；场景事件和路径元数据不可存在行为互斥，例如直行车道上不可执行左转辅助。
本申请实施例中，通过场景仿真引擎，将来源于在线设备SDK上报制定(即设备数据在线录制)、自定义编排元数据制定(即在线元数据制定)、与模板数据导入(即模版导入)制定的数据，按照国标场景定义的前向碰撞预警、交叉路口碰撞预警、左转辅助等17种基础场景通过一定程度的人工组合、设置和算法自动生成的方式编排为适用于仿真设备的场景脚本，实现了路侧设备、车载设备的仿真场景编排，用于车路协同系统、路侧设备、车载设备能力的验证。
通过仿真模拟，可以提供不易在真实世界中创造的事件和条件，例如，拥堵事件、车辆失控预警事件、道路施工事件，以及大风、大雾、路面结冰等道路天气危险事件，避免在场景验证时无法实现事件产生的条件，提高了场景验证效率。
另外，由于仿真场景能直接产生危险事件，避免了真实的车辆在行驶中为了验证仿真场景对驾驶员、行人、道路等造成危险。
此外，当17种基础场景经过编排、融合后能够形成全新的组合场景，进一步可构建算法模型，采用机器学习等算法，为特定场景的自动驾驶行为提供算法训练功能，可应用于边缘云辅助驾驶方向的机器学习、算法训练，商业应用更加广泛。
本申请实施例中，通过仿真车载设备、路侧设备，并与边缘云中仿真环境接入的真实设备混合、共同作用于车路协同场景，能够减少大量真实设备的部署以降低成本，并能创造真实世界中难以实现的场景条件。
例如，主车(host vehicle，HV)在行驶过程中，在场景中预设前方不远的道路上有一辆仿真的车辆(remote vehicle，RV)，而真实的路边激光雷达检测到了左前方有行人，此时主车应进行减速，而不是按照场景预设的 从左侧进行超车。
本申请在模拟仿真方面可以做到真实与模拟设备交替使用，易于扩展，且在后续的数据增值性、应用广泛性、机器学习数据多样性、通用性等方面较优，解决了现有技术中常见的由单一服务器仿真实现，导致做到分布式数据融合，以及人、车和物的相关智能算法训练的问题。
可选地，所述仿真场景包括历史回放固定场景和互动融合模拟场景。
本申请一实施例中，按功能需要，可以将仿真场景分为两种：历史回放固定场景和互动融合模拟场景。其中，历史回放固定场景主要是指将过往的某个实际车路协同区域的运行情况进行回放，常用于展示、展览；互动融合场景主要是指将真实设备(即路侧设备和车载设备)和仿真设备(即仿真路侧设备和仿真车载设备)进行编织，让真实设备和仿真设备共同运行在特定的线路之中，以获取车辆的行为策略反馈数据或路侧设备的交互结果。
具体的，可以根据参数配置或应用程序接口API调用，判断是否执行历史场景回放(即执行历史回放固定场景)。
如图10所示，可选地，所述边缘云执行所述仿真场景，包括：
S1001：进行场景执行引擎初始化；
S1002：根据参数配置或应用程序接口API调用，判断所述仿真场景的类型；根据所述类型，执行所述仿真场景。其中，仿真场景为历史回放固定场景时，执行S1003；仿真场景为互动融合模拟场景时，执行S1004。
需要说明的是，场景执行(即执行仿真场景)旨在将经过编排后的车端元数据、路端元数据和仿真事件元数据在车路协同具体场景下运行起来，对真实或仿真的路端交通基础设施、车辆验证其在车路协同作用下的通信能力、数据处理能力，以及经过人工智能算法增强的车端、路端计算设备的行为决策能力。
在进行车路协同、自动驾驶相关的仿真研究时，仿真或真实的车载设备、路侧设备接入边缘云上的仿真环境，共同在同一时间段执行仿真场景。
在进行车路协同、自动驾驶相关的真实设备(即车载设备、路侧设备)验收时，真实设备接入边缘云的车路协同平台，与不易在真实世界中实现 的仿真设备元数据和仿真事件元数据共同在同一时间段执行车辆协同预设场景。这样，在MEC边缘云上接入了大量真实设备时，仿真环境能够为车路协同场景实现提供不易在真实世界中创造的事件和条件，降低了场景运行的成本和风险。
仿真模拟库即是人工智能作出决策能力的基础支撑数据，其依附于V2X平台，通过真实的车载设备、路侧设备在运行过程中产生的行为数据进行自主学习，以达到能够为同样场景行为作出决策的能力。
本申请一可选实施例中，边缘云可以建立线程池，为车端(即车载设备)播发行驶数据、事件接收、行驶规划、时间处理和数据上报网络通讯等主要工作创建线程，设置线程间数据共享和同步机制，启动各线程并根据固定的频率读取、执行汽车行驶路径脚本；边缘云还可以建立线程池，为路端(即路侧设备)播发来自车路协同平台的RSI、MAP、SPAT消息或场景事件，路端主动生成RSM告警，并进行有效期内告警消息的状态维持，事件广播等主要工作创建线程，设置线程间数据共享和同步机制，启动各线程并根据仿真场景指定的频率读取、执行路侧设备(例如交通信号灯)脚本。
需要说明的是，如果当前执行场景的设备是车端(即车载设备)，则车端对脚本数据进行解码、与交通道路网络或其他设备元数据建立关联关系等预处理；如果场景事件造成了汽车必须更改行驶路径，则车端通过仿真规划出不同于预设脚本、新的行驶路径(包括GPS点位、转向角、行驶速度等)；采用算法进行场景事件的处理，例如，采用深度学习、强化学习等方法不断改进事件处理的最优解。如果当前执行场景的设备是路端(即路侧设备)，则路端对脚本数据进行解码、与交通道路网络或其他设备元数据建立关联关系等预处理。
可选地，所述边缘云进行场景执行引擎初始化，包括以下至少一项：
初始化运行所需的程序空间；
加载运行参数；
连接本地数据库、缓存或消息队列；
加载设备元数据；
初始化网络通讯链接。
本申请实施例中，在场景执行开始时，场景执行引擎进行初始化。例如，初始化运行所需的程序空间、加载运行参数，连接本地数据库、缓存、消息队列等中间件，加载必要的车端元数据、路端元数据和仿真事件元数据，初始化必要的网络通讯链接、边缘云路由网络地址等。
如图10所示，可选地，在所述类型为历史回放固定场景的情况下，所述边缘云执行所述仿真场景，包括：
选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
从数据库中加载已存储的历史场景元数据；其中，所述历史场景元数据包括设备运行数据和场景录制数据；
将所述场景录制数据发送给所述设备。
在所述类型为历史回放固定场景的情况下，即执行历史场景，则选择需要执行的设备(或设备组)，从数据库中加载历史已存储的真实(或仿真)设备的运行数据和场景录制数据，对数据设置好历史回放标志，设备之间进行进程之间或网络通讯上报或播发历史运行数据；云端仿真环境在经过车路协同平台接收到具有历史回放标志的数据后，加载录制的场景事件数据，播发给路侧设备和车载设备。
此时，车路协同平台在边缘云上能够监控到车辆当前的动态行驶状态，以及在历史场景中的决策行为。
可选地，在所述类型为互动融合模拟场景的情况下，所述边缘云所述执行所述仿真场景，包括：
根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
为所述设备匹配脚本化数据。
在所述类型为互动融合模拟场景的情况下，即场景引擎得到的指令不是执行历史场景，而是互动融合模拟场景，则根据当前的车载设备和路侧设备的设备类型加载关联的场景元数据，包括设备基础信息、区域交通道 路关系网，并匹配设备的脚本化数据。
可选地，一个仿真场景与至少一个仿真设备绑定，一个仿真设备只与一个仿真场景绑定；其中，所述仿真设备包括所述仿真车载设备和所述仿真路侧设备。
如图9所示，场景是作为仿真车载设备、仿真路侧设备以及设备间交互的基础支撑数据，为了保证设备的正常运行，需要进行数据正确性校验，需满足以下约束条件：一个场景可以绑定多个仿真设备(即仿真车载设备和仿真路侧设备)，但是一个仿真设备只可绑定一个场景。
可选地，所述边缘云还用于：根据仿真结果，向所述边缘云覆盖范围内所述车载设备和/或所述仿真车载设备发送动态感知地图。
可选地，所述车载设备与所述边缘云建立通信，包括：接收所述核心云发送的所述边缘云的网络地址；从所述网络地址中，选择与所述车载设备所在位置最近的网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
真实汽车中的车载SDK或仿真汽车中的场景引擎，可以根据初始化时获得的区域范围内边缘云网络地址，选择就近的边缘云(即第一边缘云)并建立连接，连接建立后，可以周期性获取接近范围的RSU列表和通信地址。
可选地，所述车载设备为所述边缘云提供所述第二数据，包括：
根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
根据所述第一报文，向所述边缘云上传所述第二数据。
如图11所示，为车载SDK工作流程图：
S1101：配置车辆SDK的加载参数、脚本列表；
S1102：SDK根据配置，从云平台拉取对应的脚本；
S1103：将脚本缓存下来，根据脚本的执行顺序、频率逐条报文、逐个 脚本进行执行；
S1104：根据配置连接对应的路侧单元；
S1105：判断是否连接成功；若连接成功，则执行S1104；若连接失败，则需要重新录入，即执行S1106；
S1106：进行报文的接收；
S1107：按照设计，上传需要的报文。
需要说明的是，本申请实施例中，SDK能够根据参数配置接口触发国标17类基础演示场景(如前向碰撞预警、交叉路口碰撞预计和前方拥堵提醒等场景)，根据车辆自身与边缘云的位置选择切换就近边缘云的策略。在连接边缘云中的V2X车路协同平台后，可以获取与用于演示的仿真或真实的路侧设备的事件、预警数据，完成设备能力的验证。运行在边缘云中的仿真平台和车路协同平台在展示仿真场景时，需要按照标准化的编码格式、通信频率、通信方式和场景处理行为获得车载设备在该场景下的数据，车载SDK为实现车路协同场景定义了一致性的程序标准流程和行为，使得大量不同类型的车载设备为车路协同平台服务具有标准化的场景处理能力，减少不同类型设备带来的复杂性，降低了车路协同平台实现的成本，同时也能够为验证车辆的车路协同能力或自动驾驶能力提供标准化快速验证入口。
如图10所示，可选地，所述车载设备执行所述脚本，循环执行以下步骤：
接收其他车载设备或路侧设备播发的场景事件；
对所述场景事件进行处理；
向所述边缘云发送车辆的行驶数据和所述场景事件的处理结果。
也即，在车载设备执行脚本过程中，可以循环执行以下步骤：接收远车(即其他车载设备)或路侧设备播发、封装成RSI、RSM等消息的场景事件，仿真动态事件行驶数据；对事件进行处理；上报行驶数据和事件处理结果。
可选地，所述车载设备每完成一条脚本的执行时，向所述边缘云发送一次执行脚本的路径；以及，每完成一次一次场景事件处理时，向所述边 缘云发送一次场景事件的处理结果。
也即，每当车载设备完成一条行驶脚本的执行、处理完一次场景事件，就通过线程异步的发送执行脚本的路径或场景事件处理的结果。
可选地，所述路侧设备还用于：通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
具体的，真实的路侧SDK或仿真路侧单元中的场景引擎，可以根据初始化时获得的区域范围内边缘云网络地址，选择就近的边缘云并建立连接；连接建立后，可以周期性获取接近范围的汽车列表和通信地址。
如图10所示，可选地，所述路侧设备还用于在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
也就是说，在场景的预设周期内，路侧设备可以通过主线程循环执行以下步骤：接收边缘云中车路协同平台的告警事件或自主生成告警事件；判断事件有效期，若过期则标记删除；广播事件至接近范围内车辆。
可选地，所述路侧设备还用于：周期性地检查所述告警事件的有效性；在所述告警事件已过期的情况下，丢弃所述告警事件。
如图12所示，为路侧SDK工作流程图：
S1201：SDK在路侧设备单元上电时被引导加载，进行SDK内部的初始化工作。例如，运行空间分配、存储空间检查、路侧设备单元通讯模块检查等；
S1202：SDK根据内置的参数继续引导加载，或根据远程接口配置修改运行参数。例如，通过接口配置进行软复位以清空存储的消息、通过配置边缘云节点参数设置需要连接的边缘云车路协同V2X平台地址和登录认证信息等；
S1203：SDK能够根据参数配置接口触发国标17类基础演示场景，例如，道路危险状况提示、限速预警、绿波车速引导等场景)；
S1204：SDK通过路侧设备单元的设备通信模块采集路侧交通设施的事件和数据，例如，交通信号灯的状态、标识标牌信息、摄像头数据、温湿度计数据等；并暂时到设备存储空间，准备上报到V2X平台；
S1205：SDK根据内置的边缘云通信地址表选择就近边缘云的路由策略，连接边缘云中的V2X车路协同平台与用于演示的仿真或真实的车辆；
S1206：SDK通过内置或配置的边缘云连接地址、认证信息，尝试连接边缘云节点中的V2X平台；如果连接不成功，重试N秒后重新连接，即执行S1205；如果已经连接成功，则执行S1207，并周期性的上报心跳数据包，保持设备的在线状态；
S1207：SDK将来自路侧交通设施的采集数据上报给接近范围的边缘云V2X平台；
S1208：SDK通过已与边缘云建立的连接，接收来自V2X平台的事件提醒消息(RSI)、安全消息(RSM)，经过消息解析后缓存到设备内存空间中；
需要说明的是，车路协同平台通过计算后产生道路事件或预警信息，最终推送到车载设备，完成路侧设备能力的验证。
S1209：周期性地检查消息的有效性；若有效，则执行S1210；若无效，则丢弃该消息；例如，路口拥堵事件是否过期等，如果已过期则丢弃该消息；
S1210：SDK将缓存的消息经过消息编码后通过无线网络周期性的广播给附近行驶的车辆，如果车辆已接收该消息，则将该消息上报给V2X平台，以让V2X平台能够对消息的接收、使用率等方面做统计分析；
需要说明的是，运行在边缘云中的仿真平台和车路协同平台在展示仿真场景时，需要按照标准化的编码格式、通信频率、通信方式和场景处理行为获得路侧设备在该场景下的数据。路侧SDK为实现车路协同场景，定义了一致性的程序标准流程和行为，使得大量不同类型的路侧设备为车路协同平台服务具有标准化的场景处理能力，减少不同类型设备带来的复杂 性，降低了车路协同平台实现的成本，同时也为验证路侧设备的车路协同能力或辅助验证自动驾驶车辆提供标准化快速验证入口。
此外，路侧设备在场景执行过程中，可以不断优化与边缘云中车路协同平台和行驶中汽车事件信息送达的效率。例如，可以通过深度学习算法优化路端对交通参与者的检测、跟踪和监控，降低道路拥堵、危险等场景事件的判断时延。
本申请实施例，实现了边云协同和车路协同，在MEC边缘云上实现了设备仿真环境以对车路协同平台提供接近真实环境的路侧设备、车载设备的仿真交互。其中，边云协同，采用与路侧设备、车载设备接近的MEC多接入边缘云运行仿真环境，能够以低时延、高速地与路侧设备、车载设备交互BSM、MAP、SPAT、RSI和RSM等消息，如果结合5G NR技术，能够在边缘云端支持百万级别的真实设备接入与消息处理能力。车路协同，MEC多接入边缘云为区域范围内的设备和车路协同应用提供共享的基础设施、以及仿真模拟需要的配置信息和仿真行为库；在MEC边缘云上根据配置信息接入仿真(或真实)设备数据，设计并运行仿真场景，在运行过程中根据场景配置动态加载并结合仿真行为库中的对应行为进行模拟，以验证车载设备、路侧设备、车路协同平台、三方平台在车路协同各场景下的数据收集能力、通信能力、数据融合处理能力、行为决策能力、与不同平台或应用的协作能力。本申请实施例支持模拟与真实设备协同数据处理，提供弹性扩展、分布式集群、缓存、人工智能和大数据处理能力，增强了对各地方和本地业务的支持，能有效降低网络延迟，为后续更好地开展智慧交通业务提供了一定程度上的帮助和支持。
本申请实施例中，将系统多边、多种依赖进行了进行架构分层，并提供了完整闭环业务逻辑和多设备SDK，以供各种外部依赖进行可切分、可模拟和可真实交互的解决方案。任何一方所依赖的业务实体(例如路侧设备、车载设备)都可以通过单一或者全部的模拟并嵌入车路协同系统整体中，保证系统的稳定运行，从而解决了项目开发、部署、测试中所遇到的链路过长、数据来源复杂、数据格式各异，且定位问题困难、外部环境以及条件强依赖的问题，解决了对接设备过程中的沟通噪音。车路协同整体 环境中各个层面的解耦，实现了可快速开发、数据透明、高度定制和高可用特性。
如图13所示，本申请的实施例提供一种模拟仿真方法，应用于边缘云，包括：
S1301：收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
该实施例的模拟仿真方法，通过收集路侧设备和车载设备的数据，在边缘云上进行车路协同环境的模拟仿真，可以提供不易在真实世界中创造的事件和条件，能够解决常规车路协同平台在开发过程中就需要介入大量真实设备对接的问题，从而节省调试时间和成本。
可选地，所述模拟仿真方法还包括：将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果，包括：
根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
执行所述仿真场景，得到以下至少一项：
仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
可选地，模拟仿真方法还包括：将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，模拟仿真方法还包括：根据所述仿真结果，验证所述车路协同系统的业务能力。
可选地，所述根据所述仿真结果，验证所述车路协同系统的业务能力，包括：
通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
可选地，模拟仿真方法还包括：收集所述配置信息；
其中，所述配置信息包括：
设备元数据；
场景元数据；
路径元数据。
可选地，所述边缘云收集所述设备元数据，包括：
收集设备初始元数据；
对所述设备初始元数据进行校验；
在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库。
可选地，所述设备初始元数据包括以下至少一项：
车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为车端元数据的情况下，对所述车端元数据中的所述车辆信息数据进行唯一性验证；
若所述车辆信息数据是唯一的，则验证通过。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为路端元数据的情况下，对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
对所述路端元数据进行校验；
若所述路端元数据满足第一预设条件，则校验通过；
其中，所述路侧设备信息为路侧交通设备的相关信息；
所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器。
可选地，所述路端元数据满足第一预设条件的情况，包括以下三项：
所述路侧设备信息和所述局部区域地图信息准确；
所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
可选地，对所述设备初始元数据进行校验，包括：
在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件无冲突；
对所述仿真事件进行校验；
在所述仿真事件满足第二预设条件的情况下，校验通过。
可选地，所述参数包括事件级别、执行时间、周期、地点和数值。
可选地，所述仿真事件满足第二预设条件的情况，至少包括以下三项：
所述仿真事件准确；
所述仿真事件与所述设备、地图的关联关系无逻辑错误；
所述仿真事件与所述数据库中的设备元数据之间无冲突。
可选地，收集所述场景元数据，包括以下至少一项：
接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧设备数据；
通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据；
通过在可视化操作界面上编辑并录入的第三脚本化数据；
其中，所述第一脚本化数据、所述第一脚本化数据和所述第一脚本化数据均为符合所述仿真场景运行的脚本化数据。
可选地，收集所述路径元数据，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上对路段进行切分，形成运行点；
收集汇总所述运行点并存储，形成路径元数据。
可选地，在路径上对路段进行切分，包括以下至少一项：
根据距离对路段进行均分；
根据加速度对路段进行切分；
根据角度对路段进行切分；
根据角度和加速度对路段进行切分。
可选地，进行场景编排，包括：
根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
可选地，所述边缘云根据所述路径元数据与所述场景元数据，在路径上设置场景事件，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
对所述场景事件进行校验；
若校验成功，则将所述场景事件加入待存储队列；
在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的所述场景事件。
可选地，对所述场景事件进行校验，包括：
判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；
若不存在行为互斥，则校验通过；否则，校验失败。
可选地，所述仿真场景包括历史回放固定场景和互动融合模拟场景。
可选地，执行所述仿真场景，包括：
进行场景执行引擎初始化；
根据参数配置或应用程序接口API调用，判断所述仿真场景的类型；
根据所述类型，执行所述仿真场景。
可选地，进行场景执行引擎初始化，包括以下至少一项：
初始化运行所需的程序空间；
加载运行参数；
连接本地数据库、缓存或消息队列；
加载设备元数据；
初始化网络通讯链接。
可选地，在所述类型为历史回放固定场景的情况下，执行所述仿真场景，包括：
选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
从数据库中加载已存储的历史场景元数据；其中，所述历史场景元数据包括设备运行数据和场景录制数据；
将所述场景录制数据发送给所述设备。
可选地，在所述类型为互动融合模拟场景的情况下，执行所述仿真场景，包括：
根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
为所述设备匹配脚本化数据。
可选地，一个仿真场景与至少一个仿真设备绑定，一个仿真设备只与一个仿真场景绑定；其中，所述仿真设备包括所述仿真车载设备和所述仿真路侧设备。
可选地，模拟仿真方法还包括：根据仿真结果，向所述边缘云覆盖范围内所述车载设备和/或所述仿真车载设备发送动态感知地图。
综上所述，该实施例的模拟仿真方法，在边缘云上实现了设备仿真环境以对车路协同平台提供接近真实环境的路侧设备、车载设备的仿真交互，支持模拟与真实设备协同数据处理，能够为车路协同场景实现提供不易在真实世界中创造的事件和条件，降低了场景运行的成本和风险。
需要说明的是，该方法应用于上述车路协同系统中边缘云，能够实现的各个过程，也能达到相同的技术效果，为避免重复，这里不再赘述。
如图14所示，本申请的实施例提供一种模拟仿真方法，应用于核心云，包括：
S1401：为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
该实施例的模拟仿真方法，能够提供路由信息，使得路侧设备和车载设备能够快速地就近接入边缘云。
可选地，所述模拟仿真方法还包括：
与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测。
综上所述，该实施例的模拟仿真方法，与边缘云建立通信，可以在区域、全局范围里提供相应范围的边缘协同计算调度、多级计算能力调度等功能。通过对仿真(或真实)设备接入边缘云所产生的交通事件，进行融合计算，能够实现对业务时延要求相对较低的交通业务场景分析和预测，从而指导交通基础设施规划。
需要说明的是，该方法应用于上述车路协同系统中核心云，能够实现的各个过程，也能达到相同的技术效果，为避免重复，这里不再赘述。
如图15所示，本申请的实施例提供一种模拟仿真方法，应用于路侧设备，包括：
S1501：与边缘云建立通信，为所述边缘云提供第一数据；
S1502：根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
该实施例的模拟仿真方法，通过采用与仿真路侧设备的行为和通信方式一致的路侧SDK，使得路侧设备能够继承实现仿真路侧设备的能力，并能够根据边缘云的仿真结果作出行为决策。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述模拟仿真方法还包括：
通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；
周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
可选地，所述模拟仿真方法还包括：
在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
可选地，所述模拟仿真方法还包括：
周期性地检查所述告警事件的有效性；
在所述告警事件已过期的情况下，丢弃所述告警事件。
综上所述，该实施例的模拟仿真方法，通过采用与仿真路侧设备的行为和通信方式一致的路侧SDK，使得路侧设备能够继承实现仿真路侧设备的能力，例如，仿真场景能力、边缘云通信能力和车端广播能力等，从而解决了常见的车路协同系统设计开发过程中，由于参与方众多，沟通过程冗长且充满噪音的问题，可以节约开发成本和开发周期。
需要说明的是，该方法应用于上述车路协同系统中路侧设备，能够实现的各个过程，也能达到相同的技术效果，为避免重复，这里不再赘述。
如图16所示，本申请的实施例提供一种模拟仿真方法，应用于车载设备，包括：
S1601：与边缘云建立通信，为所述边缘云提供第二数据，并根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
该实施例的模拟仿真方法，通过采用与仿真车载设备的行为和通信方式一致的车载SDK，使得车载设备能够继承实现仿真车载设备的能力，并能够根据边缘云的仿真结果作出行为决策。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述与边缘云建立通信，包括：
接收核心云发送的所述边缘云的网络地址；
从所述网络地址中，选择与所述车载设备所在位置最近的所述网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
可选地，所述为所述边缘云提供第二数据，包括：
根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
根据所述第一报文，向所述边缘云上传所述第二数据。
可选地，所述车载设备执行所述脚本，循环执行以下步骤：
接收其他车载设备或路侧设备播发的场景事件；
对所述场景事件进行处理；
向所述边缘云发送车辆的行驶数据和所述场景事件的处理结果。
可选地，所述车载设备每完成一条脚本的执行时，向所述边缘云发送一次执行脚本的路径；以及，每完成一次一次场景事件处理时，向所述边缘云发送一次场景事件的处理结果。
综上所述，该实施例的模拟仿真方法，通过采用与仿真车载设备的行为和通信方式一致的车载SDK，使得车载设备能够继承实现仿真车载设备的能力，例如仿真场景能力、预警决策能力等，能够保证真实设备能够实现国标定义的17种车路协同典型应用场景，避免过于复杂的网络环境影响和硬件需求，更好的解决了车路仿真模拟系统生命周期中各方面的成本问题。
需要说明的是，该方法应用于上述车路协同系统中车载设备，能够实现的各个过程，也能达到相同的技术效果，为避免重复，这里不再赘述。
如图17所示，本申请的实施例提供一种模拟仿真装置，应用于边缘云，包括：
仿真模块1701，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模 拟仿真，得到仿真结果。
可选地，所述模拟仿真装置还包括：
第一发送模块，用于将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述仿真模块1701包括：
场景编排子模块，用于根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
场景执行子模块，用于执行所述仿真场景，得到以下至少一项：
仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
可选地，模拟仿真装置还包括：
第二发送模块，用于将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，模拟仿真装置还包括：
验证模块，用于根据所述仿真结果，验证所述车路协同系统的业务能力。
可选地，所述验证模块包括：
验证子模块，用于通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
可选地，模拟仿真装置还包括：
收集模块，用于收集所述配置信息；
其中，所述配置信息包括：
设备元数据；
场景元数据；
路径元数据。
可选地，所述收集模块包括：
第一收集子模块，用于收集设备初始元数据；
第一校验子模块，用于对所述设备初始元数据进行校验；
第一存储子模块，用于在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库。
可选地，所述设备初始元数据包括以下至少一项：
车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件。
可选地，所述收集模块还包括：
第二校验子模块，用于在所述设备初始元数据为车端元数据的情况下，对所述车端元数据中的所述车辆信息数据进行唯一性验证；
结果确定子模块，用于若所述车辆信息数据是唯一的，则验证通过。
可选地，所述第一校验子模块包括：
第一设定单元，用于在所述设备初始元数据为路端元数据的情况下， 对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
第二设定单元，用于对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
第一校验单元，用于对所述路端元数据进行校验；
第一结果确定单元，用于若所述路端元数据满足第一预设条件，则校验通过；
其中，所述路侧设备信息为路侧交通设备的相关信息；
所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器。
可选地，所述路端元数据满足第一预设条件的情况，包括以下三项：
所述路侧设备信息和所述局部区域地图信息准确；
所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
可选地，所述第一校验子模块还包括：
第一选择单元，用于在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
第二选择单元，用于选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
设置单元，用于设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件无冲突；
第二校验单元，用于对所述仿真事件进行校验；
第二结果确定单元，用于在所述仿真事件满足第二预设条件的情况下，校验通过。
可选地，所述参数包括事件级别、执行时间、周期、地点和数值。
可选地，所述仿真事件满足第二预设条件的情况，至少包括以下三项：
所述仿真事件准确；
所述仿真事件与所述设备、地图的关联关系无逻辑错误；
所述仿真事件与所述数据库中的设备元数据之间无冲突。
可选地，第一收集子模块包括以下至少一项：
第一收集单元，用于接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧设备数据；
第二收集单元，用于通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据；
第三收集单元，用于通过在可视化操作界面上编辑并录入的第三脚本化数据；
其中，所述第一脚本化数据、所述第一脚本化数据和所述第一脚本化数据均为符合所述仿真场景运行的脚本化数据。
可选地，第一收集子模块还包括：
加载单元，用于加载自定义的动态路径元数据，并通过地图界面展示规划路径；
切分单元，用于在路径上对路段进行切分，形成运行点；
第四收集单元，用于收集汇总所述运行点并存储，形成路径元数据。
可选地，在路径上对路段进行切分，包括以下至少一项：
根据距离对路段进行均分；
根据加速度对路段进行切分；
根据角度对路段进行切分；
根据角度和加速度对路段进行切分。
可选地，场景编排子模块包括：
第一设置单元，用于根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
第三选择单元，用于选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
可选地，所述第一设置单元包括：
第一处理子单元，用于加载自定义的动态路径元数据，并通过地图界面展示规划路径；
第二处理子单元，用于在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
校验子单元，用于对所述场景事件进行校验；
结果确认子单元，用于若校验成功，则将所述场景事件加入待存储队列；
存储子单元，用于在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的所述场景事件。
可选地，对所述场景事件进行校验，包括：
判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；
若不存在行为互斥，则校验通过；否则，校验失败。
可选地，所述仿真场景包括历史回放固定场景和互动融合模拟场景。
可选地，场景执行子模块包括：
初始化单元，用于进行场景执行引擎初始化；
判断单元，用于根据参数配置或应用程序接口API调用，判断所述仿真场景的类型；
执行单元，用于根据所述类型，执行所述仿真场景。
可选地，进行场景执行引擎初始化，包括以下至少一项：
初始化运行所需的程序空间；
加载运行参数；
连接本地数据库、缓存或消息队列；
加载设备元数据；
初始化网络通讯链接。
可选地，执行单元包括：
选择子单元，用于选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
第一加载子单元，用于从数据库中加载已存储的历史场景元数据；其 中，所述历史场景元数据包括设备运行数据和场景录制数据；
发送子单元，用于将所述场景录制数据发送给所述设备。
可选地，执行单元还包括：
第二加载子单元，用于根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
匹配子单元，用于为所述设备匹配脚本化数据。
可选地，一个仿真场景与至少一个仿真设备绑定，一个仿真设备只与一个仿真场景绑定；其中，所述仿真设备包括所述仿真车载设备和所述仿真路侧设备。
可选地，模拟仿真装置还包括：
第三发送模块，用于根据仿真结果，向所述边缘云覆盖范围内所述车载设备和/或所述仿真车载设备发送动态感知地图。
该装置，在边缘云上实现了设备仿真环境以对车路协同平台提供接近真实环境的路侧设备、车载设备的仿真交互，支持模拟与真实设备协同数据处理，能够为车路协同场景实现提供不易在真实世界中创造的事件和条件，降低了场景运行的成本和风险。
本申请实施例提供的模拟仿真装置能够实现图13的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
如图18所示，本申请的实施例提供一种模拟仿真装置，应用于核心云，包括：
路由模块1801，用于为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
可选地，所述模拟仿真装置还包括：
第一处理模块，用于与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测。
该装置，通过与边缘云建立通信，可以在区域、全局范围里提供相应范围的边缘协同计算调度、多级计算能力调度等功能。通过对仿真(或真 实)设备接入边缘云所产生的交通事件，进行融合计算，能够实现对业务时延要求相对较低的交通业务场景分析和预测，从而指导交通基础设施规划。
本申请实施例提供的模拟仿真装置能够实现图14的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
如图19所示，本申请的实施例提供一种模拟仿真装置，应用于路侧设备，包括：
第一通信模块1901，用于与边缘云建立通信，为所述边缘云提供第一数据；
第一决策模块1902，用于根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述模拟仿真装置还包括：
第二处理模块，用于通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；
第三处理模块，用于周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
可选地，所述模拟仿真装置还包括：
执行模块，用于在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的 数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
可选地，所述模拟仿真装置还包括：
检测模块，用于周期性地检查所述告警事件的有效性；
第四处理模块，用于在所述告警事件已过期的情况下，丢弃所述告警事件。
该装置，通过采用与仿真路侧设备的行为和通信方式一致的路侧SDK，使得路侧设备能够继承实现仿真路侧设备的能力，例如，仿真场景能力、边缘云通信能力和车端广播能力等，从而解决了常见的车路协同系统设计开发过程中，由于参与方众多，沟通过程冗长且充满噪音的问题，可以节约开发成本和开发周期。
本申请实施例提供的模拟仿真装置能够实现图15的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
如图20所示，本申请的实施例提供一种模拟仿真装置，应用于车载设备，包括：
第二通信模块2001，用于与边缘云建立通信，为所述边缘云提供第二数据；
第二决策模块2002，用于根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述第二通信模块2001包括：
接收子模块，用于接收核心云发送的所述边缘云的网络地址；
第一处理子模块，用于从所述网络地址中，选择与所述车载设备所在位置最近的所述网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
可选地，所述第二通信模块2001还包括：
第二处理子模块，用于根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
第三处理子模块，用于对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
上传子模块，用于根据所述第一报文，向所述边缘云上传所述第二数据。
可选地，所述第三处理子模块在用于车载设备执行所述脚本时，循环执行以下步骤：
接收其他车载设备或路侧设备播发的场景事件；
对所述场景事件进行处理；
向所述边缘云发送车辆的行驶数据和所述场景事件的处理结果。
可选地，所述车载设备每完成一条脚本的执行时，向所述边缘云发送一次执行脚本的路径；以及，每完成一次一次场景事件处理时，向所述边缘云发送一次场景事件的处理结果。
该装置，通过采用与仿真车载设备的行为和通信方式一致的车载SDK，使得车载设备能够继承实现仿真车载设备的能力，例如仿真场景能力、预警决策能力等，能够保证真实设备能够实现国标定义的17种车路协同典型应用场景，避免过于复杂的网络环境影响和硬件需求，更好的解决了车路仿真模拟系统生命周期中各方面的成本问题。
本申请实施例提供的模拟仿真装置能够实现图16的方法实施例实现的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
如图21所示，本申请的实施例提供一种通信设备，所述通信设备为边缘云2100，包括处理器2110；其中，所述处理器2110用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
可选地，还包括收发机2120，所述收发机2120用于：将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述处理器2110在根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果时，具体用于：
根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
执行所述仿真场景，得到以下至少一项：
仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
可选地，所述收发机2120还用于：将所述第一数据、所述第二数据和经过所述边缘云计算得到的路况数据发送至核心云。
可选地，所述处理器2110还用于：根据所述仿真结果，验证所述车路协同系统的业务能力。
可选地，所述处理器2110在根据所述仿真结果，验证所述车路协同系统的业务能力，具体用于：
通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相 同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
可选地，所述处理器2110还用于：收集所述配置信息；
其中，所述配置信息包括：
设备元数据；
场景元数据；
路径元数据。
可选地，所述处理器2110在用于云收集所述设备元数据时，具体用于：
收集设备初始元数据；
对所述设备初始元数据进行校验；
在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库。
可选地，所述设备初始元数据包括以下至少一项：
车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件。
可选地，所述处理器2110在用于对所述设备初始元数据进行校验时，包具体用于：
在所述设备初始元数据为车端元数据的情况下，对所述车端元数据中的所述车辆信息数据进行唯一性验证；
若所述车辆信息数据是唯一的，则验证通过。
可选地，所述处理器2110在用于对所述设备初始元数据进行校验时，具体用于：
在所述设备初始元数据为路端元数据的情况下，对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
对所述路端元数据进行校验；
若所述路端元数据满足第一预设条件，则校验通过；
其中，所述路侧设备信息为路侧交通设备的相关信息；
所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器。
可选地，所述路端元数据满足第一预设条件的情况，包括以下三项：
所述路侧设备信息和所述局部区域地图信息准确；
所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
可选地，所述处理器2110在用于对所述设备初始元数据进行校验时，具体用于：
在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件无冲突；
对所述仿真事件进行校验；
在所述仿真事件满足第二预设条件的情况下，校验通过。
可选地，所述参数包括事件级别、执行时间、周期、地点和数值。
可选地，所述仿真事件满足第二预设条件的情况，至少包括以下三项：
所述仿真事件准确；
所述仿真事件与所述设备、地图的关联关系无逻辑错误；
所述仿真事件与所述数据库中的设备元数据之间无冲突。
可选地，所述处理器2110在用于收集所述场景元数据时，包括以下至少一项：
接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过 对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧设备数据；
通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据；
通过在可视化操作界面上编辑并录入的第三脚本化数据；
其中，所述第一脚本化数据、所述第一脚本化数据和所述第一脚本化数据均为符合所述仿真场景运行的脚本化数据。
可选地，所述处理器2110在用于收集所述路径元数据时，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上对路段进行切分，形成运行点；
收集汇总所述运行点并存储，形成路径元数据。
可选地，所述处理器2110在用于在路径上对路段进行切分时，包括以下至少一项：
根据距离对路段进行均分；
根据加速度对路段进行切分；
根据角度对路段进行切分；
根据角度和加速度对路段进行切分。
可选地，所述处理器2110在用于进行场景编排时，包括：
根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
可选地，所述处理器2110在用于根据所述路径元数据与所述场景元数据，在路径上设置场景事件时，包括：
加载自定义的动态路径元数据，并通过地图界面展示规划路径；
在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
对所述场景事件进行校验；
若校验成功，则将所述场景事件加入待存储队列；
在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的所述场景事件。
可选地，所述处理器2110在用于对所述场景事件进行校验时，包括：
判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；
若不存在行为互斥，则校验通过；否则，校验失败。
可选地，所述仿真场景包括历史回放固定场景和互动融合模拟场景。
可选地，所述处理器2110在用于执行所述仿真场景时，包括：
进行场景执行引擎初始化；
根据参数配置或应用程序接口API调用，判断所述仿真场景的类型；
根据所述类型，执行所述仿真场景。
可选地，所述处理器2110在用于进行场景执行引擎初始化时，包括以下至少一项：
初始化运行所需的程序空间；
加载运行参数；
连接本地数据库、缓存或消息队列；
加载设备元数据；
初始化网络通讯链接。
可选地，所述处理器2110用于在所述类型为历史回放固定场景的情况下，执行所述仿真场景时，包括：
选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
从数据库中加载已存储的历史场景元数据；其中，所述历史场景元数据包括设备运行数据和场景录制数据；
将所述场景录制数据发送给所述设备。
可选地，所述处理器2110用于在所述类型为互动融合模拟场景的情况下，执行所述仿真场景时，包括：
根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、 所述车载设备、所述仿真路侧设备和所述仿真车载设备；
为所述设备匹配脚本化数据。
可选地，一个仿真场景与至少一个仿真设备绑定，一个仿真设备只与一个仿真场景绑定；其中，所述仿真设备包括所述仿真车载设备和所述仿真路侧设备。
可选地，所述处理器2110还用于：根据仿真结果，向所述边缘云覆盖范围内所述车载设备和/或所述仿真车载设备发送动态感知地图。
该通信设备，在边缘云上实现了设备仿真环境以对车路协同平台提供接近真实环境的路侧设备、车载设备的仿真交互，支持模拟与真实设备协同数据处理，能够为车路协同场景实现提供不易在真实世界中创造的事件和条件，降低了场景运行的成本和风险。
本申请的实施例提供一种通信设备，所述通信设备为核心云，包括处理器；其中，所述处理器用于为各区域范围内的路侧设备和车载设备接入边缘云提供路由信息。
可选地，所述处理器还用于：
与全区域范围的所述边缘云建立通信，对全区域范围的交通路况进行大数据综合分析和预测。
需要说明的是，该实施例中核心云的结构与如图21所示的边缘云的结构类似。
该通信设备，与边缘云建立通信，可以在区域、全局范围里提供相应范围的边缘协同计算调度、多级计算能力调度等功能。通过对仿真(或真实)设备接入边缘云所产生的交通事件，进行融合计算，能够实现对业务时延要求相对较低的交通业务场景分析和预测，从而指导交通基础设施规划。
如图22所示，本申请的实施例提供一种通信设备，所述通信设备为车载设备2200，包括：收发机2210和处理器2220；
其中，所述收发机2210用于与边缘云建立通信，为所述边缘云提供第二数据；
所述处理器2220用于根据所述边缘云的仿真结果作出行为决策；
其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
可选地，所述第二数据包括以下至少一项：
车辆地理位置信息；
车辆行驶状态的基础安全消息BSM；
车辆传感器数据。
可选地，所述处理器2220在用于与边缘云建立通信时，包括：
接收核心云发送的所述边缘云的网络地址；
从所述网络地址中，选择与所述车载设备所在位置最近的所述网络地址所对应的第一边缘云，并与所述第一边缘云建立连接。
可选地，所述处理器2220在用于为所述边缘云提供第二数据时，包括：
根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
根据所述第一报文，向所述边缘云上传所述第二数据。
可选地，所述处理器2220在用于执行所述脚本时，循环执行以下步骤：
接收其他车载设备或路侧设备播发的场景事件；
对所述场景事件进行处理；
向所述边缘云发送车辆的行驶数据和所述场景事件的处理结果。
可选地，所述车载设备每完成一条脚本的执行时，向所述边缘云发送一次执行脚本的路径；以及，每完成一次一次场景事件处理时，向所述边缘云发送一次场景事件的处理结果。
该通信设备，通过采用与仿真车载设备的行为和通信方式一致的车载SDK，使得车载设备能够继承实现仿真车载设备的能力，例如仿真场景能力、预警决策能力等，能够保证真实设备能够实现国标定义的17种车路协同典型应用场景，避免过于复杂的网络环境影响和硬件需求，更好的解决了车路仿真模拟系统生命周期中各方面的成本问题。
本申请的实施例提供一种通信设备，所述通信设备为路侧设备，包括处理器和收发器；
其中，所述收发机用于与边缘云建立通信，为所述边缘云提供第一数据；
所述处理器用于根据所述边缘云的仿真结果作出行为决策；
其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
可选地，所述第一数据包括以下至少一项：
路侧交通设备数据；
地图消息MAP；
交通灯相位与时序消息SPAT；
路侧交通时间消息；
路侧信息RSI；
路侧安全消息RSM。
可选地，所述处理器还用于：
通过内置的或配置的边缘云的网络地址，选择与所述路侧设备所在位置最近的所述网络地址所对应的第二边缘云，并与所述第二边缘云建立连接；
周期性地获取第二预设范围内的车载设备的列表，以及每个所述车载设备对应的通信地址，并与交通道路网络或其他设备元数据建立关联关系。
可选地，所述处理器还用于：
在预设周期内，循环执行以下步骤：
接收所述边缘云发送的告警事件，或者，根据所述路侧设备采集到的数据生成告警事件；
向第三预设范围内的车辆广播所述告警事件。
可选地，所述处理器还用于：
周期性地检查所述告警事件的有效性；
在所述告警事件已过期的情况下，丢弃所述告警事件。
该通信设备，通过采用与仿真路侧设备的行为和通信方式一致的路侧 SDK，使得路侧设备能够继承实现仿真路侧设备的能力，例如，仿真场景能力、边缘云通信能力和车端广播能力等，从而解决了常见的车路协同系统设计开发过程中，由于参与方众多，沟通过程冗长且充满噪音的问题，可以节约开发成本和开发周期。
需要说明的是，该实施例中路侧设备的结构与如图22所示的车载设备的结构类似。
为达到上述目的，本申请的实施例提供一种可读存储介质，其上存储有程序或指令，所述程序或指令被处理器执行时实现如上应用于边缘云的模拟仿真方法中的步骤，或者实现如上应用于核心云的模拟仿真方法中的步骤，或者实现如上应用于路侧设备的模拟仿真方法中的步骤，或者实现如上应用于车载设备的模拟仿真方法中的步骤。
本申请另一实施例的边缘云，如图23所示，包括收发器2310、处理器2300、存储器2320及存储在所述存储器2320上并可在所述处理器2300上运行的程序或指令；所述处理器2300执行所述程序或指令时实现上述应用于边缘云的模拟仿真方法。
所述收发器2310，用于在处理器2300的控制下接收和发送数据。
其中，在图23中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器2300代表的一个或多个处理器和存储器2320代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发器2310可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器2300负责管理总线架构和通常的处理，存储器2320可以存储处理器2300在执行操作时所使用的数据。
本申请另一实施例的核心云，其结构与如图23所示的边缘云的结构类似，包括收发器2310、处理器2300、存储器2320及存储在所述存储器2320上并可在所述处理器2300上运行的程序或指令；所述处理器2300执行所述程序或指令时实现上述应用于核心云的模拟仿真方法。
所述收发器2310，用于在处理器2300的控制下接收和发送数据。
其中，在图23中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器2300代表的一个或多个处理器和存储器2320代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发器2310可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。处理器2300负责管理总线架构和通常的处理，存储器2320可以存储处理器2300在执行操作时所使用的数据。
本申请另一实施例的一种车载设备，如图24所示，包括收发器2410、处理器2400、存储器2420及存储在所述存储器2420上并可在所述处理器2400上运行的程序或指令；所述处理器2400执行所述程序或指令时实现上述应用于车载设备的模拟仿真方法。
所述收发器2410，用于在处理器2400的控制下接收和发送数据。
其中，在图24中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器2400代表的一个或多个处理器和存储器2420代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发器2410可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。针对不同的用户设备，用户接口2430还可以是能够外接内接需要设备的接口，连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
处理器2400负责管理总线架构和通常的处理，存储器2420可以存储处理器2400在执行操作时所使用的数据。
本申请另一实施例的一种路侧设备，其结构与如图24所示的车载设备的结构类似，包括收发器2410、处理器2400、存储器2420及存储在所述存储器2420上并可在所述处理器2400上运行的程序或指令；所述处理器2400执行所述程序或指令时实现上述应用于路侧设备的模拟仿真方法。
所述收发器2410，用于在处理器2400的控制下接收和发送数据。
其中，在图24中，总线架构可以包括任意数量的互联的总线和桥，具体由处理器2400代表的一个或多个处理器和存储器2420代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口提供接口。收发器2410可以是多个元件，即包括发送机和接收机，提供用于在传输介质上与各种其他装置通信的单元。针对不同的用户设备，用户接口2430还可以是能够外接内接需要设备的接口，连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
处理器2400负责管理总线架构和通常的处理，存储器2420可以存储处理器2400在执行操作时所使用的数据。
本申请实施例的一种可读存储介质，其上存储有程序或指令，所述程序或指令被处理器执行时实现如上所述的模拟仿真方法中的步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，所述的计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等。
进一步需要说明的是，此说明书中所描述的终端包括但不限于智能手机、平板电脑等，且所描述的许多功能部件都被称为模块，以便更加特别地强调其实现方式的独立性。
本申请实施例中，模块可以用软件实现，以便由各种类型的处理器执行。举例来说，一个标识的可执行代码模块可以包括计算机指令的一个或多个物理或者逻辑块，举例来说，其可以被构建为对象、过程或函数。尽管如此，所标识模块的可执行代码无需物理地位于一起，而是可以包括存储在不同位里上的不同的指令，当这些指令逻辑上结合在一起时，其构成模块并且实现该模块的规定目的。
实际上，可执行代码模块可以是单条指令或者是许多条指令，并且甚至可以分布在多个不同的代码段上，分布在不同程序当中，以及跨越多个存储器设备分布。同样地，操作数据可以在模块内被识别，并且可以依照任何适当的形式实现并且被组织在任何适当类型的数据结构内。所述操作 数据可以作为单个数据集被收集，或者可以分布在不同位置上(包括在不同存储设备上)，并且至少部分地可以仅作为电子信号存在于系统或网络上。
在模块可以利用软件实现时，考虑到现有硬件工艺的水平，所以可以以软件实现的模块，在不考虑成本的情况下，本领域技术人员都可以搭建对应的硬件电路来实现对应的功能，所述硬件电路包括常规的超大规模集成(VLSI)电路或者门阵列以及诸如逻辑芯片、晶体管之类的现有半导体或者是其它分立的元件。模块还可以用可编程硬件设备，诸如现场可编程门阵列、可编程阵列逻辑、可编程逻辑设备等实现。
上述范例性实施例是参考该些附图来描述的，许多不同的形式和实施例是可行而不偏离本申请精神及教示，因此，本申请不应被建构成为在此所提出范例性实施例的限制。更确切地说，这些范例性实施例被提供以使得本申请会是完善又完整，且会将本申请范围传达给那些熟知此项技术的人士。在该些图式中，组件尺寸及相对尺寸也许基于清晰起见而被夸大。在此所使用的术语只是基于描述特定范例性实施例目的，并无意成为限制用。如在此所使用地，除非该内文清楚地另有所指，否则该单数形式“一”、“一个”和“该”是意欲将该些多个形式也纳入。会进一步了解到该些术语“包含”及/或“包括”在使用于本说明书时，表示所述特征、整数、步骤、操作、构件及/或组件的存在，但不排除一或更多其它特征、整数、步骤、操作、构件、组件及/或其族群的存在或增加。除非另有所示，陈述时，一值范围包含该范围的上下限及其间的任何子范围。
以上所述是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (27)

  1. 一种车路协同系统，包括：
    边缘云，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果；
    所述路侧设备，用于与所述边缘云建立通信，为所述边缘云提供所述第一数据，并根据所述仿真结果作出行为决策；
    所述车载设备，用于与所述边缘云建立通信，为所述边缘云提供所述第二数据，并根据所述仿真结果作出行为决策；
    其中，在所述边缘云上模拟仿真出的车路协同环境中，包括仿真路侧设备和仿真车载设备；所述路侧设备采用与所述仿真路侧设备的行为和通信方式一致的路侧软件开发工具包SDK，所述车载设备采用与所述仿真车载设备的行为和通信方式一致的车载SDK。
  2. 根据权利要求1所述的车路协同系统，其中，所述边缘云根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，包括：
    根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
    执行所述仿真场景，得到以下至少一项：
    所述仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
    所述仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
    车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
  3. 根据权利要求2所述的车路协同系统，其中，所述边缘云还用于：
    根据所述仿真结果，验证所述车路协同系统的业务能力；其中，所述根据所述仿真结果，验证所述车路协同系统的业务能力，包括：
    通过对比相同仿真场景下的所述第一数据和所述第一仿真数据是否相同，以及对比相同仿真场景下的所述第二数据和所述第二仿真数据是否相同，验证所述车路协同系统的业务能力。
  4. 根据权利要求1或2所述的车路协同系统，其中，所述边缘云还用于收集所述配置信息；
    其中，所述配置信息包括：
    设备元数据；
    场景元数据；
    路径元数据。
  5. 根据权利要求4所述的车路协同系统，其中，所述边缘云收集所述设备元数据，包括：
    收集设备初始元数据；
    对所述设备初始元数据进行校验；
    在校验通过的情况下，将所述设备初始元数据作为所述设备元数据存储入数据库；
    其中，所述设备初始元数据包括以下至少一项：
    车端元数据，所述车端元数据包括车辆信息数据及其相对应的车载设备数据；
    路端元数据，所述路端元数据包括路侧设备信息和局部区域地图信息；
    仿真事件元数据，所述仿真事件元数据包括人工在地图上采集的GPS点位、设备属性、运行或行驶状态和仿真事件。
  6. 根据权利要求5所述的车路协同系统，其中，所述边缘云对所述设备初始元数据进行校验，包括：
    在所述设备初始元数据为路端元数据的情况下，对所述路侧设备信息中的路侧交通设备的作用范围进行设定；
    对所述路侧交通设备的全球定位系统GPS坐标进行设定，或者，对所述路侧交通设备与地图上道路的位置关系进行设定；
    对所述路端元数据进行校验；
    若所述路端元数据满足第一预设条件，则校验通过；
    其中，所述路侧设备信息为路侧交通设备的相关信息；
    所述路侧交通设备包括以下至少一项：RSU、交通信号灯、激光雷达、毫米波雷达、高清摄像头和温湿度传感器；
    其中，所述路端元数据满足第一预设条件的情况，包括以下三项：
    所述路侧设备信息和所述局部区域地图信息准确；
    所述路侧设备信息和所述局部区域地图信息的关联关系无逻辑错误；
    所述路侧设备信息和所述局部区域地图信息与所述数据库中的设备元数据之间无冲突。
  7. 根据权利要求5所述的车路协同系统，其中，所述边缘云对所述设备初始元数据进行校验，包括：
    在所述设备初始元数据为仿真事件元数据的情况下，选择关联所述仿真事件的设备；其中，所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
    选择仿真事件的类型；其中，不同所述仿真事件的类型对应不同的所述仿真场景；
    设置所述仿真事件的参数和互斥条件；所述仿真事件基于所述互斥条件无冲突；
    对所述仿真事件进行校验；
    在所述仿真事件满足第二预设条件的情况下，校验通过；
    其中，所述参数包括事件级别、执行时间、周期、地点和数值；
    所述仿真事件满足第二预设条件的情况，至少包括以下三项：
    所述仿真事件准确；
    所述仿真事件与所述设备、地图的关联关系无逻辑错误；
    所述仿真事件与所述数据库中的设备元数据之间无冲突。
  8. 根据权利要求4所述的车路协同系统，其中，所述边缘云收集所述场景元数据，包括以下至少一项：
    接收人工上传的第一脚本化数据；其中，所述第一脚本化数据是通过对所述路侧设备和所述车载设备上传的第三数据进行筛选和处理后形成的脚本化数据；所述第三数据包括车辆的行为数据和与所述车辆相关的路侧 设备数据；
    通过所述边缘云上的车路协同平台，获取所述路侧设备和所述车载设备的第四数据，并进行处理后形成的第二脚本化数据；其中，所述第四数据包括全部的车辆和所述车辆相关的路侧设备数据；
    通过在可视化操作界面上编辑并录入的第三脚本化数据；
    其中，所述第一脚本化数据、所述第二脚本化数据和所述第三脚本化数据均为符合所述仿真场景运行的脚本化数据。
  9. 根据权利要求4所述的车路协同系统，其中，所述边缘云收集所述路径元数据，包括：
    加载自定义的动态路径元数据，并通过地图界面展示规划路径；
    在路径上对路段进行切分，形成运行点；
    收集汇总所述运行点并存储，形成路径元数据；
    其中，所述边缘云在路径上对路段进行切分，包括以下至少一项：
    根据距离对路段进行均分；
    根据加速度对路段进行切分；
    根据角度对路段进行切分；
    根据角度和加速度对路段进行切分。
  10. 根据权利要求4或8或9所述的车路协同系统，其中，所述边缘云进行场景编排，包括：
    根据所述路径元数据与所述场景元数据，在路径上设置场景事件；
    选择仿真车辆，将所述路径元数据和所述仿真车辆进行绑定。
  11. 根据权利要求10所述的车路协同系统，其中，所述边缘云根据所述路径元数据与所述场景元数据，在路径上设置场景事件，包括：
    加载自定义的动态路径元数据，并通过地图界面展示规划路径；
    在路径上设置场景事件；其中，所述场景事件是利用基础场景进行自由组合形成的；
    对所述场景事件进行校验；
    若校验成功，则将所述场景事件加入待存储队列；
    在所述路径上的所述场景事件录入完成后，存储所述待存储队列中的 所述场景事件；
    其中，所述边缘云对所述场景事件进行校验，包括：
    判断所述场景事件之间以及所述场景事件与所述路径元数据之间是否存在行为互斥；
    若不存在行为互斥，则校验通过；否则，校验失败。
  12. 根据权利要求2所述的车路协同系统，其中，所述仿真场景包括历史回放固定场景和互动融合模拟场景；
    其中，所述边缘云执行所述仿真场景，包括：
    进行场景执行引擎初始化；
    根据参数配置或应用程序接口API调用，判断所述仿真场景的类型；
    根据所述类型，执行所述仿真场景。
  13. 根据权利要求12所述的车路协同系统，其中，在所述类型为历史回放固定场景的情况下，所述边缘云执行所述仿真场景，包括：
    选择需要执行所述仿真场景的设备；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
    从数据库中加载已存储的历史场景元数据；其中，所述历史场景元数据包括设备运行数据和场景录制数据；
    将所述场景录制数据发送给所述设备。
  14. 根据权利要求12所述的车路协同系统，其中，在所述类型为互动融合模拟场景的情况下，所述边缘云所述执行所述仿真场景，包括：
    根据当前的设备的类型加载关联的场景元数据；其中，所述场景元数据包括设备基础信息和区域交通道路关系网；所述设备包括所述路侧设备、所述车载设备、所述仿真路侧设备和所述仿真车载设备；
    为所述设备匹配脚本化数据。
  15. 根据权利要求1所述的车路协同系统，其中，所述车载设备为所述边缘云提供所述第二数据，包括：
    根据SDK配置，从所述边缘云拉取对应的脚本化数据，以及
    根据SDK配置，连接对应的路侧设备，并在连接成功后从所述路侧设备接收第一报文；
    对脚本化数据进行解码，根据脚本的执行顺序和频率，依次执行所述第一报文和所述脚本；
    根据所述第一报文，向所述边缘云上传所述第二数据。
  16. 一种模拟仿真方法，应用于边缘云，包括：
    收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
  17. 根据权利要求16所述的模拟仿真方法，其中，所述根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果，包括：
    根据所述配置信息、所述第一数据和所述第二数据，进行场景编排，形成仿真场景；
    执行所述仿真场景，得到以下至少一项：
    仿真路侧设备的第一仿真数据；其中，所述第一仿真数据包括仿真交通数据、仿真MAP、仿真SPAT、仿真路侧交通时间消息、仿真RSI和仿真RSM；
    仿真车载设备的第二仿真数据；其中，所述第二仿真数据包括仿真车辆BSM和仿真车辆传感器数据；
    车辆的第三仿真数据，所述第三仿真数据包括道路事件和/或预警信息。
  18. 一种模拟仿真方法，应用于路侧设备，包括：
    与边缘云建立通信，为所述边缘云提供第一数据；
    根据所述边缘云的仿真结果作出行为决策；
    其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
  19. 一种模拟仿真方法，应用于车载设备，包括：
    与边缘云建立通信，为所述边缘云提供第二数据，并根据所述边缘云的仿真结果作出行为决策；
    其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
  20. 一种模拟仿真装置，应用于边缘云，包括：
    仿真模块，用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
  21. 一种模拟仿真装置，应用于路侧设备，包括：
    第一通信模块，用于与边缘云建立通信，为所述边缘云提供第一数据；
    第一决策模块，用于根据所述边缘云的仿真结果作出行为决策；
    其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
  22. 一种模拟仿真装置，应用于车载设备，包括：
    第二通信模块，用于与边缘云建立通信，为所述边缘云提供第二数据；
    第二决策模块，用于根据所述边缘云的仿真结果作出行为决策；
    其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
  23. 一种边缘云，包括：处理器；
    所述处理器用于收集路侧设备的第一数据和车载设备的第二数据，并根据配置信息、所述第一数据和所述第二数据，进行车路协同环境的模拟仿真，得到仿真结果。
  24. 一种路侧设备，包括：收发机和处理器；
    所述收发机用于与边缘云建立通信，为所述边缘云提供第一数据；
    所述处理器用于根据所述边缘云的仿真结果作出行为决策；
    其中，所述路侧设备采用与所述边缘云上的仿真路侧设备的行为和通信方式一致的路侧SDK。
  25. 一种车载设备，包括：收发机和处理器；
    所述收发机用于与边缘云建立通信，为所述边缘云提供第二数据；
    所述处理器用于根据所述边缘云的仿真结果作出行为决策；
    其中，所述车载设备采用与所述边缘云上的仿真车载设备的行为和通信方式一致的车载SDK。
  26. 一种通信设备，包括：收发器、处理器、存储器及存储在所述存储 器上并可在所述处理器上运行的程序或指令；所述处理器执行所述程序或指令时实现如权利要求16至17任一项所述的模拟仿真方法；或者实现如权利要求18所述的模拟仿真方法；或者实现如权利要求19所述的模拟仿真方法。
  27. 一种可读存储介质，其上存储有程序或指令，所述程序或指令被处理器执行时实现如权利要求16至17任一项所述的模拟仿真方法中的步骤，或者实现如权利要求18所述的模拟仿真方法中的步骤，或者实现如权利要求19所述的模拟仿真方法中的步骤。
PCT/CN2022/092424 2021-05-12 2022-05-12 一种车路协同系统、模拟仿真方法、车载设备和路侧设备 WO2022237866A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110517707.X 2021-05-12
CN202110517707.XA CN113256976B (zh) 2021-05-12 2021-05-12 一种车路协同系统、模拟仿真方法、车载设备和路侧设备

Publications (1)

Publication Number Publication Date
WO2022237866A1 true WO2022237866A1 (zh) 2022-11-17

Family

ID=77223100

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/092424 WO2022237866A1 (zh) 2021-05-12 2022-05-12 一种车路协同系统、模拟仿真方法、车载设备和路侧设备

Country Status (2)

Country Link
CN (1) CN113256976B (zh)
WO (1) WO2022237866A1 (zh)

Cited By (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115630583A (zh) * 2022-12-08 2023-01-20 西安深信科创信息技术有限公司 仿真车辆行驶状态的生成方法、装置、设备和介质
CN115798215A (zh) * 2023-02-03 2023-03-14 江苏天一航空工业股份有限公司 一种用于民航机场车路协同行为能力测试方法
CN115952692A (zh) * 2023-03-10 2023-04-11 腾讯科技（深圳）有限公司 道路交通的仿真方法和装置、存储介质及电子设备
CN116010039A (zh) * 2023-03-28 2023-04-25 交通运输部公路科学研究所 用于智能汽车多实体联合仿真的消息中间件集成方法
CN116033387A (zh) * 2022-11-30 2023-04-28 西部科学城智能网联汽车创新中心(重庆)有限公司 道路环境协同感知决策方法及装置
CN116110225A (zh) * 2023-03-01 2023-05-12 北京图安世纪科技股份有限公司 一种基于数字孪生的车路协同云控系统及方法
CN116229726A (zh) * 2023-05-08 2023-06-06 湖南车路协同智能科技有限公司 用于调控目标道路车辆行驶状态的车路协同方法及系统
CN116229748A (zh) * 2023-02-03 2023-06-06 河北省交通规划设计研究院有限公司 基于准全天候通行的高速公路诱导灯具控制方法和系统
CN116405905A (zh) * 2022-12-20 2023-07-07 联通智网科技股份有限公司 信息处理方法、装置、设备及存储介质
CN116414075A (zh) * 2023-06-12 2023-07-11 杭州应敏科技有限公司 一种基于物联网的实验室设备控制方法及系统
CN116449806A (zh) * 2023-06-14 2023-07-18 中汽智联技术有限公司 基于安全层信息的车辆信息融合控制功能测试方法和系统
CN116486612A (zh) * 2023-04-21 2023-07-25 清华大学 基于车路云协同的混合交通队列稳定性评价方法及装置
CN116566610A (zh) * 2023-07-06 2023-08-08 合肥工业大学 一种车联网量子密钥加密通信的仿真测试系统
CN116662140A (zh) * 2023-07-24 2023-08-29 中国人民解放军国防科技大学 一种仿真数据的自动化采集与回放方法、装置和设备
CN117094182A (zh) * 2023-10-19 2023-11-21 中汽研（天津）汽车工程研究院有限公司 V2v交通场景构建方法及v2x虚实融合测试系统
CN117319490A (zh) * 2023-10-31 2023-12-29 广东利通科技投资有限公司 一种面向智慧公路的人工智能应用协同控制系统及其方法
CN117521422A (zh) * 2024-01-05 2024-02-06 吉林省知云科技有限公司 一种基于沉浸式分队行为仿真系统及方法
CN117708999A (zh) * 2024-02-06 2024-03-15 北京航空航天大学 一种面向场景的混动汽车能量管理策略评价方法

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113256976B (zh) * 2021-05-12 2022-08-05 中移智行网络科技有限公司 一种车路协同系统、模拟仿真方法、车载设备和路侧设备
CN113642177A (zh) * 2021-08-16 2021-11-12 清华大学 数字孪生虚实多车混行仿真方法及装置
CN113553730B (zh) * 2021-09-22 2022-02-11 中国汽车技术研究中心有限公司 汽车工业多设备联调场景仿真方法、装置、设备及介质
CN114158009A (zh) * 2021-12-02 2022-03-08 新唐信通(浙江)科技有限公司 一种支持超低时延传播的路侧支撑网络系统
CN114244741B (zh) * 2021-12-16 2023-11-14 阿波罗智联(北京)科技有限公司 一种链路测试方法、装置、系统、电子设备及存储介质
CN114374624A (zh) * 2021-12-17 2022-04-19 信通院车联网创新中心(成都)有限公司 V2x路侧终端功能性信息下发功能仿真测试方法
CN114283583B (zh) * 2021-12-28 2023-08-29 阿波罗智联(北京)科技有限公司 用于车路协同的方法、车载智能终端、云控平台和系统
CN114708726B (zh) * 2022-03-18 2023-12-01 北京百度网讯科技有限公司 交通限制的处理方法、装置、设备以及存储介质
CN114428748B (zh) * 2022-03-30 2022-06-21 北京数腾软件科技有限公司 一种用于真实业务场景的模拟测试方法及系统
CN114580213B (zh) * 2022-05-05 2022-07-15 国汽智控(北京)科技有限公司 多阶段路侧仿真方法、装置、设备和存储介质
CN114579657B (zh) * 2022-05-09 2022-08-02 浙江九州云信息科技有限公司 一种基于车路协同的v2x边缘云控方法及系统
CN115277373B (zh) * 2022-06-06 2024-05-14 中智行(苏州)科技有限公司 一种基于车路协调的自动驾驶线控冗余系统
CN115440070A (zh) * 2022-07-22 2022-12-06 中智行(苏州)科技有限公司 基于车路协调的自动驾驶交通信号灯信息获取系统和方法
CN115292913A (zh) * 2022-07-22 2022-11-04 上海交通大学 一种面向车路协同的路测感知仿真系统
CN115052267B (zh) * 2022-08-12 2022-11-25 深圳市城市交通规划设计研究中心股份有限公司 微观仿真车路协同数据交互系统
CN115116231B (zh) * 2022-08-26 2023-02-03 深圳市城市交通规划设计研究中心股份有限公司 一种车路协同微观仿真系统、方法、电子设备及存储介质
CN115688484B (zh) * 2022-11-30 2023-07-25 西部科学城智能网联汽车创新中心(重庆)有限公司 一种基于WebGL的V2X仿真方法、系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107728491A (zh) * 2017-09-27 2018-02-23 重庆邮电大学 一种v2x车联网在环仿真系统
CN111897305A (zh) * 2020-06-02 2020-11-06 浙江吉利汽车研究院有限公司 一种基于自动驾驶的数据处理方法、装置、设备及介质
US20200409369A1 (en) * 2019-06-25 2020-12-31 Uatc, Llc System and Methods for Autonomous Vehicle Testing
CN112671487A (zh) * 2019-10-14 2021-04-16 大唐移动通信设备有限公司 一种车辆测试的方法、服务器以及测试车辆
CN113256976A (zh) * 2021-05-12 2021-08-13 中移智行网络科技有限公司 一种车路协同系统、模拟仿真方法、车载设备和路侧设备

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102999041B (zh) * 2012-11-21 2015-10-28 上海富欣智能交通控制有限公司 适用于列车自动控制系统atc的环境仿真器
CN104463492B (zh) * 2014-12-23 2017-12-26 国家电网公司 一种电力系统云仿真平台的运营管理方法
US10303817B2 (en) * 2015-07-21 2019-05-28 Tata Elxsi Limited System and method for enhanced emulation of connected vehicle applications
US10877476B2 (en) * 2017-11-30 2020-12-29 Tusimple, Inc. Autonomous vehicle simulation system for analyzing motion planners
AT520781A2 (de) * 2017-12-22 2019-07-15 Avl List Gmbh Verhaltensmodell eines Umgebungssensors
CN111123735B (zh) * 2018-10-31 2022-09-09 百度在线网络技术（北京）有限公司 自动驾驶仿真运行方法和装置
US20200226225A1 (en) * 2019-01-10 2020-07-16 Uber Technologies, Inc. Offboard Vehicle Service Testing System
US11599103B2 (en) * 2019-02-21 2023-03-07 Dodge Industrial, Inc. Method and system for data driven machine diagnostics
CN111061167B (zh) * 2019-12-26 2022-07-22 清华大学苏州汽车研究院（相城） 一种面向智能网联示范区的混合现实自动驾驶的测试方法及虚拟测试平台
CN111625939B (zh) * 2020-05-12 2023-09-01 招商局检测车辆技术研究院有限公司 车路协同应用的规模测评系统及方法
CN112631912A (zh) * 2020-12-23 2021-04-09 北京百度网讯科技有限公司 基于车联网的仿真方法、装置、设备以及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107728491A (zh) * 2017-09-27 2018-02-23 重庆邮电大学 一种v2x车联网在环仿真系统
US20200409369A1 (en) * 2019-06-25 2020-12-31 Uatc, Llc System and Methods for Autonomous Vehicle Testing
CN112671487A (zh) * 2019-10-14 2021-04-16 大唐移动通信设备有限公司 一种车辆测试的方法、服务器以及测试车辆
CN111897305A (zh) * 2020-06-02 2020-11-06 浙江吉利汽车研究院有限公司 一种基于自动驾驶的数据处理方法、装置、设备及介质
CN113256976A (zh) * 2021-05-12 2021-08-13 中移智行网络科技有限公司 一种车路协同系统、模拟仿真方法、车载设备和路侧设备

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116033387B (zh) * 2022-11-30 2023-08-25 西部科学城智能网联汽车创新中心(重庆)有限公司 道路环境协同感知决策方法及装置
CN116033387A (zh) * 2022-11-30 2023-04-28 西部科学城智能网联汽车创新中心(重庆)有限公司 道路环境协同感知决策方法及装置
CN115630583A (zh) * 2022-12-08 2023-01-20 西安深信科创信息技术有限公司 仿真车辆行驶状态的生成方法、装置、设备和介质
CN116405905B (zh) * 2022-12-20 2024-01-30 联通智网科技股份有限公司 信息处理方法、装置、设备及存储介质
CN116405905A (zh) * 2022-12-20 2023-07-07 联通智网科技股份有限公司 信息处理方法、装置、设备及存储介质
CN115798215A (zh) * 2023-02-03 2023-03-14 江苏天一航空工业股份有限公司 一种用于民航机场车路协同行为能力测试方法
CN116229748A (zh) * 2023-02-03 2023-06-06 河北省交通规划设计研究院有限公司 基于准全天候通行的高速公路诱导灯具控制方法和系统
CN116229748B (zh) * 2023-02-03 2024-01-19 河北省交通规划设计研究院有限公司 基于准全天候通行的高速公路诱导灯具控制方法和系统
CN116110225A (zh) * 2023-03-01 2023-05-12 北京图安世纪科技股份有限公司 一种基于数字孪生的车路协同云控系统及方法
CN115952692A (zh) * 2023-03-10 2023-04-11 腾讯科技（深圳）有限公司 道路交通的仿真方法和装置、存储介质及电子设备
CN116010039A (zh) * 2023-03-28 2023-04-25 交通运输部公路科学研究所 用于智能汽车多实体联合仿真的消息中间件集成方法
CN116486612B (zh) * 2023-04-21 2023-12-26 清华大学 基于车路云协同的混合交通队列稳定性评价方法及装置
CN116486612A (zh) * 2023-04-21 2023-07-25 清华大学 基于车路云协同的混合交通队列稳定性评价方法及装置
CN116229726B (zh) * 2023-05-08 2023-08-08 湖南车路协同智能科技有限公司 用于调控目标道路车辆行驶状态的车路协同方法及系统
CN116229726A (zh) * 2023-05-08 2023-06-06 湖南车路协同智能科技有限公司 用于调控目标道路车辆行驶状态的车路协同方法及系统
CN116414075B (zh) * 2023-06-12 2023-08-18 杭州应敏科技有限公司 一种基于物联网的实验室设备控制方法及系统
CN116414075A (zh) * 2023-06-12 2023-07-11 杭州应敏科技有限公司 一种基于物联网的实验室设备控制方法及系统
CN116449806A (zh) * 2023-06-14 2023-07-18 中汽智联技术有限公司 基于安全层信息的车辆信息融合控制功能测试方法和系统
CN116449806B (zh) * 2023-06-14 2023-09-01 中汽智联技术有限公司 基于安全层信息的车辆信息融合控制功能测试方法和系统
CN116566610A (zh) * 2023-07-06 2023-08-08 合肥工业大学 一种车联网量子密钥加密通信的仿真测试系统
CN116566610B (zh) * 2023-07-06 2023-09-29 合肥工业大学 一种车联网量子密钥加密通信的仿真测试系统
CN116662140A (zh) * 2023-07-24 2023-08-29 中国人民解放军国防科技大学 一种仿真数据的自动化采集与回放方法、装置和设备
CN116662140B (zh) * 2023-07-24 2023-10-03 中国人民解放军国防科技大学 一种仿真数据的自动化采集与回放方法、装置和设备
CN117094182A (zh) * 2023-10-19 2023-11-21 中汽研（天津）汽车工程研究院有限公司 V2v交通场景构建方法及v2x虚实融合测试系统
CN117094182B (zh) * 2023-10-19 2024-03-12 中汽研（天津）汽车工程研究院有限公司 V2v交通场景构建方法及v2x虚实融合测试系统
CN117319490A (zh) * 2023-10-31 2023-12-29 广东利通科技投资有限公司 一种面向智慧公路的人工智能应用协同控制系统及其方法
CN117319490B (zh) * 2023-10-31 2024-04-16 广东利通科技投资有限公司 一种面向智慧公路的人工智能应用协同控制系统及其方法
CN117521422A (zh) * 2024-01-05 2024-02-06 吉林省知云科技有限公司 一种基于沉浸式分队行为仿真系统及方法
CN117708999A (zh) * 2024-02-06 2024-03-15 北京航空航天大学 一种面向场景的混动汽车能量管理策略评价方法
CN117708999B (zh) * 2024-02-06 2024-04-09 北京航空航天大学 一种面向场景的混动汽车能量管理策略评价方法

Also Published As

Publication number Publication date
CN113256976B (zh) 2022-08-05
CN113256976A (zh) 2021-08-13

Similar Documents

Publication Publication Date Title
WO2022237866A1 (zh) 一种车路协同系统、模拟仿真方法、车载设备和路侧设备
Faria et al. Smart mobility: A survey
Astarita et al. The use of adaptive traffic signal systems based on floating car data
US11550623B2 (en) Distributed system task management using a simulated clock
US11480964B2 (en) Distributed system execution using a serial timeline
WO2019042592A1 (en) METHOD, DEVICES AND SYSTEM FOR CONTROLLING VEHICLE
US11409927B2 (en) Architecture for configurable distributed system simulation timing
CN112839319A (zh) 蜂窝车联网信息处理方法、装置、系统、终端及存储介质
Al-Turjman et al. Overview of IoT Solutions for Sustainable Transportation Systems
US11809790B2 (en) Architecture for distributed system simulation timing alignment
US11397610B2 (en) Architecture for simulation clock-based simulation of distributed systems
Shankaran et al. Intelligent Transport Systems and Traffic Management
WO2020248136A1 (zh) 用于驾驶控制的方法、装置、设备、介质和系统
Kanchanasut et al. Internet of cars through commodity V2V and V2X mobile routers: applications for developing countries
Gibaud et al. Foresee, a fully distributed self-organized approach for improving traffic flows
US11669657B2 (en) Architecture for distributed system simulation with realistic timing
Cui et al. C-v2x vision in the chinese roadmap: Standardization, field tests, and industrialization
Blokpoel et al. Cooperative systems for future automated road transport and traffic management in urban areas
Elbery Large-scale modeling of smart cities considering the mutual impact of transportation and communication systems
Fernandes Large-scale simulation of vehicular ad hoc networks
EP4167606A1 (en) Cooperative intelligent transport system and method with cpm area perception request
Abdo et al. Cyber-security oriented co-simulation platform for connected and autonomous driving
Singh et al. An Intelligent Transportation System for Traffic Management Over the Iot
Khamari Architectures and Protocols for Connected Vehicles
Renjifo Herrera Simulation of basic multi-hop broadcast techniques in vehicular Ad-Hoc networks using veins simulator

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22806828

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22806828

Country of ref document: EP

Kind code of ref document: A1