Substation monitoring system data interaction method, system, device and program product

Abstract

The application is suitable for the field of power system automation technology, and provides a substation monitoring system data interaction method, system, device and program product. The method comprises: by the business application program as a client, interacting with the server through network connection with the logical network address; by the high-availability cluster, monitoring the business health state of the server through the health check mechanism; when it is determined that the business health state of the master server is abnormal, switching the logical network address from the master server to the standby server to maintain data interaction. Wherein, the business health state is quantified by calculating the comprehensive health score, which is generated based on the original business indicators such as the update timestamp of the key data point and the business processing queue length, and can accurately identify the implicit failure such as service death. The application replaces the tight coupling of dynamic library dependence by the loose coupling of network interaction, and combines the intelligent high-availability mechanism deeply bound with the business, realizes the decoupling of the client and the server, reduces the deployment cost, and at the same time, through the automatic switching of the fault transparent to the client, guarantees the continuity of the data interaction and the reliability of the whole system.

Description

Technical Field

[0001] This application belongs to the field of power system automation technology, and in particular relates to a data interaction method, system, equipment and program product for a substation monitoring system. Background Technology

[0002] Currently, next-generation substation monitoring systems generally adopt a basic platform or application architecture to enhance system flexibility. In this architecture, third-party developed business applications implement their business functions by interacting with the basic platform. In existing technologies, this data interaction typically relies on proprietary dynamic link libraries provided by the basic platform manufacturer. The application must integrate this dynamic link library and retrieve data by calling library functions.

[0003] However, this tightly coupled integration approach based on dynamic libraries has significant drawbacks, such as: high adaptation and deployment complexity; deep coupling between the application and the dynamic library requires strict consistency between them in terms of compiler version, operating system underlying libraries, etc.; any environmental incompatibility may lead to program malfunction, increasing deployment and maintenance costs; dynamic libraries are usually bound to specific programming languages ​​or technology platforms, limiting the use of other technology stacks. Therefore, existing technologies urgently need a more efficient and reliable data interaction solution that can solve the above problems. Summary of the Invention

[0004] This application provides a data interaction method, system, device, and program product for a substation monitoring system, aiming to solve the technical problems in the prior art, such as complex adaptation and deployment and limited technology selection caused by the tight coupling and interaction between the application program and the basic platform through dynamic link libraries.

[0005] In a first aspect, embodiments of this application provide a data interaction method for a substation monitoring system. The method is applied to a high-availability cluster including a primary server and a backup server. The basic platform of the substation monitoring system is deployed as a server on the primary and backup servers. The high-availability cluster manages an external logical network address. The method includes: The business application, acting as a client, initiates data interaction with the server by establishing a network communication connection with the logical network address. The high-availability cluster monitors the service health status of the server through a health check mechanism. When it is determined that the business health status of the primary server is abnormal, the logical network address is switched from the primary server to the backup server in order to maintain data interaction between the client and the server.

[0006] In one possible implementation of the first aspect, monitoring the business health status of the server through a health check mechanism includes: Periodically obtain at least one original business metric from the server; Based on the at least one original business indicator, a comprehensive health score is calculated to quantify the server's operational status. Based on the comprehensive health score, it is determined whether the business health status is abnormal.

[0007] In one possible implementation of the first aspect, the original business metrics include the update timestamps of key data points and the current length of the business processing queue; The calculation of a comprehensive health score based on the at least one original business indicator to quantify the server's operational status includes: Calculate the data freshness metric based on the update timestamp; Calculate the processing queue load metric based on the current length of the business processing queue; The data freshness metric and the processing queue load metric are weighted and fused to obtain the comprehensive health score.

[0008] In one possible implementation of the first aspect, determining whether the business health status is abnormal based on the comprehensive health score includes: When the overall health score is lower than the preset health threshold, the count value of the fault tolerance counter is increased; When the count value of the fault tolerance counter reaches the preset upper limit of the number of consecutive degradations, the business health status is determined to be abnormal.

[0009] In one possible implementation of the first aspect, the method further includes: Record the historical time series of the comprehensive health score; Based on the historical time series analysis, the trend of the comprehensive health score is analyzed to predict the risk of abnormal business health status of the server. When the risk of an abnormal business health status on the server exceeds a preset risk threshold, the business health status is determined to be abnormal.

