Multi-load airship platform OMC system equipment identification and management 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 identification and management method, which comprises the following steps of: distributing an equipment identification number for each managed equipment on an airship platform, pre-defining a unified management model for each equipment type, and adopting a layered micro-service distributed system architecture, an equipment management function is realized through cooperation among layers; and in the equipment access adaptation layer, a JavaScript-based plug-and-play plug-in framework is adopted, and a JS script corresponding to an equipment type is dynamically loaded and executed, so that protocol adaptation and format conversion of a management command and reported data are realized. The core problem of unified management of heterogeneous equipment in a multi-load airship platform is solved by introducing a hierarchical equipment identification system, a model-driven unified management framework, a micro-service architecture and a JS plug-in adaptation technology.

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 identifying and managing equipment in the OMC system of a multi-load airship platform. Background Technology

[0002] High Altitude Platform Station (HAPS) airships, as an emerging communication and remote sensing platform, rely on the collaborative operation of various heterogeneous payload devices integrated on the platform. However, different types of payload devices often come from different manufacturers, with varying interface protocols, forms, and functions, posing a significant challenge to the unified operation and maintenance management of the platform.

[0003] In existing technologies, traditional network management systems are mostly designed for homogeneous terrestrial networks, and their management methods have significant shortcomings when dealing with high-altitude, heterogeneous, and dynamic environments. Firstly, in terms of device identification, simple or unstructured identifiers are often used, lacking a systematic hierarchical classification of device ownership, type, and instance, leading to ambiguous device positioning, chaotic topology relationships, and difficulty in supporting precise batch operations and resource authorization. Secondly, in terms of management methods, hard-coding or static configuration is typically used to interface with specific devices, resulting in a rigid system architecture. Each time a new or upgraded payload device type is added, the core code needs to be modified, the entire system recompiled and redeployed, resulting in long development cycles, high upgrade costs, poor system flexibility, and an inability to adapt to the rapid iteration needs of payload devices. Furthermore, existing systems also have limitations in device protocol adaptation, fine-grained status management, and horizontal scalability, making it difficult to achieve efficient and automated full lifecycle operation and maintenance. Summary of the Invention

[0004] In view of this, the present invention proposes a device identification and management method for OMC system of multi-load airship platform. By introducing a hierarchical device identification system, a model-driven unified management framework, a microservice architecture and JS plug-in adaptation technology, the core problem of unified management of heterogeneous devices in multi-load airship platform is solved.

[0005] To achieve the above objectives, this invention proposes a method for equipment identification and management in an OMC system for a multi-load airship platform, comprising: Assign a device identification number to each managed device on the airship platform. The device identification number is in the format sysId=x, devTp=y, devNo=z, where sysId is the system or platform number to which the device belongs, devTp is the device type number, and devNo is the unique number of the device under its system and type. A unified management model is predefined for each device type. The management model includes at least a configuration model, an alarm model, and a performance model. Based on the management model, the device is managed in a unified manner driven by metadata. A layered microservice distributed system architecture is adopted, which includes at least a device access adaptation layer, a microservice layer, and a front-end presentation layer, and the device management function is realized through the cooperation between the layers. In the device access adaptation layer, a plug-and-play plugin framework based on JavaScript is adopted. By dynamically loading and executing JS scripts corresponding to the device type, the protocol adaptation and format conversion of management commands and reported data are realized.

[0006] Furthermore, the configuration model is defined using the human-machine language MML, which includes a set of configuration commands supported by the device. The definition of each command includes a command code and a list of command parameters. The definition of each parameter includes a parameter name, data type, value range, and optionality.

[0007] Furthermore, the alarm model includes definitions of alarm events that the device may trigger, and the definition of each alarm event includes an alarm code, an alarm level, an alarm description, and a handling suggestion.

[0008] Furthermore, the performance model includes a set of performance indicators that the device needs to collect, and the definition of each performance indicator includes indicator number, indicator name, data type and unit.

[0009] Furthermore, the management model is loaded into a distributed cache during system initialization, providing metadata support for system front-end interface generation, business logic processing, and device access adaptation.

