Containerized isolated multi-device management system and device

Abstract

The invention relates to the technical field of equipment management, in particular to a containerized isolated multi-equipment management system and equipment. The system comprises a physical host which is used for operating main control software and issuing a standardized control intention to a container through the main control software; the containers are in one-to-one connection with specific types of communication equipment, and an independent control logic operation environment is constructed for specific external equipment; each container is an independent equipment control logic operation environment, and containerization isolation ensures that control of different equipment does not interfere with each other. The control logic of each device runs in an exclusive container of the device and is responsible for direct control communication with the device, and the container analyzes a control intention and converts the control intention into a specific instruction matched with the corresponding external device; and the received feedback data is packaged and sent back to the main control software. The problems that in the prior art, performance bottlenecks occur during equipment scale expansion, and the requirements of a modern communication network for elastic expansion, high reliability and rapid deployment are difficult to meet are solved.

Description

Technical Field

[0001] This specification relates to the field of device management technology, and in particular to a containerized isolated multi-device management system and device. Background Art

[0002] Full virtualization technology uses software to simulate hardware resources, allowing multiple virtual machines (VMs) to run independently on the same physical computer. The core concept of virtualization technology is to abstract hardware resources, allowing multiple operating systems to share the computing resources of the same physical host. Each VM runs a complete operating system (OS) and has independent memory, processor, storage, and other resources. At the core of virtualization technology is the hypervisor, which allocates physical resources to VMs. The hypervisor sits between the physical hardware and the VM operating system, responsible for virtualizing computing resources (such as CPU, memory, storage, and network) and managing the VM's lifecycle.

[0003] Virtualization technology requires each virtual machine to run a complete operating system. Each operating system consumes a certain amount of resources (such as memory and CPU), resulting in wasted resources and significant overhead. Virtual machine startup is also relatively slow because it requires loading the entire operating system. Because the hypervisor performs virtualization operations and the isolation between virtual machines is strong, virtualization overhead is relatively high, impacting virtual machine performance. The virtualization layer can become a bottleneck, especially in I / O-intensive applications. In a virtualized environment, creating, managing, migrating, and monitoring virtual machines requires complex tools and management platforms. As the number of virtual machines increases, management complexity increases exponentially. Virtual machine migration typically involves operating system-level migration, which requires ensuring the correct transfer of all resources within the virtual machine. Virtual machine migration often requires copying large amounts of disk data, which consumes significant time and bandwidth.

[0004] There is an urgent need for a multi-device management system to address the problem that in traditional solutions, once new devices are added or replaced, the control system logic often needs to be manually modified and the interface protocol redeveloped, resulting in slow system response, complex integration, high maintenance costs, and seriously limiting the communication network's ability to adapt to dynamic changes. Summary of the Invention

[0005] In order to solve the problem in the prior art that various heterogeneous communication devices have significant differences in physical form, control protocol, and operating logic, which poses a great challenge to unified management and coordinated control, the embodiments of this specification provide a containerized and isolated multi-device management system and device, which can encapsulate the software of each device into an independent image. When the system accesses the hardware device, the corresponding image is used to create a container, so as to realize a one-to-one management structure with strong scalability and strong adaptability of the container device. The main control software is run at the same time, and the main control software is directly connected to each control software, decoupled from the hardware device, and uses a unified message format to publish control information to each container and receive status information of each device. The control software of each device runs in an independent container, and the system resources are more reasonably allocated and utilized. Through containerization technology, the system can be quickly deployed, expanded and adjusted to better adapt to dynamically changing needs.

[0006] In order to solve the above technical problems, the specific technical solutions of this specification are as follows:

[0007] On the one hand, an embodiment of this specification provides a containerized isolated multi-device management system, the system including a physical host and a plurality of containers;

[0008] The physical host is used to run the main control software, and the main control software issues standardized control intentions to the container;

[0009] The container is used for one-to-one connection with a specific type of communication device. Each container has an independent control logic operating environment built for a specific external device. The control logic is used to control communication with the external device.

[0010] The container is used to parse the control intent according to the control logic and convert it into specific instructions adapted to the corresponding external device; and encapsulate the data fed back by the external device, convert it into a standardized format and send it back to the main control software.

[0011] Furthermore, each container constructs an independent operating environment for the control logic of the external device, further including:

[0012] The container also includes a namespace and a control group;

[0013] The namespace is used to isolate the system resources of each container. The container runs in its own namespace and has an independent process tree, network interface and file system.

[0014] The control group is used to limit and allocate system resources used by the container.

[0015] Furthermore, the container is used to analyze the control intention according to the control logic and further includes:

[0016] The master software and the container adopt a standardized message format to transfer control information and device status;

[0017] The message analysis module in the container converts the standardized message sent by the master software into specific instructions adapted to specific devices, and encapsulates the data returned by the external device into a standardized format and uploads it to the master software.

