Automatic driving simulation method and device, computer equipment and storage medium

Abstract

The invention discloses an automatic driving simulation method and device, computer equipment and a storage medium, and relates to the technical field of vehicle simulation. The method comprises the following steps: receiving a simulation instruction; and calling a driving simulation module corresponding to the simulation instruction for simulation through a plurality of preset callback interfaces to obtain simulation result data, the driving simulation module being designed based on the plurality of preset callback interfaces. Namely, a plurality of preset callback interfaces are provided, any driving simulation module can be developed and designed based on the preset callback interface, the problem that software is coupled but interfaces are not matched in an existing simulation system is solved, the convenience and efficiency of algorithm development are improved, and the driving simulation system is suitable for being developed and designed. According to the invention, the plurality of preset callback interfaces are uniformly and synchronously called to carry out driving simulation, so that the problem of mutual calling confusion caused by scheduling logic due to a complex calling process is reduced, the test complexity is reduced, and the simulation effect of the simulation test is guaranteed.

Description

Technical Field

[0001] This application relates to the technical field of vehicle simulation, and in particular, to an autonomous driving simulation method, apparatus, computer device, and storage medium. Background Art

[0002] With the rapid development of control algorithm research and scenario applications in the field of autonomous driving, the requirements for the safety and stability of the control system for realizing autonomous driving are becoming increasingly specific, and a large number of tests are required to verify this.

[0003] Autonomous driving simulation tests cover many test processes such as Model In the Loop (MIL), Software In the Loop (SIL), Processor In the Loop (PIL), and Hardware In the Loop (HIL). Moreover, there are many algorithm modules in the autonomous driving system. Each module is independently developed by different algorithm teams on different platform systems and then integrated and coupled for testing. The operating mechanisms and data interfaces provided on different platform systems are different from each other, resulting in problems such as synchronous scheduling during integration testing and increasing the difficulty of integration testing. Summary of the Invention

[0004] This application proposes an autonomous driving simulation method, apparatus, computer device, and storage medium to ensure the simulation effect of autonomous driving simulation tests.

[0005] In a first aspect, an embodiment of this application provides an autonomous driving simulation method, and the method includes: receiving a simulation instruction; and by means of a plurality of preset callback interfaces, calling a driving simulation module corresponding to the simulation instruction for simulation to obtain simulation result data, where the driving simulation module is designed based on the plurality of preset callback interfaces.

[0006] In a second aspect, an embodiment of this application provides an autonomous driving simulation apparatus, and the apparatus includes: an instruction receiving module and a simulation calling module. Among them, the instruction receiving module is used to receive a simulation instruction; the simulation calling module is used to call a driving simulation module corresponding to the simulation instruction for simulation through a plurality of preset callback interfaces to obtain simulation result data, where the driving simulation module is designed based on the plurality of preset callback interfaces.

[0007] In a third aspect, an embodiment of this application provides a computer device, including: one or more processors; a memory; one or more programs, where the one or more programs are stored in the memory and are configured to be executed by the one or more processors, and the one or more programs are configured to execute the above method.

[0008] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which program code is stored, and the program code can be called by a processor to execute the above method.

[0009] In the solution provided by the present application, a simulation instruction is received; through a plurality of preset callback interfaces, a driving simulation module corresponding to the simulation instruction is called for simulation to obtain simulation result data, and the driving simulation module is designed based on the plurality of preset callback interfaces. That is to say, the present application provides a plurality of preset callback interfaces, and any driving simulation module can be developed and designed based on the preset callback interfaces, solving the problem of software coupling in the current simulation system but incompatible interfaces, improving the convenience and efficiency of algorithm development. And different driving simulation modules can be uniformly and synchronously called through a plurality of preset callback interfaces during the driving simulation process, reducing the complex calling process, solving the problem of mutual calling chaos caused by the need to add other interfaces when the requirements increase in the prior art, and other modules also need to adapt to develop interfaces and scheduling logic, reducing the complexity of testing and ensuring the simulation effect of the simulation test; at the same time, it also greatly reduces the coupling degree between modules, that is, realizes distributed decoupling, making the environmental requirements of the simulation test more flexible. BRIEF DESCRIPTION OF THE DRAWINGS <(

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the following drawings are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0011] Figure 1 FIG. shows a schematic flowchart of an autonomous driving simulation method provided by an embodiment of the present application.

[0012] Figure 2 FIG. shows a schematic architecture diagram of a simulation system provided by an embodiment of the present application.

[0013] Figure 3 FIG. shows a schematic flowchart of an autonomous driving simulation method provided by another embodiment of the present application.

[0014] Figure 4 FIG. shows another schematic architecture diagram of a simulation system provided by an embodiment of the present application.

[0015] Figure 5 FIG. shows a simulation timing diagram of an autonomous driving simulation method provided by an embodiment of the present application.

[0016] Figure 6 FIG. shows Figure 3Flow schematic diagram of sub-steps in step S220 in one embodiment.

[0017] Figure 7 Shows Figure 3 Flow schematic diagram of sub-steps in step S230 in one embodiment.

[0018] Figure 8 Is a block diagram of an autonomous driving simulation device provided according to an embodiment of the present application.

[0019] Figure 9 Is a block diagram of a computer device for executing the autonomous driving simulation method according to an embodiment of the present application.

[0020] Figure 10 Is a storage unit for storing or carrying program codes for implementing the autonomous driving simulation method according to an embodiment of the present application. Detailed implementation manners

[0021] In order to enable those skilled in the art to better understand the solution of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0022] It should be noted that in some processes described in the specification, claims and the above-mentioned drawings of the present application, a plurality of operations that appear in a specific order are included. These operations may not be executed in the order in which they appear in this article or may be executed in parallel. The serial numbers of the operations, such as S110, S120, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. Also, the terms "first", "second", etc. in the specification, claims and the above-mentioned drawings of the present application are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or server that includes a series of steps or sub-modules does not necessarily have to be limited to those steps or sub-modules clearly listed, but may include other steps or sub-modules that are not clearly listed or are inherent to these processes, methods, products or devices.

[0023] The inventor proposes an autonomous driving simulation method, device, computer device, and storage medium. The following will provide a detailed description of the autonomous driving simulation method provided in the embodiments of the present application.

[0024] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of an autonomous driving simulation method provided in an embodiment of the present application. The following will elaborate on the autonomous driving simulation method provided in the embodiments of the present application in conjunction with Figure 1 The autonomous driving simulation method may include the following steps:

[0025] Step S110: Receive a simulation instruction.

[0026] In this embodiment, the user can input a simulation instruction through the simulation interaction interface of the simulation software to initiate a simulation test corresponding to the driving simulation module to be tested. Specifically, the simulation interaction interface can implement at least one of the following functions through corresponding controls, windows, dialog boxes, etc.: receiving simulation elements input by the user in a text input manner, providing an expandable menu bar to receive the user's selection of simulation elements in the menu bar, providing an interaction box for the user to input or select each simulation element step by step through interaction steps, providing controls for file upload or download to enable the user to upload or download files, etc. Further, after the user inputs / selects the simulation elements and the files uploaded / downloaded, and inputs the simulation instruction, a confirmation operation can be performed. Correspondingly, the simulation system receives the simulation instruction input by the user. The simulation elements include, but are not limited to, simulation type, simulation software, simulation project, control model, use case script, simulation rate, whether to display the simulation animation, and whether to save the simulation animation. The simulation type includes, but is not limited to, Model-in-the-Loop (MIL) simulation test, Software-in-the-Loop (SIL) simulation test, Processor-in-the-Loop (PIL) simulation test, and Hardware-in-the-Loop (HIL) simulation test.

