LLM command line generation tool and transplantation method based on OpenHarmony

Abstract

The invention provides an LLM command line generation tool based on OpenHarmony and a transplantation method, belongs to the technical field of industrial Internet of Things, and aims to solve the problems that a traditional TypeScript / Node. Js scheme has limitation, is insufficient in local reasoning performance, safety performance and reliability and is high in deployment cost. The tool comprises an ETS development environment module, a code migration module, a dependency library adaptation module, a security enhancement module certificate and a deployment and operation module, a zero-dependency transplantation scheme is designed for special environments of unpacked management tools such as OpenHarmony, the problem of strong coupling of a traditional Node.js application to the environment during operation is solved, and the safety of the Node. Js application is improved. And the deployment threshold of the heterogeneous system is further reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to an OpenHarmony-based LLM command line generation tool and a transplantation method, and belongs to the technical field of industrial Internet of Things. BACKGROUND

[0002] In the field of embedded systems and industrial Internet of Things, the development and deployment of command line tools (CLI) have long faced the following technical bottlenecks, especially in OpenHarmony, a highly customized operating system based on Linux. The current industry is transforming from a "general-purpose tool chain" to a deep optimization of a vertical ecosystem: hardware collaboration: using the NPU computing power of HH-SCDAYU200 chips to realize local large model inference (such as 4TOPS computing power supporting a 7B parameter model). Flexible deployment: through the atomized service architecture of OpenHarmony, the on-demand loading and dynamic resource allocation of CLI tools are realized. Deterministic response: based on the real-time task scheduling of ARKRuntime, the microsecond-level response of critical operations (such as emergency shutdown instructions) is ensured.

[0003] However, the traditional TypeScript / Node.js solution has the following limitations: 1. Runtime dependency is too heavy: the Node.js environment requires more than 100MB of storage space and depends on dynamic link libraries (such as glibc), making it difficult to deploy in resource-constrained industrial devices (such as HH-SCDAYU200 development boards). 2. Poor cross-architecture compatibility: Existing cross-compilation tools (such as pkg) generate binary files that only support general Linux instruction sets and cannot directly call OpenHarmony proprietary hardware functions (such as NPU acceleration and multi-machine hot standby). 3. Ecological fragmentation: Node.js modules (such as child_process) have no native interface compatibility with OpenHarmony atomized services (such as device status monitoring and distributed task scheduling), and a complex bridge layer needs to be developed. In the practice of natural language interaction, there are the following challenges: 1. Defects of online LLM tools in industrial scenarios: Existing solutions (such as ChatGPT integration) require continuous networking and cannot meet the offline needs of closed environments such as coal mines and tunnels, and there is a risk of data leakage. 2. Insufficient performance of local reasoning: When calling local large models in traditional TypeScript projects, the JavaScript engine (V8) has high memory usage and lacks hardware acceleration support, resulting in a response delay of more than 5 seconds. The security and reliability challenges of command-line tools are as follows: 1. Coarse-grained permission management: Node.js applications run by default with root privileges, which can easily trigger misoperations (such as rm -rf / *), while industrial devices need to comply with IEC 62443 standards, requiring process-level permission isolation. 2. Lack of fault recovery mechanism: Existing CLI tools have no built-in HA (high availability) module, and manual intervention is required after process crashes, making it difficult to meet the 99.99% availability requirement of industrial control systems. The efficiency bottlenecks of existing transplantation solutions are as follows: 1. Development-deployment link breakage: Traditional cross-compilation requires maintaining multiple sets of build configurations (x86_64 / ARMv7 / ARMv8), and debugging relies on physical device burning, with an iteration cycle of several hours. 2. Insufficient toolchain support: OpenHarmony does not provide an SDK adaptation package for Node.js, and developers need to manually transplant core modules such as file systems and networks, with a compatibility test coverage rate of less than 40%. SUMMARY

