Message forwarding method and device, telecontrol machine and readable storage medium

Abstract

The invention provides a message forwarding method and device, a telecontrol machine and a readable storage medium, and is suitable for the technical field of telecontrol machine message forwarding. The message forwarding method comprises the following steps: acquiring a configuration file of a predetermined data exchange format; analyzing the configuration file, and determining a message template and metadata configuration; the metadata configuration comprises a metadata acquisition interface; obtaining to-be-processed data from a preset database based on the metadata obtaining interface; the to-be-processed data is data, collected by a telecontrol machine, of a measurement and control device of a transformer substation; generating a target message based on the message template and the to-be-processed data; and sending the target message to the terminal device. According to the embodiment of the invention, rapid adaptation of message forwarding can be realized through the configuration file, the configuration file can be correspondingly modified according to a change or new demand, a core code does not need to be modified, and the whole program does not need to be recompiled and deployed, so that the maintenance complexity and risk of the system are remarkably reduced, the development efficiency is improved, and the maintenance cost is reduced.

Description

Technical Field

[0001] This application relates to the field of remote motor message forwarding technology, and in particular to a message forwarding method, apparatus, remote motor, and readable storage medium. Background Technology

[0002] In substation automation systems, Remote Terminal Units (RTUs) typically require a unified standard protocol to communicate and acquire signals from edge devices. However, in the increasingly common scenario of new energy substations, intelligent RTUs need to connect to different cloud platforms. Many cloud platform master stations use MQTT (Message Queuing Telemetry Transport) for communication, and the message formats differ between different cloud platforms accessed by different stations. This necessitates customized development of message format concatenation code for intelligent RTU products when interfacing with different cloud platforms at different stations. This model requires varying levels of development work for different cloud platform connections, leading to a continuous increase in the amount of code that needs maintenance.

[0003] Currently, while the basic publish-subscribe service for communication using the MQTT protocol in intelligent remote machines can be uniformly encapsulated, custom development is required for message formats when accessing various cloud platforms, based on the message formats provided by the cloud platform vendors. This leads to increased project delivery time and maintenance costs. Therefore, existing message forwarding methods suffer from low development efficiency and high maintenance costs. Summary of the Invention

[0004] In view of this, embodiments of this application provide a message forwarding method, apparatus, telecontrol unit, and readable storage medium to solve the problems of low development efficiency or high maintenance cost in existing message forwarding methods.

[0005] This application provides a message forwarding method applied to a remote sensing machine, the method including: Obtain the configuration file in the predetermined data exchange format; The configuration file is parsed to determine the message template and metadata configuration; the metadata configuration includes the metadata retrieval interface. Based on the metadata acquisition interface, the data to be processed is obtained from the preset database; the data to be processed is the data of the substation's measurement and control devices collected by the remote motor. Generate the target message based on the message template and the data to be processed; Send the target message to the terminal device.

[0006] In one possible implementation, the metadata configuration includes metadata support for sending timing; Based on the message template and the data to be processed, generate the target message, including: If the metadata supports periodic sending, then the data to be processed will be filled into the message template to generate the target message; If the metadata supports sending at a sudden change, then when it is determined that the data to be processed has changed, the data to be processed will be filled into the message template to generate the target message.

[0007] In one possible implementation, the data to be processed is populated into a message template to generate the target message, including: Retrieve fixed and dynamic fields from the data to be processed; Write fixed fields into the message template, and fill the dynamic fields into the message template using placeholders to obtain the filled message template; Generate the target message based on the populated message template.

[0008] In one possible implementation, before retrieving the fixed and dynamic fields from the data to be processed, the following steps are also included: Iterate through the data nodes of the message template and use a pre-defined utility function to create missing object nodes in the message template as placeholders.

[0009] In one possible implementation, the target message is generated based on the populated message template, including: The filled message template is serialized to obtain a string in a predetermined data exchange format, which is then used as the target message.