[0027] Step S120: Call the driving simulation module corresponding to the simulation instruction through multiple preset callback interfaces to perform a simulation and obtain simulation result data. The driving simulation module is designed based on the multiple preset callback interfaces.

[0028] Please refer to Figure 2 , Figure 2The system architecture diagram of the aforementioned simulation system 10 is shown. The simulation system 10 may include a simulation scheduling engine, a traffic flow simulation unit, a dynamics simulation unit, and an algorithm unit to be tested. The algorithm unit to be tested may include at least one of a planning algorithm, a control algorithm, and other algorithms, that is, the algorithm unit to be tested may be regarded as an algorithm related to autonomous driving; the planning algorithm is used to plan the driving path of the vehicle, and the control algorithm is used to output corresponding control parameters according to the planned driving path, such as driving parameters, braking parameters, or steering parameters. The aforementioned driving simulation module generally includes Figure 2 The traffic flow simulation unit, dynamics simulation unit and algorithm unit to be tested.

[0029] In this embodiment, multiple preset callback interfaces include a parameter initialization (Init) callback interface, a scene initialization (Reset) callback interface, a single-step operation (Step) callback interface, and a stop operation (Stop) callback interface, wherein the callback interface is essentially an abstract callback Callback method. Any driving simulation module mentioned in this application can be designed and developed based on a software development kit (Software Development Kit, SDK), wherein the SDK contains the code of each of the aforementioned preset callback interfaces compiled into a static library or a dynamic library, and the SDK also contains a data interaction protocol, which includes a transmission control protocol (Transmission Control Protocol, TCP) and a shared memory communication interface, so that the simulation module developed based on the SDK can interact with the simulation scheduling engine for data. In addition, the business content and usage method of each preset callback interface are explained in the SDK.

[0030] Understandably, when developers design and develop further simulation modules based on this SDK, they inherit the SimModule type and write algorithmic business code within its four defined callback interface functions at the code level, implementing data interaction with the simulation scheduling system through helpers. This eliminates the need for developers to focus on the underlying communication implementation, solely on the business processes of the simulation module itself, improving development efficiency.

[0031] Furthermore, after receiving the simulation instruction, the simulation scheduling engine can call the driving simulation module corresponding to the simulation instruction through multiple preset callback interfaces to perform simulation and obtain simulation result data. That is, by calling the aforementioned four callback interfaces in the driving simulation module, the corresponding simulation business process is triggered, thereby obtaining the corresponding simulation result data.

[0032] It should be noted that for the simulation of the SIL type, the simulation system 10 is deployed on the same computer device, that is, Figure 2 the simulation scheduling engine, traffic flow simulation unit, dynamic simulation unit, and the algorithm unit to be tested in Figure 2 can all be deployed on the same computer device. For the distributed type of simulation, such as the PIL type of simulation, the simulation system 10 may only include Figure 2 the simulation scheduling engine, traffic flow simulation unit, and dynamic unit in

[0033] The algorithm unit to be tested in

[0034] is deployed on the vehicle controller, while the simulation system 10 can be deployed on another computer device. That is to say, this application supports both the access of the algorithm unit to be tested on the same machine and the same platform, and the access of the algorithm unit to be tested across platforms and machines. There is no complex system message data adaptation process, and it can meet the business requirements of both SIL and PIL simulations simultaneously. It can be understood that for the distributed type of simulation, data interaction can be based on TCP. Figure 3 , Figure 3 Please refer to Figure 3 which is a schematic flowchart of an autonomous driving simulation method provided in another embodiment of this application. The autonomous driving simulation method provided in this application will be elaborated in detail below in combination with

[0035] Step S210: Receive a simulation instruction.

[0036] Step S220: Initialize the parameters of the driving simulation module based on the parameter initialization interface function.

[0037] In this embodiment, it can be applied to the aforementioned simulation system 10, which will not be elaborated one by one here. It can be understood that before step S210, that is, before the start of the autonomous driving simulation process, it is first necessary to complete the construction of the simulation system, complete the implementation and compilation of the business code of the algorithm unit to be tested, prepare the simulation files, and load and access the algorithm unit to be tested.

[0038] For ease of subsequent understanding, first, a description is provided for multiple preset callback interfaces in the SDK provided by the simulation system 10. The multiple preset callback interfaces at least include an initialization (Init) callback interface function, a scenario initialization (Reset) callback interface function, a single-step execution (Step) callback interface function, and a run stop (Stop) callback interface function; and corresponding helper classes are provided as interface parameters to be passed to the algorithm unit under test for use, such as InitHelper, ResetHelper, StepHelper, and StopHelper, to provide interface implementations for some simulation information.

[0039] The initialization (Init) callback interface function is a customized initialization process implemented by the simulation system 10 by calling the Init method of each driving simulation module. Each driving simulation module can obtain any parameters required for its own module initialization through the InitHelper object passed in by the simulation system 10, and then perform corresponding initialization operations. The InitHelper object can include a parameter acquisition parameter interface, a publish message interface, a publish shared memory message interface, a subscribe message, and a subscribe shared memory message interface.

[0040] Among them, the parameter acquisition parameter interface can be used to obtain the key-value pairs of configuration initialization parameters. The publish (Publish) message interface is used to register the topics that the current module needs to publish with the simulation system 10. Only the topics registered through this method can later publish the message content of the corresponding topic to other driving simulation modules through the StepHelper::PublishMessage method. Otherwise, other driving simulation modules will not receive the corresponding messages. Multiple modules cannot publish messages to the same topic, otherwise the system will prompt an error. The subscribe (Subscribe) message interface is used to subscribe to the topics required by its own module with the simulation registration 10. Only the subscriptions registered through this method can later obtain the message content of the corresponding topic through the StepHelper::GetSubscribedMessage method. Otherwise, the returned message content is an empty string. If no module in the current system publishes this topic, the system will report an error and prompt.

[0041] The SubscribeShmem interface is the same as the Subscribe message interface, but the SubscribeShmem interface can specify that the data corresponding to the topic is obtained from shared memory instead of being transmitted through the default TCP communication. The mapping operation for the specified shared memory is deferred until before the SimModule::Reset method is called. If the mapping fails, the system will report an error. The PublishShmem interface is the same as the Publish message interface, but the PublishShmem interface can specify that the data corresponding to the topic is written to shared memory instead of being transmitted through the default TCP communication. After calling this method, the simulation system 10 will later attempt to apply to the operating system for shared memory of the corresponding size (if there is no corresponding shared memory resource in the system) and initialize it (clear all bytes). If there is any failure, the system will report an error. This shared memory will be destroyed after all modules that reference it have exited normally.

