An automatic driving software scheme adaptation method and device, electronic equipment and medium

Abstract

The application provides an automatic driving software scheme adaptation method and device, electronic equipment and medium, the method comprises the following steps: acquiring a function instruction, hardware resources of a vehicle and processing resources of the vehicle; determining an instruction type based on the function instruction, wherein the instruction type at least comprises a perception type, a planning type and a control type; matching a corresponding target code library based on the instruction type, wherein the target code library stores a plurality of function codes and a preset resource verification condition corresponding to each function code; verifying the hardware resources and the processing resources of the vehicle based on the preset resource verification condition; if the verification is passed, determining the function code corresponding to the preset resource verification condition as a target code; generating a target software scheme according to the target code and outputting the target software scheme. The automatic driving software scheme adaptation method solves the technical problem that the automatic driving software scheme cannot be adapted when deployed on vehicles with different configurations.

Description

Technical Field

[0001] This application relates to the field of autonomous driving technology, specifically to an autonomous driving software solution adaptation method, device, electronic device, and medium. Background Technology

[0002] With the development of autonomous driving systems, multiple levels of autonomous driving products have emerged. Each level of autonomous driving product has different requirements for autonomous driving functions, as well as for the functionality and performance of sensors, actuators, and autonomous driving domain controllers. For example, Level 2 autonomous driving functions are required for tasks such as ordinary parking and highway driving. This necessitates that the vehicle be able to perceive its surroundings, such as other vehicles and road signs. Therefore, the vehicle needs to be equipped with hardware devices such as sensors, radar, and cameras to deploy this level of autonomous driving software solution. Higher levels of autonomous driving have even more demanding requirements, necessitating even greater vehicle hardware resources.

[0003] Because the functional requirements and hardware resource requirements of each level of autonomous driving product are different, there are incompatibility issues when deploying autonomous driving software solutions on vehicles with different configurations. Summary of the Invention

[0004] In view of the shortcomings of the above-mentioned related technologies, this application provides an autonomous driving software solution adaptation method, device, electronic device and medium to solve the technical problem of incompatibility when deploying autonomous driving software solutions on vehicles with different configurations.

[0005] This application provides an autonomous driving software solution adaptation method, which includes acquiring functional instructions, vehicle hardware resources, and vehicle processing resources; determining instruction types based on the functional instructions, wherein the instruction types include at least perception type, planning type, and control type; and matching corresponding target code libraries based on the instruction types, wherein the target code library stores multiple functional codes and preset resource verification conditions corresponding to each functional code.

[0006] The hardware resources and processing resources of the vehicle are verified based on the preset resource verification conditions. If the verification passes, the function code corresponding to the preset resource verification conditions is determined as the target code. The target software solution is generated and output based on the target code.

[0007] In one embodiment of this application, multiple function codes are acquired, and the input and output interfaces of each function code are unified; based on the function type of the function code, the function code is stored in a preset perception code library, a preset planning code library, and a preset control code library.

[0008] In one embodiment of this application, if the instruction type is the perception type, the hardware resources of the vehicle are verified based on the preset resource verification conditions; if the number of hardware resources is greater than or equal to the preset number of hardware resources in the preset resource verification conditions, the verification passes, and the function code corresponding to the preset resource verification conditions is determined as the target code.

[0009] In one embodiment of this application, if the instruction type is the planning type or the control type, the processing resources of the vehicle are verified based on the preset resource verification conditions. The processing resources include computing resources, memory resources, and bandwidth resources. If the computing resources are greater than or equal to the preset computing resources of the preset resource verification conditions, the memory resources are greater than or equal to the preset memory resources of the preset resource verification conditions, and the bandwidth resources are greater than or equal to the preset bandwidth resources of the preset resource verification conditions, then the function code corresponding to the preset resource verification conditions is determined as the target code.

[0010] In one embodiment of this application, if multiple target codes exist, the target codes are filtered based on the preset resource verification conditions, which include hardware resources, computing resources, memory resources, and bandwidth resources. If the instruction type is the planning type or the control type, the target code with the smallest sum of computing resources, memory resources, and bandwidth resources is determined as the final target code. If the instruction type is the perception type, the target code with the smallest hardware resource requirement among the preset resource verification conditions is determined as the final target code.

[0011] In one embodiment of this application, simulated vehicle information and simulated environment information are obtained, and a simulated test environment is obtained based on the simulated vehicle information and the simulated environment information; the target software solution is run in the simulated test environment to obtain running results and performance results; the test results of the target software solution are obtained based on the running results and performance results, and if the test results are passed, the target software solution is output.

