Script processing method, device and equipment for automatic driving application graphical developer

Abstract

The embodiment of the invention provides a script processing method, device and equipment for an automatic driving application graphical developer. The method comprises the following steps: according to script elements of a to-be-installed script and a software type of automatic driving software corresponding to the to-be-installed script, determining a simulation environment of the to-be-installed script running in the automatic driving software; the script to be installed is a script of the automatic driving software; according to the simulation environment, performing analogue simulation on the installer of the script to be installed to obtain an analogue simulation result; the analogue simulation result represents a reaction result of the script to be installed running in a simulation environment of the automatic driving software; determining a target script element from a template database corresponding to the software type according to an analogue simulation result; and according to the target script element and a preset dependency relationship, adjusting the installation script to obtain a target script. The method is used for achieving the effects of reducing development complexity and improving efficiency and accuracy in the packaging process.

Description

Technical Field

[0001] The present application relates to the field of autonomous driving technology, and in particular to a script processing method, device and equipment for an autonomous driving application graphical developer. Background Art

[0002] With the rapid development of autonomous driving technology, how to efficiently package complex autonomous driving tool chains into easy-to-deploy installation packages has become a key challenge in this field.

[0003] At present, in order to meet the packaging needs of diverse software types in the autonomous driving tool chain, the industry has adopted a variety of packaging technologies and tools. Common packaging methods include using traditional installer generators such as NSIS (Nullsoft Scriptable InstallSystem) or WiX Toolset, which allow detailed definition of installation behavior through DSL (domain-specific language) or XML format. In addition, script generation tools such as Python or Shell scripts are also widely used to automate the implementation of simple program logic. These scripts usually automatically generate the final packaging script by replacing predefined placeholders.

[0004] However, in the prior art, there is a lack of unified standards for packaging different tool software, and a wide variety of packaging tools are used, resulting in the lack of rule verification and automatic adjustment functions for the characteristics of autonomous driving tools in the generated scripts. This not only increases the complexity of development, but also reduces the efficiency and accuracy of the packaging process. Summary of the invention

[0005] The embodiments of the present application provide a script processing method, device and equipment for an autonomous driving application graphical developer, which are used to reduce development complexity and improve the efficiency and accuracy of the packaging process.

[0006] In a first aspect, an embodiment of the present application provides a script processing method of an autonomous driving application graphical developer, comprising:

[0007] Determining a simulation environment in which the script to be installed runs in the autonomous driving software according to a script element of the script to be installed and a software type of the autonomous driving software corresponding to the script to be installed; the script to be installed is a script of the autonomous driving software;

[0008] According to the simulation environment, the installer of the script to be installed is simulated to obtain a simulation result; the simulation result represents the reaction result of the script to be installed running in the simulation environment of the autonomous driving software;

[0009] According to the simulation result, determining the target script element from the template database corresponding to the software type; wherein the template database includes at least one script template; and the script template includes the script element;

[0010] According to the target script element and the preset dependency relationship, the installation script is adjusted to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

[0011] In a possible implementation, the simulation environment includes a first simulation environment representing an installation requirement that satisfies the script installer, and a second simulation environment that does not satisfy the installation requirement of the script installer;

[0012] According to the simulation results, the target script elements are determined from the template database corresponding to the software type, including:

[0013] According to the first simulation environment and the second simulation environment, respectively simulating the installer of the script to be installed to obtain a first simulation result and a second simulation result;

[0014] If both the first simulation result and the second simulation environment indicate that the installer of the script to be installed reacts abnormally, then according to the second simulation result, a target script element is determined from a template database corresponding to the software type.

[0015] In a possible implementation, determining the target script element from a template database corresponding to the software type according to the second simulation result includes:

[0016] Determine an abnormal script element according to the second simulation result; wherein the abnormal script element represents a script element in which the script to be installed runs abnormally in the simulation environment of the autonomous driving software;

[0017] According to the position identifier of the abnormal script element in the script template, the target script element is determined from the template database.

[0018] In a possible implementation, determining a target script element from a template database according to a position identifier of an abnormal script element in a script template includes:

[0019] If the template database contains a target script element corresponding to the location identifier, the step of adjusting the script to be installed according to the target script element to obtain the target script is performed;

[0020] If the template database does not contain the target script element corresponding to the location identifier, the target script element is determined according to the software type and the usage of other script elements in the script element library.

[0021] In a possible implementation, the method further includes:

[0022] If the first simulation result indicates that the installer of the script to be installed responds normally, the script to be installed is determined to be the target script.

[0023] In a possible implementation, before adjusting the installation script according to the target script element and the preset dependency relationship to obtain the target script, the method further includes:

[0024] Determine the software type of the autonomous driving software and an initial script template corresponding to the software type;

[0025] In response to an input operation on the initial script template, obtaining input code parameters of the autonomous driving software;

[0026] According to the mapping relationship between the input parameters and the modules in the initial script template, the script elements corresponding to the input parameters are written into the script template to obtain the script to be installed.

[0027] In a possible implementation, the installation script is adjusted according to the target script element and the preset dependency relationship to obtain the target script, including:

[0028] According to the target script elements and the preset dependencies, the script to be installed is adjusted to obtain the initial target script;

[0029] Take the initial target script as the script to be installed, and re-execute the steps of determining the simulation environment in which the script to be installed runs in the autonomous driving software based on the script elements of the script to be installed and the software type of the autonomous driving software corresponding to the script to be installed, until the simulation results indicate that the installer of the script to be installed responds normally, and then determine that the script to be installed is the target script.

[0030] In a possible implementation, the script element includes at least one script element of a basic parameter, an attachment component, and a functional function.

[0031] In a second aspect, an embodiment of the present application provides a script processing device of an autonomous driving application graphical developer, comprising:

[0032] A first determination module is used to determine a simulation environment in which the script to be installed runs in the autonomous driving software according to a script element of the script to be installed and a software type of the autonomous driving software corresponding to the script to be installed; the script to be installed is a script of the autonomous driving software;

[0033] A simulation module is used to simulate the installer of the script to be installed according to the simulation environment to obtain a simulation result; the simulation result represents the reaction result of the script to be installed running in the simulation environment of the autonomous driving software;

