A power intelligent terminal service software dynamic calling method and system

Abstract

The application belongs to the technical field of power service software dynamic calling, and discloses a power intelligent terminal service software dynamic calling method and system. The method comprises the following steps: dividing a service function module into atomic capability units, implementing each atomic capability unit as an independent process which can be called through a command line, providing an external calling entrance through a CLI wrapper without modifying the original code, and automatically generating self-description meta information; executing self-description meta information configuration; querying the capability registry table, and evaluating the security level of the capability combination; decomposing a service task into a subtask sequence and mapping the subtask sequence into a CLI calling sequence; sequentially executing the CLI calling sequence, transferring stdin / stdout data in a pipeline mode between adjacent calls, and checking the output result after each calling step, triggering retry, rollback or alarm in an exception. The power intelligent terminal can be safely and efficiently discovered, arranged and called by an external intelligent agent under strict resource limitation and industrial safety constraints.

Description

Technical Field

[0001] This invention belongs to the field of dynamic invocation technology of power business software, and specifically relates to a method and system for dynamic invocation of power intelligent terminal business software. Background Technology

[0002] In current scenarios of power distribution automation, transformer substation management, and distributed energy control, various types of power smart terminals with limited hardware resources are widely deployed, and the terminal business software generally adopts a pre-fabricated execution paradigm that is fixed during the development stage.

[0003] Existing terminal operating paradigms, communication protocols, and related technical solutions have multiple shortcomings, failing to meet the needs of external intelligent agents for dynamic, secure, and auditable invocation of terminal services in resource-constrained scenarios.

[0004] Currently, the industry employs various solutions to adapt to terminal operation and interaction requirements. Business updates rely on static methods such as firmware OTA remote upgrades and overall application replacements to adapt to scenario changes. Device interaction relies on power-specific protocols to achieve data and command interaction. For general scenarios, technologies such as MCP, gRPC, and OPC UA for AI are being explored. The academic community has also verified the feasibility of CLI interfaces for Agent calls. Meanwhile, existing patents propose related technical solutions such as plug-in orchestration, cloud-edge-device collaboration, and AI-edited PLCs.

[0005] Existing solutions all have core flaws. Static upgrades can only achieve version replacement and lack the ability to dynamically call or reorganize functions at runtime. Power-specific protocols lack dynamic discovery and calling mechanisms for business functions, and general protocols such as MCP and gRPC consume too much memory and cannot be adapted to resource-constrained terminals. Academic research and existing patent solutions have not adapted to the safety constraints of the power industry and cannot atomically expose the internal business of the terminal, resulting in the black box of terminal business. Ultimately, this makes it difficult and costly to transform existing terminals and makes it difficult to integrate them into the AI ​​scheduling system on a large scale. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for dynamically calling business software of power intelligent terminals, so as to solve the problems of excessive protocol memory consumption, inability to adapt to resource-constrained terminals, and high difficulty and cost of upgrading existing terminals, making it difficult to integrate them into the AI ​​scheduling system on a large scale.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a method for dynamically invoking business software of a power smart terminal, comprising the following steps: Business function modules are divided into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameters for input, stdout for output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. Execute self-describing metadata configuration so that each CLI command implements the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal; Query the capability registry, select capability combinations according to business needs, verify compatibility and prerequisites by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The business task is decomposed into a sequence of subtasks and mapped to a CLI call sequence. The decision-making agent determines the strategic parameters. The CLI call sequence is executed in sequence, and stdin / stdout data is passed between adjacent calls in a pipeline manner. The output result is checked after each call, and retry, rollback or alarm is triggered when an exception occurs.

[0008] Furthermore, the self-describing meta-information configuration is implemented using an atomic capability self-describing registration protocol. The atomic capability self-describing registration protocol describes the input parameters, output fields, parameter constraints, error codes, preconditions, postconditions, and security levels of the atomic capability unit based on JSON Schema. The input parameters are at least divided into data parameters and policy parameters.

[0009] Furthermore, the capability registry further records the version identifier, dependency declaration, call entry point, applicable terminal type, and status information of each atomic capability unit. The decision-making agent performs compatibility verification and capability selection based on the version identifier and dependency declaration.

[0010] Furthermore, the business task decomposition and CLI call orchestration are implemented using a hierarchical task decomposition method, which decomposes the business objective into multiple sub-tasks with related constraints, and selects at least one of the sequential orchestration mode, conditional orchestration mode, and cyclic orchestration mode for the sub-tasks to form an executable CLI call sequence; before executing the CLI call sequence, a pre-check is performed on parameter integrity, dependency legality, and security level matching.