[0010] Furthermore, the JavaScript-based PNP plugin framework is specifically implemented as follows: A corresponding JS script plugin is developed for each device type, and the plugin encapsulates the protocol conversion logic for the corresponding device type; The device access adaptation layer dynamically loads and manages the JS script plugins through the plugin management engine; When it is necessary to issue management commands to the device, the corresponding function in the JS plugin is called to convert the commands in the system's unified format into a specific format that the device agent can recognize. When data is received from the device agent, the parsing function agreed upon in the JS plugin is called to convert the device-specific data into a standard data object in a unified format within the system.

[0011] Furthermore, the method also includes modeling and managing the management status and link status of the device: The device management states include initialization, activation, deactivation, and destruction states, and the transition conditions between states are defined. The device link status includes initialization, connection, and disconnection statuses, and is dynamically maintained through a heartbeat detection mechanism.

[0012] Furthermore, the microservice layer includes multiple independent business microservices, including at least device management service, configuration management service, performance statistics service, alarm management service, security management service, and log management service. The services communicate with each other through RESTful interfaces or message brokers.

[0013] Furthermore, the security management service implements access control based on the enhanced role-access control (RBAC) model, by defining four elements: users, roles, operations, and resources, and establishing binding relationships between users and roles, roles and operations, and users and resources.

[0014] Furthermore, the system supports deployment expansion from single-node to multi-node clusters, and achieves plug-and-play compatibility with new device types through the PNP plugin framework.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention achieves precise location and hierarchical management of all devices through a three-segment unique device identifier, laying the foundation for topology organization, access control, and batch operations, greatly improving management accuracy and efficiency. Secondly, it employs metadata-driven configuration, alarm, and performance models to abstract and standardize device management logic. The system dynamically generates interfaces and processes business logic through these models, enabling flexible expansion of device types. Adding new device types requires no modification to the core code, significantly reducing development complexity and maintenance costs. Furthermore, this invention decouples device-specific protocol parsing logic from the system core using a JavaScript-based PNP plugin framework, achieving dynamic adaptation through hot-loadable scripts. This gives the system plug-and-play compatibility with different device interface protocols, supports online updates and smooth evolution, and greatly enhances the system's adaptability and flexibility in complex heterogeneous environments. Attached Figure Description

[0016] 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 OMC system equipment identification and management method for multi-load airship platforms proposed in this invention. Detailed Implementation

[0017] 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.

[0018] This embodiment proposes a method, such as... Figure 1 As shown, the purpose of this embodiment is to achieve unified, efficient, and intelligent operation and maintenance management throughout the entire lifecycle of various heterogeneous payload devices carried by High Altitude Platform Station (HAPS) airships, including but not limited to terahertz communication equipment, optical remote sensing payloads, navigation enhancement equipment, and spaceborne phased array equipment. By constructing an equipment identification system, a metadata-driven management model, a layered software architecture, and a dynamic adaptation mechanism, it achieves accurate identification, status monitoring, configuration control, performance analysis, fault early warning, and security management of widely distributed and diverse payload devices in complex network environments.

[0019] The operation of the entire system begins with the unique identification of each physical or logical managed object. This embodiment designs an extensible device unique identifier, called the Device Identifier (DN), whose format strictly follows the specification sysId=x, devTp=y, devNo=z. Here, sysId represents the system or platform number to which the device belongs, used to distinguish different airship platforms or ground station systems; devTp is the device type number, precisely corresponding to the type and model of the device, such as Camera210 representing a specific model of remote sensing camera, and Send110 representing a terahertz optical transmitter; devNo is the unique serial number of this type of device within its system. This naming rule not only ensures the uniqueness of each device's identity within the entire management domain but also naturally forms a management hierarchy for devices, laying the foundation for subsequent device discovery, topology organization, permission allocation, and batch operations. For example, the first remote sensing camera deployed on the airship platform numbered haps101 would have its DN assigned the values ​​sysId=haps101, devTp=Camera210, devNo=c01. This DN number will serve as the device's digital identity card, and will be used throughout all interactive processes, from device registration and activation to every configuration distribution, performance data collection, alarm reporting, and even the final decommissioning of the device, to ensure the accurate association and traceability of management commands and data records.

