Unified management method based on equipment model in airship platform OMC system

Abstract

The invention provides a unified management method based on an equipment model in an airship platform OMC system, and the method comprises the steps: constructing an equipment model for managed equipment of the OMC system; storing the equipment model; generating a management user interface according to the equipment model; receiving a management operation request through the management user interface, wherein the management operation request comprises an equipment identification code and a model command code; searching a corresponding equipment model through the equipment identification code, verifying the management operation request according to the searched equipment model, and converting the management operation request to obtain an intermediate instruction; converting the intermediate instruction into a native protocol message through an adaptation framework, and issuing the native protocol message to a managed device for control; and acquiring the collected data of the managed equipment, converting the collected data through the adaptive framework and performing conversion again, and displaying the data subjected to conversion again in the management user interface through the equipment model.

Description

Technical Field

[0001] This invention relates to the field of equipment management technology, and more specifically, to a unified management method based on equipment models in an airship platform OMC system. Background Technology

[0002] With the widespread application of communication, navigation, and remote sensing payloads on airship platforms, the Airship Operation and Maintenance Center (OMC) system needs to manage various types and protocols of equipment, including remote platform systems and payloads, near-end platform systems and equipment, and communication link equipment between the remote and near ends. Traditional OMC systems typically use hard-coded methods to implement equipment management functions. Each time a new type of equipment is added or a device protocol is updated, the core system code needs to be modified, and the user interface and interfaces need to be redeveloped, resulting in long system development cycles, high maintenance costs, and poor scalability.

[0003] Furthermore, existing equipment management systems often lack a unified equipment modeling methodology. The management logic for different devices is scattered across various modules of the system, resulting in inconsistent management interfaces, redundant data processing logic, and high system coupling, making it difficult to achieve true unified management. Especially on complex platforms like airships with high dynamics and multiple loads, the variety of equipment and the strong heterogeneity of protocols make it difficult for traditional management methods to meet the needs of efficient, flexible, and scalable operation and maintenance.

[0004] Therefore, there is an urgent need for a unified management method that can achieve standardized, automated, and scalable equipment management in order to improve the operation and maintenance efficiency and system adaptability of the airship platform OMC system. Summary of the Invention

[0005] In view of this, the present invention proposes a unified management method based on the device model in the OMC system of the airship platform to solve the problems existing in the prior art.

[0006] To achieve the above objectives, this invention proposes a unified management method based on a device model in the OMC system of an airship platform, including: For the managed devices in the OMC system, a device model is constructed; the device model is stored; the device model corresponds to the device type; For the aforementioned device model, a dynamic driver is used to generate a management user interface and application programming interface (API). The system receives management operation requests through the management user interface and application structure, wherein the management operation requests include device identification codes and model command codes. The corresponding device model is found by using the device identification code. The management operation request is then verified based on the found device model and converted into an intermediate instruction. The intermediate instructions are converted into native protocol messages through the adaptation framework and sent to the managed devices for control. The system acquires data from the managed devices, transforms the acquired data using an adaptation framework, and then further transforms it. Finally, it displays the transformed data in the management user interface based on the device model.

[0007] Optionally, the device model includes a configuration model, a performance model, and an alarm model. The configuration model describes the configuration attributes and constraints of the managed device, the performance model describes the monitored performance indicators of the managed device, and the alarm model describes the abnormal events of the managed device.

[0008] Optionally, in the device model, the configuration model includes a set of configuration commands, parameter definitions, and configuration constraints; the performance model includes a set of performance metrics, collected metadata, and metric relationships; and the alarm model includes alarm definitions, alarm attributes, and alarm associations.

[0009] Optionally, the process of generating the management user interface includes: Obtain the device type code, and search for the corresponding device model from the stored device models according to the device type to obtain the corresponding device model; Based on the corresponding device model, the management user interface and application programming interface are dynamically generated. Within the corresponding device model, based on the configuration model, a configuration management interface containing command selection and parameter input controls is dynamically rendered. Based on the performance model, a performance monitoring interface containing indicator selection and chart display is dynamically rendered. Based on the alarm model, an alarm list and statistical alarm interface are dynamically rendered.