[0010] In one possible implementation of the first aspect, the method further includes: Periodically assess the network communication quality between the client and the server, and / or assess the service load status of the server; Based on the network communication quality and / or the service load status, dynamically adjust the heartbeat detection interval and / or connection timeout threshold used to maintain the network communication connection.

[0011] In one possible implementation of the first aspect, in the network communication connection, the client and the server communicate according to a predefined application layer data interaction protocol; the application layer data interaction protocol adopts an application protocol data unit message structure including: a protocol header and an application service data unit; the protocol header includes a service identifier field; The method further includes: The server and / or client identify high-priority service messages based on the service identifier field, and place the high-priority service messages at the head of the data message queue used for caching service messages for priority processing.

[0012] Secondly, embodiments of this application provide a data interaction system for a substation monitoring system, the system comprising: A high-availability cluster consisting of a primary server and a backup server, wherein a substation monitoring system platform is deployed on the high-availability cluster as a server, and the high-availability cluster is configured as follows: Manage a logical network address that is exposed to the outside world; The health status of the server is monitored through a health check mechanism. When it is determined that the business health status of the primary server is abnormal, the logical network address is switched from the primary server to the backup server in order to maintain data interaction between the client and the server.

[0013] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the substation monitoring system data interaction method described in any one of the first aspects above.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the substation monitoring system data interaction method described in any one of the first aspects above.

[0015] Fifthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to execute the substation monitoring system data interaction method described in any one of the first aspects.

[0016] This application's embodiments decouple the client and server by transforming tightly coupled dynamic library dependencies into loosely coupled network protocol interactions. Client applications only need to support standard network communication to connect, without needing to concern themselves with the server's underlying technical implementation and environmental details. This reduces system integration and deployment costs and breaks down technology stack lock-in. By employing a high-availability cluster composed of primary and backup servers and providing a unified logical network address, automatic failover to the server is achieved. This failover process is transparent to the client; when the primary server fails, the client can automatically reconnect to the backup server taking over the service, ensuring continuous data interaction and improving overall system reliability. By introducing a health check mechanism deeply integrated with business logic, the system can monitor the server's business health status, rather than simply the process liveness status.

[0017] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a schematic diagram of the architecture of a data interaction system for a substation monitoring system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a data interaction method for a substation monitoring system provided in an embodiment of this application; Figure 3 This is a data interaction signaling timing diagram provided in an embodiment of this application; Figure 4 This is a schematic diagram of the application protocol data unit structure provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the control word in the protocol header provided in the embodiments of this application; Figure 6 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] This application provides a data interaction method and system for a substation monitoring system. In one specific implementation, the method and system are based on a client / server architecture, decoupling the basic platform of the substation monitoring system from the business applications, and ensuring the continuity and reliability of data interaction through an intelligent high-availability mechanism deeply bound to the business status.

[0027] like Figure 1 As shown in the embodiments of this application, the data interaction system includes a high-availability cluster and a business application acting as a client. The high-availability cluster consists of at least one primary server and one backup server. Both the primary and backup servers are deployed with a substation monitoring system basic platform service as the server-side, and a high-availability management module for implementing high-availability functions. The high-availability management module, for example, can be implemented using software such as Keepalived. It manages an external logical network address based on the Virtual Router Redundancy Protocol (VRRP), which in one specific implementation can be a Virtual IP Address (VIP). Under normal operating conditions, the primary server, with higher priority, holds this logical network address and provides services externally. The business application, acting as a client, always directs its network connection requests to this logical network address, rather than the physical network address of the primary or backup server, thereby decoupling from the underlying physical servers.

[0028] The term "external" here refers to the business application (client), where the logical network address serves as a unified service access point, shielding the details of the underlying physical server.

[0029] Reference Figure 2 The flowchart shown illustrates the data interaction method provided in this application embodiment, and its overall process may include the following steps.

[0030] S201, the business application acting as the client initiates data interaction with the server by establishing a network communication connection with the logical network address.

[0031] The logical network address refers to a network access address that is transparent to client applications and not bound to any specific physical server hardware. This address is managed centrally by the high-availability cluster and can dynamically switch between servers. Its specific implementation may include, but is not limited to, virtual IP (VIP) addresses or service domain names registered in the Domain Name System (DNS).

