Power concentrator application system based on service function for container partitioning

Abstract

The application provides a power concentrator application system based on service function container partitioning, comprising a host computer and a containerization architecture; the containerization architecture comprises a protocol stack container and a terminal management container, a network management container, a database container, a display container, an uplink container and a downlink container which are respectively in communication connection with the protocol stack container; each container is in communication connection with the host computer and an external system through an lxcbr0 virtual bridge; the protocol stack container is configured as a centralized routing node, receives data from other containers, re-encapsulates the data according to a preset protocol after analysis and processing, and then forwards the data to a target container; the uplink container is a communication node with the external system; and the downlink container is a communication node with a power meter node. The application divides the application system into seven containers according to services, realizes fault isolation and independent upgrading, and combines a multi-level keep-alive strategy and a hybrid database to improve system reliability, maintainability and data processing capacity.

Description

Technical Field

[0001] This invention relates to the field of power equipment technology, and in particular to a power concentrator application system that partitions containers based on business functions. Background Technology

[0002] Traditional power concentrators use a monolithic architecture for their firmware, meaning all functions are compiled into a single firmware. This leads to direct function calls between modules without isolation. When a single point of failure occurs, the crash of any module can cause the entire system to crash, resulting in the interruption of the entire data collection service and power quality monitoring. Furthermore, during the upgrade process of monolithic architecture applications, all functional modules need to be deployed synchronously, which can cause service interruptions. There is also the risk that the failure of one component will cause the global upgrade to fail. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a power concentrator application system that partitions containers based on business functions, so as to achieve high reliability and business continuity of the power concentrator.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0005] A power concentrator application system that uses container partitioning based on business functions includes a host machine and a containerized architecture. The containerized architecture includes a protocol stack container and terminal management container, network management container, database container, display container, uplink container, and downlink container that are respectively connected to the protocol stack container. Each container in the containerized architecture communicates with the host machine and external systems through the lxcbr0 virtual bridge.

[0006] The uplink container, as a communication node between the power concentrator and the external system, is configured to connect to the external system, including the master station system and the host computer. It receives control command data and / or parameter setting command data issued by the master station system and the host computer and forwards them to the protocol stack container, and receives data sent by the protocol stack container and forwards it to the external system.

[0007] The protocol stack container, as a centralized routing node in the containerized architecture, is configured to receive data from other containers, parse and process it, re-encapsulate it according to a preset protocol, and then forward it to the target container.

[0008] The downlink container, as a communication node between the power concentrator and the meter nodes, is configured to connect to each meter node, receive instruction data obtained by the protocol stack container after processing the control instruction data and / or parameter setting instruction data, encapsulate the data according to the communication protocol of the target meter node after parsing and sending it to the target meter node, and receive data sent by any meter node and forward it to the protocol stack container.

[0009] The terminal management container, as the hardware management node of the power concentrator, is configured as the master watchdog process with a hardware watchdog, which collects health votes from other containers and executes the final watchdog decision.

[0010] The network management container, as the network interface management node of the power concentrator, is configured to establish communication connections between each container in the containerized architecture and the external system using the host machine's network physical devices.

[0011] Optionally, the database container, serving as a data center node of the power concentrator, is configured to employ a hybrid deployment strategy of PostgreSQL and Redis databases. Each container within the containerized architecture accesses the PostgreSQL database via a fixed IP connection to store persistent data, including historical data, time logs, configuration information, and statistical analysis data, in the PostgreSQL database. Each container within the containerized architecture caches real-time data in the Redis database.

[0012] Optionally, the display container, as a human-machine interaction node of the power concentrator, is configured to have two interaction modes: management web access and local LCD display.

[0013] For web access, the display container receives web requests from the external system by deploying an HTTPD service, queries the PostgreSQL database based on the web requests to obtain target persistent data, and simultaneously obtains status data from each container within the containerized architecture in real time. The target persistent data and the status data are then assembled to generate dynamic page response data.