[0020] Based on establishing the unique identity of each device, this embodiment introduces a model-driven management paradigm. The system predefines a detailed management model for each device type (devTp), including a configuration model, an alarm model, and a performance model. The configuration model uses the human-machine interface language (MML) to describe all configuration commands supported by this type of device. Each command explicitly defines its command code, command name, description, and a set of parameters. Each parameter further specifies its parameter name, data type, value range, whether it is required, default value, and parameter description. The alarm model defines all alarm events that this type of device may trigger. Each alarm event is identified by a unique alarm code and associated with an alarm title, detailed description, preset severity level, and recommended handling suggestions. The performance model specifies the set of performance indicators that the device needs to collect and report. Each performance indicator defines its indicator number, indicator name, description, data type, unit, and possible value range. All model information is abstracted and defined during the system design phase and persistently stored in the system database. When the OMC system starts, the model management module loads the model definitions into a distributed cache, providing unified metadata support for dynamic generation of the system's front-end interface, processing of business logic, and protocol conversion in the device adaptation layer. This model-driven architecture enables the system to handle different types of devices in a standardized way, greatly enhancing the system's scalability and maintainability. When a new type of payload device needs to be connected, maintenance personnel only need to define its corresponding management model in the system without modifying the system's core business code.

[0021] To achieve the aforementioned management capabilities, the OMC system adopts a layered, microservice-based distributed system architecture. Overall, the system follows a B / S (Browser / Server) model. The front-end presentation layer is built on a modern web framework, providing users with a graphical interface through a browser for functions such as topology management, configuration management, performance management, alarm management, security management, and log management. The server-side uses Java and is built on mature microservice frameworks such as Spring Boot and Spring Cloud. Architecturally, from bottom to top, it can be divided into a device access adaptation layer, a data persistence layer, a distributed service framework layer, a microservice layer, and a web container and application layer. The device access adaptation layer acts as a bridge between the system and specific devices, responsible for establishing and managing communication links with the OMC agent deployed on the payload device side or aggregation node, and executing management commands and converting the format of reported data. The data persistence layer utilizes an ORM framework to store massive amounts of structured data such as device information, configuration data, performance metrics, alarm records, and operation logs in a MySQL or PostgreSQL relational database. Simultaneously, it uses NoSQL databases such as Redis as a distributed cache to store session information, model data, alarm pools, and other frequently accessed information to improve system access performance. The distributed service framework layer integrates Kafka or RabbitMQ as a message queue and bus to achieve asynchronous and decoupled communication between microservices; it also provides infrastructure support such as service registration and discovery, client load balancing, and configuration center. The microservice layer is the core of the system's business logic, consisting of a series of independently deployed microservices with single responsibilities. These include a security authentication service responsible for user authentication and authorization, a device management service managing device lifecycles, a configuration management service handling configuration distribution, a performance statistics service collecting and analyzing metrics, an alarm management service receiving and processing alarm events, a log service recording and querying various logs, and an API gateway service providing external integration capabilities. These services collaborate through RESTful APIs or message topics to jointly complete all the business functions of the OMC system. The web container and application layer are responsible for hosting the web application, handling HTTP / HTTPS requests, and routing front-end user operations to the corresponding back-end microservices for processing.

[0022] The device access adaptation layer is crucial for achieving device compatibility and scalability in this method. This embodiment proposes a JavaScript-based PNP plug-and-play plugin framework. For each device type, there are one or more corresponding JS script files, which encapsulate the details of specific protocol interactions with that type of device. The system implements a plugin management engine in the device access adaptation layer. This engine dynamically loads the corresponding JS plugins when the system starts or the device type changes. When the OMC server needs to issue a configuration command to the device, such as a standard MML command, the configuration management service calls the adaptation layer interface. Based on the target device type, the adaptation layer locates and calls the function with the same name as the command code in the corresponding JS plugin, converting the unified MML command object and its parameters into a specific format that the device agent can recognize, including binary byte streams, JSON objects, or XML messages. Conversely, when a device agent reports performance data or alarm information via the communication link, the raw, device-specific reported data is transmitted to the adaptation layer. The adaptation layer calls the parsing function agreed upon in the JS plugin to parse the raw data and convert it into standardized data objects that conform to the system's internal performance or alarm model definition. These objects are then used by the upper-layer performance statistics service or alarm management service for subsequent processing, persistence, and display. This plug-in design extracts the device-specific protocol parsing logic from the system's core code, presenting it as a hot-loadable, non-compiled script, improving the development efficiency and flexibility of device access. When a new device type is added or the interface protocol of an existing device is upgraded, developers only need to write or update the corresponding JS plugin. Without restarting the OMC core service or releasing a version, the adaptation logic can be updated and effective in real time, achieving smooth online evolution of the system and strong device compatibility.

