Graphical tool development method, system and equipment for automatic driving development engineering

Abstract

The invention relates to the technical field of software development, and particularly discloses a graphical tool development method, system and equipment for automatic driving development engineering.In the system, an instruction interaction module is used for analyzing a first instruction input into the development system to generate a first instruction and a first instruction parameter; the scheduling module is used for generating a corresponding task flow according to the first command and the first command parameter; the task flow comprises at least one pipeline task; the processing module is used for executing the pipeline tasks in each task flow according to a preset sequence to generate a target graphic tool; wherein in each task flow, the second pipeline task receives the output of the first pipeline task as the input of the second pipeline task; the first pipeline task is a previous pipeline task of the second pipeline task. By using the graphical tool system for the automatic driving development engineering in the scheme, the compatibility of the tool can be improved while the development efficiency is ensured.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and specifically to a graphical tool development method, system, and device for autonomous driving development engineering. Background Technology

[0002] Graphical tools in autonomous driving development engineering refer to visualization tools that assist in the development, debugging, or display of images and sensor data in autonomous driving systems, and are used to display the information collected by sensors in autonomous driving systems.

[0003] However, in the field of graphical tools for autonomous driving, graphical debugging tools, visualization tools, and other software engineering tools each have different implementation methods, and each tool usually relies on different auxiliary tools during the development process. For example, the creation phase requires the use of template CLI tools, the runtime phase requires relevant startup tools, the build phase has a dedicated build system, and the release phase requires corresponding release configurations.

[0004] Therefore, developers not only face low development efficiency in developing graphical tools, but also suffer from poor compatibility. Summary of the Invention

[0005] In view of this, this application provides a graphical tool development method, system and device for autonomous driving development engineering, which can improve tool compatibility while ensuring development efficiency. The technical solution is as follows.

[0006] Firstly, a graphical tool development system for autonomous driving development engineering is provided, the system including an instruction interaction module, a scheduling module, and a processing module;

[0007] The instruction interaction module is used to parse the first instruction input to the development system to generate a first command and first command parameters;

[0008] The scheduling module is used to generate a corresponding task flow based on the first command and the first command parameters; the task flow includes at least one pipeline task.

[0009] The processing module is used to execute the pipeline tasks in each task flow in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

[0010] In one alternative implementation, each pipeline task in each task flow shares a context object; the processing module is further configured to write the output of the first pipeline task to the context object and obtain the input of the second pipeline task from the context object.

[0011] In an optional implementation, the scheduling module is further configured to:

[0012] Select a project configuration file according to the development command; the project configuration file is used to indicate a preset task flow; the preset task flow includes preset pipeline tasks arranged in a preset order;

[0013] Based on the command parameters, the parameters of the preset pipeline tasks in the project configuration file are set to generate the corresponding task flow.

[0014] In one optional implementation, the instruction interaction module is further configured to parse the second instruction input to the development system to generate a second command and second command parameters; select a preset task flow and a target pipeline task according to the second instruction; and insert the target pipeline task into a specified position in the preset task flow.

[0015] In one optional implementation, the instruction interaction module is further configured to parse a third instruction input into the development system and generate a pipeline task template file based on the third instruction; the pipeline task template file is used to generate corresponding pipeline tasks based on the user's editing operations.

[0016] In one optional implementation, the system further includes a command interpretation and execution module; the command interpretation and execution module is used to encapsulate the corresponding shell command into a pipeline task, and execute the shell command corresponding to the pipeline task when a request to execute the pipeline command is received from the processing module.

[0017] Secondly, a graphical tool development method for autonomous driving development engineering is provided. This method is executed by a graphical tool development system for autonomous driving development engineering, and includes:

[0018] Receive and parse the first instruction to obtain the first command and its parameters;

[0019] Based on the first command and its parameters, a corresponding task flow is generated; the task flow includes at least one pipeline task.

[0020] The pipeline tasks in each task flow are executed in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

[0021] Optionally, the method further includes:

[0022] Receive and parse the second instruction input to the development system to generate a second command and second command parameters;