[0011] Furthermore, the method also includes hierarchical operation permissions and security sandbox control, wherein the security level is divided into four levels from L0 to L3, corresponding to autonomous execution, execution after recording, execution after manual confirmation, and execution after dual approval, respectively; the security level assessment result is used to constrain the call execution permissions, and the system calls, access paths, and resource operations involved in CLI calls are whitelisted and controlled through a process-level sandbox.

[0012] Furthermore, CLI wrapper adaptation for existing terminals includes the following sub-processes: Identify the existing interfaces and reusable call paths of the original business modules; Construct a CLI wrapper corresponding to the existing interface; Inject the wrapper capability information into the capability registry; Establish a zero-intrusion external call entry point while keeping the original business code unchanged; Expand the coverage of the wrapper gradually according to the terminal capabilities to achieve incremental deployment.

[0013] Furthermore, the system invokes CLI commands to retrieve the current state, compares the actual state with the expected state, regenerates and re-executes the corrected call sequence if the goal is not achieved, and records the entire call process in the audit log.

[0014] Secondly, the present invention provides a dynamic invocation system for power intelligent terminal business software, comprising: The capability provision module is used to divide business function modules into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameter input, stdout output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. The self-describing metadata configuration module is used to perform self-describing metadata configuration, enabling each CLI command to implement the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal. The decision-making agent calculation module is used to query the capability registry, select capability combinations according to business needs, verify compatibility and preconditions by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The calling module is used to decompose business tasks into sub-task sequences and map them into CLI calling sequences. The decision-making agent determines the strategic parameters. The CLI calling sequence is executed sequentially, and stdin / stdout data is passed between adjacent calls in a pipeline manner. The output results are checked after each call, and retry, rollback or alarm is triggered when an exception occurs.

[0015] Thirdly, the present invention provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the dynamic invocation method for power smart terminal business software.

[0016] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the dynamic invocation method for power intelligent terminal business software.

[0017] Compared with the prior art, the present invention has the following technical effects: This invention transforms the business software of power intelligent terminals from a pre-built execution paradigm to a dynamic invocation mode based on CLI-based atomic capability units. Through agent-driven capability discovery, pipelined orchestration, and closed-loop verification mechanisms, it achieves on-demand dynamic reconfiguration and secure execution of business functions in resource-constrained embedded environments. Specifically, this method significantly reduces invocation resource overhead by constructing independent command-line processes on the terminal side according to the single responsibility principle and encapsulating data interaction in a unified stdin / stdout and JSON format. It can be deployed seamlessly on field terminals with 64MB-256MB of RAM; the standard invocation latency meets the near real-time business requirements of fault analysis and regulation planning. For existing terminals, zero-intrusion adaptation can be achieved through CLI wrappers, with small memory increments, supporting gradual deployment and significantly reducing transformation costs and timelines. Simultaneously, this method establishes a unified discovery and compatibility verification mechanism based on --schema self-describing metadata and a capability registry, providing the agent with an interpretable and verifiable view of terminal capabilities. Combined with L0-L3 four-level permission control and a process-level sandbox, a security audit chain is embedded in every invocation process, introducing extremely low additional security overhead while maintaining flexible orchestration.

[0018] Furthermore, the stdin / stdout pipe-based data transfer method directly utilizes Linux pipes to achieve efficient command transmission, providing ample data interaction bandwidth for collaborative orchestration of multiple capability units. This solves problems in existing technologies such as the black-box nature of terminal functions, the inability to dynamically invoke them, excessive memory consumption of general protocols, and the difficulty of integrating existing terminals into AI scheduling systems. It enables power intelligent terminals to be safely and efficiently discovered, orchestrated, and invoked by external intelligent agents under strict resource constraints and industrial safety requirements. Attached Figure Description

[0019] Figure 1 This is a diagram of the overall system architecture of the present invention.

[0020] Figure 2 This is a flowchart illustrating the CLI-based business function design of this invention.

[0021] Figure 3 This is a timing diagram for capability discovery and dynamic invocation in this invention.

[0022] Figure 4 This is a diagram of the hierarchical access control and security sandbox architecture of this invention.

[0023] Figure 5 This is a diagram showing the CLI adaptation architecture for existing terminals in this invention.

