A distributed operating system access method and system for inventory devices

Abstract

The application discloses a kind of distributed operating system access methods and systems of inventory equipment, it is related to electric power internet of things and edge computing technical field, including: in inventory equipment or associated edge node provides isolated running environment;In isolated running environment, running communication agent component, by communication agent component, the private protocol data of inventory equipment is converted into standard thing model data, and based on standard thing model data accesses distributed soft bus network;In isolated running environment, the original business process of communication agent component and inventory equipment is executed resource quota control and safety isolation.This application can realize inventory equipment low overhead, high security access distributed operating system ecology without replacing hardware, improves the level of interconnection and operation and maintenance efficiency.

Description

Technical Field

[0001] This invention belongs to the field of power Internet of Things and edge computing technology, specifically relating to a distributed operating system access method and system for existing devices. Background Technology

[0002] With the large-scale application of distributed operating systems in the Industrial Internet of Things (IIoT) field, newly added terminal devices can achieve cross-device collaborative operation by relying on the native architecture to complete software and hardware adaptation. However, in the process of ecological transformation of existing devices, there is a natural disconnect between the existing traditional device architecture and the distributed architecture. On the one hand, existing devices are mostly early-production embedded hardware with very low design margins in processor computing power, memory, and storage resources, which cannot support the deployment of a complete distributed operating system software stack. On the other hand, traditional existing devices mostly adopt a single-process tightly coupled running architecture, lacking independent resource partitioning and process isolation mechanisms. Different services share the same running space, and once the newly added distributed communication components malfunction or are attacked by external forces, it is easy to cause cross-service interference or leakage of core production data, making it difficult to meet the requirements of high reliability and high security. In addition, existing transformation solutions mostly rely on independent gateways for simple data pass-through, without building a layered and decoupled integrated access architecture on the edge side. This makes it impossible for existing devices to truly integrate into the distributed soft bus network, and the on-site transformation cost is high and the operation and maintenance efficiency is low. Therefore, there is an urgent need for a technical solution that can enable existing devices to access the distributed operating system with low overhead and high security without replacing hardware. Summary of the Invention

[0003] To address the shortcomings of existing technologies, the present invention aims to provide a distributed operating system access method and system for existing devices. This method and system run a communication proxy component in an isolated operating environment to perform protocol conversion and soft bus access, and implement resource quota management and security isolation, thereby enabling existing devices to access smoothly and securely without the need to replace hardware.

[0004] This invention provides a method for accessing a distributed operating system on existing devices, comprising:

[0005] Provide an isolated operating environment for existing equipment or associated edge nodes;

[0006] A communication proxy component is run in the isolated operating environment. The communication proxy component converts the private protocol data of the existing devices into standard object model data, and accesses the distributed soft bus network based on the standard object model data.

[0007] In the isolated operating environment, resource quota management is performed on the original business processes of the communication proxy component and the existing equipment;

[0008] In the isolated operating environment, security isolation is performed on the original business processes of the communication proxy component and the existing devices.

[0009] The step of converting the private protocol data of the existing devices into standard object model data through the communication proxy component, and accessing the distributed soft bus network based on the standard object model data, includes: receiving the private protocol data through a lightweight protocol stack within the communication proxy component; mapping the private protocol data to the standard object model data through an object model parsing component within the communication proxy component; and accessing the standard object model data to the distributed soft bus network through a soft bus proxy within the communication proxy component.

[0010] The step of mapping the private protocol data to the standard object model data through the object model parsing component within the communication proxy component includes: parsing the private protocol data and extracting multi-protocol data points, wherein the multi-protocol data points include at least one of device status data, measurement values, and control commands; obtaining a preset object model mapping rule table, wherein the object model mapping rule table records the correspondence between the identifiers of the multi-protocol data points and attributes, events, or services in the standard object model data; based on the correspondence, converting the multi-protocol data points into a structured data format conforming to the target distributed operating system specification; when the multi-protocol data point is device status data or measurement value, mapping it to attribute data or event data in the standard object model data and attaching a timestamp and device identifier; when the multi-protocol data point is a control command, mapping it to service data in the standard object model data and generating a service call request containing execution parameters and a callback address.

[0011] The process of implementing resource quota management for the original business processes of the communication proxy component and the existing devices in the isolated operating environment includes: setting tiered quotas for processor computing power, running memory, and network bandwidth for the original business processes of the communication proxy component and the existing devices respectively; and performing dynamic resource scheduling for the original business processes of the communication proxy component and the existing devices based on the tiered quotas to limit the upper limit of resource usage of the original business processes of the communication proxy component and the existing devices.

[0012] The dynamic resource scheduling of the communication proxy component and the existing business processes of the existing devices based on the tiered quota includes: allocating a first resource control group to the communication proxy component and a second resource control group to the existing business processes of the existing devices based on container engine control group technology; configuring a first processor computing power threshold, a first running memory threshold, and a first network bandwidth threshold in the first resource control group, and configuring a second processor computing power threshold, a second running memory threshold, and a second network bandwidth threshold in the second resource control group; real-time monitoring of the resource consumption of the communication proxy component and the existing business processes of the existing devices; triggering resource rate limiting or process suspension operations on the communication proxy component when the resource consumption of the communication proxy component reaches any one of the first processor computing power threshold, the first running memory threshold, or the first network bandwidth threshold; triggering resource rate limiting or process suspension operations on the existing business processes of the existing devices when the resource consumption of the existing business processes of the existing devices reaches any one of the second processor computing power threshold, the second running memory threshold, or the second network bandwidth threshold.

[0013] The process of performing security isolation on the original business processes of the communication proxy component and the existing devices in the isolated operating environment includes: performing independent process isolation on the original business processes of the communication proxy component and the existing devices to prevent cross-business interference; performing network isolation on the original business processes of the communication proxy component and the existing devices to block unauthorized access; and performing encryption processing on the end-to-end data transmission between the communication proxy component and the distributed soft bus network.