[0023] According to the second instruction, a preset task flow and a target pipeline task are selected, so as to insert the target pipeline task into a specified position in the preset task flow.

[0024] Thirdly, an electronic device is provided, the computer device including a processor and a memory, the memory storing at least one instruction, the at least one instruction being loaded and executed by the processor to implement the graphical tool development method for the above-described autonomous driving development project.

[0025] Fourthly, a computer-readable storage medium is provided, wherein at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the graphical tool development method of the above-described autonomous driving development project.

[0026] The technical solution provided by this application may have the following beneficial effects:

[0027] The autonomous driving graphical development system provided in this application includes an instruction interaction module, a scheduling module, and a processing module. The instruction interaction module parses the first instruction input into the development system to generate a first command and its parameters. The scheduling module generates a corresponding task flow based on the first command and its parameters. Each task flow includes at least one pipeline task. The processing module then executes the pipeline tasks in each task flow in a preset order to generate the target graphical tool. This solution allows users to input instructions and have the scheduling module generate corresponding task flows, reducing the amount of manual code development required. Furthermore, since the tool development process is implemented through task flow generation by the scheduling module, the compatibility between tools is strong. Therefore, using this graphical tool development system for autonomous driving development can improve tool compatibility while maintaining development efficiency. Attached Figure Description

[0028] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0029] Figure 1 This is a flowchart illustrating a graphical tool development method for autonomous driving development engineering, according to an exemplary embodiment.

[0030] Figure 2 This is a system block diagram illustrating a graphical tool development system for autonomous driving development engineering, according to an exemplary embodiment.

[0031] Figure 3 A flowchart illustrating the workflow of the scheduler involved in an embodiment of this application is shown.

[0032] Figure 4 The diagram illustrates the entry template definition and execution flowchart involved in the embodiments of this application.

[0033] Figure 5 The diagram illustrates the structure and execution flow of a workflow according to an embodiment of this application.

[0034] Figure 6 It illustrates a complete logic from command execution to result data and monitoring.

[0035] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0037] In the description of the embodiments of this application, the term "correspondence" may indicate that there is a direct or indirect correspondence between two things, or that there is an association between two things, or that there is a relationship of instruction and being instructed, configuration and being configured, etc.

[0038] In the field of graphical tools for autonomous driving, graphical debugging tools, visualization tools, and other software engineering tools each have different implementation methods, and each tool typically relies on different auxiliary tools during development. For example, the creation phase requires template CLI tools, the runtime phase requires relevant startup tools, the build phase has a dedicated build system, and the release phase requires corresponding release configurations. Each phase has an independent implementation within the same graphical tool, and their respective auxiliary tools and usage methods need to be clearly distinguished during use. Developers and graphical tool providers need to make choices based on the applicability to the business and verify their effectiveness through engineering. Making unsuitable choices requires adjustments and optimizations, which may involve starting from scratch or making architectural adjustments, directly impacting the delivery time of the graphical tool and multiplying the investment of manpower and time. Even with fewer adjustments, the process is relatively cumbersome, and there is still much room for improvement in efficiency.

[0039] Due to the decentralized management approach and the heterogeneity of the systems, developers need to invest a significant amount of time and effort in building and maintaining an engineering management system. This additional time investment directly compresses the core development time for graphical tools and limits the team's focus on application feature innovation. Especially when it comes to tasks related to non-application features such as building and releasing, these additional overheads significantly reduce development efficiency and extend the development cycle. Furthermore, due to the lack of a unified management process, manual management methods are prone to inconsistencies due to differences in individual understanding and familiarity, ultimately affecting system stability and upgrade reliability, and may even lead to delivery delays and unforeseen risks.

[0040] To address the aforementioned issues, this application provides a graphical tool development method for autonomous driving development engineering. Please refer to [reference needed]. Figure 1 , Figure 1 This is a flowchart illustrating a graphical tool development method for autonomous driving development engineering according to an exemplary embodiment. The method is applied to a graphical tool development system for autonomous driving development engineering; the method includes:

[0041] Step 101: Receive and parse the first instruction to obtain the first command and its parameters.

[0042] In this embodiment, the graphical tool development system for autonomous driving development engineering constructs an efficient, flexible, and scalable user interaction entry point. It receives user commands via a command-line tool and uses a schema-driven mechanism to structurally define and parse these commands. The system uses the command-line tool as the direct interface between the user and the entire engineering management solution, responsible for acquiring and parsing the input commands to obtain the corresponding first command and its parameters.

[0043] Step 102: Generate a corresponding task flow based on the first command and its parameters; the task flow includes at least one pipeline task.

[0044] In this embodiment, the development process is abstracted as a series of independent tasks (i.e., "Pipes"). These Pipes are executed in a preset order to jointly complete a high-level project management function. Therefore, in this embodiment, when the development system receives the user's first instruction and parses it to obtain the corresponding first command and first command parameters, it can map the first command and first command parameters to a specific executable structured task flow.

[0045] For example, in this embodiment of the application, the mapping relationship between commands and parameters and Pipelines can be precisely configured in advance through a configuration file; or the corresponding Pipeline can be selected according to the first command, and then the parameters of each pipe in the Pipeline can be set according to the parameters of the first command.

[0046] Using the above approach, users or project teams can adjust the behavior of existing commands by modifying these configuration files, and even define entirely new workflows by combining existing or custom Pipe packages.

[0047] Step 103: Execute the pipeline tasks in each task flow in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

[0048] In this embodiment, the development system includes a Pipeline engine, which controls the entire process by executing each Pipe in a strictly preset order. This sequential execution ensures the logical rigor of the tasks and the correctness of their dependencies; that is, the completion of one task is a prerequisite for the start of the next.

[0049] In this embodiment, Pipe is the core module, breaking down complex engineering management tasks into multiple independent Pipe packages. Each Pipe package follows the single responsibility principle and is responsible for a specific function. For example, the clean task is used for cleanup work before and after the build, and the submitter is used for Git operations in the release process.

[0050] In this embodiment, the development system predefines several Pipe packages, which users can directly call via commands to achieve the required functions. Since all users utilize these Pipe packages during development, the compatibility between the tools developed by different users is good. Furthermore, users can directly generate graphical tools by calling task flows or Pipe packages, greatly reducing the workload of user code development.

[0051] In summary, during the interaction between the card reader and the sensing device, when the sensing device switches to the first state, it sends a first response identifier to the card reader. Upon receiving the first response identifier, the card reader recognizes that the sensing device has switched to the first state and can send it the first instruction corresponding to the first state to initiate the next state. After receiving the first instruction, the sensing device needs to parse it to determine if it corresponds to the first state. However, if it cannot parse it temporarily, the sensing device can remain in the first state, waiting for subsequent instructions from the card reader. In this scheme, if the sensing device detects an error, and the error is due to an unparseable received instruction, it indicates that the error may be caused by external interference or the signal transmission environment. In this case, it can remain in the first state, waiting for the card reader to resend the instruction, without needing to return to the idle state to restart the interaction process. This ensures fault tolerance while improving interaction efficiency.

[0052] Please refer to Figure 2 , Figure 2 This is a system block diagram illustrating a graphical tool development system for autonomous driving development engineering according to an exemplary embodiment. This system enables the following: Figure 1 The graphical tool development method for autonomous driving development projects is shown. For example... Figure 2 As shown, the graphical tool development system for this autonomous driving development project includes an instruction interaction module, a scheduling module, and a processing module.

[0053] The instruction interaction module is used to parse the first instruction input to the development system to generate the first command and the first command parameters.

[0054] The scheduling module is used to generate a corresponding task flow based on the first command and its parameters; the task flow includes at least one pipeline task.

[0055] The processing module is used to execute the pipeline tasks in each task flow in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

[0056] The implementation logic of each of the above modules can be found in [link to documentation]. Figure 1 The embodiments shown are not described in detail here.

[0057] Furthermore, in addition to achieving such Figure 1 In addition to the functions shown, it may also have other functions. The following is a further explanation of the development system architecture shown in the embodiments of this application.