[0018] Further, the physical host further comprises a shared container engine and an operating system,

[0019] The shared container engine is used to control the operation of multiple containers on the same operating system, and perform container creation, start and stop operations;

[0020] The operating system runs on the physical host and is used to receive operation instructions from an operator and convert them into the standardized control intent.

[0021] Further, encapsulating the received data feedback from the external device further comprises,

[0022] The physical host obtains external device running state information from each container through a standardized protocol, and performs data processing, display and storage.

[0023] Further, each container further comprises,

[0024] An input / output module is used to complete the reception, analysis and sending of the control intent.

[0025] Further, the container for analyzing the control intent according to the control logic further comprises,

[0026] The communication between the container and the physical host is through a network interface or a bridged network connection, and each container is assigned a virtual IP address using a port mapping function;

[0027] A UDP communication channel is established between the physical host and the container, and the physical host communicates with the container through the virtual IP address and a specified port using UDP.

[0028] On the other hand, the embodiments of the present specification also provide a computer device, comprising a memory, a processor, and a computer program stored in the memory, and the processor executes the computer program to realize the above-mentioned system.

[0029] Finally, the embodiments of the present specification also provide a computer storage medium having a computer program stored thereon, and the computer program is run by the processor of the computer device to execute the above-mentioned system.

[0030] By using the embodiments of this specification, a communication network multi-device management system based on containerization technology with strong adaptability and scalability is provided by constructing a system of physical hosts and several containers, wherein the physical host is used to run the main control software and publish standardized control intentions to the container through the main control software; and the container is generally used for one-to-one connection of a specific type of communication device, and each container builds an independent control logic operating environment for a specific external device, wherein the control logic is used to control communication with the external device; each container is an independent device control logic operating environment, and containerization isolation ensures that the controls of different devices do not interfere with each other. The control logic of each device runs in its own dedicated container and is responsible for direct control communication with the device. The container is used to parse the control intention according to the control logic and convert it into specific instructions adapted to the corresponding external device; and encapsulate the data received from the external device feedback, convert it into a standardized format and send it back to the main control software. This solves the problem that the performance bottleneck occurs when the device scale is expanded in the existing technology, and it is difficult to meet the requirements of modern communication networks for elastic expansion, high reliability and rapid deployment. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 The figure shows a schematic diagram of an implementation system of a containerized isolated multi-device management system according to an embodiment of this specification;

[0033] Figure 2 The figure shows a schematic diagram of a containerized isolated multi-device management system according to an embodiment of this specification;

[0034] Figure 3 The process of constructing a new container according to the embodiment of this specification is shown;

[0035] Figure 4 The figure shows a schematic diagram of a multi-device management system based on containerized isolation technology according to an embodiment of this specification;

[0036] Figure 5 Shown is a schematic diagram of the logical composition of the container according to an embodiment of this specification;

[0037] Figure 6 The figure shows a schematic diagram of the structure of the computer device according to the embodiment of this specification.

[0038]

Description of the accompanying drawings

[0039] 101. Physical host;

[0040] 102. Container;

[0041] 103. External equipment;

[0042] 802. Computer equipment;

[0043] 804. Processing equipment;

[0044] 806. Storage resources;

[0045] 808, driving mechanism;

[0046] 810, input / output module;

[0047] 812. Input devices;

[0048] 814. Output device;

[0049] 816. Presentation equipment;

[0050] 818. Graphical User Interface;

[0051] 820, network interface;

[0052] 822, communication link;

[0053] 824. Communication bus. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without making any creative efforts are within the scope of protection of this specification.

[0055] It should be noted that the terms "first," "second," and the like in the description and claims of this specification and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate so that the embodiments of this specification described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having," as well as any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, apparatus, product, or device comprising a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to these processes, methods, products, or devices.

[0056] like Figure 1 The diagram shows a system diagram for implementing a containerized, isolated, multi-device management system according to an embodiment of this specification. The system may include a physical host 101 and a container 102. A communication connection is established between the physical host 101 and the container 102, enabling data exchange. The physical host 101 can input control intents into the container 102, which then controls various external devices 103 based on the control intents. The container 102 also receives data from the external devices 103, converts it into a standardized format, and sends it back to the physical host 101.

[0057] In the embodiments of this specification, the container 102 is a lightweight virtualization technology that allows an application and all its dependencies (such as operating system libraries and configuration files) to be packaged in a container image to ensure that the application can run consistently in different environments. It provides isolation through operating system-level virtualization, so that multiple containers can share the kernel of the host operating system, while each container can have its own independent operating environment. This approach is more efficient and lightweight than traditional hardware virtualization technologies (such as virtual machines). The image is a static definition of a container, which contains all the contents of the application and its operating environment. The image will be loaded when the container starts to form a container instance. The image is read-only, but the container will have a writable layer at runtime to store the container's runtime data.

