Adaptation and tailoring method and system based on power terminal device honmos operating system

Abstract

The application discloses an adaptation and cutting method and system based on a power terminal device Hongmeng operating system, which comprises the following steps: firstly, the function demand and performance requirement of the power terminal device are adapted with the Hongmeng operating system type and the chip type; secondly, the system service adaptation is realized by sequentially starting the service management hub, the device event listener and the application hatcher process through the initialization script; then, the hardware nodes that need to be cut are removed based on the layered cutting strategy, the Hongmeng operating system can be customized for the function cutting according to different power application scenarios; then, the driving adaptation is carried out to ensure that the power terminal device can stably and efficiently run under the selected Hongmeng operating system; finally, the old application transplantation and the new application deployment on the power terminal device are realized; the method can realize the efficient running and the function customization of the power terminal device under the Hongmeng operating system, and greatly improves the overall performance and reliability of the power Internet of Things system.

Description

Technical Field

[0001] This invention relates to the field of power Internet of Things (IoT) technology, and in particular, to a method and system for adapting and tailoring a power terminal device to the HarmonyOS operating system, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Currently, power edge terminal equipment is diverse, mainly divided into concentrators and converged terminals. The chip platforms used include over ten main control chip models from multiple chip manufacturers, such as Rockchip RK3358J, Allwinner T3 / T3-C, SemiDrive D9342 / D9341, Zhixin SCM801, and Wango 8130L. These different chips differ in memory, processor architecture, and other aspects, resulting in inconsistent functionality and performance among power terminal equipment. Due to the diversity of chips in power terminal equipment and the varying hardware requirements of different types of HarmonyOS, existing power terminal equipment is difficult to directly adapt to the HarmonyOS operating system, leading to compatibility issues. Furthermore, different power application scenarios have different functional requirements for power terminal equipment. Without proper adaptation of the operating system, system resources may be wasted or functionality may be insufficient, severely impacting the performance of power terminal equipment and the overall operating efficiency of the power system. Therefore, there is an urgent need for an adaptation and customization method that can solve the difficulties in adapting existing power terminal equipment to the HarmonyOS operating system and address functional redundancy or insufficiency. Summary of the Invention

[0003] This invention provides a method and system for adapting and customizing the HarmonyOS operating system for power terminal devices, as well as an electronic device and a computer-readable storage medium. It enables the efficient operation and functional customization of power terminal devices under the HarmonyOS operating system, greatly improving the overall performance and reliability of the power Internet of Things system.

[0004] According to one aspect of the present invention, a method for adapting and tailoring a device to the HarmonyOS operating system for power terminal equipment is provided, comprising the following:

[0005] Select the appropriate HarmonyOS based on the functional requirements and performance requirements of the power terminal equipment, select the appropriate target chip based on the selected HarmonyOS, and map the kernel of the selected HarmonyOS and the HDF hardware unified driver framework to the target chip to build and adapt the hardware layer.

[0006] The kernel of the HarmonyOS operating system in the target chip is started based on the hardware layer, the initialization script is configured and started, the initialization process is generated, and the service management hub, device event listener and application incubator process are started in sequence through the initialization process to build the system service layer.

[0007] Based on the application scenarios of power terminal equipment, the core functions of power terminal equipment are mapped to the hardware nodes corresponding to the selected HarmonyOS operating system using the system service layer, and the hardware nodes that need to be cut are removed based on the layered cutting strategy to obtain the cut system structure.

[0008] Driver adaptation is performed based on the trimmed system architecture and the HDF hardware unified driver framework to obtain the driver adaptation result.

[0009] The application operating environment of power terminal equipment is transplanted to enable the deployment and migration of applications on power terminal equipment.

[0010] Furthermore, the process of mapping the selected HarmonyOS kernel and HDF hardware unified driver framework to the target chip includes the following:

[0011] Confirm whether the CPU architecture of the target chip is within the support range of the selected HarmonyOS. If it is within the support range, create a corresponding architecture subdirectory in the kernel source code directory and implement the core modules of startup code, interrupt handling, and process scheduling. Otherwise, develop an adapted basic architecture.

[0012] Customize the hardware abstraction layer according to the characteristics of the target chip, define the address and interrupt number of the power terminal peripheral in the device tree and perform physical address mapping, configure the clock tree to implement the clock operation interface, and encapsulate the control interface and allocate data transmission buffer for the hardware acceleration module in the hardware abstraction layer.

[0013] Modify the kernel code to ensure that the kernel can be compiled and run correctly on the target chip;

[0014] Write power terminal peripheral drivers that conform to the HDF hardware unified driver framework specification;

[0015] Hardware parameters are defined through hardware configuration source files, and the consistency between the device tree and the parameters in the hardware configuration source files is ensured. The driver loading order is then configured in the manager of the HDF hardware unified driver framework.

[0016] Modify the system build configuration to add a driver module and generate a system image. After burning the image to the target chip, verify the driver function and the effectiveness of power data transmission.

[0017] Furthermore, after constructing the system service layer, the following content is also included:

[0018] Perform graphical driver adaptation.

[0019] Furthermore, the process of performing graphical driver adaptation includes the following:

[0020] At the hardware layer, the graphics processor model is identified through the device tree, the compatibility identifier and register address range of the graphics processor are defined in the device tree, the hardware abstraction layer library provided by the graphics processor manufacturer is integrated into the system's specified path, the driver module information of the graphics processor is registered through the configuration file, test cases are run using the preset graphics interface test tool, the driver status of the graphics processor is judged based on the frame rate stability, the display controller parameters are configured in the device tree, and the kernel display driver is modified to support frame buffer operations.

[0021] At the framework layer, the graphics synthesizer type is selected and the number of buffers is set through the system configuration file. The input device information of the power terminal equipment is registered in the input management configuration. The touch coordinate calibration tool is used to perform touch coordinate calibration and verify the accuracy of the data.

[0022] At the application layer, a user interface framework is integrated according to the needs of power applications. If the HarmonyOS native interface framework is used, the page layout is defined through declarative syntax and responsive design is used. If a third-party framework is used, the framework display driver is initialized and basic controls are built.