[0010] In one possible implementation, the metadata configuration includes a function lookup index; After parsing the configuration file and determining the message template and metadata configuration, the following steps are also included: Based on the function lookup index, function pointers are obtained through a pre-defined plugin manager; the plugin manager is used to scan and load plugin files to register exported function pointers. Based on function pointers, the corresponding plugin function is called to retrieve the data to be processed from the preset database.

[0011] In one possible implementation, obtaining a configuration file in a predetermined data exchange format includes: scanning configuration files in a specified directory and obtaining at least one configuration file when the main program starts. After obtaining the configuration file for the predetermined data exchange format, it includes: Create one thread for each configuration file; Each thread establishes a Message Queuing Telemetry Transport Protocol (MQTT) connection with a corresponding terminal device.

[0012] A second aspect of this application provides a message forwarding device applied to a remote sensing machine, comprising: The first acquisition module is used to acquire a configuration file in a predetermined data exchange format; The parsing module is used to parse the configuration file to determine the message template and metadata configuration; the metadata configuration includes the metadata retrieval interface; The second acquisition module is used to acquire data to be processed from a preset database based on the metadata acquisition interface; the data to be processed is the data of the substation's measurement and control devices collected by the remote motor. The generation module is used to generate the target message based on the message template and the data to be processed; The sending module is used to send the target message to the terminal device.

[0013] A third aspect of this application provides a teletype, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method of the first aspect.

[0014] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method of the first aspect.

[0015] Compared with the prior art, the embodiments of this application have at least the following technical effects: The message forwarding method of the first aspect of this application is applied to a remote control unit (RTU). It can obtain a configuration file with a predetermined data exchange format; then parse the configuration file to determine the message template and metadata configuration, including a metadata acquisition interface; then, based on the metadata acquisition interface, retrieve data to be processed from a preset database; and finally, based on the message template and the data to be processed, generate a target message and send the target message to the terminal device. Therefore, this application embodiment can achieve rapid adaptation of message forwarding through the configuration file. For changes or new requirements, the configuration file can be modified accordingly without modifying the core code or recompiling and deploying the entire program, significantly reducing system maintenance complexity and risk, improving development efficiency, and reducing maintenance costs. Moreover, this application embodiment is a highly versatile, flexible, and maintainable general message forwarding method.

[0016] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the framework of a message sending system provided in an embodiment of this application; Figure 2 This is a flowchart of a message forwarding method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the architecture of an MQTT message forwarding system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a message forwarding device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of the telemotor provided in the embodiments of this application. Detailed Implementation

[0019] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0020] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0021] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0023] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0025] The shortcomings of existing technologies.

[0026] Research has revealed that existing MQTT message forwarding methods for remote machines have the following shortcomings: (1) High cost of customized development: Existing solutions are usually hard-coded for different cloud platforms or device specifications. Each project needs to reimplement the core logic such as message structure definition, serialization, and message concatenation, resulting in a large amount of duplicate code and manpower investment.

[0027] (2) Complex system maintenance and updates: When cloud platform protocols, device data formats, or communication protocols change, program code needs to be modified, then recompiled and deployed. This is not only time-consuming and labor-intensive, but also increases the risk of introducing new errors. Poor scalability and adaptability. (3) The system lacks the ability to quickly adapt to new cloud platforms or new equipment types, the project cycle is long, and it is difficult to respond quickly to changes in business needs.

[0028] The message forwarding method, apparatus, telecontroller, and readable storage medium provided in this application are intended to solve the above-mentioned technical problems of the prior art.

[0029] The technical solution of this application and how it solves the above-mentioned technical problems are described in detail below with specific embodiments. It should be noted that the following embodiments can be referenced, borrowed, or combined with each other, and the same terms, similar features, and similar implementation steps in different embodiments will not be described again.