[0032] In this embodiment of the application, the business application, acting as a client, establishes a network communication connection with the logical network address and initiates data interaction with the basic platform service, which acts as a server.

[0033] S202 is a high-availability cluster that monitors the business health status of the server through a health check mechanism.

[0034] High availability clusters refer to server clusters consisting of at least one primary server and one backup server, designed to provide continuous and uninterrupted service through redundancy and failover mechanisms.

[0035] Business health status refers to a comprehensive assessment of the server's internal business logic processing capabilities, as opposed to simply checking physical conditions such as network connectivity or process existence. It focuses on deeper operational aspects, such as whether data is updated in a timely manner and whether there is a backlog of tasks.

[0036] In this embodiment, the high-availability cluster continuously monitors the business health status of the servers (i.e., basic platform services) running on the currently active master server through its built-in health check mechanism. The health check mechanism determines whether the business health status of the servers is abnormal.

[0037] S203: When it is determined that the business health status of the primary server is abnormal, the logical network address is switched from the primary server to the backup server in order to maintain data interaction between the client and the server.

[0038] In this embodiment, the health check mechanism determines whether the server's business health status is abnormal. If the determination is negative, meaning the business health status is normal, periodic monitoring continues. If the determination is positive, indicating an abnormality in the primary server's business health status, the high availability management module triggers a failover process, seamlessly switching the logical network address from the primary server to the backup server. Since the business application connects to the logical network address, this switching process is transparent to the client. After a brief connection interruption, the client automatically reconnects to the same logical network address now taken over by the backup server via a reconnection mechanism, thus maintaining data interaction with the server and ensuring business continuity.

[0039] Figure 3 This diagram illustrates the detailed signaling interaction sequence between the client and server. The interaction process typically includes: first, establishing a TCP connection via a standard three-way handshake; then, to ensure communication security, an optional key negotiation process can be performed to negotiate the session key; after the secure channel is established, the client sends an APP registration request to identify itself and perform authentication; after the server responds to the registration request, both parties enter the data transmission phase, where the client can send various data request messages, and the server returns corresponding data response messages; when the interaction ends, the client can send a deregistration request, and finally, both parties disconnect the TCP connection. This entire series of interactions is accomplished by sending and receiving Application Protocol Data Units (APDUs) conforming to a predefined protocol format.

[0040] In this embodiment, the health check mechanism does not simply check whether a service process exists or whether a port is listening, but rather delves into the business layer to intelligently perceive and quantitatively assess the business health status of the server. This can effectively identify apparent dead states such as business logic freezes or data processing blockages. Specifically, the high availability management module implements this function by executing a deeply customized health check script. This script uses a dynamic evaluation algorithm to quantitatively score the true business health of the basic platform services. The specific process is as follows: First, at least one raw business indicator from the server is periodically acquired. In this embodiment, optionally, the raw business indicator includes the update timestamp of key data points and the current length of the business processing queue. For example, the key data point could be the total active power of the power grid, representing the overall operating status of the power grid, and its update timestamp directly reflects whether the data acquisition and processing link is smooth. The business processing queue could be a queue of remote control commands to be processed, and its length reflects the system's load and response capability.

[0041] Secondly, based on the acquired raw business metrics, a comprehensive health score is calculated to quantify the server's operational status. This calculation process can be divided into several steps.

[0042] The first step is to calculate the Data Freshness Metric (DFM) based on the update timestamp, which is used to assess whether the core data has been updated within the expected timeframe. The calculation formula can be designed as follows: DFM=max(0,1-(T_now-T_last_update) / T_max_delay) Here, DFM represents the data freshness metric, with a value range of [0,1]. The closer the value is to 1, the fresher the data. T_now represents the timestamp when the current check is executed. T_last_update represents the latest update timestamp of the key data point obtained from the internal status interface of the basic platform service. T_max_delay is the maximum allowable data update delay configured according to the specific substation scenario, for example, it can be set to 5 seconds. When the actual delay exceeds T_max_delay, DFM is 0.