[0042] The Reset callback interface function is the interface function called by the driving simulation module when resetting the scenario in the simulation system 10, that is, it can also be understood as the interface function called when the scenario needs to be initialized. The Reset callback interface function can obtain some basic information in the current simulation scenario through the parameter Helpe object. For example, the map file path corresponding to the current simulation scenario, the start and end point information of the host vehicle, etc. This method is generally called after calling the Init callback interface or the Stop callback interface. ResetHelper is the helper type initialized by the simulation system 10 before calling this method and passed in, providing some APIs required for any driving simulation module to load the scenario. In ResetHelper, APIs can be used to obtain the current map path, the origin of the scenario map, the end point of the host vehicle, the start point of the host vehicle, the location of the scenario file, etc.

[0043] Exemplarily, the get_map_file_path interface for obtaining the map file path corresponding to the current simulation scenario. The map_local_origin interface for obtaining the recommended origin of the map corresponding to the current simulation scenario. The positions in the obstacle and ego vehicle information that can be emitted in the simulation system generally adopt the form of longitude and latitude. Through this origin, these longitude and latitude coordinates can be conveniently converted into a local coordinate system for calculation, and the origin coordinates (longitude - latitude - altitude) of the map corresponding to the current scenario are returned. The ego_destination interface for obtaining the end position (longitude and latitude) of the ego vehicle in the current simulation scenario. The ego_start_location interface for obtaining the initial positioning information of the ego vehicle in the current simulation scenario. The scenario_file_path interface for obtaining the scenario file path corresponding to the current scenario.

[0044] The Step callback interface function is a method called when the driving simulation module conducts simulation in the simulation system. The simulation system advances the simulation scenario by continuously calling the Step callback interfaces of each driving simulation module. The simulation system will call the Step callback interface of the simulation driving module once every step_time (milliseconds, simulation / logical time) according to the configured call frequency (1 / step_time) of each module. When calling, the time information of the current simulation system can be obtained through the parameter helper object. All calculations in the algorithm should be based on this simulation time information rather than the real physical time (e.g., Beijing time). The StepHelper can include functions such as the interface function for obtaining subscribed messages, the interface function for publishing messages, the interface function for subscribing to memory data (shared memory), the interface function for publishing memory data (shared memory), the interface function for stopping the simulation scenario, the interface function for obtaining the system time, and the interface function for obtaining the simulation system time. It should be noted that the call step length (step_time) of all driving simulation modules should be a common multiple of the system-set step length. If the system-set step length s(tep_time) is 10ms, then the step lengths of the corresponding driving simulation modules should be multiples of 10ms such as 10ms, 20ms, 30ms, etc., to ensure the synchronization of the state calculations of each driving simulation module.

[0045] Among them, the GetSubscribedMessage interface function is used to obtain the message content subscribed by the current driving simulation module. How to parse the message content depends on how the module that publishes the message encodes the message, which is the string or serialized byte array corresponding to the topic built into the simulation system. The PublishMessage interface function is used to publish messages to the simulation system so that other driving simulation modules can obtain this message, and only the messages corresponding to the topics registered through InitHelper::Publish can be published to the simulation system. Similarly, the published message content can be a string or a serialized byte array. The StopScenario interface function is used to notify the simulation system to stop the current scenario. Generally, the simulation system will not actively end a certain scenario. Usually, it is determined by the user algorithm when to stop the current scenario. For example, the host vehicle reaches the end point set in the current scenario, or other reasons cause the algorithm to think that the current scenario cannot continue to run (an accident occurs, there is no optional path, etc.).

[0046] The timestamp interface function for obtaining the current simulation system time is used to obtain the current simulation system timestamp, unit: millisecond. This timestamp represents the time that the current simulation scenario has run, which belongs to logical (virtual) time and is different from the real physical time. The current_timestamp interface function for obtaining the physical machine system time is used to obtain the timestamp of the Coordinated Universal Time (UTC) in the current system, unit: millisecond (ms). The GetSubscribedShmemData interface function is similar to the GetSubscribedMessage interface function. However, the GetSubscribedShmemData interface function obtains data from the corresponding shared memory. The GetPublishedShmemBuffer interface function for obtaining the shared memory address of the published message is used to obtain the starting address of the shared memory corresponding to the topic to be published, and the returned memory address pointer is used to write the data to be published.

[0047] The Run Stop callback interface function is a method called by the driving simulation module when the simulation system ends the simulation scenario. This Stop callback interface function is mainly used to collect some custom feedback information from each simulation driving module about the current scenario operation and dispatch it to the simulation system. StopHelper is a helper type initialized and passed in by the simulation system before calling this method, providing some APIs required by each driving simulation module when the simulation scenario ends. StopHelper implements the set_feedback interface for returning status data, and feeds back some statistical information about the current scenario operation to the simulation system in the form of key-value pairs for display on the front-end interface of the simulation software. Of course, whether to call the set_feedback interface to feed back the statistical information to the front-end interface for display can be adjusted according to actual needs, and this embodiment does not limit this. Among them, the statistical information includes but is not limited to information such as the scenario operation duration in the simulation scenario, the driving distance of the host vehicle, the number of vehicle collisions, and the number of times the vehicle violates traffic rules, etc.

[0048] Furthermore, after completing the construction of the simulation system, further implement and compile the business code of the algorithm unit to be tested. That is, developers can, based on the aforementioned SDK, enable the algorithm unit to be tested to write algorithm business code at the code level by inheriting the SimModule type and writing in the 4 callback interfaces defined by it, and realize data interaction with the simulation scheduling engine through the helper. During the simulation process, the simulation scheduling engine triggers relevant algorithm business processes by calling the four basic callback interfaces in each algorithm unit. Optionally, after the business code is implemented, the algorithm in the algorithm unit to be tested can be compiled into a dynamic library (so / dll), and then loaded by the simulation system, and the corresponding interface functions implemented by each algorithm unit to be tested are called at runtime to execute the corresponding user algorithm logic. This method only requires developers to add the simulation header files to the code project and does not require additional linking of any simulation dependent libraries, which is convenient to operate. Optionally, developers can also compile the algorithm business code of the algorithm unit to be tested into an executable file (binary / exe). In this method, in addition to adding the simulation-related header files, it is also necessary to additionally link the dynamic library of the simulation system.

[0049] It should be noted that if the algorithm business code of the algorithm unit to be tested needs to be compiled into an executable file, a SimMoudleService class also needs to be created. This class provides at least three interface functions, namely Serve (service startup), Wait (service waiting), and ShutDonwn (service shutdown). This class initializes the service thread of the current simulation module to connect the currently implemented SimModule to the simulation system. The Serve interface is used to start the service of the current algorithm unit to be tested. Only after this interface is called can the driving simulation module be recognized by the simulation system. This method will return immediately, and the interface parameters are the name of the simulation module, the instance of the simulation module, and the network IP address of the machine where the simulation scheduling engine runs. The Wait interface is used to block the current thread and wait for the service of the current simulation module to stop. The service will only stop when a simulation service error occurs, an interrupt signal is received, or another thread calls Shutdown. The ShutDown interface is used to notify the service of the current driving simulation module to stop. This method will return immediately after sending the stop signal. When the service of the current driving simulation module actually stops needs to wait for the Wait method to return.

[0050] Then, the simulation personnel upload the simulation files required for the current simulation scenario to the simulation system. The upload methods include but are not limited to directly placing the simulation files under the corresponding computer file address or database, or uploading the files to the corresponding file address or database through the simulation interaction interface of the simulation software. Among them, the simulation files at least include simulation scenario files and simulation map files; the simulation scenario files at least include information such as the parameters, motion behaviors, and simulation duration of the main vehicle and traffic participants in the simulation, and the simulation map files at least include information such as the topological structure, geometric parameters, and static facilities of the simulation road network.