[0030] See Figure 1 As shown in the diagram, this application provides a framework diagram of a message sending system. Figure 1As shown, the intelligent remote control unit acts as a gateway, aggregating all the information collected by various measurement and control devices connected to it. It then configures MQTT to form MQTT channels for data forwarding to different cloud platform MQTT servers. The forwarding table selects the data required by different cloud platforms and configures the message formats required by different cloud platforms. This ensures that one gateway unit can access one or more cloud platforms and forward different message formats to communicate with the cloud platforms. The cloud platform MQTT server can communicate with the MQTT client on the master station side. See Figure 2 As shown, this application provides a flowchart of a message forwarding method. The message forwarding method of this application is applied to a remotely operated vehicle (ROV), specifically an intelligent RAV4. Figure 2 As shown, the message forwarding method includes steps S201 to S205.

[0031] S201. Obtain the configuration file for the predetermined data exchange format.

[0032] Alternatively, the configuration file can be a JSON configuration file, which can describe the data source, target location, format requirements, and sending strategy, rather than hard-coding the execution logic.

[0033] In some embodiments, obtaining a configuration file in a predetermined data exchange format includes: scanning configuration files in a specified directory and obtaining at least one configuration file when the main program starts. After obtaining the configuration file of the predetermined data exchange format, the process includes: creating a thread for each configuration file; and establishing an MQTT connection with a corresponding terminal device through each thread.

[0034] Optionally, one JSON configuration file corresponds to one cloud platform, containing various information related to connecting to and sending messages with that cloud platform. When the program runs, it parses different JSON configuration files, starting multiple threads. Each thread parses one JSON configuration file and begins processing message sending with the cloud platform.

[0035] This application embodiment supports concurrent access from multiple cloud platforms. When the main program starts, it scans the configuration files in the specified directory and creates an independent thread for each configuration file. Each thread is responsible for establishing an MQTT long connection with a cloud platform.

[0036] S202. Parse the configuration file to determine the message template and metadata configuration; the metadata configuration includes the metadata retrieval interface.

[0037] Optionally, message templates can be used to populate data, and metadata configuration can be used for data retrieval and population.

[0038] S203. Based on the metadata acquisition interface, obtain the data to be processed from the preset database; the data to be processed is the data of the substation's measurement and control device collected by the remote motor.

[0039] Optionally, the default database is the real-time database of the intelligent remote motor. The data to be processed is obtained from the real-time database, such as: various commonly used data such as system time, UUID (Universally Unique Identifier), fixed values, remote motor information, equipment configuration information, etc.

[0040] In this embodiment, the thread periodically scans all metadata configurations (metadata configurations mainly include metadata ID, metadata retrieval interface, metadata support sending timing, interface parameters, etc.), calls the corresponding metadata retrieval interface through the metadata configuration to obtain the corresponding data to be processed, returns it, and caches it.

[0041] S204. Generate the target message based on the message template and the data to be processed.

[0042] Optionally, the message template is a JSON template.

[0043] In some embodiments, metadata configuration includes metadata support for sending timing; generating a target message based on a message template and pending data, including: If the metadata supports periodic sending, then the data to be processed will be filled into the message template to generate the target message; If the metadata supports sending at a sudden change, then when it is determined that the data to be processed has changed, the data to be processed will be filled into the message template to generate the target message.

[0044] This application embodiment can perform periodic and abrupt data processing, and the sending timing for each metadata element is configured according to different timings. If the metadata element supports abrupt sending timing, it is not necessary to fill the message template with the data to be processed if it is determined that no abrupt change has occurred.

[0045] In some embodiments, the data to be processed is populated into a message template to generate a target message, including: Retrieve fixed and dynamic fields from the data to be processed; Write fixed fields into the message template, and fill the dynamic fields into the message template using placeholders to obtain the filled message template; Generate the target message based on the populated message template.

[0046] The configuration file in this embodiment provides a message template. Fixed fields are directly written into the template, while dynamic fields are filled using placeholders. The placeholder is a metadata ID, which is obtained by parsing the configuration file and includes parameters from the metadata retrieval interface. After obtaining the data to be processed, it is filled into the message template to construct a complete message.