[0010] Optionally, the process of storing the device model includes: The device model is stored in a physical storage location. For each modification to the device model, a globally unique model version snapshot is generated. The model version snapshot records the version history and change information. Assign a corresponding Uniform Resource Identifier to each element in the device model; Based on the Uniform Resource Identifier (URI), a model data mapping table is constructed, wherein the model data mapping table records the mapping rules between the URIs of elements in the model and their physical storage locations.

[0011] Optionally, the process of storing the device model further includes: A model relationship graph is constructed, which stores the business logic relationships between configuration, performance, and alarm model elements. The business logic relationships include triggering, constraint, and dependency relationships, which are used for parameter change impact analysis and alarm root cause analysis.

[0012] Optionally, the adaptation framework completes the protocol conversion by loading a protocol adapter corresponding to the device type, and the protocol adapter is in the form of a plug-in.

[0013] On the other hand, the present invention also provides a unified management system based on a device model in the airship platform OMC system for executing the above-described methods.

[0014] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention, by constructing configuration, performance, and alarm models, abstracts the control capabilities of all managed devices into structured data, forming a unified device model library, fundamentally solving the management complexity problem caused by device heterogeneity. Adopting a model-driven dynamic UI / API generation mechanism, adding new device types only requires defining their device models and developing corresponding protocol adapters, without modifying the core system code, greatly reducing the development cost and time for system upgrades and expansions. Through unified command processing services, data processing services, and adaptation frameworks, device differences are isolated at the model and adaptation layers, decoupling core services from specific devices, avoiding code redundancy and logic dispersion, and improving the overall architectural clarity and maintainability of the system. Through version snapshots, global URI addressing, and model-data mapping tables, the system achieves full traceability, rollback capability, and intelligent impact analysis of device models, providing strong data support for system evolution and fault diagnosis. Through dynamically generated management interfaces and unified processing flows, administrators can efficiently manage various devices on a single platform; combined with model relationship graphs, the system can intelligently analyze alarm root causes and configuration impacts, significantly improving operation and maintenance response speed and decision-making quality. 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 invention process in an embodiment of the present 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] In the Operation & Management Center (OMC) system for airship platforms, the objects managed and communicated by the OMC system fall into several categories: remote platform systems and payload equipment, near-end platform systems and equipment, and remote-to-near-end communication and data links. Remote platform systems and payloads include various communication, navigation, and telemetry payload devices, terahertz communication equipment (such as optical transmitters), remote platform networking equipment, and other supporting equipment. Furthermore, various components of remote platforms (such as airship systems) can also be included in the OMC system, but these platform-type devices often have dedicated management and control systems for unified management (such as airship flight control platforms). Near-end platform systems and equipment include local receiving devices for communication, navigation, and telemetry payload data, local networking equipment, local terahertz communication equipment (such as optical receivers), supporting communication alignment turntable equipment, and other equipment. In addition, the equipment in the remote and near-end communication links and service links is also managed, but its management status and indicator data are reflected through the communication equipment at both ends. In the above context, the managed objects and communication objects can communicate with the OMC system through existing unified communication protocols and methods.

[0018] The airship platform serves as the carrier, carrying remote equipment, remote payloads, remote networking equipment, remote terahertz transceivers, and a system management OMC platform. The relevant near-end equipment is placed on the ground, and its system management OMC platform is also located on the ground. The remote system management OMC platform and the near-end system management OMC platform also interact with each other. The aforementioned remote equipment consists of the airship platform's control and environmental sensing devices, the remote payload consists of the relevant data acquisition devices, and the remote networking equipment ensures data transmission between the remote equipment, remote payload, and system management OMC platform.

[0019] The main business processes of the managed devices in the OMC system of its airship platform are as follows: remote devices and remote payloads aggregate service data through optical switches; optical transmitters transmit service data through remote transmission links; the local system receives service data through optical receivers; the local optical switch distributes service data to the application platform; and the system management OMC platform manages the devices. During device management, the OMC system manages associated devices by associating them with device types and management models, and by calling relevant content from the management model.

