Algorithm deployment verification method and device, equipment and storage medium

Abstract

The invention relates to an algorithm deployment verification method and apparatus, a device and a storage medium. The method comprises the steps of deploying a target driving algorithm to a virtual micro-control unit MCU; reading a first data set output by the virtual camera, and injecting the first data set into a target driving algorithm deployed on the virtual MCU to obtain an output result; generating a control signal based on the output result, and verifying the accuracy of the target driving algorithm through the control signal; under the condition that the verification of the accuracy of the target driving algorithm is passed, migrating the target driving algorithm to a physical MCU in the target vehicle; the verification cost of the driving algorithm can be reduced.

Description

Technical Field

[0001] The present invention relates to the automotive field, and in particular to an algorithm deployment verification method and device, equipment, and storage medium. Background Art

[0002] The autonomous driving technology of automobiles requires the support of driving algorithms, which are usually deployed on microcontroller units (MCUs). However, the support for inference frameworks on different MCU platforms varies greatly. When the same algorithm is deployed on different MCUs, it needs to be adapted to different MCU platforms, which results in poor adaptability and high cost in verifying the algorithm. Summary of the invention

[0003] One of the purposes of the present invention is to provide a method and apparatus, device, and storage medium for verifying the deployment of an algorithm, which can reduce the verification cost of a driving algorithm.

[0004] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0005] A deployment verification method for an algorithm, the deployment verification method for the algorithm comprising:

[0006] Deploy the target driving algorithm to the virtual microcontroller unit MCU;

[0007] Reading a first data set output by the virtual camera, injecting the first data set into a target driving algorithm deployed on the virtual MCU, and obtaining an output result;

[0008] Generate a control signal based on the output result, and verify the accuracy of the target driving algorithm through the control signal;

[0009] When the accuracy of the target driving algorithm is verified, the target driving algorithm is migrated to the physical MCU in the target vehicle.

[0010] The technical solution of the present invention can directly deploy the driving algorithm on the virtual MCU without considering the adaptability of the physical MCU when deploying the driving algorithm, which can expand the selection range of the physical MCU. At the same time, the driving algorithm can also be tested and verified on the virtual MCU and migrated after the verification, thereby reducing the verification cost of the driving algorithm.

[0011] In the above algorithm deployment verification method, before deploying the target driving algorithm to the virtual microcontroller unit MCU, the method further includes:

[0012] Obtaining an initial driving algorithm;

[0013] The model format of the initial driving algorithm is converted into a binary format, and the initial driving algorithm is preprocessed to obtain a target driving algorithm; the preprocessing at least includes reconstructing the network structure of the initial driving algorithm and optimizing the operator of the initial driving algorithm.

[0014] Based on the above technical solution, the memory size of the target driving algorithm can be reduced, thereby reducing the resource consumption of the target driving algorithm during runtime.

[0015] In the above algorithm deployment verification method, after the target driving algorithm is deployed on the virtual microcontroller unit MCU, the method further includes:

[0016] Starting a virtual camera process on the virtual MCU; the virtual camera process includes a main thread and a first sub-thread; the first sub-thread is a software development kit SDK sub-thread;

[0017] Configure the main thread to listen to the first socket; the first socket is used to implement communication between the virtual camera deployed on the first device and the virtual camera process;

[0018] The first child thread is configured to listen to the second socket; the second socket is used to implement communication between at least two threads.

[0019] Based on the above technical solution, the communication between the first device and the virtual MCU is realized through the monitoring relationship between the main thread and the first sub-thread and the first socket and the second socket respectively.

[0020] In the deployment verification method of the above algorithm, the first data set includes metadata, and the method further includes:

[0021] Starting a virtual camera; and establishing a first connection between the virtual camera and the first socket;

[0022] Receiving metadata sent by the virtual camera based on the first connection using the first socket;

[0023] The received metadata is sent to a target SDK on the virtual MCU by using the first subthread and the second socket; the target SDK is an SDK for implementing camera-related operations.

[0024] In the deployment verification method of the above algorithm, the first data set includes frame data, and the method further includes:

[0025] Start the second sub-thread corresponding to the virtual camera; the second sub-thread is used to process the frame data of the virtual camera;

[0026] The second sub-thread is used to receive the frame data sent by the virtual camera based on the first connection, and the frame data is written into a preset circular queue; the preset circular queue is created for the first sub-thread.

[0027] Based on the above technical solution, data transmission between the second sub-thread and the target SDK can be achieved by setting a preset circular queue.

[0028] In the deployment verification method of the above algorithm, writing frame data into a preset circular queue includes:

[0029] Using the second child thread to obtain the preset circular queue;

[0030] The second sub-thread is used to call a preset queue entry function to write the frame data into a preset circular queue.

[0031] In the deployment verification method of the above algorithm, after writing the frame data into the preset circular queue, the method further includes:

[0032] Use the read function in the target SDK to cyclically read frame data from the preset circular queue.

[0033] In the deployment verification method of the above algorithm, a first data set output by a virtual camera is read, and the first data set is injected into a target driving algorithm deployed on a virtual MCU to obtain an output result, including:

[0034] Read the virtual camera metadata and frame data from the target SDK;

[0035] Inject metadata and frame data into the target driving algorithm deployed on the virtual MCU to obtain output results.

[0036] Based on the above technical solution, by injecting the metadata and frame data of the virtual camera on the first device into the target driving algorithm deployed on the virtual MCU, the purpose of verifying the target driving algorithm on the virtual MCU can be achieved.

[0037] In the deployment verification method of the above algorithm, the accuracy of the target driving algorithm is verified through the control signal, including:

[0038] forwarding the control signal to the third sub-thread using the target SDK and the second socket;

[0039] Using the third sub-thread to encapsulate the control signal into a preset format, and sending the encapsulated control signal to the first monitoring program;

[0040] By utilizing the association relationship between the first monitoring program on the virtual MCU and the second monitoring program on the first device, the packaged control signal is sent to the second monitoring program, so that the second monitoring program forwards the packaged control signal to the simulation software deployed on the first device to verify the accuracy of the target driving algorithm.

[0041] An algorithm deployment verification device, the algorithm deployment verification device comprising:

[0042] A deployment unit, used to deploy the target driving algorithm onto the virtual microcontroller unit MCU;

[0043] A reading unit, used for reading a first data set output by the virtual camera, injecting the first data set into a target driving algorithm deployed on the virtual MCU, and obtaining an output result;

[0044] A generating unit, used for generating a control signal based on the output result, and verifying the accuracy of the target driving algorithm through the control signal;

[0045] The migration unit is used to migrate the target driving algorithm to the physical MCU in the target vehicle when the accuracy of the target driving algorithm is verified.

[0046] The technical solution of the present invention can directly deploy the driving algorithm on the virtual MCU without considering the adaptability of the physical MCU when deploying the driving algorithm, which can expand the selection range of the physical MCU. At the same time, the driving algorithm can also be tested and verified on the virtual MCU and migrated after the verification, thereby reducing the verification cost of the driving algorithm. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 A schematic diagram of the relationship between different machine learning methods provided by an embodiment of the present invention;

[0048] Figure 2 A schematic diagram of an exemplary deployment of an existing autonomous driving algorithm provided in an embodiment of the present invention;

[0049] Figure 3 A schematic diagram of a flow chart of a deployment verification method of an algorithm provided in an embodiment of the present invention;

[0050] Figure 4 A schematic diagram of an exemplary deployment of an autonomous driving algorithm provided by an embodiment of the present invention;

[0051] Figure 5 A schematic diagram of an exemplary algorithm deployment verification method provided in an embodiment of the present invention;

[0052] Figure 6 A schematic diagram of the structure of a deployment verification device for an algorithm provided in an embodiment of the present invention;

[0053] Figure 7 A schematic diagram of the composition structure of a deployment verification device for an algorithm provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0054] The following will describe the embodiments of the present invention with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the contents disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention, not for limiting the scope of protection of the present invention.

[0055] The present invention is used to simulate virtual sensors on virtual twin cars, and is also used for the development and verification of visual algorithms such as pure visual autonomous driving or driving behavior monitoring. More specifically, the present invention involves the injection of virtual camera data into virtual domain control, and the zero-dependency deployment and migration of autonomous driving algorithms.

[0056] At present, the existing technology realizes the simulation of the camera by the following methods:

[0057] 1. A data interaction method, device, electronic device and medium based on a virtual camera, the method comprising: opening a pre-created virtual camera device node and applying for a buffer queue for receiving data; placing the buffer queue into a loaded virtual camera driver; starting camera transmission to trigger receiving data transmitted by a sender; each time the virtual camera driver receives an interrupt signal, taking out the corresponding received data from the buffer queue according to the interrupt signal until the transmission channel created by the sender is closed and the data transmission is stopped. However, this method only realizes the reading of data in the domain controller, and does not realize the sending of data on the host side; at the same time, the method is realized through the kernel driver (Video for linux2, V4L2) ecosystem for video devices in Linux, and the process of realizing data injection from the host side to the virtual domain controller is relatively complicated.

[0058] 2. A 4-bit quantization-based intelligent monitoring tinyML (micro machine learning) method, the method includes: (1) training of personnel detection models; (2) post-training quantization of models; (3) construction of AI reasoning framework on MCU; (4) on-chip storage of 4-bit models and on-chip storage encoding of reasoning weights; (5) camera data collection and real-time reasoning of data. Although this method realizes the standard process of tinyML deployment and the construction and optimization of reasoning framework on MCU, many MCUs do not support the framework enough, and it is still difficult to rely on the framework for deployment.

[0059] refer to Figure 1 , the relationship between tinyML and mechine learning (machine learning), cloudML (cloud machine learning), and EdgeML (edge ​​machine learning) is as follows Figure 1. The main feature of tinyML is that it is deployed on low-cost and low-power MCUs. It is precisely because of the low cost and low power consumption of MCUs that more and more companies and researchers are trying to deploy autonomous driving algorithms on MCUs. For example, NVIDIA's famous PilotNet (unmanned driving algorithm) takes raw camera images as input and steering wheel angles as output, that is, learning how to control the car directly from the camera sensor. From the perspective of low cost and low power consumption, it is very important to choose a suitable MCU to deploy PilotNet.

[0060] In summary, the prior art has the following shortcomings:

[0061] 1. Due to the limited resources of MCU and the lack of operating system, deploying TinyML on MCU brings many technical challenges. One of them is that the support for inference frameworks on different MCU platforms varies greatly. When the same algorithm is deployed on different MCUs, it needs to be adapted to different MCU platforms. Figure 2 When the same autonomous driving algorithm is deployed on different MCUs, it needs to rely on AI reasoning framework 1 and camera 1 for development on MCU1, AI reasoning framework 2 and camera 2 for development on MCU2, and AI reasoning framework 3 and camera 3 for development on MCU3. However, if MCU3 does not support the AI ​​reasoning framework or does not support it enough, it will fail to be deployed on MCU3.

[0062] 2. The AI ​​reasoning framework on the MCU is usually not open source as the core technology of the MCU manufacturer. This results in the inability to use some of the latest reasoning optimization methods for specific visual algorithms, including quantization and operator optimization. You need to wait until the framework supports it before you can use it.

[0063] 3. High cost of algorithm verification: Autonomous driving algorithms need to be verified on the road.

[0064] In view of the above technical problems, the present invention provides an algorithm deployment verification method, which is implemented by an algorithm deployment verification device. Figure 3 A flowchart of a deployment verification method of an algorithm provided in an embodiment of the present invention is shown as follows: Figure 3 As shown, the steps S301 to S304 are included:

[0065] Step S301: deploy the target driving algorithm to the virtual micro control unit MCU.

[0066] In an embodiment of the present invention, the algorithm deployment verification device deploys the target driving algorithm onto a virtual micro control unit MCU.

[0067] In an embodiment of the present invention, the target driving algorithm may be an autonomous driving model PilotNet or a micro machine learning autonomous driving model TinyML; the specific target driving algorithm may be selected according to actual conditions, and the embodiment of the present invention does not make any specific limitation here.

[0068] In the embodiment of the present invention, the virtual MCU can be understood as an MCU running on a virtual server, and its hardware resources are no different from those of a physical MCU.

