Multi-load airship platform OMC system equipment state dynamic switching method

Abstract

The invention relates to the technical field of high-altitude platform station operation and maintenance management, and provides a multi-load airship platform OMC system equipment state dynamic switching method, which comprises the following steps that: an equipment management component calls an access adaptation layer according to an operation instruction of target equipment; the access adaptation layer instantiates a corresponding adapter module according to the equipment type; the adapter module establishes a session connection with the associated device agent based on the configuration strategy, and starts a heartbeat monitoring mechanism to maintain and monitor a link state after the session connection is successfully established; and dynamically switching a management state and a link state of the target equipment based on a result of the heartbeat monitoring mechanism and the equipment management instruction. According to the method, delicacy management and real-time monitoring of the equipment state are realized by integrating hierarchical management, a micro-service architecture, a dynamic plug-in technology and a security mechanism, the reliability and the expandability of the system are improved, the operation and maintenance complexity is reduced, and the method is suitable for diversified requirements of an HAPS platform in a long-distance communication scene.

Description

Technical Field

[0001] This invention relates to the field of operation and maintenance management technology for high-altitude platform stations, and more specifically, to a method for dynamic switching of equipment status in the OMC system of a multi-load airship platform. Background Technology

[0002] High Altitude Platform Stations (HAPS) based on airships typically carry various types of payload equipment and form a complete operational system with the near-end ground system via technologies such as terahertz communication. In order to achieve unified and efficient management and maintenance of the remote payloads, near-end equipment, and communication links in the system, a fully functional OMC system must be designed.

[0003] In existing network device management solutions, especially in traditional terrestrial fixed communication network management, device management typically adopts a relatively static configuration and management model. The technical principle usually involves the network management system establishing a management connection with the device through standard network management protocols or vendor-specific interfaces to perform configuration distribution, status queries, and alarm monitoring. Device status changes usually require manual intervention rather than being automatically and smoothly managed by the system. Furthermore, the correlation between the device's management status and the physical link's communication status is often relatively simple, or requires extensive manual rule configuration. However, the operating environment of airship platforms and their payloads is complex and variable. Devices frequently experience connection interruptions and recoveries due to platform movement, environmental interference, energy limitations, etc. Existing static management solutions cannot handle frequent status transitions, leading to a rigid management link. In addition, airship platforms carry a wide variety of payload devices. Existing solutions typically involve hard-coding or deep customization for specific device types. Integrating new types of devices requires modifying the core code of the network management system and redeploying, resulting in long development cycles and hindering rapid device management. When the management link is abnormal, the recovery mechanisms of existing solutions are often immature, making it difficult to guarantee the continuity of management functions under unreliable communication links. Therefore, there is an urgent need for a device status management method that can adapt to the dynamic environment of high-altitude platforms, support flexible and rapid access of multiple types of load devices, and possess high reliability and performance, in order to address the shortcomings of existing technical solutions in the above-mentioned application scenarios. Summary of the Invention

[0004] In view of this, the present invention proposes a solution to address the problems existing in the prior art.

[0005] To achieve the above objectives, this invention proposes a method for dynamic switching of equipment states in an OMC system for a multi-load airship platform, characterized by the following steps: The device management component invokes the access adaptation layer for operation commands of the target device; The access adaptation layer instantiates the corresponding adapter module according to the device type of the target device; The adapter module establishes a session connection with the device agent associated with the target device based on a configuration policy. The configuration policy includes the OMC Server actively connecting to the device agent or the device agent actively connecting to the OMC Server. After a session connection is successfully established, a heartbeat monitoring mechanism is initiated to maintain and monitor the link status. Based on the results of the heartbeat monitoring mechanism and device management instructions, the management state and link state of the target device are dynamically switched; wherein, the management state includes initialization, activation, deactivation and destruction, and the link state includes initialization, connection and disconnection.

[0006] Furthermore, establishing a session connection between the device agent associated with the target device specifically includes: The adapter module obtains the connection parameters of the device proxy from the device information table. The connection parameters include IP address, port number and authentication information. If configured in Server active mode, the adapter module acts as a client and initiates a TCP connection request to the listening port of the device proxy. If configured in Proxy active mode, the adapter module acts as a server, listening on a specified port and accepting connection requests from the device proxy. After the physical link is established, security authentication is performed, and the session context is initialized after successful authentication.