[0012] In one embodiment of this application, if the running result matches the function instruction, the running result is considered passed; if the performance result exceeds a preset performance threshold, the performance result is considered passed; if both the running result and the performance result are considered passed, the test result is considered passed.

[0013] In one embodiment of this application, a design verification report is generated based on the running results and the performance results, and the design verification report and the target software solution are output.

[0014] Embodiments of this application also provide an autonomous driving software solution adaptation device. The device includes: an instruction acquisition module, used to acquire function instructions, vehicle hardware resources, and vehicle processing resources, and determine instruction types based on the function instructions, wherein the instruction types include at least perception type, planning type, and control type; a code library matching module, used to match a corresponding target code library based on the instruction type, wherein the target code library stores multiple function codes and preset resource verification conditions corresponding to each function code; a code verification module, used to verify the vehicle's hardware resources and processing resources based on the preset resource verification conditions, and if the verification passes, determine the function code corresponding to the preset resource verification conditions as the target code; and a code execution module, used to run and integrate the target code to generate target software in response to the function instructions.

[0015] Embodiments of this application also provide an electronic device, which includes one or more processors and a storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the electronic device enables the autonomous driving software solution adaptation method as described in any of the above embodiments.

[0016] Embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a computer's processor, causes the computer to perform the autonomous driving software solution adaptation method as described in any of the above embodiments.

[0017] The beneficial effects of this invention are as follows: The embodiments of this application provide an autonomous driving software solution adaptation method, apparatus, electronic device, and medium. The method includes acquiring function instructions, vehicle hardware resources, and vehicle processing resources; determining instruction types based on function instructions, where instruction types include at least perception, planning, and control types; matching corresponding target code libraries based on instruction types, where the target code library stores multiple function codes and preset resource verification conditions corresponding to each function code; verifying the vehicle's hardware resources and processing resources based on the preset resource verification conditions; if the verification passes, determining the function code corresponding to the preset resource verification conditions as the target code; generating and outputting a target software solution based on the target code; and filtering the target code library for vehicle-compatible target codes based on the vehicle's resources to prevent the generated software solution from being incompatible. This autonomous driving software solution adaptation method solves the technical problem of incompatibility when deploying autonomous driving software solutions on vehicles with different configurations.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0020] Figure 1 This is a schematic diagram of an autonomous driving software platform architecture shown in an exemplary embodiment of this application;

[0021] Figure 2 This is a schematic diagram illustrating an autonomous driving software solution adaptation method in an exemplary embodiment of this application;

[0022] Figure 3 This is a schematic diagram illustrating the process of building an autonomous driving software platform, as shown in an exemplary embodiment of this application.

[0023] Figure 4 This is a schematic diagram of an autonomous driving software solution adaptation code library illustrated in an exemplary embodiment of this application;

[0024] Figure 5 This is a schematic diagram illustrating hardware resource code matching management of an autonomous driving software platform, as shown in an exemplary embodiment of this application.

[0025] Figure 6 This is a schematic diagram illustrating the function code matching management of an autonomous driving software platform, as shown in an exemplary embodiment of this application.

[0026] Figure 7 This is a schematic diagram illustrating the adaptation code management of an autonomous driving software solution, as shown in an exemplary embodiment of this application.

[0027] Figure 8 This is a schematic diagram illustrating the adaptation simulation verification of an autonomous driving software solution, as shown in an exemplary embodiment of this application.

[0028] Figure 9 This is a schematic diagram of the software architecture of an autonomous driving software platform, illustrating an exemplary embodiment of this application;

[0029] Figure 10 This is a block diagram illustrating an autonomous driving software solution adaptation device in an exemplary embodiment of this application;

[0030] Figure 11 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown. Detailed Implementation

[0031] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0032] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0033] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0034] Please see Figure 1 , Figure 1 This is a schematic diagram of an autonomous driving software platform architecture shown in an exemplary embodiment of this application. Figure 1 The autonomous driving software platform architecture includes the system-on-a-chip (SoC) underlying drivers and hardware 101, the SoC operating system 102, the SoC middleware 103, parallel computing units and their algorithms 104, a microprocessor 105, a real-time processor 106, real-time processor middleware 107, real-time processor operating system 108, and real-time processor underlying drivers and hardware 109. This platform software architecture consists of four parts: a logical layered architecture, an interface between the underlying layer and middleware, software modules and data flows, and application module software interfaces. The logical layered architecture includes: a hardware and driver layer (including the SoC underlying drivers and hardware 101 and the real-time processor underlying drivers and hardware 109); an operating system layer (including the SoC operating system 102 and the real-time processor operating system 108); a middleware layer (including the SoC middleware 103 and the real-time processor middleware 107); and an application layer (including the parallel computing units and their algorithms 104, the microprocessor 105, and the real-time processor 106).

