A method and system for generating a control program based on hierarchical planning

Abstract

The application belongs to the technical field of computer development, and particularly relates to a kind of generation method and system of central control equipment driver based on hierarchical planning, aiming at solving the problems of high degree of artificial dependence, high technical threshold and low efficiency in the existing driver development process.The method comprises the following steps: analyzing device protocol documents and extracting structured protocol information;obtaining standardized operation processes matched with user instructions, combining structured protocol information to generate structured execution plans;generating central control equipment drivers and simulation code for simulating the behavior of the central control equipment according to the structured execution plans and structured protocol information;verifying the central control equipment driver based on the simulation code, and determining or updating the final central control equipment driver according to the verification result.The application reduces the threshold and workload of driver development by constructing an automated process from protocol analysis, plan generation to driver generation and closed-loop verification, significantly improving the efficiency and accuracy of equipment integration.

Description

Technical Field

[0001] This application belongs to the field of computer development technology, specifically relating to a method and system for generating central control equipment drivers based on hierarchical planning. Background Technology

[0002] A central control system (CCS) is a device that centrally controls various third-party devices, such as those with acoustic, optical, and electrical sensors. It is widely used in scenarios such as conference rooms and exhibition halls. To integrate devices from different manufacturers and models into the CC, implementation personnel need to develop corresponding device drivers for each type of device.

[0003] Traditional device driver development processes are highly manual. Implementers first need to carefully study the varied and complex communication protocol documents provided by the equipment manufacturer to understand the equipment's functions, control commands, and status feedback. Then, in the central control system designer software, they manually program or configure the protocol content to convert it into driver data that the central control system can recognize and execute. This process not only demands extremely high technical skills and project experience from the implementers but is also time-consuming, inefficient, and prone to errors.

[0004] To improve efficiency, some solutions have emerged that use large language models to assist in generating code or configurations. However, these solutions cannot directly understand the internal workflow and proprietary data structure of software like the central control designer. Users usually still need to have some protocol knowledge and operate through interactive Q&A, filling in preset templates, or based on existing protocol libraries. This requires a lot of manual intervention and adjustment, and cannot achieve fully automated generation of a process from an unstructured protocol document of any format to a final usable and verified device driver.

[0005] Therefore, existing technologies still have significant shortcomings in reducing the knowledge threshold for implementers and achieving end-to-end automated generation. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, namely the high reliance on manual labor, high technical barriers, and low efficiency of existing driver development processes, this application provides a method for generating central control equipment drivers based on hierarchical planning, comprising the following steps:

[0007] Parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details; Obtain a standardized operating procedure that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan; Based on the structured execution plan and structured protocol information, a central control device driver conforming to a preset data structure and simulation code for simulating the behavior of the central control device are generated. The central control device driver is verified based on the simulation code, and the final central control device driver is determined or updated based on the verification results.

[0008] In some preferred embodiments, parsing the acquired device protocol source data specifically includes: Perform structured parsing to extract text, tables, and key fields; A lightweight language model is used to perform preliminary screening of the device protocol source data to exclude pre-defined invalid sections; A large language model is used to perform deep semantic understanding on the filtered effective content in order to extract the structured protocol information; wherein the parameter scale of the large language model is larger than that of the lightweight language model.

[0009] In some preferred embodiments, a standardized operating procedure matching the received user instructions is obtained by means of: Based on the received user instructions, an experience knowledge base is retrieved to obtain a standardized operation procedure that matches the user instructions. The experience knowledge base stores multiple standardized operation procedures, each of which is associated with the semantic representation of one or more task instructions and defines a series of general execution steps that are independent of specific device protocols to implement the task instructions.

[0010] In some preferred embodiments, the method employs a layered processing architecture, wherein: The upper-level processing flow is responsible for responding to user commands and decomposing tasks to generate the structured execution plan. The lower-level processing flow is responsible for executing specific driver generation tasks according to the execution steps defined in the structured execution plan.

[0011] In some preferred embodiments, the upper-layer processing flow responds to user instructions to generate the structured execution plan, specifically including: The received user instructions are parsed to extract query keywords; Based on the query keywords, semantic retrieval and reordering are performed in the experience knowledge base to obtain the standardized operation process most relevant to the user's instructions. The user instructions, the structured protocol information, and the obtained standardized operation process are input into a preset generation model to generate the structured execution plan.