[0007] Furthermore, the dynamic switching of the management state and link state of the target device includes a device activation process: Upon receiving the device activation command, the management status of the target device is marked as active. After the adapter module successfully establishes a session connection and starts heartbeat monitoring, the management status of the target device is updated to active, and the link status is updated to connected. When the management status is active and the link status is connected, management commands can be sent to the target device through the established session channel, and status data reported by the target device can be received.

[0008] Furthermore, the dynamic switching of the management state and link state of the target device includes a device deactivation process: Upon receiving a device deactivation command, the adapter module disconnects the session connection with the device agent and stops heartbeat monitoring; Update the management status of the target device to deactivated and the link status to disconnected; In the deactivated state, management commands are prohibited from being issued to the target device and data reports are not received from it.

[0009] Furthermore, the method also includes an exception handling and state recovery process: During device activation, if the heartbeat monitoring mechanism detects a link anomaly, it will automatically set the link status of the target device to disconnected and trigger an alarm event report. When the link is restored, the device re-reports its status, and the corresponding alarms are cleared and converted to historical alarms.

[0010] Furthermore, the adapter module executes device-specific adaptation logic through a dynamic plug-in loading framework; The dynamic plugin loading framework loads the corresponding JavaScript plugin according to the device type to implement at least one of the functions of session management, command conversion and data parsing. The JavaScript plugin is executed through a JavaScript engine and supports hot reloading.

[0011] Furthermore, the device activation command is asynchronously sent through a message queue, specifically including: After the front end initiates an activation request, the device management component marks the device status as active, encapsulates the activation task parameters into a message and sends it to the message queue topic, and at the same time returns a response to the front end indicating that the operation has been accepted. The background command processor microservice instance listens to the message queue topic, and after obtaining the message, executes the actual connection establishment logic; Once the connection is established, the execution result will be published to the result notification topic, which will be listened to by the device management component to update the final state of the device accordingly.

[0012] Furthermore, the method is implemented based on a microservice architecture, utilizing service registration and discovery, load balancing and circuit breaker mechanisms, and using distributed caching and message queues to cache device status and broadcast status change events.

[0013] Furthermore, the method integrates a role-based access control mechanism to authenticate and verify the permissions of users performing state switching operations, and to record the operation process in a secure log.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention achieves smooth switching and real-time monitoring of device states through a hierarchical management model and dynamic plug-in loading technology. The dynamic management mechanism enables the system to adapt to the complex and ever-changing working environment of the airship platform, quickly responding to changes in device states and improving system flexibility and response speed. During the dynamic switching of device states, this invention fully considers abnormal situations and system fault tolerance. When the heartbeat monitoring mechanism detects a link anomaly, the system automatically sets the link state to disconnected and triggers an alarm event report, while also supporting an automatic alarm recovery mechanism. Furthermore, the OMC system is implemented based on a microservice architecture, utilizing service registration and discovery, load balancing, and circuit breaker mechanisms to ensure that a single service failure does not affect the overall state switching process. Distributed caching and message queues cache device state and broadcast state change events, ensuring data consistency among components. Attached Figure Description

[0015] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings: Figure 1 This is a schematic diagram of the overall process of the dynamic switching method for the OMC system equipment status of the multi-load airship platform proposed in this invention. Detailed Implementation

[0016] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0017] This embodiment proposes a method for dynamic switching of equipment states in the OMC system of a multi-load airship platform, such as... Figure 1As shown, the method described in this embodiment is based on the design principles and architecture of the Operations and Maintenance Center (OMC) in a High Altitude Platform Station (HAPS) terahertz communication system. It is essentially a dynamic management mechanism designed to achieve flexible, efficient, and reliable status management of various payload devices at both the remote and near ends. The core of this method lies in achieving smooth switching and real-time monitoring of device states through a layered management model, microservice architecture, device access adaptation framework, and dynamic plug-in loading technology, ensuring stable system operation and rapid response in complex environments. Dynamic switching of device states involves not only lifecycle management such as device activation, deactivation, and destruction, but also real-time monitoring and alarm handling of device link states, thus forming a complete device status management system.