[0051] Furthermore, the algorithm unit to be tested can be connected to the simulation system where the simulation scheduling engine is located by using the set algorithm access method. Among them, the set algorithm access methods include but are not limited to direct algorithm access, docker access, and adapter conversion access, etc. Of course, developers can choose different set algorithm access methods according to different application scenarios.

[0052] Optionally, in the direct algorithm access mode, developers can encapsulate the autonomous driving algorithm in the algorithm unit to be tested into a dynamic library or an executable program based on the SDK mentioned above, and it can run on the local machine or different machines and platforms. If it runs on the same machine, it supports both dynamic link library loading and calling as well as callback as an algorithm service; if the algorithm unit to be tested and the simulation system are in the same local area network but not on the same host, the algorithm needs to be started manually. During the manual startup process of the algorithm, the corresponding module name, the IP address and port number of the computer where the simulation system is located are input, and then registration and connection are performed, waiting for communication callback. It should be noted that the communication connection between the algorithm unit to be tested and the simulation system is not limited to being established through a local area network. This communication connection can also be other network connections; however, considering that in practical applications, factors such as network latency, transmission rate, and data security may exist, generally, a local area network connection is still selected as the aforementioned communication connection to ensure the synchronization and data security of data interaction between the algorithm unit to be tested and the simulation system.

[0053] Optionally, in the docker access mode, in some scenarios, the configuration environment of the algorithm unit to be tested is relatively complex and needs to be deployed based on docker. After the algorithm unit to be tested accesses the SDK, it can also run in docker. However, the algorithm in docker can only be made into an executable program. After docker is started, the module name, as well as the host and fixed port number of the computer where the simulation system is located, are input, and then registration and connection are performed, waiting for communication callback.

[0054] Optionally, in the adapter conversion access mode, refer to Appendix Figure 4 , this usage scenario is applicable when there are significant differences between the algorithm running environment or the data structure used and the internal data structure of the simulation system. For example, various algorithms to be tested in the algorithm unit to be tested run in the Robot Operating System (ROS) environment, and the algorithm itself has a set of data structures. If accessed according to the aforementioned two access methods, it will cause significant changes to the algorithm under test. Based on this, an adapter can be written at this time for data conversion. This adapter uses the SDK to access the simulation system in the form of an executable program, and at the same time uses the ROS SDK as a node of ROS. The adapter is responsible for forwarding and data conversion of the messages between the simulation system and the algorithm unit to be tested.

[0055] For ease of explanation, this embodiment will be combined with Figure 5The following is an explanation of the simulated timing diagram shown. Before the simulation, the driving simulation modules designed based on the aforementioned SDK (for example, the dynamics simulation module, the traffic flow simulation module, and the algorithm unit to be tested) all need to register with the simulation scheduling engine. Registration can be understood as enabling the simulation scheduling engine to identify and know which driving simulation modules can be called and enter a state of waiting to be scheduled. In some embodiments, the simulation scheduling engine can read the configuration file information corresponding to the driving simulation module. The configuration file information at least includes the module identifier, the absolute path, and the module operation parameters of the driving simulation module; and store the configuration file information in the simulation registry. In this way, the driving simulation module can be directly loaded and called by the simulation scheduling engine through dynamic linking.

[0056] In other embodiments, the driving simulation module can be indirectly called by the simulation scheduling engine; in this way, it is necessary to first run the simulation scheduling engine in the simulation system, and then run the driving simulation module. When the driving simulation module is initialized, it will initialize SimMoudleService and call the serve interface. By passing in the module name, the instantiated algorithm module object, the Internet Protocol Address (IP address) and port number of the running machine where the simulation system is located, and then establish a network communication connection to complete the registration of the driving simulation module to the simulation scheduling engine. It should be noted that if the driving simulation module runs in docker, the simulation scheduling engine also needs to obtain the mirror address of the docker where the driving simulation module runs, the shell file for the mirror to run, and the system directory address where the driving simulation module is located after running in docker during registration.

[0057] It can be understood that after each driving simulation module completes registration with the simulation scheduling engine, the simulation system where the simulation scheduling engine is located can, as described in step S210, call the registered driving simulation modules based on the received simulation instruction input by the user to implement the simulation test under the simulation scenario corresponding to the simulation instruction. Among them, the user input simulation instruction corresponds to Figure 5 the operation of the user to start the simulation task.

[0058] In this embodiment, the simulation instruction can include dynamics configuration parameters, traffic flow configuration parameters, and simulation algorithm configuration parameters; the dynamics configuration parameters at least include vehicle model parameters, vehicle control signal subscription parameters, and vehicle state signal publication parameters, and the traffic flow configuration parameters at least include following model parameters, lane change model parameters, and traffic signal parameters. Based on this, after receiving the simulation instruction, the simulation scheduling engine will parse the simulation instruction, and based on the parsed parameters, call the Init callback interface to complete the parameter initialization of each driving simulation module; that is, asFigure 5 After receiving the simulation instruction to start the simulation task from the user, the shown simulation scheduling engine will call the Init callback interface to initialize the dynamic simulation unit, the traffic flow simulation unit, and the algorithm under test unit respectively. Specifically, please refer to Figure 6 , step S220 may include the content of the following steps S221 to S223:

[0059] Step S221: Initialize the parameters based on the parameter initialization interface function, and transmit the vehicle model parameters, the vehicle control signal subscription parameters, and the vehicle state signal publishing parameters to the dynamic simulation unit for parameter initialization.

[0060] In other words, the dynamic simulation unit can request parameters from the simulation scheduling engine based on the parameter initialization interface function defined in the Init callback interface, and initialize itself based on the requested dynamic configuration parameters. Among them, the dynamic configuration parameters at least include vehicle model parameters, vehicle control signal subscription parameters, and vehicle state signal publishing parameters. Specifically, the dynamic simulation unit obtains the initialization configuration parameters from the simulation scheduling engine by calling the InitHelper.getParameter interface to complete the initialization of the configuration parameters; then calls the InitHelper.Publish interface to register and publish the topic, informing the simulation scheduling engine of the type of topic message it will send. Finally, calls the InitHelper.Subscribe interface to register and subscribe to the topic, informing the simulation scheduling engine of the type of topic information that the dynamic simulation unit will subscribe to from the simulation scheduling engine. Among them, all topic message types need to be negotiated and established with the simulation scheduling system or related algorithm modules before the simulation runs, so as to ensure that the dynamic simulation unit can publish, receive, and parse information when interacting with the simulation scheduling system.

[0061] Step S222: Initialize the parameters based on the parameter initialization interface function, and transmit the car-following model parameters, the lane-changing model parameters, and the traffic signal parameters to the traffic flow simulation unit for parameter initialization.