[0043] The second step is to calculate the Queue Load Metric (QLM) based on the current length of the business processing queue, which is used to assess whether there is a backlog of data processing tasks. To make the assessment results more sensitive to load growth, a non-linear exponential decay model can be used for calculation, as shown in the following formula: QLM=exp(-α*(L_queue / L_max)) Where QLM represents the processing queue load metric, with a value range of (0,1], where a value closer to 1 indicates a lower system load; exp is the natural exponential function; L_queue is the current length of the queue of pending data requests obtained from the basic platform service; L_max is the maximum tolerable queue length designed by the system, for example, 1000 requests; α is the load sensitivity coefficient, used to adjust the severity of the impact of queue length on the score, for example, a value of 5.

[0044] The third step is to perform a weighted fusion of the data freshness metric and the processing queue load metric to obtain the final comprehensive health score (H_score). The calculation formula is as follows: H_score = w_dfm * DFM + w_qlm * QLM Here, H_score represents the overall health score, with a value range of [0,1]. w_dfm and w_qlm are the weighting coefficients for data freshness and queue load, respectively. Their values ​​are set according to the different priorities of the business regarding data real-time performance and processing capabilities, and must satisfy w_dfm + w_qlm = 1. For example, for scenarios with extremely high real-time requirements, w_dfm can be set to 0.7 and w_qlm to 0.3.

[0045] Next, based on the calculated comprehensive health score, the system determines whether the business health status is abnormal. To prevent misjudgments and unnecessary switching due to network jitter or brief system overload, this embodiment introduces a fault-tolerance counter mechanism, meaning the health check mechanism also maintains a fault-tolerance counter. Specifically, a health threshold H_threshold (e.g., 0.3) and a maximum number of consecutive degradations C_max (e.g., 3) are preset. During each health check, if the calculated H_score is lower than H_threshold, the internal fault-tolerance counter C_degrade is incremented by 1. Conversely, if H_score is not lower than H_threshold, C_degrade is immediately cleared. Only when the accumulated C_degrade count reaches the preset maximum C_max is the server's business health status ultimately determined to be abnormal. At this point, the health check script returns a failure status to the high availability management module, thereby triggering a primary / standby switchover.

[0046] To achieve the upgrade from a passive response-based to a proactive defense-based switchover, this embodiment further introduces a trend-predictive pre-switchover decision-making logic. This logic first needs to record the historical time series of the comprehensive health score. For example, a fixed-length N (e.g., N=10) First-In-First-Out (FIFO) queue can be maintained to store the H_score sequence calculated from the most recent N checks: {H_t, H_t-1, ..., H_t-N+1}. Then, based on this historical time series, the changing trend of the comprehensive health score is analyzed to predict the risk of abnormal business health status on the server side. A simple trend analysis method is to calculate the linear regression slope Slope(H) of the score sequence, which can be simplified as: Slope(H) = (H_t - H_t - N+1) / (N-1) Where Slope(H) represents the slope of the health score change; H_t is the latest score; H_t-N+1 is the score N times before the check; and N is the length of the historical sequence. When the slope is negative and its absolute value is large, it indicates that the service health status is rapidly deteriorating. When the risk of an abnormal business health status on the server side exceeds a preset risk threshold, for example, when H_score itself is already below a warning threshold H_predict_threshold (e.g., 0.5) and its slope Slope(H) is also below a negative slope threshold Slope_threshold (e.g., -0.05), it can be judged as a high-risk state, and a primary / standby switchover can be triggered in advance. This predictive switchover capability can complete the switchover before the failure has a substantial impact on the business, raising the system availability to a new level.

[0047] like Figure 4 As shown, the Application Protocol Data Unit (APDU) message structure used for communication between the client and server in this embodiment includes a protocol header, an Application Service Data Unit (ASDU), and an optional signature field. The protocol header is a fixed-length data structure used to carry metadata such as protocol version and message length. The ASDU, as the core data payload of the message, is organized using a structured data format; for example, in this embodiment, a UTF-8 encoded JSON string format may be used. The signature field is used to digitally sign the message content to ensure its integrity and non-repudiation.

[0048] The Application Protocol Data Unit (APDU) refers to a message unit that follows a predefined format when data is exchanged at the application layer. In this application, its structure may include a protocol header, Application Service Data Unit (ASDU), and other parts.