[0069] Step S302: read a first data set output by the virtual camera, inject the first data set into a target driving algorithm deployed on the virtual MCU, and obtain an output result.

[0070] In an embodiment of the present invention, after deploying the target driving algorithm on the virtual microcontroller unit MCU, the algorithm deployment verification device reads a first data set output by the virtual camera, injects the first data set into the target driving algorithm deployed on the virtual MCU, and obtains an output result.

[0071] In the embodiment of the present invention, the virtual camera can be understood as a camera implemented by software, which simulates the functions of a real camera, but the data comes from software generation or processing. The software of the virtual camera is usually installed on a physical host.

[0072] In an embodiment of the present invention, the algorithm deployment verification device can read the first data set generated by the virtual camera simulation from the physical host, and then inject the read first data set into the target driving algorithm deployed on the virtual MCU to simulate the driving situation of the automatic driving algorithm based on camera data in the real scene.

[0073] In an embodiment of the present invention, the output result of the target driving algorithm can be understood as the driving decision result output by the target driving algorithm after making judgments based on the camera data of the virtual camera, such as acceleration, deceleration, steering, lane changing, parking, etc.; the specific output result can be determined based on actual conditions, and the embodiment of the present invention does not make specific limitations here.

[0074] Step S303: Generate a control signal based on the output result, and verify the accuracy of the target driving algorithm through the control signal.

[0075] In an embodiment of the present invention, after obtaining the output result, the algorithm deployment verification device generates a control signal based on the output result, and verifies the accuracy of the target driving algorithm through the control signal.

[0076] In the embodiment of the present invention, the control signal can be understood as a control instruction. For example, if the output result is acceleration, the corresponding control signal can be the accelerator pedal opening; if the output result is deceleration, the corresponding control signal can be the brake pedal pressure; if the output result is steering, the corresponding control signal can be the steering wheel angle, etc.; the specific control signal can be determined according to the output result, and the embodiment of the present invention does not make any specific limitation here.

[0077] Step S304: When the accuracy of the target driving algorithm is verified, the target driving algorithm is migrated to the physical MCU in the target vehicle.

[0078] In an embodiment of the present invention, after verifying the accuracy of the target driving algorithm through a control signal, the algorithm deployment verification device migrates the target driving algorithm to a physical MCU in the target vehicle if the accuracy of the target driving algorithm is verified.

[0079] In an embodiment of the present invention, after the accuracy of the target driving algorithm deployed on the virtual MCU is verified, it is characterized that the target driving algorithm has passed the test. At this time, only part of the information needs to be modified to migrate the target driving algorithm on the virtual MCU to the physical MCU.

[0080] Based on the above embodiment, the algorithm deployment verification device needs to perform the following steps before deploying the target driving algorithm to the virtual microcontroller unit MCU: obtaining an initial driving algorithm; converting the model format of the initial driving algorithm into a binary format, and performing algorithm preprocessing on the initial driving algorithm to obtain a target driving algorithm; the preprocessing at least includes reconstructing the network structure of the initial driving algorithm and performing operator optimization on the initial driving algorithm.

[0081] In the embodiment of the present invention, taking the PilotNet model as an example, the parameters of each layer of the PilotNet model are shown in Table 1:

[0082] Table 1 Parameters of each layer of the PilotNet model

[0083] layer Dimensions Step Length parameter Convolutional layer 1 5x5x3x24 1x2x2x1 1800 Convolutional Layer 2 5x5x24x36 1x2x2x1 21600 Convolutional layer 3 5x5x36x48 1x2x2x1 43200 Convolutional layer 4 3x3x48x64 1x1x1x1 27648 Convolutional layer 5 3x3x64x64 1x1x1x1 36864 Fully connected layer 1 1152x1164 1340928 Fully connected layer 2 1164x100 116400 Fully connected layer 3 100x50 5000 Fully connected layer 4 50x10 500 Fully connected layer 5 10x1 10 Total: 1593950

[0084] It should be noted that the original PilotNet model is in tensorflow format. In addition to the necessary parameters, it also contains various network structure information. The algorithm size is about 39M. However, after converting the model format of the PilotNet model to binary format, only the parameters of each layer need to be saved. Assuming that it is saved in float type, the algorithm size is about 6.1M.

[0085] In the embodiment of the present invention, taking the PilotNet model as an example, the binary format of the PilotNet model is shown in Table 2:

[0086] Table 2 Binary format of the PilotNet model

[0087]

[0088] In an embodiment of the present invention, still taking the PilotNet model as an example, the conversion process of the binary format is: first, traverse the PilotNet model in tensorflow format, and collect the parameters of each layer of the PilotNet model in sequence according to the storage order, and then write the parameters of each convolution layer in the binary file in sequence: shape_conv (convolution layer shape), strides_conv (convolution step), W_conv (convolution kernel weight) and b_conv (convolution layer bias), and finally, write the parameters of each fully connected layer in the binary file in sequence: shape_fc (fully connected layer shape), W_fc (fully connected layer weight) and b_fc (fully connected layer bias).

[0089] In an embodiment of the present invention, after converting the model format of the initial driving algorithm into a binary format, the algorithm deployment verification device also needs to create a memory for the runtime of the initial driving algorithm to store the activation value of each layer of the initial driving algorithm during its operation, in preparation for subsequent algorithm calculations, back propagation, or further optimization of the algorithm.

[0090] In the embodiment of the present invention, the PilotNet model is still taken as an example. When the PilotNet model is inferring, the activation value and the weight are calculated. Since the PilotNet model is calculated layer by layer, only two runtime memories need to be created. After the calculation of the previous layer is completed, it can be reused for the calculation of the next layer.

[0091] In an embodiment of the present invention, the algorithm deployment verification device needs to rebuild the network structure of the initial driving algorithm and optimize the operators of the initial driving algorithm at the same time or after creating the memory for the initial driving algorithm to run.