[0035] In one embodiment of this application, the autonomous driving software platform is divided into a microprocessor and a real-time processor. The microprocessor isolates the application from the impact of different operating systems, such as Linux, QNX, or VxWorks. The microprocessor mainly includes peripheral drivers, processor and memory drivers, task process management, encryption, and network communication interfaces. Image processing-related interfaces are the parts that need to be adjusted according to the project. The platformization method adapts machine learning-related image network models based on different parallel computing unit toolchains, while maintaining a unified interface for fusion and localization-related modules. The real-time processor includes peripheral drivers, processor and memory drivers, task management, encryption and power-down memory interfaces, diagnostic interfaces, inter-chip communication interfaces, vehicle signal input / output, and sensor input interfaces. The vehicle signal input / output and sensor input interfaces are software modules that need to be adjusted according to project changes; others only require parameter configuration and matching adjustments. Specifically, the vehicle input / output signals and intelligent sensors are mainly based on CAN signal transmission and reception. The platformization method adds an interface adaptation layer, i.e., a vehicle information module. Its main function is to adapt vehicle information and sensor information for different vehicle models, unifying their data interfaces and definitions to the application layer. Meanwhile, to eliminate the impact of protocol changes on project development, the work of protocol parsing can be divided into application layer development, which can meet the signal parsing needs during the development process and independently complete protocol adaptation.

[0036] Please see Figure 2 , Figure 2 This is a schematic flowchart of an autonomous driving software solution adaptation method illustrated in an exemplary embodiment of this application. In an exemplary embodiment, the autonomous driving software solution adaptation method includes at least steps S210 to S240.

[0037] Step S210: Obtain function commands, vehicle hardware resources and vehicle processing resources, and determine command types based on function commands. Command types include at least perception type, planning type and control type.

[0038] In one embodiment of this application, a hardware resource table and a processing resource table for the vehicle are established based on the vehicle model and the original manufacturer's manual by user input of a function command. The hardware resource table includes the vehicle's hardware resources, and the processing resource table includes the vehicle's processing resources. If it is detected that the vehicle has been equipped with additional hardware or processing resources, the hardware resource table and the processing resource table are updated accordingly. The vehicle's hardware resources and processing resources are obtained based on the hardware resource table and the processing resource table.

[0039] In one embodiment of this application, the hardware resource table records the current hardware resource limit of the vehicle, including the number and specific model attributes of hardware devices such as sensors and cameras in the vehicle, and the processing resource table records the current processing resource limit of the vehicle, including the vehicle's computing resources, memory resources and bandwidth resources.

[0040] In one embodiment of this application, before obtaining the function instruction, the method further includes: obtaining multiple function codes and unifying the input and output interfaces of each function code; and storing the function codes in a preset perception code library, a preset planning code library, and a preset control code library based on the function type of the function codes.

[0041] In one embodiment of this application, software modules for different scenario requirements are designed in detail according to the functional logic of autonomous driving. Modules are divided according to the smallest granularity, and the software module design is completed based on the fundamental data flow of perception fusion -> decision planning -> control. Simultaneously, within the same professional domain, different software solutions and designs are completed based on different technical approaches. Based on the algorithms of each domain, their input and output interfaces are unified, and optimizations and extensions are performed within each domain. Specifically, methods for unifying the interfaces of similar algorithm modules include: abstraction, type unification, maximization, and configuration-based management.

[0042] Step S220: Match the corresponding target code library based on the instruction type. The target code library stores multiple function codes and preset resource verification conditions corresponding to the function codes.

[0043] In one embodiment of this application, matching the corresponding functional code library based on the functional instruction includes: if the instruction type is a perception type, then a preset perception code library is determined as the target code library; if the instruction type is a planning type, then a preset planning code library is determined as the target code library; if the instruction type is a control type, then a preset control code library is determined as the target code library.

[0044] In one embodiment of this application, the preset perception code library mainly includes perception algorithms such as relative position calculation, attitude calculation, speed calculation, acceleration calculation, lane line perception, drivable area perception and positioning; the preset planning code library mainly includes path planning algorithms; and the preset control code library mainly includes vehicle control algorithms.