[0034] A second determination module is used to determine the target script element from a template database corresponding to the software type according to the simulation result; wherein the template database includes at least one script template; and the script template includes the script element;

[0035] The adjustment module is used to adjust the installation script according to the target script element and the preset dependency relationship to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

[0036] In a third aspect, an embodiment of the present application provides a script processing device, including: a memory, a processor;

[0037] Memory stores computer-executable instructions;

[0038] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0039] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0040] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0041] The script processing method, device and equipment of the graphical developer of autonomous driving applications provided in the embodiments of the present application, after determining the initial path of the target lane, determines the simulation environment suitable for the software by analyzing the elements in the script to be installed and the corresponding software type, ensuring that the test is close to the actual operating conditions and improving reliability and effectiveness. The installation script is fully simulated in the selected simulation environment to verify its execution and capture potential problems or incompatibilities, providing a basis for subsequent optimization. Based on the simulation results, a suitable target script element is selected from a pre-set template database, and the original installation script is automatically adjusted according to the target script element and its dependencies to generate a means of optimizing the target script. In this way, the scripts of complex autonomous driving software can be accurately and quickly verified and adjusted, and the scripts can be ensured to meet the specific requirements of autonomous driving, thereby improving the consistency and efficiency of packaging. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0043] Figure 1 A schematic diagram of a scenario of a script processing method for a graphical developer of an autonomous driving application provided in this application;

[0044] Figure 2 Schematic diagram of the script processing method of the autonomous driving application graphical developer provided in this application Figure 1 ;

[0045] Figure 3 Schematic diagram of the script processing method of the autonomous driving application graphical developer provided in this application Figure 1 ;

[0046] Figure 3a A flowchart of another script processing method for a graphical developer of an autonomous driving application provided in this application;

[0047] Figure 4 A schematic diagram of the structure of the script processing device of the autonomous driving application graphical developer provided in this application;

[0048] Figure 5 A schematic diagram of the structure of the script processing device provided for this application.

[0049] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0050] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0051] First, the terms involved in this application are explained:

[0052] A script is a series of instructions or commands that are executed in sequence, usually used to automate tasks. It can be written in a programming language to simplify repetitive operations, configure the environment, install software, perform system management tasks, etc.

[0053] A script installer is a set of instructions or programs used to automate the software installation process. A script installer can be a script file that can perform a series of tasks to prepare, configure, and deploy software to the target system.

[0054] Autonomous Driving refers to the technology that enables vehicles to perceive the environment and make driving decisions without human driver intervention. By integrating multiple sensors, computing platforms and algorithms, the autonomous driving system can handle complex traffic conditions and achieve safe driving from the starting point to the end point.

[0055] A graphical developer may refer to a tool for scanning codes, generating description files, and calling code components based on the description files, so as to display the code components graphically, and then determine the configuration information of the code components according to the graphically displayed code components to generate the corresponding autonomous driving software. In the field of autonomous driving, the business process involves a large number of functional software, including hardware debugging, sensor data monitoring, and middleware communication, from sensor hardware to ROS2 middleware and then to user interaction in the vehicle-mounted middleware. After each application update or requirement iteration, it is necessary to maintain a separate packaging script for each software, resulting in a lot of time wasted in the software packaging and distribution stage. Existing tools such as NSIS and WiX lack specific solutions for autonomous driving tools, especially the lack of rule verification and automatic adjustment functions for generated scripts that meet the characteristics of autonomous driving tools. This makes the generated scripts unable to automatically adapt to complex environmental dependencies and support requirements. Any changes in environmental requirements or parameter configuration items require manual intervention, which increases duplication of work and reduces automation efficiency. In addition, the learning curve of these tools is steep, and users need to master specific DSL or XML configuration languages, which makes it difficult to flexibly respond to the specific requirements of Inno Setup, resulting in poor user experience. Therefore, there is an urgent need for an improved solution that can provide customized rule verification and automatic adjustment functions to simplify the configuration process, reduce duplication of work, and improve the efficiency of the entire development and deployment process.

[0056] The script processing method, device and equipment of the graphical developer of autonomous driving applications provided in the embodiments of the present application can automatically determine the simulation environment suitable for the software by analyzing the elements in the installation script and its corresponding software type, ensuring that the test is close to the actual operating conditions and improving reliability and effectiveness. A comprehensive simulation is performed in the selected simulation environment to verify the execution of the script and capture potential problems or incompatibilities, providing a basis for subsequent optimization. Based on the simulation results, the system selects the most suitable target script element from the pre-set script template database, and automatically adjusts the original installation script according to its dependencies to generate the optimized target script. This process implements rule verification and automatic adjustment, ensuring that the script meets the specific requirements of autonomous driving and improving the consistency and efficiency of packaging.

[0057] Figure 1 A schematic diagram of a scenario of a script processing method for a graphical developer of an autonomous driving application provided in this application, such as Figure 1As shown, the specific application scenario of the present application is a script processing system, wherein the script processing system can be a server, and the server can be a computer, a mobile phone, a tablet and other devices. This embodiment does not impose any special restrictions on the implementation method of the execution subject, as long as the execution subject can determine the simulation environment in which the installation script runs in the autonomous driving software according to the script elements of the installation script and the software type of the autonomous driving software corresponding to the installation script; simulate the installation script according to the simulation environment of the installation script to obtain the simulation result; determine the target script element from the database of the script template corresponding to the software type according to the simulation result; adjust the installation script according to the target script element and the dependency relationship between the target script element and the script element in the script template to obtain the target script.

[0058] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0059] Figure 2 Schematic diagram of the script processing method of the autonomous driving application graphical developer provided in this application Figure 1 ,like Figure 2 As shown, the method includes:

[0060] S201. Determine a simulation environment in which the script to be installed runs in the autonomous driving software based on script elements of the script to be installed and the software type of the autonomous driving software to which the script to be installed corresponds; the script to be installed is a script of the autonomous driving software.

[0061] The script to be installed may refer to a set of all commands and instructions required for the automated deployment and configuration of the autonomous driving software. It may include operating system level settings, installation of dependent libraries, configuration of environment variables, startup of services, and all other operations necessary for the normal operation of the autonomous driving software. The autonomous driving software may be software configured through a graphical developer, which may include various modules, each of which may also be an independent software. For example, the autonomous driving software may be software generated by a data acquisition module, software generated by a labeling module, software generated by a perception system module, software generated by a test and evaluation module, software generated by a domain control communication module, and software of a visual graphics application developer in a graphical developer.

