Equipment link state monitoring and dynamic adjusting method in airship platform OMC system

Abstract

The invention provides an equipment link state monitoring and dynamic adjusting method in an airship platform OMC system, which comprises the following steps: carrying out link connection on the OMC system and managed equipment, establishing a management link, and adjusting the link state from an initialized state to a connected state; monitoring and analyzing a link in a connection state through a heartbeat monitoring task, and judging whether the connection state is maintained or not; when the connection state cannot be maintained, disconnecting the connection between the OMC system and the managed equipment, and adjusting the link state from the connection state to the disconnection state; the time corresponding to the disconnection state is broadcasted and alarmed in the OMC system, the link in the disconnection state is reconnected and established, and the link state is adjusted to the connection state after establishment.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of communication monitoring, in particular to a method for monitoring and dynamically adjusting link state of equipment in an airship platform OMC system. BACKGROUND

[0002] The airship platform OMC system is responsible for unified management of remote loads, near-end ground equipment and communication links. The traditional OMC system usually uses a static and fixed heartbeat mechanism for link state monitoring, resulting in inaccurate monitoring and large network overhead. Secondly, there is a lack of early warning mechanism, and operation and maintenance is passive. Finally, it is difficult to quickly locate the root cause when a fault occurs, and the recovery strategy is blind, resulting in low operation and maintenance efficiency. Currently, there is an urgent need for a link state management scheme that can achieve adaptive adjustment to improve the reliability and operation and maintenance automation level of the airship platform OMC system. SUMMARY

[0003] In view of this, the present application provides a method for monitoring and dynamically adjusting link state of equipment in an airship platform OMC system to solve the problems existing in the prior art.

[0004] To achieve the above purpose, the present application provides a method for monitoring and dynamically adjusting link state of equipment in an airship platform OMC system, comprising: link connection between the OMC system and the managed equipment is performed, a management link is established, and the link state is adjusted from initialization to connection state; the link in the connection state is monitored and analyzed by a heartbeat monitoring task, and it is judged whether to maintain the connection state; when the connection state cannot be maintained, the OMC system disconnects the connection between the OMC system and the managed equipment, and adjusts the link state from the connection state to the disconnected state; and the time corresponding to the disconnected state is broadcasted and alarmed in the OMC system, and the link in the disconnected state is reconnected and established, and the link state is adjusted to the connection state after establishment.

[0005] Optionally, in the heartbeat monitoring task, heartbeat data transmitted between the OMC system and the managed equipment is collected in real time, heartbeat delay data of the heartbeat data is counted, feature information of the heartbeat delay data is extracted, the feature information includes short-term trend and root mean square jitter information, and it is judged whether the link state deteriorates according to the feature information, and when the deterioration occurs, the connection state in the link state is adjusted to the deterioration state; when the request in the heartbeat data times out, it is judged that the connection state cannot be maintained, all communication data between the OMC system and the managed equipment is obtained for causal reasoning, and the fault reason is obtained, and the fault reason is used to assist in reconnection and establishment of the link in the disconnected state.

[0006] Optionally, the feature information extraction process comprises: Obtaining heartbeat delay data, and according to the heartbeat delay data, dimensionally fixing the length of a heartbeat delay sequence, performing linear regression calculation on the heartbeat delay sequence, obtaining the slope of the heartbeat delay sequence as a short-term trend, and calculating the root mean square of adjacent delay differences in the heartbeat delay sequence as root mean square jitter information.

[0007] Optionally, the causal reasoning is performed by using a belief propagation method through a preset causal graph model, the causal graph model is encoded in the form of a directed acyclic graph, and the causal relationship between variables including heartbeat timeout, same group device state, gateway load, switch port error and configuration change record in the causal graph model. The belief propagation method injects all communication data between the OMC system and the managed device into the causal graph model for probability propagation, and outputs a posterior probability list of the root cause.

[0008] Optionally, during the process of adjusting the link state from the initialization to the connection state, a management link is established according to device information of the managed device, and the device information includes communication address information, device port, device state, device password, device password and communication protocol.

[0009] Optionally, after obtaining the fault cause, the method further comprises reconnecting and establishing the link in the disconnected state by using a recovery strategy, and the recovery strategy comprises: if the fault cause is network congestion, starting a reconnection mechanism with exponential backoff characteristics; and if the fault cause is device failure, reducing the detection frequency and sending a high-priority accurate alarm to an operation and maintenance platform.