[0023] Furthermore, the layered pruning strategy includes removing pre-installed applications unrelated to power services in the application layer, pruning subsystems unrelated to power interruption functions in the framework layer, and removing unnecessary file system functions in the kernel layer.

[0024] Furthermore, the process of driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework includes the following:

[0025] Bind the driver service interface of the power terminal equipment peripheral to the HDF hardware unified driver framework, define the driver initialization interface and resource release interface, and call the driver entry registration macro to register the driver entry into the HDF hardware unified driver framework.

[0026] Write driver compilation scripts according to the type of operating system running on the target chip;

[0027] Declare the hardware parameters of the power terminal equipment peripherals in the device description file.

[0028] Furthermore, the process of transplanting the application operating environment of the power terminal equipment includes the following:

[0029] In the cross-compilation service configuration, specify the absolute path of the compilation toolchain, set the directory addresses of the standard libraries and header files required by the target chip, and configure the compiler path;

[0030] Obtain the container compilation image of the selected HarmonyOS operating system, start the container environment and download the dependent components required for compiling HarmonyOS, enable the dependent functions required for container operation by modifying the kernel configuration, and add the directory and file permission configurations required for container operation in the file system.

[0031] The compiled system image is burned to the power terminal device, the static executable file of the container is deployed to the system path, and the storage driver parameters of the container are adjusted to adapt to the storage device characteristics of the power terminal device, thus completing the porting of the application runtime environment of the power terminal device.

[0032] In addition, the present invention also provides an adaptation and customization system based on the HarmonyOS operating system for power terminal equipment, comprising:

[0033] The hardware platform adaptation module is used to select the HarmonyOS operating system to be adapted according to the functional requirements and performance requirements of the power terminal equipment, select the target chip to be adapted according to the selected HarmonyOS operating system, and map the kernel of the selected HarmonyOS operating system and HDF hardware unified driver framework to the target chip to build and adapt the hardware layer.

[0034] The system service adaptation module is used to start the kernel of the HarmonyOS operating system in the target chip based on the hardware layer, configure and start the initialization script, generate the initialization process, and start the service management hub, device event listener and application incubator process in sequence through the initialization process to build the system service layer.

[0035] The function trimming module is used to map the core functions of the power terminal equipment to the hardware nodes corresponding to the selected HarmonyOS operating system based on the application scenario of the power terminal equipment, and remove the hardware nodes to be trimmed based on the layered trimming strategy to obtain the trimmed system structure.

[0036] The driver adaptation module is used to perform driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework to obtain the driver adaptation result.

[0037] The application adaptation module is used to port the application operating environment of power terminal equipment to enable the deployment and migration of applications on power terminal equipment.

[0038] In addition, the present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the steps of the method described above by calling the computer program stored in the memory.

[0039] In addition, the present invention also provides a computer-readable storage medium for storing a computer program adapted and tailored to the HarmonyOS operating system of power terminal equipment, wherein the computer program executes the steps of the method described above when running on a computer.

[0040] The present invention has the following beneficial effects:

[0041] The present invention provides a method for adapting and tailoring the HarmonyOS operating system for power terminal devices. First, it adapts the functional and performance requirements of the power terminal device to the HarmonyOS type and chip type to build and adapt the hardware layer. Then, it sequentially starts the service management hub, device event listener, and application incubator processes through initialization scripts to build the system service layer, thereby achieving system service adaptation. Next, it maps the core functions of the power terminal device to the hardware nodes corresponding to the selected HarmonyOS based on the application scenario, and removes the hardware nodes that need to be tailored based on a layered tailoring strategy. This allows for customized functional tailoring of the HarmonyOS according to different power application scenarios, reducing system resource waste and achieving functional customization. Then, it performs driver adaptation based on the tailored system structure and the HDF hardware unified driver framework to ensure stable and efficient operation of the power terminal device under the selected HarmonyOS. Finally, it migrates the application runtime environment of the power terminal device to achieve the migration of old applications and the deployment of new applications. This method enables efficient operation and functional customization of power terminal devices under the HarmonyOS, greatly improving the overall performance and reliability of the power Internet of Things system.

[0042] In addition, the adaptation and customization system based on the HarmonyOS operating system for power terminal equipment of the present invention also has the above-mentioned advantages.

[0043] In addition to the objectives, features, and advantages described above, the present invention has other objectives, features, and advantages. The invention will now be described in further detail with reference to the figures. Attached Figure Description

[0044] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings:

[0045] Figure 1 This is a flowchart illustrating the adaptation and customization method for the HarmonyOS operating system of power terminal equipment according to a preferred embodiment of this application.

[0046] Figure 2 yes Figure 1 A schematic diagram of the sub-process of step S1;

[0047] Figure 3 yes Figure 1 A schematic diagram of the sub-process of step S4;

[0048] Figure 4 yes Figure 1 A schematic diagram of the sub-process of step S5;

[0049] Figure 5 This is a schematic diagram of the module structure of an adaptation and customization system based on the HarmonyOS operating system for power terminal equipment, according to another embodiment of this application. Detailed Implementation

[0050] 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.

[0051] Reference Figure 1 A preferred embodiment of this application provides a method for adapting and tailoring a device to the HarmonyOS operating system for power terminal equipment, including the following:

[0052] Step S1: Select the appropriate HarmonyOS operating system based on the functional and performance requirements of the power terminal equipment, select the appropriate target chip based on the selected HarmonyOS operating system, and map the kernel of the selected HarmonyOS operating system and HDF hardware unified driver framework to the target chip to build and adapt the hardware layer.

[0053] Step S2: Start the kernel of the HarmonyOS operating system in the target chip based on the hardware layer, configure and start the initialization script, generate the initialization process, and start the service management hub, device event listener and application incubator process in sequence through the initialization process to build the system service layer;

[0054] Step S3: Based on the application scenario of the power terminal equipment, the core functions of the power terminal equipment are mapped to the hardware nodes corresponding to the selected HarmonyOS operating system using the system service layer, and the hardware nodes that need to be cut are removed based on the layered cutting strategy to obtain the cut system structure.

[0055] Step S4: Perform driver adaptation based on the trimmed system structure and HDF hardware unified driver framework to obtain the driver adaptation result;