[0058] In an optional embodiment, device communication standardization and universal data bus technology. The core is to adopt a unified data encapsulation format and communication interface specification as a data exchange "channel" between various devices in the system. Regardless of the specific implementation of the device, the communication must follow the unified protocol. This mechanism effectively isolates device differences and improves the plug-and-play capability of device access. In the multi-device management system involved in this specification, different devices need to operate collaboratively under the same control platform. If the traditional point-to-point adaptation mode is still used, the complexity of system integration and subsequent maintenance costs will be greatly increased. Therefore, with the help of a unified communication protocol, combined with a structured message mechanism, encapsulation and parsing based on a unified message header, data field and terminator are realized between devices, which not only reduces the difficulty of integration, but also improves the flexibility and stability of the control system when facing multiple platforms, multiple device accesses, and multi-task switching.

[0059] It should be noted that Figure 1 What is shown is only one application environment provided by the present disclosure. In actual applications, other application environments may also be included, which are not limited in the embodiments of this specification.

[0060] In order to solve the problems existing in the prior art, the embodiments of this specification provide a containerized isolated multi-device management system. Figure 2The figure shows a flow chart of a containerized isolated multi-device management system provided by an embodiment of this specification. The structure of the containerized isolated multi-device management system is described in this figure. Figure 2 As shown, the system includes a physical host 101 and several containers 102;

[0061] The physical host 101 is used to run the main control software, and the main control software issues standardized control intentions to the container 102;

[0062] The container 102 is used for one-to-one connection with a specific type of communication device. Each container 102 has an independent control logic operating environment built for a specific external device 103. The control logic is used to control communication with the external device 103.

[0063] The container 102 is used to parse the control intent according to the control logic and convert it into specific instructions adapted to the corresponding external device 103; and encapsulate the data fed back by the external device 103, convert it into a standardized format and send it back to the main control software.

[0064] By using the embodiments of this specification, a communication network multi-device management system based on containerization technology with strong adaptability and scalability is provided by constructing a system of physical hosts and several containers, wherein the physical host is used to run the main control software and publish standardized control intentions to the container through the main control software; and the container is generally used for one-to-one connection of a specific type of communication device, and each container builds an independent control logic operating environment for a specific external device, wherein the control logic is used to control communication with the external device; each container is an independent device control logic operating environment, and containerization isolation ensures that the controls of different devices do not interfere with each other. The control logic of each device runs in its own dedicated container and is responsible for direct control communication with the device. The container is used to parse the control intention according to the control logic and convert it into specific instructions adapted to the corresponding external device; and encapsulate the data received from the external device feedback, convert it into a standardized format and send it back to the main control software. This solves the problem that the performance bottleneck occurs when the device scale is expanded in the existing technology, and it is difficult to meet the requirements of modern communication networks for elastic expansion, high reliability and rapid deployment. Each device's software is encapsulated as a separate image. When the system connects to a hardware device, the corresponding image is used to create a container, enabling a highly scalable and adaptable management architecture with one-to-one correspondence between containers and devices. The master control software runs concurrently, directly communicating with each control software, decoupled from the hardware devices. It uses a unified message format to publish control information to each container and receive status information from each device. Each device's control software runs in an independent container, ensuring more efficient allocation and utilization of system resources. Containerization technology enables rapid system deployment, expansion, and adjustment, making it more adaptable to dynamically changing needs.

[0065] In another embodiment of the present specification, a multi-device management system based on containerized isolation technology can flexibly build a container cluster containing the control software of each hardware device for multiple scenarios and multiple tasks. The main control software uniformly processes the device status information and issues control instructions, which is highly adaptable to different application scenarios, device types and scenario scales. A unified communication message format is constructed and uniformly formulated based on the control information of each device. The control software of each device is mirrored to achieve a one-to-one correspondence between the device and the container, and a new container is created for each new device. New device types are revised based on the existing messages, thereby realizing an architecture that adapts to a management model of multiple and large-scale devices, which has the characteristics of strong scalability. The main control software is responsible for direct interaction between the human and the machine, and the operator does not need to understand the specific operation of each device. The main control software visualizes the status information of each device in the interface, reducing the cognitive burden of the device operator and making human-computer interaction intelligent. The main control software generates control tasks based on user operations or scheduling strategies, and encapsulates them into instruction data packets according to the predefined message format and sends them to the target container. After receiving the command, the container's internal parsing module translates the standardized message into the device's proprietary control commands and sends the command through the device's physical interface (such as a serial port, TCP interface, network port, or GPIO). The communication device executes the corresponding action and, within a specified timeframe, reports the execution status or result data via the same link. The device feedback is first received and initially parsed by the container, then repackaged into the system's internal unified status message format and transmitted back to the master control platform. The master control software uses this status information to update the front-end visualization interface, update the device status cache, and adjust the next task strategy. Throughout operation, the container management module within the master control platform continuously monitors the operational status of each container, including communication heartbeats, CPU usage, memory changes, and port connectivity. If a container exhibits an abnormal response (such as no response, resource leaks, or task failures), the system immediately triggers the container's self-recovery mechanism, automatically restarting, rolling back, and reassigning tasks to ensure uninterrupted control flow. Deployment Platform: The master control software platform is deployed on the central control host and network connectivity with various communication devices is configured. The main control platform integrates task scheduling module, communication instruction generation module, container management module and data display module to provide unified interface support for subsequent equipment management and control.