[0062] Similarly, the traffic flow simulation unit also requests parameters from the simulation scheduling engine based on the parameter initialization interface function defined in the Init callback interface, and initializes itself based on the obtained traffic flow configuration parameters. Among them, the traffic flow configuration parameters at least include car-following model parameters, lane-changing model parameters, and traffic signal parameters. Specifically, the traffic flow simulation unit also obtains the initialization configuration parameters from the simulation scheduling engine by calling the InitHelper.getParameter interface to complete the initialization of the configuration parameters; then calls the InitHelper.Publish interface to register and publish topics, informing the simulation scheduling engine of the types of topic messages it will send. Finally, it calls the InitHelper.Subscribe interface to register and subscribe to topics, informing the simulation scheduling engine of the types of topic information that the traffic flow simulation unit will subscribe to from the simulation scheduling engine. Among them, all types of topic messages need to be negotiated and established with the simulation scheduling system or relevant algorithm modules before the simulation runs, so as to ensure that the traffic flow simulation unit can publish, receive, and parse information when interacting with the simulation scheduling system.

[0063] Step S223: Based on the parameter initialization interface function, send the simulation algorithm configuration parameters to the to-be-tested simulation algorithm unit for parameter initialization.

[0064] Similarly, the to-be-tested simulation algorithm unit can also request parameters from the simulation scheduling engine based on the parameter initialization interface function defined in the Init callback interface, and initialize itself based on the obtained simulation algorithm configuration parameters. Among them, the parameters included in the simulation algorithm configuration parameters can be personalized according to the different services implemented by the algorithm. Taking the to-be-tested simulation algorithm as a planning algorithm as an example, the simulation algorithm configuration parameters corresponding to the planning algorithm can at least include the main vehicle status signal name (subscription) and the traffic vehicle status information name (publication). Specifically, the to-be-tested simulation algorithm unit also obtains the initialization configuration parameters from the simulation scheduling engine by calling the InitHelper.getParameter interface to complete the initialization of the configuration parameters; then calls the InitHelper.Publish interface to register and publish topics, informing the simulation scheduling engine of the types of topic messages it will send. Finally, it calls the InitHelper.Subscribe interface to register and subscribe to topics, informing the simulation scheduling engine of the types of topic information that the to-be-tested simulation algorithm unit will subscribe to from the simulation scheduling engine. Among them, all types of topic messages need to be negotiated and established with the simulation scheduling system or relevant algorithm modules before the simulation runs, so as to ensure that the to-be-tested simulation algorithm unit can publish, receive, and parse information when interacting with the simulation scheduling system.

[0065] It can be seen that the simulation call engine calls the init callback interfaces of each driving simulation module. The business code in the init callback interfaces implements the configuration initialization code. Based on this, each driving simulation module can obtain the initialization parameters from the simulation scheduling engine by means of reading memory or RPC requests through the Helper function, so as to complete the initialization of the configuration parameters of each driving simulation module. In this way, since the parameter initialization of each driving simulation module is implemented through negotiation with the simulation scheduling engine, it can be ensured that each driving simulation module realizes the publication, forwarding, reception, and parsing of messages through the simulation scheduling engine.

[0066] Step S230: Based on the scenario initialization interface function, perform scenario initialization on the driving simulation module after parameter initialization.

[0067] In some embodiments, the foregoing simulation instructions further include dynamic scenario parameters, traffic flow scenario parameters, and simulation algorithm scenario parameters. The dynamic scenario parameters at least include vehicle position parameters and vehicle orientation parameters. The traffic flow scenario parameters at least include the departure time, departure position, departure ratio, headway, traffic flow, and macroscopic path of the vehicle. Please refer to Figure 7 , Step S230 may include the content of the following steps S231 to S233:

[0068] Step S231: Based on the scenario initialization interface function, transmit the vehicle position parameters and the vehicle orientation parameters to the dynamic simulation unit for scenario initialization.

[0069] In other words, after the dynamic simulation unit completes parameter initialization, it can further request the dynamic scenario parameters from the simulation scheduling engine based on the scenario initialization interface function ResetHelper defined in the Reset callback interface, and perform self-scenario initialization based on the requested dynamic scenario parameters. Among them, the dynamic scenario parameters include vehicle position parameters and vehicle orientation parameters. Among them, for the specific method of obtaining the dynamic scenario parameters through ResetHelper, reference can be made to the foregoing description of the Reset callback interface, which will not be elaborated here one by one.

[0070] Step S232: Based on the scenario initialization interface function, transmit the traffic flow scenario parameters to the traffic flow simulation unit for scenario initialization.

[0071] Similarly, after the traffic flow simulation unit completes parameter initialization, it will further request traffic flow scenario parameters from the simulation scheduling engine based on the scenario initialization interface function ResetHelper defined in the Reset callback interface, and perform scenario initialization on itself based on the requested traffic flow scenario parameters. Among them, the traffic flow scenario parameters include the departure time, departure location, departure ratio, headway, departure flow rate of vehicles, and the macroscopic paths of vehicles, etc., which will not be elaborated one by one here. Among them, for the specific method of obtaining the foregoing traffic flow scenario parameters through ResetHelper, reference can be made to the relevant description of the Reset callback interface above, which will not be elaborated one by one here.

[0072] Step S233: Based on the scenario initialization interface function, transmit the simulation algorithm scenario parameters to the to-be-tested simulation algorithm unit for scenario initialization.

[0073] Similarly, after the to-be-tested simulation algorithm unit completes parameter initialization, it will further request simulation algorithm scenario parameters from the simulation scheduling engine based on the scenario initialization interface function ResetHelper defined in the Reset callback interface, and perform scenario initialization on itself based on the requested simulation algorithm scenario parameters. Among them, the parameters included in the simulation algorithm scenario parameters can be personalized to set different scenario parameters according to the different services implemented by the to-be-tested simulation algorithm unit, including but not limited to parameters such as the scenario file path, map file path, starting position of the host vehicle, target position of the host vehicle, speed limit of the host vehicle, and the current simulation start time. Among them, for the specific method of obtaining the foregoing simulation algorithm scenario parameters through ResetHelper, reference can be made to the relevant description of the Reset callback interface above, which will not be elaborated one by one here.

[0074] It can be seen that the simulation call engine calls the Reset callback interfaces of each driving simulation module. The business code in the Reset callback interface implements the initialization code related to the scenario, and can obtain the initialization scenario parameters from the simulation scheduling engine by means of reading memory or RPC request through the helper function, so as to complete the initialization of the scenario parameters of each driving simulation module.

[0075] Step S240: Based on the single-step operation interface function, call the driving simulation module after the simulation scenario is initialized for simulation until the set simulation end condition is met, and then based on the operation stop interface function, stop the simulation process of the driving simulation module to obtain the simulation result data.

[0076] In some embodiments, a simulation task is generally a collection of scenario subtasks, that is, the simulation task is started and run in a sequential loop manner; based on this, a simulation instruction generally includes multiple simulation subtasks and the task execution order of the multiple simulation subtasks; the driving simulation module includes a dynamics simulation unit, a traffic flow simulation unit, and a to-be-tested simulation algorithm unit.

[0077] In this mode, based on the single-step running interface function, and in accordance with the task execution order, the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit are called for simulation until the set simulation end condition is met, then based on the running stop interface function, the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit are stopped, and the simulation result data is obtained. It can be understood that the simulation scheduling engine gradually calls the step callback interface functions in the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit according to the task execution order of the multiple simulation subtasks. The dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit respectively obtain the single-step input information for completing the solution of their respective units through the subscribe function of StepHelper, then perform internal iterative solution, and then send the solution results in the form of a topic and call the publish interface of StepHelper to send them to the simulation scheduling engine to promote the time-step iterative evolution of the simulation tasks of the entire simulation system. Among them, the data interaction method between each simulation unit and the simulation scheduling engine can be an interaction method based on shared memory for data reading and writing, or an interaction method based on RPC requests. This embodiment does not limit this.