[0056] Step S5: Transplant the application operating environment of the power terminal equipment to realize the deployment and migration of applications on the power terminal equipment.

[0057] It is understood that the adaptation and customization method for the HarmonyOS operating system on power terminal devices in this embodiment first adapts the functional and performance requirements of the power terminal devices to the HarmonyOS type and chip type to build and adapt the hardware layer. Then, the service management hub, device event listener, and application incubator processes are started sequentially through initialization scripts to build the system service layer, thereby achieving system service adaptation. Next, the core functions of the power terminal devices are mapped to the hardware nodes corresponding to the selected HarmonyOS based on the application scenarios of the power terminal devices, and the hardware nodes that need to be customized are removed based on the layered customization strategy. Customized functional customization of the HarmonyOS can be performed according to different power application scenarios, which not only reduces the waste of system resources but also achieves functional customization. Then, driver adaptation is performed based on the customized system structure and HDF hardware unified driver framework to ensure that the power terminal devices run stably and efficiently under the selected HarmonyOS. Finally, the application runtime environment of the power terminal devices is ported to realize the porting of old applications and the deployment of new applications on the power terminal devices. This method can achieve efficient operation and functional customization of power terminal devices under the HarmonyOS, greatly improving the overall performance and reliability of the power Internet of Things system.

[0058] HarmonyOS typically comprises three system sizes: lightweight system and lightweight system. L 0. Small system L 1 and standard system L 2, of which, lightweight system L It supports a minimum memory of 128KB and multiple lightweight network protocols, lightweight image frames, and IoT bus read / write components, making it suitable for some smart sensors and widely used in the nerve endings of the power grid; small systems. L 1. Supports a minimum memory of 1MB, while providing high security capabilities, a standard graphics framework, and multimedia encoding and decoding functions, suitable for various intelligent converged terminals, and widely used in "transmission, transformation, distribution, and application"; while standard systems L 2. It supports a minimum memory of 128MB, while possessing strong interactive capabilities and supporting hardware synthesis and animation effects, making it suitable for edge computing scenarios such as smart meters and power terminals. Therefore, in step S1, it is necessary to select a suitable HarmonyOS operating system based on the functional and performance requirements of the power terminal equipment, and then select a suitable target chip based on the selected HarmonyOS operating system. For example, for resource-constrained and functionally simple power terminal equipment, such as some small power sensors, a lightweight system-supporting chip should be selected. L For the target chip of 0, a chip that supports small systems will be selected for various intelligent converged terminals. L The target chip is 1, while for edge computing scenarios, a standard system that supports it is selected. L2. Target Chip. In addition, after adapting the functional and performance requirements of the power terminal equipment to the HarmonyOS operating system type and chip type, the Git tool is used to pull the selected HarmonyOS base code repository from the official HarmonyOS repository or mirror site, download the system's dependent components, and complete the compilation environment setup. A JSON configuration file for the target chip is created or modified in the product configuration directory to explicitly define hardware parameters such as chip model, processor architecture, memory mapping, clock configuration, and peripheral driver interfaces. The kernel of the selected HarmonyOS and the HDF hardware unified driver framework are then mapped to the target chip to build and adapt the hardware layer.

[0059] Among them, such as Figure 2 As shown, the process of mapping the selected HarmonyOS kernel and HDF hardware unified driver framework to the target chip includes the following:

[0060] Step S11: Confirm whether the CPU architecture of the target chip is within the support range of the selected HarmonyOS. If it is within the support range, create a corresponding architecture subdirectory in the kernel source code directory and implement the core modules of startup code, interrupt handling, and process scheduling. Otherwise, develop an adapted basic architecture.

[0061] Step S12: Customize the hardware abstraction layer according to the characteristics of the target chip, define the address and interrupt number of the power terminal peripheral in the device tree and perform physical address mapping, configure the clock tree to implement the clock operation interface, and encapsulate the control interface of the hardware acceleration module in the hardware abstraction layer and allocate the data transmission buffer.

[0062] Step S13: Modify the kernel code to ensure that the kernel can be compiled and run normally on the target chip;

[0063] Step S14: Write a power terminal peripheral driver program that conforms to the HDF hardware unified driver framework specification;

[0064] Step S15: Define hardware parameters through the hardware configuration source file, and coordinate the consistency between the device tree and the hardware configuration source file parameters to configure the driver loading order in the manager of the HDF hardware unified driver framework.

[0065] Step S16: Modify the system build configuration to add the driver module and generate the system image. After burning it to the target chip, verify the effectiveness of the driver function and power data transmission.

[0066] Specifically, first confirm whether the target chip's CPU architecture is within the supported range of the selected HarmonyOS operating system. If it is, create a corresponding architecture subdirectory in the kernel source code directory and implement the boot code, interrupt handling, and process scheduling core modules. If it is not within the supported range, develop an adapted basic architecture. Additionally, when adapting to the Linux kernel, it is also necessary to integrate the kernel patches provided by the chip manufacturer and verify the kernel compilation effectiveness.

[0067] Then, a hardware abstraction layer is customized according to the characteristics of the target chip. The addresses and interrupt numbers of the power terminal peripherals are defined in the device tree and physical address mapping is performed. The clock tree is configured to implement the clock operation interface. The control interface of the hardware acceleration module is encapsulated in the hardware abstraction layer and a data transmission buffer is allocated.

[0068] Next, the kernel code is modified to ensure that the kernel can be compiled and run correctly on the target chip. For example, based on patches provided by the target chip manufacturer or through self-development, the initialization code of core modules closely related to the chip architecture, such as timer, interrupt controller (GIC), and clock controller drivers, is implemented or modified in the kernel. In the corresponding architecture subdirectory under the arch / directory, hardware platform initialization files (such as platform.c) are added or modified, hardware resources defined in the device tree are called to complete the early setup of the platform, and code segments or API calls in the kernel that are incompatible with the target chip are modified to ensure that the kernel can be compiled and run correctly on the target chip.