[0018] In the OMC system, dynamic device state switching is primarily based on a hierarchical device management model. Each managed device is identified by a unique device identifier (DN), consisting of the system ID (sysId), device type ID (devTp), and device ID (devNo), ensuring the accuracy and scalability of device management. Device states mainly include four management states: initialization, activation, deactivation, and destruction; and three link states: initialization, connection, and disconnection. Dynamic device state switching relies on the coordinated operation of various components within the OMC system, including device management, topology management, configuration management, performance statistics, alarm management, access adaptation, and distributed caching and message queue services.

[0019] In a preferred embodiment, the dynamic switching of device status is triggered by maintenance personnel through the OMC's web interface or mobile app. They select the target device in the device management interface and perform activation or deactivation operations. Upon system startup, the device management component initializes device type and model information, loads the device configuration model, alarm model, and performance model from the persistent database, and caches them in a distributed cache to improve access efficiency. When a user creates a device, the device object is created and is in an initialized state. At this time, the device only stores basic information, including device name, IP address, port, and device description, but has not yet established a communication link with the device agent. The device activation process is a crucial step in the status switching. After the user initiates the activation command, the device management component calls the access adaptation layer to instantiate the corresponding adapter module based on the device type.

[0020] The adapter module is responsible for establishing a session connection with the device agent OMC Proxy. The connection methods include OMCServer actively connecting to the Proxy and the Proxy actively connecting to the listening port of OMC Server. The specific process is as follows: When the OMC Server receives the device activation command, the device management component calls the access adaptation layer to locate the corresponding adapter instance based on the target device's type identifier. The adapter first retrieves the associated proxy information for the device from the device information table, including the proxy IP address, port number, authentication account, and password. Depending on the configuration policy, connection establishment can adopt two modes: if configured in Server-initiated mode, the adapter acts as a client, initiating a TCP connection request to the proxy's listening port via Socket programming; if configured in Proxy-initiated mode, the adapter acts as a server, listening for connection requests from the proxy on a specific port. During connection establishment, both parties first perform a secure authentication handshake. The adapter encapsulates the device authentication information into an authentication message according to the agreed format and sends it. After successful proxy verification, a success response is returned, thus formally establishing the physical link.

[0021] Building upon the physical link, the adapter further initializes the session context, including creating a session ID, maintaining heartbeat parameters, and setting timeout. After successful session creation, the adapter automatically starts an independent heartbeat maintenance thread, periodically sending heartbeat detection messages to the agent at configured intervals. Simultaneously, the adapter returns a successful session establishment notification to the device management component, triggering an update of the device status to "active" and the link status to "connected." Thereafter, this session channel is used to transmit various management commands and status data. The entire connection process is uniformly encapsulated by the adapter, transparent to upper-layer business modules. Business modules only need to use the device DN number to invoke the corresponding session to send and receive data, achieving unified management and dynamic maintenance of device connections.

[0022] After the session connection is established, the adapter module initiates a heartbeat handshake mechanism, periodically sending heartbeat messages to monitor the link status. If the heartbeat response is normal, the device link status is set to "Link," and the device management status changes to "Active." In the active state, the device can receive configuration commands, performance acquisition tasks, and alarm clearing instructions issued by the OMC, and can report status data, performance metrics, and alarm information in real time. Specifically, the configuration management component issues device configurations via MML commands. These commands are dynamically converted into a format recognizable by the device agent using a JavaScript plugin at the adaptation layer, and then sent to the device through the established session. The performance statistics component issues measurement tasks, and the device collects and reports performance data at specified intervals. The OMC parses the data and persists it to the database for use in threshold alarm detection. The alarm management component monitors the alarm events reported by the device in real time, updates the alarm pool cache, and performs alarm forwarding or root cause analysis according to rules.

[0023] Device deactivation is another important state transition scenario. After a user initiates a deactivation command, the device management component notifies the access adaptation layer to disconnect the session connection with the device agent, stop heartbeat monitoring, and set the device management state to Unactive, while the link state becomes Broken. In the deactivated state, the device cannot receive management commands or report any data, but the device information is still retained in the system for later querying or reactivation. If maintenance personnel decide to permanently remove the device, they can perform a deletion operation. At this time, the device record is moved to the history table, the device state becomes Deleted, and it is unrecoverable. This dynamic state transition mechanism ensures the flexibility and data integrity of device management, avoiding data loss due to accidental operations.