[0047] S205. Send the target message to the terminal device.

[0048] Optionally, the terminal device is a cloud platform.

[0049] The message forwarding method of this application embodiment is applied to a remote control unit (RTU). It can obtain a configuration file with a predetermined data exchange format; then parse the configuration file to determine the message template and metadata configuration, the metadata configuration including a metadata acquisition interface; then, based on the metadata acquisition interface, obtain the data to be processed from a preset database; and then, based on the message template and the data to be processed, generate a target message and send the target message to the terminal device.

[0050] Therefore, the embodiments of this application can achieve rapid adaptation of message forwarding through configuration files. For changes or new requirements, the configuration files can be modified accordingly without modifying the core code or recompiling and deploying the entire program. This significantly reduces the system's maintenance complexity and risk, improves development efficiency, and lowers maintenance costs. Moreover, the embodiments of this application represent a highly versatile, flexible, and maintainable general message forwarding method.

[0051] The embodiments of this application are mainly applied to the field of substation automation in power systems, especially in substation scenarios where the master station is a cloud platform. The design methods and architectural concepts of these embodiments have broad applicability and can be applied to products in many other fields, such as the communication development of communication protocols in traditional intelligent remote control products, data transmission in power system distribution network scenarios, and data acquisition and transmission in new energy power control products.

[0052] As an example, this application uses the standard JSON format as the external configuration file. The parsing and storage of the configuration file includes the following: (1) Parsing library: The RapidJSON C++ library can be used to parse JSON configuration files.

[0053] (2) In-program mapping storage: The parsed JSON data is stored in a pre-designed C++ structure.

[0054] (3) Interface parameter processing: The funcParams field in the metadata structure will not be directly parsed into a fixed structure, but will be stored as a raw JSON string (funcParamsJson) and passed to the plugin function. Similarly, SharedConfigData and messageTemplate are also stored as raw JSON strings to support dynamic parsing and processing.

[0055] Here, funcParams is a field used to store function parameters. It is stored in the raw JSON string format, rather than being parsed into a fixed data structure.

[0056] SharedConfigData is a structure for storing shared configuration data. It is stored in raw JSON string format (SharedDataJson) and supports dynamic configuration information that can be shared among multiple components or plugins.

[0057] messageTemplate is a structure used to define message templates. It is stored in raw JSON string format (messageTemplateRaw) and supports the dynamic generation of standardized message formats.

[0058] In some embodiments, the metadata configuration includes a function lookup index. After parsing the configuration file and determining the message template and metadata configuration, the method further includes: Based on the function lookup index, function pointers are obtained through a pre-defined plugin manager; the plugin manager is used to scan and load plugin files to register exported function pointers. Based on function pointers, the corresponding plugin function is called to retrieve the data to be processed from the preset database.

[0059] This application supports the acquisition of diverse data sources. By parsing the configuration file and using the metadata acquisition interface, as well as the plugin mechanism of the plugin manager, it supports the acquisition of data to be processed from the real-time database of the intelligent telemetry machine. For data in special scenarios, the plugin mechanism can also be used to extend the data.

[0060] In this embodiment, the plugin manager is responsible for scanning, loading plugins, finding and registering the entry points for metadata retrieval functions provided by the plugins. All entry functions are indexed and cached using ID signatures and entry addresses, so that function pointers can be quickly obtained through the plugin manager during data retrieval, indirectly calling the plugin functions to obtain newly extended data.

[0061] This application provides a plug-in extension method that achieves high scalability through plug-ins (shared libraries, SO / DLLs), mainly including: (1) Plugin Manager: Scans the preset plugin directory when the main program starts and dynamically loads the SO / DLL files therein.

[0062] (2) Function registration: The plugin finds and registers the exported specific functions into the name-function pointer mapping table.

[0063] (3) Unified interface: All data acquisition plugins must follow the unified function signature.