[0023] Regarding dynamic management features, this method provides detailed modeling of device management status and communication link status. Device management status includes initialization, activation, deactivation, and destruction. A newly registered device is initially in the initialization state, a brief state indicating that the device has been entered into the system but a management connection has not yet been established. After the maintenance personnel perform the activation operation through the management interface, the OMC system will attempt to establish a stable management session with the device agent through the adaptation layer. After the session is successfully established and an initial handshake or heartbeat detection may be initiated, the device status changes to active. At this time, the system can normally issue management commands to it and receive the operational data actively reported by it. When the device needs to be temporarily removed from management, the maintenance personnel put it into the deactivation state, and the system will actively disconnect from the management session, suspending data collection and command issuance to the device. For devices that are determined to no longer be managed, a destruction operation is performed, the system moves its record to the history archive, and logically deletes the device. Parallel to the device management status is the device link status, which focuses more on the health of the physical or logical communication channel, including initialization, connection, and disconnection. Link status is monitored through periodic heartbeat handshake messages or data stream continuity, dynamically reflecting the actual connectivity of the management channel. Even if a device is active, if the heartbeat times out or communication is interrupted, its link status will be marked as broken, and the system will generate a corresponding link alarm to remind maintenance personnel to pay attention to the network status.

[0024] In terms of the specific implementation of core management functions, the configuration management module allows operations and maintenance personnel to issue configuration commands for individual devices or batches of devices through a dynamically generated MML command interface. Commands support multiple modes including immediate execution, scheduled execution, and batch execution. The execution process follows an overall flow of permission verification, command conversion, issuance and execution, result feedback, and parsing. The performance management module allows users to create performance measurement tasks, defining the types of metrics to be collected, the granularity of collection, and the reporting cycle. After task activation, the system periodically receives performance data reported by device agents, parses it through a JS plugin, performs persistent storage, multi-dimensional statistical analysis, and visualization, and supports threshold alarm triggering based on preset thresholds. The alarm management module is the core of the system's fault management, updating the current alarm list and historical alarm records by receiving alarm and recovery messages reported by devices in real time. Furthermore, the system maintains an alarm pool based on a distributed cache to ensure processing efficiency and consistency during high-concurrency alarm reporting. Alarms support manual confirmation, deconfirmation, and clearing operations, and employ an alarm rule engine to support alarm filtering, delay, merging, automatic clearing, and forwarding notifications via email and SMS. Furthermore, the system actively explores rule-based and artificial intelligence algorithm-based alarm root cause analysis, aiming to quickly locate the root cause of faults from a large number of related alarms and improve the efficiency of operation and maintenance troubleshooting. The security management module is based on and enhanced with the Role-Based Access Control (RBAC) model, enabling fine-grained authorization of users, roles, operations, and resources. Each user is assigned one or more roles, and each role is bound to a set of allowed operations. The binding of users to resources determines the scope of operation permissions. All user logins, logouts, and critical operations are recorded in detail in the security logs, meeting security audit requirements. The log management module uniformly collects, stores, and manages system logs, operation logs, and security logs, providing flexible query, export, and archiving functions, offering complete data traceability capabilities for system operation and maintenance and problem localization.

[0025] In terms of system scalability, compatibility, and deployment, the PNP plugin framework at the device access layer allows the system to easily expand its support for new device types, achieving plug-and-play functionality. Its microservice architecture inherently possesses horizontal scalability, enabling the addition of service instances to handle ever-increasing management scale and data load. The system design also fully considers compatibility with existing device management systems, using an adaptation layer on the OMC side to complete interface protocol conversion and adaptation, minimizing the need for modifications to managed devices. Regarding deployment modes, the OMC server supports a smooth transition from single-node deployment to multi-node cluster deployment, flexibly adapting to different stages of operation and maintenance needs, from laboratory debugging and small-scale pilot projects to large-scale commercial applications. Security is integrated into every aspect of the system design, encompassing not only fine-grained access control but also multiple layers such as encrypted communication transmission, encrypted storage of sensitive data, software version integrity verification, and anti-virus and anti-attack measures, constructing a comprehensive security protection system.