[0024] As a preferred embodiment, the dynamic device state switching method also considers abnormal situations and system fault tolerance. During device activation, if heartbeat monitoring fails or the link is abnormal, the system automatically sets the link state to Broken and triggers an alarm report. The alarm management component generates active alarms according to the alarm model definition and notifies the operations and maintenance personnel. Simultaneously, the system supports an automatic alarm recovery mechanism; when the link is restored, the device re-reports its state, the alarm is cleared, and it is converted to a historical alarm. Furthermore, the OMC system achieves high availability through a microservice architecture. Specifically, the OMC system uses Spring Cloud's Eureka service registration and discovery, Ribbon load balancing, and Hystrix circuit breaker functionality to ensure that a single service failure does not affect the overall state switching process. Distributed caching and message queues are used to cache device state and broadcast state change events, ensuring data consistency among components.

[0025] In terms of technical implementation, dynamic device state switching relies on a dynamic plugin loading framework in the access adaptation layer. The adaptation layer uses PNP plugins, employing JavaScript to write device-specific adaptation logic, such as command conversion, data parsing, and session management. These scripts are stored as files in the resource directory and dynamically loaded according to device type. For example, during device activation, the adapter loads the corresponding device-type JS plugin and calls its session establishment function; during configuration distribution, it calls the command conversion function to convert MML to the device protocol format. The JS plugin executes through a Java scripting engine (such as Nashorn or GraalVM), supporting hot reloading and compilation-free updates, greatly improving the system's scalability and maintainability. Simultaneously, the adaptation layer provides a unified plugin management interface to ensure the security and efficiency of plugin loading.

[0026] Security and performance optimization are crucial components of the dynamic device state transition process. The system employs a role-based access control mechanism to ensure that only authorized users can perform state transition operations. Upon user login, a security authentication service verifies user identity and permissions, and operation and security logs are recorded in detail for auditing purposes. During data transmission, critical information such as passwords and configuration commands are protected through encryption technology to prevent theft or tampering.

[0027] In terms of performance, the system utilizes distributed caching to reduce database access pressure and employs message queues for asynchronous processing to avoid blocking during state transitions. Specifically, when maintenance personnel perform device activation operations on the front-end interface, the system does not synchronously wait for the entire activation process to complete. Instead, it uses an asynchronous processing mechanism based on message queues to improve system response speed and overall throughput. The specific implementation process is as follows: After the front-end interface initiates an activation request, the device management component does not immediately call the access adaptation layer to establish a connection. Instead, it first updates the target status of the device in the database to "activating." Subsequently, it encapsulates the core parameters of the activation task, such as the device DN number, agent information, and session parameters, into a structured message object. This message object is immediately sent to a dedicated message queue topic and returns an immediate response of "processing" to the front-end, thereby releasing the web request thread and avoiding interface lag caused by network latency or slow device response.

[0028] Meanwhile, in the system background, one or more microservice instances dedicated to handling device activation command processing are continuously listening to the aforementioned message queue topic. Once a new activation message arrives, one of the instances acquires the message through a contention-based consumption mechanism. The command processor then executes the actual, time-consuming activation logic, locating and invoking the corresponding access adapter module based on the device type in the message. The adapter, in turn, performs operations such as establishing a TCP session with the device agent, performing security authentication, and starting a heartbeat thread, based on the IP address and port carried in the message. Throughout this process, the initiator and processor of the command are completely decoupled.

[0029] Finally, once the backend processor has established the actual connection, it publishes the final execution result to another result notification topic. The device management component listens to this result topic and updates the final device status in the database accordingly. The system also pushes the result to the frontend interface in real time, notifying the user of the final operation result. Through this mechanism, the system achieves separation of request and processing, ensuring the efficiency and stability of the core process.

[0030] This method demonstrates a high degree of automation and intelligence in practical applications. In OTA upgrade management, device status switching and software update processes are tightly integrated. After maintenance personnel upload the new firmware, they issue upgrade commands via the OMC. The device agent receives the commands, verifies the version information, and then downloads the firmware package. During the upgrade process, the device temporarily enters a deactivation state to ensure upgrade stability; after the upgrade is complete, the device is reactivated and reports the new version status. Furthermore, the system supports AI-based alarm root cause analysis. By training models using historical alarm data, it automatically identifies the root causes of abnormal device status, reducing false alarms and missed alarms, and improving maintenance efficiency.