[0024] Figure 6 This is a flowchart of the CLI call in Example 2.

[0025] Figure 7 This is a flowchart of the CLI call in Example 3.

[0026] Figure 8 This is a flowchart of the CLI call in Example 4.

[0027] Figure 9 This is a flowchart of the CLI call in Example 5.

[0028] Figure 10 This is a flowchart of the present invention. Detailed Implementation

[0029] The present invention will be further described below with reference to the accompanying drawings: Example 1, please refer to Figure 10 This invention provides a method for dynamically invoking business software in a power smart terminal, comprising the following steps: S1 divides business function modules into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameter input, stdout output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. The originally cohesive business modules are decoupled into smaller, more granular atomic capability units, each responsible for a single, clearly defined business sub-function. Each atomic capability unit is encapsulated as an independent command-line executable program. Its input is uniformly received as JSON structured data via standard input stdin or command-line parameters, and its output is returned as JSON structured results via standard output stdout, thus establishing a unified interaction contract. For existing terminals already running on the network, there is no need to modify the original business code. Instead, by building a CLI wrapper, calls to the original function library or process are intercepted and forwarded, and parameters, return values, and other information are automatically extracted from the existing interface metadata to generate self-describing capability declarations, achieving zero-intrusion external call capabilities.

[0030] Native CLI Mode: On newly developed or refactored terminals, write independent executable programs in C language directly according to the Single Responsibility Principle. The program parses parameters through argc / argv, reads the JSON context passed from the pipe from stdin, performs calculations, writes the results to stdout in JSON format, and executes the results with exit code 0 / non-zero. Each atomic capability unit has a preset --schema option.

[0031] Existing Terminal Wrapper Pattern: For traditional monolithic business applications, a lightweight CLI wrapper is written. This wrapper provides a command-line entry point for each exposed function, dynamically loads existing shared libraries or calls existing interfaces through inter-process communication, maps the input parameters of the existing interfaces to JSON fields, and reassembles the return results into JSON output.

[0032] The internal business functions of the terminal have been transformed from a black box and fixed form into a set of atomic capabilities that can be accessed independently and freely combined. The unified stdin / stdout and JSON interfaces have eliminated communication barriers between heterogeneous functions; while the wrapper solution enables a large number of existing terminals to be integrated into the AI ​​scheduling system with extremely low resource overhead and engineering workload. The adaptation of a single module only requires a man-day workload, which greatly reduces the transformation cost.

[0033] S2 executes self-describing meta-information configuration, enabling each CLI command to implement the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal. Machine-readable self-describing metadata is created for each atomic capability unit and centrally managed through a capability registry maintained locally on the terminal. Each CLI command must implement the `--schema` parameter. When called with the `--schema` parameter, the command outputs a JSON capability description document conforming to a predefined structure to stdout. This description must include at least: command name, input parameter format, output field pattern, execution preconditions, postconditions, and security level. The capability registry summarizes a summary index of all currently available atomic capability units on the terminal, recording each unit's command name, version identifier, dependencies, invocation entry path, applicable terminal type, and running status for quick external lookup.

[0034] For native CLI modules, programmers can directly define structs that conform to the JSON Schema specification in their code and serialize the output under the --schema path.

[0035] The registry can be a static JSON file or a lightweight key-value store, written by each atomic capability unit upon terminal startup. This file contains a JSON array, with each element corresponding to a summary of a command. The decision-making agent reads this file once during connection establishment to complete capability discovery, and can subsequently invoke the `--schema` option of a specific command to retrieve complete detailed constraints as needed.

[0036] The self-describing mechanism allows external agents to understand the semantics, constraints, and risks of each capability without needing to pre-code any terminal knowledge. Version identifiers and dependency declarations support automatic compatibility checks, preventing call failures due to software version mismatches.

[0037] S3. Query the capability registry, select capability combinations according to business needs, verify compatibility and prerequisites by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The agent first loads the terminal capability registry to obtain a list of available capabilities, and then filters a set of candidate capabilities from the list based on the current business objectives. Next, the agent sequentially calls the `--schema` interface of these candidate capabilities to obtain their complete input / output patterns and preconditions, and performs compatibility checks: including checking whether the input and output fields match between different commands, whether the version identifier meets the requirements, whether all dependencies are satisfied, and verifying that the applicable terminal types of these capabilities are consistent with the current terminal. Finally, the agent extracts the security level declared in each candidate capability and summarizes them into an overall security risk rating for this call chain, providing a basis for subsequent execution control.