[0058] Optionally, the scheduling module in this embodiment is further configured to:

[0059] Select a project configuration file according to the development command; the project configuration file is used to indicate the preset task flow; the preset task flow includes preset pipeline tasks arranged in a preset order; according to the command parameters, set the parameters of the preset pipeline tasks in the project configuration file to generate the corresponding task flow.

[0060] Specifically, since this system is designed and implemented around multiple modules, each responsible for its independent function, it is decomposed according to the single responsibility principle. For example, the terminal command interaction construction system is used to parse the multiple modules that need to work together to form a complete engineering management tool. Therefore, a scheduler (i.e., the scheduling module in this embodiment) is needed to integrate these modules. The scheduler is responsible for managing the interaction and communication between the various functional modules, deciding when to start a pipeline task flow, and providing shared basic information that is reused among the modules.

[0061] The specific process is as follows: when a user enters a command through the terminal to trigger a task in the command-line tool, the scheduler first receives the request. The scheduler autonomously collects relevant pipeline tasks and distributes them to the corresponding task flows for execution, controlling each stage of the task execution process. When a stage changes, the scheduler sends a notification to all subscribers through an event mechanism. Upon receiving the notification, subscribers will perform corresponding processing operations based on the event content. Overall, this scheduler plays a core role in the entire engineering management tool, serving as the carrier and internal manager of multiple modules, ensuring efficient collaboration between modules to complete predetermined tasks. Figure 3 A flowchart illustrating the workflow of a scheduler according to an embodiment of this application is shown. Figure 3 As shown, the user inputs instructions through the instruction interaction module (which can be a CMD command control unit in this embodiment). The instruction interaction module parses the input instructions into corresponding commands (such as create, build, etc.), and then the scheduler determines how to start the pipeline task flow based on the instructions.

[0062] Furthermore, due to the complex interactive structure involved in this solution and the interrelationships between different modules, implementing it using traditional stacking logic would make the program difficult to maintain and read. To address this issue, this embodiment employs a schema-based instruction construction system. Structured data description significantly improves program maintainability and readability, maintaining a clear structure. After defining the data structure, this embodiment also requires implementing a parser (i.e., a command interpretation and execution module) to convert this structure into a logical structure that the program can recognize, and further into an interactive form that the command line can recognize. When the user triggers a command in the console, the defined interactive method can be invoked and used. Optionally, this embodiment provides various interactive instructions, such as create, install, build, etc., with instruction types that can be set to input, single selection, multiple selection, etc. Furthermore, multi-level nesting via subs allows for highly extensible commands.

[0063] For example, users will use a single-selection interaction when choosing a project template type; an input interaction when linking a Git repository; and a multi-selection interaction when choosing whether to depend on certain modules within a project template. Furthermore, version information and other details will also be required during deployment, which will also necessitate input interaction support.

[0064] Therefore, this application embodiment also requires the design of a terminal command interaction system to support the implementation of this solution, effectively improving the convenience and flexibility of user interaction. To achieve the above objectives, this application embodiment provides a command-line tool, namely... Figure 2 The command-line interaction module in this application parses input commands and dispatches tasks to the scheduler. The command-line tool first obtains a set of terminal instructions from the scheduler and parses these instructions into specific commands. When a user inputs a terminal instruction, the command is passed to the command-line tool through the scheduler. In complex projects, a single instruction may execute multiple different types of tasks. Therefore, in this embodiment, corresponding parameters need to be defined for each instruction, allowing users to selectively pass these parameters according to their needs. After receiving the instruction, the tool parses and outputs the command and its parameters, then passes the parsing result to the scheduler. Upon receiving the command and parameters, the scheduler executes the corresponding logic and starts the pipeline tasks. This command-line tool supports multi-platform and cross-system use and supports global installation, allowing users to invoke it from any terminal. Most mainstream editors currently support embedded terminals, so users can also run commands directly within the editor.