[0062] The script element may refer to a specific component or instruction used to constitute the script to be installed. In the embodiment of the present application, the script element includes at least one script element of basic parameters, attachment components and functional functions, wherein:

[0063] Basic parameters can refer to a series of key settings configured by the user, which are used to define the basic properties and behaviors of the installation package. Especially when using installation program generation tools such as Inno Setup, basic parameters cover all necessary information to ensure a smooth installation process. For example, basic parameters can include software program name, version number, output path, default installation path, and one or more parameters of all Section parameters supported by Inno Setup.

[0064] Additional components can refer to software modules, libraries, tools, or other resources that need to be installed or configured in addition to ensure that the main program can run normally. These components may not be part of the core application, but are essential to achieve specific functions. Through the standardized config.json configuration file, users can flexibly describe these additional components and their behavior logic, thereby achieving configurable management of component integration. For example, for the GAATool software type, additional components can be Vscode and Foxglove for visual graphics development.

[0065] Functional functions can refer to tasks used to implement automated detection and configuration, ensuring that the installation process proceeds smoothly and meets the environmental conditions required for the software to run. Functional functions can be divided into two categories: software and hardware environment detection and system environment configuration. Among them, software and hardware environment detection is used to check whether the target machine has the hardware and software resources required to install and run autonomous driving software, including but not limited to: memory detection, processor performance detection, network connection detection and other items. System environment configuration is used to automatically configure the system environment of the target machine based on the detection results to ensure that all necessary settings have been completed correctly, including but not limited to: configuring environment variables, firewalls and security settings and other items.

[0066] The software type of the autonomous driving software corresponding to the script to be installed may refer to a classification identifier predetermined during the packaging and deployment process to describe the main functions and application scenarios of the software. The software type may reflect the core purpose and technical characteristics of the software.

[0067] In an embodiment of the present application, the script elements of the script to be installed and the software type of the autonomous driving software corresponding to the script to be installed can be obtained by analyzing the template of the script to be installed.

[0068] The simulation environment in which the script to be installed runs in the autonomous driving software may refer to a simulation environment used to verify whether the script to be installed can correctly configure and deploy a specific type of autonomous driving software. Among them, the simulation environment can be used to simulate real operating conditions, verify the requirements of specific software types, and automate verification rules. Among them, for the verification of the script to be installed of the autonomous driving application software type selected by the user, in the verification stage the tool simulates the real installation environment through a virtual machine (VM), Docker container or WSL (Windows Subsystem for Linux) according to the software type.

[0069] In the embodiment of the present application, the simulation environment in which the script to be installed runs in the autonomous driving software can automatically match and apply corresponding preset conditions according to the software type and script elements, thereby quickly determining the simulation environment in which the script to be installed runs in the autonomous driving software. S202: Simulate the installer of the script to be installed according to the simulation environment to obtain a simulation result; the simulation result represents the reaction result of the script to be installed running in the simulation environment of the autonomous driving software.

[0070] Among them, the installer of the installation script is simulated, and the simulation result can refer to verifying whether the installer of the script to be installed fully meets the requirements in the software and hardware environment, whether it can successfully output an installation package that meets the requirements, and check whether the syntax and logic of the script are correct.

[0071] For example, in some embodiments, simulating the installer of the installation script to obtain the simulation result may include:

[0072] The simulation of the network environment is used to determine the stability, bandwidth and latency of the network connection to ensure that real-time data transmission is not affected. For example, there is a function module to check whether the network connection is available and whether the data transmission bandwidth requirements are met (for example, the minimum bandwidth requirement can be 10Mbps), there is a function module to check whether the network delay is within the allowed range (for example, the ping delay does not exceed 100ms), and there is a function module to ensure that the relevant remote storage service or cloud service is accessible.

[0073] Checking the storage space: Due to the huge amount of collected data, a large amount of storage space is required. For example, there is a function module to check whether the current hardware configuration meets the software requirements (for example, whether the remaining space is greater than 200GB).

[0074] Check the sensor driver: For specific sensors, you need to install the corresponding driver and SDK. For example, check whether there are additional components containing the necessary sensor (such as LiDAR, camera) drivers.

[0075] Check the ROS middleware to see whether it is accessing and managing sensor data streams.

[0076] Thus, it is possible to obtain simulation results showing whether the installer responds correctly to the simulation environment during runtime and whether the results are normal.

[0077] S203. Determine a target script element from a template database corresponding to the software type according to the simulation result; wherein the template database includes at least one script template; and the script template includes a script element.

[0078] Among them, the template database may refer to a database set up according to a script template. Different script templates correspond to different software in the field of autonomous driving, and the script elements stored in the database that are applied to the software in the field of autonomous driving are also different.

[0079] Through the simulation results, it is possible to determine which script elements in the script to be installed have abnormal problems. Thus, the target script elements that match the abnormal script elements can be determined from the script template corresponding to the software type through the abnormal script elements. The target script elements can be used to supplement and replace the abnormal script elements in the script to be installed, wherein the script elements with abnormal problems may refer to erroneous script elements or missing script elements.

[0080] The installation simulation environment includes a first simulation environment that represents the installation requirements of the script installer and a second simulation environment that does not meet the installation requirements of the script installer. In the embodiment of the present application, according to the simulation results, the target script element is determined from the template database corresponding to the software type, including:

[0081] The target script elements are determined in the template database corresponding to the software type, including:

[0082] According to the first simulation environment and the second simulation environment, respectively simulating the installer of the script to be installed to obtain a first simulation result and a second simulation result;

[0083] If both the first simulation result and the second simulation environment indicate that the installer of the script to be installed reacts abnormally, then according to the second simulation result, a target script element is determined from a template database corresponding to the software type.

[0084] Among them, the first simulation environment that meets the installation requirements of the script installer may refer to setting up the software and hardware environment to fully meet the requirements for the operation of the autonomous driving software. For example, when there are three operating requirements, the network bandwidth and latency meet the requirements; there is sufficient storage space and the hard disk meets the requirements (for example, more than 200GB of available space); the required sensor drivers (such as LiDAR, camera) have been correctly installed.