[0038] Internally, the Agent can implement the above process as a planner module. Specifically, it maintains a session state machine, first sending batch registry queries to obtain a list of capabilities; then performing a coarse screening based on the business semantic model; subsequently, asynchronously and concurrently or sequentially sending `command_name --schema` calls to parse the returned JSON schema; using graph theory or a rule engine to check input / output field alignment; and reading a pre-configured security policy library to map L0-L3 to different operational restrictions. After all verifications pass, a verified candidate capability combination and risk rating report is generated.

[0039] This step dynamically combines explicit business knowledge (from the Agent) with the terminal's own capability self-description, enabling runtime capability discovery and matching without manual configuration. A multi-party verification mechanism ensures that the orchestrated call sequence is syntactically and logistically feasible and controllable, fundamentally preventing incidents caused by interface mismatches, version conflicts, or unauthorized calls.

[0040] S4. Decompose the business task into a sequence of subtasks and map them to a CLI call sequence. The decision-making agent determines the strategic parameters. Execute the CLI call sequence in sequence, pass stdin / stdout data between adjacent calls in a pipeline manner, and check the output result after each call. If an exception occurs, trigger a retry, rollback, or alarm.

[0041] S4 executes actual dynamic orchestration and invocation based on the capability set verified by S3. The Agent hierarchically decomposes macro-level business tasks into a sub-task tree, then maps leaf tasks one-to-one to specific CLI command invocation sequences. During mapping, the Agent populates policy parameters based on real-time status and external environment data read from the terminal. During execution, the Agent starts each CLI command process sequentially, connecting the stdout of the previous command directly to the stdin of the next command via an anonymous pipe in the operating system, transmitting structured JSON data in a streaming manner to avoid storing intermediate results on disk. After each command is executed, the Agent immediately parses its output, checking if it meets the postconditions declared in `--schema`. If an anomaly occurs, such as a non-zero exit code, missing fields, or exceeding numerical limits, the Agent automatically triggers retries, rolls back to the previous safe state, or alerts the operations system according to pre-defined policies.

[0042] Hierarchical task decomposition and pipelined orchestration enable complex power business processes to be automatically broken down into the simplest atomic, ordered combinations, significantly improving business response flexibility. Utilizing Linux pipes for inter-command data transfer directly leverages the operating system kernel's efficient zero-copy mechanism, achieving a basic throughput of 5GB / s and a zero-copy throughput of 35-65 GiB / s, meeting the low-latency transmission requirements of multi-data fusion scenarios. Pre-fork pools, pre-checks, and tiered exception handling mechanisms ensure execution efficiency while providing industrial-grade process robustness and traceability, enabling dynamic calls to operate stably in closed loops under complex real-world conditions.

[0043] Example 2 is applicable to a single-phase grounding fault scenario in a 10kV distribution line. The field terminal is a feeder terminal unit (FTU) fault indicator, responsible for collecting fault waveforms, switch status, and feeder topology information. When a grounding fault occurs on the line, the decision-making agent uses dynamically orchestrated CLI atomic capabilities on the terminal side to complete fault information reading, feature extraction, topology association, fault segment location, isolation scheme generation, control execution, and recovery verification.

[0044] This embodiment is executed according to steps S101-S107, and the call sequence is shown in the table below.

[0045]

[0046] In this embodiment, S106 is a controllable operation that requires manual confirmation before execution; S101-S105 and S107 are read-only or analysis operations that are executed autonomously by the Agent and logs are recorded.

[0047] Parameter configuration

[0048] Performance data

[0049] Difference analysis with other embodiments

[0050] Example 3 is applicable to scenarios where the transformer substation is heavily overloaded and requires flexible peak shaving. The field terminal is a smart distribution transformer terminal (TTU), connected to downstream electric vehicle charging stations, HVAC loads, and energy storage devices. The decision-making agent queries load status, predicts short-term load trends, discovers flexible resources, generates peak shaving plans, issues demand response instructions, and records settlement information to achieve real-time flexible control of the transformer substation load.

[0051] This embodiment is executed according to steps S201-S207, and the call sequence is shown in the table below.

[0052]

[0053] S205 involves actual regulatory actions and requires manual confirmation before execution; S207 is used to record regulatory results and subsequent settlement basis, and is an operation to be executed after recording.

[0054] Key parameter configuration

[0055] Performance data

[0056] Difference analysis with other embodiments