[0012] In some preferred embodiments, the structured execution plan is a JSON-formatted data object containing fields for defining the task context and a list for defining multiple execution steps, wherein each step in the list defines the type of execution task assigned to that step, the source of input data, and the method of storing output data.

[0013] In some preferred embodiments, the lower-level processing flow executes specific driver generation tasks according to a structured execution plan, specifically including: The data model generation component is invoked to generate model data defining the capabilities of the central control device based on the structured protocol information. The driving logic generation component is invoked to generate driving logic containing specific control logic based on the model data and the structured protocol information. The driving logic is then combined with the model data to form a central control device driver. The driving logic generation component also generates simulation code for simulating the behavior of the central control device based on the structured protocol information.

[0014] In some preferred embodiments, verifying the central control device driver based on the simulation code specifically includes the following steps: The control commands issued by the central control device driver are used as input to the simulation code, and the response output results returned by the simulation code according to the preset behavior logic are obtained. Combining structured protocol information, the correctness of the central control device driver is verified based on the control commands and response output results. Specifically, it is determined whether the control command byte stream matches the command format defined in the structured protocol information, and whether the response output results are consistent with the expected response defined in the structured protocol information.

[0015] In some preferred embodiments, the final central control device driver is determined or updated based on the verification results, specifically including: When the verification result indicates that the central control device driver is correct, the central control device driver is used as the final central control device driver output; When the verification result indicates that there is a deviation in the correctness of the central control device driver, feedback information containing error type and current execution context is generated to correct the structured execution plan, and the central control device driver is regenerated based on the corrected structured execution plan.

[0016] On the other hand, embodiments of this application provide a central control equipment driver generation system based on hierarchical planning, the system comprising: The document parsing module is configured to parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details; The plan generation module is configured to obtain a standardized operation process that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan; The driver generation module is configured to generate a central control device driver conforming to a preset data structure and simulation code for simulating the behavior of the central control device based on the structured execution plan and structured protocol information. The verification and update module is configured to verify the central control device driver based on the simulation code and update the central control device driver according to the verification results.

[0017] The beneficial effects of this application are: 1) This application achieves end-to-end automation from parsing protocol documents to generating verified and usable drivers through an automated process of protocol parsing, task planning and code generation, which greatly improves device integration efficiency; and users do not need to have an in-depth understanding of complex communication protocol details or master professional programming skills, but only need to provide the original protocol documents to obtain device drivers, thus lowering the technical threshold. 2) An automated closed-loop verification mechanism is adopted. Using the parsed structured protocol information, simulation code for simulating device behavior is generated synchronously. The generated simulation code is then used to perform interactive testing with the driver, forming a closed loop of "generation-verification-correction". This ensures that the generated driver strictly conforms to the protocol specifications in terms of function and logic, effectively avoids common errors caused by human negligence, reduces the workload of on-site debugging, and ensures project quality. 3) By introducing an experience knowledge base that stores standardized operating procedures, the system can perform intelligent retrieval and planning based on the experience knowledge base when receiving user instructions. It can decompose user intentions into a series of precise and orderly underlying device operations, enabling it to understand user intentions more accurately and respond flexibly to protocol differences. The reflection and correction mechanism further endows the system with the ability to self-correct, enabling it to flexibly cope with various complex protocols and abnormal situations, and has a stronger robustness and intelligence level. Attached Figure Description

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating a hierarchical planning-based central control equipment driver generation method provided in one embodiment of this application; Figure 2 This is a schematic diagram of the topology of a central control equipment drive generation system based on hierarchical planning provided in one embodiment of this application; Figure 3 This is a schematic diagram of the interface between the central control designer and the AI ​​assistant provided in one embodiment of this application; Figure 4 This is a comparative diagram of a single agent architecture and a layered agent architecture according to an embodiment of this application. The left diagram shows the single agent architecture in the prior art, and the right diagram shows the layered agent architecture of this application. Figure 5 This is a schematic diagram of the workflow of an embodiment of this application using the Plan-Act-Reflect mode; Figure 6 This is a schematic diagram of the structure of a computer system used to implement the methods, systems, and electronic devices of this application. Detailed Implementation