[0049] In the embodiments of this application, such as Figure 4 and Figure 5 As shown, the protocol header contains a service identifier field and a control word field. The control word field (e.g., ...) Figure 5 As shown, different bit flags can indicate whether a message needs to be signed, encrypted, compressed, or fragmented. The service identifier field is used to distinguish different business logics. This method utilizes this service identifier field to prioritize high-priority services. Specifically, the server and / or client can identify high-priority service messages based on predefined service identifier values ​​(e.g., the protocol specifies that messages with a service identifier of 0x1001 are emergency alarm messages). When such high-priority messages are received, the processor places them at the head of the data packet queue used to cache service messages, or assigns them a dedicated high-priority processing thread, thereby bypassing ordinary service messages waiting in the queue and achieving priority processing. This built-in Quality of Service (QoS) guarantee mechanism ensures that critical information such as substation protection actions and emergency alarms can be transmitted and responded to with minimal latency.

[0050] Optionally, the protocol header is fixed at 21 bytes in length, and the definitions of each field are shown in the table below: field name length type describe Frame header identifier 4 bytes uint32 The frame header identifier, used for quick identification of protocol packets, is fixed at 0xcd90cd90. The receiver first verifies this field; if the verification fails, the packet is discarded. Protocol version 1 byte uint8 Protocol version number, for example, 0x01 indicates version 1. Used for subsequent protocol upgrades and compatibility handling. control word 1 byte uint8 Message control information is used to indicate whether encryption or signature is required, and the specific meaning of each flag bit is as follows: Figure 5 As shown. Segment ID 1 byte uint8 Segment ID. When not sent in segments, it is fixed at 0; when the application service data unit is sent in segments, each segment of the same complete application service data unit is identified by the same segment ID value, which ranges from 1 to 255. Service Identifier 2 bytes uint16 Service identifiers are used to distinguish different business logics on the same server. For example, 1 represents the registration service and 2 represents the login service. length 4 bytes uint32 The data body length indicates the number of bytes in the subsequent Application Service Data Unit (ASDU), transmitted in network byte order (big endian). Data length before compression 4 bytes uint32 When the compression flag is 0, the value of this field is 0; when the compression flag is 1, the value of this field is the original length of the data before compression. Reserved fields 4 bytes uint32 Reserved field, intended for future expansion, filled with 0 by default.

[0051] The flag bits of the control word are defined as shown in the table below: Flag value illustrate Signature mark 1 The Application Protocol Data Unit (APDU) is identified by a signature field at the end, which needs to be verified using the SM2 algorithm. Encryption flag 1 The Application Service Data Unit (ASDU) is identified as encrypted data and requires decryption. If the compression flag is also set to 1, decompression will occur before decompression. Compression mark 1 The Application Service Data Unit (ASDU) is identified as compressed data and needs to be decompressed. Segmentation Marker 1 The current Application Service Data Unit (ASDU) is identified as incomplete data, requiring subsequent fragments to be received for data combination, until the last fragment with a fragment flag of 0 is received, and the segment IDs in the headers of all fragments are the same.

[0052] In this embodiment, the Application Service Data Unit (ASDU) is organized in JSON format, and the meanings of some fields are shown in the table below: field name illustrate identitycheck Registration code, used for identity verification within the app. appname App name. version App version number. result The basic platform will respond with a return code; 0 indicates success. condition Request conditions. data The data content returned by the basic platform.

[0053] It should be noted that this application primarily addresses the interaction method between the underlying platform and the application, changing the traditional dynamic library calling method to a TCP-based network service calling method. Under this architecture, the data packets themselves can use the existing format without requiring additional modifications to the packet structure, thereby reducing the integration cost for application providers.

[0054] For ease of understanding, the following examples use JSON format to illustrate several typical business scenarios and provide examples of Application Service Data Units (ASDUs).

[0055] 1. APP registration request message { "identitycheck": "WERASDFERSFLKJLKAUYOIUHADKAHKJHUEFJJHASDUHUNZCMVBKJLKSJDFJKHKASN", "appname": "app", "appdesc": "app", "version": "1.0" } 2. APP registration response message { "identitycheck": "WERASDFERSFLKJLKAUYOIUHADKAHKJHUEFJJHASDUHUNZCMVBKJLKSJDFJKHKASN", "appname": "app", "appdesc": "app", "version": "1.0", "result": 0 } The above examples are only used to illustrate the message interaction format adopted in this application. In actual applications, more fields can be added according to business needs, and other structured data formats such as XML can be supported.