[0064] (4) Calling process: When the main program needs to obtain data, it obtains the corresponding function pointer according to the function name, and then passes the function parameters to the plugin function in a unified manner. The plugin function is responsible for parsing its own parameters and implementing the data acquisition logic.

[0065] See Figure 3 As shown in the diagram, this application provides an architecture diagram of an MQTT message forwarding system. Figure 3 As shown, the MQTT message forwarding system of this application embodiment is deployed in a smart remote control machine or industrial gateway, serving as the core data cloud module. It mainly includes: (1) Main program: responsible for scanning configuration files, managing multiple MQTT forwarding threads, and coordinating data flow.

[0066] (2) MQTT forwarding thread: Each thread corresponds to an instance and is responsible for independently managing the MQTT connection with a cloud platform, data collection and publishing cycle. It can assemble messages, connect to the MQTT cloud platform, and publish messages.

[0067] (3) PluginManager: Responsible for dynamically loading extension plugins (SO / DLL) and managing the registration and search of data retrieval functions.

[0068] (4) Data source: The interface of the data source is such as the Realtime Database (Realtime DB) interface or the System Information API (Application Programming Interface). If there are special requirements, it can be extended by using the dynamic library of the plugin.

[0069] The message forwarding method in this application embodiment is triggered periodically or on demand within each MQTT forwarding thread, including the following: (1) Task scheduling: The thread triggers the data acquisition task according to the periodic upload and sudden upload in the configuration file.

[0070] (2) Traverse metadata: The thread traverses the metadata array under the current configuration file and collects specific data.

[0071] (3) Call the plugin manager: For each metadata that needs to obtain data, the program obtains the metadata ID, description and function name, and indirectly calls the plugin function through the function pointer.

[0072] (4) Execution of plugin functions: The plugin function will automatically parse funcParamsJson and sharedDataJson, extract the required parameters (such as telemetry point number, time format, etc.), execute its specific data acquisition logic, and fill the result into the value container result. For example, to obtain a single value from the real-time database, the underlying real-time database API will be called to obtain the YC value (analog measurement value).

[0073] (5) Data post-processing: The core program obtains the data in the ValueContainer and performs type conversion, precision formatting, value mapping, and other processing according to the metadata output configuration. The processed data, along with the metadata ID, is stored in the processed element mapping.

[0074] (6) Mutation detection: For real-time library data, if mutation detection is enabled, it will be compared with historical values. If the mutation data threshold is exceeded and the minimum mutation interval in seconds is exceeded, it will be marked as a mutation and the data will be sent.

[0075] In some embodiments, before obtaining the fixed fields and dynamic fields in the data to be processed, the method further includes: traversing the data nodes of the message template and using a preset utility function to create missing object nodes in the message template as placeholders.

[0076] In some embodiments, generating a target message based on a padded message template includes: serializing the padded message template to obtain a string in a predetermined data exchange format, which is then used as the target message.

[0077] This application's embodiments parse the message template in the configuration file, perform type conversion on the message template according to the metadata ID configured in the configuration file, and replace the message template with the result. For more complex arrays or map objects, they are injected into the corresponding positions in the message template according to the metadata configuration. Missing object nodes are automatically created. After performing a depth-first traversal of the entire message template, the final JSON message is constructed, serialized into a string, and published through the MQTT client. The map object is a key-value pair data structure.

[0078] As an example, this application provides a message population process, which is responsible for assembling the acquired and processed data into a final JSON message, including the following steps: (1) Message template loading: Get the message template from the configuration file.

[0079] (2) Data Injection: Traverse the element mapping. For each metadata ID and its value, the message builder uses the data path output by the metadata to locate the target position through an internal utility function. This utility function can intelligently parse path fragments and automatically create non-existent object nodes in the path. Once the location is successful, the processed data (single value, object, or array) is inserted into the specified position.