[0010] Optionally, the change of the device link state is broadcasted through a message bus of the OMC system, and the device link state is centrally maintained in a distributed cache to ensure the consistency of the link state of the device in the OMC system.

[0011] On the other hand, the application also provides a device link state monitoring and dynamic adjustment system in an airship platform OMC system, which is used for executing the above-mentioned method.

[0012] Compared with the prior art, the application has the beneficial effects that, The application can dynamically generate the optimal heartbeat interval and timeout threshold according to the device type, network topology position and real-time link quality, overcome the disadvantages of the traditional static heartbeat mechanism, significantly improve the accuracy of state monitoring, effectively reduce unnecessary network signaling overhead, and realize the optimization of resource utilization. Based on real-time signal processing of the heartbeat delay sequence, the system can identify the performance degradation trend before the link is completely interrupted, and switch the state to the "Degraded" (degraded) early warning state in advance. This provides a valuable intervention window for operation and maintenance personnel, changes the passive processing after failure of the system to active early warning and protection before failure, greatly enhances the maintainability and usability of the system. When a link failure occurs, it can quickly integrate multi-dimensional evidence and accurately locate the root cause (such as network congestion, device failure or platform anomaly). Based on the clear root cause diagnosis, the system can automatically trigger the most targeted recovery strategy (such as exponential backoff reconnection, low-frequency detection or route switching), completely changes the traditional blind retry recovery mode, and significantly improves the fault recovery success rate and operation and maintenance efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0013] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of preferred embodiments, and are not meant to limit the present application. In the drawings: Figure 1 The method flowchart in the embodiments of the present application is shown. DETAILED DESCRIPTION

[0014] Exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments described herein. On the contrary, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be accurately conveyed to those skilled in the art. It should be noted that the embodiments in the present application and the features in the embodiments can be combined with each other without conflict. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0015] In the airship platform operation and management center (OMC) system, the objects managed and communicated by the OMC system include several categories, i.e., remote platform system and load equipment, near-end platform system and equipment, remote-near-end communication and data link. The remote platform system and load include various types of "communication, guidance and remote" load equipment, terahertz communication equipment (such as optical transmitters), remote platform networking equipment and other supporting equipment. In addition, various components of the remote platform (such as the airship system) can also be included in the OMC system, but these platform-type equipment often have dedicated management and control systems to be uniformly managed (such as the airship flight control platform). The near-end platform system and equipment include local receiving devices of "communication, guidance and remote" load data, local networking equipment, local terahertz communication equipment (such as optical receivers), supporting communication alignment turntable equipment, and other equipment, etc. In addition, the communication link and service link between the remote and near-end are also managed objects, and their management state and index data are reflected through the connected two-end communication equipment. In the above content, the managed objects and communication objects can communicate with the OMC system through existing unified communication protocols and methods.

[0016] Among them, the airship platform carries remote equipment, remote load, remote networking equipment, remote terahertz transceiver equipment and system management OMC platform, and the near-end related equipment is placed on the ground. The system management OMC platform is also set up on the ground. The system management OMC platform of the remote and the system management OMC platform of the near-end also perform related interactions. The above-mentioned remote equipment is the related control and environmental perception equipment of the airship platform, the remote load is the related data acquisition equipment, and the remote networking equipment ensures the data transmission between the remote equipment, the remote load and the system management OMC platform.

[0017] The main business processes of the communication equipment and managed equipment of the OMC system in the airship platform are as follows: the remote equipment and remote load converge service data through the optical switch; the optical transmitter transmits service data through the remote transmission link; the local system receives service data through the optical receiver; the local optical switch distributes service data to the application platform; and the system management OMC platform manages equipment through the management link.

[0018] The embodiment proposes a device link state monitoring and dynamic adjustment method in the airship platform OMC system, as shown in Figure 1 , which includes monitoring the link state of the device in communication with the airship platform OMC system, wherein the device link state changes with the state change of the device, and the link state is dynamically adjusted in combination with the link monitoring mechanism. The device link state includes initialization (Init), connection (Link) and broken link (Broken).