[0057] Example 4 is applicable to scenarios where fluctuations in photovoltaic output lead to increased risks of feeder voltage exceeding limits or backfeed power. The field terminal is a distributed energy controller, responsible for collecting photovoltaic inverter status, weather information, and grid node status, and receiving power optimization schemes generated by the Agent. During operation, the Agent dynamically selects adjustment strategies based on power, irradiance, weather forecasts, and grid status to orchestrate and control the active and reactive power output of the inverter.

[0058] This embodiment is executed according to steps S301-S307, and the call sequence is shown in the table below.

[0059]

[0060] Key parameter configuration

[0061] Performance data

[0062] Difference analysis with other embodiments

[0063] Example 5 is applicable to a comprehensive management scenario where the voltage at the end of a low-voltage distribution area is too low or the voltage at some local nodes exceeds the limit. The field terminal is a smart distribution area fusion terminal, connecting voltage regulating transformers, capacitor banks, line voltage regulators, and distributed energy resources. The Agent dynamically combines and calls upon various voltage regulating resources with the goal of minimizing voltage quality and network losses, and determines the management effect through closed-loop verification.

[0064] This embodiment is executed according to steps S401-S408, and the call sequence is shown in the table below.

[0065]

[0066] In this embodiment, S405 and S406 are device control commands, both of which require manual confirmation. If the governance scheme includes more device actions, such as SVG setting or DER reactive power scheduling, it can be further expanded in the plan generated in S404, but its invocation mechanism remains consistent with the method of this invention.

[0067] Key parameter configuration

[0068] Performance data

[0069] Difference analysis with other embodiments

[0070] The four embodiments described above cover four typical power business scenarios: fault handling, flexible load regulation, distributed energy power regulation, and comprehensive voltage management. They demonstrate the unified invocation mechanism of this invention under different terminals, different business objectives, and different control objects. Although the specific command names, input parameters, and output fields of each embodiment differ, they all follow the common methods defined in steps S1-S5: based on CLI atomic capability units, discovery is completed through --schema and the capability registry; runtime orchestration is performed through the Agent; data flow is completed through stdin / stdout / pipe; security is ensured through hierarchical permission control and process sandboxing; and a closed loop is formed by verifying commands.

[0071] In another embodiment of the present invention, a dynamic invocation system for power intelligent terminal business software is provided, which can be used to implement the above-mentioned dynamic invocation method for power intelligent terminal business software. Specifically, the system includes: The capability provision module is used to divide business function modules into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameter input, stdout output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. The self-describing metadata configuration module is used to perform self-describing metadata configuration, enabling each CLI command to implement the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal. The decision-making agent calculation module is used to query the capability registry, select capability combinations according to business needs, verify compatibility and preconditions by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The calling module is used to decompose business tasks into sub-task sequences and map them into CLI calling sequences. The decision-making agent determines the strategic parameters. The CLI calling sequence is executed sequentially, and stdin / stdout data is passed between adjacent calls in a pipeline manner. The output results are checked after each call, and retry, rollback or alarm is triggered when an exception occurs.

[0072] The module division in this embodiment of the invention is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of the invention can be integrated into a single processor, exist as separate physical entities, or be integrated into a single module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0073] In another embodiment of the present invention, a computer device is provided, comprising a processor and a memory. The memory stores a computer program, which includes program instructions. The processor executes the program instructions stored in the computer storage medium. The processor may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. It is the computing and control core of the terminal, suitable for implementing one or more instructions, specifically suitable for loading and executing one or more instructions from the computer storage medium to achieve a corresponding method flow or corresponding function. The processor described in this embodiment of the present invention can be used for the operation of a dynamic invocation method in power intelligent terminal business software.

[0074] In another embodiment of the present invention, a storage medium is provided, specifically a computer-readable storage medium (Memory), which is a memory device in a computer device used to store programs and data. It is understood that the computer-readable storage medium here can include both the built-in storage medium in the computer device and extended storage media supported by the computer device. The computer-readable storage medium provides storage space that stores the terminal's operating system. Furthermore, the storage space also stores one or more instructions suitable for loading and execution by a processor. These instructions can be one or more computer programs (including program code). It should be noted that the computer-readable storage medium here can be high-speed RAM or non-volatile memory, such as at least one disk storage device. The processor can load and execute one or more instructions stored in the computer-readable storage medium to implement the corresponding steps of the dynamic invocation method for power smart terminal business software in the above embodiments.