[0014] Specifically, for local LCD display, the display container responds to key events by reading target real-time data from the Redis database and obtaining relevant data from each container within the containerized architecture to drive the LCD screen of the power concentrator to update the displayed content.

[0015] Optionally, containers within the containerized architecture interact with each other via UDS.

[0016] Optionally, the host machine is configured to have a container health detection mechanism;

[0017] The container health detection mechanism includes:

[0018] The status of each container within the containerized architecture is periodically polled and detected, and the status of the container is determined based on the container's running status and the status of the processes inside the container.

[0019] Based on the status of each container obtained in the current polling, perform corresponding processing on abnormal containers;

[0020] Record and store the entire process log;

[0021] The correspondence between the state of the container and the processing includes:

[0022] If the container is in a stopped state or the service inside the container is unresponsive, the corresponding action is to restart the container.

[0023] If the container's status indicates that the process inside the container has crashed, the corresponding action is to restart the service.

[0024] If the container's status is "container resources exceeded", the corresponding action is resource adjustment.

[0025] If the container's status is "container business function abnormal", the corresponding action is "business recovery".

[0026] Optionally, each container within the containerized architecture is equipped with an application health detection mechanism;

[0027] The application health detection mechanism includes:

[0028] Applications within each container in the containerized architecture periodically perform thread working status self-checks and report the health votes obtained from the self-checks to the protocol stack container through an application timer.

[0029] The protocol stack container forwards the received health votes to the terminal management container via routing.

[0030] The terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision.

[0031] Optionally, the terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision, including:

[0032] The terminal management container determines, based on the health votes of each container, whether the number of active processes in the containerized architecture is greater than or equal to half of the total number of processes in the containerized architecture.

[0033] If so, the decision to continue feeding the dog is executed, and the system continues to run;

[0034] If not, implement the decision to suspend dog feeding and wait for the watchdog timeout to occur before the system restarts and resumes operation.

[0035] Optionally, the host machine and each container within the containerized architecture communicate with each other via a shared directory mount.

[0036] The terminal management container is also configured to directly access the host machine's hardware device files via the shared directory, and to handle hardware events including system time synchronization, RTC clock calibration, battery ADC monitoring, power management, LED control, and GPIO hardware status detection.

[0037] Optionally, the protocol stack container includes a protocol parser, a protocol adapter, and a routing decision-maker; the routing decision-maker is connected to each of the other containers in the containerized architecture, except for the protocol stack container.

[0038] Optionally, the uplink container includes a TCP client, a TCP server, and a data processor; the data processor is connected to the TCP client, the TCP server, and the protocol parser in the protocol stack container; the TCP client is also connected to the master station system; and the TCP server is also connected to the host computer.

[0039] The beneficial effects of this invention are as follows: Through a business function container partitioning design, this invention enables independent operation and decoupling of each business module in the power concentrator application system, reducing the impact of single failures and improving modularity and scalability. Relying on the lxcbr0 virtual bridge and UDS communication, it ensures efficient and accurate communication between containers, between containers and external systems, and between containers and meter nodes. A multi-level system keep-alive strategy combining a dual health detection mechanism and watchdog timer decision-making significantly improves system reliability and fault tolerance. A hybrid storage system using PostgreSQL and Redis balances data persistence and real-time access performance. Dual-mode human-machine interaction adapts to different operating scenarios. Terminal management containers centrally manage hardware, reducing control complexity. Ultimately, this invention achieves high reliability and business continuity assurance for power concentrators, better adapting to the development needs of power concentrators. Attached Figure Description

[0040] Figure 1 A schematic diagram of the basic architecture of a power concentrator application system based on business functions for container partitioning, provided in an embodiment of the present invention;

[0041] Figure 2 This is an exemplary diagram of collaborative communication according to the present invention;

[0042] Figure 3This is a schematic diagram illustrating the working principle of inter-container communication in a specific embodiment of the present invention;

[0043] Figure 4 This is a schematic diagram illustrating the internal configuration and business functions of an exemplary protocol stack container according to the present invention.