[0004] To solve the limitations of traditional TypeScript / Node.js solutions, local reasoning performance, security performance, and reliability are insufficient, and the deployment cost is high, the present application proposes an LLM command line generation tool based on OpenHarmony and a transplantation method.

[0005] The technical solution adopted by the present application to solve the above problems is: the LLM command line generation tool based on OpenHarmony proposed by the present application comprises: The ETS development environment module is used to build a development, debugging, compilation and deployment platform for the CLI tool. The code migration module is used to migrate the original TypeScript code to the ETS development environment module and adapt the native capabilities of the OpenHarmony operating system. The dependent library adaptation module is used to replace the Node.js module with the ETS development environment module after code migration, and optimize computationally intensive tasks. The security enhancement module is used to implement dynamic permission management and command sandbox verification. The deployment and operation module is used to support one-key industrial device cluster deployment and remote management.

[0006] Further, the ETS development environment module includes an OpenHarmony operating system configuration submodule and a distributed debugging tool submodule. The OpenHarmony operating system configuration submodule is used to configure the OpenHarmony operating system SDK and ETS plug-ins, and automatically generate build-profile.json configuration files and module.json5 configuration files during the configuration of the OpenHarmony operating system SDK. The distributed debugging tool submodule is used to support cross-device collaborative development.

[0007] Further, the code migration module includes a UI layer reconstruction submodule and a distributed capability injection submodule. The UI layer reconstruction submodule is used to migrate Web-style UI components to ArkUI declarative syntax in the ETS development environment module. The distributed capability injection submodule is used to integrate the collaborative interface of the OpenHarmony operating system.

[0008] Further, the dependent library adaptation module includes an integrated development environment submodule, a system interface replacement submodule, and an ARK compilation optimization unit. The integrated development environment submodule is used to convert ONNX models into NPU-specific formats. The system interface replacement submodule is used to replace Node.js file operation APIs with native APIs of the OpenHarmony operating system. The ARK compilation optimization unit is used to enable advanced optimization in the generated build-profile.json configuration file.

[0009] Further, the security enhancement module includes a permission dynamic management submodule and a command sandbox verification submodule. The permission dynamic management submodule is used for declaring a minimized permission set in the generated module.json5 configuration file and dynamically applying sensitive operation permissions. The command sandbox verification submodule is used for creating an isolated sandbox environment and performing simulation execution and resource occupation prediction on high-risk commands.

[0010] The transplantation method of the LLM command line generation tool based on OpenHarmony includes: Step 1: Build an ETS development environment based on an ETS development environment module, and configure an OpenHarmony SDK to support ETS project development, debugging, compilation and deployment; Step 2: Migrate the original TypeScript code to the built ETS development environment based on a code migration module, and adapt the ArkUI framework and the native capabilities of the OpenHarmony operating system; Step 3: Replace the Node.js file operation API with the native API of the OpenHarmony operating system based on a code dependency library adaptation module, optimize computationally intensive tasks, and use the Native API of ARK Runtime to accelerate AI inference; Step 4: Perform permission dynamic management and command sandbox verification based on a security enhancement module; Step 5: After completing the above configuration, perform one-key industrial device cluster deployment and remote management through a deployment and operation module, and generate a binary file through static compilation.

[0011] Further, step 1 specifically includes: The OpenHarmony operating system configuration submodule configures the OpenHarmony SDK, installs the ETS plug-in and sets the environment variable, and enables the distributed debugging tool submodule to support cross-device collaborative development.

[0012] Further, step 3 specifically includes: The integrated development environment submodule converts the ONNX model into a NPU special format and integrates it into ETS to realize accelerated inference; The system interface replacement submodule replaces the native API of the OpenHarmony operating system with the Node.js file operation API, and enables advanced optimization in build-profile.json based on the ARK compilation optimization unit, wherein the advanced optimization includes the maximum optimization level and link-time optimization.