[0066] According to one embodiment of the present specification, each container constructs an independent operating environment for the control logic of the external device, further comprising:

[0067] The container 102 also includes a namespace and a control group;

[0068] The namespace is used to isolate the system resources of each container. The container runs in its own namespace and has an independent process tree, network interface and file system.

[0069] The control group is used to limit and allocate system resources used by the container.

[0070] In one embodiment of the present specification, in order to solve the problems of poor scalability, high maintenance cost and lack of intelligence in traditional point-to-point adaptation solutions, an independent operating environment for a multi-device management system is constructed through containerized isolation technology. The specific implementation method is as follows: an independent operating environment is constructed for the control logic of external devices in each container 102, and the container 102 includes a namespace and a control group. The namespace is based on operating system-level virtualization technology to isolate the system resources of each container (such as process ID, network interface, file system and host name), so that the container runs in its own namespace and has an independent process tree and network configuration, thereby completely eliminating the static binding defect of "one device and one interface" in traditional point-to-point adaptation. Through the isolation mechanism of the namespace, the control logic of different devices does not need to rely on the deep coupling of private protocol parsing, but runs independently as a container unit. When a new device is added, only a new container needs to be deployed, avoiding the exponential growth of the connection path and the repeated development of the adaptation code.

[0071] Furthermore, the control group dynamically allocates and limits the CPU, memory, and storage I / O resources of the container to ensure that a single container does not over-occupy host resources. Compared to the system stability issues caused by device resource competition in traditional solutions, this specification automatically avoids resource conflicts between multiple devices through resource quota management of the control group. For example, a higher CPU usage limit is allocated to high-priority device containers, while low-priority devices are limited to a preset memory quota, thereby optimizing overall system performance. In addition, this embodiment replaces the private protocol conversion mechanism in traditional point-to-point adaptation with a unified communication message format (including device ID, instruction type, and parameter fields). The main control software sends standardized control messages to each container, and the parsing module in the container converts them into device-specific instructions, while encapsulating the device feedback data into a standard format and sending it back. This design abstracts the universal communication interface, so that changes in device protocols only require adjusting the parsing logic of the corresponding container, without modifying the main control system or other containers, significantly reducing maintenance costs. For example, when the communication protocol of a certain type of device is upgraded, only the image file of the device container needs to be updated, while the rest of the system maintains the original logic, ensuring the stability of the overall call chain. Through the above technical solution, this embodiment effectively solves the defects of limited scalability, complex maintenance and insufficient intelligence in traditional point-to-point adaptation solutions, and realizes efficient, flexible and stable operation of the multi-device management system.

[0072] According to one embodiment of the present specification, the container 102 is used to parse the control intention according to the control logic, further comprising:

[0073] The control information and device status are transmitted between the main control software and the container using a standardized message format;

[0074] The message parsing module in the container 102 converts the standardized message sent by the main control software into specific instructions adapted to a specific device, and encapsulates the data returned by the external device 103 into a standardized format and uploads it to the main control software.

[0075] In one embodiment of this specification, Figure 4 As shown, the multi-device management system based on containerized isolation technology realizes the decoupling of device control logic and management logic through container technology, forming a modular and distributed control architecture. Figure 1 As shown, the system operation platform consists of a physical host, main control software and multiple containers, in which the physical host deploys the main control software and several containers bound to external devices one by one, and each container independently runs the control logic of a specific device. As the core management module, the main control software is responsible for receiving external input or preset control strategies, generating standardized control messages and distributing them to the corresponding containers. At the same time, it summarizes the device operation status information reported by each container through standardized protocols, and performs unified processing, visualization and storage. Each container serves as an independent control unit. The control software inside it contains an input and output module for receiving standardized control messages issued by the main control software, parsing and converting them into the specific instruction format of the adapter device (such as private protocol instructions), and sending them to the external device through a communication line (such as a serial port, Ethernet interface) to execute the operation; at the same time, the container re-encapsulates the feedback data returned by the device (such as status information, execution results) into a standardized message format and transmits it back to the main control software. Communication between the master control software and the container is based on a predefined standardized message format, consisting of a device ID, a command type, and a parameter field. For example, when the master control software needs to adjust a router's routing table, the device ID in the message identifies the target router, the command type field defines the operation as a routing configuration, and the parameter field carries the specific routing rules. This design enables modularization and decoupling of device control. Adding a new device requires only deploying a container image containing its control logic and expanding the communication field based on the standardized message format, without modifying the core logic of the master control software. This significantly improves the system's scalability and maintenance efficiency, adapting to dynamic and ever-changing device management needs.