[0092] In an embodiment of the present invention, still taking the PilotNet model as an example, when reconstructing the network structure of the PilotNet model, the model file of the original PilotNet model in the tensorflow format can be referred to, and the PilotNet model can be reconstructed layer by layer, which may include convolutional layers, rectified linear units (Rectified Linear Unit, ReLU) activation functions, fully connected layers, and matmul (matrix multiplication operations). It should be noted that since the reconstruction of the network structure only involves reasoning, there is no need to reconstruct the Dropout (regularization) layer in the PilotNet model.

[0093] Furthermore, operator optimization can be understood as operator fusion or operator quantization. Taking operator fusion as an example, the model usually adds a bias term to each output channel after the convolution operation. The bias term is a learnable parameter that allows the model to offset the output of each output channel, thereby increasing the flexibility of the model. At the same time, a ReLU activation function is usually introduced for each output channel. Therefore, the three operators can be fused into one operator to achieve operator optimization.

[0094] Based on the above embodiment, after the algorithm deployment verification device deploys the target driving algorithm on the virtual microcontroller unit MCU, it is also necessary to perform the following steps: start the virtual camera process on the virtual MCU; the virtual camera process includes a main thread and a first sub-thread; the first sub-thread is a software development kit SDK sub-thread; configure the main thread to listen to the first socket; the first socket is used to realize the communication between the virtual camera deployed on the first device and the virtual camera process; configure the first sub-thread to listen to the second socket; the second socket is used to realize the communication between at least two threads.

[0095] In an embodiment of the present invention, the deployment verification device of the algorithm starts the main thread in the virtual camera process, so that the main thread listens to the first socket, and at the same time starts the first child thread in the virtual camera process, so that the first child thread listens to the second socket; exemplarily, the first socket can be vsock (cid:port0), the second socket can be SDKvsock (cid:port1), and the first child thread can use event polling (eventpoll, epoll) multiplexing when listening to the second socket.

[0096] Based on the above embodiment, the first data set includes metadata, and the deployment verification device of the algorithm can also perform the following steps: start the virtual camera; and establish a first connection between the virtual camera and the first socket; use the first socket to receive metadata sent by the virtual camera based on the first connection; use the first child thread and the second socket to send the received metadata to the target SDK on the virtual MCU; the target SDK is an SDK used to implement camera-related operations.

[0097] In the embodiment of the present invention, the first data set of the virtual camera includes metadata and frame.

[0098] In the embodiment of the present invention, the data format of the metadata of the virtual camera is shown in Table 3:

[0099] Table 3 Data format of virtual camera metadata

[0100]

[0101] In an embodiment of the present invention, the virtual camera is deployed on the first device, not in the virtual MCU. Therefore, when the virtual camera is started, first, it is necessary to establish a connection between the virtual camera and the first socket vsock (cid:port0). As a result, the virtual MCU can obtain the first data set of the virtual camera through the main thread of the virtual camera process. Then, the virtual camera can send metadata to the first socket vsock (cid:port0). At this time, vsock (cid:port0) receives the metadata in the main thread and saves it. Finally, the first child thread first obtains the camera information of the virtual camera through the Video Capture function in the target SDK, and then based on the second socket, searches for the metadata corresponding to the camera information from all the saved metadata, and sends the metadata to the target SDK.

[0102] In the embodiment of the present invention, the target SDK is a camera SDK; the specific target SDK can be selected according to actual conditions, and the embodiment of the present invention does not make any specific limitation here.

[0103] In an embodiment of the present invention, in the process of executing the above-mentioned sending metadata corresponding to the virtual camera to the target SDK, the first sub-thread also needs to create a circular queue for storing frame data corresponding to the virtual camera, wherein the path of the circular queue is jointly determined by the identifier of the virtual camera, i.e., sensor_id, and the identifier of the target SDK, i.e., camera_sdk_id.

[0104] Based on the above embodiment, the first data set includes frame data, and the algorithm deployment verification device can also perform the following steps: start the second sub-thread corresponding to the virtual camera; the second sub-thread is used to process the frame data of the virtual camera; use the second sub-thread to receive the frame data sent by the virtual camera based on the first connection, and write the frame data into a preset circular queue; the preset circular queue is created for the first sub-thread.

[0105] In the embodiment of the present invention, when the virtual camera is started, a second sub-thread (frame sub-thread) is started at the same time to process the frame data of the virtual camera.

[0106] In the embodiment of the present invention, the data format of the frame data of the virtual camera is shown in Table 4:

[0107] Table 4 Data format of the frame data of the virtual camera

[0108]

[0109] In an embodiment of the present invention, after sending the metadata, the virtual camera continues to send frame data to the first socket vsock (cid:port0). At this time, the second sub-thread (frame sub-thread) continues to receive the frame data sent by the virtual camera from the first connection, and writes the received frame data into the corresponding circular queue.

[0110] Based on the above embodiment, the algorithm deployment verification device writes frame data into a preset circular queue, including the following steps: using the second sub-thread to obtain the preset circular queue; using the second sub-thread to call a preset enqueue function to write the frame data into the preset circular queue.

[0111] In an embodiment of the present invention, a circular queue is implemented by two shared memories, one shared memory is used to store metadata information of the circular queue, and the other shared memory is used to store specific elements stored in the circular queue. In order to achieve data synchronization between the two shared memories, Semaphore (named semaphore) in the Linux system is adopted.

[0112] In the embodiment of the present invention, the data format of the metadata of the circular queue is shown in Table 5:

[0113] Table 5 Data format of metadata of circular queue

[0114]

[0115] In the embodiment of the present invention, the metadata information of the circular queue includes at least element_size (element size), count (number), front (front of the queue), and rear (end of the queue) as shown in Table 5.

[0116] In the embodiment of the present invention, the data format of the specific elements stored in the circular queue is shown in Table 6:

[0117] Table 6 Data format of specific elements stored in circular queue

[0118]

[0119] In an embodiment of the present invention, when the second sub-thread calls the preset enqueue function to write frame data into the preset circular queue, it is first necessary to obtain the circular queue created for the virtual camera, and then call the preset enqueue function of the corresponding circular queue to write each frame data into the circular queue; it should be noted that according to the design of the circular queue, if the circular queue has no free space, the oldest frame data will be directly overwritten, that is, only the latest frame data of the virtual camera will be saved.