[0013] The present application has the following advantages: 1. The present application solves the "secondary development" problem of cross-platform tool chains through deep coupling of the ETS language and the OpenHarmony SDK.

[0014] 2. The application realizes zero-trust security protection while improving the running speed by 3 times through the AOT compilation of ARK bytecode and the process sandbox mechanism.

[0015] 3. The application sinks the large model capability to the edge device, and promotes the large-scale landing of natural language interaction in the OT (operation technology) scene.

[0016] 4. The application designs a zero-dependence transplantation scheme for the special environment of OpenHarmony and other package management tools, solves the strong coupling problem of traditional Node.js applications to the runtime environment, and further reduces the deployment threshold of heterogeneous systems. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A structural diagram of an OpenHarmony-based LLM command line generation tool provided by the application is shown in the figure; Figure 2 A command line interactive UI component adaptation strategy diagram of a dependent library adaptation module provided by the application is shown in the figure. DETAILED DESCRIPTION

[0018] Specific implementation one: combined Figure 1 In this embodiment, the structure of the OpenHarmony-based LLM command line generation tool includes: An ETS development environment module, which is used to build a development, debugging, compiling and deployment platform for the CLI tool; The ETS development environment module includes an OpenHarmony operating system configuration submodule and a distributed debugging tool submodule; the OpenHarmony operating system configuration submodule is used to configure the OpenHarmony operating system SDK and the ETS plug-in, and automatically generates the build-profile.json configuration file and the module.json5 configuration file during the configuration of the OpenHarmony operating system SDK; the distributed debugging tool submodule is used to support cross-device collaborative development.

[0019] A code migration module, which is used to migrate the original TypeScript code to the ETS development environment module and adapt the native capability of the OpenHarmony operating system; The code migration module includes a UI layer reconstruction submodule and a distributed capability injection submodule; the UI layer reconstruction submodule is used to migrate the Web-style UI component to the ArkUI declarative syntax in the ETS development environment module; the distributed capability injection submodule is used to integrate the collaborative interface of the OpenHarmony operating system.

[0020] A dependent library adaptation module is configured to replace the Node.js module using the code-migrated ETS development environment module and optimize the computationally intensive tasks. The dependent library adaptation module includes an integrated development environment submodule, a system interface replacement submodule, and an ARK compilation optimization unit. The integrated development environment submodule is configured to convert the ONNX model into an NPU-specific format. The system interface replacement submodule is configured to replace the Node.js file operation API using the native API of the OpenHarmony operating system. The ARK compilation optimization unit is configured to enable advanced optimization in the generated build-profile.json configuration file.

[0021] A security enhancement module is configured to implement dynamic permission management and command sandbox verification. The security enhancement module includes a permission dynamic management submodule and a command sandbox verification submodule. The permission dynamic management submodule is configured to declare a minimum permission set in the generated module.json5 configuration file and dynamically apply for sensitive operation permissions. The command sandbox verification submodule is configured to create an isolated sandbox environment and perform simulated execution and resource occupation prediction on high-risk commands.

[0022] A deployment and operation module is configured to support one-key industrial device cluster deployment and remote management.

[0023] After the configuration of the LLM command line generation tool described above is completed, next, the present embodiment proposes a transplantation method of the LLM command line generation tool based on OpenHarmony, which specifically includes: S1. Development environment configuration; S101: Hardware requirements: Host machine: x86_64 architecture, Ubuntu 22.04 LTS, memory ≥ 16 GB, hard disk ≥ 100 GB Target device: OpenHarmony 4.1.2, HH-SCDAYU200 development board (ARMv8 architecture, NPU ≥ 4TOPS) S102: Software installation: Install DevEco Studio 4.1: (1) Download the Windows version of OpenHarmony IDE Visit HUAWEI DevEco Studio the official website and download the Windows version of DevEco Studio (note to select the OpenHarmony branch): (2) Install the IDE: Unzip the downloaded deveco-studio-4.1.2.100-windows.zip.