[0014] The steps of performing independent process isolation for the communication proxy component and the original business processes of the existing devices, and performing network isolation for the communication proxy component and the original business processes of the existing devices, include: creating a first process namespace and a first file system namespace for the communication proxy component based on container engine namespace technology, and creating a second process namespace and a second file system namespace for the original business processes of the existing devices, so that the communication proxy component and the original business processes of the existing devices run independently within their respective process namespaces and file system namespaces; allocating a first virtual network stack for the communication proxy component and a second virtual network stack for the original business processes of the existing devices; configuring network access control rules between the first virtual network stack and the second virtual network stack, wherein the network access control rules prohibit direct data packet transmission between the first virtual network stack and the second virtual network stack; and establishing an encrypted communication tunnel between the communication proxy component and the distributed soft bus network through the first virtual network stack, wherein the encrypted communication tunnel uses a transport layer security protocol or a national cryptographic algorithm to encrypt the end-to-end transmitted data.

[0015] The method further includes: real-time inspection of the health status of the isolated operating environment; automatic restart of the communication proxy component when a failure is detected; performing a canary update of the container image in the isolated operating environment in response to receiving an image update instruction; and reporting the operating logs of the isolated operating environment to the cloud operation and maintenance platform.

[0016] This invention also provides a distributed operating system access system for existing devices, comprising: an environment adaptation module for providing an isolated operating environment for existing devices or associated edge nodes; a communication proxy module for running a communication proxy component in the isolated operating environment, converting the private protocol data of the existing devices into standard object model data through the communication proxy component, and accessing a distributed soft bus network based on the standard object model data; a resource management module for performing resource quota management on the communication proxy component and the original business processes of the existing devices in the isolated operating environment; and a security isolation module for performing security isolation on the communication proxy component and the original business processes of the existing devices in the isolated operating environment.

[0017] The above system achieves the same technical effect as the method embodiment through the collaborative work of its various functional modules, that is, it enables existing devices to access the distributed operating system ecosystem with low overhead and high security without replacing hardware.

[0018] 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 computer program to implement the method described above.

[0019] This invention discloses a method and system for accessing a distributed operating system for existing devices. By providing an isolated operating environment for existing devices or associated edge nodes, and running a communication proxy component within it, a lightweight protocol stack and object model parsing component are used to convert private protocol data into standard object model data and connect it to a distributed soft bus network. This addresses the architectural challenge of heterogeneous existing devices being unable to uniformly access a distributed ecosystem. Simultaneously, by implementing resource quota management based on control group technology for the communication proxy component and existing business processes within the isolated operating environment, and by implementing dual security isolation for processes and networks based on namespace technology, the resource contention and security risks caused by the scarcity of hardware resources and the tightly coupled single-process architecture of existing devices are effectively overcome. This solution does not require replacing the main hardware of existing devices; smooth access can be achieved solely through software-level virtualization and containerization modifications, significantly reducing modification costs and on-site implementation difficulty. Furthermore, the automated operation and maintenance mechanism improves the management efficiency throughout the entire lifecycle, meeting the comprehensive needs of industries such as power for the reuse of existing equipment, security compliance, and interoperability. Attached Figure Description

[0020] Figure 1 This is a diagram of the distributed operating system access system for existing devices according to an embodiment of this application;

[0021] Figure 2 This is a flowchart of the method for accessing a distributed operating system for existing devices according to an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application.

[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0024] like Figure 2 As shown in the figure, this application provides a method for integrating a distributed operating system into existing devices. This method is mainly applied in industrial scenarios such as the power Internet of Things, aiming to solve the technical problem that traditional existing devices cannot be directly integrated into the new distributed operating system ecosystem due to limited hardware resources and closed architecture. The method in this embodiment mainly includes the following steps during operation.

[0025] Step S100: Provide an isolated operating environment for existing devices or associated edge nodes.

[0026] Specifically, the isolated operating environment provides the built-in endpoints of this system with full-domain resource scheduling and underlying isolation protection architecture. Its core is building a logically independent isolated operating environment on top of physical hardware, forming an independent computing and storage sandbox completely separated from the host machine's original power services. This provides a secure operating foundation for HarmonyOS adaptation components. This unit supports two deployment methods for the isolated environment: one is to build the isolated sandbox locally on existing devices with spare computing power and memory, enabling on-site processing of endpoint data and reducing transmission latency; the other is to deploy the isolated environment on the edge nodes that communicate with it, adapting to older terminals with extremely scarce hardware resources that cannot bear the virtualization overhead, with the edge nodes acting as proxies to complete protocol conversion. For integration with HarmonyOS, the isolated operating environment can be built using lightweight container engines such as Docker and LXC to create a user-space isolated space, or a hardware-level virtualization instance can be built based on KVM Virtual Machine Monitor. Both are configured with independent file systems, process spaces, and dedicated network stacks. The unit synchronously builds a hierarchical quota management mechanism for CPU, memory, and network bandwidth, and adds multi-layer security protection with process isolation, end-to-end encryption, and hierarchical access control. Relying on this underlying isolation architecture, HarmonyOS access functionality can be dynamically added without modifying the original firmware code of existing devices, avoiding the risk of operational failures caused by modifications to the underlying system, and building a deep security system on the edge side, which complies with the requirements of the power monitoring system grade protection standard.

[0027] Step S200: Run the communication proxy component in the isolated operating environment, convert the private protocol data of the existing devices into standard object model data through the communication proxy component, and access the distributed soft bus network based on the standard object model data.

[0028] Specifically, the communication proxy component is a runtime entity residing in an isolated operating environment, acting as both a "protocol translator" and an "ecosystem connector." During operation, the communication proxy component first reads or receives private protocol data from the existing business processes of the existing devices. This data typically follows vendor-defined binary specifications or non-standard text formats, which cannot be directly recognized by the distributed operating system. Subsequently, the communication proxy component internally executes protocol parsing and mapping logic, converting this heterogeneous private data into standard object model data conforming to the target distributed operating system specifications in real time. Standard object model data is a structured digital twin representation containing standardized semantic fields such as attributes, events, and services. Finally, the communication proxy component utilizes the distributed soft bus interface to publish the standardized data to the distributed soft bus network, enabling other HarmonyOS ecosystem devices or applications in the network to access the existing device as if it were a native device. This process is entirely a dynamic data flow executed automatically at runtime, rather than static code compilation or manual configuration. This runtime protocol conversion and access mechanism completely decouples the existing hardware devices from the upper-layer ecosystem applications, enabling heterogeneous devices from different manufacturers and using different protocols to seamlessly integrate into the distributed collaborative network with a unified identity.

[0029] Step S300: In the isolated operating environment, resource quota control is performed on the original business processes of the communication agent components and existing equipment.