[0045] Step S230: Verify the vehicle's hardware resources and processing resources based on preset resource verification conditions. If the verification passes, determine the function code corresponding to the preset resource verification conditions as the target code.

[0046] In one embodiment of this application, the vehicle's hardware resources and processing resources are verified based on preset resource verification conditions. If the verification passes, the function code corresponding to the preset resource verification conditions is determined as the target code. This includes: if the instruction type is a perception type, the vehicle's hardware resources are verified based on the preset resource verification conditions; if the number of hardware resources is greater than or equal to the preset number of hardware resources in the preset resource verification conditions, the verification passes, and the function code corresponding to the preset resource verification conditions is determined as the target code.

[0047] In a specific embodiment of this application, for example, implementing the parking function requires issuing vehicle signal function commands, monitoring function commands, planning control commands, etc., to match different algorithms such as vehicle signals, monitoring functions, and planning control. Each type of algorithm has a different implementation method. A table of algorithms and their attributes is established to verify whether the vehicle's hardware resources and processing resources meet the preset resource verification conditions. When the vehicle's hardware resources and processing resources meet the resource attributes in the table (such as scheduling method, computing power requirements, and storage resource requirements), it is considered to meet the preset resource verification conditions, as shown in Table 1. Table 1 is an example table of algorithm attribute correspondence. This table establishes a mapping relationship with the corresponding algorithm library, expressing the correspondence between functional requirements and algorithms, and solutions for different algorithms within the same software function. This correspondence is used to verify whether the preset resource verification conditions are met.

[0048] The parking function illustrated in Table 1 includes code attributes that require the implementation of parking functions, including vehicle signals, monitoring, planning, and control instructions. In this embodiment, the vehicle signal and monitoring codes are included in a general code library. Table 1 shows the specific algorithm codes for several autonomous driving parking functions, along with the deployment location, programming language, scheduling method, and resource consumption of each code.

[0049] Table 1

[0050]

[0051] In one embodiment of this application, the hardware resources and processing resources of the vehicle are verified based on preset resource verification conditions. If the verification passes, the functional code corresponding to the preset resource verification conditions is determined as the target code. The method further includes: if the instruction type is a planning type or a control type, the processing resources of the vehicle are verified based on the preset resource verification conditions. The processing resources include computing resources, memory resources, and bandwidth resources. If the computing resources are greater than or equal to the preset computing resources of the preset resource verification conditions, the memory resources are greater than or equal to the preset memory resources of the preset resource verification conditions, and the bandwidth resources are greater than or equal to the preset bandwidth resources of the preset resource verification conditions, the functional code corresponding to the preset resource verification conditions is determined as the target code.

[0052] In a specific instance of this application, the hardware resources and processing resources of the vehicle are obtained. The hardware resources are the number and specific model attributes of hardware devices such as sensors and cameras in the vehicle. The processing resources are the upper limit of the vehicle's hardware processing resources (computing resources - KDMIPS, memory resources - MB, bandwidth - KB). Based on the sum of the vehicle's computing resources, memory resources, and bandwidth resources, the code in the target code library and its corresponding preset resource verification conditions are checked in the order of computing resources, memory resources, and bandwidth resources. If the vehicle's resources are greater than the computing resources, memory resources, and bandwidth resources in the preset resource verification conditions, the verification passes, and the code corresponding to the preset resource verification conditions is used as the target code. If the verification fails, the code with lower preset resource verification conditions is checked again until the verification passes or no suitable code solution can be found.

[0053] In one embodiment of this application, if multiple target codes exist, the target codes are filtered based on preset resource verification conditions, which include hardware resources, computing resources, memory resources, and bandwidth resources. If the instruction type is planning or control, the target code with the smallest sum of computing resources, memory resources, and bandwidth resources is determined as the final target code. If the instruction type is perception, the target code with the smallest hardware resource requirement among the preset resource verification conditions is determined as the final target code.

[0054] In a specific embodiment of this application, when multiple codes in a target code library pass the verification, the code with the lowest required resources is selected as the target code based on vehicle resources. For example, when the vehicle's hardware resources are a single radar and two cameras, if algorithm A requires a single radar and a single camera, and algorithm B requires a single radar and two cameras, then algorithm A is determined as the final target code.

[0055] Step S240: Generate and output the target software solution based on the target code.