[0120] In the embodiment of the present invention, the preset enqueue function may be an enqueue function; the specific preset enqueue function may be selected according to actual conditions, and the embodiment of the present invention does not make any specific limitation here.

[0121] In an optional embodiment of the present invention, part of the operation code of the circular queue is as follows:

[0122]

[0123]

[0124] Based on the above embodiment, after the algorithm deployment verification device writes the frame data into the preset circular queue, the following steps may be further performed: using the read function in the target SDK to cyclically read the frame data from the preset circular queue.

[0125] In an embodiment of the present invention, the deployment verification device of the algorithm calls the read function (read function) in the target SDK to continuously read frame data from the circular queue. According to the design of the circular queue, the oldest frame data in the circular queue is read, and the frame data is delayed at most by the first number; the first number is less than the maximum storage number of the circular queue.

[0126] Based on the above embodiment, the algorithm deployment verification device reads the first data set output by the virtual camera, injects the first data set into the target driving algorithm deployed on the virtual MCU, and obtains the output result, including the following steps: reading the metadata and frame data of the virtual camera from the target SDK; injecting the metadata and frame data into the target driving algorithm deployed on the virtual MCU to obtain the output result.

[0127] In an embodiment of the present invention, since the first sub-thread sends the metadata of the virtual camera to the target SDK in advance, the algorithm deployment verification device needs to read the metadata of the virtual camera from the target SDK, mainly to obtain the identifier of the virtual camera. Secondly, since the frame data of the virtual camera is stored in a circular queue, it is necessary to cyclically read the frame data of the virtual camera from the circular queue through the target SDK. At this time, the target SDK has both the metadata and frame data of the virtual camera. The target SDK can input the metadata and frame data of the virtual camera into the target driving algorithm to obtain the output result.

[0128] Based on the above embodiment, the algorithm deployment verification device verifies the accuracy of the target driving algorithm through a control signal, including the following steps: using the target SDK and the second socket to forward the control signal to the third sub-thread; using the third sub-thread to encapsulate the control signal into a preset format, and sending the encapsulated control signal to the first monitoring program; using the association relationship between the first monitoring program on the virtual MCU and the second monitoring program on the first device, the encapsulated control signal is sent to the second monitoring program, so that the second monitoring program forwards the encapsulated control signal to the simulation software deployed on the first device to verify the accuracy of the target driving algorithm.

[0129] In an embodiment of the present invention, communication between a first device on which simulation software is installed and a virtual MCU can be implemented based on CtuCAN and SocketCAN in a Linux system. The specific steps are as follows: first, a CANbus device, namely SocketCAN, is created on the first device. When the virtual MCU is started, corresponding startup parameters are configured. At this time, the corresponding VCAN device, namely CtuCAN, can be seen inside the virtual MCU. At this time, the CANbus device on the first device is monitored to obtain the control signal sent from the virtual MCU, and then forward it to the simulation software, such as the carla simulation engine.

[0130] In an embodiment of the present invention, after generating a control signal according to the output result of the target driving algorithm, the algorithm deployment verification device calls send_control in the target SDK to send the control signal to the third sub-thread, that is, the VCAN sub-thread corresponding to the VCAN device. After receiving the control signal, the VCAN sub-thread encapsulates the control signal into a CAN format message and sends it to the CtuCAN in the domain controller. At this time, the SocketCAN monitoring program on the host receives the control signal and forwards it to the simulation software.

[0131] In the embodiment of the present invention, reference Figure 4The autonomous driving algorithm is first deployed on the virtual MCU, and the virtual camera data of the virtual camera is used to verify the autonomous driving algorithm. After the verification, the autonomous driving algorithm is migrated to the physical MCU1, physical MCU2 and physical MCU3, so that the physical MCU1, physical MCU2 and physical MCU3 can use the autonomous driving algorithm based on the corresponding camera 1, camera 2 and camera 3.

[0132] It is understandable that the virtual MCU is implemented in C language to facilitate subsequent migration. Since most physical MCUs provide C language version of the development interface and support the most basic logical operations (addition, subtraction, multiplication and division), and since the target driving algorithm has been verified on the virtual MCU, it only needs to modify the code for obtaining the virtual camera and the code for sending control signals to migrate the verified target driving algorithm to the physical MCU that meets the above conditions.

[0133] An embodiment of the present invention provides a deployment verification method for an algorithm, the method comprising: deploying a target driving algorithm on a virtual microcontroller unit MCU; reading a first data set output by a virtual camera, injecting the first data set into the target driving algorithm deployed on the virtual MCU, and obtaining an output result; generating a control signal based on the output result, and verifying the accuracy of the target driving algorithm through the control signal; if the accuracy of the target driving algorithm is verified, migrating the target driving algorithm to a physical MCU in a target vehicle; by adopting the above implementation scheme, when deploying the driving algorithm, there is no need to consider the adaptability of the physical MCU, and the driving algorithm can be directly deployed on the virtual MCU, which can expand the selection range of the physical MCU. At the same time, the driving algorithm can also be tested and verified on the virtual MCU, and migrated after the verification is passed, thereby reducing the verification cost of the driving algorithm.

[0134] The above introduces the deployment verification method of the algorithm provided in the embodiment of the present application. To facilitate understanding of the embodiment of the present application, the following introduces possible implementation schemes of the deployment verification of the algorithm applicable to the embodiment of the present application in actual application scenarios.

[0135] Take the PilotNet model as an example, refer to Figure 5 .

[0136] 1. Parse the model format of the PilotNet model, that is, convert the tensorflow format of the PilotNet model into binary format, refer to Figure 5 Step S501 in .

[0137] Specifically, traverse the PilotNet model in tensorflow format, collect the parameters of each layer of the PilotNet model in order of storage, and then write the parameters of each convolution layer in the binary file in turn: shape_conv (convolution layer shape), strides_conv (convolution step size), W_conv (convolution kernel weight) and b_conv (convolution layer bias). Finally, write the parameters of each fully connected layer in the binary file in turn: shape_fc (fully connected layer shape), W_fc (fully connected layer weight) and b_fc (fully connected layer bias).

[0138] 2. Create the memory for the PilotNet model runtime, refer to Figure 5 Step S502 in .