[0024] Run deveco-studio-4.1.2.100.exe and follow the wizard to complete the installation (the default path is C:\DevEcoStudio).

[0025] Start DevEco Studio and complete the initialization configuration (agree to the agreement, install the necessary components, etc.).

[0026] S102. Configure OpenHarmony SDK; (1) Install the SDK in the IDE: S10201. Open DevEco Studio and click the top menu Tools>SDK Manager.

[0027] S10202. In the SDK Manager interface, check the following components: OpenHarmony SDK: 4.1.2 (API Version 12) (latest stable version) and Previewer (previewer tool) ArkUI toolchain: ETS 3.2.6 (ArkTS development support) S10203. Click Apply and wait for the SDK to download.

[0028] The present application solves the "secondary development" problem of cross-platform toolchain through the deep coupling of ETS language and OpenHarmony SDK. (2) Configure environment variables S10301. Open system environment variables (right-click "This PC"> Properties> Advanced System Settings> Environment Variables).

[0029] S10302. Add the following variables: # OpenHarmony SDK path OHOS_SDK = C:\Users\<username>\AppData\Local\Huawei\Sdk\openharmony\4.1.2.100# Add toolchain to PATHPATH += %OHOS_SDK%\toolchains\llvm\bin S10303. Verify environment variables: # Open PowerShell or CMD echo %OHOS_SDK% S2. Code migration and refactoring As Figure 2 shown, including: UI layer migration (example: command input interface): Original TypeScript code (Web style) / / React-based input component class CommandInput extends React.Component {render() {return (<input type="text" id="cmdInput" placeholder=" Input natural language instructions " / >);}} ETS refactoring code (ArkUI declarative): @Entry@Componentstruct CommandInput {@State inputText: string = '' build() {Column() {TextInput({ placeholder: ' Input natural language instructions '}).width(' 90%').height(50).onChange((value: string) =>{this.inputText = value})}}} System interface replacement (example: file operation): Original Node.js code import fs from 'fs'; / / Read log files const logContent = fs.readFileSync (' / var / log / system.log', 'utf-8'); ETS adaptation code: import fs from '@ohos.fs'; / / Use OpenHarmony Native file APIlet fd = fs.openSync(' / var / log / system.log', 0o0); / / 0o0 Indicate read-only let logContent = fs.readSync(fd, { encoding: 'utf-8'});fs.closeSync(file.fd); S3. Dependency library adaptation strategy; During the application migration process, for several key NPM dependency packages used in the original system, this scheme uses native modules or recommended modes in the ETS environment for replacement and adaptation. The specific strategy is as follows: S301: Command line interactive UI component adaptation strategy: Original NPM dependency: @clack / core and prompts.

[0030] Function description: Provide a command line interface user interaction component.

[0031] ETS alternative: Use the ArkUI declarative UI framework provided by OpenHarmony, combined with the @ohos.promptAction module.

[0032] Adaptation description: Refactor the original command line interactive interface through ArkUI's TextInput, Button, and other basic UI components. Use @ohos.promptAction to implement various popup prompts and interaction functions to ensure smooth transition of user experience.

[0033] S302: HTTP client adaptation strategy: Original NPM dependency: axios.

[0034] Function description: Realize the function of HTTP network request.

[0035] ETS alternative: Use the @ohos.net.http native network request module provided by OpenHarmony.

[0036] Adaptation description: Call the httpRequest interface provided by the @ohos.net.http module to initiate various HTTP requests. Pay special attention to properly handling network security policies in the OpenHarmony environment during adaptation. For example, for special network environments such as industrial private networks, specific certificate verification and security configuration may be required.

[0037] S303: Subprocess management adaptation strategy: Original NPM dependency: execa.

[0038] Function description: Used to create and manage sub processes.

[0039] ETS alternative: Combine the use of the @ohos.process subprocess management module and the @ohos.worker multithreading module of OpenHarmony.