[0056] In one embodiment of this application, before generating and outputting the target software solution based on the target code, the method further includes: obtaining simulation vehicle information and simulation environment information; obtaining a simulation test environment based on the simulation vehicle information and simulation environment information; running the target software solution in the simulation test environment to obtain running results and performance results; obtaining test results of the target software solution based on the running results and performance results; and outputting the target software solution if the test results are passed.

[0057] In one embodiment of this application, obtaining the test result of the target software solution based on the running results and performance results includes: if the running result matches the functional instructions, the running result is considered passed; if the performance result exceeds a preset performance threshold, the performance result is considered passed; if both the running result and the performance result are passed, the test result is considered passed. A design verification report is generated based on the running results and performance results, and the design verification report and the target software solution are output.

[0058] In one embodiment of this application, the simulation environment consists of two parts: a vehicle model and an environment model. By inputting vehicle control information, the virtual vehicle can run in the environment model. As the vehicle changes in the model, the virtual vehicle's sensors output the perception information and vehicle information from the environment model to the simulation software, thereby enabling closed-loop verification of the simulation software.

[0059] Please see Figure 3 , Figure 3 This is a schematic diagram illustrating the process of building an autonomous driving software platform, as shown in an exemplary embodiment of this application. Figure 3 The process of building an autonomous driving software platform includes four steps: designing a unified software architecture and defining unified module interfaces; developing different software modules under different hardware solutions or functional requirements, especially different solutions within each module; establishing the relationship between hardware solutions or functional requirements and modules; and developing compatible solutions and code libraries for the vehicle platform. Finally, a code management system and a visual interactive interface are developed to generate solutions based on user input.

[0060] Please see Figure 4 , Figure 4 This is a schematic diagram illustrating an autonomous driving software solution adaptation code library as shown in an exemplary embodiment of this application, such as... Figure 4 As shown, the adaptation method for autonomous driving software solutions includes pre-setting at least three code libraries, including a pre-set perception code library, a pre-set planning code library, and a pre-set control code library. Multiple functional codes are acquired in advance, and the input and output interfaces of each functional code are standardized. Based on the functional type of the functional code, it is stored in the pre-set perception code library, the pre-set planning code library, and the pre-set control code library. The code libraries use a unified code development language (C / C++). The real-time processing part uses the RTE interface to ensure interface consistency between platforms and modules. The microcontroller part uses Proto to define a unified interaction protocol. The controller communicates with external domain controllers via CAN and ETH protocols to ensure the compatibility of the code combinations.

[0061] In one embodiment of this application, the perception code library contains algorithms corresponding to different vehicle hardware resources. 1R1V represents a perception algorithm that requires a single radar and a single camera, while 5R5V12U represents a perception algorithm that requires 5 radars, 5 cameras, and 12 ultrasonic sensors.

[0062] In one specific embodiment of this application, the preset planning code library contains various algorithms, such as planning based on the tangency of circular arcs and straight lines, or a hybrid search algorithm A*. The preset control code library contains different algorithms such as PID, MPC, and LQR. The perception code library includes algorithms corresponding to different configurations. The specific algorithm input and output interfaces remain consistent; the difference lies in the required computing and storage resources and programming languages.

[0063] It's important to understand that the search algorithm, A*, is used to solve path planning problems with motion constraints. PID (Proportional-Integral-Derivative) is a common control algorithm used to adjust the system input to make it as close as possible to the desired output. MPC (Model Predictive Control) is a control strategy widely used in various systems and fields. MPC is an optimization algorithm that solves an optimization problem in each control cycle, predicting future behavior and selecting the optimal control action. LQR stands for Linear Quadratic Regulator, a term in control theory. LQR is an optimization control strategy used to design a linear controller to minimize a quadratic cost function, which typically represents the weights of system performance.

[0064] Please see Figure 5 , Figure 5 This is a schematic diagram illustrating hardware resource code matching management of an autonomous driving software platform, as shown in an exemplary embodiment of this application. Figure 5 As shown, the upper limit of the vehicle's hardware resources is input into the hardware resource code matching management system. In the code management system, each code library is matched. If the preset computing resources in the preset resource verification conditions of the code in the code library are less than the upper limit of the hardware computing resources, and the preset storage resources in the preset resource verification conditions of the code in the code library are less than the hardware storage resources, and the preset bandwidth resources in the preset resource verification conditions of the code in the code library are less than the hardware bandwidth resources, then an autonomous driving software solution is generated based on the target code. Software-in-the-loop simulation is performed on the autonomous driving software solution to generate a software engineering document including architecture design documents, recommended functions, and target code.