[0080] (3) Placeholder replacement: Perform a deep traversal of the message template containing the injected data. Identify all placeholders enclosed in {} in all string values ​​(e.g., {dataElement.message_tid}, {device.deviceId}, {currentTime.unixSeconds}). Based on the predefined message context (containing values ​​of all metadata, device configuration information, current time, UUID, etc.), find and replace these placeholders with the actual dynamic values.

[0081] (4) Message serialization: Serialize the final constructed and filled message template into a JSON message string.

[0082] This application also provides a message forwarding process, including the following steps: (1) The filled and serialized string is sent to the topic of the configuration file through the MQTT connection corresponding to the JSON configuration file to complete the message publication.

[0083] (2) Caching mechanism: If the main program detects that the MQTT connection has been disconnected and attempts to reconnect multiple times but still fails, it will enable the caching mechanism to cache all published messages in the local database (Sqlite / MySQL, etc.).

[0084] (3) Retransmission logic: When the MQTT connection is restored, the program will automatically read all unsent messages from the local cache database and retransmit them in order to ensure reliable delivery of data.

[0085] This application aims to address the problems of low development efficiency, high maintenance cost, poor scalability, configuration redundancy, and insufficient data reliability in existing MQTT data forwarding schemes. It provides a general MQTT message forwarding method with high versatility, high flexibility, and high maintainability, specifically solving the following problems: (1) Significantly reduce the repetitive development work of remote motors for different cloud platforms and device specifications.

[0086] (2) By using external configuration drivers, rapid adaptation and specification changes can be achieved, reducing maintenance costs.

[0087] (3) Through the plug-in mechanism, it supports the dynamic expansion of new data sources and processing logic.

[0088] (4) Optimize configuration management, reduce redundant information, and support a program to access multiple cloud platforms simultaneously.

[0089] (5) Provide a reliable message storage and retransmission mechanism to ensure that data is not lost when the network is abnormal.

[0090] (6) Implement periodic data reporting and flexible reporting strategies based on value changes (mutations).

[0091] (7) Supports efficient and flexible JSON message construction to adapt to complex and ever-changing cloud data format requirements.

[0092] This application's embodiments achieve rapid adaptation for MQTT forwarding through external configuration drivers, plug-in extensions, and efficient data processing mechanisms, offering the following significant advantages and positive effects: (1) Extremely high development efficiency: Through configuration file-driven and plug-in mechanism, it avoids repetitive coding for each platform or specification, greatly shortens the development cycle, and achieves the goal of "one program to adapt to thousands of different specifications".

[0093] (2) Significantly reduce maintenance costs: Changes or new requirements can be addressed by modifying configuration files and deploying new plugins without modifying the core code or recompiling and deploying the entire program, which significantly reduces the complexity and risk of system maintenance.

[0094] (3) Excellent scalability and flexibility: The plug-in architecture allows for the dynamic addition of new data sources and new data processing logic without modifying the core program, easily coping with future functional expansion.

[0095] (4) Optimized configuration management: The configuration sharing mechanism between different devices on the same cloud platform reduces configuration redundancy, making the configuration clearer and easier to manage. The single configuration file corresponds to a single thread mode, which supports concurrent access from multiple cloud platforms and ensures mutual isolation, thereby improving system stability and resource utilization.

[0096] (5) High data reliability: The built-in message caching and retransmission mechanism ensures that messages are not lost when the network is interrupted or the MQTT connection is abnormal, thus ensuring the integrity and reliability of data transmission.

[0097] (6) Flexible data reporting strategy: It supports periodic reporting of data points and intelligent reporting mechanism based on value changes (mutations), which reduces unnecessary data transmission, optimizes network bandwidth usage, and improves the timeliness of key data.

[0098] (7) Efficient and flexible message construction: The highly parameterized data path mapping, data formatting and placeholder replacement functions can flexibly construct JSON message formats that meet the requirements of various complex cloud platforms without hard-coding conversion logic.

[0099] (8) Easy deployment and management: As a core component of the intelligent remote machine docking cloud platform, its modular design and configuration file-driven characteristics make deployment, configuration and troubleshooting easier.