[0056] In summary, this embodiment deploys the basic platform as a highly available server employing intelligent health checks, with business applications acting as clients. The two interact loosely via standardized network protocols. When the basic platform service on the primary server experiences a business logic freeze or other apparent failure, its data updates stagnate or task queues accumulate. This is captured by the health check script using the aforementioned formulas and decision logic, or its continued deterioration trend is detected by predictive failover logic. Upon receiving the failure status returned by the script, the high-availability management module immediately triggers a primary-backup switchover, transferring the logical network address to the backup server. Since the client business applications are always connected to the logical network address, their reconnection mechanism quickly reconnects to the same address now being served by the backup server, restoring service within a very short time. This solution not only decouples applications from the platform, reducing the complexity of integration and deployment, but also improves the reliability and data accuracy of the system under complex failure scenarios and ensures the real-time performance of critical business operations through an intelligent failover mechanism deeply integrated with business processes.

[0057] In another possible implementation, the data format of the Application Service Data Unit (ASDU) is not limited to JSON. While maintaining... Figure 1 The client / server architecture, high availability mechanism, and Figure 4While maintaining the existing APDU structure (header + payload), the ASDU data format can be replaced from JSON to another widely used structured data format—XML. In this case, the message processing modules of the basic platform services and business applications need to be adjusted accordingly, using an XML parser (such as libxml2 or TinyXML) instead of a JSON parser to process the ASDU portion. For example, an ASDU for an app registration request can be represented in the following XML format: <request> <identitycheck> a1b2c3d4e5f6...< / identitycheck> <appname> app< / appname> ...< / request> .

[0058] In this implementation, the length field in the protocol header indicates the number of bytes in the subsequent XML string. During operation, the client constructs an APDU message containing an XML-formatted ASDU and sends it to the server. The server receives the message, parses the protocol header, and then extracts the XML data based on the length information for parsing and business processing. This embodiment demonstrates the universality of the method proposed in this application, showing its compatibility with various structured data formats and thus supporting a wider range of system integration scenarios.

[0059] Furthermore, the logical network addresses used to achieve high availability are not limited to virtual IP technology. While maintaining the client / server architecture and APDU protocol (such as...), Figure 4 , Figure 5 Without changing the underlying implementation (as shown), the high availability solution can be replaced from a Keepalived (VRRP)-based solution to a DNS load balancing-based solution. In this implementation, an internal DNS server needs to be deployed, and a unique service domain name (e.g., substation.service.local) needs to be created for the basic platform service. Normally, this domain name resolves to the physical IP address of the primary server. A separate health monitoring service, using the same business status awareness and prediction script as in the previous embodiment, continuously checks the business availability of the primary server. The client configuration of the business application no longer uses a virtual IP address, but rather this service domain name. When the health monitoring service detects a business failure on the primary server or predicts a failure risk, it automatically updates the records in the DNS server, pointing the service domain name to the physical IP address of the backup server. Disconnected clients, upon reconnection, will perform a new DNS query to obtain the new IP address of the backup server and establish a connection, thus achieving transparent failover to the client. This embodiment demonstrates that the concept of a logical network address can be implemented using various technologies, the core of which lies in shielding the client from the details of the physical server to achieve high availability.

[0060] In an alternative implementation, to further enhance communication security, the communication security scheme can be replaced from application-layer custom key negotiation to the standard Transport Layer Security (TLS) protocol. In this implementation, the system architecture (such as...) Figure 1 (as shown), high availability mechanisms and APDU protocol structure (such as...) Figure 4 (As shown) remains unchanged. The main changes are: configuring a server certificate for the server and issuing client certificates for legitimate clients. The connection between the client and the server is no longer a regular TCP connection, but a TLS encrypted connection. Figure 3 The key negotiation process shown is replaced by the standard TLS handshake process. The client initiates a TLS connection request to the server's logical network address, and both parties perform a two-way authenticated TLS handshake. After a successful handshake, a fully encrypted communication channel is established. Since the client's identity has been verified through certificates, the original application layer registration and authentication steps can be simplified. All subsequent APDU messages (whose structure remains the same) Figure 4 and Figure 5 All data (as shown) are transmitted over this encrypted channel, inherently possessing confidentiality and integrity protection. This embodiment demonstrates that the security mechanism of the method in this application has multiple implementation methods, and using the industry-standard TLS protocol can achieve end-to-end encrypted communication and authentication more efficiently and securely.