[0020] This embodiment proposes a unified management method based on a device model in the OMC system of an airship platform, such as... Figure 1 As shown, it includes: In the OMC system for airship platforms, to achieve unified management, a standardized equipment model is first constructed for all managed devices. This equipment model is a digital blueprint for equipment management capabilities and the cornerstone of all unified management operations. The equipment model includes a configuration model, a performance model, and an alarm model.

[0021] The configuration model describes the configurable attributes and constraints of a device. It defines how the device is configured. In the configuration model, model elements include configuration command sets, parameter definitions, and configuration constraints. The configuration command set is a unique identifier for all management commands supported by the device (e.g., `setTurntableAngle`). Parameter definitions include the parameter name, data type (integer, floating-point, string, enumeration, etc.), value range, default value, and dependencies between parameters for each command. Configuration constraints define the logical constraints between parameters; for example, if parameter A has a certain value, parameter B must be within a certain range.

[0022] A performance model describes the monitorable performance metrics of a device. It defines how well the device is performing. Model elements include a set of performance metrics, collected metadata, and metric relationships. The performance metric set includes a unique ID, name, description, and data type (e.g., counter, measured value, status quantity) for each metric. The collected metadata includes the granularity of the metric (e.g., every 5 minutes, every 1 hour), the unit (e.g., Mbps, dBm, ℃), and whether real-time reporting is supported. Metric relationships define the calculation formulas between basic metrics and derived metrics (KPIs).

[0023] The alarm model describes abnormal events that a device may generate. It defines when device intervention is required. Model elements include: alarm definition, alarm attributes, and alarm associations. Alarm definitions include the alarm's unique code, alarm title, detailed description, and severity level (urgent, important, minor, warning). Alarm attributes include possible causes of the alarm, remedial suggestions, and whether it can be automatically cleared. Alarm associations include defining the suppression and correlation relationships between alarms (e.g., when a "power failure" alarm occurs, all "communication interruption" alarms caused by it should be automatically suppressed).

[0024] All device models are defined in a structured data format (such as XML Schema or JSON Schema) and persistently stored in the system database, forming a unified device model library.

[0025] After completing the device model construction, we adopted a method called model-driven dynamic UI / API generation to achieve unified management. In this method, the user interface (UI) and application programming interface (API) of the OMC system are not pre-coded by developers, but are dynamically driven and generated in real time by the device model.

[0026] The specific technical solution for unified management using the above method is as follows: When an administrator selects a device type or specific device on the OMC system's web interface, the OMC system's UI engine sends a request to the server. The device models mentioned above are directly stored on the server. Based on the target device's device type ID, the server queries the corresponding configuration model, performance model, and alarm model from a unified device model library in real time. The UI engine then dynamically renders the corresponding management interface on the browser based on the obtained model definitions.

[0027] For configuration management: The engine automatically generates a configuration command panel containing controls such as drop-down menus, input boxes, and radio buttons based on the command set and parameter definitions in the configuration model. Logic such as parameter range validation and dependency validation is also dynamically implemented by the UI engine based on the constraints in the model.

[0028] For performance management: The engine automatically generates a performance metric selector and a corresponding data chart display area based on the metric set in the performance model. The chart type (line chart, bar chart) can be intelligently selected according to the data type of the metric.

[0029] For alarm management: The engine automatically generates column definitions, alarm filters, and statistics panels for the alarm list based on the alarm model.

[0030] When an administrator performs an operation (such as issuing a configuration command) through a dynamically generated UI, the front end assembles the operation content into a structured request. The format of this request is uniform, and its core consists of the device identifier (DN), model command code, and parameter key-value pairs.

[0031] The request is sent to a unified, generic command processing service on the backend. This service does not contain any device-specific business logic. The processing service mainly performs the following tasks: receiving generic requests; finding the device type and corresponding configuration model based on the device DN in the request; validating the parameters in the request (data type, value range, etc.) according to the model; and converting the standardized request into an intermediate command format after successful validation.

