Terahertz communication platform OMC system PNP plug-in and dynamic loading method

Abstract

The invention provides a terahertz communication platform OMC system PNP plug-in and a dynamic loading method. The method comprises the steps that a PNP plug-in frame of an equipment adaptation layer is constructed in an OMC system, and a tool type is initialized; after original binary data reported by equipment is packaged into a JSparam object, a system dynamically loads a corresponding PNP plug-in according to the type of the equipment to carry out data analysis, converts a physical quantity value into a standard JSON format and returns the standard JSON format to an OMC system; the system carries out storage updating, state display and alarm management on the standardized data; when the OMC issues a control command, the command is converted into a device specific protocol format through a conversion function of the PNP plug-in and then issued to a target device, and transparent management and hot plug type expansion of a device protocol are achieved.

Description

Technical Field

[0001] This invention relates to the field of equipment management technology, and more specifically, to the PNP plugin and dynamic loading method of the OMC system for terahertz communication platforms. Background Technology

[0002] In the field of terahertz communication platform OMC system management, traditional architectures face severe challenges: the system needs to manage various heterogeneous "communication, navigation, and remote sensing" payload devices, terahertz communication devices, and supporting equipment in remote and near-end platforms. These devices use diverse communication protocols and data formats, resulting in extremely high system adaptation complexity. Existing solutions typically use hard-coding to achieve device adaptation, which requires modifying the core code and redeploying the entire system when adding new device types or changing protocols. This not only results in long upgrade cycles and high risks but also limits system scalability and reduces development efficiency. The device adaptation logic is tightly coupled with the core business logic of the system, leading to poor code reusability and failing to meet the urgent need for flexible device management in the ever-expanding application scenarios of the HAPS platform. Summary of the Invention

[0003] In view of this, the present invention proposes a PNP plugin and dynamic loading method for the OMC system of the terahertz communication platform to solve the problems existing in the prior art.

[0004] To achieve the above objectives, this invention proposes a PNP plugin and dynamic loading method for a terahertz communication platform OMC system, including: In the OMC system, build the PNP plugin and PNP plugin management framework for the device adaptation layer, and initialize the tool types of the PNP plugin; The managed device sends raw binary data to the OMC system. The device adaptation layer receives this data and encapsulates it into a JSParam object. Based on the managed device's device type, it loads the corresponding PNP plugin. The PNP plugin then performs format conversion and parsing on the JSParam object to obtain the parsed result of the raw binary data; wherein the parsed result is a physical quantity value. The parsing results are filled into a JSON object to generate standardized data, and the parsing process is recorded. The standardized data is then converted into a string format and returned to the OMC system. The OMC system manages the converted string format data, including data storage updates, device status display updates, and alarm management. When the OMC system issues a control command to the managed device, it calls the corresponding PNP plugin according to the control command, and converts the control command into the specific data format of the managed device according to the conversion function in the PNP plugin, and then sends the converted control command to the target device.

[0005] Optionally, the PNP plugin is an independent JavaScript plugin file, with one independent JavaScript plugin file corresponding to each type of managed device. The file is stored in a specified path of Spring Boot resources. The plugin file is named with the device type number. Each PNP plugin includes a data reporting parsing method and one or more control command conversion methods.

[0006] Optionally, the process of format conversion and parsing the converted JSParam object includes: The input parameter is always a JSParam object; The JSParam object provides methods to obtain the device type ID, device ID, and device port; The getParas() method returns a performance metric mapping table, in which one performance metric corresponds to one data object.

[0007] Optionally, the process of converting control commands into a specific data format of the managed device includes: Each command controls a string that corresponds to a function with the same name; The function parameter corresponding to each command-controlled string is uniformly jsParam; The command control parameters are obtained through the getParas() method, which returns a performance metric mapping table. The getPara(pname) method retrieves the parameter with the specified name and returns an Object object, converting the control command result into a byte[] type.

[0008] Optionally, the script engine of the PNP plugin may be either the Nashorn engine or the GraalVM engine.

[0009] Optional utility types include: ByteBuffer class for handling binary data parsing; ArrayList class for creating list collections; HashMap class for creating key-value pair mappings; String class for string manipulation; JSONObject class for handling JSON data formatting; DecimalFormat class for number formatting; and LogPrint class for logging debugging information.