[0139] Specifically, when the PilotNet model is inferring, the activation value and weight are calculated. Since the PilotNet model is calculated layer by layer, only two runtime memories need to be created. After the calculation of the previous layer is completed, it can be reused for the calculation of the next layer.

[0140] 3. Reconstruct the network structure of the PilotNet model, refer to Figure 5 Step S503 in .

[0141] Specifically, referring to the model file of the original PilotNet model in tensorflow format, the PilotNet model is reconstructed layer by layer, which may include convolutional layers, rectified linear unit (ReLU) activation functions, fully connected layers, and matmul (matrix multiplication operations). It should be noted that since the reconstruction of the network structure only involves reasoning, there is no need to reconstruct the Dropout (regularization) layer in the PilotNet model.

[0142] 4. Optimize the operator of PilotNet model, refer to Figure 5 Step S504 in .

[0143] Specifically, operator optimization can be understood as operator fusion or operator quantization. Taking operator fusion as an example, the model usually adds a bias term to each output channel after the convolution operation. The bias term is a learnable parameter that allows the model to offset the output of each output channel, thereby increasing the flexibility of the model. At the same time, a ReLU activation function is usually introduced for each output channel. Therefore, the three operators can be fused into one operator to achieve operator optimization.

[0144] 5. Read the virtual camera metadata data from the camera SDK.

[0145] Start the main thread in the virtual camera process and make the main thread listen to the first socket vsock (cid:port0), refer to Figure 5 Step S505 in the process; start the SDK subthread (the first subthread in the above embodiment) in the virtual camera process, use epoll multiplexing to listen to the second socket SDK vsock (cid:port1), refer to Figure 5 Step S506 in .

[0146] Specifically, the virtual camera metadata data processing flow is as follows:

[0147] (1) Start the virtual camera on the host (the first device in the above embodiment) and establish a connection between the virtual camera and the first socket vsock (cid:port0). Figure 5 Step S507 in .

[0148] (2) The virtual camera sends metadata data to the first socket vsock (cid:port0).

[0149] (3) vsock (cid:port0) receives metadata data in the main thread and saves it.

[0150] (4) Deployment of Algorithm The verification device calls the VideoCapture function in the camera SDK (the target SDK in the above embodiment) to obtain the information of the virtual camera, for example, the identification information of the virtual camera.

[0151] (5) The SDK child thread creates a circular queue corresponding to the virtual camera (the path is determined by sensor_id and camera_sdk_id), refer to Figure 5 Step S508 in .

[0152] (6) The SDK child thread searches the metadata for the data corresponding to the virtual camera and returns it to the cameraSDK.

[0153] 6. Through the camera SDK, loop to read the virtual camera frame data.

[0154] Specifically, the virtual camera frame data processing flow is as follows:

[0155] (1) The virtual camera continuously sends frame data to the first socket vsock (cid:port0).

[0156] (2) The frame sub-thread (the second sub-thread in the above embodiment) continuously receives frame data from the corresponding camera connection, referring to Figure 5 Step S509 in .

[0157] (3) The frame sub-thread obtains the circular queue created by the SDK sub-thread in the above metadata data processing flow.

[0158] (4) The frame sub-thread calls the enqueue function of the corresponding circular queue to write each frame data into the circular queue. Figure 5 According to the design of the circular queue, if there is no free space in the circular queue, the oldest frame data will be directly overwritten, that is, only the latest frame data of the virtual camera will be saved.

[0159] (5) The algorithm deployment verification device calls the read function in the target SDK to continuously read frame data from the circular queue. Figure 5 In step S511, according to the design of the circular queue, the oldest frame data in the circular queue is read, and the frame data is delayed by at most a first number; the first number is less than the maximum storage number of the circular queue.

[0160] (6) Input the virtual camera metadata data and frame data into the PilotNet model, refer to Figure 5 Step S512 in .

[0161] (7) Generate a control signal based on the output result.

[0162] (8) Call the camera SDK to send a control signal to CtuCAN (the first monitoring program in the above embodiment) on the host. Figure 5 Step S513 in; after receiving the control signal, CtuCAN sends the control signal to SocketCAN on the host (the second monitoring program in the above embodiment), refer to Figure 5 Step S514 in SocketCAN; SocketCAN inputs the control signal into the simulation software for algorithm verification, refer to Figure 5 Step S515 in .

[0163] (9) After the PilotNet model is verified, migrate the PilotNet model to the physical MCU. Figure 5 Step S516 in .

[0164] Based on the above embodiment, in another embodiment of the present invention, a deployment verification device for an algorithm is provided. Figure 6 A schematic diagram of the structure of a deployment verification device for an algorithm provided in an embodiment of the present invention is shown in FIG. Figure 6 As shown, the deployment verification device 6 of the algorithm includes:

[0165] A deployment unit 600, used to deploy the target driving algorithm to the virtual micro control unit MCU;

[0166] A reading unit 601 is used to read a first data set output by a virtual camera, and inject the first data set into a target driving algorithm deployed on the virtual MCU to obtain an output result;

[0167] A generating unit 602, configured to generate a control signal based on the output result, and verify the accuracy of the target driving algorithm through the control signal;

[0168] The migration unit 603 is used to migrate the target driving algorithm to a physical MCU in the target vehicle when the accuracy of the target driving algorithm is verified.

[0169] Optionally, the algorithm deployment verification device 6 further includes: an acquisition unit and a conversion unit;

[0170] The acquisition unit is used to acquire an initial driving algorithm;

[0171] The conversion unit is used to convert the model format of the initial driving algorithm into a binary format, and perform algorithm preprocessing on the initial driving algorithm to obtain the target driving algorithm; the preprocessing at least includes reconstructing the network structure of the initial driving algorithm and performing operator optimization on the initial driving algorithm.

[0172] Optionally, the algorithm deployment verification device 6 further includes: a startup unit and a configuration unit;

[0173] The startup unit is used to start the virtual camera process on the virtual MCU; the virtual camera process includes a main thread and a first sub-thread; the first sub-thread is a software development kit SDK sub-thread;

[0174] The configuration unit is used to configure the main thread to listen to the first socket; the first socket is used to implement communication between the virtual camera deployed on the first device and the virtual camera process;