[0030] Specifically, because the hardware resources of existing equipment are often in a state of tight balance, newly added communication proxy components, if operated without restrictions, can easily preempt the CPU, memory, or bandwidth resources required by the original core business, leading to production accidents. Therefore, this step establishes a mandatory resource scheduling mechanism within the isolated operating environment. This mechanism explicitly manages both the communication proxy components and the original business processes, reflecting a strategy of "equal emphasis on both new and old, with priority given to backup." During operation, the system monitors the resource consumption of both parties in real time according to a preset tiered quota policy. For example, higher resource priority and backup quotas can be allocated to the original business processes that ensure core production, while strict resource usage limits are set for the communication proxy components. When the resource consumption of the communication proxy component exceeds the threshold, rate limiting, degradation, or suspension operations are automatically triggered to ensure that it does not crowd out the critical resources of the original business; conversely, if an abnormal resource leak occurs in the original business process, it will also be subject to quota restrictions to prevent overall system crashes. This two-way resource quota management mechanism ensures the operational certainty of existing equipment after the introduction of new functions from the bottom up, and solves the problem of mutual interference between new and old services caused by the lack of resource isolation in traditional solutions.

[0031] Step S400: In the isolated operating environment, perform security isolation on the original business processes of the communication proxy component and existing equipment.

[0032] Specifically, secure isolation is a crucial defense against attacks that prevent existing devices from becoming springboards for attacks after being connected to a distributed network. This step constructs a multi-dimensional security protection system within the isolated operating environment. On one hand, independent process isolation is implemented for the communication proxy component and the original business processes, ensuring they run in mutually invisible process spaces and file systems. Even if the communication proxy component suffers malicious attacks or exploits due to exposed interfaces, attackers cannot penetrate the isolation boundary to access or tamper with the core data and control logic of the original business processes. On the other hand, network isolation is implemented for both, blocking unauthorized lateral access paths and opening only necessary controlled communication channels. Furthermore, end-to-end encryption is performed on data transmission between the communication proxy component and the external distributed soft bus network to prevent sensitive power data from being eavesdropped on or tampered with during transmission. This defense-in-depth security isolation mechanism ensures that existing devices can enjoy the convenience of the distributed ecosystem while still meeting the stringent security and compliance requirements of industrial control systems.

[0033] In summary, this embodiment provides an isolated operating environment for existing devices or edge nodes, within which a communication proxy component performs protocol conversion and soft bus access. Simultaneously, it implements resource quota management and security isolation, forming a complete runtime access solution. This solution requires no replacement of the existing device hardware or intrusive firmware modifications. Through software-level virtualization and containerization, it enables existing devices to access the distributed operating system ecosystem with low overhead and high security, effectively addressing the technical pain points of high cost, significant security risks, and poor compatibility associated with existing device modifications in existing technologies.

[0034] Furthermore, the protocol conversion and access mechanisms within the communication proxy component are described in detail. The process of converting the private protocol data of existing devices into standard object model data through the communication proxy component, and then accessing the distributed soft bus network based on the standard object model data, specifically includes: receiving private protocol data through the lightweight protocol stack within the communication proxy component; mapping the private protocol data to standard object model data through the object model parsing component within the communication proxy component; and accessing the standard object model data to the distributed soft bus network through the soft bus proxy within the communication proxy component.

[0035] Specifically, the communication proxy component is not a standalone black-box program at runtime. Instead, it consists of three functionally decoupled sub-components—a lightweight protocol stack, a device model parsing component, and a soft bus proxy—working together to construct a layered, cross-protocol data standardization transformation architecture. The lightweight protocol stack, serving as the data entry point, is specifically tailored and optimized for the resource constraints of existing devices. It removes redundant network protocol processing logic from general-purpose operating systems, retaining only the minimal protocol parsing capabilities necessary for interaction with the original business processes of existing devices. It is responsible for capturing private protocol data streams in real-time from channels such as shared memory, local sockets, or serial ports, extracting and initially structuring the raw messages, and synchronously sending the pre-processed data to the device model parsing component and the soft bus proxy. The device model parsing component is the core translation engine that enables unified device model mapping and adaptive protocol conversion. It has pre-built or dynamically loaded semantic conversion logic adapted to the current device type, responsible for converting non-standard binary or text data into standard semantics understandable by the distributed operating system. The soft bus proxy, serving as the external exit, encapsulates the device discovery, bidirectional security authentication, and data transmission interfaces of the distributed soft bus, publishing the standardized device model data to the network in a manner compliant with ecosystem specifications. This layered architecture design allows each component to be iterated and optimized independently. For example, when a new protocol needs to be adapted, only the lightweight protocol stack needs to be updated, without having to reconstruct the entire proxy component, which significantly reduces maintenance costs and runtime overhead.

[0036] Furthermore, regarding the specific mapping logic of the object model parsing component, the object model parsing component within the communication proxy component maps private protocol data to standard object model data, including: parsing the private protocol data packet header and payload; extracting multi-protocol data points according to predetermined field marker bits, wherein the multi-protocol data points include at least one of the following: device status data (such as switch status, operating mode), measured values ​​(such as voltage, current, power factor), and control commands (such as remote tripping, parameter setting); secondly, obtaining a preset object model mapping rule table, which records the correspondence between the identifiers of the multi-protocol data points and the attributes, events, or services in the standard object model data; then, based on the correspondence, The component converts multi-specification data points into a structured data format that conforms to the target distributed operating system specification. When the multi-specification data points are device status data or measurement values, they are mapped to attribute data or event data in the standard object model data, and timestamps and device identifiers are appended. When the multi-specification data points are control commands, they are mapped to service data in the standard object model data, and a service call request containing execution parameters and callback addresses is generated. For unknown data points that do not match in the mapping rule table, the component executes a default processing strategy, including discarding and recording error logs, uploading raw hexadecimal messages for manual analysis in the cloud, or forwarding them directly according to a preset "transparent transmission" channel to ensure the fault tolerance and observability of the access link.

[0037] Specifically, multi-protocol data points refer to various information units defined by existing devices under different communication protocols. Their physical representation may be a register address, an offset, or a specific code. The object model parsing component first performs syntactic analysis on the original message to extract these discrete data points. Subsequently, the system does not rely on hard-coded conversion logic but instead queries a preset object model mapping rule table. This rule table is essentially a metadata configuration that defines the binding relationship between source-end data point identifiers (such as Modbus address 40001 or IEC104 information body address) and target-end object model fields (such as temperature, voltage_a). It should be understood that this mapping rule table is not a fixed static file; it can be JSON, XML, YAML, or other custom serialization formats, and supports updates at runtime via cloud distribution or hot reloading of local configuration files. This gives the communication proxy component the ability to adapt to new devices or adjust data semantics without recompiling the firmware.