[0065] Optionally, the instruction interaction module is also used to parse the second instruction input to the development system to generate a second command and second command parameters; select a preset task flow and a target pipeline task according to the second instruction; and insert the target pipeline task into a specified position in the preset task flow.

[0066] Optionally, the instruction interaction module is also used to parse the third instruction input into the development system and generate a pipeline task template file based on the third instruction; the pipeline task template file is used to generate corresponding pipeline tasks based on the user's editing operations.

[0067] The Pipeline engine can execute Pipe tasks sequentially. In this embodiment, different Pipe packages are needed to execute tasks, requiring different Pipe packages to be implemented according to their functions. The Pipeline engine, as the core module of this application, determines which types of tasks can be executed. For example, the clean task is used for pre- and post-build cleanup, the submitter is used for Git operations in the release process, and i18n is responsible for project internationalization. We have already implemented some commonly used basic pipe packages, which users can use directly, saving time developing these basic functions. If special project requirements arise, custom development and release of new pipe packages are also possible.

[0068] Specifically, this application also specifies the development process and specifications for the pipe package. Using the command-line tool provided in this application, users can initialize a pipe package. This pipe package automatically generates an entry function, receives a context object, and contains the pipe's own configuration options. Inside the function, users can implement specific pipe logic. After completing the task, the execution flow is passed to the next pipe using the `next` method. After development is complete, users can publish the pipe package to a repository, allowing other projects or developers to use the package. Figure 4 The diagram illustrates the entry template definition and execution flowchart involved in an embodiment of this application. For example... Figure 4 As shown, developers can initialize a pipe package using the command-line tool provided in this application. The pipe package will automatically generate an entry function to receive the context object. At this time, users can also modify the code in the pipe package using code tools to configure the pipe package corresponding to the desired function. Then, developers can insert the configured pipe into the pipeline stream to update the pipeline stream.

[0069] On the other hand, in this embodiment of the application, the Pipe tasks to be executed in the Pipeline flow are specified through a configuration file, and users are also allowed to add custom Pipe packages to the Pipeline flow (that is, to add the pipe to the pipeline flow through the second instruction).

[0070] In this embodiment, the engineering configuration files are stored in the directories of each project. Through a unified convention and protocol, the type of configuration file can be quickly identified. Since different projects have different configuration requirements, the configuration files are distributed across various projects. The configuration files use JSON format, with the main configuration item being "pipeline," which contains the specific Pipe task configuration. Each Pipe configuration item mainly includes the pipe package and pipe options, where the options are private configurations for each Pipe. This design allows each Pipe to flexibly define its parameter structure according to its own needs.

[0071] Furthermore, this application embodiment also includes internal constants and provides flexible usage through template syntax. For example, ${root} represents the root directory of the project and can be directly referenced during configuration. External configuration can adjust the internal strategy according to requirements, thereby improving the flexibility and convenience of project management. When the command invokes the Pipeline, the relevant task flow will start automatically.

[0072] Optionally, in this embodiment, each pipeline task in each task flow shares a context object; the processing module is further configured to write the output of the first pipeline task into the context object and obtain the input of the second pipeline task from the context object.

[0073] Specifically, to achieve automated engineering management, certain individual instructions may require complex logical processing. However, since all instructions share commonalities, it's impractical to place all the logical processing code in the scheduler's instruction parsing section. To address this issue, this application's embodiment designs a Pipeline engine. The Pipeline engine controls the entire process by executing each Pipe sequentially. Each Pipe receives the output of the previous Pipe as input, and the functions of each Pipe are independent and uncoupled. Different Pipes can be flexibly configured according to functional requirements.