[0100] This application provides a powerful, easily expandable and maintainable general-purpose MQTT message forwarding solution that can effectively solve various pain points in the prior art and significantly improve the efficiency, reliability and adaptability of data migration to the cloud in power systems and other industrial scenarios.

[0101] See Figure 4 As shown, this application embodiment provides a schematic diagram of the structure of a message forwarding device 40. Figure 4 As shown, the message forwarding device 40 of this application embodiment is applied to a remote control machine. The message forwarding device 40 includes: a first acquisition module 401, a parsing module 402, a second acquisition module 403, a generation module 404, and a sending module 405.

[0102] The first acquisition module 401 is used to acquire a configuration file in a predetermined data exchange format; Parsing module 402 is used to parse the configuration file to determine the message template and metadata configuration; the metadata configuration includes the metadata acquisition interface; The second acquisition module 403 is used to acquire data to be processed from a preset database based on the metadata acquisition interface; the data to be processed is data from the substation's measurement and control devices collected by the remote motor. The generation module 404 is used to generate a target message based on the message template and the data to be processed; The sending module 405 is used to send the target message to the terminal device.

[0103] Optionally, the metadata configuration includes metadata support for sending timing; the generation module 404 is used to fill the data to be processed into the message template and generate the target message if the metadata support for sending timing is periodic; if the metadata support for sending timing is abrupt, the data to be processed is filled into the message template and the target message is generated when it is determined that the data to be processed has abruptly changed.

[0104] Optionally, the generation module 404 is used to obtain fixed fields and dynamic fields in the data to be processed; write the fixed fields into the message template, and fill the dynamic fields into the message template through placeholders to obtain the filled message template; and generate the target message based on the filled message template.

[0105] Optionally, the generation module 404 is used to traverse the data nodes of the message template before obtaining the fixed and dynamic fields in the data to be processed, and to create the missing object nodes in the message template as placeholders using a preset utility function.

[0106] Optionally, the generation module 404 is used to serialize the filled message template to obtain a string in a predetermined data exchange format as the target message.

[0107] Optionally, the metadata configuration includes a function lookup index; the second acquisition module 403 is also used to acquire function pointers based on the function lookup index through a preset plugin manager; the plugin manager is used to scan and load plugin files to register exported function pointers; based on the function pointers, the plugin function corresponding to the function pointers is called to acquire the data to be processed from the preset database.

[0108] Optionally, the first acquisition module 401 is used to scan the configuration files in the specified directory and acquire at least one configuration file when the main program starts. Optionally, the sending module 405 is used to create a thread for each configuration file; each thread corresponds to an MQTT connection with a terminal device.

[0109] In applications, the modules in the message forwarding device 40 can be software program modules, or they can be implemented through different logic circuits integrated in the processor, or they can be implemented through multiple distributed processors.

[0110] The message forwarding device 40 of this application embodiment can execute the method provided in this application embodiment. The implementation principle is similar. The actions performed by each module in the message forwarding device 40 of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the message forwarding device 40, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0111] See Figure 5 As shown, this application provides a schematic diagram of the structure of a remote control unit 50. Figure 5 As shown, the remote control unit 50 of this application embodiment includes: a memory 52, a processor 51, and a computer program 53 stored in the memory 52 and executable on the processor 51. When the processor 51 executes the computer program, it implements the steps of the methods of the various embodiments of this application.

[0112] The remote control unit 50 may include, but is not limited to, a processor 51 and a memory 52. ​​Those skilled in the art will understand that... Figure 5The example shown is merely a representation of the remote control 50 and does not constitute a limitation on the remote control 50. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0113] The processor 51 can be a Central Processing Unit (CPU), but it can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0114] In some embodiments, memory 52 may be an internal storage unit, such as a hard disk or RAM. Memory 52 may be a removable / non-removable, volatile / non-volatile computer system storage medium; for example, memory 52 may be a non-volatile memory used for reading and writing non-volatile magnetic media. In other embodiments, memory 52 may be an external storage device, such as a plug-in hard disk on the remote control 50, a Smart Media Card (SMC), a Secure Digital (SD) card, a Flash Card, etc. Memory 52 is used to store the operating system, applications, bootloader, data, and other programs, such as program code for computer programs. Memory 52 may also be used to temporarily store data that has been output or will be output.