[0044] Figure 5 This is a schematic diagram illustrating the internal configuration and working principle of an exemplary upstream container according to the present invention;

[0045] Figure 6 This is a schematic diagram illustrating the working principle of an exemplary upstream and downstream container collaborative communication according to the present invention.

[0046] Figure 7 This is a schematic diagram illustrating the working principle of an exemplary terminal management container according to the present invention;

[0047] Figure 8 This is a schematic diagram illustrating the working principle of an exemplary network management container according to the present invention;

[0048] Figure 9 This is a schematic diagram illustrating the working principle of an exemplary database container according to the present invention;

[0049] Figure 10 This is a schematic diagram illustrating the working principle of an exemplary display container according to the present invention;

[0050] Figure 11 This is a schematic diagram illustrating the principle of the host machine's container health detection mechanism in a specific embodiment of the present invention;

[0051] Figure 12 This is a schematic diagram illustrating the principle of the health detection mechanism within the container in a specific embodiment of the present invention. Detailed Implementation

[0052] To explain in detail the technical principles, specific implementable solutions, possible application scenarios, and achievable objectives and effects of the present invention, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. It is understood that the embodiments described herein and the embodiments shown in the accompanying drawings are only used to more clearly illustrate the technical solutions of the present invention, and are therefore only examples intended to explain the present invention, and should not be construed as limiting the present invention. It should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein.

[0053] Explanation of technical terms involved in this invention:

[0054] lxcbr0 Virtual Bridge: The Linux kernel virtual bridge (software switch) that comes with LXC (Linux Containers) container technology by default is automatically created and managed by the lxc-net service. It adopts a NAT architecture and integrates dnsmasq to provide DHCP and DNS services. It is used to provide isolated private network environments and external network connectivity for containers on the same host machine.

[0055] UDS: Unix Domain Socket (UDS) is an inter-process communication (IPC) mechanism that is compatible with the API of network sockets (TCP / UDP). It does not go through the network protocol stack and has the characteristics of being faster and more secure than TCP / UDP local communication; it is used for inter-container communication.

[0056] Please see Figures 1 to 10 This invention provides a power concentrator application system that partitions containers based on business functions.

[0057] like Figure 1 As shown in the figure, an embodiment of the present invention provides a power concentrator application system based on business functions for container partitioning, including a host OS and a containerized architecture.

[0058] The containerized architecture includes seven business function modules: protocol stack container, terminal management container, network management container, database container, display container, uplink container, and downlink container.

[0059] In the containerized architecture, the protocol stack container acts as the core server, communicating with the terminal management container, network management container, database container, display container, uplink container, and downlink container, respectively, and is responsible for routing and forwarding all messages between containers. Each container within the containerized architecture provides TCP / IP communication capabilities through the lxcbr0 virtual bridge, enabling communication with the host machine and external systems. The external systems include the main station system and the host computer. The host computer includes, but is not limited to, PCs, mobile terminals, and smart terminals.

[0060] In some specific implementations, communication within the application system is interconnected via a UDS (Unix Domain Socket) and a lxcbr0 virtual bridge. The UDS handles high-performance communication between different container processes, while the lxcbr0 virtual bridge connects processes within a container to external networks. An exemplary diagram of collaborative communication is shown below. Figure 2 As shown.

[0061] As one specific implementation, the containers use a TCP communication mechanism based on Unix Domain Sockets. For example... Figure 3 As shown, for routine resource and data access between containers, the protocol stack container acts as a Unix Socket TCP server, uniformly receiving and forwarding data sent by each container as a client; the target container is distinguished by data encoding identifiers, and centralized routing is achieved by relying on a unified internal protocol, effectively reducing communication complexity.

[0062] In this embodiment, the containerized architecture, which is divided into containerized partitions according to different business functions, has each container configured with a corresponding dedicated business function:

[0063] 1. Protocol stack container