[0032] Intermediate instructions are sent to a unified adaptation framework. This framework loads the corresponding device protocol adapter (such as a PNP plugin written in JavaScript) based on the device type. The adapter's sole responsibility is to convert the intermediate instructions into native protocol messages (such as binary streams, JSON, or XML) that the device can recognize. The conversion logic is pre-written according to the device protocol, but its invocation and execution are dynamic and triggered by the model.

[0033] Performance and alarm data reported by devices are reverse-engineered using a unified adaptation framework and transformed into standardized data objects that conform to the definitions of performance and alarm models. These standardized data objects are then sent to a unified data processing service on the backend. This service, like any other service, is indifferent to the device from which the data originates; it simply persists performance data to the corresponding table in the database, or matches alarm data with alarm models to enrich their alarm descriptions and handling suggestions before storing them in the alarm database, based on the definitions in the models. Finally, this data is presented to the user through a dynamically generated UI or API.

[0034] The core advantage of this solution lies in its extreme flexibility and consistency. When adding a new device model, developers only need to define its configuration, performance, and alarm models in the device model library and develop a corresponding protocol adapter (such as a JS plugin). Afterward, the system can automatically generate all the UI and API interfaces for managing that device, without requiring any modifications to the core platform code of the OMC system.

[0035] Deprecated UI / API: Traditional systems have fixed, pre-developed functional interfaces. In this solution, however, the management interface and API are "stateless," and their form is entirely determined by the device model data in the backend, achieving a dynamic management experience of "what you see is what you get."

[0036] The system's core services (such as command processing and data processing) are purely generic and device-independent. They are more like "engines" that execute standardized processes, with device differences completely isolated in the model library and adaptation layer. This architecture achieves absolute uniformity in management logic, completely avoiding code "corruption" caused by device differences.

[0037] Through this model-driven dynamic generation method for UI / API, the OMC system of the airship platform has achieved full standardization and automation from device definition to management function presentation, and has achieved truly unified management of payload devices with different forms and complex protocols.

[0038] The aforementioned UI engine software components dynamically and automatically transform these models into corresponding web management interfaces. Administrators do not need to concern themselves with the backend implementation; they only need to operate through a unified entry point, and the system can automatically adapt to different devices.

[0039] The use of the UI engine includes the following: Defining a configuration model that details all configurable functions of the device. Assigning a unique command identifier to each configuration function and specifying the parameters required for each command, including parameter name, data type, value range, unit, and constraints between parameters. Generating a structured configuration model list that clearly defines what the device "can do" and "how to configure."

[0040] Define a performance model that details all monitorable operational metrics of the device. Assign a unique identifier to each performance metric and specify its name, data type, unit of measurement, and data collection frequency. Generate a structured list of performance models that clarifies how the device's operational status is measured.

[0041] Define alarm models to describe in detail all possible abnormal events that may occur on the device. Assign a unique alarm code to each alarm and specify the alarm title, detailed description, severity level, and initial handling recommendations. Generate a structured list of alarm models that specifies "under what circumstances the device needs to issue an alarm" and "the severity of the alarm."

[0042] The three defined models are then persistently stored as a complete device type description in a centralized "device model library." A new device type record is added to the model library, which can then be queried by other components of the system.

[0043] The following content is automatically triggered during the administrator's daily operations, driven by the UI engine.

[0044] Content: On the main interface of the OMC system, the administrator selects a specific device instance from the device tree or list.

[0045] After the front-end UI engine detects the device selection event, it automatically sends a request to the server backend to query the device type model data corresponding to the device.

[0046] After receiving configuration, performance, and alarm model data from the server, the UI engine begins parsing these models according to predetermined rules and dynamically constructs a complete web management interface in the browser. Specifically, this includes: Based on the model type, tabs such as "Configuration", "Performance", and "Alarms" are automatically created.

[0047] Read the command list from the configuration model and generate a command selection dropdown; dynamically render the corresponding parameter input control based on the parameter definition of the selected command, and automatically attach data validation logic.