[0069] Then, write peripheral drivers for power terminal devices that conform to the HDF hardware unified driver framework specification. For example, define a driver entry structure of type HDF Driver Entry and complete its registration. Operate hardware registers and expose user-mode access interfaces in the driver initialization function. Use the work queue mechanism of the HDF hardware unified driver framework to handle asynchronous events for complex peripherals.

[0070] Hardware parameters are then defined through the hardware configuration source file (i.e., HCS file) to achieve dynamic driver loading and ensure consistency between the device tree and the hardware configuration source file parameters. The driver loading order is then configured in the manager of the HDF hardware unified driver framework.

[0071] Finally, modify the system build configuration to add a driver module and generate a system image. After burning the image to the target chip, verify the driver function and the effectiveness of power data transmission.

[0072] It's understandable that existing Linux systems, when adapting to touchscreen driver chips for power terminal equipment, typically add touchscreen node information, including I2C address, interrupt pins, and reset pins, to the board-level device tree file when modifying the device tree. This configuration information is scattered across the device tree, kernel configuration, and driver source code, lacking a unified standard. Regarding driver writing or configuration, if a driver for the chip already exists in the kernel, it needs to be compiled into the kernel. If the driver is not in the kernel, it needs to be written separately, such as defining an `i2c_driver` structure, implementing callback functions like `probe`, `remove`, `suspend`, and `resume`, and registering an input device with the input subsystem. This may result in the driver failing to compile directly on different Linux versions, requiring modifications to adapt to new kernel APIs. Furthermore, directly modifying the kernel source code leads to a huge and difficult workload for later maintenance. In terms of compilation and deployment, the kernel needs to be recompiled or the driver compiled as a module before being updated to the device. When the hardware is ported to another chip platform, the kernel needs to be modified or recompiled as a module, resulting in poor reusability. Unlike traditional Linux systems that require calling specific functions of the Linux kernel (such as register_chrdev and request_irq) to interact with the system kernel, the HDF unified hardware driver framework of this application only needs to call standardized APIs (such as driver registration, resource management, and terminal processing), without calling specific functions in the system kernel. This enables loosely coupled interaction between the driver framework and the system kernel, avoiding the problem of poor reusability caused by strong coupling when deployed to different devices or chip platforms. At the same time, a unified hardware configuration file is written based on a unified standard for configuration information, and all hardware configuration information is centrally defined in the HCS file (i.e., the hardware configuration source file), achieving complete separation of configuration and code. In addition, in terms of adaptability and portability, this application only needs to modify the corresponding HCS configuration file to update parameters such as GPIO pins and I2C bus numbers, without changing the main driver code, which greatly improves reusability.

[0073] In addition, after mapping the selected HarmonyOS kernel and HDF hardware unified driver framework to the target chip, kernel-mode or user-mode drivers need to be developed based on the HDF hardware unified driver framework. Adaptation is required to meet the diverse peripheral needs of power terminal equipment, covering standard interface protocols such as GPIO, I2C, SPI, and UART, as well as complex peripheral protocols such as USB, Bluetooth / Wi-Fi. Hardware parameters are described using a declarative syntax through HCS files, achieving decoupling between hardware configuration and driver code. During system startup, the HDF hardware unified driver framework dynamically parses the HCS file, automatically allocates memory, interrupts, and other resources according to the configuration, and binds the corresponding driver modules. For example, the same I2C driver can be adapted to I2C controllers of different chips by modifying the register addresses and interrupt number parameters in the HCS, achieving multi-platform reuse without modifying the driver code.

[0074] Optionally, the HCS file not only defines hardware resource attributes but also supports dynamic loading of device configurations. For example, user-space drivers can configure permission isolation and resource access rules through a separate HCS file, and combine this with a hot-plug mechanism to achieve dynamic loading of USB or Bluetooth modules. When a device is plugged in, the HDF framework detects the hardware event and triggers an HCS configuration update, dynamically loading the corresponding driver and allocating resources. This design allows drivers to flexibly respond to hardware changes, while the centralized management of configuration files simplifies the multi-platform adaptation process.

[0075] In addition, in step S2, after the HarmonyOS kernel in the target chip is started based on the hardware layer, a temporary root file system containing the minimum file structure is loaded. This temporary root file system is embedded in the kernel image via initramfs or initrd mechanisms, or its storage location is specified by the device tree. Next, a root directory switching operation is performed to switch the system root directory to the target root file system adapted to the terminal storage characteristics of power equipment. This is specifically implemented through the mount_root() function, and finally, the switch_root command is used to switch the root directory context. Then, an initialization script is configured and started, generating an initialization process. This initialization process starts key services and defines the service dependency order according to the configuration script. After parsing the script, the service management hub, device event listener, and application incubator process are started sequentially. Simultaneously, the system program directory is monitored to dynamically load newly added power services, thereby achieving system service adaptation. The device event listener is responsible for listening to uevent events sent by the kernel through the netlink socket, triggering the HDF framework to dynamically load the driver. The application incubator process is responsible for receiving application startup requests from the Ability Manager, parsing the application description file, creating a sandbox environment according to the permission configuration, and generating a child process through the clone() system call. The service management hub is responsible for maintaining the service registry. When a service starts, it registers with the service management hub through the SAMGR_RegisterService interface, and other modules call it as needed through SAMGR_GetService.

[0076] Furthermore, in step S3, based on the application scenario corresponding to the power terminal equipment, the core functions of the power terminal equipment are mapped to the hardware nodes corresponding to the selected HarmonyOS operating system using the system service layer. Hardware nodes requiring pruning are then removed based on a layered pruning strategy, resulting in the pruned system structure. The pruning of the HarmonyOS operating system revolves around three core objectives: resource minimization, functional focus, and security hardening. Modules are streamlined to address the hardware constraints of the power terminal equipment, while ensuring the integrity of the security subsystem. The pruning process follows three principles: layered pruning, a combination of static and dynamic analysis, and configurability. Dependencies are analyzed level by level from the application layer to the kernel layer, combining static code analysis and runtime dynamic tracing. Dynamic loading and unloading of modules are achieved through compilation macros and HCS configuration files.