[0026] In summary, the method described in this embodiment achieves refined, automated, and intelligent operation and maintenance management of various types of load devices in complex high-altitude platforms by constructing a complete technical solution from device identification, model definition, system architecture to dynamic adaptation. This method not only effectively solves the problem of unified management of heterogeneous devices, but its model-driven and plug-in design also endows the system with flexibility and scalability, providing crucial management support for the reliable, efficient, and long-term stable operation of the high-altitude platform communication system.

[0027] 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 identification and management of OMC system equipment of multi-load airship platform, characterized in that, The method comprises the following steps: allocating a device identification number for each managed device on the airship platform, the device identification number being in the format of sysId=x, devTp=y, devNo=z, wherein sysId is the system or platform number to which the device belongs, devTp is the device type number, and devNo is the unique number of the device under the system and type; defining a unified management model for each device type, the management model comprising at least a configuration model, an alarm model, and a performance model, and performing metadata-driven unified management of the device based on the management model; adopting a hierarchical micro-service distributed system architecture, the architecture comprising at least a device access adaptation layer, a micro-service layer, and a front-end display layer, and realizing device management functions through cooperation between the layers; in the device access adaptation layer, adopting a JavaScript-based plug-and-play plug-in framework, and realizing protocol adaptation and format conversion of management commands and reported data by dynamically loading and executing JS scripts corresponding to the device type.

2. The method of claim 1, wherein, The configuration model is defined by using a man-machine language MML, and comprises a configuration command set supported by the device, the definition of each command comprising a command code, a command parameter list, the definition of each parameter comprising a parameter name, a data type, a value range, and selectivity.

3. The method of claim 1, wherein, The alarm model comprises definitions of alarm events that can be triggered by the device, the definition of each alarm event comprising an alarm code, an alarm level, an alarm description, and a processing suggestion.

4. The method of claim 1, wherein, The performance model comprises a performance index set that needs to be collected by the device, the definition of each performance index comprising an index number, an index name, a data type, and a unit.

5. The method of claim 1, wherein, The management model is loaded into a distributed cache during system initialization, and provides metadata support for system front-end interface generation, business logic processing, and device access adaptation.

6. The method of claim 1, wherein, The JavaScript-based PNP plug-in framework comprises the following specific implementations: developing a corresponding JS script plug-in for each device type, the plug-in encapsulating protocol conversion logic of the corresponding type of device; the device access adaptation layer dynamically loading and managing the JS script plug-in through a plug-in management engine; when a management command needs to be issued to the device, a corresponding function in the JS plug-in is called to convert the command in a uniform format within the system into a specific format recognizable by the device agent; when data reported by the device agent is received, a designated parsing function in the JS plug-in is called to convert the data in the specific format of the device into a standard data object in the uniform format within the system.

7. The method of claim 1, wherein, The method further comprises modeling and managing the management state and link state of the device: the device management state comprises initialization, activation, deactivation, and destruction states, and transition conditions between the states are defined; the device link state comprises initialization, connection, and disconnection states, and is dynamically maintained through a heartbeat detection mechanism.

8. The method of claim 1, wherein, The micro-service layer comprises a plurality of independent business micro-services, at least comprising a device management service, a configuration management service, a performance statistics service, an alarm management service, a security management service, and a log management service, and the services communicate with each other through Restful interfaces or message middleware.

9. The method of claim 8, wherein, The security management service implements permission management based on an enhanced role-based access control (RBAC) model, defines four elements of user, role, operation and resource, and establishes binding relationships between the user and the role, the role and the operation, and the user and the resource.

10. The method of claim 1, wherein, The system supports deployment expansion from a single node to a multi-node cluster, and realizes plug-and-play compatible support for newly added device types through the PNP plug-in framework.

Images