[0038] During data conversion, differentiated encapsulation strategies are adopted for different types of data points. For device status data (such as switch opening / closing positions) or measured values ​​(such as voltage and current RMS values), they are mapped to attribute data or event data of the object model. To ensure the timing consistency of distributed collaboration, a high-precision timestamp and a globally unique device identifier must be forcibly appended to the converted data to ensure that upper-layer applications can accurately trace the data source and time. For control commands (such as remote control and parameter settings), they are mapped to service data of the object model. At this time, the object model parsing component not only converts the command itself, but also automatically generates a service call request containing execution parameters and callback addresses, enabling the control end in the distributed network to know the execution context of the command and receive feedback results through the callback address after execution, forming a complete closed-loop control link.

[0039] For example, in a power distribution terminal scenario, the existing business process reported a telemetry message containing the voltage value of phase A via the IEC104 protocol. After receiving this message, the lightweight protocol stack's object model parsing component extracts the data point with address 0x4001 and queries the mapping rule table to find that this address corresponds to the `phaseAVoltage` attribute in the HarmonyOS object model. Subsequently, the component reads the floating-point value from the message and encapsulates it into a structured object containing `device_id`, `timestamp`, `identifier`, and `value` fields according to the target specification. Finally, the soft bus proxy publishes this object through the distributed soft bus interface, enabling monitoring applications within the ecosystem to directly subscribe to and display the voltage value. This process completely shields the complexity of the underlying IEC104 protocol, achieving a transparent conversion of heterogeneous data to a unified ecosystem language.

[0040] Furthermore, the resource quota management mechanism and its underlying implementation within the isolated operating environment are described in detail. In the isolated operating environment, resource quota management is implemented for the original business processes of the communication proxy components and existing devices. This includes: setting tiered quotas for processor computing power, RAM, and network bandwidth for the original business processes of the communication proxy components and existing devices respectively; and based on these tiered quotas, dynamic resource scheduling is performed on the original business processes of the communication proxy components and existing devices to limit their resource usage limits.

[0041] Specifically, the tiered quota strategy is not a simple average allocation or fixed division, but a differentiated resource allocation based on business criticality and real-time requirements. In this application, the existing business processes of existing equipment typically carry core production tasks such as power data acquisition and relay protection, which have extremely high deterministic requirements for resource response, and are therefore assigned a high-priority guaranteed quota. The communication proxy component, as a newly added ecosystem access function, is important but auxiliary, and its quota setting follows the principle of "sufficient for use, with excess relinquished." This tiered mechanism ensures that the introduction of new functions on resource-constrained existing equipment does not come at the expense of the stability of core businesses. Dynamic resource scheduling refers to adjusting the amount of resources available to each process in real time based on the actual load during runtime, rather than performing a one-time static allocation at startup. In this way, the system can maximize the use of idle resources to improve the data processing efficiency of the communication proxy component while ensuring that existing business processes are not interfered with, achieving a dynamic balance between resource utilization and security.

[0042] Furthermore, to ensure the mandatory enforcement of the aforementioned tiered quota strategy, dynamic resource scheduling is implemented for the original business processes of communication proxy components and existing devices based on tiered quotas. This includes: allocating a first resource control group to the communication proxy components and a second resource control group to the original business processes of existing devices using container engine control group technology; configuring a first processor computing power threshold, a first running memory threshold, and a first network bandwidth threshold in the first resource control group, and configuring a second processor computing power threshold, a second running memory threshold, and a second network bandwidth threshold in the second resource control group; real-time monitoring of the resource consumption of the original business processes of the communication proxy components and existing devices; triggering resource rate limiting or process suspension operations on the communication proxy components when the resource consumption of the communication proxy components reaches any one of the first processor computing power threshold, the first running memory threshold, or the first network bandwidth threshold; and triggering resource rate limiting or process suspension operations on the original business processes of existing devices when the resource consumption of the original business processes of existing devices reaches any one of the second processor computing power threshold, the second running memory threshold, or the second network bandwidth threshold.

[0043] Specifically, cgroups are a resource isolation and limitation mechanism provided by the Linux kernel, enabling precise physical-level constraints on process groups' CPU time slices, memory usage, I / O bandwidth, etc., from the operating system level. In this embodiment, the container engine utilizes this mechanism to classify the communication proxy component and the original business processes into independent first and second resource control groups, respectively. This division ensures that the two process groups do not interfere with each other when competing for resources, completely avoiding the risk of the entire system crashing due to abnormal resource consumption by a single module in the traditional single-process architecture. The configuration of various thresholds is not arbitrarily set, but rather a safety boundary calculated based on the hardware specifications and business characteristics of the existing devices. For example, for a typical power distribution terminal equipped with an ARM Cortex-A7 processor and 512MB of memory, the first processor computing power threshold of the communication proxy component can be set to 80%, and the first running memory threshold can be set to 128MB; at the same time, the second running memory threshold of the original business processes can be set to 384MB, reserving sufficient buffer space.

[0044] During operation, the resource management module continuously collects resource consumption data from each control group. When the CPU utilization of the communication proxy component reaches the 80% threshold, the system automatically triggers rate limiting operations, such as reducing its data collection frequency or suspending the upload of non-urgent data, to bring its CPU utilization back to a safe range, thereby preventing it from crowding out the computing resources of the original business processes. Conversely, if the memory consumption of the original business processes exceeds the 384MB threshold due to memory leaks or other reasons, the system will trigger a temporary suspension operation or send an alarm signal to prevent it from exhausting system memory and causing the equipment to crash. In contrast, in traditional transformation schemes that do not implement the resource quota management mechanism of this application, once the newly added protocol conversion program experiences an infinite loop or memory overflow, it often instantly fills up all available resources, causing the original power acquisition business to completely stop or even restart the equipment, resulting in serious production safety hazards. This embodiment utilizes a hardware-level resource firewall built with control group technology to strictly limit the impact of faults to their respective resource sandboxes. Even if the communication proxy component malfunctions, existing business processes can still maintain basic operation using reserved resource quotas, significantly improving the overall reliability and robustness of existing devices after accessing the distributed ecosystem. It should be understood that the aforementioned threshold values ​​are merely illustrative and can be flexibly adjusted according to specific device models and business needs in practical applications. Any application employing a hierarchical quota management approach based on control groups falls within the scope of protection of this application.