[0085] According to the first simulation environment, the installer of the script to be installed is simulated, and obtaining the first simulation result may refer to the process of building and executing the installation package in the first simulation environment, and observing whether it can be successfully output. The first simulation result may include the verification content of the script to be installed in the first simulation environment, for example, it can be checked whether the output installation package contains correct basic parameters (for example, application name, icon, version information, etc.); execute the script and check whether the installation package can run smoothly without syntax errors or logical errors.

[0086] In some embodiments, when simulating the installer of the script to be installed according to the first simulation environment, obtaining the first simulation result may refer to the process of executing the script to be installed and verifying the installation program in the first simulation environment, that is, determining whether the sensor and hardware dependency configurations after the installation package is output are correct, and ensuring that the correct sensor driver and additional components are installed in the installation directory.

[0087] The first simulation environment may refer to an environment in which the software and hardware environment fully meets the requirements of the software type, all drivers and sensors are correctly installed, and the output installation package is run and installed, and the installation directory is checked.

[0088] The first simulation result may include: ensuring that the installation package correctly installs the necessary sensors and hardware drivers (such as LiDAR, camera). Confirming whether the device is correctly connected and identifiable by checking whether the relevant driver files exist or through the command line; verifying whether additional components (such as ROS middleware, sensor SDK) are correctly installed and can run normally.

[0089] The second simulation environment that does not meet the installation requirements of the script installer may refer to the setting of the software and hardware environment that does not meet the requirements of the software type of the autonomous driving software. For example, when there are three operating requirements, the network connection is unstable, the bandwidth is lower than the minimum requirement (such as lower than 10Mbps), the delay is higher than the maximum allowed value (such as more than 100ms); insufficient storage space (for example, the remaining space is less than 200GB). The required sensor driver is not installed or the driver is incorrect.

[0090] According to the second simulation environment, the installer of the script to be installed is simulated, and the second simulation result can refer to building and executing the installation package in the second simulation environment, verifying whether the script to be installed can correctly throw an exception when the hardware and software environment are not met, and checking whether the functional function module works according to the rules, wherein the second simulation result can include the verification content of the script to be installed in the second simulation environment, such as network environment detection: check whether the network connection is available, whether the bandwidth meets the minimum requirements, and whether the delay is within the allowable range. The script should be able to throw relevant exceptions (such as "network connection is unavailable" or "insufficient bandwidth"); check the storage space: check whether insufficient storage space is detected and throw an exception (such as "insufficient disk space").

[0091] Therefore, when both the first simulation result and the second simulation environment indicate that the installer of the script to be installed reacts abnormally, the target script element is determined from a database of script templates corresponding to the software type according to the second simulation result.

[0092] Among them, in the embodiment of the present application, according to the second simulation result, an abnormal script element is determined; wherein the abnormal script element represents a script element in which the script to be installed runs abnormally in the simulation environment of the autonomous driving software;

[0093] According to the position identifier of the abnormal script element in the script template, the target script element is determined from the template database.

[0094] Among them, the abnormal script elements can be determined based on the log records, for example, through detailed log records (such as using the tee command to save the output to the log file) of the execution results, error messages and repair suggestions of each step, so as to accurately locate the problem when the execution of the script to be installed fails. For example:

[0095] Function configuration and integration results: If the function is not successfully integrated, the log will output the reason, such as missing configuration parameters or incorrect code logic in the module. Repair suggestions include supplementing missing parameters, modifying parameter types, or rewriting module function code.

[0096] Execution result of the script to be installed: If the execution fails, the log will indicate the problem, such as code logic errors or missing minimum necessary configuration items. Repair suggestions include adding required configuration items or adjusting code logic according to the error location.

[0097] In the embodiment of the present application, the second simulation result is the script to be installed executed in a completely unsatisfactory environment, so the exception handling mechanism of the script can be better tested to better reflect the performance of the script in the real world, especially its exception handling ability and robustness. Therefore, determining the abnormal script elements according to the second simulation result can ensure that the script can run stably and reliably in various environments.

[0098] Determining the target script element from the database of the script template according to the position identifier of the abnormal script element in the script template can refer to utilizing the error position information in the log (such as line number, function name, file path, position in the script template, etc.) to determine the specific position of the abnormal script element in the script template, and mapping the position identifier of the abnormal element (such as line number, file name) to a specific entry in the script template database according to the specific position of the abnormal script element in the script template, that is, the target script element that best meets the current software type and requirements can be selected from the database.

[0099] In addition, in some embodiments, when a function function is missing in the script to be installed: if a function function is missing, the user can be allowed to manually select an existing function module or modify the function template code in the current script during the current process that has not passed the verification, and then re-execute the verification process.

[0100] When the script output does not match the parameter configuration: If the installation program generated by the script is inconsistent with the input basic parameter configuration, the tool will give priority to the input parameters and automatically adjust the script output results to ensure that the final installation package meets the specified configuration.

[0101] When add-ons are missing: If the required add-ons are missing from the result of the script to be installed, the user can reconfigure a certain add-on or rewrite the relevant part to ensure that the script can correctly install all required components.

[0102] Among them, in the embodiment of the present application, according to the position identifier of the abnormal script element in the script template, determining the target script element from the template database includes:

[0103] If the template database contains a target script element corresponding to the location identifier, the step of adjusting the script to be installed according to the target script element to obtain the target script is performed;

[0104] If the template database does not contain the target script element corresponding to the location identifier, the target script element is determined according to the software type and the usage of other script elements in the script element library.

[0105] Among them, if the target script elements corresponding to the position identifier exist in the template database, it can mean that if the target script elements corresponding to the position identifier exist in the template database, these elements are directly applied for repair.

[0106] If the template database does not contain the target script element corresponding to the location identifier, if no match is found in the template database, a new target script element is determined and created based on the software type and the usage of other elements in the script element library to ensure that it meets current requirements and is applied to the script.