[0010] Optionally, the method also includes a dynamic plugin loading mechanism: When the OMC system starts up, it scans and loads the PNP plugins in the device adaptation layer through the plugin management framework. When a new device type is added or a device protocol is updated, the OMC system automatically identifies the newly added or modified PNP plugin file; Dynamically load and instantiate new PNP plugins without restarting the OMC system core services; By standardizing the plug-in interface, the details of the device communication protocol are decoupled from the core business logic of the system; The dynamic loading mechanism supports the rapid integration of new device types and the online updating of existing device protocols.

[0011] On the other hand, the present invention also provides a PNP plugin and dynamic loading system for the terahertz communication platform OMC system, for executing the above-described method.

[0012] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention achieves transparent processing of device protocols through an innovative PNP plugin and dynamic loading mechanism, greatly improving system flexibility and scalability. Adding new device types only requires developing corresponding JavaScript plugins without modifying the core code, supporting "hot-swappable" management of device protocols. Simultaneously, it significantly improves development and maintenance efficiency, leveraging the flexibility of JavaScript and the stability of the Java ecosystem to reduce development barriers and engineering implementation complexity while ensuring system performance. Through standardized data formats and full-link log tracking, it ensures reliable data transmission and convenient fault location, effectively solving the technical challenges of managing multiple devices and protocols in terahertz communication platforms, and providing reliable technical support for the intelligent operation and maintenance of high-altitude platform stations. Attached Figure Description

[0013] 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 method flow in an embodiment of the present invention. Detailed Implementation

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

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

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

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

[0018] This embodiment proposes a PNP plugin and dynamic loading method for the OMC system of a terahertz communication platform, such as... Figure 1 As shown, it includes: During the system initialization and environment building phase, the OMC system establishes a PNP plugin management framework for the device adaptation layer at startup, initializes the JavaScript script engine and scans the predefined plugin directory. By declaring and instantiating key Java utility classes in the JavaScript runtime environment, it builds a complete technical support system for subsequent data processing, ensuring that the plugins have the basic ability to handle various device data format conversions and serialization operations.

[0019] The data reception and parsing phase begins when the device agent sends the raw binary data to the OMC system via the communication link. After receiving the data, the OMC adaptation layer encapsulates it into a JSParam object and dynamically loads the corresponding JavaScript plugin according to the device type. Subsequently, the PNP plugin extracts the binary byte array reported by the device from the JSParam object, packages it into a ByteBuffer object for sequential reading, and parses the specific physical quantity value according to the predefined protocol format, completing the conversion process from raw bytes to actual physical value.

[0020] In the data standardization and integration phase, the parsed physical quantity values ​​are filled into a newly created JSON object to form a standardized data structure. At the same time, the complete parsing process and result information are recorded by a logger. Finally, the JSON object is converted into a string format and returned to the OMC main system, realizing the unified formatted output of data and providing a consistent data foundation for the subsequent collaborative processing of various business modules.

[0021] In the business processing and distribution phase, the OMC system receives standardized data, the performance management module stores it in the database and updates the statistics, the topology management module refreshes the device status display in real time, the alarm management module monitors thresholds and triggers corresponding alarm processing, and finally completes the internal distribution and external provision of data through the message bus and northbound interface, forming a complete device management closed loop.

[0022] The command issuance and control phase is a reverse processing flow. When the OMC system needs to issue control commands, it calls the corresponding plugin's conversion function based on the command word to convert the unified MML command format into a device-specific binary protocol format. The command is then issued to the target device for execution through the device agent, thereby achieving fine-grained control and management of the entire terahertz communication platform.

[0023] The details are as follows: PNP (Plug and Play) plugins are primarily used in the device adaptation layer. They utilize JavaScript to write proprietary logic for device adaptation, organizing the JavaScript into PNP plugins. A PNP plugin management and loading framework is then developed within the adaptation layer to enable dynamic loading of these JavaScript plugins. This online plugin loading method significantly improves adaptation development efficiency, avoids major OMC (Object Management Console) upgrades due to modifications to adaptation details, and reduces the complexity of project upgrades.

[0024] PNP plugins refer to the encapsulation of protocol adaptation logic for different device types into independent JavaScript script modules that conform to specific specifications in the OMC system.