[0175] The configuration unit is further used to configure the first sub-thread to monitor a second socket; the second socket is used to implement communication between at least two threads.

[0176] Optionally, the algorithm deployment verification device 6 further includes: a control unit;

[0177] The startup unit is further used to start the virtual camera; and establish a first connection between the virtual camera and the first socket;

[0178] The control unit is configured to receive, by using the first socket, metadata sent by the virtual camera based on the first connection;

[0179] The control unit is further used to use the first sub-thread and the second socket to send the received metadata to the target SDK on the virtual MCU; the target SDK is an SDK for implementing camera-related operations.

[0180] Optionally, the starting unit is further used to start a second sub-thread corresponding to the virtual camera; the second sub-thread is used to process the frame data of the virtual camera;

[0181] The control unit is further used to use the second sub-thread to receive frame data sent by the virtual camera based on the first connection, and write the frame data into a preset circular queue; the preset circular queue is created for the first sub-thread.

[0182] Optionally, the control unit is further used to use the second sub-thread to obtain the preset circular queue; use the second sub-thread to call a preset enqueue function to write the frame data into the preset circular queue.

[0183] Optionally, the control unit is further used to utilize a read function in the target SDK to cyclically read the frame data from the preset circular queue.

[0184] Optionally, the reading unit 601 is also used to read the metadata and the frame data of the virtual camera from the target SDK; inject the metadata and the frame data into the target driving algorithm deployed on the virtual MCU to obtain an output result.

[0185] Optionally, the control unit is also used to forward the control signal to a third sub-thread using the target SDK and the second socket; encapsulate the control signal into a preset format using the third sub-thread, and send the encapsulated control signal to the first monitoring program; and utilize the association relationship between the first monitoring program on the virtual MCU and the second monitoring program on the first device to send the encapsulated control signal to the second monitoring program, so that the second monitoring program can forward the encapsulated control signal to the simulation software deployed on the first device to verify the accuracy of the target driving algorithm.

[0186] An embodiment of the present invention provides an algorithm deployment verification device, the device comprising: a deployment unit, used to deploy a target driving algorithm on a virtual microcontroller unit MCU; a reading unit, used to read a first data set output by a virtual camera, and inject the first data set into the target driving algorithm deployed on the virtual MCU to obtain an output result; a generation unit, used to generate a control signal based on the output result, and verify the accuracy of the target driving algorithm through the control signal; a migration unit, used to migrate the target driving algorithm to a physical MCU in a target vehicle when the accuracy of the target driving algorithm is verified; by adopting the above implementation scheme, when deploying the driving algorithm, there is no need to consider the adaptability of the physical MCU, and the driving algorithm can be directly deployed on the virtual MCU, which can expand the selection range of the physical MCU. At the same time, the driving algorithm can also be tested and verified on the virtual MCU, and migrated after the verification is passed, thereby reducing the verification cost of the driving algorithm.

[0187] Figure 7 A schematic diagram of the structure of a deployment verification device for an algorithm provided in an embodiment of the present invention. In practical applications, based on the same disclosure concept of the above embodiments, Figure 7 As shown, the algorithm deployment verification device 7 of this embodiment includes: a processor 700 , a memory 701 and a communication bus 702 .

[0188] In the process of a specific embodiment, the above-mentioned deployment unit 600, reading unit 601, generation unit 602, migration unit 603, acquisition unit, conversion unit, startup unit, configuration unit and control unit can be implemented by a processor 700 located on the deployment verification device 7 of the algorithm, and the above-mentioned processor 700 can be at least one of an application-specific integrated circuit (ASIC, Application Specific Integrated Circuit), a digital signal processor (DSP, Digital Signal Processor), a digital signal processing image processing device (DSPD, Digital Signal Processing Device), a programmable logic image processing device (PLD, Programmable Logic Device), a field programmable gate array (FPGA, Field Programmable Gate Array), a CPU, a controller, a microcontroller, and a microprocessor. It can be understood that for the deployment verification device 7 of different algorithms, the electronic device used to implement the above-mentioned processor function can also be other, and this embodiment is not specifically limited.

[0189] In the embodiment of the present invention, the communication bus 702 is used to realize the connection communication between the processor 700 and the memory 701; when the processor 700 executes the running program stored in the memory 701, the deployment verification method of the following algorithm is implemented:

[0190] Deploy the target driving algorithm to the virtual microcontroller unit MCU;

[0191] Reading a first data set output by the virtual camera, injecting the first data set into a target driving algorithm deployed on the virtual MCU, and obtaining an output result;

[0192] generating a control signal based on the output result, and verifying the accuracy of the target driving algorithm through the control signal;

[0193] When the accuracy of the target driving algorithm is verified, the target driving algorithm is migrated to a physical MCU in the target vehicle.

[0194] Optionally, the processor 700 is also used to obtain an initial driving algorithm; convert the model format of the initial driving algorithm into a binary format, and perform algorithm preprocessing on the initial driving algorithm to obtain the target driving algorithm; the preprocessing at least includes reconstructing the network structure of the initial driving algorithm and performing operator optimization on the initial driving algorithm.

[0195] Optionally, the processor 700 is also used to start a virtual camera process on the virtual MCU; the virtual camera process includes a main thread and a first sub-thread; the first sub-thread is a software development kit SDK sub-thread; the main thread is configured to listen to a first socket; the first socket is used to realize communication between the virtual camera deployed on the first device and the virtual camera process; the first sub-thread is configured to listen to a second socket; the second socket is used to realize communication between at least two threads.

[0196] Optionally, the processor 700 is also used to start the virtual camera; and establish a first connection between the virtual camera and the first socket; use the first socket to receive metadata sent by the virtual camera based on the first connection; use the first sub-thread and the second socket to send the received metadata to the target SDK on the virtual MCU; the target SDK is an SDK used to implement camera-related operations.

[0197] Optionally, the processor 700 is also used to start a second sub-thread corresponding to the virtual camera; the second sub-thread is used to process the frame data of the virtual camera; the second sub-thread is used to receive the frame data sent by the virtual camera based on the first connection, and write the frame data into a preset circular queue; the preset circular queue is created for the first sub-thread.