[0048] Read the list of metrics from the performance model and generate a metric selector; automatically initialize and render the corresponding chart components based on the data type and unit of the metrics.

[0049] Read the alarm model, automatically create an alarm list table, and set the corresponding columns and filter conditions.

[0050] After a complete web management interface is built, administrators can perform operations on the dynamically generated interface, such as issuing configurations, viewing performance charts, and handling alarms. All operations are processed through a unified backend service interface, which is itself decoupled from the device model and is universal.

[0051] The backend general service translates the administrator's standard operation requests into native instructions that the device can understand through an "adaptation layer" and then issues them. The data reported by the device is also converted into a standard format through this adaptation layer and finally updated on the dynamic interface, completing a closed-loop operation.

[0052] This invention also proposes a unified storage management method for preceding device models (configuration model, performance model, and alarm model). The core of this method is not only to store the model itself, but more importantly, to store the evolution relationship between model versions, the dynamic mapping between the model and real-time data, and the globally unique addressability of model elements.

[0053] Instead of the traditional, simplistic approach of storing models as static database tables, this approach treats all device models as a living, evolving knowledge system, building a centralized "model repository." This repository not only records the "current state" of each model but also its "lifecycle," providing robust metadata services to other system components.

[0054] During storage, the updated model is not directly overwritten. Each modification to any device model (such as adding a configuration command or changing the unit of a performance metric) generates a globally unique "model version snapshot".

[0055] Each snapshot is a complete, self-describing JSON or XML document containing all model definitions (configuration, performance, alarms) for that device type in this version. Snapshots are managed using a Git-like mechanism. Each commit includes a version hash, committer, commit time, and change description (e.g., "Add night vision mode configuration command for Camera_V2 device"). The system maintains a unified version history tree shared by all device models. This allows for precise rewinding to any point in history to view the exact definition of any device model. By comparing snapshots from different versions, the derivation relationships between models can be clearly analyzed (e.g., device type B is an extension of model V1.2 based on device type A).

[0056] In the process of globally uniquely addressing metadata within stored procedures, a globally unique, immutable Uniform Resource Identifier (URI) is assigned to each minimal element in the model. Once published, the URI remains valid indefinitely. Even though the `setNightMode` command was deprecated in version 2.2, its URI can still be precisely queried using `@v2.1`. This ensures the interpretability of historical data. The URI itself contains the element's category, affiliation, and version, making it a self-interpreting addressing method.

[0057] Establish a separate "Model-Data Mapping Relationship Table" to decouple model definitions from physical storage. This table does not store specific models or data, only mapping rules. The table records the mapping relationship between performance metric URIs and physical database table / field names. For the configuration model: it records the mapping from configuration command URIs to the corresponding adapter script storage paths. For the alarm model: it records the conversion rules from alarm definition URIs to the original alarm codes in the alarm database.

[0058] This mapping layer decouples changes to the model definition from the underlying database schema. When database optimization or sharding is needed, only this mapping table needs to be updated, without modifying the model definition itself. These mapping relationships are dynamically loaded during system startup or model updates. This means that changing the performance data storage location of a device does not require restarting the entire OMC system; only the mapping table needs to be updated.

[0059] A graph database is constructed to store the complex relationships between device model elements. In the graph data, nodes represent model elements (such as a configuration command, a performance metric, or an alarm code). Edges represent the relationships between elements, such as: triggers: power overload performance metric triggers hardware overload alarms; constraints: set transmit power commands; constraints: set the current channel parameter value range; depends_on: calculate the spectrum utilization KPI depends_on, two basic performance metrics: actual bandwidth and available bandwidth.

[0060] This graph breaks down the boundaries between configuration, performance, and alarm models, revealing the hidden, deep business logic connections between them.

[0061] Impact analysis: When a model element needs to be changed (for example, changing the unit of a performance indicator), the graph can be traversed to immediately analyze which configuration command constraints, which derived KPI calculation formulas, and which alarm trigger thresholds will be affected, thereby achieving intelligent change impact assessment.