[0064] As a centralized routing node in a containerized architecture, the protocol stack container is configured to receive data from other containers, parse and process it, repackage it according to a preset protocol, and then forward it to the target container.

[0065] In some specific implementations, the protocol stack container is configured to include: a protocol parser, a protocol adapter, and a routing decision-maker; the routing decision-maker is connected to each of the other containers in the containerized architecture besides the protocol stack container.

[0066] Here, the protocol stack container serves as the core of the power concentrator's communication protocol processing, specifically responsible for the parsing and encapsulation of various power industry standards, including DLMS and 376.1, enabling conversion and adaptation between different protocols. Simultaneously, it acts as the hub for communication between containers, serving as the UDS server (referred to as the Socket server), uniformly receiving and processing connection requests from all internal containers, forwarding them to the routing decision-maker for message routing, data forwarding, and event broadcasting, ensuring the efficiency and reliability of inter-container communication, and providing unified communication scheduling and protocol processing services for the entire system. An exemplary configuration and business function diagram of the protocol stack container is shown below. Figure 4 As shown.

[0067] 2. Upward container

[0068] As a communication node between the power concentrator and external systems, the uplink container is configured to communicate with external systems (including the master station system and the host computer). After receiving control command data and / or parameter setting command data issued by the master station system / host computer, it forwards them to the protocol stack container, and after receiving data sent by the protocol stack container, it forwards them to the external system.

[0069] In some specific embodiments, the uplink container is configured with a TCP client, a TCP server, and a data processor. The data processor is connected to the TCP client, the TCP server, and the protocol parser in the protocol stack container; the TCP client is also connected to the main station system; and the TCP server is also connected to the host computer. An exemplary internal configuration and working principle of the uplink container is as follows: Figure 5 As shown.

[0070] Here, the uplink container functions as both a TCP client actively connecting to the main system and a TCP server accepting connections from PCs and other host devices. When the main system / host computer issues control commands or parameter setting commands, the uplink container first receives this raw external data through the TCP client / TCP server, and then forwards it to the data processor. The data processor then sends the raw data to the protocol stack container for protocol parsing and routing decisions. The protocol stack container parses and processes the command data sent by the uplink container, repackages it into formatted command data, and forwards it to the target container to enable data reading, remote control, and other control functions for other containers. When the uplink container actively connects to the main system through a TCP client, its data processor receives the data sent by the protocol stack container and then forwards it to the main system via the TCP client to achieve proactive data push.

[0071] 3. Downstream container

[0072] As a communication node between the power concentrator and the meter nodes, the downlink container is configured to connect to each meter node, receive control command data and / or parameter setting command data issued by the protocol stack container to the external system, process the command data, and then encapsulate it according to the communication protocol of the target meter node (such as DLMS / COSEM, 645 protocol, etc.) and send it to the target meter node. It also receives data sent by any meter node and forwards it to the protocol stack container, which then reports it to the external system.

[0073] In some specific implementations, the downlink container sends instructions to specific meter nodes via the host machine's serial communication module (including but not limited to carrier, low-power wireless, RS485, and other communication methods). The meter executes the corresponding operation based on the instruction and returns response data. The downlink container receives and parses the response data sent by the meter, then forwards the response data to the protocol stack container. The protocol stack container routes the response data back to the uplink container, which ultimately reports the response data to the master station system or host computer that issued the instruction.

[0074] In this embodiment, communication between the uplink container and the downlink container is the core service of the power concentrator. The communication process forms a complete closed loop: external system command → uplink container → protocol stack container → downlink container → meter node → downlink container → protocol stack container → uplink container → external system response. This design enables unified management and secure control of the data flow. The protocol stack container, as the system's intelligent routing center, is responsible for protocol conversion, data encapsulation, and routing forwarding for cross-container communication; the uplink container focuses on external network communication; and the downlink container focuses on meter device communication. Each container has a clearly defined business function and operates collaboratively. An exemplary working principle of collaborative communication between uplink and downlink containers is illustrated below. Figure 6 As shown.

[0075] 4. Terminal Management Container