[0061] To improve connection robustness and optimize system resources in unstable network environments, this application also provides an adaptive heartbeat and dynamic timeout mechanism. Based on the architecture of Embodiment 1, the communication protocol is extended. A dedicated heartbeat / probe message type is defined. The heartbeat request message sent by the client adds a field to carry network quality parameters (such as average RTT, packet loss rate), and the heartbeat response message sent by the server adds a field to carry its own load index. During communication, the client continuously calculates the moving average network round-trip time (RTT_avg) and packet loss rate (Loss_rate) by recording the sending and receiving timestamps of the probe messages, thereby periodically evaluating network communication quality. Simultaneously, the server internally monitors performance indicators such as CPU utilization and message queue length in real time, and calculates a standardized load index L_idx (value range [0,1]) according to a preset weighted formula to assess its own business load status. Both the client and server follow a preset algorithm to dynamically adjust the heartbeat detection interval and connection timeout threshold based on network quality and / or business load. For example, the client can dynamically calculate the timeout time according to the following formula: Timeout_new=Timeout_base+k_rtt*RTT_avg+k_loss*Loss_rate In this system, `Timeout_base` is the base timeout period, and `k_rtt` and `k_loss` are adjustment coefficients. Simultaneously, the server can suggest adjustments to the heartbeat interval for the client based on its own load, such as `Interval_suggested = Interval_base * (1 + k_load * L_idx)`, where `Interval_base` is the base interval and `k_load` is the adjustment coefficient. This way, when network congestion increases RTT, the timeout threshold is widened to avoid false disconnection detections; when the server is under high load, it requests the client to reduce the heartbeat frequency to alleviate its own burden. This mechanism enables the system to intelligently adapt to environmental changes, improving connection stability and efficiency.

[0062] Furthermore, to achieve rapid recovery after client disconnection, this application also provides an optimized reconnection mechanism based on differential snapshots and incremental synchronization. Based on the architecture of Embodiment 1, the data synchronization process is optimized. The server maintains an incrementing state version number (DataVersion) for the key datasets (such as the whole-site telemetry and telecontrol point table) that it needs to synchronize to the client. The version number increments by 1 whenever the data changes. The client caches the data and the corresponding DataVersion locally. When the client disconnects and reconnects due to network fluctuations or master / slave switching, it reports the last known version number (last_known_versions) of each locally cached dataset to the server during re-registration. Upon receiving the request, the server compares the version number reported by the client with its own current latest version number. If the version numbers match, no synchronization is needed; if they do not match, the server generates a differential packet containing only version difference data based on internal change logs or real-time comparison; a snapshot packet containing the complete dataset is prepared only when the version difference is too large or when the client connects for the first time. This differential packet or snapshot packet is carried in the server's registration response message. Upon receiving the response, if it is a differential packet, the client merges it in its local cache, quickly restoring to the latest state. This mechanism optimizes the traditional reconnection process, which requires fetching all data, to synchronizing only incremental data. This reduces data recovery time from minutes to seconds or even milliseconds, while also reducing network bandwidth usage and achieving a near-uninterrupted reconnection experience.

[0063] It should be understood that the sequence number of each step in the above embodiments does not imply 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 application.

[0064] Corresponding to the data interaction method of the substation monitoring system described in the above embodiments, this application also provides a data interaction system for the substation monitoring system, the structure of which can be referred to Figure 1The system comprises a high-availability cluster consisting of a primary server and a backup server. A basic service platform serving as the server is deployed on this high-availability cluster. Furthermore, the high-availability cluster is configured to: manage an external logical network address; monitor the service health status of the server through the health check mechanism described in any of the foregoing embodiments; and, when it is determined that the service health status of the primary server is abnormal, switch the logical network address from the primary server to the backup server to maintain data interaction between the client and the server.

[0065] This application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0066] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0067] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.