[0074] Throughout the execution process, context objects (hereinafter referred to as ctx) act as the medium for transmission and interaction within the Pipeline workflow. ctx effectively ensures the decoupling and independence of the Pipeline workflow; each workflow is created in real-time during execution and destroyed upon completion, thus preventing dirty data from polluting the global environment. Furthermore, ctx provides hooks for establishing communication between the system and the Pipeline. These hooks can trigger corresponding operations at different execution stages, making complex project management processes more flexible and controllable. Figure 5 This illustration shows the structure and execution flowchart of a workflow according to an embodiment of this application. Figure 5 As shown, the pipeline workflow includes a context, a configuration, hooks, and utilities. During execution, the pipeline utilizes these elements to manage data, read configurations, trigger events, and provide general-purpose tools. In the pipeline workflow, pipes A, B, C, etc., are executed in a pre-defined order, with the output of pipe A serving as the input of pipe B, and the output of pipe B serving as the input of pipe C. During pipe execution, data and status can be stored and retrieved in the database, and the context serves as a data transfer and interaction medium for passing data between pipes.

[0075] Optionally, the system also includes a command interpretation and execution module; this module is used to encapsulate the corresponding shell command into a pipeline task, and execute the shell command corresponding to the pipeline task when a request to execute the pipeline command is received from the processing module.

[0076] In the embodiments of this application, many functions of the development tools involve command-line operations such as Git, npm, and fs, thus requiring a command interpreter. To meet this need, a basic Shell function package is implemented in this system, and a Pipe package for executing Shell commands is encapsulated on top of this. By configuring the corresponding Pipe in the Pipeline, various Shell operations can be easily executed and centrally managed in the engineering scheme. This module has high scalability, and any system-related operation can be completed through it. It encapsulates commonly used Shell operations, including background running and child process management, which can be used internally in the engineering system and also provide a consistent operating style and performance externally. To ensure cross-platform compatibility, the module also provides a method for operating system conversion, so the application layer does not need to worry about the differences in the underlying operating system, but only needs to focus on controlling the workflow. Figure 6The structure and operation flow of the command interpretation and execution module are demonstrated. Figure 6 This demonstrates a complete logic from command execution to result data and monitoring, including:

[0077] 1. Execution call (execute call excute(cmd)): The starting point of the entire process is "execute call excute(cmd)", which is the request when the command interpretation and execution module receives the command, where cmd represents the specific command string.

[0078] 2. Command parse: After receiving an execution request, the system first enters the "command parse" stage, where it parses the incoming command to understand its structure and intent.

[0079] 3. Process Execution & Processing: From the "command parse" node, the process can fork a path to "process execution," meaning the system will create a new child process to execute the parsed command. Following "process execution" is the "processing" stage, where the child process performs data processing while executing the command, and the results flow to "stdout" (the standard output).

[0080] 4. Looping Listening: In other words, the command interpretation and execution module can loop through the standard output, and finally print the result to the loop node.

[0081] 5. Until child process execution (unitil child execute) and printing: From the "command parse" node, there is another main path, passing through "unitil child execute" (until child process executes). This means the main process will wait for or monitor the execution status of the child process until it completes.

[0082] Through the above process, the command interpretation and execution module goes through command parsing, creation and execution of subprocesses, real-time processing and listening of standard output, and printing and summarizing of the final results, until the entire command execution process is completed in a closed loop, thereby ensuring that the underlying Shell commands can be effectively encapsulated and executed, and the results are returned to the upper layer logic.

[0083] In summary, the autonomous driving graphical development system provided in this application includes an instruction interaction module, a scheduling module, and a processing module. The instruction interaction module parses the first instruction input into the development system to generate a first command and its parameters. The scheduling module generates a corresponding task flow based on the first command and its parameters. Each task flow includes at least one pipeline task. The processing module then executes the pipeline tasks in each task flow in a preset order to generate the target graphical tool. This solution allows users to input instructions and have the scheduling module generate corresponding task flows, reducing the amount of manual code development required. Furthermore, since the tool development process is implemented through task flow generation by the scheduling module, the compatibility between tools is strong. Therefore, using this graphical tool development system for autonomous driving development can improve tool compatibility while maintaining development efficiency.