[0065] Please see Figure 6 , Figure 6 This is a schematic diagram illustrating the function code matching management of an autonomous driving software platform, as shown in an exemplary embodiment of this application. Figure 6As shown, the process involves inputting project requirements, obtaining functional instructions, matching the target code library in the code management system based on the functional instructions, ensuring that the type of the target code library matches the functional requirements of the functional instructions, generating an autonomous driving software solution based on the code in the target code library, performing software-in-the-loop simulation on the autonomous driving software solution, and generating a software engineering document including architecture design documents, hardware resource limits, and target code.

[0066] Please see Figure 7 , Figure 7 This is an exemplary embodiment of the present application illustrating an autonomous driving software solution adaptation code management diagram. It obtains function instructions, derives project requirements based on these instructions, and matches corresponding function code libraries and function codes according to the function instruction type, vehicle processing resources, and hardware resources. It should be noted that a single function code library may contain multiple codes that meet the requirements, but different codes have different algorithmic computing power and storage requirements, thus affecting hardware resource requirements. Appropriate algorithms can be selected based on the actual hardware configuration. Figure 7 In this process, the general code library, perception code library, planning code library and control code library are selected as target code libraries based on functional instructions. Then, the vehicle's processing resources and hardware resources are verified against the preset resource verification conditions corresponding to the functional codes in each code library. Finally, the functional codes that pass the verification are selected as target codes, and all target codes are integrated into the final software solution.

[0067] In one embodiment of this application, the preset code library also includes a general code library, which includes a vehicle information code library and a monitoring code library, etc. The perception code library contains algorithms corresponding to different vehicle hardware resources, including single radar and single camera and 5 radar, 5 cameras and 12 ultrasonic sensors, etc. The functional codes in the perception code library are filtered based on the vehicle's hardware resources.

[0068] Please see Figure 8 , Figure 8 This is a schematic diagram illustrating the adaptation simulation verification of an autonomous driving software solution, as shown in an exemplary embodiment of this application. Figure 8 The simulation verification environment consists of a vehicle model and an environment model. By inputting vehicle control information, the virtual vehicle can run in the environment model. As the vehicle changes in the environment model, the virtual vehicle's sensors output the perception information and vehicle information from the environment model to the simulated software, thereby realizing the closed-loop verification of the software. The vehicle's control signal is issued based on the final target software solution obtained from the above embodiments, thereby realizing the simulation test of the target software solution and obtaining the design verification report of the target software solution.

[0069] Please see Figure 9 , Figure 9 This is a schematic diagram of the software architecture of an autonomous driving software platform, illustrating an exemplary embodiment of this application. Figure 9 The platform software architecture consists of three parts: client 901, server 902, and code repository 903. In this embodiment, server 902 is used for status management, establishing a human-machine interface with client 901, and also for resource verification, code management, functional verification, performance simulation, and document generation. Client 901 logs into server 902 of the design system locally via a web interface. After logging in, it starts creating a project and inputting functional requirements. The design platform then filters target code in code repository 903 based on the autonomous driving software solution adaptation method described in the above embodiments to obtain the target software solution, generating a complete architecture and source code. Since it is platform-based software and interfaces, after obtaining the target software solution, it is compiled and the application function is verified in the software environment. Combined with the simulation environment, performance simulation can be further performed, ultimately obtaining a complete test report.

[0070] In the embodiments of this application, the code library of the corresponding type is determined as the target code library based on the instruction type of the function instruction, and the code library is filtered according to the functional requirements to ensure that the filtered code can complete the functional task issued by the function instruction.

[0071] In the embodiments of this application, before obtaining the function instructions, multiple function codes are obtained and the input and output interfaces of each function code are unified. This ensures that the code uniformity can more efficiently complete the deployment of autonomous driving software for different vehicles and is beneficial to the testing and output of the target software solution.

[0072] In the embodiments of this application, target code is filtered from the target code library based on the vehicle's hardware resources to ensure that the target software solution generated from the filtered target code can be adapted to vehicles with different hardware resource configurations.

[0073] In the embodiments of this application, target code is filtered from the target code library based on the vehicle's processing resources to ensure that the target software solution generated from the filtered target code can be adapted to vehicles with different processing resource configurations.

[0074] In the embodiments of this application, if there are multiple target codes, the optimal code with the least resources is selected based on processing resources and hardware resources, so as to achieve the purpose of completing the functional instructions with the least resources.