[0019] Here, the initialization state is in the time range from the creation of the device to the activation. After the device is successfully started, the corresponding link state becomes the Link state. After the device is successfully suspended, the corresponding link state becomes the Broken state. In addition, during the activation of the device, the link monitoring mechanism (such as the heartbeat keep-alive) is also set, and the link state is dynamically adjusted according to the monitoring result. For example, if the link is monitored to be broken, the corresponding link state is set to Broken, and after the broken link is recovered, the link state is set to Link.

[0020] In the foregoing, the following specific operation process is involved: First, link establishment is performed, and an operation of “device activation” is performed on the interface by an operation and maintenance personnel. The OMC system initiates a link connection request (such as a TCP socket connection) according to the IP / port and other information configured by the device. If the link is successfully established, the device link state immediately transitions from Init to Link.

[0021] Then, when the device link state is adjusted to the Link, the device starts a periodic heartbeat monitoring task.

[0022] The heartbeat monitoring task periodically sends a heartbeat request message to the device agent through the established link, and waits for a response. If a valid response is received within a preset timeout time, the link is considered to be healthy, and the Link state is continued.

[0023] If the heartbeat response is not received for a plurality of times continuously or network exceptions are captured, it is determined that the link is faulty. When the heartbeat monitoring mechanism determines that the link is faulty, the OMC system captures the exception of disconnection in the communication process. The device link state transitions from Link to Broken.

[0024] And a state change event is broadcast to a topology management module and the like, triggering interface alarm and visual update. At the same time, a background reconnection task is started, and a periodic attempt is made to reestablish the link. If the link can be reestablished, the automatic reconnection task successfully reestablishes the connection with the device agent. The device link state is restored from Broken to Link. And the heartbeat monitoring task is resumed. The related modules are notified that the link has been recovered, and the related alarms are cleared.

[0025] The disconnection of the link can be performed by an operation and maintenance personnel on the interface by performing an operation of “device suspension”. The link connection with the device agent is actively disconnected. And the heartbeat monitoring task of the device is stopped. The device link state transitions from Link to Broken.

[0026] In the above content, the heartbeat monitoring mechanism uses an independent thread pool to manage per device, avoiding blocking the main business. Meanwhile, the heartbeat interval and timeout threshold are configurable to adapt to devices in different network environments. The device link state is centrally maintained in the OMC system memory to ensure access efficiency. Any state change is broadcast to all network elements through the message bus to ensure the consistency of the state of topology, alarm, etc. Exponential backoff strategy is adopted to avoid unnecessary traffic and load when the network is temporarily unavailable. This scheme ensures that the OMC system can real-time and accurately grasp and manage the communication link status of each device in the domain, and provides intuitive state display and timely fault alarm for operation and maintenance personnel.

[0027] The heartbeat monitoring mechanism mainly includes the following contents: the party sending the heartbeat (such as a remote device) is running and has no downtime. The network connection between the sending party and the receiving party (such as the OMC system) is established and available. In the heartbeat monitoring mechanism, the sending party is the agent program of the managed device, and the receiving party is the OMC server. Usually, only the most basic information such as device identifier, timestamp and a fixed "heartbeat" message type is contained in a simple data packet. The core is not to carry a large amount of data, but the existence itself.

[0028] It can be implemented through any protocol, such as sending a specific short string or binary packet on a TCP connection, periodically sending a datagram through UDP, subscribing to a specific topic in the MQTT protocol and periodically publishing messages. The data sending frequency of the heartbeat monitoring mechanism is periodic according to the preset interval, for example, once every 30 seconds.

[0029] For the above specific technical content, the present application is explained as follows: For the link establishment process from the Init transition to the Link process described above, the relevant implementation is performed by the following operations: The operation and maintenance personnel selects the device with a unique device identifier including the device type, device number, and identification code in the device list or topology graph of the front-end interface, and clicks the "activate" button. The front-end interface captures the click event and assembles a "device activation request" message. The core field of the message is the device unique identifier. The front-end interface sends the "device activation request" to the back-end API gateway through the HTTP protocol. The back-end API gateway receives the "device activation request". First, the identity of the request initiator (operation and maintenance personnel) is authenticated to confirm that it has the right to operate the device. After authentication, according to the request type, it is routed to the dedicated device management service. The device management service receives the request. The received device number is used as the key to query the distributed cache to request the detailed connection information of the device.

[0030] The distributed cache returns the device information corresponding to the device number, including but not limited to: communication address information, device port, device state, device password, device password, and communication protocol.