[0076] According to one embodiment of this specification, the physical host further includes a shared container engine and an operating system.

[0077] The shared container engine is used to control multiple containers to run on the same operating system and perform container creation, start and stop operations;

[0078] The operating system runs on the physical host and is used to receive operation instructions from operators and convert them into the standardized control intentions.

[0079] In one embodiment of the present specification, the containerized isolated multi-device management system works in conjunction with the operating system through a shared container engine on the physical host to achieve unified management and resource isolation of containers. The physical host runs an operating system, which is responsible for receiving the operator's control instructions and converting them into standardized control intentions (such as device start and stop, parameter adjustment, etc.), which are then handed over to the shared container engine for execution. As the core management component of the container, the shared container engine creates, starts and stops multiple containers in the same operating system environment based on operating system-level virtualization technology, ensuring that each container runs independently and does not interfere with each other. Containers achieve resource isolation and allocation through namespace and control group technology: the namespace divides an independent system resource view (including process ID, network interface, file system and host name) for each container, so that the container has an exclusive process tree and network configuration, completely isolating the control logic between devices; the control group dynamically limits the container's CPU usage, memory quota and storage I / O resources to prevent a single container from excessively occupying host resources and ensuring the overall stability of the system. In addition, containers use layered file system technology to separate the base layer image (read-only) from the runtime layer (writable). Each container loads the base image and creates an independent file system view at startup. File modifications during runtime only affect its own writable layer, avoiding any impact on the host machine or other containers. Through this mechanism, containers, based on lightweight virtualization, achieve efficient resource utilization and flexible deployment management, while providing a secure and isolated operating environment for multi-device control systems, ensuring the independence of device control logic and the maintainability of the entire system.

[0080] In another embodiment of this specification, Figure 5 The figure below illustrates the logical composition of containers. A container is an isolated environment for running applications. Each container contains the application and its dependencies, ensuring independent operation. Multiple containers run on the same operating system through a shared container engine. The container engine, as the core management component of containers, is responsible for operations such as creating, starting, and stopping containers. The operating system runs directly on the physical machine, providing basic system resource support. This architecture allows each container to operate independently, achieving efficient resource utilization and application isolation.

[0081] According to one embodiment of this specification, Figure 3 As shown, the container is used for one-to-one connection of a specific type of communication device further comprising:

[0082] Step 301: Encapsulate each device software into an independent image;

[0083] Step 302: When the system accesses the hardware device, it uses the corresponding image to create a container.

[0084] Specifically, container deployment involves packaging the control logic of each communication device into an image, including all of the device's dependencies (such as communication protocols, algorithm libraries, and hardware drivers). This enables a highly scalable and adaptable management architecture with a one-to-one correspondence between containers and devices. When a container is started, a specific network port is allocated for communication with the main control system. The container image also includes a mapping module for translating standardized instruction formats into device-specific protocols, enabling automatic adaptation of a unified instruction structure across multiple devices.

[0085] According to one embodiment of the present specification, encapsulating the received data fed back by the external device further includes:

[0086] The physical host obtains the operating status information of the external devices from each container through a standardized protocol, and performs data processing, display and storage.

[0087] Specifically, standardized messages are implemented to define a unified control and status message format between the main control software and the container. The message fields include device ID, instruction type, parameters, status code, etc., to ensure that different types of communication devices can be controlled through unified management logic.

[0088] According to one embodiment of the present specification, each container further comprises:

[0089] The input and output module is used to receive, analyze and send control intentions.

[0090] The communication between the container and the physical host is connected through a network interface or a bridge network, and each container is assigned a virtual IP address using the port mapping function;

[0091] A UDP communication channel is established between the physical host and the container, and the physical host performs UDP communication with the container through the virtual IP address and the specified port.