[0078] Specifically, the simulation scheduling engine can transmit the control signal and vehicle position state of the vehicle under test to the dynamics simulation unit based on the single-step running interface function, and obtain the pose and motion state of the vehicle under test output by the dynamics simulation unit. That is, the simulation scheduling engine calls the dynamics simulation unit through the step callback interface. Correspondingly, the dynamics simulation unit can obtain the single-step input information required for the dynamics simulation unit to perform simulation from the simulation scheduling engine based on the subscribe function in the StepHelper method under the step callback interface, such as the control signal of the vehicle under test and the vehicle position state; then the dynamics simulation unit performs internal iterative solution based on the single-step input information, and then sends the solution results (that is, the pose and motion state of the vehicle under test) in the form of a topic and calls the publish interface of StepHelper to send them to the simulation task scheduling system.

[0079] Similarly, the simulation scheduling engine can also transmit the surrounding traffic environment parameters of the vehicle under test to the traffic flow simulation unit based on the single-step operation interface function, and obtain the pose and motion state of the vehicles in the traffic environment output by the traffic flow simulation unit. That is, the simulation scheduling engine calls the traffic flow simulation unit through the step callback interface. Correspondingly, the traffic flow simulation unit can obtain the single-step input information required for the traffic flow simulation unit to perform simulation from the simulation scheduling engine based on the subscribe function in the StepHelper method under the step callback interface, such as the surrounding traffic environment parameters, the surrounding departure model information, including departure time, departure position, departure ratio, headway, departure flow, and vehicle macroscopic path. Then, the dynamic simulation unit performs internal iterative solution based on the single-step input information, and then sends the solution result (i.e., the pose and motion state of the vehicles in the traffic environment) to the simulation task scheduling system in the form of a topic by calling the publish interface of StepHelper.

[0080] Similarly, the simulation scheduling engine can also transmit the pose and motion state of the vehicle under test, as well as the pose and motion state of the vehicles in the traffic environment to the decision-making and planning algorithm unit, and obtain the planned path output by the decision-making and planning algorithm unit. That is, the simulation scheduling engine calls the planning algorithm unit through the step callback interface. Correspondingly, the planning algorithm unit can obtain the single-step input information required for the planning algorithm unit to perform simulation from the simulation scheduling engine based on the subscribe function in the StepHelper method under the step callback interface, such as the pose and motion state of the vehicle under test, as well as the pose and motion state of the vehicles in the traffic environment. Then, the planning algorithm unit performs internal iterative solution based on the single-step input information, and then sends the solution result (i.e., the planned path of the vehicle under test) to the simulation task scheduling system in the form of a topic by calling the publish interface of StepHelper.

[0081] Similarly, the simulation scheduling engine can also transmit the planned path to the control algorithm unit based on the single-step operation interface function, obtain the vehicle control signal output by the control algorithm unit, and until the set simulation end condition is satisfied, then based on the operation stop interface function, stop the simulation processes of the dynamic simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit, and obtain the simulation result data. That is, the simulation scheduling engine calls the control algorithm unit through the step callback interface. Correspondingly, the control algorithm unit can obtain the single-step input information required for the control algorithm unit to complete the simulation, that is, the planned path of the vehicle under test, from the simulation scheduling engine based on the subscribe function in the StepHelper method under the step callback interface; then the planning algorithm unit performs internal iterative solution based on the single-step input information, and then sends the solution result (that is, the vehicle control signal of the vehicle under test, such as the drive signal, the brake signal, and the steering signal) to the simulation task scheduling system in the form of a topic by calling the publish interface of StepHelper.

[0082] Optionally, the foregoing set simulation end condition may at least include that the simulation scheduling engine receives a simulation stop instruction input by the user, all sub-simulation tasks have been executed, the vehicle under test collides or violates traffic rules during the simulation, there is no optional planned path, etc., and this embodiment does not limit this. Further, after the set simulation end condition is satisfied, the simulation scheduling engine calls the stop callback interface to end the simulation task corresponding to the foregoing simulation instruction, and each simulation unit can feedback the operation data to the simulation system through the set_feedback interface of StepHelper, that is, feedback the foregoing simulation result data. Among them, the feedback operation data can be used to represent the status data of whether each simulation unit is operating normally.

[0083] Further, the foregoing operation data will be saved in the simulation scheduling engine. If the simulation software has a corresponding simulation interaction interface, the operation and data can be displayed on the interaction interface for the simulation personnel to view; if the simulation software does not have a corresponding simulation interaction page, the feedback operation data can be saved in a text file. Here, only the operation status data is feedback. For the evaluation of the algorithm unit to be tested, an independent evaluation module can be designed based on the foregoing SDK. The operation mechanism of the evaluation module and the foregoing algorithm unit to be tested is the same. By obtaining relevant data in the step interface function, calculating the evaluation indexes, and obtaining the simulation evaluation result. Based on this, the simulation evaluation result includes, but is not limited to, evaluation parameters such as the response rate, algorithm accuracy, and stability of each algorithm unit to be tested; it can be understood that the simulation evaluation result can be saved in the simulation scheduling engine and displayed on the simulation interaction interface for the developers of the algorithm unit to be tested to view, so that the developers can adjust and optimize the algorithm unit to be developed based on the simulation evaluation result.

[0084] In this embodiment, through the SDK, the encapsulation of the interfaces of the four main simulation processes of initialization, scenario reset, step call, and stop in the simulation process is realized. Any algorithm can be developed based on this SDK, and only by exposing the above four interface functions can it be scheduled by the simulation platform and obtain data from the simulation platform. Using a unified scheduling method and interaction protocol, the problem that the software in the current simulation system is coupled but the protocols are not compatible is solved, and the convenience of algorithm development is improved. Secondly, the algorithm development method based on the SDK involved in this application supports deployment on different machines and environments, that is, distributed simulation can be realized, meeting the flexible demand for independent testing of the algorithm test environment, and improving the applicability of the system application scenario. Due to distributed decoupling, this simulation system supports not only SIL simulation but also PIL simulation testing. The same system meets the requirements of the two-stage testing. That is to say, this application unifies all complex interfaces into the four preset callback interfaces mentioned above, and each driving simulation module also provides only these four preset callback interfaces externally, reducing the complex call process, and solving the problem of mutual call confusion caused by the need to add other interfaces when the requirements increase in the prior art, and other modules also need to adapt to develop the interface and the scheduling logic.

[0085] Please refer to Figure 8 , which shows a structural block diagram of an autonomous driving simulation device 300 provided in an embodiment of the present application. The device 300 may include: an instruction receiving module 310 and a simulation calling module 320.

[0086] The instruction receiving module 310 is configured to receive simulation instructions. The simulation module 320 is configured to call the driving simulation module corresponding to the simulation instructions through a plurality of preset callback interfaces to perform simulation and obtain simulation result data, and the driving simulation module is designed based on the plurality of preset callback interfaces.