[0076] As the hardware management node of the power concentrator, the terminal management container is configured as the master watchdog process with a hardware watchdog, which collects health votes from other containers and executes the final watchdog decision.

[0077] In some specific implementations, the core responsibilities of the terminal management container include not only the management of the hardware watchdog timer but also the management of the physical hardware in the power concentrator. For the latter, it achieves precise control of the physical hardware by directly accessing the host machine's hardware device files (such as / dev / drv_wdg, / dev / rtc0, / sys / class / gpio, etc.), implementing measures including but not limited to: system time synchronization and RTC clock control, backup battery voltage monitoring (ADC), power management, LED control, and GPIO hardware status detection; and synchronizing the status to other containers via an event mechanism to ensure system hardware reliability and time consistency. An exemplary terminal management container working principle is illustrated below. Figure 7 As shown.

[0078] 5. Network Management Container

[0079] As the network interface management node of the power concentrator, the network management container is configured to establish communication connections between each container in the containerized architecture and the external system using the host's network physical devices.

[0080] In some specific implementations, the network management container is responsible for the unified management of all network interfaces in the power concentrator, including but not limited to: detecting the insertion and removal status of wired network cards (such as Ethernet cards and Wi-Fi cards), controlling the dial-up connection of 4G modules, and virtualizing devices such as Bluetooth and infrared as network card interfaces for unified management. Specifically, when the 4G module successfully dials up, the network management container will immediately notify the uplink container to initiate the establishment of a TCP connection with the main station system. Simultaneously, as a data transceiver hub, it performs preliminary processing on the data received by virtualized peripherals (Bluetooth, infrared, etc.) and forwards it to the protocol stack container, which performs unified protocol parsing and routing distribution to achieve standardized access and communication collaboration for various peripherals. In addition, the network management container also acts as a NAT gateway in the entire system, meaning it can manage the routing of Ethernet and 4G network cards within its own container and enable data forwarding. All containers access the internet through the lxcbr0 host network card. An exemplary working principle of the network management container is illustrated below. Figure 8 As shown.

[0081] 6. Database container

[0082] As a data center node of the power concentrator, the database container is configured with a hybrid deployment strategy using PostgreSQL and Redis databases to achieve centralized storage of critical shared data. Each container within the containerized architecture directly accesses the PostgreSQL database via a fixed IP connection to store persistent data, including but not limited to historical data, time logs, configuration information, and statistical analysis data, in the PostgreSQL database; each container within the containerized architecture caches real-time data in the Redis database. An exemplary working principle of the database container is illustrated below. Figure 9 As shown.

[0083] 7. Display container

[0084] As the human-machine interface node of the power concentrator, the display container is configured to manage both web access and local LCD display interaction. For web access, the display container receives web requests from external systems via an deployed HTTPD service, queries the PostgreSQL database to obtain target persistent data based on the web request, and simultaneously retrieves real-time status data from various containers within the containerized architecture. The target persistent data and the status data are then assembled to generate dynamic page response data. For local LCD display, the display container responds to button events, reads target real-time data from the Redis database, and retrieves relevant data from various containers within the containerized architecture to drive the power concentrator's LCD screen to update the displayed content. This achieves dual human-machine interface functionality for remote web monitoring and local LCD display. An exemplary working principle of the display container is illustrated below. Figure 10 As shown.

[0085] This embodiment provides a power concentrator application system based on business function container partitioning. It is divided into seven core containers according to application responsibilities, achieving business function isolation and independent upgrades (upgrade failures are limited to a single container and can be recovered through a fast rollback mechanism), improving reliability, technical flexibility, and maintainability. UDS is used to achieve efficient communication between containers, eliminating middleware dependencies and simplifying modifications; the protocol stack container is central, facilitating unified protocol management. The database uses a hybrid deployment of PostgreSQL and Redis, balancing persistent data storage with real-time high-speed access, resulting in a stable and efficient overall architecture. This system provides a solid technical foundation for the intelligent, automated, and interactive development of smart grids.