[0019] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] This invention proposes a hierarchical planning-based method and system for generating central control device drivers. It aims to address the problems of low efficiency, high cost, and error-proneness in existing technologies that rely on manual protocol reading and programming when developing drivers for heterogeneous central control devices from different manufacturers. This invention achieves end-to-end automatic generation of device drivers and models—from unstructured device protocol documents to validated drivers that can be directly used in the central control device designer—by constructing a hierarchical multi-agent system and combining it with a Plan-Act-Reflect working mode.

[0022] To more clearly explain the hierarchical programming-based central control equipment driver generation method of this application, the following will be combined with... Figure 1 The methods described in the embodiments of this application will be described in detail.

[0023] Before proceeding with the specific implementation of this application, some core terms involved in this application are first defined: Central Control Designer: A client software installed on the computer of the implementation personnel. In the conference room central control industry, the user's operation interface and active and passive control logic are all designed through the designer. The implementation personnel can adjust the interface and control logic according to the client's needs. The results designed by the designer are then sent to the central control system to ultimately provide services to the user.

[0024] Device driver: In a central control unit (CCU) designer, a driver is the representation of a device model within the designer; it is a concrete implementation of a model. It defines what the device should do when performing certain actions by implementing services, reflects the device's state or other information by implementing attributes, and communicates its state changes externally by implementing events. In this application, it specifically refers to device driver data within the CCU designer.

[0025] Model: In the central control designer, a model is an abstract representation of a class of devices. A model has definitions of attributes, events, and services, representing the general capabilities of this type of device. In this patent, it specifically refers to the device model data in the central control designer, not the general model definition used in IoT. The model data contains various information about the model: ID, name, version, and the services, attributes, and events that the model possesses.

[0026] The hierarchical planning-based central control device driver generation method of the first embodiment of this application, in a specific application scenario, is executed by a cloud-based AI Agent service deployed in the cloud and interacts with the user through a central control designer on the client side. This method aims to achieve end-to-end automatic generation from unstructured device protocol documents to verified drivers and models usable in the central control designer. Figure 1 As shown, steps S100-S400 are included, and each step is described in detail below: S100: Parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details.

[0027] Preferably, the parsed and acquired device protocol source data specifically includes: Perform structured parsing to extract text, tables, and key fields; A lightweight language model is used to perform preliminary screening of the device protocol source data to exclude pre-defined invalid sections; A large language model is used to perform deep semantic understanding on the filtered effective content in order to extract the structured protocol information; wherein the parameter scale of the large language model is larger than that of the lightweight language model.

[0028] For example, the lightweight language model can be a language model with a small parameter size, low computational overhead, and suitable for rapid semantic filtering or preliminary analysis; the large language model can be a language model with a larger parameter size and stronger semantic understanding and reasoning capabilities. Those skilled in the art can choose language models of different sizes or architectures to implement the present invention based on cost, performance, or deployment environment, without being limited by specific model types, parameter sizes, or implementation details.

[0029] Furthermore, in a specific embodiment, when a user uploads a device protocol source data (such as a device manual in PDF or Word format) through the AI ​​assistant interface of the central control designer, the system executes the following sub-steps: 1) Document preprocessing and content extraction: Use specialized document parsing tools to extract plain text content and table data from different formats such as PDF and Word.

[0030] 2) Invalid content filtering: In order to reduce noise in subsequent processing, a lightweight large language model (LLM) is used to quickly scan and initially filter the extracted text by paragraph, automatically identifying and excluding invalid sections such as "Company Profile", "Copyright Statement", "Safety Instructions" and other sections that are not directly related to the device control protocol.

[0031] 3) Structured Information Generation: The filtered and valid content is submitted to a more powerful and larger-scale language model. This model performs deep semantic understanding and information extraction on the text, identifying and extracting key information necessary for device control, such as: communication parameters (baud rate, data bits, etc.), instruction sets (e.g., power-on instructions, input source switching instructions), instruction formats (e.g., the composition of instruction headers, data bodies, and checksums), and the format and meaning of device status feedback. Finally, this information is organized into machine-readable structured protocol information. This embodiment preferably uses JSON format data.