[0107] Among them, the usage of other script elements in the script element library may refer to the usage of other script elements when applied to the same software type. The usage may include usage functions, dependencies in templates, and frequency of use. Through the usage, the target script element can be indirectly determined. For example, some script elements may be specialized for specific tasks, such as sensor calibration, environmental detection, or middleware communication. A commonly used sensor driver may depend on a specific version of a library file or configuration tool. Ensuring that these dependencies are properly integrated can avoid potential compatibility issues. Highly used elements are usually more tested and verified, and have higher stability and reliability.

[0108] In some embodiments, the usage function, the dependency in the template, and the frequency of usage may be used to consider whether other script elements are used as target script elements by setting weights, wherein the weight of the usage function may be higher than the weight of the dependency in the template and the weight of the frequency of usage.

[0109] If the target script element determined according to the usage of other script elements in the same software type is not suitable after detection, it can also be determined by manual adjustment.

[0110] In this embodiment of the present application, the method further includes:

[0111] If the first simulation result indicates that the installer of the script to be installed responds normally, the script to be installed is determined to be the target script.

[0112] Among them, if the first simulation result indicates that the installer of the script to be installed responds normally, it can be indicated that the script to be installed can be executed normally. Therefore, regardless of whether the second simulation result indicates that the installer of the script to be installed responds normally, there is no need to adjust the script to be installed according to the second simulation result.

[0113] S204. Adjust the installation script according to the target script element and the preset dependency relationship to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

[0114] Among them, the script elements in the script template can refer to other normal script elements.

[0115] In an embodiment of the present application, according to the target script element and the preset dependency relationship, all necessary dependencies (such as libraries, tools, and configurations) can be analyzed and confirmed, and these dependencies are correctly introduced and configured into the script to be installed. Then, the script is adjusted to ensure that the newly added target script element is seamlessly integrated with the existing script element to avoid any conflict or missing. The target script finally generated not only fixes the problems in the original script, but also ensures that it can run stably and reliably in the actual environment.

[0116] In an embodiment of the present application, after obtaining the target script, the automated installation, configuration and deployment process of the autonomous driving software can be implemented to ensure that the autonomous driving software can run quickly and reliably in different environments.

[0117] Among them, in the embodiment of the present application, according to the target script elements and the preset dependency relationship, the installation script is adjusted to obtain the target script, including:

[0118] According to the target script elements and the preset dependencies, the script to be installed is adjusted to obtain the initial target script;

[0119] Take the initial target script as the script to be installed, and re-execute the steps of determining the simulation environment in which the script to be installed runs in the autonomous driving software based on the script elements of the script to be installed and the software type of the autonomous driving software corresponding to the script to be installed, until the simulation results indicate that the installer of the script to be installed responds normally, and then determine that the script to be installed is the target script.

[0120] Among them, after the script to be installed is adjusted, the adjusted initial target script can be simulated, that is, the initial target script is used as the script to be installed, and step S201 in the embodiment of the present application is re-executed to avoid problems with the initial target script.

[0121] In an embodiment of the present application, when the software type of the autonomous driving software corresponding to the script to be installed is a visual graphics application developer in a graphical developer, the simulation environment can be memory (whether it is greater than 32G), hard disk (whether the remaining space is greater than 200GB), and Docker environment support. By simulating the script to be installed of the graphical developer software in the first simulation environment and simulating the second simulation environment, a first simulation result and a second simulation result can be obtained. Then, based on the first simulation result and the second simulation result, it is determined whether the script to be installed of the graphical developer software reacts abnormally. If the reaction is abnormal, the abnormal script element in the script to be installed of the graphical developer software can be determined according to the second simulation result. According to the position identification of the abnormal script element in the script template corresponding to the graphical developer software, the target script element is determined. According to the target script element, the script to be installed is adjusted until the script to be installed is correct, and the target script can be obtained.

[0122] Therefore, the script processing method of the graphical developer of the autonomous driving application provided in the embodiment of the present application can simulate different hardware and software environments for verification through a virtual machine (VM), a Docker container or WSL (Windows Subsystem for Linux), and the system will automatically create a corresponding virtual environment according to the software type. Based on the running results of these virtual environments, the system will determine whether the verification is passed. If the verification fails, the system can automatically adjust and optimize the script to ensure that all functional modules and additional components fully meet the minimum requirements of the selected software type. At the same time, in the process of automatically adjusting and optimizing the script, since the method of the embodiment of the present application can be performed within the system, the security of the data can be improved, and the problems such as the leakage of autonomous driving software data caused by manual inspection can be avoided. In addition, since the amount of script data of the autonomous driving software is usually large, the system can judge the verification according to each script element and the dependency relationship between the script elements, which can also improve the real-time problem of the entire script processing process, thereby improving the efficiency of the processing of the autonomous driving software.

[0123] The script processing method of the graphical developer of the autonomous driving application provided in the embodiment of the present application can also help users identify and fix problems in the script through detailed log records and error reports, and support users to manually select or modify functional modules to ensure that the final script fully meets the requirements of software installation. In this way, not only the accuracy and reliability of the script are improved, but also the debugging and correction process of the user is simplified, ensuring that the script to be installed can be smoothly executed in various environments.

[0124] Figure 3 Schematic diagram of the script processing method of the autonomous driving application graphical developer provided in this application Figure 2 ,like Figure 3As shown, in this embodiment Figure 2 Based on the embodiment, the script processing method of the graphical developer of the autonomous driving application is described in detail, and the steps before the installation script is adjusted according to the target script element and the preset dependency relationship to obtain the target script. The method includes:

[0125] S301. Determine the software type of the autonomous driving software and an initial script template corresponding to the software type.

[0126] The initial script template corresponding to the software type may refer to the best matching template selected from the predefined script template library. Each template contains all the standard script elements and their dependencies required to create that type of software. These templates are optimized to ensure that a specific type of autonomous driving software can be correctly configured and deployed.

[0127] S302: In response to an input operation on the initial script template, obtaining input code parameters of the autonomous driving software;

[0128] S303: According to the mapping relationship between the input parameters and the modules in the initial script template, the script elements corresponding to the input parameters are written into the script template to obtain the script to be installed.

[0129] Among them, the module can refer to the data items used to be written into the initial script template. The module can include a basic parameter module, an accessory component module and a functional function module. By entering the mapping relationship between the code parameters and the modules in the initial script template, the corresponding data items can be quickly written into the initial script template to obtain the script to be installed.