[0062] When the UI needs to be dynamically generated: the UI engine requests the latest version snapshot of the target device type from the "model repository". The repository returns the complete model document, which the UI renders based on.

[0063] When a configuration command needs to be sent to a device: the general command processing service finds the corresponding adapter script path through the "model-data mapping table", loads and executes the script, and completes the protocol conversion.

[0064] When performance data needs to be stored: After receiving the raw data reported by the device, the data processing service queries the physical database table and field corresponding to the metric URI through the "model-data mapping table", and then stores the value in the correct location.

[0065] When it is necessary to analyze the root cause of an alarm, operations and maintenance personnel can use the "model relationship graph" to traverse the graph starting from the alarm, quickly locate the abnormal performance indicators or related incorrect configuration commands that may have caused the alarm, and greatly improve troubleshooting efficiency.

[0066] This unified storage management approach, based on versioned snapshots, global URI addressing, dynamic mapping tables, and relationship graphs, elevates device models from static, isolated configuration data into a dynamic, interconnected, and semantically rich "knowledge system." It not only solves the "how to store" problem but, more importantly, provides a solid data foundation for the system's dynamic generation, intelligent analysis, and robust evolution. This is a highly forward-looking model management paradigm, uncommon in traditional network management systems.

[0067] 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 unified management based on device model in airship platform OMC system, characterized in that, Comprise: For the managed device of the OMC system, construct a device model; store the device model; The device model corresponds to a device type; For the device model, dynamically drive the generation of a management user interface and an application program interface; Receive a management operation request through the management user interface and the application program interface, wherein the management operation request includes a device identification code and a model command code; Find the corresponding device model through the device identification code, verify the management operation request according to the found device model, and convert the management operation request to obtain an intermediate instruction; Convert the intermediate instruction to a native protocol message through an adaptation framework and send it to the managed device for control; Obtain the collected data of the managed device, convert the collected data through the adaptation framework and perform re-conversion, and display the re-converted data in the management user interface through the device model.

2. The method of claim 1, wherein: The device model includes a configuration model, a performance model, and an alarm model, the configuration model describes the configuration properties and constraints of the managed device, the performance model describes the monitored performance indicators of the managed device, and the alarm model describes the abnormal events of the managed device.

3. The method of claim 2, wherein: In the device model, the configuration model includes a configuration command set, parameter definitions, and configuration constraints; the performance model includes a performance indicator set, collection metadata, and indicator relationships; and the alarm model includes alarm definitions, alarm attributes, and alarm associations.

4. The method of claim 1, wherein: The generation process of the management user interface includes: Obtain a device type code, find the corresponding device model from the stored device model according to the device type, and obtain the corresponding device model; According to the corresponding device model, dynamically generate a management user interface and an application program interface; in the corresponding device model, according to the configuration model, dynamically render a configuration management interface containing command selection and parameter input controls; according to the performance model, dynamically render a performance monitoring interface containing indicator selection and chart display; and according to the alarm model, dynamically render an alarm list and statistical alarm interface.

5. The method of claim 1, wherein: The process of storing the device model includes: Physically store the device model, generate a globally unique model version snapshot for each modification of the device model, and the model version snapshot records version history and change information; Assign a corresponding uniform resource identifier to each element in the device model; According to the uniform resource identifier, construct a model data mapping relationship table, wherein the model data mapping relationship table records the mapping rules of the uniform resource identifiers and physical storage locations of the elements in the model.

6. The method of claim 5, wherein: The process of storing the device model further includes: A model relationship graph is constructed, in which a business logic relationship between configuration, performance and alarm model elements is stored, the business logic relationship including trigger, constraint and dependency relationships, and is used for parameter change impact analysis and alarm root cause analysis.

7. The method of claim 1, wherein, The adaptation framework completes protocol conversion by loading a protocol adapter corresponding to the device type, the protocol adapter being in the form of a plug-in.

8. A unified management system based on device models in an airship platform OMC system, characterized by, A computer program product for performing the method of any of the preceding claims 1-7.

Images