[0032] 4) Vectorized storage: To facilitate subsequent fast semantic retrieval, the system uses an embedding model to vectorize this structured protocol information and its original text fragments, and stores the vector results in a vector database.

[0033] By parsing the acquired device protocol source data, the system transforms an unstructured or semi-structured device manual into a standardized structured data foundation that the AI ​​Agent can directly understand and utilize.

[0034] In a preferred embodiment, the method employs a layered agent architecture, using... Figure 5 The Plan-Act-Reflect pattern shown includes: The upper-layer processing flow is responsible for responding to user commands and decomposing tasks to generate the structured execution plan; the lower-layer processing flow is responsible for executing specific driver-generated tasks according to the execution steps defined in the structured execution plan.

[0035] S200: Obtain the standardized operation process that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan.

[0036] Preferably, the method for obtaining a standardized operating procedure that matches the received user instruction is as follows: Based on the received user instructions, an experience knowledge base is retrieved to obtain a standardized operation procedure that matches the user instructions. The experience knowledge base stores multiple standardized operation procedures, each of which is associated with the semantic representation of one or more task instructions and defines a series of general execution steps that are independent of specific device protocols to implement the task instructions.

[0037] The experience knowledge base described in this embodiment is maintained by R&D personnel or engineers from the after-sales expert group, and contains textual descriptions of the operation procedures corresponding to various types of equipment.

[0038] More preferably, the upper-layer processing flow responds to user instructions to generate the structured execution plan, specifically including: The received user instructions are parsed to extract query keywords; Based on the query keywords, semantic retrieval and reordering are performed in the experience knowledge base to obtain the standardized operation process most relevant to the user's instructions. The user instructions, the structured protocol information, and the obtained standardized operation process are input into a preset generation model to generate the structured execution plan.

[0039] Furthermore, in a specific embodiment, upon entering the "Plan" phase, the upper-layer processing flow responds to user instructions to generate the structured execution plan, specifically including: S201. Intent Analysis and Keyword Extraction: First, the user's natural language input (user instructions) is analyzed to extract core task keywords (such as "generation driver" and "Panasonic projector"). The input may be translated and rewritten to adapt to the language of the knowledge base (such as translating English input into Chinese).

[0040] S202. Knowledge retrieval based on RAG: The Retrieval Enhancement Generation (RAG) technology is used to perform vector similarity queries in the internal experience knowledge base using extracted keywords.

[0041] Optionally, this knowledge base is pre-written by R&D or senior implementation personnel, stored in plain text format, and contains extremely detailed "standardized operating procedures" for machine operation.

[0042] Specifically, an example of a "standardized operating procedure" is as follows: The process of adding a driver: 1. Check if the model exists. If it does not exist, refer to the "Create Model" process; 2. Based on the protocol information, create a device model. 3. Generate the driver logic based on the created model and protocol information; 4. Generate simulation code for verification; 5. Perform closed-loop verification; By using vector query and reranker model, we find the standardized operation process text that best matches the user's intent.

[0043] S203. Generate a structured execution plan: The retrieved standardized operation process text, the structured protocol information obtained in the previous steps, and the user's specific requirements are assembled into a prompt, and then the large language model is called; the large language model generates a structured, multi-step execution plan based on these inputs.

[0044] In a preferred embodiment, the structured execution plan is a JSON-formatted data object containing fields for defining the task context and a list for defining multiple execution steps. Each step in the list defines the assigned task type, input data source, and output data storage method. This decomposes the complex generation task into a series of simple subtasks executed by different lower-level agents.

[0045] By generating structured execution plans, a vague user intent is transformed into a precise, orderly action blueprint that can be automatically executed by machines. This is the core advantage of the layered agent architecture.

[0046] S300. Based on the structured execution plan and structured protocol information, generate a central control device driver that conforms to a preset data structure and simulation code for simulating the behavior of the central control device; Preferably, the lower-level processing flow executes specific driver generation tasks according to the structured execution plan, specifically including: The data model generation component is invoked to generate model data defining the capabilities of the central control device based on the structured protocol information. The driving logic generation component is invoked to generate driving logic containing specific control logic based on the model data and the structured protocol information. The driving logic is then combined with the model data to form a central control device driver. The driving logic generation component also generates simulation code for simulating the behavior of the central control device based on the structured protocol information.