[0045] Furthermore, the multi-level security isolation mechanism and its underlying implementation within the isolated operating environment are described in detail. In the isolated operating environment, security isolation is performed on the original business processes of the communication proxy component and existing devices, including: performing independent process isolation on the original business processes of the communication proxy component and existing devices to prevent cross-business interference; performing network isolation on the original business processes of the communication proxy component and existing devices to block unauthorized access; and performing encryption processing on end-to-end data transmission between the communication proxy component and the distributed soft bus network.

[0046] Specifically, the aforementioned triple isolation mechanism is not a sequential process executed in chronological order, but rather a parallel protection layer that takes effect simultaneously upon startup of the isolated operating environment, collectively forming a defense-in-depth system for existing devices. Independent process isolation aims to address the mutual interference problem caused by new components sharing address space with core business processes in traditional single-process architectures; network isolation aims to cut off unauthorized lateral penetration paths, preventing external attacks from using communication proxy components as springboards to affect existing business processes; and end-to-end encryption ensures the confidentiality and integrity of sensitive power data when it leaves the device boundary and enters the distributed soft bus network. This multi-dimensional security architecture design enables existing devices to meet the stringent security and compliance requirements of industrial control systems while accessing the open ecosystem.

[0047] Furthermore, to ensure that the above isolation strategy can be enforced at the operating system level, independent process isolation is performed on the original business processes of the communication proxy component and the existing devices, and network isolation is performed on the original business processes of the communication proxy component and the existing devices. This includes: using container engine namespace technology, creating a first process namespace and a first file system namespace for the communication proxy component, and creating a second process namespace and a second file system namespace for the original business processes of the existing devices, so that the communication proxy component and the original business processes of the existing devices run independently within their respective process namespaces and file system namespaces; allocating a first virtual network stack for the communication proxy component, and allocating a second virtual network stack for the original business processes of the existing devices; configuring network access control rules between the first virtual network stack and the second virtual network stack, the network access control rules prohibiting direct data packet transmission between the first virtual network stack and the second virtual network stack; establishing an encrypted communication tunnel between the communication proxy component and the distributed soft bus network through the first virtual network stack, the encrypted communication tunnel using transport layer security protocols or national cryptographic algorithms to encrypt end-to-end transmitted data.

[0048] Specifically, namespaces are resource isolation primitives provided by the Linux kernel, capable of reshaping the view of processes at the system call level. In this embodiment, the container engine utilizes PID namespace technology to ensure that the communication proxy component and the original business processes have their own independent process numbering systems, making them unaware of each other's existence and preventing cross-process interference through signal sending or other means. Simultaneously, using Mount namespace technology, completely isolated file system root directories are mounted for both, allowing the communication proxy component to access only its dedicated sandbox's configuration files and temporary data. It is completely unable to traverse or read the sensitive business partitions where the original business processes reside, thus eliminating the risk of malicious code tampering with core firmware or stealing local storage data at its source.

[0049] At the network layer, the system creates independent first and second virtual network stacks for the communication proxy component and the original business processes, respectively. Each virtual network stack has its own independent network device interface, routing table, and firewall rules, essentially creating two unconnected network planes on a single physical network card. Based on this, the system explicitly configures network access control rules between the first and second virtual network stacks, such as setting DROP policies through iptables or nftables, strictly prohibiting any direct IP packet transmission between the two virtual network stacks. This means that even if the communication proxy component is vulnerable to exploitation or malware injection due to exposed service interfaces, attackers cannot detect any service ports of the original business processes through network scanning or port connections, completely blocking lateral movement attack paths. Simultaneously, the communication proxy component is only authorized to establish encrypted communication tunnels with external distributed soft bus networks through the first virtual network stack. This tunnel uses the TLS protocol or national cryptographic algorithms (such as SM2 / SM3 / SM4) conforming to the standards of the State Cryptography Administration at the transport layer to encapsulate and encrypt all incoming and outgoing traffic, ensuring that data is not eavesdropped on or tampered with when transmitted over public networks or shared buses.

[0050] For example, in a real-world deployment scenario of a power distribution terminal, suppose the communication proxy component triggers a buffer overflow vulnerability by parsing malformed packets, allowing an attacker to gain shell privileges. Due to the security isolation mechanism implemented in this embodiment, when an attacker executes the `ps` command inside the communication proxy component's container, they can only see the proxy component's own child processes and cannot detect the existence of the original business processes. Attempts to access business configuration directories such as ` / etc / config` will return empty results or permission denial errors due to the isolation of the file system namespace. Attempts to ping or telnet the IP address of the original business processes will result in data packets being directly discarded by the access control rules between the virtual network stacks, preventing them from reaching the target port. In contrast, in traditional modification models that do not adopt this solution, once the proxy program is compromised, attackers can easily escalate privileges and control the entire terminal device, leading to the leakage of power data or malicious tampering of remote control commands. Therefore, this embodiment, through its underlying mandatory isolation mechanism built on namespaces and virtual network stacks, strictly limits security risks to a minimized sandbox, significantly improving the inherent security level of existing devices after they are integrated into the distributed ecosystem. It should be understood that the above-mentioned selection of namespace type, network stack configuration method and encryption algorithm is only an illustrative example. In actual application, it can be flexibly adjusted according to the support of the specific operating system and the security level requirements. As long as the multi-layer security protection concept based on kernel-level isolation technology is adopted, it falls within the protection scope of this application.

[0051] Furthermore, the automated operation and maintenance and fault self-healing mechanism of the isolated operating environment is described in detail. This method also includes: real-time monitoring of the health status of the isolated operating environment; automatically restarting the communication agent component when a failure is detected; performing canary updates to the container images in the isolated operating environment in response to received image update commands; and reporting the operating logs of the isolated operating environment to the cloud-based operation and maintenance platform.