[0077] Specifically, the process begins with requirements analysis and module dependency mapping. The core functions of the power terminal equipment are mapped to the corresponding modules of the selected HarmonyOS operating system, generating a module dependency graph. For example, data acquisition is associated with the Sensor Framework and I2C / SPI drivers, while encrypted communication depends on the TEE OS, TLS protocol stack, and hardware encryption drivers. Then, the module call graph is generated using the module analysis tool ohos-build, identifying strong and weak dependencies to provide a basis for formulating a tailoring strategy.

[0078] Next, a layered pruning strategy is formulated. This strategy includes removing pre-installed applications unrelated to power services from the application layer, pruning subsystems unrelated to power interruption functions from the framework layer, and removing unnecessary file system functions from the kernel layer. For example, the application layer removes unrelated pre-installed applications such as Settings and Camera, retaining basic services; the framework layer prunes distributed scheduling and AI subsystems, retaining power management; and the kernel layer removes procfs and debugfs from VFS, retaining JFFS2 or LittleFS file systems. Additionally, on-demand loading of optional functional modules is enabled through the hardware configuration source file HCS.

[0079] Then, according to the pruning strategy, the pruning modules are marked by modifying the system compilation configuration file, unnecessary functions in the kernel are disabled by using the kernel configuration tool kconfig, the device tree file is modified, the marked pruning hardware nodes are removed, and the pruned device tree binary file is compiled. Combined with the pruned system modules, the pruned system structure can be formed.

[0080] It is understandable that existing embedded operating systems are typically tailored at the module or component level, which is fine-grained but has limited flexibility. For example, FreeRTOS components can be dynamically configured, but the kernel and components are strongly coupled, and dependencies must be considered as a whole when tailoring. µC / OS extends functionality through a plug-in mechanism, but plug-ins lack dynamic collaboration capabilities. Furthermore, embedded operating system architectures are mostly monolithic kernels, with highly integrated functions but limited scalability. For example, TencentOS tiny provides a streamlined RTOS kernel that supports modular tailoring, but all services still run in kernel mode, resulting in limited functionality after tailoring. In addition, traditional embedded operating systems optimize resources by tailoring kernel modules, but there is a risk of kernel bloat. The layered trimming strategy of this application achieves coarse-grained trimming at the subsystem level by removing unnecessary modules (such as pre-installed applications, subsystems, or file systems unrelated to power business) at the application layer, framework layer, and kernel layer. This effectively reduces the overall resource consumption of the system. Compared with traditional embedded operating systems that trim by module or component, the strategy of trimming at a high level such as the subsystem avoids direct modification of the kernel itself, thereby reducing the possibility of kernel bloat due to improper or incomplete kernel trimming. At the same time, the subsystems of the HarmonyOS support functional granular trimming, which can split the enhanced software service subsystem into multiple sub-modules such as AI and multimedia. This trimming method allows the HarmonyOS to support complex application scenarios with a smaller amount of data. In addition, in terms of technical architecture, the HarmonyOS architecture adopts a design that combines a microkernel and a distributed soft bus. The microkernel only provides basic services such as thread scheduling and IPC communication, while system functions exist in a modular form and cross-device resource scheduling is achieved through the distributed soft bus. This architecture makes the code size of the HarmonyOS only 1 / 4 of that of the Android operating system, and it can still maintain cross-device collaboration capabilities after trimming.

[0081] In addition, in step S4, driver adaptation is performed based on the trimmed system structure and the HDF hardware unified driver framework of the HarmonyOS operating system. The HDF driver binding tool is used to bind the driver interface of the power terminal device peripheral. The driver compilation script is written according to the type of operating system running the target chip, and the device description file is configured to obtain the driver adaptation result.

[0082] Among them, such as Figure 3 As shown, the process of driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework includes the following:

[0083] Step S41: Bind the driver service interface of the power terminal equipment peripheral to the HDF hardware unified driver framework, define the driver initialization interface and resource release interface, and call the driver entry registration macro to register the driver entry into the HDF hardware unified driver framework.

[0084] Step S42: Write the driver compilation script according to the type of operating system running on the target chip;

[0085] Step S43: Declare the hardware parameters of the power terminal equipment peripherals in the device description file.

[0086] Specifically, the driver adaptation of the HarmonyOS operating system needs to be implemented based on the HDF hardware unified driver framework. This framework provides driver loading, service management and cross-process communication mechanisms, covering core components such as unified hardware device interface, driver model, operating system abstraction layer and configuration interface. The driver adaptation process includes three key steps: driver implementation, writing compilation scripts and device configuration. During the driver implementation phase, the driver service interface of the power terminal device peripheral is bound to the HDF hardware unified driver framework through the HDF driver service binding interface. HDF driver initialization and release interfaces are defined, and the driver entry point is registered to the HDF hardware unified driver framework using a global variable of type HDF Driver Entry. During the compilation script writing phase, a driver compilation script needs to be written according to the operating system type of the target chip. For example, if the target chip runs a lightweight operating system, the driver is compiled using the compilation template provided by the HDF hardware unified driver framework, and the compilation result is linked to the kernel image. If the target chip runs a Linux operating system, a Kconfig configuration file and a Makefile need to be added to define the compilation logic of the driver module. During the device configuration phase, the hardware parameters of the power terminal device peripheral need to be declared in the device description file. These hardware parameters include chip model, register address, interrupt number, clock frequency, and peripheral protocol type, such as GPIO pin multiplexing mode or SPI controller address range, providing the necessary information for the HDF framework to load the driver.

[0087] In addition, the driver message mechanism adopts a layered design to integrate message queues, event distribution, and asynchronous processing. It supports priority scheduling and secure delivery in a multi-threaded environment. The publish-subscribe model decouples the driver from the system service. For example, the driver layer registers an event listener, and the system service subscribes to the event and is asynchronously notified by the HDF framework to ensure real-time response. Driver service management binds service interfaces through the Bind pointer function of HDF Driver Entry and supports two acquisition methods: direct call through HDF interface or dynamic discovery of services based on the subscription mechanism. For example, after the encryption driver binds to the AesEncrypt interface, the application layer obtains the service instance through HDF Device Obtain or dynamically loads it by subscribing to service change events.