[0068] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 6 As shown, the computer device of this embodiment includes: at least one processor 60 ( Figure 6 (Only one is shown in the diagram), memory 61, and computer program 62 stored in memory 61 and executable on at least one processor 60, wherein the processor 60 executes computer program 62 to implement the steps in any of the above embodiments of the data interaction method for substation monitoring systems.

[0069] The computer device may include, but is not limited to, a processor 60 and a memory 61. Those skilled in the art will understand that... Figure 6 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.

[0070] The processor 60 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0071] In some embodiments, the memory 61 may be an internal storage unit of the computer device, such as a hard drive or memory. In other embodiments, the memory 61 may be an external storage device of the computer device, such as a plug-in hard drive, smart media card (SMC), secure digital card (SD), flash card, etc. Furthermore, the memory 61 may include both internal and external storage units of the computer device. The memory 61 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 61 can also be used to temporarily store data that has been output or will be output.

[0072] If the integrated unit is implemented as 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, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / computer equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0073] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0074] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0075] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0076] The units described as separate components may or may not be physically separate. 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 can be selected to achieve the purpose of this embodiment according to actual needs.

[0077] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A data interaction method for a substation monitoring system, characterized in that, The method is applied to a high-availability cluster including a primary server and a backup server. The basic platform of the substation monitoring system is deployed as a server on the primary server and the backup server. The high-availability cluster manages an external logical network address. The method includes: The business application, acting as a client, initiates data interaction with the server by establishing a network communication connection with the logical network address. The high-availability cluster monitors the service health status of the server through a health check mechanism. When it is determined that the business health status of the primary server is abnormal, the logical network address is switched from the primary server to the backup server in order to maintain data interaction between the client and the server.

2. The method according to claim 1, characterized in that, The monitoring of the server's business health status through the health check mechanism includes: Periodically obtain at least one original business metric from the server; Based on the at least one original business indicator, a comprehensive health score is calculated to quantify the server's operational status. Based on the comprehensive health score, it is determined whether the business health status is abnormal.

3. The method according to claim 2, characterized in that, The original business metrics include the update timestamps of key data points and the current length of the business processing queue; The calculation of a comprehensive health score based on the at least one original business indicator to quantify the server's operational status includes: Calculate the data freshness metric based on the update timestamp; Calculate the processing queue load metric based on the current length of the business processing queue; The data freshness metric and the processing queue load metric are weighted and fused to obtain the comprehensive health score.

4. The method according to claim 3, characterized in that, The step of determining whether the business health status is abnormal based on the comprehensive health score includes: When the overall health score is lower than the preset health threshold, the count value of the fault tolerance counter is increased; When the count value of the fault tolerance counter reaches the preset upper limit of the number of consecutive degradations, the business health status is determined to be abnormal.

5. The method according to claim 2, characterized in that, The method further includes: Record the historical time series of the comprehensive health score; Based on the historical time series analysis, the trend of the comprehensive health score is analyzed to predict the risk of abnormal business health status of the server. When the risk of an abnormal business health status on the server exceeds a preset risk threshold, the business health status is determined to be abnormal.

6. The method according to claim 1, characterized in that, The method further includes: Periodically assess the network communication quality between the client and the server, and / or assess the service load status of the server; Based on the network communication quality and / or the service load status, dynamically adjust the heartbeat detection interval and / or connection timeout threshold used to maintain the network communication connection.

7. The method according to claim 1, characterized in that, In the network communication connection, the client and the server communicate in accordance with a predefined application layer data interaction protocol; The application layer data interaction protocol adopts an application protocol data unit message structure including: a protocol header and an application service data unit; the protocol header includes a service identifier field. The method further includes: The server and / or client identify high-priority service messages based on the service identifier field, and place the high-priority service messages at the head of the data message queue used for caching service messages for priority processing.

8. A data interaction system for a substation monitoring system, characterized in that, The system includes: A high-availability cluster consisting of a primary server and a backup server, wherein a substation monitoring system platform is deployed on the high-availability cluster as a server, and the high-availability cluster is configured as follows: Manage a logical network address that is exposed to the outside world; The health status of the server is monitored through a health check mechanism. When it is determined that the business health status of the primary server is abnormal, the logical network address is switched from the primary server to the backup server in order to maintain data interaction between the client and the server.

9. A computer device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when run, implements the method as described in any one of claims 1 to 7.

Images