[0115] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0117] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0118] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.

[0119] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc. The storage medium can also include combinations of the above types of memory.

[0120] This application provides a computer program product that, when run on a processor, enables the processor to execute the steps described in the various method embodiments above.

[0121] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0122] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0123] In the embodiments provided in this application, it should be understood that the disclosed apparatus / network devices and methods can be implemented in other ways. For example, the apparatus / network device embodiments described above are merely illustrative. For instance, the division of modules or units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0124] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0125] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A message forwarding method, characterized in that, Applied to a telematics unit, the method includes: Obtain the configuration file in the predetermined data exchange format; The configuration file is parsed to determine the message template and metadata configuration; the metadata configuration includes a metadata retrieval interface. Based on the metadata acquisition interface, data to be processed is obtained from a preset database; the data to be processed is the data collected by the remote motor from the substation's measurement and control device. Based on the message template and the data to be processed, a target message is generated; The target message is sent to the terminal device.

2. The message forwarding method according to claim 1, characterized in that, The metadata configuration includes metadata support for sending timing; Based on the message template and the data to be processed, a target message is generated, including: If the metadata supports periodic sending, then the data to be processed is filled into the message template to generate the target message; If the metadata supports a sudden change in the sending timing, then when it is determined that the data to be processed has changed, the data to be processed is filled into the message template to generate the target message.

3. The message forwarding method according to claim 2, characterized in that, The step of filling the message template with the data to be processed to generate the target message includes: Obtain the fixed and dynamic fields from the data to be processed; Write the fixed fields into the message template, and fill the dynamic fields into the message template using placeholders to obtain the filled message template; The target message is generated based on the filled message template.

4. The message forwarding method according to claim 3, characterized in that, Before obtaining the fixed fields and dynamic fields in the data to be processed, the process also includes: The data nodes of the message template are traversed, and a preset utility function is used to create missing object nodes in the message template as placeholders.

5. The message forwarding method according to claim 3, characterized in that, The process of generating the target message based on the filled message template includes: The filled message template is serialized to obtain a string in a predetermined data exchange format, which is used as the target message.

6. The message forwarding method according to any one of claims 1-5, characterized in that, The metadata configuration includes a function lookup index; After parsing the configuration file to determine the message template and metadata configuration, the process also includes: Based on the function lookup index, the function pointer is obtained through a preset plugin manager; the plugin manager is used to scan and load plugin files to register the exported function pointers. Based on the function pointer, the corresponding plugin function is called to retrieve the data to be processed from the preset database.

7. The message forwarding method according to any one of claims 1-5, characterized in that, The step of obtaining the configuration file in the predetermined data exchange format includes: scanning the configuration files in the specified directory and obtaining at least one of the configuration files when the main program starts. After obtaining the configuration file in the predetermined data exchange format, the process includes: Create one thread for each of the aforementioned configuration files; Each thread establishes a Message Queuing Telemetry Transport Protocol (MQTT) connection with one of the terminal devices.

8. A message forwarding device, characterized in that, Applications in telemetry include: The first acquisition module is used to acquire a configuration file in a predetermined data exchange format; The parsing module is used to parse the configuration file to determine the message template and metadata configuration; the metadata configuration includes a metadata acquisition interface. The second acquisition module is used to acquire data to be processed from a preset database based on the metadata acquisition interface; the data to be processed is the data collected by the remote motor from the substation's measurement and control device. The generation module is used to generate a target message based on the message template and the data to be processed; The sending module is used to send the target message to the terminal device.

9. A teletype, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images