[0031] The device management service packages the device information and the obtained connection information and initiates a "link establishment request" to the session and connection manager. The session and connection manager receives the "link establishment request". The session and connection manager first creates a "session context" object for the DEVDN, which records all the states and information of this connection. At the same time, the link state of the device in the cache is temporarily marked as "connecting". The session and connection manager calls the TCP client component of the network communication layer according to the communication protocol type (such as TCP), and transmits the communication IP address information and device port as parameters.

[0032] The TCP client component of the network communication layer initiates a TCP connection request (sends a SYN packet) to the communication IP address information and device port. The device agent listens on the port and receives the connection request, and replies with a SYN-ACK packet. The network communication layer completes the third handshake (ACK), and the TCP link is successfully established. On the established TCP link, an application layer handshake message (for example, a login message containing the device password and device password) is immediately constructed and sent. The device agent checks the authentication information and replies with a "login success" response message.

[0033] The network communication layer receives the "login success" response, parses it, and returns a "link establishment success" signal to the session and connection manager of the upper layer.

[0034] After receiving the success signal, the session and connection manager performs the following key operations: sets the state of the "session context" object maintained in its internal to "active". Issues an update instruction to the distributed cache to update the link state field of the device state from "connecting" to Link permanently. Starts a dedicated heartbeat monitoring task for the active session.

[0035] The device state in the distributed cache is updated to Link. This state change event is automatically broadcast through the system message bus. The session and connection manager returns an "activation success" result to the device management service. The device management service returns the result to the front-end interface through the back-end API gateway. The front-end interface pops up a prompt "device activation success" to the operation and maintenance personnel. The topology management module of the system listens to the event that the device state changes to Link through the message bus, and immediately refreshes the topology graph, rendering the icon of the device to green (or online state). At the same time, the alarm management module may clear the "communication interruption" type alarm of the device due to previous inactivation.

[0036] At the same time, after the device link state is adjusted to Link, the heartbeat monitoring task is started. The start of the heartbeat monitoring task marks that the link state management enters a dynamic and intelligent life maintenance stage from a static channel establishment.

[0037] In the heartbeat monitoring task, the first step of task initialization is to initiate a strategy request to the federated learning model. In the heartbeat monitoring task, a global unified heartbeat interval is not used, but the device type, historical link quality indicators and network topology position of the current device are submitted to the lightweight federated learning model deployed on the OMC server side as features. The lightweight federated learning model aggregates anonymized connection experiences from the same type of devices in the whole network, and can predict the optimal heartbeat interval and timeout threshold under the current network environment and business load, taking into account timeliness and low overhead. The heartbeat monitoring task sets the clock for the first heartbeat evaluation according to the personalized strategy issued.

[0038] In the above content, the input of the lightweight federated learning model is the device type, historical link quality indicators and network topology position of the related current device, and at the same time, the current network environment information and business load information are also included. The output is the corresponding optimal heartbeat interval and timeout threshold. The lightweight federated learning model can use the existing model architecture, and its input layer and output layer are adjusted and trained through related training samples. The network architecture can be selected, including LSTM network or other deep learning models.

[0039] When the first heartbeat period arrives, the task instructs the network layer to send a lightweight heartbeat probe packet to the device agent. The complete round-trip delay from sending to receiving the response is accurately recorded. This delay value is immediately sent to a real-time updated time series buffer.

[0040] Subsequently, the state prediction module based on signal processing starts to work. This module regards this sequence of delay data as a discrete signal to be analyzed. A lightweight digital filtering algorithm is applied to smooth incidental noise. First-order difference and moving average filtering are applied to the delay sequence, and its short-term trend and root mean square jitter are continuously calculated. Once the algorithm identifies that the delay presents a statistically significant upward trend or the jitter range exceeds the safety boundary set by the model, even if all heartbeat responses are successfully received at this time, the system will decisively switch the link state from a healthy "Link" to a pre-warning degraded "Degraded" state. This early transition of state provides a valuable intervention window for operation and maintenance personnel, and realizes the paradigm shift from fault handling to fault prediction.

[0041] In the above, the time series buffer is a fixed-length first-in-first-out queue, continuously storing the last N (e.g. N=10) successful heartbeat round-trip delay values. New data enters, oldest data is flushed out.