[0052] Specifically, the aforementioned automated operation and maintenance mechanism is a key support for ensuring the long-term stable operation of existing equipment after it is connected to the distributed ecosystem. All its actions are automatically triggered by the system during runtime, requiring no manual on-site intervention. Real-time inspection refers to the system's built-in monitoring daemon sampling and detecting key indicators of the isolated operating environment at preset intervals (e.g., every second or every few seconds), including but not limited to the process liveness status of the communication proxy component, memory usage, CPU load, network connectivity, and response latency of critical business interfaces. This proactive health monitoring differs from the traditional passive alarm mode, as it can detect abnormal signs before a fault affects upper-layer services. When the inspection logic determines that the communication proxy component has failed (e.g., process exit, no response, or key indicators exceeding limits), the system automatically triggers a restart operation. This restart process is a lightweight recovery completed within the isolated operating environment, without involving a complete restart of the host machine, and therefore will not cause any interruption to the original business processes. Through this millisecond-level fault self-healing capability, the availability of the communication proxy component is significantly improved, enabling existing equipment to have self-recovery characteristics similar to a hardware watchdog when facing transient software anomalies.

[0053] Regarding image updates, considering the large number and wide distribution of existing devices, pushing a new version to all devices carries a very high risk of batch failures. Therefore, this application adopts a canary update strategy. When the cloud-based operations and maintenance platform issues an image update command, it does not directly push the complete image to all target devices. Instead, it selects a small number of devices as preliminary verification nodes based on preset canary rules (such as by device ID hash value, geographical location, or device batch). Only after these preliminary nodes have been confirmed to be stable and have normal functional indicators after a preset observation period following the update will the push scope be gradually expanded until full coverage is achieved. This phased and rollback-capable update mechanism minimizes the risks of version iteration and avoids the catastrophic consequences of large-scale device paralysis due to defects in the new version. It should be understood that the specific proportion and verification cycle of the canary update can be flexibly configured according to the actual business tolerance. For example, the initial canary update can select 5% to 10% of devices, and after verification, it can be promoted in a step-by-step manner at the proportions of 20%, 50%, and 100%.

[0054] Furthermore, the reporting of operational logs is a crucial part of forming a closed-loop operation and maintenance system. Various operational logs generated within the isolated operating environment (including error logs, performance metrics, audit records, etc.) are collected in real time, encrypted and compressed, and uploaded to the cloud-based operation and maintenance platform via a secure channel. Encryption ensures that potentially sensitive device information contained in the logs is not leaked during transmission. Based on the massive amounts of aggregated log data, the cloud platform can perform big data analysis, root cause analysis, and predictive maintenance, thereby achieving a leap from single-point fault handling to global intelligent operation and maintenance capabilities.

[0055] For example, in the actual operation scenario of a power distribution terminal, suppose the communication proxy component triggers an uncaught exception due to parsing a malformed message, causing the process to crash and exit. Thanks to the automated operation and maintenance mechanism implemented in this embodiment, the monitoring daemon detects the process's disappearance in the next inspection cycle within 1 second, and then completes the startup and initialization of a new instance within 2 seconds. The entire process takes approximately 3 seconds. During this time, the power data acquisition and control services of the original business processes are completely unaffected; only a brief data interruption occurs on the distributed soft bus network, which the upper-layer application can smoothly transition through caching or retransmission mechanisms. In a version upgrade scenario, maintenance personnel release a new image with optimized protocol parsing efficiency. The system initially pushes this image only to 10% of the distribution terminals in the existing network. These 10% of devices run continuously for 24 hours after the update. Only after the cloud platform confirms that their average CPU load has decreased by 15%, there are no new error logs, and business functions are normal, does it automatically trigger the batch update of the remaining 90% of devices. Compared to traditional solutions where a defective new firmware version can cause a complete network outage and require manual repair of each device individually, this embodiment significantly reduces the long-term maintenance costs and security risks of existing devices after HarmonyOS upgrades through automated fault self-healing and refined gray-scale releases. This enhances the feasibility of the technical solution in industrial settings and increases user trust.

[0056] like Figure 1 As shown in the illustration, this application also provides a distributed operating system access system for existing devices. Corresponding to the method, this system aims to achieve secure access for existing devices without requiring hardware replacement through the collaborative work of functional modules. The system includes an environment adaptation module, a communication proxy module, a resource management module, and a security isolation module.

[0057] Specifically, the modules mentioned above are not static code units or development tools, but rather runtime entities deployed on existing devices or associated edge nodes. Together, they form a layered, decoupled, and top-down organic whole. For example... Figure 1 As shown, the system is logically located between the HarmonyOS ecosystem layer and the existing power equipment layer, playing a key pivotal role in connecting the two.

[0058] The environment adaptation module is used to provide an isolated operating environment on existing devices or associated edge nodes. Specifically, the environment adaptation module corresponds to... Figure 1The container / virtualization service layer, serving as the underlying resource foundation of the entire system, is responsible for dynamically allocating and allocating computing, storage, and network resources based on the host machine's hardware specifications, constructing a logical space isolated from other business areas of the host machine. This module not only supports the creation of lightweight container instances directly on existing devices but also supports the creation of virtualization instances on edge gateways communicating with existing devices, thus flexibly adapting to terminal devices with different computing power levels. By providing this standardized, isolated operating environment, the differences in underlying heterogeneous hardware are shielded from upper-layer functional components, enabling existing devices to possess the basic capability to support new distributed applications.

[0059] The communication proxy module runs in an isolated environment, converting private protocol data from existing devices into standard object model data and then connecting to the distributed soft bus network based on this data. Specifically, the communication proxy module is the core executor for protocol interoperability, integrating a lightweight protocol stack, an object model parsing component, and a soft bus proxy. During runtime, this module continuously monitors private protocol data streams from existing business processes within the power equipment layer. Through real-time processing actions such as protocol parsing, semantic mapping, and standardized encapsulation, it transforms this data into object model data conforming to the HarmonyOS ecosystem specifications and publishes it to the HarmonyOS ecosystem layer via the distributed soft bus interface. This process achieves a transparent conversion from heterogeneous device languages ​​to a unified ecosystem language, enabling existing devices to be recognized and accessed by other nodes in the distributed network, completely breaking down the information silos of traditional devices.

[0060] The resource management module is used to implement resource quota control for communication proxy components and existing business processes on existing devices in an isolated operating environment. Specifically, as the resource scheduling hub within the system, the resource management module performs fine-grained allocation and real-time monitoring of CPU computing power, memory usage, and network bandwidth within the isolated operating environment based on a preset tiered quota strategy. This module clearly distinguishes between newly added communication proxy components and existing core business processes, setting independent resource usage limits and priorities for both through control groups and other technical means. When the resource consumption of either party reaches the threshold, it automatically triggers protective actions such as rate limiting or suspension, ensuring that the operation of the communication proxy components does not crowd out the critical resources of existing business processes, and also preventing the collapse of the entire access system due to abnormalities in existing services. This achieves harmonious coexistence and stable operation of new and old services on resource-constrained existing devices.