[0025] The PNP plugin is the technical implementation of this method. It's not an abstract concept, but a concrete JavaScript file conforming to specific specifications. Each device type corresponds to a separate, physically existing .js file, located in js / plugin / . <devtype>Located in the .js path, this file encapsulates all protocol adaptation logic specific to this device type, including data parsing and command conversion. These modules follow a "plug-and-play" design philosophy, featuring standardized interfaces and a unified loading method. Specifically, each device type corresponds to an independent plugin file, which must contain uniformly named data parsing and command conversion functions. Through a predefined plugin management and loading framework, the system can dynamically identify, load, and execute these plugins without restarting the core service. This decouples the device-specific communication protocol details from the OMC system's core business logic, enabling rapid integration of new device types and flexible updates to existing device protocols. Ultimately, this achieves modularization, standardization, and hot deployment capabilities for device adaptation logic.

[0026] Java's JavaScript engine: Java can execute JavaScript scripts using various engines, the most common being the Nashorn engine (introduced in JDK 8) and the Rhino engine (in earlier versions). However, it's important to note that the Nashorn engine was removed starting with Java 9. If you need similar functionality in newer versions of Java, you can consider alternatives such as GraalVM.

[0027] 1. Nashorn Engine (JDK8) Nashorn is a high-performance JavaScript engine introduced in JDK 8. It fully supports the ECMAScript 5.1 specification and allows Java code to interact with JavaScript code. Example code for executing JavaScript using the Nashorn engine is as follows: / / Import JavaScript engine related class packages import javax.script.ScriptEngine; / / Script engine interface used to execute script code import javax.script.ScriptEngineManager; / / Script engine manager, used to create and manage script engines import javax.script.ScriptException; / / Script exception class, used to handle errors during script execution. / / Define a public class named NashornExample public class NashornExample { / / Main method, the program's entry point public static void main(String[] args) { / / Create a Script Engine Manager instance to obtain the script engine ScriptEngineManager manager = new ScriptEngineManager(); / / Obtain a JavaScript engine instance named "nashorn" via the manager. / / Nashorn is a built-in JavaScript engine in JDK 8. ScriptEngine engine = manager.getEngineByName("nashorn"); / / Use a try-catch block to catch exceptions that may be thrown during script execution try { / / Define the JavaScript code string to be executed / / Includes a function definition and an immediately invoked function. String jsCode = "function sayHello() { return 'Hello fromNashorn!';} sayHello();"; / / Execute JavaScript code using a script engine and return the execution result. Object result = engine.eval(jsCode); / / Convert the execution result to a string and print it to the console. System.out.println(result.toString()); } catch (ScriptException e) { / / If a script exception occurs during execution, print the exception stack trace. e.printStackTrace(); } } } The above process is mainly as follows: Initialization phase: Create ScriptEngineManager to manage the script engine; obtain the Nashorn JavaScript engine instance through the manager.

[0028] Script execution phase: Define a JavaScript code string, including: a sayHello function that returns a greeting; immediately call the function to get the return value; call the engine.eval() method to execute the JavaScript code.

[0029] Result processing stage: Obtain the execution result of the JavaScript code; convert the result into a string and output it to the console; expected output: Hello from Nashorn!.

[0030] Exception handling: Use try-catch to catch possible script execution exceptions; if an error occurs, print detailed stack trace information.

[0031] 2. GraalVM (alternative) For Java 9 and above, since the Nashorn engine has been removed, GraalVM can be used as an alternative. GraalVM is a high-performance runtime that supports multiple programming languages, including JavaScript. Executing JavaScript scripts using GraalVM requires additional configuration and dependencies; detailed steps can be found in the official GraalVM documentation.

[0032] Device Management Adapter Plugin (PNP Plugin) Example: Example of a compatible JavaScript plugin: I. Agreement: 1. Each device type corresponds to a separate JavaScript plugin file. The file location is relative to the Spring Boot resources directory (e.g., / js / plugin / ). <devtype>.js); 2. The JS plugin file name is <devtype>In .js, devtype is the device type number, such as devxxx; 3. The JS plugin includes a data reporting and parsing method and N (N>0) control command conversion methods.

[0033] The core function of this agreement is to establish a standardized set of plug-in development and management specifications, laying the foundation for the feasibility of the PNP plug-in mechanism.

[0034] By explicitly requiring each device type to have a uniquely named JavaScript plugin file, all stored in a designated directory, the system is ensured to automatically and accurately discover, identify, and load the correct adaptation logic. Furthermore, mandating that each plugin include at least one uniformly named data parsing method and several command conversion methods essentially defines the contractual interface between the plugin and the OMC core system. This guarantees that regardless of changes in the plugin's internal implementation, the system can invoke its key functions in a consistent manner. This achieves standardized and modular management of device protocol adaptation, providing a prerequisite for subsequent dynamic loading and hot-swapping.