[0042] The short-term trend is calculated using linear regression, taking the sequence index (i.e. time point) of each heartbeat as the independent variable, and the delay value as the dependent variable. The linear regression slope of the current sequence is calculated. This slope is the short-term trend. If the slope > positive threshold, it is determined to be an "upward trend"; if the slope < negative threshold, it is determined to be a "downward trend"; otherwise, it is "stable".

[0043] In the process of calculating the root mean square jitter, the difference between each data point in the sequence and the previous data point is calculated: thus obtaining a difference sequence with a length of N-1. The root mean square of the difference sequence is calculated, which is the root mean square jitter.

[0044] The calculated slope and root mean square jitter value are compared with the preset dynamic threshold. If the slope is continuously positive and exceeds the threshold, or the root mean square jitter exceeds its threshold, the link state transitions to Degraded.

[0045] If the heartbeat probe fails to receive a response as expected (exceeding the response time threshold), triggering the traditional timeout event, the causal reasoning engine is immediately activated. It will synchronously capture system snapshots in multiple dimensions: including but not limited to querying the link status of other devices belonging to the same physical gateway or the same HAPS platform, checking the core switch port error count, and retrieving whether there have been recent configuration changes that affect the network. The engine quickly correlates and probabilistically reasons about these concurrent events through a pre-set causal graph model, aiming to determine the root cause of this heartbeat disconnection: whether it is a device itself failure, a local network fluctuation, or a systemic abnormality on the platform side.

[0046] The specific implementation of the causal graph model is as follows: the implementation of the causal reasoning engine starts with knowledge modeling and the construction of the causal graph. First, all possible variables that can be observed and related to the link state are determined, including direct heartbeat timeout events, the running state of other devices in the same network area or under the same physical platform, the central processor load of the associated network gateway, the error count increment of the core switch port, recent configuration change records of the system, and the processor load of the managed device itself. After obtaining these observed variables, the system pre-constructs the causal graph model in the form of a directed acyclic graph according to deep network operation and maintenance field knowledge, such as what will happen under the above specific indicator judgment conditions, what needs to be done to recover, and the above causal relationship is pre-constructed to encode the causal relationship between these variables, thereby constructing the pre-constructed causal graph model. For example, the model defines that high processor load of the gateway can cause abnormal state of multiple devices hanging under it, or port error of the switch can directly cause heartbeat timeout to a specific device.

[0047] When the heartbeat monitoring task triggers a timeout event, the causal reasoning engine is immediately activated and enters the evidence injection and probability propagation phase. The engine will immediately automatically capture the real-time state of all other observed variables at the current time from the distributed monitoring system, and these states will be taken as solid evidence. For example, it may find that other several devices under the same platform also have link degradation, the processor load of the associated gateway is at a high level, and the port error count of the switch is zero and there is no configuration change in the recent period. These collected evidence is injected into the causal graph model. Subsequently, the engine uses a fast approximate reasoning algorithm such as belief propagation to perform message passing and probability calculation along the established causal path in the graph. This process is essentially to deduce the observed abnormal phenomenon in the networked causal relationship, thereby updating the probability distribution of all root cause variables that are not directly observed.

[0048] The process of belief propagation is as follows: the method flow starts with the injection of evidence. When some variables (such as "heartbeat timeout" and "abnormality of devices in the same group") are observed, these observations are solidified as the initial probability distribution of the corresponding nodes, that is, the probabilities of these observed nodes are set to 100% or 0%, representing solid evidence. Then enter the iterative message passing phase. In each iteration, each node in the graph will perform two key operations. First, it needs to receive and aggregate the belief messages about the current state from all other neighbor nodes except the target neighbor. Then, it calculates the new belief message for the target neighbor according to the aggregated information and its inherent conditional probability table, and sends it out. For example, the "heartbeat timeout" node will receive prediction messages from the "gateway failure" and "device failure" parent nodes, as well as evidence messages from its child nodes (if any), and after comprehensive calculation, it will feed back updated messages to its parent nodes.

[0049] This localized computation and communication is synchronized across all nodes, constituting one complete iteration. Iterations continue until the entire network reaches a stable state, i.e., the amount of change in the probability distribution computed by all nodes compared to the previous iteration is less than a pre-set threshold, indicating that information has been sufficiently propagated and consensus reached in the network.