[0092] Specifically, the containerized isolated multi-device management system realizes efficient interaction of device control through input and output modules and standardized communication mechanisms. Each container is equipped with an input and output module, which is responsible for receiving the control intention issued by the main control software, parsing the standardized message and converting it into device-specific instructions, and sending it to the corresponding external device through the host machine's physical interface (such as serial port, Ethernet or TCP / IP interface) to perform operations, and at the same time re-encapsulating the feedback data returned by the device into a standard format for transmission back. The communication between the container and the physical host is achieved through a bridge network. The host machine assigns an independent virtual IP address and port mapping function to each container to form a virtual communication link. An asynchronous communication channel is established between the main control software and the container based on the UDP protocol. The host machine sends control messages through the container's virtual IP address and designated port. The container receives instructions and responds through the listening port to ensure real-time and low latency communication. Device access rights are strictly restricted through the mapping relationship between the container and the physical interface. For example, serial port devices are only allowed to be bound to specific containers to avoid cross-container interference and enhance system security and isolation. In addition, the system adopts a unified message format specification, defining core fields such as device ID, instruction type and parameter field. The main control software and each container exchange data based on this format, shielding the differences in device protocols. For example, the message sent by the main control software accurately locates the target container through the device ID. The parsing module in the container dynamically generates the control logic of the adapter device according to the instruction type, and the parameter field carries the specific operation content (such as adjusting the router bandwidth threshold). Through the above design, the system not only realizes the standardized and modular communication of device control and status feedback, but also significantly reduces the problems of protocol inconsistency and high link coupling in traditional point-to-point adaptation. When adding new devices, it is only necessary to expand the message field and deploy the container image, without the need to reconstruct the main control logic, thereby improving the flexibility and maintainability of the system.

[0093] In one embodiment of the present specification, the multi-device management system based on containerized isolation technology realizes efficient communication between the main control software and the container through a unified message format. The unified message format includes three parts: a message header, a data field and a message tail: the message header includes a data header (2 bytes to identify the start of the message), a timestamp (4 bytes for event sorting), a data length (4 bytes to identify the total length of the data field), an instruction type (1 byte to distinguish between categories such as control instructions and status reports), a device ID (2 bytes to identify the target container), a source / target IP address (4 bytes each for network addressing) and a reserved extension field (4 bytes); the data field is dynamically filled according to the message type, for example, the control instruction includes the control target, parameter value and priority, and the status report encapsulates the operation status code, measurement value and alarm flag. All fields use standardized data types to ensure universal parsing of the main control system; the message tail includes a check code (2 bytes with optional CRC check) and a terminator (2 bytes with fixed value to identify the end). During operation, the container regularly collects device data, encapsulates the raw data into standard status messages through control logic, and sends them to the main control software via the bridge network. After parsing, the main control software visualizes the device status and parameters. When the user issues instructions through the graphical interface (such as parameter setting or device start and stop), the main control software calls the message encapsulation module, automatically fills in the fields based on the template to generate a control message, and sends it to the target container; the parsing module in the container maps the message into a device-proprietary protocol instruction and issues it for execution, while re-encapsulating the device feedback data into a standard format and sending it back, forming a "issue-execution-feedback" closed loop. For example, when the main control software sends an instruction to adjust the router bandwidth, the device ID field locates the target container, and the parameter value field carries the specific threshold. After parsing, the container generates and executes device-specific instructions, and finally encapsulates the actual bandwidth status into a standard message feedback. This mechanism shields device protocol differences by standardizing the intermediate layer communication language, significantly improving the compatibility of heterogeneous devices and reducing interface development and maintenance costs.

[0094] According to one embodiment of the present specification, the system further comprises a main control software platform deployed on the central management server for instruction generation, container management, and status feedback processing;

[0095] Multiple container instances, each corresponding to a type of communication device, encapsulating device control logic and protocol parsing modules;

[0096] Bridge network communication mechanism, the container and the host interact through the virtual IP address and UDP protocol. The message format includes the task type, device ID and control parameters;

[0097] Physical interface communication link: The container is connected to external devices through serial ports, TCP and other interfaces, and device access rights are limited to the dedicated container;

[0098] The container operation and maintenance module monitors the container status in real time and performs abnormal recovery to ensure system stability;

[0099] Dynamic expansion capability: when adding new devices, hot plugging is achieved by deploying container instances and extending message fields, without modifying the main control logic.

[0100] Specifically, this system builds a multi-device management architecture based on containerized isolation technology. The master control platform collaborates with container instances to achieve efficient device control and communication. The master control platform, deployed on a central management server, serves as a unified dispatch center, responsible for receiving user commands, generating control messages, managing containers, and processing device status feedback. Each type of communication device (such as routers, switches, and base stations) corresponds to a dedicated container instance, which encapsulates device control logic, protocol parsing modules, and status processing services, ensuring isolation and logical decoupling of device operating environments. Containers communicate with the host via a bridged network. Each container is assigned a unique virtual IP address and port mapping functionality. The master control platform and containers interact using the UDP protocol, with communication messages following a uniformly defined format (including fields such as task type, device ID, and control parameters). The master control platform generates standardized control messages based on user commands and sends them to the target container. The container parses the messages and converts them into device-specific protocol instructions, which are then sent to the device for execution via physical interfaces (such as serial ports, TCP, and GPIO). Device status feedback is converted by the container into a unified format and transmitted back to the master control platform for visualization and dynamic policy adjustments. The system supports hot-swapping and dynamic expansion of devices. Adding new devices requires only deploying the corresponding container instance and expanding the message fields, without modifying the main control logic. The container operation and maintenance module monitors the container's operating status (CPU load, memory usage, heartbeat communication, etc.) in real time and automatically restarts or resets the status in the event of anomalies, ensuring stable system operation in complex environments.