[0061] The security isolation module is used to perform security isolation on the communication agent component and the original business processes of existing devices in an isolated operating environment. Specifically, the security isolation module constructs a defense-in-depth system, and its implemented protective measures include, but are not limited to, independent process isolation, network isolation, and data transmission encryption. During runtime, the module uses namespace technology to create mutually exclusive process spaces and file system views for the communication agent component and the original business processes, blocking unauthorized cross-process access; simultaneously, through a virtual network stack and access control rules, it prohibits direct message transmission between the two, retaining only controlled communication channels; furthermore, it performs end-to-end encryption on the interactive data between the communication agent component and the external distributed soft bus network. This multi-dimensional security isolation mechanism effectively prevents security risks introduced by accessing an open ecosystem from penetrating into core production operations, ensuring the security and compliance of the power monitoring system.

[0062] In summary, the system provided in this embodiment forms a complete runtime access architecture through the close collaboration of the environment adaptation module, communication proxy module, resource management module, and security isolation module. Each module performs its own function while cooperating with each other. The environment adaptation module lays the foundation, the communication proxy module establishes the link, the resource management module ensures stability, and the security isolation module safeguards the bottom line. Together, they achieve low-overhead, high-security access for existing devices without replacing hardware, solving the technical pain points of high transformation costs, high security risks, and poor compatibility in existing technologies.

[0063] This application also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, and the processor executes the computer program to implement the aforementioned method.

[0064] Specifically, the electronic device, as the physical entity carrying the distributed operating system access method for existing devices, is not limited to a specific chip model or bus structure in its hardware architecture. The processor can be a general-purpose central processing unit, network processor, digital signal processor, or application-specific integrated circuit, etc., which are computing units with logical operation and instruction execution capabilities; the memory can be volatile memory or non-volatile memory, used to persistently store the program code, mapping rule table, and runtime data required to implement the above access method. When the processor reads and executes the computer program in the memory, it instantiates the technical actions described in the foregoing embodiments, such as the construction of the isolated operating environment, the operation of the communication proxy component, resource quota management, and security isolation, at the physical level, transforming the abstract software process into concrete hardware behavior.

[0065] In practical applications, the specific form of this electronic device is highly flexible. It can be existing devices such as power distribution terminals and power consumption acquisition terminals, which can be locally upgraded by loading the program of this application onto the existing hardware; or it can be an edge gateway or edge computing node that communicates with existing devices, acting as a computing power proxy to perform protocol conversion and access tasks. This hardware and software combined carrier design not only provides a solid physical basis for the protection of the method patent, but also verifies the technical feasibility of this solution to achieve low-overhead access of existing devices without replacing the main hardware from an engineering implementation perspective, effectively supporting the reuse and value enhancement of existing assets in the power Internet of Things.

[0066] To more clearly illustrate the application value of the technical solution in practical industrial scenarios, this embodiment takes the HarmonyOS-based retrofitting of existing power distribution terminal equipment as an example for detailed explanation. In the construction of the power Internet of Things (IoT), a large number of operational 10kV distribution terminals undertake critical tasks of power acquisition and monitoring. These devices mostly use ARM Cortex-A7 processors with only 512MB of RAM, resulting in extremely limited hardware resources. With the promotion of the HarmonyOS ecosystem in the power industry, there is an urgent need to connect these older devices to a distributed soft bus network to achieve cross-terminal collaboration. However, limited by hardware performance and security architecture, traditional solutions often require complete device replacement, which is costly and time-consuming. The technical solution provided in this application can achieve secure and low-overhead access for such existing equipment without replacing the hardware.

[0067] Specifically, in this application scenario, an isolated runtime environment is first built on the Linux system of the power distribution terminal using LXC container technology. Considering the computing power limitations of the Cortex-A7 processor, the selected LXC container removes heavy initialization services such as systemd, retaining only minimal user-space runtime dependencies. This keeps the static memory footprint of the isolated runtime environment itself below 20MB, reserving ample space for subsequent business operations. A lightweight communication proxy component is deployed in this isolated runtime environment. This component is specifically adapted for the power distribution terminal's IEC104 proprietary communication protocol. During runtime, the communication proxy component monitors the IEC104 telemetry and tele-signaling messages output by the original business processes in real time. Its internal object model parsing component converts these messages into standard object model data conforming to the HarmonyOS specification, and then publishes them to the distributed soft bus network through a soft bus proxy. This allows upper-layer HarmonyOS applications to transparently access the real-time status of the power distribution terminal.

[0068] To ensure the absolute stability of the core business of the power distribution terminal, this embodiment implements strict resource quota control within an isolated operating environment. Utilizing the control group technology of the container engine, an independent resource control group is allocated to the communication agent component 220, with its processor computing power cap set at 30% and its running memory cap set at 128MB. This threshold setting is based on calculations using a typical load model of the power distribution terminal: under normal operating conditions, the average CPU utilization of the communication agent component is approximately 15%-20%, and its memory utilization is approximately 60MB-80MB. The set upper limits not only meet peak processing demands but also forcibly reserve at least 70% of the CPU computing power and more than 300MB of memory for existing business processes. Even when the communication agent component experiences a surge in load due to a sudden increase in data reporting, the control group mechanism will automatically trigger rate limiting to ensure that the original data acquisition and control services are not affected, completely eliminating the risk of core business lag or downtime caused by new functions.

[0069] Regarding security isolation, in response to the high standards of the power monitoring system's graded protection system, this embodiment uses namespace technology to create completely independent process spaces and file system views for the communication proxy component and the original business processes, and configures access control rules between the virtual network stacks to prohibit direct IP communication between them. Simultaneously, data transmission between the communication proxy component and the external distributed soft bus network uses the national cryptographic SM2 / SM4 algorithm to establish encrypted tunnels, ensuring the confidentiality and integrity of power-sensitive data during transmission. Even if the communication proxy component suffers an external network attack, attackers cannot penetrate the isolation boundary to access the original business processes or steal locally stored key files, effectively meeting the stringent requirements of the power industry for intrinsic security.