[0050] When the algorithm converges, the process enters the result extraction phase. The system directly reads the final probability distribution maintained by those nodes representing the root causes (e.g., "gateway failure," "network congestion"). These probability values are the posterior probabilities of each root cause being true after synthesizing all observed evidence. The system orders these root causes by their probability values from high to low, generating a list of posterior probabilities for final decision-making.

[0051] In the process of computing the new belief message targeting the neighbor of interest, Corresponding to the first step: collecting information. Node X and the current node gather the current messages received from all other neighbors except the target neighbor Y. These messages represent the "opinions" or "supports" of other parts of the graph based on their current knowledge about the state of node X. We denote this as μ Z→X (X), where Z are the neighbors of X excluding Y. Node X multiplies all these external messages with its intrinsic conditional probability table P(X | Parents(X)). The conditional probability table encodes the probabilities of X taking different values given the states of its parents. This multiplication operation fuses local knowledge with external evidence, forming a local estimate of the joint probability over the variable set. To generate the message specifically for Y, X needs to "integrate out" (or "sum out") the variables that Y does not directly depend on. Specifically, it sums the result from the second step to eliminate all variables except Y (integrates for continuous variables). The final computed result μ X→Y (Y) is a brand new belief message from X to Y, which condenses X's latest judgment about the possible state of neighbor Y based on all information currently known.

[0052] In summary, each node plays the role of an "information fusion and forwarding center." It continuously receives messages from various sources, combines its "expert knowledge" (conditional probability table), and then tailors a new, comprehensive "report" for each neighbor and sends it out. Through this localized, parallel computation, global information is eventually circulated and agreed upon throughout the network After the completion of probability propagation, the engine enters the root cause ranking and decision-making phase. At this time, the model outputs a list of posterior probabilities of all potential root causes. This list quantifies the likelihood of different failure hypotheses given various evidence, for example, a gateway failure has a 75% probability, while network congestion and device failure have probabilities of 20% and 5%, respectively. The system selects the hypothesis with the highest posterior probability and determines it as the most likely root cause of the current heartbeat disconnection, thereby accurately pinpointing a vague "connection timeout" as a specific "gateway failure".

[0053] Finally, the system executes strategy-driven and feedback learning based on this accurate diagnosis. The determined root cause directly drives the subsequent recovery strategy, for example, after confirming a gateway failure, the operation and maintenance system can automatically start the backup routing path, rather than futilely attempting to restart the remote device or waiting for it to recover itself. At the same time, all evidence features collected during this event and the root cause label confirmed or corrected by the operation and maintenance personnel will be combined to form a new training sample. These samples, after accumulating to a certain number, will be used to periodically update the structural parameters or conditional probability table of the causal graph model, so that the entire reasoning engine can continuously learn from actual operation and maintenance experience, constantly optimizing its accuracy and speed of future diagnosis, forming an intelligent closed loop that self-improves from practical feedback.

[0054] Based on the high-probability root cause obtained through causal reasoning, the heartbeat task dynamically adjusts its recovery strategy. For example, if the reasoning result strongly points to temporary network congestion, the task may start an aggressive reconnection mode with exponential backoff characteristics, while suppressing unnecessary alarm reporting to avoid causing an alarm storm. Conversely, if the root cause analysis points to a device power failure, the task will enter a low-frequency detection mode and mark the link status as "Broken (Suspected PowerLoss)", while sending a high-priority precise alarm containing the diagnosis conclusion to the operation and maintenance platform.

[0055] During the entire task life cycle, the results of each heartbeat interaction - whether it is successful delayed data or failed root cause analysis conclusion - are anonymized and fed back to the federated learning model as new training samples. This forms a complete self-optimization closed loop: the data generated by the heartbeat task execution continuously fine-tunes the model parameters, while the optimization of the model in turn improves the accuracy of future heartbeat strategies and the self-adaptation ability of the entire system. The adaptive ability of the heartbeat monitoring task.

[0056] At the same time, the above information is collected between the managed devices in the OMC system to monitor the link status between the managed devices and dynamically adjust.