[0088] Understandably, in traditional driver adaptation solutions, driver code is often deeply coupled with specific chip platforms and operating system kernels, resulting in poor portability and high reuse costs. Whenever hardware is upgraded or the operating system is changed, drivers often require large-scale rewriting or cumbersome adaptation. Simultaneously, drivers, device configurations, and compilation logic are scattered across various locations, lacking a unified standard, making management complex and maintenance difficult. Furthermore, drivers often use tightly coupled synchronous calls with upper-layer applications or system services, which can easily lead to blocking in multi-threaded environments, affecting the system's real-time responsiveness. This application, however, separates the driver implementation in step S41, the compilation configuration in step S42, and the device parameters in step S43 using the HDF framework. Driver developers only need to focus on the implementation of core service interfaces and interact with the framework through standard interfaces. Hardware-specific configurations (such as register addresses and interrupt numbers) are independently placed in the device description file, allowing the same driver code to be reused on different hardware platforms simply by modifying the configuration file, greatly reducing adaptation costs and complexity. Furthermore, the HDF framework provides a unified driver model and operating system abstraction layer, enabling drivers to be loaded and managed consistently. During the compilation phase, a standardized compilation template can be selected based on the target operating system, achieving standardization and automation of the build process and avoiding the errors prone to occur in traditional solutions due to manually writing Makefiles and other files. In addition, the driver message mechanism in this application adopts a layered design, integrating event distribution and asynchronous processing (publish-subscribe model). Events generated by the driver layer can be asynchronously subscribed to and notified by system services, rather than through traditional synchronous waiting. This decoupling design avoids blocking, supports priority scheduling, and ensures that critical tasks (such as real-time control of power terminals) can be responded to quickly and reliably. Furthermore, the service management mechanism (such as binding service interfaces through the Bind pointer function to support dynamic discovery) further strengthens the independence between components, facilitating dynamic loading and updating of services.

[0089] In addition, in step S5, the compilation toolchain parameters are configured through cross-compilation services, and the application runtime environment of the power terminal equipment is ported using container technology to achieve the deployment and migration of applications on the power terminal equipment.

[0090] Among them, such as Figure 4 As shown, the process of transplanting the power terminal equipment into the application operating environment includes the following:

[0091] Step S51: Specify the absolute path of the compilation toolchain in the cross-compilation service configuration, set the directory addresses of the standard libraries and header files required by the target chip, and configure the compiler path;

[0092] Step S52: Obtain the container compilation image of the selected HarmonyOS operating system, start the container environment and download the dependent components required for compiling HarmonyOS operating system, enable the dependent functions required for container operation by modifying the kernel configuration, and add the directory and file permission configurations required for container operation in the file system.

[0093] Step S53: Burn the compiled system image to the power terminal device, deploy the static executable file of the container to the system path, and adjust the storage driver parameters of the container to adapt to the storage device characteristics of the power terminal device, thereby completing the porting of the application runtime environment of the power terminal device.

[0094] Specifically, first, in the cross-compilation service configuration, specify the absolute path of the compilation toolchain, set the directory addresses of the standard libraries and header files required by the target chip, and configure the compiler path. Then, obtain the container compilation image of the selected HarmonyOS operating system, start the container environment, and download the dependent components required for HarmonyOS compilation. Enable the necessary dependency functions for container operation by modifying the kernel configuration; for example, enable options such as CONFIG_NAMESPACES and CONFIG_CGROUPS via `make menuconfig`. Add directory and file permission configurations for container operation dependencies to the file system. After completing the system image compilation, burn it to the power terminal device, download the static Docker binary file and configure it to the system path, and adjust the storage driver by modifying ` / etc / docker / daemon.json` to adapt to low-performance storage devices. Finally, burn the compiled system image to the power terminal device, deploy the container's static executable file to the system path, and adjust the container's storage driver parameters to adapt to the storage device characteristics of the power terminal device. This completes the porting of the application runtime environment on the power terminal device, enabling the porting of old applications and the deployment of new applications on the power terminal device.

[0095] Optionally, the adaptation and customization method based on the HarmonyOS operating system for power terminal devices further includes the following after constructing the system service layer:

[0096] Perform graphical driver adaptation.

[0097] It is understandable that the HarmonyOS operating system supports a graphical interface. Therefore, this application also addresses the graphical interface adaptation requirements by implementing graphical driver adaptation in layers of hardware, framework, and application.

[0098] The process of implementing graphical driver adaptation through a layered approach involving hardware, framework, and application layers includes the following:

[0099] At the hardware layer, the graphics processor model is first confirmed using the device tree or the lspci command. The compatibility identifier and register address range of the graphics processor are defined in the device tree. The hardware abstraction layer library provided by the graphics processor manufacturer is integrated into the system-specified path vendor / lib / hw. The graphics processor driver module information is registered through the configuration file hdf_config.hcs. The OpenGL ES 2.0 test cases are run using the preset graphics interface testing tool glmark2-es2. The driver status of the graphics processor is determined based on frame rate stability. Display controller parameters are configured in the device tree, and the kernel display driver is modified to support frame buffer operations. For example, for the display driver, display controller parameters need to be configured in the device tree, such as specifying the Rockchip RK3568 display controller as rockchip,rk3568-display, and defining the clock frequency, blanking parameters, etc. Simultaneously, the kernel driver fbmem.c is modified to support the FBIO_WAITFORVSYNC command, enabling multi-buffer switching of the frame buffer and avoiding screen tearing.

[0100] At the framework layer, the graphics compositor type and buffer quantity are selected through the system configuration file. The input device information of the power terminal equipment is registered in the input management configuration. Touch coordinate calibration is performed and data accuracy is verified using a coordinate calibration tool. For example, the graphic subsystem is enabled in build / subsystem_config.json, and the graphic_surface and window_manager components are activated. The graphics compositor type and buffer quantity are selected through the HCS configuration file to reduce lag. Input event adaptation requires registering the input device information of the power terminal equipment in input_manager_config.hcs. Touch coordinate calibration is performed using the coordinate calibration tool tslib. A calibration matrix is ​​generated using ts_calibrate and the accuracy of the raw data is verified using ts_print_raw.