[0047] Furthermore, in a specific embodiment, upon entering the "Act (Execution)" phase, the lower-level processing flow executes specific driver generation tasks according to the structured execution plan, specifically including: S301, Generate Device Model: Call the data model generation component Model-Agent. The prompts in Model-Agent only contain knowledge related to model creation. Based on the protocol information passed by the execution plan, generate model data (JSON format) that defines device capabilities (services, attributes, events).

[0048] S302. Generate device driver: Schedule the driver logic generation component Driver-Agent. Driver-Agent generates driver data (JSON format) based on the generated model data and protocol information.

[0049] The core of Driver-Agent is to generate specific workflows for each service defined in the model, that is, how to assemble and send control commands according to the protocol. The generation logic comes from the large language model's understanding of the knowledge of "how to generate driver workflows" in the experience knowledge base.

[0050] S303. Generating Simulation Code: In order to achieve automated verification, the Driver-Agent component also generates a simulation code.

[0051] The large language model automatically generates a piece of code, such as Python or Node.js, based on the communication type (e.g., TCP / IP, UDP, RS-232) and command response logic in the protocol information. This code can simulate the behavior of a real device: listening on a specific port, receiving commands from the driver, and returning the correct success / failure response or status data according to the protocol specifications.

[0052] While generating the central control device driver, the necessary tools for verifying the correctness of the central control device driver are also generated, preparing for subsequent verification and driver selection.

[0053] Preferably, such as Figure 4 As shown, each step in the execution process needs to determine whether it meets the expected plan. Specifically, when the lower-level processing flow executes any execution step in the structured execution plan, if an execution exception is captured, the upper-level processing flow corrects the structured execution plan based on the execution exception and re-executes the corresponding generation task based on the corrected structured execution plan. When the execution exception cannot be automatically corrected, the user is requested to provide supplementary information to assist in the correction. If the expected results are met, the actuator continues to execute the next step until all steps in the structured execution plan are completed, generating the central control device driver.

[0054] S400. Verify the central control device driver based on the simulation code, and determine or update the final central control device driver based on the verification results.

[0055] Preferably, verifying the central control device driver based on the simulation code specifically includes the following steps: The control commands issued by the central control device driver are used as input to the simulation code, and the response output results returned by the simulation code according to the preset behavior logic are obtained. Combining structured protocol information, the correctness of the central control device driver is verified based on the control commands and response output results. Specifically, it is determined whether the control command byte stream matches the command format defined in the structured protocol information, and whether the response output results are consistent with the expected response defined in the structured protocol information.

[0056] More preferably, the final central control device driver is determined or updated based on the verification results, specifically including: When the verification result indicates that the central control device driver is correct, the central control device driver is used as the final central control device driver output; When the verification result indicates that there is a deviation in the correctness of the central control device driver, feedback information containing error type and current execution context is generated to correct the structured execution plan, and the central control device driver is regenerated based on the corrected structured execution plan.

[0057] More preferably, in a specific embodiment, the process enters the "Reflect" phase, where an automated closed-loop verification process is performed in an isolated environment, specifically including: 1) Startup Interaction: The generated central control device driver is run to call (i.e. control) the startup simulation code. For example, the driver executes the "power on" service, sending a protocol-defined power-on instruction byte stream to the simulation code's listening port.

[0058] 2) Result Determination: Capture the response from the simulation code and make a determination based on the preset verification logic. For example, determine whether the byte stream returned by the simulation code is completely consistent with the "power-on successful" response defined in the protocol document; or check whether a certain status code returned by the simulation server is correct.

[0059] 3) Reflection and Correction: If the verification is successful, this step is complete, and the process continues.

[0060] If verification fails, the system captures this deviation information; this information is fed back to the upper-level Planner Agent; the Planner Agent analyzes the reason for the failure: whether it is a planning error (such as an error in the instruction generation logic) or a lack of necessary information. If it is a planning problem, the execution plan is corrected and the relevant steps are retried (for example, prompting the Driver-Agent to generate instructions in another way); if the information is insufficient, a question is asked to the user through the AI ​​assistant interface (for example, "The method of calculating the checksum defined in the protocol is unclear, please supplement it").