[0086] Please see Figures 11 to 12 Another embodiment of the present invention is a further extension based on the above embodiments, and the lifecycle management of the specific system is described in detail.

[0087] The power concentrator application system provided in this embodiment, which partitions containers based on business functions, is configured with a multi-level keep-alive strategy:

[0088] (1) Container health detection mechanism deployed on the host machine;

[0089] (2) Application health detection mechanism deployed in each container.

[0090] The core decision-making principle of the multi-level survival strategy is:

[0091] 1) If a process restart can solve the problem, do not restart the container.

[0092] 2) If a container restart can solve the problem, a system restart is not necessary.

[0093] 3) A system restart performed by a hardware watchdog is the last resort and should be used in extreme cases.

[0094] The multi-level survival strategy described above will be explained in detail below.

[0095] (1) Container health detection mechanism deployed on the host machine

[0096] The host machine's container health detection mechanism includes:

[0097] The status of each container within the containerized architecture is periodically polled and detected. The status of the container is determined based on the read container running status and the internal process status.

[0098] Based on the status of each container obtained in the current polling, perform corresponding processing on abnormal containers;

[0099] Record and store logs for the entire process from status reading to exception handling.

[0100] In some specific implementations, such as Figure 11 As shown, the relationship between the state of the exception container and its corresponding handling method is as follows:

[0101] If the container is in a stopped state or the service inside the container is unresponsive, then restart the container.

[0102] If the container's status indicates that the process inside the container has crashed, then restart the service;

[0103] If the container's status is "container resources exceeded", then resources will be adjusted.

[0104] If the container's status indicates that the container's business function is abnormal, then the business function will be restored.

[0105] (2) Application health monitoring mechanism deployed in each container

[0106] The health detection mechanism within the container includes:

[0107] Applications within each container in the containerized architecture periodically perform thread working status self-checks and report the health votes obtained from the self-checks to the protocol stack container through application timers (such as the event_base timer task).

[0108] The protocol stack container forwards the received health votes to the terminal management container via routing.

[0109] The terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision.

[0110] In some specific implementations, such as Figure 12As shown, the terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision, specifically including:

[0111] The terminal management container determines, based on the health votes of each container, whether the number of active processes in the containerized architecture is greater than or equal to half of the total number of processes in the containerized architecture.

[0112] If so, the decision to continue feeding the dog is executed, and the system continues to run;

[0113] If not, implement the decision to suspend dog feeding and wait for the watchdog timeout to occur before the system restarts and resumes operation.

[0114] The health monitoring mechanism within the container is implemented based on a hardware watchdog. The terminal management container acts as the voting decision-maker, while applications within other containers act as voting initiators. They periodically self-check the working status of their internal threads and report their health status to the terminal management container via timers. The terminal management container then aggregates the voting results from all containers and controls the watchdog's feeding operation. Here, the hardware watchdog serves as the last level of system protection, only stopping feeding and triggering a system-level restart when multiple processes experience deadlocks, livelocks, business logic freezes, or when the terminal management container detects a hardware anomaly. Furthermore, the hardware watchdog feeding operation is executed by the terminal management container, satisfying both the real-time requirements of hardware monitoring and its highest hardware privilege attribute, perfectly aligning with the container's single responsibility design.

[0115] The application system in this embodiment adopts a multi-level keep-alive strategy that combines multi-level systemd daemons with a hardware watchdog for application lifecycle health voting decisions. This solution overcomes the shortcomings of traditional systemd daemons, which can only monitor process survival but cannot identify and handle application deadlocks, livelocks, and business freezes. It achieves three-level keep-alive protection at the process level, business level, and hardware level, which can efficiently manage the container lifecycle, accurately identify various anomalies, and significantly improve system reliability and stability.

[0116] In summary, the power concentrator application system based on business functions for container partitioning provided by this invention has the following technical effects:

[0117] (1) The system is containerized and partitioned according to different application responsibilities. Based on the core business of the power concentrator, it is divided into seven core containers and allocated differentiated hardware resources. This design achieves fault domain isolation through functional isolation, avoiding the spread of single container anomalies to the entire system; it supports independent upgrades and maintenance of each container, reduces the complexity of version management, and significantly improves reliability, security and maintainability while ensuring the integrity of system functions.

[0118] (2) Compared with the existing inter-container communication scheme using MQTT, this system uses Unix Domain Socket to implement inter-container communication, which is more efficient, has no additional middleware dependencies, and does not require code architecture reconstruction when migrating from non-containerized deployment to containerized deployment. The protocol stack container serves as the server to uniformly carry inter-container communication, and the internal protocol parsing is centrally processed. The star topology is simple, easy to maintain, and facilitates the standardization of internal protocols.

[0119] (3) The system adopts a multi-level keep-alive strategy that combines a multi-level systemd daemon process with a hardware watchdog that makes lifecycle health voting decisions. Compared with existing technologies, the hardware watchdog in this system does not require a dedicated watchdog feeding container, avoiding over-design and waste of system resources. The multi-level keep-alive strategy can comprehensively monitor the application's running status, achieving three levels of keep-alive protection: process level, business level, and hardware level, ensuring that the system has stable and reliable anomaly recovery capabilities.

[0120] (4) The database container adopts a hybrid deployment architecture of PostgreSQL and Redis: PostgreSQL is responsible for the reliable storage and complex query of persistent data such as event logs and configuration parameters; Redis provides high-speed read and write of high-frequency real-time data such as power data and device status, providing stable and efficient data support for the real-time status display of the display container.

[0121] Although preferred embodiments of the invention have been described, those skilled in the art, upon understanding the basic inventive concept, can make other changes and modifications to the embodiments. Therefore, the appended claims are intended to cover the preferred embodiments and all equivalent modifications falling within the scope of protection defined by the claims and their equivalents. Clearly, those skilled in the art can make various alterations and variations to the invention without departing from its spirit and scope. If such modifications and variations fall within the scope of protection defined by the claims and their equivalents, the invention also intends to include them.

[0122] It should be noted that any reference signs placed between parentheses in the claims should not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. In a unit claim enumerating several means, several of these means may be embodied by the same item of hardware.

[0123] In this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "multiple" means two or more, unless otherwise explicitly specified. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone.

[0124] In this invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," and "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in this invention according to the specific circumstances.

[0125] In this specification, the use of terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refers to a specific feature, structure, material, or characteristic described in connection with that embodiment or example, which is included in at least one embodiment or example of the present invention. The illustrative expressions of the above terms in this specification should not be construed as necessarily referring to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0126] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A power concentrator application system that partitions containers based on business functions, characterized in that, The system includes a host machine and a containerized architecture. The containerized architecture includes a protocol stack container, and terminal management containers, network management containers, database containers, display containers, uplink containers, and downlink containers that are respectively connected to the protocol stack container. Each container in the containerized architecture communicates with the host machine and external systems through an lxcbr0 virtual bridge. The containers in the containerized architecture interact with each other through UDS. The uplink container, as a communication node between the power concentrator and the external system, is configured to connect to the external system, including the master station system and the host computer. It receives control command data and / or parameter setting command data issued by the master station system and the host computer and forwards them to the protocol stack container, and receives data sent by the protocol stack container and forwards it to the external system. The protocol stack container, as a centralized routing node in the containerized architecture, is configured to receive data from other containers, parse and process it, re-encapsulate it according to a preset protocol, and then forward it to the target container. The downlink container, as a communication node between the power concentrator and the meter nodes, is configured to connect to each meter node, receive instruction data obtained by the protocol stack container after processing the control instruction data and / or parameter setting instruction data, encapsulate the data according to the communication protocol of the target meter node after parsing and sending it to the target meter node, and receive data sent by any meter node and forward it to the protocol stack container. The terminal management container, as the hardware management node of the power concentrator, is configured as the master watchdog process with a hardware watchdog, which collects health votes from other containers and executes the final watchdog decision. The network management container, serving as the network interface management node of the power concentrator, is configured to establish communication connections between each container within the containerized architecture and the external system using the host machine's network physical devices. The database container, serving as the data center node of the power concentrator, is configured to employ a hybrid deployment strategy using PostgreSQL and Redis databases. Each container within the containerized architecture accesses the PostgreSQL database via a fixed IP connection to store persistent data, including historical data, time logs, configuration information, and statistical analysis data, in the PostgreSQL database. Each container within the containerized architecture caches real-time data in the Redis database.