[0084] In summary, the autonomous driving graphical development system provided in this application includes an instruction interaction module, a scheduling module, and a processing module. The instruction interaction module parses the first instruction input into the development system to generate a first command and its parameters. The scheduling module generates a corresponding task flow based on the first command and its parameters. Each task flow includes at least one pipeline task. The processing module then executes the pipeline tasks in each task flow in a preset order to generate the target graphical tool. This solution allows users to input instructions and have the scheduling module generate corresponding task flows, reducing the amount of manual code development required. Furthermore, since the tool development process is implemented through task flow generation by the scheduling module, the compatibility between tools is strong. Therefore, using this graphical tool development system for autonomous driving development can improve tool compatibility while maintaining development efficiency.

[0085] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0086] The system in this embodiment is presented in the form of functional units. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0087] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of the present invention. This electronic device can be implemented as a card reader or a sensing device as described above, such as... Figure 7As shown, the electronic device includes one or more processors 10, a memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces).

[0088] The processor 10 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0089] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0090] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the use of the electronic device based on the display of a mini-program landing page. Furthermore, the memory 20 may include high-speed random access memory (RAM), and may also include non-transient memory, such as at least one disk storage device, flash memory device, or other non-transient solid-state storage device. The memory 20 may include volatile memory, such as RAM; the memory may also include non-volatile memory, such as flash memory, hard disk, or solid-state drive; the memory 20 may also include combinations of the above types of memory.

[0091] The electronic device also includes a communication interface 30 for communicating with other devices or communication networks.

[0092] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0093] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A graphical tool development system for autonomous driving development engineering, characterized in that, The system includes an instruction interaction module, a scheduling module, and a processing module; The instruction interaction module is used to parse the first instruction input to the development system to generate a first command and first command parameters; The scheduling module is used to generate a corresponding task flow based on the first command and the first command parameters; the task flow includes at least one pipeline task. The processing module is used to execute the pipeline tasks in each task flow in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

2. The system according to claim 1, characterized in that, Each pipeline task in each task flow shares a context object; the processing module is also used to write the output of the first pipeline task to the context object and obtain the input of the second pipeline task from the context object.

3. The system according to claim 2, characterized in that, The scheduling module is also used for: Select a project configuration file according to the development command; the project configuration file is used to indicate a preset task flow; the preset task flow includes preset pipeline tasks arranged in a preset order; Based on the command parameters, the parameters of the preset pipeline tasks in the project configuration file are set to generate the corresponding task flow.

4. The system according to claim 2, characterized in that, The instruction interaction module is also used to parse the second instruction input to the development system to generate a second command and second command parameters; select a preset task flow and a target pipeline task according to the second instruction; and insert the target pipeline task into a specified position in the preset task flow.

5. The system according to claim 3, characterized in that, The instruction interaction module is also used to parse the third instruction input into the development system and generate a pipeline task template file based on the third instruction; the pipeline task template file is used to generate corresponding pipeline tasks based on the user's editing operations.

6. The system according to any one of claims 1 to 5, characterized in that, The system also includes a command interpretation and execution module; the command interpretation and execution module is used to encapsulate the corresponding shell command into a pipeline task, and execute the shell command corresponding to the pipeline task when a request to execute the pipeline command is received from the processing module.

7. A graphical tool development method for autonomous driving development engineering, characterized in that, The method is executed by a graphical tool development system for autonomous driving development engineering, and the method includes: Receive and parse the first instruction to obtain the first command and its parameters; Based on the first command and its parameters, a corresponding task flow is generated; the task flow includes at least one pipeline task. The pipeline tasks in each task flow are executed in a preset order to generate the target graphics tool; wherein, in each task flow, the second pipeline task receives the output of the first pipeline task as its own input; the first pipeline task is the pipeline task preceding the second pipeline task.

8. The method according to claim 7, characterized in that, The method further includes: Receive and parse the second instruction input to the development system to generate a second command and second command parameters; According to the second instruction, a preset task flow and a target pipeline task are selected, so as to insert the target pipeline task into a specified position in the preset task flow.

9. An electronic device, characterized in that, include: The system includes a memory and a processor, which are interconnected. The memory stores computer instructions, and the processor executes these computer instructions to perform the graphical tool development method for autonomous driving development as described in claim 7 or 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the graphical tool development method for the autonomous driving development project as described in claim 7 or 8.

Images