[0075] In the embodiments of this application, the target software solution is simulated and tested before the target code is generated and output, so as to obtain the running results and performance results, ensuring that the target software solution can fulfill the functional requirements of the functional instructions and the performance is qualified.

[0076] In the embodiments of this application, the target software solution is output only after both the performance test and the running result test of the target software solution have passed the test.

[0077] In the embodiments of this application, the design verification report and the target software solution are output together, which is beneficial because the design verification report can serve as a guide when deploying the target software solution in a vehicle, making it easier to deploy the target software solution on the vehicle.

[0078] Figure 10 This is a block diagram illustrating an autonomous driving software solution adaptation device in an exemplary embodiment of this application, such as... Figure 10 As shown, the exemplary autonomous driving software solution adaptation device includes an instruction acquisition module 1001, a code library matching module 1002, a code verification module 1003, and a code execution module 1004.

[0079] The instruction acquisition module 1001 is used to acquire function instructions, vehicle hardware resources and vehicle processing resources, and determine the instruction type based on the function instructions. The instruction type includes at least perception type, planning type and control type.

[0080] The code library matching module 1002 is used to match the corresponding target code library based on the instruction type. The target code library stores multiple functional codes and preset resource verification conditions corresponding to each functional code.

[0081] The code verification module 1003 is used to verify the vehicle's hardware resources and processing resources based on preset resource verification conditions. If the verification passes, the function code corresponding to the preset resource verification conditions is determined as the target code.

[0082] Code execution module 1004 is used to run and integrate the target code to generate target software in response to functional instructions.

[0083] It should be noted that the autonomous driving software solution adaptation device and the autonomous driving software solution adaptation method provided in the above embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here. In practical applications, the autonomous driving software solution adaptation device provided in the above embodiments can allocate the above functions to different functional modules as needed, that is, divide the internal structure of the device into different functional modules to complete all or part of the functions described above, and this is not a limitation.

[0084] Embodiments of this application also provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the electronic device enables the autonomous driving software solution adaptation method provided in the above embodiments.

[0085] Figure 11A schematic diagram of a computer system suitable for implementing the embodiments of this application is shown. It should be noted that... Figure 11 The computer system 1100 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0086] like Figure 11 As shown, the computer system 1100 includes a Central Processing Unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1102 or programs loaded from storage portion 1108 into Random Access Memory (RAM) 1103, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 1103. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. An Input / Output (I / O) interface 1105 is also connected to bus 1104.

[0087] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0088] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs various functions defined in the system of this application.

[0089] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0091] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0092] Another aspect of this application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a computer's processor, causes the computer to perform the autonomous driving software adaptation method as described above. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not assembled into the electronic device.

[0093] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the autonomous driving software adaptation method provided in the various embodiments described above.

[0094] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A method for adapting autonomous driving software solutions, characterized in that, The autonomous driving software solution adaptation method includes: The system acquires functional instructions, vehicle hardware resources, and vehicle processing resources, and determines the instruction type based on the functional instructions. The instruction type includes at least perception type, planning type, and control type. Based on the target code library corresponding to the instruction type, the target code library stores multiple functional codes and preset resource verification conditions corresponding to each functional code; The hardware resources and processing resources of the vehicle are verified based on the preset resource verification conditions. If the verification passes, the functional code corresponding to the preset resource verification conditions is determined as the target code. Determining the functional code corresponding to the preset resource verification conditions as the target code further includes: if multiple target codes exist, filtering the target codes based on the preset resource verification conditions, where the preset resource verification conditions include hardware resources, computing resources, memory resources, and bandwidth resources; if the instruction type is the planning type or the control type, the target code with the smallest sum of computing resources, memory resources, and bandwidth resources is determined as the final target code; if the instruction type is the perception type, the target code with the smallest hardware resource requirement among the preset resource verification conditions is determined as the final target code. Generate and output the target software solution based on the target code; The method further includes: establishing a hardware resource table and a processing resource table for the vehicle based on the vehicle model and the original manufacturer's manual. The hardware resource table includes the vehicle's hardware resources, and the processing resource table includes the vehicle's processing resources. If it is detected that the vehicle has been equipped with additional hardware or processing resources, the hardware resource table and the processing resource table are updated accordingly. The vehicle's hardware resources and processing resources are obtained based on the hardware resource table and the processing resource table.

2. The autonomous driving software solution adaptation method according to claim 1, characterized in that, The target code library matched based on the instruction type includes: If the instruction type is a perception type, then the preset perception code library is determined as the target code library; If the instruction type is a planning type, then the preset planning code library is determined as the target code library; If the instruction type is a control type, then the preset control code library is determined as the target code library.