[0087] In some embodiments, the multiple preset callback interfaces at least include a parameter initialization interface function, a scenario initialization interface function, a single-step running interface function, and a running stop interface function. The simulation module 320 may include a parameter initialization unit, a scenario initialization unit, and a simulation running unit. Among them, the parameter initialization unit may be configured to perform parameter initialization on the driving simulation module based on the parameter initialization interface function. The scenario initialization unit may be configured to perform simulation scenario initialization on the driving simulation module after parameter initialization based on the scenario initialization interface function. The simulation running unit may be configured to call the driving simulation module after simulation scenario initialization for simulation based on the single-step running interface function until a set simulation end condition is met, and then stop the simulation process of the driving simulation module based on the running stop interface function to obtain the simulation result data.

[0088] In this mode, the simulation instruction includes multiple simulation subtasks and the task execution order of the multiple simulation subtasks. The driving simulation module at least includes a dynamics simulation unit, a traffic flow simulation unit, and a to-be-tested simulation algorithm unit. The simulation running unit may be configured to call the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit for simulation based on the single-step running interface function and in accordance with the task execution order until the set simulation end condition is met, and then stop the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit based on the running stop interface function to obtain the simulation result data.

[0089] In some embodiments, the to-be-tested simulation algorithm unit includes a decision-making and planning algorithm unit and a control algorithm unit. The simulation running unit may specifically be configured to transmit a control signal and a vehicle position state for the vehicle under test to the dynamics simulation unit based on the single-step running interface function to obtain the pose and motion state of the vehicle under test output by the dynamics simulation unit; transmit the surrounding traffic environment parameters of the vehicle under test to the traffic flow simulation unit based on the single-step running interface function to obtain the pose and motion state of the vehicles in the traffic environment output by the traffic flow simulation unit; transmit the pose and motion state of the vehicle under test and the pose and motion state of the vehicles in the traffic environment to the decision-making and planning algorithm unit based on the single-step running interface function to obtain a planned path output by the decision-making and planning algorithm unit; transmit the planned path to the control algorithm unit based on the single-step running interface function to obtain a vehicle control signal output by the control algorithm unit until the set simulation end condition is met, and then stop the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit based on the running stop interface function to obtain the simulation result data.

[0090] In some embodiments, the simulation instruction further includes kinetic configuration parameters, traffic flow configuration parameters, and simulation algorithm configuration parameters. The kinetic configuration parameters at least include vehicle model parameters, vehicle control signal subscription parameters, and vehicle status signal publication parameters. The traffic flow configuration parameters at least include car-following model parameters, lane-changing model parameters, and traffic signal parameters. The parameter initialization unit can specifically be configured to: based on the parameter initialization interface function, transmit the vehicle model parameters, the vehicle control signal subscription parameters, and the vehicle status signal publication parameters to the kinetic simulation unit for parameter initialization; based on the parameter initialization interface function, transmit the car-following model parameters, the lane-changing model parameters, and the traffic signal parameters to the traffic flow simulation unit for parameter initialization; based on the parameter initialization interface function, send the simulation algorithm configuration parameters to the to-be-tested simulation algorithm unit for parameter initialization.

[0091] In some embodiments, the simulation instruction further includes kinetic scenario parameters, traffic flow scenario parameters, and simulation algorithm scenario parameters. The kinetic scenario parameters at least include vehicle position parameters and vehicle orientation parameters. The traffic flow scenario parameters at least include the departure time, departure position, departure ratio, headway, departure flow rate, and macroscopic vehicle path of the vehicle. The scenario initialization unit can specifically be configured to, based on the scenario initialization interface function, transmit the vehicle position parameters and the vehicle orientation parameters to the kinetic simulation unit for scenario initialization; based on the scenario initialization interface function, transmit the traffic flow scenario parameters to the traffic flow simulation unit for scenario initialization; based on the scenario initialization interface function, transmit the simulation algorithm scenario parameters to the to-be-tested simulation algorithm unit for scenario initialization.

[0092] In some embodiments, the autonomous driving simulation device 300 may further include: a registration module. The registration module can be configured to, before calling the driving simulation module corresponding to the simulation instruction through a plurality of preset callback interfaces to perform simulation and obtain simulation result data, read the configuration file information corresponding to the driving simulation module. The configuration file information at least includes the module identifier, absolute path, and module operation parameters of the driving simulation module; store the configuration file information in the simulation registry.

[0093] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the foregoing method embodiments, and will not be elaborated herein.

[0094] In several embodiments provided in the present application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0095] In addition, each functional module in various embodiments of the present application may be integrated into a processing module, may exist independently as individual physical modules, or two or more modules may be integrated into one module. The above integrated module may be implemented in the form of hardware or in the form of a software functional module.

[0096] In summary, through the SDK, the encapsulation of the interfaces for the four main simulation processes of initialization, scene reset, step call, and stop during the simulation process is achieved. Any algorithm can be developed based on this SDK, and only by exposing the above four interface functions can it be scheduled by the simulation platform and obtain data from the simulation platform. By adopting a unified scheduling method and interaction protocol, the problem of software coupling but protocol incompatibility in the current simulation system is solved, and the convenience of algorithm development is improved. Secondly, the algorithm development method based on the SDK involved in the present application supports deployment on different machines and environments, that is, distributed simulation can be realized, meeting the flexible requirements of the independent test method for the algorithm test environment, and improving the applicability of the system application scenario. Due to distributed decoupling, this simulation system supports not only SIL simulation but also PIL simulation testing, and the same system meets the requirements of testing in two stages. Moreover, different driving simulation modules can be uniformly synchronously called through multiple preset callback interfaces during the driving simulation process to achieve the interaction of simulation data, thereby completing the driving simulation to obtain the final simulation result data, which can greatly reduce the difficulty of simulation testing and ensure the effect of simulation testing.

[0097] Next, a computer device provided by the present application will be described in conjunction with Figure 9 a computer device provided by the present application will be described.

[0098] Referring to Figure 9 , Figure 9 FIG. shows a structural block diagram of a computer device 400 provided by an embodiment of the present application, and the above method provided by the embodiment of the present application can be executed by the computer device 400. The computer device may be an electronic terminal with data processing capabilities, and the electronic terminal includes but is not limited to smart phones, tablet computers, laptop computers, and desktop computers, etc.; of course, the computer device may also be a server, and the server may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), and big data and artificial intelligence platforms.

[0099] The computer device 400 in the embodiments of the present application may include one or more of the following components: a processor 401, a memory 402, and one or more application programs. One or more application programs may be stored in the memory 402 and configured to be executed by one or more processors 401. The one or more programs are configured to execute the methods described in the foregoing method embodiments.

[0100] The processor 401 may include one or more processing cores. The processor 401 connects various parts within the entire computer device 400 using various interfaces and lines. By running or executing instructions, programs, code sets, or instruction sets stored in the memory 402, and by calling data stored in the memory 402, the processor 401 executes various functions of the computer device 400 and processes data. Optionally, the processor 401 may be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). The processor 401 may integrate one or a combination of several of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU mainly processes the operating system, user interface, and application programs, etc.; the GPU is responsible for rendering and drawing display content; the modem is used to process wireless communications. It can be understood that the above modem may also be integrated into the processor 401 and implemented separately through a communication chip.

[0101] The memory 402 may include random access memory (RAM) and may also include read-only memory. The memory 402 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 402 may include a program storage area and a data storage area. Among them, the program storage area may store instructions for implementing the operating system, instructions for implementing at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the following various method embodiments, etc. The data storage area may also store data created during the use of the computer device 400 (such as the various corresponding relationships described above), etc.