[0101] At the application layer, a user interface framework is integrated based on the power application requirements. If the HarmonyOS native UI framework ArkUI is used, the page layout is defined using declarative syntax and responsive design is employed. For example, in Index.ets, decorators are used to define the page entry and component layout, and Flex layout is used to achieve responsive design. If a third-party framework, such as LVGL, is used, the framework display driver is initialized and basic controls are built. Additionally, at the application layer, dynamic resolution adaptation requires registering a Display Manager listener in the application to dynamically adjust the layout based on resolution change events, and using percentages or weights instead of fixed-pixel layouts to adapt to different screen sizes.

[0102] It is understandable that traditional embedded systems, when adapting graphical interfaces at the hardware layer, heavily rely on directly modifying the kernel source code and device tree to adapt to the graphics hardware. This process is cumbersome, strongly tied to the kernel version, and has high porting and maintenance costs. In contrast, this application maps the HDF hardware unified driver framework to the target chip and defines and registers hardware information through a standardized HCS configuration file, decoupling the driver from the kernel. This allows for graphics hardware adaptation without modifying the kernel source code, making the adaptation process simpler and easier to maintain. Furthermore, traditional embedded systems, when adapting graphical interfaces at the framework layer, require manually selecting, compiling, and integrating numerous scattered open-source components, a complex and error-prone process. In this application, during actual development, developers only need to declare the required functions in a unified configuration file, and the system automatically completes the integration. For input device management and calibration, the HarmonyOS operating system also provides a unified framework and standardized tools, achieving an out-of-the-box experience, greatly simplifying the development process and lowering the technical threshold. In addition, traditional embedded systems rely heavily on third-party UI libraries when adapting graphical interfaces at the application layer. Developers need to handle complex issues such as the connection with the underlying system and cross-screen adaptation themselves. In contrast, this application provides the HarmonyOS native interface framework ArkUI and declarative syntax. The underlying system has been deeply optimized and integrated with the graphics system, which improves development efficiency.

[0103] In addition, such as Figure 5 As shown, another embodiment of the present invention also provides an adaptation and customization system based on the HarmonyOS operating system for power terminal devices, preferably employing the adaptation and customization method based on the HarmonyOS operating system for power terminal devices as described above, including:

[0104] The hardware platform adaptation module is used to select the HarmonyOS operating system to be adapted according to the functional requirements and performance requirements of the power terminal equipment, select the target chip to be adapted according to the selected HarmonyOS operating system, and map the kernel of the selected HarmonyOS operating system and HDF hardware unified driver framework to the target chip to build and adapt the hardware layer.

[0105] The system service adaptation module is used to start the kernel of the HarmonyOS operating system in the target chip based on the hardware layer, configure and start the initialization script, generate the initialization process, and start the service management hub, device event listener and application incubator process in sequence through the initialization process to build the system service layer.

[0106] The function trimming module is used to map the core functions of the power terminal equipment to the hardware nodes corresponding to the selected HarmonyOS operating system based on the application scenario of the power terminal equipment, and remove the hardware nodes to be trimmed based on the layered trimming strategy to obtain the trimmed system structure.

[0107] The driver adaptation module is used to perform driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework to obtain the driver adaptation result.

[0108] The application adaptation module is used to port the application operating environment of power terminal equipment to enable the deployment and migration of applications on power terminal equipment.

[0109] It is understood that the adaptation and customization system for the HarmonyOS operating system based on power terminal devices in this embodiment first adapts the functional and performance requirements of the power terminal devices to the HarmonyOS type and chip type to build and adapt the hardware layer. Then, it sequentially starts the service management hub, device event listener, and application incubator processes through initialization scripts to build the system service layer, thereby achieving system service adaptation. Next, it maps the core functions of the power terminal devices to the hardware nodes corresponding to the selected HarmonyOS based on the application scenarios of the power terminal devices, and removes the hardware nodes that need to be customized based on the layered customization strategy. It can customize the functions of the HarmonyOS according to different power application scenarios, which not only reduces the waste of system resources, but also realizes functional customization. Then, it performs driver adaptation based on the customized system structure and HDF hardware unified driver framework to ensure that the power terminal devices run stably and efficiently under the selected HarmonyOS. Finally, it migrates the application runtime environment of the power terminal devices to realize the migration of old applications and the deployment of new applications on the power terminal devices. This system can realize the efficient operation and functional customization of power terminal devices under the HarmonyOS, which greatly improves the overall performance and reliability of the power Internet of Things system.

[0110] In addition, another embodiment of the present invention provides an electronic device including a processor and a memory, wherein the memory stores a computer program, and the processor executes the steps of the method described above by calling the computer program stored in the memory.

[0111] In addition, another embodiment of the present invention provides a computer-readable storage medium for storing a computer program adapted and tailored to the HarmonyOS operating system of a power terminal device, wherein the computer program executes the steps of the method described above when running on a computer.

[0112] Common computer-readable storage media include: floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, any other optical media, punch cards, paper tape, any other physical media with perforated patterns, random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), flash erasable programmable read-only memory (FLASH-EPROM), any other memory chips or cartridges, or any other media readable by a computer. Instructions may further be transmitted or received by a transmission medium. The term transmission medium can include any tangible or intangible medium used to store, encode, or carry instructions for execution by a machine, and includes digital or analog carrier communication signals or intangible media that facilitate communication of such instructions. Transmission media include coaxial cables, copper wires, and optical fibers, which contain conductors for transmitting a bus of computer data signals.

[0113] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented 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. The solutions in the embodiments of this application can be implemented in various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0114] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. 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... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0115] 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.

[0116] 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.

[0117] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0118] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