[0035] II. Analysis of Device-Reported Performance Data: 1. Parsing device-reported performance measurement data (metadata): The method name can be fixed as: funcupdataparse. 2. Input parameter is fixed as: JSParam: Including the following methods: (2.1) getDevtypeid() → Get the device type ID; (2.2) getDevId() → Get the device ID; (2.3) getDevport() → Get the device port; (2.4) getParas() → Retrieves the performance data parsing results and returns a performance metric mapping table: Map<String, Object> One indicator corresponds to one data object.

[0036] The core function of this agreed-upon procedure is to establish a standardized processing mechanism for the uplink channel of device data.

[0037] By uniformly naming the performance data parsing method "funcupdataparse" and fixing its acceptance of the JSParam parameter, the OMC system ensures that it can consistently invoke the performance data parsing logic of different devices. Specifically, the definition of standardized methods for obtaining the device type ID, device ID, and device port that the JSParam object must provide provides plugins with complete device context information, enabling them to accurately identify the data source. Furthermore, the requirement that the getParas() method return a structured performance metric mapping table forces all plugins to convert the raw, device-specific data format into a unified data model that the system can understand. This design achieves reliable conversion from multi-source heterogeneous device data to a standardized internal data structure, providing a high-quality data foundation for subsequent data storage, monitoring analysis, and alarm processing.

[0038] III. Control Command Conversion Instructions: 1. Each command control word corresponds to a function, and the function name = control word name; 2. The input parameter of func for each control word is uniformly jsParam, defined with the same performance data parsing, where the getparas() method retrieves command control parameters: (2.4) getParas(), Return value: Map<String, Object> , key=[P1,..., Pn], val=parameter values ​​corresponding to P1~Pn; (2.5) getPara(pname) → Gets the parameter with the specified name and returns an Object object; 3. The result of the control command conversion is byte[].

[0039] The various Java objects provided by the JDK that can be used during the conversion are typically List objects like JSONObject, which is a JSON conversion object class, as shown in this example.

[0040] The core function of this agreement is to establish a standardized conversion mechanism for the downlink channel of system control commands.

[0041] By stipulating that each command control word must correspond to a conversion function with the same name, and uniformly using jsParam as the input parameter, the OMC system ensures that it can consistently invoke the command issuance logic of different devices. Specifically, the design of obtaining a key-value pair mapping containing all parameters through the getParas() method, and obtaining a specific parameter value through getPara(pname), provides plugins with flexible and complete command parameter access capabilities, enabling them to accurately understand control intent. Furthermore, the requirement that all command conversion functions ultimately return byte[] type results ensures that regardless of differences in the internal processing logic of the plugins, the final output to the device is in binary format conforming to its specific communication protocol. This design achieves reliable conversion from a unified command format within the system to a device-specific protocol format, providing technical support for precise device control. Simultaneously, by allowing the use of various Java objects provided by the JDK for data conversion processing, it balances development flexibility and execution efficiency.

[0042] Commonly used Java type references: / / Referencing Java's ByteBuffer class in a JavaScript environment for handling binary data: var ByteBuffer = Java.type('java.nio.ByteBuffer'); / / Referencing Java's ArrayList class for creating list collections var List = Java.type('java.util.ArrayList'); / / Referencing Java's HashMap class for creating key-value pair mappings var Map = Java.type('java.util.HashMap'); / / Referencing Java's String class for string manipulation. var String = Java.type('java.lang.String'); / / Referencing Java's JSONObject class for handling JSON data format. var JSONObject = Java.type('org.json.JSONObject'); / / Referencing Java's DecimalFormat class for number formatting var DecimalFormat = Java.type('java.text.DecimalFormat'); / / Create a DecimalFormat instance and set the number format mode to retain two decimal places. java.text.DecimalFormat df = new java.text.DecimalFormat("#.00"); This section covers the PNP plugin's runtime environment initialization phase. By declaring and instantiating key Java utility classes in JavaScript, a complete technical support system is built for subsequent data processing. This includes ByteBuffer for binary stream parsing, ArrayList and HashMap for structured data storage, string and JSON format processing tools, and DecimalFormat for numerical formatting. This ensures that the plugin has the basic ability to handle various device data format conversions and serialization operations during subsequent execution.