[0130] For example, as shown in 3a, another script processing method of a graphical developer of an autonomous driving application provided in an embodiment of the present application is as follows: Figure 3a As shown, the method includes: user input (command line parameters / config.json), function module selection (memory check, virtualization), whether parsing and verification (format, integrity), template engine and script generation (filling template and generating installation script), installation script preview (confirming configuration correctness), installation script debugging and output (debugging and generating final script), where:

[0131] 1. Basic parameter configuration:

[0132] Among them, the basic parameter configuration can solve the problem of users repeatedly writing basic parameters when creating Inno Setup installation scripts. The existing method requires users to edit the configuration item by item in strict accordance with the specifications of the Inno Setup scripting language, which is a cumbersome and error-prone process. In the embodiment of the present application, parameters can be input through the command line, combined with the parameter item Method (used to represent different categories of software types in the field of autonomous driving), and the parameters entered by the user are automatically mapped to the script template that matches the specified software type. These templates are pre-integrated with specific packaging script requirements that meet different application scenarios, thereby realizing the automation and simplification of script configuration, greatly improving efficiency and accuracy. Among them, the correspondence between the Method parameter and the software type can be shown in Table 1:

[0133] Method Software Type Data Acquisition Data acquisition software Labeling Annotation software Perception Perception system software GAATool Visual Graphics Application Developer TestingAndEvaluation Test and Evaluation Software ToolsetMessage Domain control communication software

[0134] During use, users can configure all Section parameters supported by Inno Setup, among which common configuration items may include software program name, version number, output path, default installation path, etc. The basic parameter configuration tool can parse the parameters entered by the user to check whether they are complete and meet the requirements of Inno Setup. If some parameters are not provided, the tool will automatically fill in the preset default values ​​(for example, the default output path is the user directory). After ensuring that the parameter format is correct, the tool uses the template engine to dynamically generate the corresponding configuration section based on the provided parameters and built-in template rules. After completing the configuration, the user can preview the filled script by adding the preview parameter to ensure that the configuration is correct. 2. Attachment component configuration:

[0135] Among them, the add-on component configuration can support users to flexibly describe the add-ons and their behavior logic in the installer through the standardized config.json configuration file, and realize the configuration of component integration. In different software and add-on scenarios, there is no need to repeatedly write scripts to meet diverse needs.

[0136] Users can flexibly specify the properties of each component in the configuration file, such as component name, version, dependencies, and whether it is necessary to force installation or check the system environment. The accessory component configuration will provide the corresponding default accessory component configuration based on the Method (autonomous driving software type) selected by the user in the previous step. For different application scenarios of autonomous driving (such as simulation, perception, path planning, etc.), these scenarios usually have a high dependence on the operating environment. The accessory component configuration automatically matches the appropriate component integration template according to the Method selected by the user through preset templates, efficiently meeting diverse needs. For example, for the GAATool software type (i.e., graphical developer), the tool will install Vscode and Foxglove by default. Both are necessary components for visual graphics development, avoiding users from repeatedly configuring JSON files under the same software type.

[0137] The add-on component configuration will dynamically fill in the relevant parts of the add-on components in the script to be installed based on the content of the configuration file, ensuring that the installation program is executed correctly according to user requirements. At the same time, the tool supports the configuration of dependencies between components to ensure that specific components will be installed only when the conditions are met. For example, users can set environmental check logic to ensure that components are installed only after they meet the conditions, or force the installation of specific components when necessary, regardless of environmental restrictions. Such flexible configuration can adapt to a variety of complex installation requirements.

[0138] To ensure the legitimacy and integrity of the config.json file, the add-on component configuration will be strictly checked when parsing the configuration. Verify whether the fields are complete and whether they meet the format and rule requirements, ensure that there are no omissions or errors in the configuration file, and avoid problems during the installation process caused by improper configuration.

[0139] The user specifies parameters through the command line or config.json file configuration. After the tool verifies the configuration content, it fills the values ​​of each corresponding field into the installation script. The user previews and confirms that the parameters can be adjusted. After the final parameter configuration is confirmed, the tool will output the final installation script.

[0140] 3. Function module configuration:

[0141] Among them, the function module configuration allows users to select from the preset function modules and integrate them into the final installation script according to their needs to achieve specific functions of the toolchain tool. In this way, complex installation logic can be simplified, avoiding users from repeatedly writing similar codes, while maintaining the clarity of the tool structure and facilitating maintenance and expansion.

[0142] In the embodiment of the present application, the functional function modules are mainly divided into two categories: hardware and software environment detection and system environment configuration. The first category includes checking whether the hardware of the installation machine meets the installation requirements, such as checking whether the memory size is greater than 16GB, whether the remaining hard disk space is greater than 100GB, etc. The second category involves the configuration of the system environment, such as downloading and enabling the WSL (Windows Subsystem for Linux) environment, or enabling Windows virtualization and other settings.

[0143] The configuration of function modules and additional components is also affected by the Method software type parameters entered by the user. The tool will preset the necessary function modules in the corresponding template according to the type of autonomous driving software selected by the user to meet the installation requirements in specific scenarios.

[0144] For example, for the ToolsetMessage domain control communication software type, the tool will preset the following function modules by default:

[0145] Check whether the middleware service has been installed: Make sure the system has the necessary communication support environment.

[0146] Check whether the remaining disk space is greater than 50 GB: Verify whether the system meets the minimum storage requirements required for installation.

[0147] Both modules are prerequisites for installing ToolsetMessage type autonomous driving software. By presetting these function modules, the tool can effectively reduce the workload of users in configuring software of the same type, while ensuring the correctness and consistency of the script, thereby further optimizing the installation process.

[0148] During the function selection process, the user needs to determine which page of the installer the function is inserted into. The page configurations supported by the tool include: welcome page, license agreement page, installation path selection page, custom component installation interface, installation progress page, and installation completion page. The naming convention of the function uses the following format: function description-blocking installation flag-version number.