[0119] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for adapting and tailoring the HarmonyOS operating system for power terminal equipment, characterized in that, Includes the following: Select the appropriate HarmonyOS based on the functional requirements and performance requirements of the power terminal equipment, select the appropriate target chip based on the selected HarmonyOS, and map the kernel of the selected HarmonyOS and the HDF hardware unified driver framework to the target chip to build and adapt the hardware layer. The kernel of the HarmonyOS operating system in the target chip is started based on the hardware layer, the initialization script is configured and started, the initialization process is generated, and the service management hub, device event listener and application incubator process are started in sequence through the initialization process to build the system service layer. Based on the application scenarios of power terminal equipment, the core functions of power terminal equipment are mapped to the hardware nodes corresponding to the selected HarmonyOS operating system using the system service layer, and the hardware nodes that need to be cut are removed based on the layered cutting strategy to obtain the cut system structure. Driver adaptation is performed based on the trimmed system architecture and the HDF hardware unified driver framework to obtain the driver adaptation result. The application operating environment of the power terminal equipment is transplanted to enable the deployment and migration of applications on the power terminal equipment; The process of mapping the selected HarmonyOS kernel and HDF hardware unified driver framework to the target chip includes the following: Confirm whether the CPU architecture of the target chip is within the support range of the selected HarmonyOS. If it is within the support range, create a corresponding architecture subdirectory in the kernel source code directory and implement the core modules of startup code, interrupt handling, and process scheduling. Otherwise, develop an adapted basic architecture. Customize the hardware abstraction layer according to the characteristics of the target chip, define the address and interrupt number of the power terminal peripheral in the device tree and perform physical address mapping, configure the clock tree to implement the clock operation interface, and encapsulate the control interface and allocate data transmission buffer for the hardware acceleration module in the hardware abstraction layer. Modify the kernel code to ensure that the kernel can be compiled and run correctly on the target chip; Write power terminal peripheral drivers that conform to the HDF hardware unified driver framework specification; Hardware parameters are defined through hardware configuration source files, and the consistency between the device tree and the parameters in the hardware configuration source files is ensured. The driver loading order is then configured in the manager of the HDF hardware unified driver framework. Modify the system build configuration to add a driver module and generate a system image. After burning the image to the target chip, verify the driver function and the effectiveness of power data transmission. The process of transplanting power terminal equipment into the application and operating environment includes the following: In the cross-compilation service configuration, specify the absolute path of the compilation toolchain, set the directory addresses of the standard libraries and header files required by the target chip, and configure the compiler path; Obtain the container compilation image of the selected HarmonyOS operating system, start the container environment and download the dependent components required for compiling HarmonyOS, enable the dependent functions required for container operation by modifying the kernel configuration, and add the directory and file permission configurations required for container operation in the file system. The compiled system image is burned to the power terminal device, the static executable file of the container is deployed to the system path, and the storage driver parameters of the container are adjusted to adapt to the storage device characteristics of the power terminal device, thus completing the porting of the application runtime environment of the power terminal device.

2. The adaptation and customization method for HarmonyOS based on power terminal equipment as described in claim 1, characterized in that, After building the system service layer, the following content is also included: Perform graphical driver adaptation.

3. The adaptation and customization method for HarmonyOS based on power terminal equipment as described in claim 2, characterized in that, The process of performing graphical driver adaptation includes the following: At the hardware layer, the graphics processor model is identified through the device tree, the compatibility identifier and register address range of the graphics processor are defined in the device tree, the hardware abstraction layer library provided by the graphics processor manufacturer is integrated into the system's specified path, the driver module information of the graphics processor is registered through the configuration file, test cases are run using the preset graphics interface test tool, the driver status of the graphics processor is judged based on the frame rate stability, the display controller parameters are configured in the device tree, and the kernel display driver is modified to support frame buffer operations. At the framework layer, the graphics synthesizer type is selected and the number of buffers is set through the system configuration file. The input device information of the power terminal equipment is registered in the input management configuration. The touch coordinate calibration tool is used to perform touch coordinate calibration and verify the accuracy of the data. At the application layer, a user interface framework is integrated according to the needs of power applications. If the HarmonyOS native interface framework is used, the page layout is defined through declarative syntax and responsive design is used. If a third-party framework is used, the framework display driver is initialized and basic controls are built.

4. The adaptation and customization method for HarmonyOS based on power terminal equipment as described in claim 1, characterized in that, The layered pruning strategy includes removing pre-installed applications unrelated to power services from the application layer, pruning subsystems unrelated to power interruption functions from the framework layer, and removing unnecessary file system functions from the kernel layer.

5. The adaptation and customization method for HarmonyOS based on power terminal equipment as described in claim 1, characterized in that, The process of driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework includes the following: Bind the driver service interface of the power terminal equipment peripheral to the HDF hardware unified driver framework, define the driver initialization interface and resource release interface, and call the driver entry registration macro to register the driver entry into the HDF hardware unified driver framework. Write driver compilation scripts according to the type of operating system running on the target chip; Declare the hardware parameters of the power terminal equipment peripherals in the device description file.

6. An adaptation and customization system for HarmonyOS on power terminal devices, employing the adaptation and customization method for HarmonyOS on power terminal devices as described in any one of claims 1 to 5, characterized in that, include: The hardware platform adaptation module is used to select the HarmonyOS operating system to be adapted according to the functional requirements and performance requirements of the power terminal equipment, select the target chip to be adapted according to the selected HarmonyOS operating system, and map the kernel of the selected HarmonyOS operating system and HDF hardware unified driver framework to the target chip to build and adapt the hardware layer. The system service adaptation module is used to start the kernel of the HarmonyOS operating system in the target chip based on the hardware layer, configure and start the initialization script, generate the initialization process, and start the service management hub, device event listener and application incubator process in sequence through the initialization process to build the system service layer. The function trimming module is used to map the core functions of the power terminal equipment to the hardware nodes corresponding to the selected HarmonyOS operating system based on the application scenario of the power terminal equipment, and remove the hardware nodes to be trimmed based on the layered trimming strategy to obtain the trimmed system structure. The driver adaptation module is used to perform driver adaptation based on the trimmed system architecture and the HDF hardware unified driver framework to obtain the driver adaptation result. The application adaptation module is used to port the application operating environment of power terminal equipment to enable the deployment and migration of applications on power terminal equipment.

7. An electronic device, characterized in that, The method includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the steps of the method as described in any one of claims 1 to 5 by calling the computer program stored in the memory.

8. A computer-readable storage medium for storing computer programs adapted and tailored to the HarmonyOS operating system for power terminal equipment, characterized in that, The computer program, when run on a computer, performs the steps of the method as described in any one of claims 1 to 5.

Images