[0057] The application can dynamically generate the optimal heartbeat interval and timeout threshold according to the device type, network topology position and real-time link quality, overcoming the drawbacks of the traditional static heartbeat mechanism. The precision of state monitoring is significantly improved, while unnecessary network signaling overhead is effectively reduced, realizing the optimization of resource utilization. Based on real-time signal processing of the heartbeat delay sequence, the system can identify the performance degradation trend before the link is completely interrupted, and switch the state to the "Degraded" (degraded) early warning state in advance. This provides a valuable intervention window for the operation and maintenance personnel, changes the system from passive processing after failure to active early warning and protection before failure, greatly enhancing the maintainability and usability of the system. When a link failure occurs, it can quickly integrate multi-dimensional evidence and accurately locate the root cause (such as network congestion, device failure or platform anomaly). Based on the clear root cause diagnosis, the system can automatically trigger the most targeted recovery strategy (such as exponential backoff reconnection, low-frequency detection or route switching), completely changing the traditional blind retry recovery mode, and significantly improving the fault recovery success rate and operation and maintenance efficiency.

[0058] In another aspect, the application also provides a device link state monitoring and dynamic adjustment system in a flying boat platform OMC system, which is used to execute the above method.

[0059] Finally, it should be noted that: the above examples are only used to illustrate the technical solutions of the application and not to limit it, although the application has been described in detail with reference to the above examples, those skilled in the art should understand that: the specific embodiments of the application can still be modified or replaced, without departing from the spirit and scope of the application. Any modification or equivalent replacement, which should be covered within the protection scope of the claims of the application.

Claims

1. A method for monitoring and dynamically adjusting the device link status in an airship platform OMC system, characterized in that, include: Establish a management link between the OMC system and the managed device, and change the link status from initialization to connection status. The heartbeat monitoring task monitors and analyzes the links in the connected state to determine whether to maintain the connection. When the connection cannot be maintained, the OMC system disconnects the connection with the managed device and changes the link status from connected to disconnected. The OMC system broadcasts and alarms the time corresponding to the disconnection state, and reconnects the links in the disconnection state. After the reconnection is established, the link status is adjusted to the connected state.

2. The method according to claim 1, characterized in that, In the heartbeat monitoring task, heartbeat data transmitted between the OMC system and the managed device is collected in real time, and heartbeat delay data is statistically analyzed. Feature information is extracted from the heartbeat delay data, including short-term trend and root mean square jitter information. Based on the feature information, it is determined whether the link status has deteriorated. When deterioration occurs, the connection status in the link status is adjusted to the deteriorated state. When a request in the heartbeat data times out, it is determined that the connection cannot be maintained. Then, all communication data between the OMC system and the managed device is obtained for causal reasoning to obtain the cause of the fault. The cause of the fault is used to assist in reconnecting and establishing the link in the disconnected state.

3. The method according to claim 2, characterized in that, The process of extracting the feature information includes: Acquire heartbeat delay data, and based on the heartbeat delay data, perform linear regression calculation on the heartbeat delay sequence with a fixed length dimension to obtain the slope of the heartbeat delay sequence as the short-term trend, and calculate the root mean square of the difference between adjacent delays in the heartbeat delay sequence as the root mean square jitter information.

4. The method according to claim 2, characterized in that, Causal reasoning is performed using a belief propagation method through a pre-defined causal graph model. The causal graph model is encoded in the form of a directed acyclic graph and includes causal relationships between variables such as heartbeat timeout, status of devices in the same group, gateway load, switch port error, and configuration change records. The confidence propagation method described therein injects all communication data between the OMC system and the managed device into the causal graph model for probability propagation, and outputs a list of posterior probabilities of the root cause.

5. The method according to claim 4, characterized in that, During the process of adjusting the link state from initialization to connection, a management link is established based on the device information of the managed device. The device information includes: communication address information, device port, device status, device password, device password and communication protocol.

6. The method according to claim 2, characterized in that, After obtaining the cause of the fault, the method also includes reconnecting the disconnected link through a recovery strategy. The recovery strategy includes: if the cause of the fault is network congestion, then start a reconnection mechanism with exponential backoff characteristics; if the cause of the fault is equipment failure, then reduce the detection frequency and send a high-priority accurate alarm to the operation and maintenance platform.

7. The method according to claim 1, characterized in that, Also includes: Changes in device link status are broadcast via the message bus of the OMC system; Device link status is centrally maintained in a distributed cache to ensure the consistency of device link status within the OMC system.

8. A device link status monitoring and dynamic adjustment system in the OMC system of an airship platform, characterized in that, Used to perform the method described in any one of claims 1-7.

Images