[0061] Optionally, after the verification steps are completed, the system integrates all generated final products (model data, driving data), determines whether all steps have been executed, and if so, summarizes and concludes the results through the user interaction module (see reference). Figure 2 The data is displayed to the user along with a clear "Apply to Project" or "Confirm Generation" button. Only after the user actively confirms will the tool's agent execution module be authorized to formally write the verified and correct data into the current project in the central control designer. Simultaneously, this operation is logged, and the user can undo the generation at any time using the rollback button, ensuring the security and traceability of the operation.

[0062] In summary, this embodiment fully demonstrates the execution flow of the method proposed in this application. By decomposing the complex driver generation task into four ordered steps—protocol parsing, task planning, task execution, and closed-loop verification—it innovatively introduces RAG planning based on an experience knowledge base, hierarchical agent execution, and an automated verification closed loop with a reflective mechanism. This achieves end-to-end automated generation from unstructured documents to verified, ready-to-use central control device drivers. This method significantly improves the efficiency and accuracy of driver development, reduces reliance on human experience, and has significant technological advancements and practical value.

[0063] The second embodiment of this application presents a central control equipment driver generation system based on hierarchical planning, which is used to execute the method described in embodiment one. (Refer to...) Figure 2 The system is deployed in a distributed environment that includes clients and the cloud, comprising a central control designer on the client side and a cloud-based AI Agent service. Its core functional modules include: The document parsing module is configured to parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details; The plan generation module is configured to obtain a standardized operation process that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan; The driver generation module is configured to generate a central control device driver conforming to a preset data structure and simulation code for simulating the behavior of the central control device based on the structured execution plan and structured protocol information. The verification and update module is configured to verify the central control device driver based on the simulation code and update the central control device driver according to the verification results.

[0064] Preferably, the system further includes a task scheduling module, configured to receive and parse the structured execution plan generated by the plan generation module, and then sequentially call, coordinate and manage the driver generation module and the closed-loop verification module according to the step sequence and dependencies defined in the plan.

[0065] Preferably, the system further includes a knowledge base module, a client communication module for cloud communication, and a large model interaction module for interaction. The knowledge base module contains an experience knowledge base, which stores multiple standardized operation procedures. Each standardized operation procedure is associated with the semantic representation of one or more task instructions and defines a series of general execution steps that are independent of specific device protocols to implement the task instruction.

[0066] Preferably, the system adopts a hierarchical, multi-level agent architecture, namely Plan-Act-Reflect, with different executors at each level. (See also...) Figure 4 The left figure shows a monolithic agent architecture in existing technologies. Traditional monolithic agents need to process all types of task and tool information within a single prompt. When business logic becomes complex and the number of tools increases, this leads to excessively long contexts and cluttered information, resulting in decreased inference performance and success rate for LLM. This embodiment, however, decomposes tasks through a layered agent architecture, such as... Figure 4 The image on the right specifically includes: The document parsing module is integrated into the cloud-based AI Agent service. It is responsible for receiving device protocol source data uploaded by the client and using a series of models and tools to parse it into structured protocol information.

[0067] The plan generation module is the upper-level planning agent (PlannerAgent) in the multi-level agent architecture. This module is responsible for top-level task planning. It receives the user's original intent and, through interaction with the experience knowledge base (described later), decomposes complex and ambiguous user requests into a clear, orderly, and structured multi-step execution plan.

[0068] The task scheduling module is the middle-level scheduling agent (DispatcherAgent) in the multi-level agent architecture. It is responsible for task distribution and context management. It receives the execution plan generated by the planning agent and, according to the steps in the plan, calls the corresponding lower-level execution agents in sequence and passes the necessary input data (context) to them.

[0069] The driving generation module is the lower-level execution agent (ExecutorAgent) in the multi-level agent architecture, which includes multiple generation components (sub-specialty agents) that execute different tasks. According to the instructions and context (such as protocol information and model data) passed by the scheduling module, each generation component is responsible for executing a specific, single task.