[0043] / / Formatting numbers using a df instance (example code; replace "the number you want to format" with this code in actual use): df.format(the number you want to format); / / Read 1 byte of data from the ByteBuffer buf.get(); / / read 1 byte / / Read 2 bytes of short integer data from ByteBuffer buf.getShort(); / / read 2 bytes / / Read 4 bytes of integer data from ByteBuffer buf.getInt(); / / read 4 bytes / / Read 8 bytes of long integer data from ByteBuffer buf.getLong(); / / read 8 bytes This section showcases the core tools and methods for data processing in the PNP plugin: DecimalFormat is used to format numerical values ​​to ensure data readability, while a series of get methods of ByteBuffer are used to accurately parse the binary data stream reported by the device according to different byte lengths, reading physical quantity values ​​of different data types such as single-byte, double-byte short integers, four-byte integers, and eight-byte long integers, providing basic parsing capabilities for subsequent data standardization and conversion.

[0044] / / Redeclare the ByteBuffer reference (repeated from above) var ByteBuffer = Java.type('java.nio.ByteBuffer'); / / Redeclare ArrayList reference var List = Java.type('java.util.ArrayList'); / / Redeclare String reference var String = Java.type('java.lang.String'); / / Redeclare JSONObject reference var JSONObject = Java.type('org.json.JSONObject'); / / Redeclare HashMap reference var Map = Java.type('java.util.HashMap'); / / Referencing the OMC system's custom log printing class for recording debugging information. var LogPrint = Java.type('com.hongshan.omc.adapter.pm.app.service.rptparse.JsLogPrint'); This section is the PNP plugin's initialization module. Its core function is to establish a bridge between the JavaScript runtime environment and the Java class library. By declaring references to ByteBuffer, ArrayList, HashMap, String, JSONObject, and the custom log class LogPrint, the plugin can directly call Java's native capabilities to handle tasks such as binary data parsing, complex data structure construction, JSON format standardization, and runtime log recording. This ensures that while maintaining the flexibility of JavaScript development, it fully utilizes the stability, performance, and existing infrastructure of the Java platform, enabling the plugin to efficiently and accurately complete device data adaptation and protocol conversion.

[0045] 1. The method for parsing reported performance data should be uniformly and consistently named: funcupdataparse. / / Function comment: The method for parsing reported performance data is uniformly and consistently named funcupdataparse / / Input parameter: JSParam - A Java object containing the data reported by the device function funcupdataparse(jsParam){ / / Retrieve the performance data payload (usually a binary byte array) named 'uppayload' from the JSParam parameter. var bs = jsParam.getPara('uppayload'); / / Wrap the byte array into a ByteBuffer object to make it easier to parse binary data byte by byte. var buf = ByteBuffer.wrap(bs); / / Read 4 bytes from the ByteBuffer and parse them into a floating-point number (assuming a depth value). var depth = buf.getFloat(); / / Create a new JSONObject object to organize the parsed structured data. var json = new JSONObject(); / / Create a log printer instance to record the parsing process and debugging information. var logger = new LogPrint(); / / Store the parsed depth value into a JSON object with "depth" as the key. json.put("depth", depth); / / Record the parsed metadata information to the system log logger.info("Js parsed metadata:" + json.toString()); / / Convert the JSON object to a string format and return it to the OMC system. return json.toString(); } / / Utility function: string insertion delimiter / / Parameter description: / / t - raw string / / c - the separator to insert / / n - Insert a separator once every n characters function InsertString(t, c, n){ / / Create an empty array to store the split string fragments var r = new Array(); / / Loop through the string, with a step size of n characters. for (var i = 0; i * 2 < t.length; i++) { / / Extract a substring of n characters starting from position i*2 and add it to the array. r.push(t.substr(i * 2, n)); } / / Connect all string fragments in the array using the separator 'c' return r.join(c); } / / Reserved command conversion function template In practice, each device control command (such as setTurntableAngle) will have a corresponding conversion function. / / Function name = command name, used to convert OMC's MML commands into a format that the device can recognize. function xxxx() { / / The specific command conversion logic is yet to be implemented. / / Typically, JSON command arguments are converted to device-specific binary protocol format here. } The following is a description of the methodology and workflow for the above content: Phase 1: Data Reception and Transmission: The device agent sends the raw binary data to the OMC system through the communication link. After receiving the data, the OMC adaptation layer encapsulates it into a JSParam object and dynamically loads the corresponding JavaScript plugin according to the device type, preparing to call the data parsing function within it for processing.