2. The power concentrator application system for container partitioning based on business functions as described in claim 1, characterized in that, The display container, as the human-machine interaction node of the power concentrator, is configured to have two interaction modes: management web access and local LCD display. For web access, the display container receives web requests from the external system by deploying an HTTPD service, queries the PostgreSQL database based on the web requests to obtain target persistent data, and simultaneously obtains status data from each container within the containerized architecture in real time. The target persistent data and the status data are then assembled to generate dynamic page response data. Specifically, for local LCD display, the display container responds to key events by reading target real-time data from the Redis database and obtaining relevant data from each container within the containerized architecture to drive the LCD screen of the power concentrator to update the displayed content.

3. The power concentrator application system for container partitioning based on business functions as described in claim 1, characterized in that, The host machine is configured to have a container health detection mechanism; The container health detection mechanism includes: The status of each container within the containerized architecture is periodically polled and detected, and the status of the container is determined based on the container's running status and the status of the processes inside the container. Based on the status of each container obtained in the current polling, perform corresponding processing on abnormal containers; Record and store the entire process log; The correspondence between the state of the container and the processing includes: If the container is in a stopped state or the service inside the container is unresponsive, the corresponding action is to restart the container. If the container's status indicates that the process inside the container has crashed, the corresponding action is to restart the service. If the container's status is "container resources exceeded", the corresponding action is resource adjustment. If the container's status is "container business function abnormal", the corresponding action is "business recovery".

4. The power concentrator application system for container partitioning based on business functions as described in claim 3, characterized in that, Each container within the containerized architecture is equipped with an application health detection mechanism. The application health detection mechanism includes: Applications within each container in the containerized architecture periodically perform thread working status self-checks and report the health votes obtained from the self-checks to the protocol stack container through an application timer. The protocol stack container forwards the received health votes to the terminal management container via routing. The terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision.

5. The power concentrator application system for container partitioning based on business functions as described in claim 4, characterized in that, The terminal management container makes a comprehensive judgment based on the health votes reported by each container and executes the corresponding dog-feeding decision, including: The terminal management container determines, based on the health votes of each container, whether the number of active processes in the containerized architecture is greater than or equal to half of the total number of processes in the containerized architecture. If so, the decision to continue feeding the dog is executed, and the system continues to run; If not, implement the decision to suspend dog feeding and wait for the watchdog timeout to occur before the system restarts and resumes operation.

6. The power concentrator application system for container partitioning based on business functions as described in claim 1, characterized in that, The host machine and each container in the containerized architecture communicate with each other through a shared directory mount; The terminal management container is also configured to directly access the host machine's hardware device files via the shared directory, and to handle hardware events including system time synchronization, RTC clock calibration, battery ADC monitoring, power management, LED control, and GPIO hardware status detection.

7. The power concentrator application system for container partitioning based on business functions as described in claim 1, characterized in that, The protocol stack container includes a protocol parser, a protocol adapter, and a routing decision-maker; the routing decision-maker is connected to each of the other containers in the containerized architecture, except for the protocol stack container.

8. The power concentrator application system for container partitioning based on business functions as described in claim 7, characterized in that, The uplink container includes a TCP client, a TCP server, and a data processor; the data processor is connected to the TCP client, the TCP server, and the protocol parser in the protocol stack container; the TCP client is also connected to the master station system; and the TCP server is also connected to the host computer.

Images