[0070] In this embodiment, these generation components are domain-specific experts. For example, Model-Agent focuses on generating device model data, Driver-Agent focuses on generating driver logic code, and Space-Agent is responsible for querying and managing project space information. Because the prompts and toolsets for each execution agent are highly focused on their own tasks, the accuracy and stability of execution are significantly improved.

[0071] By breaking the system down into independent agents, the complexity of development, testing, and maintenance is reduced, and the coupling between business functions is significantly decreased, facilitating modular iteration and minimizing the impact between different business functions. Based on a multi-layered agent design, the agent parsing the protocol document can use prompt word engineering and RAG technology to assist the large model in understanding the content of the protocol document, identifying which parts of the document are needed, which are invalid, and which are key information for generating drivers and models. This extends the general capabilities of the large model to the concrete business functions of the central control designer, thereby shifting the workload from implementation personnel to the large model.

[0072] Preferably, the system further includes an interaction and execution module, serving as the interaction entry point between the user and the backend intelligent service (central control designer). This module itself does not perform complex AI reasoning but primarily acts as an agent. This module includes: The user interaction module is responsible for presenting the AI ​​interactive interface, receiving users' natural language input or file uploads, and displaying the results returned from the cloud (such as text, data, confirmation requests) to the user. The cloud communication and authentication submodule is responsible for securely encrypting and transmitting requests from the user interaction module to the cloud service, while authenticating the identities of both communicating parties to ensure the security and compliance of data transmission. The tool's agent execution submodule is responsible for writing the final driver data, verified in the cloud, to the local project after obtaining user authorization. To ensure data security and operational control, this module requests explicit authorization from the user before performing any operations that create, modify, or delete local data such as drivers or models. Simultaneously, this module records all operation logs and supports log-based rollback operations, allowing users to undo unwanted modifications.

[0073] Please see Figure 3 The diagram illustrates the user interface of the central control designer. Users can interact with the system through the AI ​​dialogue bar on the right side of the interface. For example, a user can enter, "Please generate a driver for this PDF agreement document I uploaded," or "Help me modify the startup command of the projector driver." The user interaction module captures these inputs and sends them to the cloud AI Agent service via the cloud communication and authentication module. The cloud processes the data and returns the results, such as a preview of the generated data, a query, or an operation confirmation prompt, which is then displayed on the interface by the user interaction module.

[0074] In summary, the system disclosed in this embodiment provides a complete, efficient, and stable operating platform for the method in Embodiment 1 through its innovative C / S architecture and clear "planning-scheduling-execution" three-tiered agent design. This system decouples plan generation, task scheduling, and multiple dedicated execution processes, forming a clear command chain. This not only ensures that complex tasks can be executed in an orderly and reliable manner but also greatly improves the system's scalability and maintainability.

[0075] It should be noted that the hierarchical planning-based central control equipment driver generation system provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of this application can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of this application are only for distinguishing the various modules or steps and are not considered as an improper limitation of this application.

[0076] A device according to a third embodiment of this application includes: At least one processor; and a memory communicatively connected to at least one of the processors; The memory stores instructions that can be executed by the processor to implement the above-described hierarchical planning-based central control device driver generation method.

[0077] A computer-readable storage medium according to a fourth embodiment of this application stores computer instructions, which are executed by the computer to implement the above-described hierarchical planning-based central control device driver generation method.

[0078] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0079] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system for implementing embodiments of the systems, methods, and electronic devices of this application. Figure 6 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0080] like Figure 6 As shown, the computer system includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 602 or programs loaded from storage section 608 into Random Access Memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

[0081] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0082] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0083] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0085] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0086] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0087] The technical solutions of this application have been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of this application is obviously not limited to these specific embodiments. Without departing from the principles of this application, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of this application.

Claims

1. A method for generating central control equipment drivers based on hierarchical planning, characterized in that, Includes the following steps: Parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details; Obtain a standardized operating procedure that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan; Based on the structured execution plan and structured protocol information, a central control device driver conforming to a preset data structure and simulation code for simulating the behavior of the central control device are generated. The central control device driver is verified based on the simulation code, and the final central control device driver is determined or updated based on the verification results.