[0149] For example, when using the automated installation script generation tool to configure a function module, cbdx-tool represents the name of the tool, the features parameter represents the selected function module, and multiple function modules are separated by commas. Take checkMemoryMore-Than16GB as an example, it represents a function that is used to detect whether the memory of the installation machine is greater than 16GB. This function will not block the installation process. The version is 0.1 and the naming format is checkMemoryMoreThan16GB-True-0.1. In addition, wpWelcome indicates that the function will be inserted before the welcome page, and different function functions are distinguished by ",".

[0150] The corresponding relationship between page identifier and page description is shown in Table 2:

[0151] Page Identifier describe wpWelcome Welcome Page wpLicense License Agreement Page wpSelectDir Select Destination Folder Page wpSelectComponents Select Components Page wpReady Ready to install page wpInstalling Installation Progress Page wpFinished Installation Completed Page

[0152] In the Inno Setup script language support, that is, the script template to be installed in the tool, the function selected by the user will be filled in the script. According to the page identifier specified by the function, the function module configuration will fill the function call to the functionSet placeholder at the corresponding position in the CurPageChanged trigger.

[0153] The user selects the function by name in the command line and uses the ":" identifier to select the insert page. After pressing Enter to confirm, the tool will parse the function, insert the function into the specified location of the script template, and finally output the installation script.

[0154] 4. Module management of environment configuration:

[0155] The function library is part of the module management of the environment configuration. The function library consists of several predefined function modules, allowing users to manage the current preset modules and easily add or delete function modules through the command line.

[0156] Each functional module can include the following key elements:

[0157] Name: The name of the module, used to identify and describe the module.

[0158] Exception message: Applicable to software and hardware environment detection, the exception information text thrown when it does not meet the requirements.

[0159] Unique identifier: used for internal reference within the tool to ensure the uniqueness of each module.

[0160] Description: Briefly describe the purpose and objectives of the functional module.

[0161] Whether to block installation: A Boolean flag indicating whether the module will block the installation process.

[0162] Version number: current function module version information.

[0163] Code module: code implementation based on Inno setup script language.

[0164] Users can manage function modules through the following commands:

[0165] feature--list: displays all currently available function modules.

[0166] feature--D<module corresponding id>: delete the specified function module.

[0167] feature--C<config.json> : Create a new function module by providing a configuration file. The tool will verify whether the name of the function module is unique and check whether there are syntax errors in the code module to ensure the correctness and validity of the module.

[0168] In this way, users can not only use predefined function modules conveniently, but also expand and customize functions according to their own needs and flexibly adjust the behavior of the installation script.

[0169] In the embodiments of the present application, the codes of all function modules need to comply with the following three specifications:

[0170] No external parameters and no external dependencies: Function modules should run independently without relying on external input parameters or other external modules. This means that each function module should be self-contained and able to perform its function without other external conditions.

[0171] Single function and unique function: Each functional module should focus on a specific function, and the function must be unique. This helps to ensure modular design, avoid duplication and conflict of functions, and ensure that each functional module can efficiently complete its designated task.

[0172] Return value is Boolean type: The return value of each function module should be Boolean type (True or False). Returning True means that the function is executed successfully and the installation process can continue; returning False means that the environment detection has not passed or the system configuration has failed, thus blocking the installation progress and making it impossible to proceed to the next step.

[0173] This ensures the simplicity, independence, and predictability of the functional modules, avoids problems caused by inconsistent behaviors or external dependencies, and ensures the stability and execution efficiency of the installation script.

[0174] This feature allows users to list all available function modules through the command line, and supports creating or deleting function modules. Users can delete a specified module based on the module's unique ID identifier; at the same time, by providing a config.json file that complies with the specification, users can add new function modules. The tool will automatically check the validity of the file content, fields, and code. If the check passes, the function module list will be updated.

[0175] Another script processing method provided in the embodiment of the present application can automatically generate a packaging script that conforms to the Inno Setup syntax through a simple command line interface and a config.json configuration file, avoiding the cost of users learning a new language and supporting highly flexible configuration. For different types of autonomous driving software, the tool automatically selects the corresponding template according to the Method parameter, fills in the parameters required for the installation script (such as software name, version number, output path, etc.), simplifies the configuration process, and facilitates rapid deployment. In addition, the tool provides an extensible function library that automatically selects preset function functions according to the Method parameter. Users can select or customize modules according to their needs and dynamically integrate functions into the installation script, enhancing flexibility and scalability.

[0176] Figure 4 A schematic diagram of the structure of the script processing device of the autonomous driving application graphical developer provided in this application, such as Figure 4 As shown, the script processing device 40 of the autonomous driving application graphical developer provided in this embodiment:

[0177] A first determination module 401 is used to determine a simulation environment in which the script to be installed runs in the autonomous driving software according to a script element of the script to be installed and a software type of the autonomous driving software corresponding to the script to be installed; the script to be installed is a script of the autonomous driving software;

[0178] The simulation module 402 is used to simulate the installer of the script to be installed according to the simulation environment to obtain a simulation result; the simulation result represents the reaction result of the script to be installed running in the simulation environment of the autonomous driving software;

[0179] The second determination module 403 is used to determine the target script element from the template database corresponding to the software type according to the simulation result; wherein the template database includes at least one script template; and the script template includes the script element;

[0180] The adjustment module 404 is used to adjust the installation script according to the target script element and the preset dependency relationship to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

[0181] In a possible implementation, the installation simulation environment includes a first simulation environment that represents the installation requirements of the script installer and a second simulation environment that does not represent the installation requirements of the script installer; the second determination module 403 may also be specifically used to:

[0182] According to the first simulation environment and the second simulation environment, respectively simulating the installer of the script to be installed to obtain a first simulation result and a second simulation result;

[0183] If both the first simulation result and the second simulation environment indicate that the installer of the script to be installed reacts abnormally, then according to the second simulation result, a target script element is determined from a template database corresponding to the software type.

[0184] In a possible implementation manner, the second determining module 403 may also be specifically configured to:

[0185] Determine an abnormal script element according to the second simulation result; wherein the abnormal script element represents a script element in which the script to be installed runs abnormally in the simulation environment of the autonomous driving software;

[0186] According to the position identifier of the abnormal script element in the script template, the target script element is determined from the template database.

[0187] In a possible implementation manner, the second determining module 403 may also be specifically configured to:

[0188] If the template database contains a target script element corresponding to the location identifier, the step of adjusting the script to be installed according to the target script element to obtain the target script is performed;