[0101] According to one embodiment of the present specification, the system further includes:

[0102] The main control platform is used to generate standardized control messages and manage container instances. The messages contain device ID, instruction type and parameters;

[0103] Independent container instance, each device corresponds to a container, encapsulating the device control logic and protocol analysis module, and connecting to the main control platform through a virtual network bridge;

[0104] Unified message protocol to achieve UDP-based communication between the control platform and the container. The container parses the message and converts it into device-specific instructions for execution.

[0105] Closed-loop feedback mechanism: The container normalizes device status data and encapsulates it into standard messages, returning them to the main control platform, supporting visual display and dynamic policy adjustment.

[0106] Dynamic expansion capabilities enable rapid access by deploying container instances when adding new devices, without having to modify the core logic of the main control platform.

[0107] Specifically, this system builds a multi-device management architecture based on containerized isolation technology. Through the collaborative work of the master control platform and container instances, it solves the problems of high control logic coupling, high adaptation cost and complex maintenance in traditional multi-device communication systems. Taking router control as an example, the control logic of each router runs in an independent container. The container is connected to the communication network of the master control platform through virtual network bridging, and opens a specific UDP port to receive standardized instructions issued by the master control system. Based on scheduling requirements (such as routing path adjustment, bandwidth limitation policy issuance, etc.), the master control platform encapsulates instruction information (including target device ID, instruction type and parameters) in a unified message protocol and sends it to the target container through the container network. After the control program inside the container parses the standardized message, it converts it into a private command format supported by the router, and sends it to the router through the physical interface for execution.

[0108] After the router completes the instruction, its status information (such as real-time traffic load, link health status, etc.) is fed back to the container through the communication link. The parsing module in the container normalizes the data, repackages it into a standard status message, and returns it to the main control platform. The main control system performs visual display, threshold alarms or dynamic policy adjustments based on this, forming a "distribution-execution-feedback" closed-loop control. Compared with traditional full virtualization solutions (such as deploying virtual machine instances for each router), this system significantly reduces resource consumption and startup delays through containerization technology, avoiding the waste of resources caused by virtual machines relying on a complete operating system. At the same time, the communication mechanism based on standardized message protocols replaces traditional shared disks or customized message channels, reduces interface coupling, improves status feedback efficiency and control closed-loop speed, and is suitable for flexible deployment and efficient management of large-scale router nodes.

[0109] In another embodiment of the present specification, efficient collaborative management of distributed base stations is achieved based on containerized isolation technology, and the problems of complex protocol parsing, high maintenance costs, and difficulty in multi-device collaboration in traditional point-to-point adaptation solutions are solved through the collaboration between the main control platform and the container instance. For each independently deployed communication base station, the main control platform creates a dedicated container instance to encapsulate the control logic, parameter scheduling module, and protocol adapter of the base station. The container communicates with the host network and listens to the designated port to receive standardized control instructions issued by the main control system. The main control platform generates a standardized message containing the target device ID, instruction type, and parameters according to the scheduling strategy (such as spectrum negotiation, power co-integration, etc.), and sends it to the target base station container through the container network. The container converts the standard protocol field into a dedicated control command supported by the base station based on the mapping table, and sends it to the base station for execution through the physical interface.

[0110] After the base station performs the task, the running state and configuration result are fed back to the container, the container processes the data into a structured form, and then encapsulates the data into a standard state message and returns it to the main control platform. The main control system dynamically updates the signal coverage map, detects the interference of the adjacent area, and adjusts the power distribution according to the standard state message, and further issues an optimization strategy to realize cross-base station adaptive cooperation. For example, in the spectrum resource allocation scenario among multiple base stations, the main control platform coordinates the containers through the standardized message, the containers generate base station-specific instructions to adjust the transmission power after analysis, and finally the actual spectrum occupancy rate is fed back to the platform to form a closed-loop control. Compared with the traditional point-to-point adaptive solution (which needs to hard-code protocol analysis logic for each type of base station), the system significantly reduces the development amount of adaptation when adding new equipment by isolating containers and using a unified communication protocol, avoids field conflicts and protocol incompatibility problems, and supports multi-base station standardized state synchronization and task-level resource scheduling, improves cooperation efficiency and reduces maintenance complexity.