[0198] Optionally, the processor 700 is further configured to use the second sub-thread to obtain the preset circular queue; and use the second sub-thread to call a preset enqueue function to write the frame data into the preset circular queue.

[0199] Optionally, the processor 700 is further configured to utilize a read function in the target SDK to cyclically read the frame data from the preset circular queue.

[0200] Optionally, the processor 700 is also used to read the metadata and the frame data of the virtual camera from the target SDK; inject the metadata and the frame data into the target driving algorithm deployed on the virtual MCU to obtain an output result.

[0201] Optionally, the processor 700 is also used to forward the control signal to a third sub-thread using the target SDK and the second socket; encapsulate the control signal into a preset format using the third sub-thread, and send the encapsulated control signal to the first monitoring program; and utilize the association relationship between the first monitoring program on the virtual MCU and the second monitoring program on the first device to send the encapsulated control signal to the second monitoring program, so that the second monitoring program can forward the encapsulated control signal to the simulation software deployed on the first device to verify the accuracy of the target driving algorithm.

[0202] An embodiment of the present invention provides a storage medium having a computer program stored thereon. The computer-readable storage medium stores one or more programs. The one or more programs can be executed by one or more processors and applied to an algorithm deployment verification device. The computer program implements the algorithm deployment verification method as described above.

[0203] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage and optical storage, etc.) containing computer-usable program code.

[0204] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0205] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0206] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0207] The above is only a specific embodiment of the present invention, but the protection scope of the present invention is not limited thereto. Any changes or substitutions that can be easily thought of by a person skilled in the art within the technical scope disclosed by the present invention should be included in the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims

1. A deployment verification method for an algorithm, characterized in that: The method comprises: Deploy the target driving algorithm to the virtual microcontroller unit MCU; Reading a first data set output by the virtual camera, injecting the first data set into a target driving algorithm deployed on the virtual MCU, and obtaining an output result; generating a control signal based on the output result, and verifying the accuracy of the target driving algorithm through the control signal; When the accuracy of the target driving algorithm is verified, the target driving algorithm is migrated to a physical MCU in the target vehicle.

2. The algorithm deployment verification method according to claim 1, characterized in that: Before deploying the target driving algorithm on the virtual microcontroller unit MCU, the method further includes: Obtaining an initial driving algorithm; The model format of the initial driving algorithm is converted into a binary format, and the initial driving algorithm is preprocessed to obtain the target driving algorithm; the preprocessing at least includes reconstructing the network structure of the initial driving algorithm and optimizing the operator of the initial driving algorithm.

3. The algorithm deployment verification method according to claim 1 or 2, characterized in that: After deploying the target driving algorithm on the virtual microcontroller unit MCU, the method further includes: Starting a virtual camera process on the virtual MCU; the virtual camera process includes a main thread and a first sub-thread; the first sub-thread is a software development kit SDK sub-thread; Configuring the main thread to listen to a first socket; the first socket is used to implement communication between the virtual camera deployed on the first device and the virtual camera process; The first subthread is configured to listen to a second socket; the second socket is used to implement communication between at least two threads.

4. The algorithm deployment verification method according to claim 3, characterized in that: The first data set includes metadata, and the method further includes: Starting the virtual camera; and establishing a first connection between the virtual camera and the first socket; Receiving, using the first socket, metadata sent by the virtual camera based on the first connection; The received metadata is sent to a target SDK on the virtual MCU by using the first sub-thread and the second socket; the target SDK is an SDK for implementing camera-related operations.

5. The algorithm deployment verification method according to claim 4, characterized in that: The first data set includes frame data, and the method further includes: Starting a second sub-thread corresponding to the virtual camera; the second sub-thread is used to process frame data of the virtual camera; The second sub-thread is used to receive the frame data sent by the virtual camera based on the first connection, and the frame data is written into a preset circular queue; the preset circular queue is created for the first sub-thread.

6. The algorithm deployment verification method according to claim 5, characterized in that: The step of writing the frame data into a preset circular queue comprises: Using the second sub-thread to obtain the preset circular queue; The second sub-thread is used to call a preset enqueue function to write the frame data into a preset circular queue.

7. The algorithm deployment verification method according to claim 5 or 6, characterized in that: After writing the frame data into the preset circular queue, the method further includes: The frame data is cyclically read from the preset circular queue using a read function in the target SDK.

8. The algorithm deployment verification method according to claim 7, characterized in that: The reading of the first data set output by the virtual camera and injecting the first data set into the target driving algorithm deployed on the virtual MCU to obtain an output result includes: Reading the metadata and the frame data of the virtual camera from the target SDK; The metadata and the frame data are injected into a target driving algorithm deployed on a virtual MCU to obtain an output result.

9. The algorithm deployment verification method according to claim 1, characterized in that: The verifying the accuracy of the target driving algorithm by the control signal includes: forwarding the control signal to the third sub-thread using the target SDK and the second socket; Encapsulating the control signal into a preset format using the third sub-thread, and sending the encapsulated control signal to the first monitoring program; By utilizing the association relationship between the first monitoring program on the virtual MCU and the second monitoring program on the first device, the packaged control signal is sent to the second monitoring program, so that the second monitoring program forwards the packaged control signal to the simulation software deployed on the first device to verify the accuracy of the target driving algorithm.

10. An algorithm deployment verification device, characterized in that: The device comprises: A deployment unit, used to deploy the target driving algorithm onto the virtual microcontroller unit MCU; A reading unit, used for reading a first data set output by the virtual camera, injecting the first data set into a target driving algorithm deployed on the virtual MCU, and obtaining an output result; a generating unit, configured to generate a control signal based on the output result, and verify the accuracy of the target driving algorithm through the control signal; A migration unit is used to migrate the target driving algorithm to a physical MCU in a target vehicle when the accuracy of the target driving algorithm is verified.

11. A deployment verification device for an algorithm, characterized in that: The device comprises: a processor, a memory and a communication bus; when the processor executes the running program stored in the memory, the method according to any one of claims 1 to 9 is implemented.

12. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor, the method according to any one of claims 1 to 9 is implemented.

Images