[0189] If the template database does not contain the target script element corresponding to the location identifier, the target script element is determined according to the software type and the usage of other script elements in the script element library.

[0190] In a possible implementation manner, the second determining module 403 may also be specifically configured to:

[0191] If the first simulation result indicates that the installer of the script to be installed responds normally, the script to be installed is determined to be the target script.

[0192] In a possible implementation manner, the second determining module 403 may also be specifically configured to:

[0193] Determine the software type of the autonomous driving software and an initial script template corresponding to the software type;

[0194] In response to an input operation on the initial script template, obtaining input code parameters of the autonomous driving software;

[0195] According to the mapping relationship between the input parameters and the modules in the initial script template, the script elements corresponding to the input parameters are written into the script template to obtain the script to be installed.

[0196] In a possible implementation, the adjustment module 404 may also be specifically configured to:

[0197] According to the target script elements and the preset dependencies, the script to be installed is adjusted to obtain the initial target script;

[0198] Take the initial target script as the script to be installed, and re-execute the steps of determining the simulation environment in which the script to be installed runs in the autonomous driving software based on the script elements of the script to be installed and the software type of the autonomous driving software corresponding to the script to be installed, until the simulation results indicate that the installer of the script to be installed responds normally, and then determine that the script to be installed is the target script.

[0199] In a possible implementation, the script elements in the first determination module 401 include at least one script element of basic parameters, attachment components, and functional functions.

[0200] The script processing device of the autonomous driving application graphical developer provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.

[0201] Figure 5 This is a schematic diagram of the structure of the script processing device provided in this application. Figure 5 As shown, the script processing device 50 provided in this embodiment includes: at least one processor 501 and a memory 502. Optionally, the device 50 also includes a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected via a bus 504.

[0202] In a specific implementation process, at least one processor 501 executes the computer-executable instructions stored in the memory 502, so that at least one processor 501 executes the above method.

[0203] The specific implementation process of the processor 501 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0204] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0205] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0206] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0207] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0208] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0209] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0210] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0211] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

[0212] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0213] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0214] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0215] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0216] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A script processing method for an autonomous driving application graphical developer, characterized in that: include: Determining a simulation environment in which the script to be installed runs in the autonomous driving software according to a script element of the script to be installed and a software type of the autonomous driving software corresponding to the script to be installed; the script to be installed is a script of the autonomous driving software; According to the simulation environment, simulating the installer of the script to be installed to obtain a simulation result; the simulation result represents the reaction result of the script to be installed running in the simulation environment of the autonomous driving software; According to the simulation result, determining the target script element from a template database corresponding to the software type; wherein the template database includes at least one script template; and the script template includes a script element; According to the target script element and the preset dependency relationship, the installation script is adjusted to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

2. The method according to claim 1, characterized in that The simulation environment includes a first simulation environment that represents an installation requirement that satisfies the script installer, and a second simulation environment that does not meet the installation requirement of the script installer; The step of determining the target script element from a template database corresponding to the software type according to the simulation result includes: According to the first simulation environment and the second simulation environment, respectively simulating the script to be installed to obtain a first simulation result and a second simulation result; If both the first simulation result and the second simulation environment indicate that the installer of the script to be installed reacts abnormally, a target script element is determined from a template database corresponding to the software type according to the second simulation result.

3. The method according to claim 2, characterized in that Determining the target script element from a template database corresponding to the software type according to the second simulation result includes: Determine an abnormal script element according to the second simulation result; wherein the abnormal script element represents a script element in which the script to be installed runs abnormally in the simulation environment of the autonomous driving software; According to the position identifier of the abnormal script element in the script template, a target script element is determined from the template database.

4. The method according to claim 3, characterized in that The step of determining the target script element from the template database according to the position identifier of the abnormal script element in the script template comprises: If the template database contains a target script element corresponding to the location identifier, the step of adjusting the script to be installed according to the target script element to obtain the target script is performed; If the template database does not contain the target script element corresponding to the location identifier, the target script element is determined according to the software type and the usage of other script elements in the script element library.

5. The method according to claim 2, characterized in that: The method further comprises: If the first simulation result indicates that the installer of the script to be installed responds normally, the script to be installed is determined to be a target script.

6. The method according to claim 5, characterized in that Before adjusting the installation script according to the target script elements and the preset dependency relationship to obtain the target script, the method further includes: Determining a software type of the autonomous driving software and an initial script template corresponding to the software type; In response to an input operation on the initial script template, obtaining input code parameters of the autonomous driving software; According to the mapping relationship between the input parameters and the modules in the initial script template, the script elements corresponding to the input parameters are written into the script template to obtain the script to be installed.

7. The method according to claim 1, characterized in that The step of adjusting the installation script according to the target script element and the preset dependency relationship to obtain the target script includes: According to the target script elements and the preset dependency relationship, the script to be installed is adjusted to obtain an initial target script; Take the initial target script as the script to be installed, and re-execute the step of determining the simulation environment in which the script to be installed runs in the autonomous driving software based on the script elements of the script to be installed and the software type of the autonomous driving software corresponding to the script to be installed, until the simulation result indicates that the installer of the script to be installed responds normally, and then determine that the script to be installed is the target script.

8. The method according to any one of claims 1 to 7, characterized in that The script elements include at least one script element of basic parameters, attachment components and functional functions.

9. A script processing device for an autonomous driving application graphical developer, characterized in that: include: A first determination module is used to determine a simulation environment in which the script to be installed runs in the autonomous driving software according to a script element of the script to be installed and a software type of the autonomous driving software corresponding to the script to be installed; the script to be installed is a script of the autonomous driving software; A simulation module, configured to simulate the installer of the script to be installed according to the simulation environment to obtain a simulation result; the simulation result represents a reaction result of the script to be installed running in the simulation environment of the autonomous driving software; A second determination module is used to determine a target script element from a template database corresponding to the software type according to the simulation result; wherein the template database includes at least one script template; and the script template includes a script element; The adjustment module is used to adjust the installation script according to the target script element and the preset dependency relationship to obtain the target script; wherein the preset dependency relationship represents the dependency relationship between the script element and the script element in the script template.

10. A script processing device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 8.

Images