3. The autonomous driving software solution adaptation method according to claim 1, characterized in that, Before obtaining function commands, the following also applies: Obtain multiple function codes and unify the input and output interfaces of each function code; Based on the function type of the function code, the function code is stored in a preset perception code library, a preset planning code library, and a preset control code library.

4. The autonomous driving software solution adaptation method according to claim 1, characterized in that, Based on the preset resource verification conditions, the hardware resources and processing resources of the vehicle are verified. If the verification passes, the function code corresponding to the preset resource verification conditions is determined as the target code, including: If the instruction type is the perception type, then the hardware resources of the vehicle are verified based on the preset resource verification conditions; If the number of hardware resources is greater than or equal to the preset number of hardware resources in the preset resource verification condition, the verification passes, and the function code corresponding to the preset resource verification condition is determined as the target code.

5. The autonomous driving software solution adaptation method according to claim 1, characterized in that, The hardware resources and processing resources of the vehicle are verified based on the preset resource verification conditions. If the verification passes, the function code corresponding to the preset resource verification conditions is determined as the target code. The method further includes: If the instruction type is the planning type or the control type, then the processing resources of the vehicle are verified based on the preset resource verification conditions. The processing resources include computing resources, memory resources and bandwidth resources. If the computing resources are greater than or equal to the preset computing resources of the preset resource verification condition, the memory resources are greater than or equal to the preset memory resources of the preset resource verification condition, and the bandwidth resources are greater than or equal to the preset bandwidth resources of the preset resource verification condition, then the function code corresponding to the preset resource verification condition is determined as the target code.

6. The autonomous driving software solution adaptation method according to claim 1, characterized in that, Before generating and outputting the target software solution based on the target code, the following steps are also included: Acquire simulation vehicle information and simulation environment information, and obtain a simulation test environment based on the simulation vehicle information and the simulation environment information; The target software solution was run in the simulation test environment to obtain the running results and performance results. Based on the running results and performance results, the test results of the target software solution are obtained. If the test results are passed, the target software solution is output.

7. The autonomous driving software solution adaptation method according to claim 6, characterized in that, The test results of the target software solution, based on the aforementioned operation and performance results, include: If the running result matches the function instruction, then the running result is successful; If the performance result exceeds the preset performance threshold, then the performance result is considered passed. If both the running result and the performance result are passed, then the test result is passed.

8. The autonomous driving software solution adaptation method according to claim 6, characterized in that, The output of the target software solution also includes: A design verification report is generated based on the running results and the performance results, and the design verification report and the target software solution are output.

9. An autonomous driving software solution adaptation device, characterized in that, The autonomous driving software solution adaptation device includes: The instruction acquisition module is used to establish a vehicle hardware resource table and a vehicle processing resource table based on the vehicle model and the original manufacturer's manual. The hardware resource table includes the vehicle's hardware resources, and the processing resource table includes the vehicle's processing resources. If it is detected that the vehicle has been equipped with additional hardware or processing resources, the hardware resource table and the processing resource table are updated accordingly. The module acquires the vehicle's hardware resources and processing resources based on the hardware resource table and the processing resource table. It also acquires function instructions and determines the instruction type based on the function instructions. The instruction type includes at least perception type, planning type, and control type. The code library matching module is used to match the corresponding target code library based on the instruction type. The target code library stores multiple functional codes and preset resource verification conditions corresponding to each functional code. A code verification module is used to verify the hardware resources and processing resources of the vehicle based on the preset resource verification conditions. If the verification passes, the functional code corresponding to the preset resource verification conditions is determined as the target code. Determining the functional code corresponding to the preset resource verification conditions as the target code further includes: if multiple target codes exist, filtering the target codes based on the preset resource verification conditions, where the preset resource verification conditions include hardware resources, computing resources, memory resources, and bandwidth resources; if the instruction type is the planning type or the control type, the target code with the smallest sum of computing resources, memory resources, and bandwidth resources is determined as the final target code; if the instruction type is the perception type, the target code with the smallest hardware resource requirement among the preset resource verification conditions is determined as the final target code. The code execution module is used to run and integrate the target code to generate target software in response to the functional instructions.

10. An electronic device, characterized in that, The electronic device includes: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the electronic device to implement the autonomous driving software solution adaptation method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by the computer's processor, causes the computer to perform the autonomous driving software solution adaptation method according to any one of claims 1 to 8.

Images