[0102] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described devices and modules can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0103] In several embodiments provided by the present application, the coupling, direct coupling or communication connection between the modules shown or discussed with each other may be through some interfaces, and the indirect coupling or communication connection of the devices or modules may be in electrical, mechanical or other forms.

[0104] In addition, in each embodiment of the present application, each functional module may be integrated in a processing module, or each module may exist physically alone, or two or more modules may be integrated in one module. The above integrated modules may be implemented in the form of hardware or in the form of software functional modules.

[0105] Please refer to Figure 10 , which shows a structural block diagram of a computer-readable storage medium provided by an embodiment of the present application. Program code is stored in the computer-readable medium 500, and the program code can be called by a processor to execute the method described in the above method embodiment.

[0106] The computer-readable storage medium 500 may be an electronic memory such as a flash memory, an EEPROM (electrically erasable programmable read-only memory), an EPROM, a hard disk, or a ROM. Optionally, the computer-readable storage medium 500 includes a non-transitory computer-readable storage medium. The computer-readable storage medium 500 has a storage space for the program code 510 that executes any method step in the above method. These program codes may be read out from or written into one or more computer program products. The program code 510 may be compressed in a suitable form, for example.

[0107] In some embodiments, a computer program product or a computer program is provided. The computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the steps in the above method embodiments.

[0108] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, and are not intended to limit them; although the present application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. An automatic driving simulation method, characterized in that, The method includes: Receiving a simulation instruction; Calling a driving simulation module corresponding to the simulation instruction through a plurality of preset callback interfaces to perform a simulation, and obtaining simulation result data, where the driving simulation module is designed based on the plurality of preset callback interfaces.

2. The method according to claim 1, wherein The plurality of preset callback interfaces at least include a parameter initialization interface function, a scenario initialization interface function, a single-step operation interface function, and a running stop interface function; The calling the driving simulation module corresponding to the simulation instruction through a plurality of preset callback interfaces to perform a simulation and obtaining simulation result data includes: Performing parameter initialization on the driving simulation module based on the parameter initialization interface function; Performing simulation scenario initialization on the driving simulation module after parameter initialization based on the scenario initialization interface function; Based on the single-step operation interface function, calling the driving simulation module after simulation scenario initialization to perform a simulation until a set simulation end condition is met, and then based on the running stop interface function, stopping the simulation process of the driving simulation module to obtain the simulation result data.

3. The method according to claim 2, characterized in that, The simulation instruction includes a plurality of simulation subtasks and the task execution order of the plurality of simulation subtasks, and the driving simulation module at least includes a dynamics simulation unit, a traffic flow simulation unit, and a to-be-tested simulation algorithm unit; The based on the single-step operation interface function, calling the driving simulation module after simulation scenario initialization to perform a simulation until a set simulation end condition is met, and then based on the running stop interface function, stopping the simulation process of the driving simulation module to obtain the simulation result data includes: Based on the single-step operation interface function and in accordance with the task execution order, calling the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit to perform a simulation until the set simulation end condition is met, and then based on the running stop interface function, stopping the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit to obtain the simulation result data.

4. The method according to claim 3, wherein The to-be-tested simulation algorithm unit includes a decision-making and planning algorithm unit and a control algorithm unit; The based on the single-step operation interface function and in accordance with the task execution order, calling the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit to perform a simulation until the set simulation end condition is met, and then based on the running stop interface function, stopping the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit to obtain the simulation result data includes: Based on the single-step operation interface function, transmitting a control signal and a vehicle position state for the vehicle under test to the dynamics simulation unit, and obtaining the dynamics simulation unit outputting the pose and motion state of the vehicle under test; Based on the single-step operation interface function, transmitting the surrounding traffic environment parameters of the vehicle under test to the traffic flow simulation unit, and obtaining the traffic flow simulation unit outputting the pose and motion state of the traffic environment vehicles; Based on the single-step operation interface function, transmit the pose and motion state of the vehicle under test, as well as the pose and motion state of the traffic environment vehicle, to the decision-making and planning algorithm unit, and obtain the planned path output by the decision-making and planning algorithm unit; Based on the single-step operation interface function, transmit the planned path to the control algorithm unit, obtain the vehicle control signal output by the control algorithm unit, and until the set simulation end condition is satisfied, then based on the operation stop interface function, stop the simulation processes of the dynamics simulation unit, the traffic flow simulation unit, and the to-be-tested simulation algorithm unit, and obtain the simulation result data.

5. The method according to claim 3, characterized in that The simulation instruction further includes dynamics configuration parameters, traffic flow configuration parameters, and simulation algorithm configuration parameters. The dynamics configuration parameters at least include vehicle model parameters, vehicle control signal subscription parameters, and vehicle state signal publication parameters. The traffic flow configuration parameters at least include car-following model parameters, lane-changing model parameters, and traffic signal parameters; Based on the parameter initialization interface function, perform parameter initialization on the driving simulation module, including: Based on the parameter initialization interface function, transmit the vehicle model parameters, the vehicle control signal subscription parameters, and the vehicle state signal publication parameters to the dynamics simulation unit for parameter initialization; Based on the parameter initialization interface function, transmit the car-following model parameters, the lane-changing model parameters, and the traffic signal parameters to the traffic flow simulation unit for parameter initialization; Based on the parameter initialization interface function, send the simulation algorithm configuration parameters to the to-be-tested simulation algorithm unit for parameter initialization.

6. The method according to claim 3, wherein The simulation instruction further includes dynamics scenario parameters, traffic flow scenario parameters, and simulation algorithm scenario parameters. The dynamics scenario parameters at least include vehicle position parameters and vehicle orientation parameters. The traffic flow scenario parameters at least include the departure time, departure position, departure ratio, headway, departure flow rate, and vehicle macroscopic path of the vehicle; Based on the scenario initialization interface function, perform simulation scenario initialization on the driving simulation module after parameter initialization, including: Based on the scenario initialization interface function, transmit the vehicle position parameters and the vehicle orientation parameters to the dynamics simulation unit for scenario initialization; Based on the scenario initialization interface function, transmit the traffic flow scenario parameters to the traffic flow simulation unit for scenario initialization; Based on the scenario initialization interface function, transmit the simulation algorithm scenario parameters to the to-be-tested simulation algorithm unit for scenario initialization.

7. The method according to any one of claims 1-6, characterized in that, Before obtaining the simulation result data by calling the driving simulation module corresponding to the simulation instruction through multiple preset callback interfaces, the method further includes: Read the configuration file information corresponding to the driving simulation module, and the configuration file information at least includes the module identifier, absolute path, and module operation parameters of the driving simulation module; Store the configuration file information in the simulation registry.

8. An automatic driving simulation device, characterized in that, The device includes: An instruction receiving module, configured to receive a simulation instruction; A simulation module, configured to call the driving simulation module corresponding to the simulation instruction through a plurality of preset callback interfaces for simulation to obtain simulation result data, where the driving simulation module is designed based on the plurality of preset callback interfaces.

9. A computer device, characterized in that, Comprising: One or more processors; A memory; One or more programs, where the one or more programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Program code is stored in the computer-readable storage medium, and the program code can be called by a processor to execute the method according to any one of claims 1 to 7.

Images