2. The method for generating central control equipment drivers based on hierarchical planning according to claim 1, characterized in that, The obtained device protocol source data, obtained through parsing, specifically includes: Perform structured parsing to extract text, tables, and key fields; A lightweight language model is used to perform preliminary screening of the device protocol source data to exclude pre-defined invalid sections; A large language model is used to perform deep semantic understanding on the filtered effective content in order to extract the structured protocol information; wherein the parameter scale of the large language model is larger than that of the lightweight language model.

3. The method for generating central control equipment drivers based on hierarchical planning according to claim 1, characterized in that, The method for obtaining a standardized operating procedure that matches the received user instructions is as follows: Based on the received user instructions, an experience knowledge base is retrieved to obtain a standardized operation procedure that matches the user instructions. The experience knowledge base stores multiple standardized operation procedures, each of which is associated with the semantic representation of one or more task instructions and defines a series of general execution steps that are independent of specific device protocols to implement the task instructions.

4. The method for generating central control equipment drivers based on hierarchical planning according to claim 1, characterized in that, The method employs a layered processing architecture, wherein: The upper-level processing flow is responsible for responding to user commands and decomposing tasks to generate the structured execution plan. The lower-level processing flow is responsible for executing specific driver generation tasks according to the execution steps defined in the structured execution plan.

5. The method for generating central control equipment drivers based on hierarchical planning according to claim 4, characterized in that, The upper-layer processing flow responds to user instructions to generate the structured execution plan, specifically including: The received user instructions are parsed to extract query keywords; Based on the query keywords, semantic retrieval and reordering are performed in the experience knowledge base to obtain the standardized operation process most relevant to the user's instructions. The user instructions, the structured protocol information, and the obtained standardized operation process are input into a preset generation model to generate the structured execution plan.

6. The method for generating central control equipment drivers based on hierarchical planning according to claim 5, characterized in that, The structured execution plan is a JSON-formatted data object containing fields for defining the task context and a list for defining multiple execution steps. Each step in the list defines the type of execution task assigned to that step, the source of input data, and the method of storing output data.

7. The method for generating central control equipment drivers based on hierarchical planning according to claim 4, characterized in that, The lower-level processing flow executes specific driver generation tasks according to the structured execution plan, specifically including: The data model generation component is invoked to generate model data defining the capabilities of the central control equipment based on the structured protocol information. The driving logic generation component is invoked to generate driving logic containing specific control logic based on the model data and the structured protocol information. The driving logic is then combined with the model data to form a central control device driver. The driving logic generation component also generates simulation code for simulating the behavior of the central control device based on the structured protocol information.

8. The method for generating central control equipment drivers based on hierarchical planning according to claim 1, characterized in that, Verifying the central control device driver based on the simulation code specifically includes the following steps: The control commands issued by the central control device driver are used as input to the simulation code, and the response output results returned by the simulation code according to the preset behavior logic are obtained. Combining structured protocol information, the correctness of the central control device driver is verified based on the control commands and response output results. Specifically, it is determined whether the byte stream of the control commands matches the command format defined in the structured protocol information, and whether the response output results are consistent with the expected response defined in the structured protocol information.

9. The method for generating central control equipment drivers based on hierarchical planning according to claim 8, characterized in that, The final central control device driver is determined or updated based on the verification results, specifically including: When the verification result indicates that the central control device driver is correct, the central control device driver is used as the final central control device driver output; When the verification result indicates that there is a deviation in the correctness of the central control device driver, feedback information containing error type and current execution context is generated to correct the structured execution plan, and the central control device driver is regenerated based on the corrected structured execution plan.

10. A central control equipment drive generation system based on hierarchical programming, characterized in that, include: The document parsing module is configured to parse the acquired device protocol source data to extract structured protocol information containing device functions, status, and communication protocol details; The plan generation module is configured to obtain a standardized operation process that matches the received user instruction, and parse the user instruction in conjunction with the structured protocol information to generate a structured execution plan; The driver generation module is configured to generate a central control device driver conforming to a preset data structure and simulation code for simulating the behavior of the central control device based on the structured execution plan and structured protocol information. The verification and update module is configured to verify the central control device driver based on the simulation code and update the central control device driver according to the verification results.

Images