[0031] In summary, this method achieves refined management and real-time monitoring of device status by integrating layered management, microservice architecture, dynamic plug-in technology, and security mechanisms. This method not only improves system reliability and scalability but also reduces operational complexity, making it suitable for the diverse needs of HAPS platforms in scenarios such as long-distance communication, environmental monitoring, and national defense security. The entire method design fully considers the dynamic characteristics and anomaly handling in actual deployments, ensuring stable system operation under high-pressure environments and providing a solid technical foundation for multi-load management of airship platforms.

[0032] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for dynamic switching of equipment status in an OMC system of a multi-load airship platform, characterized in that, Includes the following steps: The device management component invokes the access adaptation layer for operation commands of the target device; The access adaptation layer instantiates the corresponding adapter module according to the device type of the target device; The adapter module establishes a session connection with the device agent associated with the target device based on a configuration policy. The configuration policy includes the OMC Server actively connecting to the device agent or the device agent actively connecting to the OMC Server. After a session connection is successfully established, a heartbeat monitoring mechanism is initiated to maintain and monitor the link status. Based on the results of the heartbeat monitoring mechanism and device management instructions, the management state and link state of the target device are dynamically switched; wherein, the management state includes initialization, activation, deactivation and destruction, and the link state includes initialization, connection and disconnection.

2. The method according to claim 1, characterized in that, The establishment of a session connection between the device agent associated with the target device specifically includes: The adapter module obtains the connection parameters of the device proxy from the device information table. The connection parameters include IP address, port number and authentication information. If configured in Server active mode, the adapter module acts as a client and initiates a TCP connection request to the listening port of the device proxy. If configured in Proxy active mode, the adapter module acts as a server, listening on a specified port and accepting connection requests from the device proxy. After the physical link is established, security authentication is performed, and the session context is initialized after successful authentication.

3. The method according to claim 1, characterized in that, The dynamic switching of the management status and link status of the target device includes the device activation process: Upon receiving the device activation command, the management status of the target device is marked as active. After the adapter module successfully establishes a session connection and starts heartbeat monitoring, the management status of the target device is updated to active, and the link status is updated to connected. When the management status is active and the link status is connected, management commands can be sent to the target device through the established session channel, and status data reported by the target device can be received.

4. The method according to claim 1, characterized in that, The dynamic switching of the management state and link state of the target device includes a device deactivation process: Upon receiving a device deactivation command, the adapter module disconnects the session connection with the device agent and stops heartbeat monitoring; Update the management status of the target device to deactivated and the link status to disconnected; In the deactivated state, management commands are prohibited from being issued to the target device and data reports are not received from it.

5. The method according to claim 1, characterized in that, The method also includes an exception handling and state recovery process: During device activation, if the heartbeat monitoring mechanism detects a link anomaly, it will automatically set the link status of the target device to disconnected and trigger an alarm event report. When the link is restored, the device re-reports its status, and the corresponding alarms are cleared and converted to historical alarms.

6. The method according to claim 1, characterized in that, The adapter module executes device-specific adaptation logic through a dynamic plug-in loading framework. The dynamic plugin loading framework loads the corresponding JavaScript plugin according to the device type to implement at least one of the functions of session management, command conversion and data parsing. The JavaScript plugin is executed through a JavaScript engine and supports hot reloading.

7. The method according to claim 1, characterized in that, Device activation commands are sent asynchronously via a message queue, specifically including: After the front end initiates an activation request, the device management component marks the device status as active, encapsulates the activation task parameters into a message and sends it to the message queue topic, and at the same time returns a response to the front end indicating that the operation has been accepted. The background command processor microservice instance listens to the message queue topic, and after obtaining the message, executes the actual connection establishment logic; Once the connection is established, the execution result will be published to the result notification topic, which will be listened to by the device management component to update the final state of the device accordingly.

8. The method according to claim 1, characterized in that, The method is implemented based on a microservice architecture, utilizing service registration and discovery, load balancing and circuit breaker mechanisms, and using distributed caching and message queues to cache device status and broadcast status change events.

9. The method according to claim 1, characterized in that, The method integrates a role-based access control mechanism to authenticate and verify the permissions of users performing state switching operations, and to record the operation process in a secure log.

Images