[0111] As Figure 6 FIG. 8 shows a diagram of a computer device 802 in accordance with an embodiment of the present specification. The device in the present specification can be a computer device in the embodiment, which executes the method of the present specification. The computer device 802 can include one or more processing devices 804, such as one or more central processing units (CPUs), each of which can implement one or more hardware threads. The computer device 802 can also include any storage resources 806 for storing any kind of information, such as code, settings, data, etc. Without limitation, for example, the storage resources 806 can include any one or a combination of the following: any type of RAM, any type of ROM, a flash memory device, a hard disk, an optical disk, etc. More generally, any storage resource can store information using any technology. Further, any storage resource can provide volatile or non-volatile retention of information. Further, any storage resource can represent a fixed or removable component of the computer device 802. In one case, the computer device 802 can perform any operation of the associated instructions when the processing device 804 executes the associated instructions stored in any storage resource or combination of storage resources. The computer device 802 also includes one or more drive mechanisms 808 for interacting with any storage resource, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0112] The computer device 802 may also include an input / output module 810 (I / O) for receiving various inputs (via input devices 812) and for providing various outputs (via output devices 814). A specific output mechanism may include a presentation device 816 and an associated graphical user interface (GUI) 818. In other embodiments, the input / output module 810 (I / O), input devices 812, and output devices 814 may not be included, and the computer device 802 may simply be a computer device in a network. The computer device 802 may also include one or more network interfaces 820 for exchanging data with other devices via one or more communication links 822. One or more communication buses 824 couple the components described above together.

[0113] The communication link 822 may be implemented in any manner, for example, via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, etc., or any combination thereof. The communication link 822 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0114] It should be understood that in the various embodiments of this specification, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this specification.

[0115] It should also be understood that in the embodiments of this specification, the term "and / or" is merely a description of the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, the character " / " in this specification generally indicates that the associated objects are in an "or" relationship.

[0116] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in this specification can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the composition and steps of each example according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this specification.

[0117] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0118] In the several embodiments provided in this specification, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, or can be an electrical, mechanical or other form of connection.

[0119] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of this specification.

[0120] In addition, the functional units in the various embodiments of this specification may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0121] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this specification is essentially or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of this specification. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0122] Specific embodiments are used in this specification to illustrate the principles and implementation methods of this specification. The description of the above embodiments is only used to help understand the methods and core ideas of this specification. At the same time, for those skilled in the art, based on the ideas of this specification, there will be changes in the specific implementation methods and application scope. In summary, the contents of this specification should not be understood as limiting this specification.

Claims

1. A containerized isolated multi-device management system, characterized in that: The system includes a physical host and several containers; The physical host is used to run the main control software, and the main control software issues standardized control intentions to the container; The container is used for one-to-one connection with a specific type of communication device. Each container has an independent control logic operating environment built for a specific external device. The control logic is used to control communication with the external device. The container is used to parse the control intent according to the control logic and convert it into specific instructions adapted to the corresponding external device; and encapsulate the data fed back by the external device, convert it into a standardized format and send it back to the main control software.

2. The containerized isolated multi-device management system according to claim 1, characterized in that: Each of the containers further includes an independent operating environment for the control logic of the external device. The container also includes a namespace and a control group; The namespace is used to isolate the system resources of each container. The container runs in its own namespace and has an independent process tree, network interface and file system. The control group is used to limit and allocate system resources used by the container.

3. The containerized isolated multi-device management system according to claim 1, characterized in that: The container is used to parse the control intention according to the control logic and further includes: The control information and device status are transmitted between the main control software and the container using a standardized message format; The message parsing module in the container converts the standardized message sent by the main control software into specific instructions adapted to a specific device, and encapsulates the data returned by the external device into a standardized format and uploads it to the main control software.

4. The containerized isolated multi-device management system according to claim 1, characterized in that: The physical host also includes a shared container engine and an operating system. The shared container engine is used to control multiple containers to run on the same operating system and perform container creation, start and stop operations; The operating system runs on the physical host and is used to receive operation instructions from operators and convert them into the standardized control intentions.

5. The containerized isolated multi-device management system according to claim 1, characterized in that: The encapsulation of the data received from the external device further includes: The physical host obtains the operating status information of the external devices from each container through a standardized protocol, and performs data processing, display and storage.

6. The containerized isolated multi-device management system according to claim 1, characterized in that: Each of said containers further comprises, The input and output module is used to receive, analyze and send control intentions.

7. The containerized isolated multi-device management system according to claim 1, characterized in that: The container is used to parse the control intention according to the control logic and further includes: The communication between the container and the physical host is connected through a network interface or a bridge network, and each container is assigned a virtual IP address using the port mapping function; A UDP communication channel is established between the physical host and the container, and the physical host performs UDP communication with the container through the virtual IP address and the specified port.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that: When the processor executes the computer program, the system according to any one of claims 1 to 7 is implemented.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the system according to any one of claims 1 to 7 is implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the system according to any one of claims 1 to 7 is implemented.

Images