[0046] Phase 2: Binary Data Parsing: The PNP plugin extracts the binary byte array reported by the device from the JSParam object, wraps it into a ByteBuffer object for sequential reading, and then parses the specific physical quantity value according to the predefined protocol format, completing the conversion process from raw bytes to actual physical value.

[0047] The third stage: data standardization processing: the parsed physical quantity values ​​are filled into a newly created JSON object to form a standardized data structure. At the same time, the complete parsing process and result information are recorded by a logger. Finally, the JSON object is converted into a string format and returned to the OMC main system to achieve unified formatted output of data.

[0048] Phase 4: System Business Processing: After receiving standardized data, the OMC system stores the data in the database and updates the statistics. The topology management module refreshes the device status display in real time, and the alarm management module monitors the thresholds and triggers corresponding alarm processing. Finally, the data is distributed internally and provided externally through the message bus and northbound interface.

[0049] The entire process achieves transparent processing of device protocols through the PNP plug-in mechanism, ensuring that the OMC core system can process data from various heterogeneous devices in a unified manner, while maintaining the system's flexibility, scalability, and end-to-end traceability.

[0050] 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.< / devtype> < / devtype> < / devtype>

Claims

1. A PNP plug-in and dynamic loading method for OMC system of terahertz communication platform, characterized in that, include: In the OMC system, build the PNP plugin and PNP plugin management framework for the device adaptation layer, and initialize the tool types of the PNP plugin; The managed device sends raw binary data to the OMC system. After receiving the data, the device adaptation layer encapsulates it into a JSParam object. Based on the device type of the managed device, the corresponding PNP plugin is loaded. The PNP plugin performs format conversion and parsing on the JSParam object to obtain the parsing result of the raw binary data; wherein the parsing result is a physical quantity value. The parsing results are filled into a JSON object to generate standardized data, and the parsing process is recorded. The standardized data is then converted into a string format and returned to the OMC system. The OMC system manages the converted string format data, including data storage updates, device status display updates, and alarm management. When the OMC system issues a control command to the managed device, it calls the corresponding PNP plugin according to the control command, and converts the control command into the specific data format of the managed device according to the conversion function in the PNP plugin, and then sends the converted control command to the target device.

2. The method according to claim 1, characterized in that, The PNP plugin is an independent JavaScript plugin file. Each type of managed device corresponds to an independent JavaScript plugin file, which is stored in the specified path of the Spring Boot resources. The plugin file is named with the device type number. Each PNP plugin includes a data reporting parsing method and one or more control command conversion methods.

3. The method according to claim 1, characterized in that, The process of format conversion and parsing of the converted JSParam object includes: The input parameter is always a JSParam object; The JSParam object provides methods to obtain the device type ID, device ID, and device port; The getParas() method returns a performance metric mapping table, in which one performance metric corresponds to one data object.

4. The method according to claim 1, characterized in that, The process of converting control commands into a specific data format for the managed device includes: Each command controls a string that corresponds to a function with the same name; The function parameter corresponding to each command-controlled string is uniformly jsParam; The command control parameters are obtained through the getParas() method, which returns a performance metric mapping table. The getPara(pname) method retrieves the parameter with the specified name and returns an Object object, which converts the control command result into a byte[] type.

5. The method according to claim 1, characterized in that, The script engine for the PNP plugin is either the Nashorn engine or the GraalVM engine.

6. The method according to claim 1, characterized in that, The tool types include: ByteBuffer class for handling binary data parsing; ArrayList class for creating list collections; HashMap class for creating key-value pair mappings; String class for string manipulation; JSONObject class for handling JSON data formatting; DecimalFormat class for number formatting; and LogPrint class for recording debugging information.

7. The method according to claim 1, characterized in that, It also includes a dynamic plugin loading mechanism: When the OMC system starts up, it scans and loads the PNP plugins in the device adaptation layer through the plugin management framework. When a new device type is added or a device protocol is updated, the OMC system automatically identifies the newly added or modified PNP plugin file; Dynamically load and instantiate new PNP plugins without restarting the OMC system core services; By standardizing the plug-in interface, the details of the device communication protocol are decoupled from the core business logic of the system; The dynamic loading mechanism supports the rapid integration of new device types and the online updating of existing device protocols.

8. The terahertz communication platform OMC system PNP plug-in and dynamic loading system, characterized in that, Used to perform the method described in any one of claims 1-7.

Images