[0070] Through the above implementation methods, the 10kV power distribution terminal successfully achieved HarmonyOS ecosystem access, supporting functions such as remote real-time monitoring, firmware gray-scale upgrades, and cross-device linkage. Compared to traditional upgrade solutions that require replacing the entire unit or adding an independent gateway, the upgrade cost per unit in this application is reduced by more than 90%, and no power outages are required for construction, greatly improving the reuse value and operational efficiency of existing assets. It should be understood that the above descriptions of hardware models, container types, resource thresholds, and encryption algorithms are merely illustrative examples. In practical applications, these can be flexibly adjusted according to specific equipment specifications and business needs. As long as the core concepts of isolated operating environment, communication proxy, resource management, and security isolation described in this application are adopted, they all fall within the protection scope of this application.

[0071] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for accessing a distributed operating system on existing devices, characterized in that, include: Provide an isolated operating environment for existing equipment or associated edge nodes; A communication proxy component is run in the isolated operating environment. The communication proxy component converts the private protocol data of the existing devices into standard object model data, and accesses the distributed soft bus network based on the standard object model data. In the isolated operating environment, resource quota management is performed on the original business processes of the communication proxy component and the existing equipment; In the isolated operating environment, security isolation is performed on the original business processes of the communication proxy component and the existing devices.

2. The method according to claim 1, characterized in that, The step of converting the private protocol data of the existing devices into standard object model data through the communication proxy component, and accessing the distributed soft bus network based on the standard object model data, includes: The private protocol data is received through the lightweight protocol stack within the communication proxy component; The private protocol data is mapped to the standard object model data through the object model parsing component within the communication proxy component; The standard object model data is connected to the distributed soft bus network through the soft bus proxy within the communication proxy component.

3. The method according to claim 2, characterized in that, The step of mapping the private protocol data to the standard object model data through the object model parsing component within the communication proxy component includes: The private protocol data is parsed to extract multi-protocol data points, which include at least one of device status data, measurement values, and control commands. Obtain a preset object model mapping rule table, which records the correspondence between the identifiers of the multi-specification data points and the attributes, events, or services in the standard object model data; Based on the correspondence, the multi-specification data points are converted into a structured data format that conforms to the target distributed operating system specification; When the multi-specification data points are device status data or measurement values, they are mapped to attribute data or event data in the standard object model data, and timestamps and device identifiers are appended. When the multi-specification data point is a control command, it is mapped to service data in the standard object model data, and a service call request containing execution parameters and callback address is generated.

4. The method according to claim 1, characterized in that, The process of implementing resource quota control on the original service processes of the communication proxy component and the existing devices in the isolated operating environment includes: The existing business processes of the communication proxy component and the existing equipment are respectively assigned tiered quotas for processor computing power, running memory and network bandwidth; Based on the tiered quota, dynamic resource scheduling is performed on the original business processes of the communication proxy component and the existing equipment to limit the upper limit of resource usage of the original business processes of the communication proxy component and the existing equipment.

5. The method according to claim 4, characterized in that, The dynamic resource scheduling of the original service processes of the communication proxy component and the existing equipment based on the tiered quota includes: Based on the container engine's control group technology, a first resource control group is allocated to the communication proxy component, and a second resource control group is allocated to the original business processes of the existing devices. Configure a first processor computing power threshold, a first running memory threshold, and a first network bandwidth threshold in the first resource control group; configure a second processor computing power threshold, a second running memory threshold, and a second network bandwidth threshold in the second resource control group. Real-time monitoring of the resource consumption of the original business processes of the communication proxy component and the existing equipment; When the resource consumption of the communication proxy component reaches any one of the first processor computing power threshold, the first running memory threshold, or the first network bandwidth threshold, resource throttling or process suspension operations are triggered on the communication proxy component. When the resource consumption of the original business process of the existing device reaches any one of the second processor computing power threshold, the second running memory threshold, or the second network bandwidth threshold, resource throttling or process suspension operations are triggered on the original business process of the existing device.

6. The method according to claim 1, characterized in that, The process of performing security isolation on the original service processes of the communication proxy component and the existing devices in the isolated operating environment includes: Independent process isolation is performed on the original business processes of the communication proxy component and the existing equipment to prevent cross-business interference. Network isolation is performed on the original business processes of the communication proxy component and the existing devices to block unauthorized access; Encryption is performed on the end-to-end data transmitted between the communication proxy component and the distributed soft bus network.

7. The method according to claim 6, characterized in that, The step of performing independent process isolation on the original service processes of the communication proxy component and the existing devices, and performing network isolation on the original service processes of the communication proxy component and the existing devices, includes: Based on the container engine's namespace technology, a first process namespace and a first file system namespace are created for the communication proxy component, and a second process namespace and a second file system namespace are created for the original business processes of the existing devices, so that the communication proxy component and the original business processes of the existing devices can run independently within their respective process namespaces and file system namespaces. A first virtual network stack is allocated to the communication proxy component, and a second virtual network stack is allocated to the original service processes of the existing device. Configure network access control rules between the first virtual network stack and the second virtual network stack, wherein the network access control rules prohibit direct data packet transmission between the first virtual network stack and the second virtual network stack; An encrypted communication tunnel is established between the communication proxy component and the distributed soft bus network through the first virtual network stack. The encrypted communication tunnel uses a transport layer security protocol or a national cryptographic algorithm to encrypt the end-to-end transmitted data.

8. The method according to claim 1, characterized in that, The method further includes: Real-time monitoring of the health status of the isolated operating environment; When a failure is detected in the communication proxy component, the communication proxy component is automatically restarted; In response to receiving an image update command, a canary update is performed on the container image in the isolated operating environment; The operation logs of the isolated operating environment are reported to the cloud-based operation and maintenance platform.

9. A distributed operating system access system for existing devices, characterized in that, include: The environment adaptation module is used to provide an isolated operating environment on existing devices or associated edge nodes; A communication proxy module is used to run a communication proxy component in the isolated operating environment, convert the private protocol data of the existing devices into standard object model data through the communication proxy component, and access the distributed soft bus network based on the standard object model data; The resource management module is used to perform resource quota management on the original business processes of the communication proxy component and the existing equipment in the isolated operating environment; The security isolation module is used to perform security isolation on the original business processes of the communication proxy component and the existing devices in the isolated operating environment.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, and the processor executing the computer program to implement the method of any one of claims 1 to 8.

Images