[0040] Adaptation description: Create and control the life cycle of sub processes through interfaces such as startProcess of the @ohos.process module. For tasks that need to be executed concurrently (such as executing multiple commands in parallel), utilize the @ohos.worker thread pool capabilities for scheduling and management to improve execution efficiency.

[0041] S304: Clipboard operation adaptation strategy: Original NPM dependency: clipboardy.

[0042] Function description: Provides the function of reading and writing system clipboard.

[0043] ETS alternative: Use the @ohos.pasteboard clipboard service module provided by OpenHarmony.

[0044] Adaptation description: Get the system clipboard instance by calling the createSystemPasteboard() method of the @ohos.pasteboard module, and then realize the reading and writing operations of the clipboard content. This adaptation needs to declare the ohos.permission.WRITE_PASTEBOARD permission in the application's configuration file.

[0045] S305: Multi-line string formatting adaptation strategy: Original NPM dependency: dedent.

[0046] Function description: Used for processing and formatting multi-line strings, usually removing unnecessary leading indentation.

[0047] ETS alternative: Directly use the built-in template string (backtick `) feature of ETS language, or implement a lightweight custom formatting utility function.

[0048] Adaptation description: For simple multi-line strings, ETS's template strings can meet the needs. If precise control of indentation is required, auxiliary functions such as trimLeadingWhitespace can be written to replace the original dedent library functions.

[0049] S306: INI file parsing adaptation strategy: Original NPM dependency: ini.

[0050] Function description: Used for parsing and processing.ini format configuration files.

[0051] ETS alternative: Consider using the relevant tools in @ohos.util provided by OpenHarmony, or customize the parsing logic.

[0052] Adaptation description: OpenHarmony environment recommends using JSON or YAML as the configuration file format. Therefore, when adapting this dependency, priority is given to refactoring the original INI configuration file into JSON or YAML format and using the corresponding parsing library. If compatibility with INI is necessary, modifications can be made based on the XML parsing capabilities in @ohos.util (if applicable), or a specific INI file parsing function can be written.

[0053] S307: OpenAI API call adaptation strategy: Original NPM dependency: openai.

[0054] Function description: Used for interacting with various large language model APIs provided by OpenAI.

[0055] ETS alternative: Switch to using a large language model deployed locally, which has been quantized, and combine it with the @ohos.ai module of OpenHarmony for NPU hardware-accelerated inference.

[0056] Adaptation Description: The core strategy is to convert the dependence on cloud OpenAI API to a call to the device's local AI capabilities. This includes selecting or training a quantized large model suitable for edge devices (such as the 7B parameter model mentioned in the figure), and loading the model through the loadModel interface of the @ohos.ai module, using the NPU of the device (such as RK3588) for hardware acceleration, achieving offline natural language processing and command generation, meeting the requirements of real-time and data privacy in industrial scenarios.

[0057] S308: Token Counting Adaptation Strategy: Original NPM dependency: @dqbd / tiktoken.

[0058] Function Description: Used to calculate the number of Tokens corresponding to the text, commonly used for text preprocessing before interacting with large language models.

[0059] ETS Alternative: Use the tokenization function provided by the @ohos.nlp (Natural Language Processing) module built into OpenHarmony.

[0060] Adaptation Description: Use the tokenize (or other similar) interface of the @ohos.nlp module to perform tokenization on the text, and perform Token counting or similar text analysis based on the tokenization results, thereby avoiding the introduction of external Token counting dependencies.

[0061] S309: Terminal Color Rendering Adaptation Strategy: Original NPM dependency: kolorist.

[0062] Function Description: Used to output colored text in the command line terminal.

[0063] ETS Alternative: Use the @ohos.console module provided by OpenHarmony and directly use ANSI escape codes.

[0064] Adaptation Description: Use the console.log() output function to embed standard ANSI escape sequences (for example, \x1b[32mSuccess\x1b[0m is used to output green text and then restore the default color) to achieve color rendering of terminal text. To improve code maintainability, commonly used color escape codes can be encapsulated into utility classes or constants.

[0065] S3010: Internationalization Support Adaptation Strategy: Original NPM dependency: i18next.

[0066] Function Description: Provides multi-language internationalization (i18n) support for applications.

[0067] ETS alternative: Use the @ohos.i18n native internationalization module provided by OpenHarmony.

[0068] Adaptation instructions: Follow the internationalization specifications of OpenHarmony, and place resource files in different languages (usually in JSON format) in the corresponding subdirectories under the / resources directory of the application project. In the code, call the interfaces provided by the @ohos.i18n module (such as i18n.getDisplayCountry() or the method for obtaining string resources) to realize the loading and display of multi-language text.

[0069] Missing module processing solution: If the third-party library has no corresponding OHOS implementation, the following methods can be used: 1. Native API encapsulation uses C++ to write core logic, and generates ETS bindings through NAPI: / / native_code.cpp#include<napi / n_api.h>napi_value EncryptCommand (napi_env env, napi_callback_info info) { / / Implement encryption logic return nullptr;} / / encrypt.ets import native from 'libencrypt.so'; const encrypted = native.encryptCommand("rm -rf / tmp / *"); 2. Lightweight Polyfill implements alternative versions for commonly used utility functions: / / polyfills / string-utils.etsexport function padStart(str: string, targetLength: number, padChar: string): string { if (str.length>= targetLength) return str ; return padChar.repeat(targetLength - str.length) + str ; } S4: Security enhancement implementation; Dynamic permission application: S401: Declare permissions: Define the required permissions in module.json5 : { "module": { "requestPermissions": { "name": "ohos.permission.ACCESS_FILE","reason": " Read system logs "," usedScene": {"ability": ["CommandExecutor"],"when": "always"}}]}} S402: Runtime check code and comments as follows: import abilityAccessCtrl from '@ohos.abilityAccessCtrl';const requestPermissions = async () =>{const atManager = abilityAccessCtrl.create AtManager();try {await atManager.requestPermissionsFromUser([' ohos.permission.ACCESS_FILE']);} catch (err) {console.error(" Permission application failure: ", err.code);}}; Command sandbox execution: import resourceMonitor from '@ohos.resourceschedule';const executeSafely = async (command: string) => / / Create isolated environment const sandbox = resourceMonitor.createSandbox({cpuQuota: 30, / / Maximum occupancy 30% CPUmemoryMB: 512 / / Memory limit 512MB}); / / 模拟执行并监控资源const result = await sandbox.simulateExecute(command);if (result.exitCode!== 0 || result.cpuPeak>80){throw new Error(" Command execution risk is too high ");} / / Actual execution return sandbox.realExecute(command);} ; The application realizes zero-trust security protection while improving the running speed by 3 times by means of AOT compilation of ARK bytecode and process sandbox mechanism. Finally, the application designs a zero-dependence transplantation scheme for the special environment of OpenHarmony and other package management tools, solves the strong coupling problem of traditional Node.js applications to the runtime environment, and further reduces the deployment threshold of heterogeneous systems.

[0070] The above is only a preferred embodiment of the present application, and does not limit the present application in any form. Although the present application has been disclosed as above, it is not intended to limit the present application. Any person skilled in the art can make some changes or modifications to the above disclosed technical content without departing from the scope of the technical solution of the present application, and any simple modification, equivalent replacement and improvement of the above embodiments within the scope of the technical solution of the present application, according to the technical essence of the present application, within the spirit and principles of the present application, are all within the protection scope of the present application.

Claims

1. An LLM command-line generation tool based on OpenHarmony, characterized in that, include: The ETS development environment module is used to build a platform for the development, debugging, compilation, and deployment of CLI tools. The code migration module is used to migrate the original TypeScript code to the ETS development environment module and adapt it to the native capabilities of the OpenHarmony operating system. The dependency library adaptation module is used to replace the Node.js module with the ETS development environment module after code migration and to optimize computationally intensive tasks; The security enhancement module is used to implement dynamic access control and command sandbox verification; The deployment and maintenance module supports one-click deployment and remote management of industrial equipment clusters.

2. The LLM command-line generation tool based on OpenHarmony according to claim 1, characterized in that, The ETS development environment module includes an OpenHarmony operating system configuration submodule and a distributed debugging tool submodule; The OpenHarmony operating system configuration submodule is used to configure the OpenHarmony operating system SDK and ETS plugin, and automatically generates the build-profile.json and module.json5 configuration files during the OpenHarmony operating system SDK configuration process; The distributed debugging tool submodule is used to support cross-device collaborative development.

3. The LLM command-line generation tool based on OpenHarmony according to claim 1, characterized in that, The code migration module includes a UI layer refactoring submodule and a distributed capability injection submodule; The UI layer reconstruction submodule is used to migrate Web-style UI components to the ArkUI declarative syntax in the ETS development environment module; The distributed capability injection submodule is used to integrate the collaborative interface of the OpenHarmony operating system.

4. The LLM command-line generation tool based on OpenHarmony according to claim 1, characterized in that, The dependency library adaptation module includes an integrated development environment submodule, a system interface replacement submodule, and an ARK compilation optimization unit; The integrated development environment submodule is used to convert the ONNX model into the NPU-specific format; The system interface replacement submodule is used to replace the Node.js file operation API with the native API of the OpenHarmony operating system; The ARK compilation optimization unit is used to enable advanced optimizations in the generated build-profile.json configuration file.

5. The LLM command-line generation tool based on OpenHarmony according to claim 1, characterized in that, The security enhancement module includes a dynamic access control submodule and a command sandbox verification submodule; The dynamic permission management submodule is used to declare a minimized permission set and dynamically request sensitive operation permissions in the generated module.json5 configuration file; The command sandbox verification submodule is used to create an isolated sandbox environment and simulate the execution of high-risk commands and predict resource consumption.

6. A method for porting an OpenHarmony-based LLM command-line generation tool, applied to the OpenHarmony-based LLM command-line generation tool as described in any one of claims 1-5, characterized in that, include: Step 1: Build the ETS development environment based on the ETS development environment module and configure the OpenHarmony SDK to support ETS project development, debugging, compilation and deployment; Step 2: Based on the code migration module, migrate the original TypeScript code to the built ETS development environment and adapt it to the native capabilities of the ArkUI framework and the OpenHarmony operating system; Step 3: Based on the code dependency library adaptation module, replace the Node.js file operation API with the native API of the OpenHarmony operating system to optimize computationally intensive tasks, and use the ARK Runtime's native API to accelerate AI inference; Step 4: Perform dynamic permission control and command sandbox verification based on the security enhancement module; Step 5: After completing the above configuration, perform one-click deployment and remote management of industrial equipment clusters through the deployment and maintenance module, and generate binary files through static compilation.

7. The method for porting the OpenHarmony-based LLM command-line generation tool according to claim 6, characterized in that, Step 1 specifically includes: Configure the OpenHarmony SDK based on the OpenHarmony operating system configuration submodule, install the ETS plugin and set environment variables, and enable the distributed debugging tool submodule to support cross-device collaborative development.

8. The method for porting the OpenHarmony-based LLM command-line generation tool according to claim 6, characterized in that, Step 3 specifically includes: Based on the integrated development environment submodule, the ONNX model is converted into the NPU-specific format and integrated into ETS to accelerate inference; The system interface replacement submodule replaces the Node.js file operation API with the native API of the OpenHarmony operating system, and enables advanced optimizations in build-profile.json based on the ARK compilation optimization unit. These advanced optimizations include the maximum optimization level and link-time optimizations.

Images