[0075] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0076] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0077] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0078] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0079] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the protection scope of the claims of the present invention.

Claims

1. A method for dynamically invoking business software of a power intelligent terminal, characterized in that, Includes the following steps: Business function modules are divided into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameters for input, stdout for output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. Execute self-describing metadata configuration so that each CLI command implements the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal; Query the capability registry, select capability combinations according to business needs, verify compatibility and prerequisites by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The business task is decomposed into a sequence of subtasks and mapped to a CLI call sequence. The decision-making agent determines the strategic parameters. The CLI call sequence is executed in sequence, and stdin / stdout data is passed between adjacent calls in a pipeline manner. The output result is checked after each call, and retry, rollback or alarm is triggered when an exception occurs.

2. The method for dynamically invoking power intelligent terminal business software according to claim 1, characterized in that, The self-describing meta-information configuration is implemented using an atomic capability self-describing registration protocol. The atomic capability self-describing registration protocol describes the input parameters, output fields, parameter constraints, error codes, preconditions, postconditions, and security levels of the atomic capability unit based on JSON Schema. The input parameters are at least divided into data parameters and policy parameters.

3. The method for dynamically invoking power intelligent terminal business software according to claim 2, characterized in that, The capability registry further records the version identifier, dependency declaration, call entry point, applicable terminal type, and status information of each atomic capability unit. The decision-making agent performs compatibility verification and capability selection based on the version identifier and dependency declaration.

4. The method for dynamically invoking power intelligent terminal business software according to claim 1, characterized in that, The business task decomposition and CLI call orchestration are implemented using a hierarchical task decomposition approach, which decomposes the business objective into multiple sub-tasks with associated constraints, and selects at least one of the sequential orchestration mode, conditional orchestration mode, and cyclic orchestration mode for the sub-tasks to form an executable CLI call sequence; before executing the CLI call sequence, a pre-check is performed on parameter integrity, dependency legality, and security level matching.

5. The method for dynamically invoking power intelligent terminal business software according to claim 1, characterized in that, The method also includes hierarchical operation permissions and security sandbox control, wherein the security level is divided into four levels from L0 to L3, corresponding to autonomous execution, execution after recording, execution after manual confirmation, and execution after dual approval, respectively; the security level assessment result is used to constrain the call execution permission, and the system calls, access paths and resource operations involved in CLI calls are whitelisted and controlled through a process-level sandbox.

6. The method for dynamically invoking power intelligent terminal business software according to claim 1, characterized in that, CLI wrapper adaptation for existing terminals includes the following sub-processes: Identify the existing interfaces and reusable call paths of the original business modules; Construct a CLI wrapper corresponding to the existing interface; Inject the wrapper capability information into the capability registry; Establish a zero-intrusion external call entry point while keeping the original business code unchanged; Expand the coverage of the wrapper gradually according to the terminal capabilities to achieve incremental deployment.

7. The method for dynamically invoking power intelligent terminal business software according to claim 5, characterized in that, Call the CLI command for data reading to obtain the current state, compare the actual state with the expected state; if the goal is not achieved, regenerate the correct call sequence and execute it again; And record the entire call process in the audit log.

8. A dynamic invocation system for power intelligent terminal business software, characterized in that, include: The capability provision module is used to divide business function modules into atomic capability units. Each atomic capability unit is implemented as an independent process that can be called via the command line, using stdin or command line parameter input, stdout output, and a unified JSON data format. For existing terminals, an external call entry point is provided through a CLI wrapper without modifying the original code, and self-descriptive metadata is automatically generated. The self-describing metadata configuration module is used to perform self-describing metadata configuration, enabling each CLI command to implement the --schema parameter to return a capability description containing name, parameter format, output format, preconditions, postconditions, and security level, and the capability registry is maintained by the terminal. The decision-making agent calculation module is used to query the capability registry, select capability combinations according to business needs, verify compatibility and preconditions by reading the return results of the corresponding CLI command's --schema, and evaluate the security level of the capability combination. The calling module is used to decompose business tasks into sub-task sequences and map them into CLI calling sequences. The decision-making agent determines the strategic parameters. The CLI calling sequence is executed sequentially, and stdin / stdout data is passed between adjacent calls in a pipeline manner. The output results are checked after each call, and retry, rollback or alarm is triggered when an exception occurs.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the dynamic invocation method for power intelligent terminal business software as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the dynamic invocation method for power intelligent terminal business software as described in any one of claims 1 to 7.

Images