Power protocol development system, electronic device, and computer-readable storage medium

Abstract

The application relates to the technical field of power system substation automation, in particular to a power protocol development system, an electronic device and a computer readable storage medium. The system comprises a protocol processing core engine module, which is used for providing a basic function framework of protocol processing. A dynamic loading library storage module is used for storing a plurality of dynamic loading libraries. A protocol configuration generation module is used for generating a protocol configuration file, wherein combination information of the dynamic loading libraries corresponding to a target communication protocol is recorded in the protocol configuration file. A protocol running management module is connected with the protocol processing core engine module, the dynamic loading library storage module and the protocol configuration generation module, respectively, and is used for reading the corresponding protocol configuration file when the target communication protocol starts, and loading the protocol function modules in the dynamic loading libraries to the corresponding scheduling interfaces in the protocol processing core engine module. The application can realize plug and play and flexible expansion of the protocol function modules, and improves the development efficiency and maintenance convenience.

Description

Technical Field

[0001] This application relates to the field of power system substation automation technology, and in particular to a power protocol development system, electronic equipment, and computer-readable storage medium. Background Technology

[0002] In the field of substation automation in power systems, gateway devices, as the core hub for data interaction, must simultaneously integrate and operate multiple power communication protocols such as IEC 61850 (MMS / CMS), IEC 60870-5-101 / 104, and MODBUS. With the advancement of new power system construction, a large number of new energy sources such as distributed power sources and energy storage are being connected, leading to a significant increase in both the types and quantities of protocol adaptation requirements.

[0003] Traditional technical solutions typically involve writing a complete set of protocol processing code independently for each new protocol or different vendor variants of the same protocol. This approach has the following technical drawbacks: First, different protocols repeatedly implement common processing steps such as connection management, timeout retries, and message framing. Even protocols within the same family cannot achieve binary-level reuse, requiring re-adaptation and porting when the platform changes. Second, the same protocol exhibits non-standard differences in information object address arrangement and optional function enabling across different vendor devices, requiring line-by-line adaptation and debugging. Furthermore, underlying communication and multi-threading issues are often intertwined with protocol logic, making localization difficult. Additionally, when expanding functionality or adapting to different vendors, new versions are generated using a branch-copying method. As the number of protocol variants increases, it becomes difficult to synchronize the fixing of common defects, leading to chaotic version management.

[0004] However, traditional technical solutions typically employ object-oriented specification design frameworks or configuration script mechanisms to separate message structure definition from parsing logic, but this still fails to resolve the fundamental contradiction. There is a lack of standardized runtime assembly mechanisms between the general processing flow of the specification and specific business semantics, which means that the developed functional units cannot be dynamically combined and deployed in a plug-and-play manner, and the entire specification module still needs to be compiled and replaced when adjusting some business semantics. Summary of the Invention

[0005] This application provides a power protocol development system, electronic device, and computer-readable storage medium. Through a fixed engine framework and a runtime architecture that dynamically loads modules according to configuration, it enables plug-and-play and flexible expansion of protocol functional modules, improving development efficiency and maintenance convenience.

[0006] Firstly, this application provides a power protocol development system, comprising: a protocol processing core engine module, which provides a basic functional framework for protocol processing, wherein multiple protocol processing scheduling interfaces are defined in the basic functional framework; a dynamic loading library storage module, which stores multiple dynamic loading libraries, each containing one or more protocol function modules; a protocol configuration generation module, which generates protocol configuration files, wherein the protocol configuration files record the combination information of the dynamic loading libraries corresponding to the target communication protocol; and a protocol operation management module, which is connected to the protocol processing core engine module, the dynamic loading library storage module, and the protocol configuration generation module, respectively, for reading the corresponding protocol configuration file when the target communication protocol starts, loading the corresponding dynamic loading library from the dynamic loading library storage module according to the combination information, and loading the protocol function modules in each dynamic loading library onto the corresponding scheduling interface in the protocol processing core engine module.

[0007] In some implementations, the protocol operation management module loads the protocol function modules in each dynamically loaded library onto the corresponding scheduling interface in the protocol processing core engine module. This includes: loading the corresponding dynamically loaded library into the process address space of the protocol processing core engine module, and establishing a call association between the function exported from the dynamically loaded library and the scheduling interface through symbol lookup or function pointer binding.

[0008] In some implementations, the protocol processing core engine module defines multiple protocol processing scheduling interfaces, including: a message receiving and framing scheduling interface, a message parsing and classification scheduling interface, a data sending and framing scheduling interface, a data uploading and processing scheduling interface, a subsequent data uploading scheduling interface, an operation and mutual exclusion control scheduling interface, a processing priority management scheduling interface, and a timeout control scheduling interface.

[0009] In some implementations, the protocol function module in the dynamically loaded library includes: a protocol specification function module for implementing message format processing for a single communication protocol; and a protocol service function module for implementing one or more protocol application service functions. Each protocol specification function module uniquely corresponds to a communication protocol and is used to implement link-layer message framing verification, application-layer message parsing and classification, and message framing and encapsulation functions for that communication protocol. The protocol service function module comprises multiple modules, each corresponding to a different type of message service for that communication protocol, and is used to implement application service functions including data upload processing, subsequent data upload, operation control, and mutual exclusion processing.

[0010] In some implementations, when the specification configuration generation module generates the specification configuration file, it records in the configuration file the path identifier of the dynamically loaded library, the type identifier of each dynamically loaded library, the calling relationship between the dynamically loaded libraries, the corresponding mapping relationship between the specification service function modules and the specification message type, the timing coordination relationship between multiple specification service function modules, and the connection relationship between the data upload trigger conditions of each specification service function module and the subsequent data upload target. The type identifier is used to distinguish whether the dynamically loaded library belongs to the specification specification function module or the specification service function module.

[0011] In some implementations, after the protocol operation management module reads the protocol configuration file and before loading the dynamic loading library, it also performs a configuration verification step, including: verifying the existence of the dynamic loading library file referenced in the protocol configuration file, verifying the consistency of the interface signatures between each scheduling interface and the loaded functional module, and verifying the uniqueness of the mapping relationship between the protocol message type and the service functional module.

[0012] In some implementations, the configuration file generated by the protocol configuration generation module can be modified or created to redetermine the combination information of the dynamically loaded libraries corresponding to the target communication protocol, in order to adapt to the differences in applications from different manufacturers or the need for extended protocol functionality for the same communication protocol. The core engine module for protocol processing remains unchanged during the adaptation process.

[0013] In some implementations, the protocol processing core engine module also encapsulates a protocol registration interface, a protocol initialization interface, a protocol startup interface, and a protocol stop interface, used for unified registration, initialization, startup, and stop management of loaded protocol processing function instances. The protocol processing core engine module also includes a runtime status monitoring unit and an exception handling unit, used to monitor the runtime status of protocol processing function instances and perform exception handling when exceptions occur.

[0014] Thirdly, this application provides a chip for performing the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system described in the first aspect above.

[0015] Fourthly, this application provides an electronic device including a processor and a memory. The processor executes a computer program stored in the memory to implement the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system described in the first aspect above. Alternatively, Electronic devices include chips, as described in the third aspect.

[0016] Fifthly, this application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system described in the first aspect above.

[0017] Sixthly, this application provides a computer program product that stores a computer program. When the computer program is executed by a processor, it performs the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system described in the first aspect above.

[0018] In the power protocol development system provided in this application embodiment, the protocol processing core engine module provides a unified and fixed basic functional framework and scheduling interface. It also includes a dynamically loaded library storage module for storing reusable protocol function modules, a protocol configuration generation module, and a protocol operation management module. When a target protocol starts, the corresponding function modules are dynamically loaded and assembled onto the engine's scheduling interface based on the configuration file. This achieves modular and configurable development of protocol functions, eliminating the need for repeated engine development when a new protocol is integrated. Furthermore, when there are differences between different manufacturers of the same protocol or when functions are expanded, only the module combination and configuration need to be adjusted. This effectively solves the technical problems of low development efficiency, high debugging difficulty, and difficult maintenance management in the prior art, improving the development efficiency, debugging convenience, and maintenance flexibility of power communication protocols. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of the system structure of a power protocol development system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the engine specification processing flow of a power specification development system provided in an embodiment of this application; Figure 3 This is a schematic diagram of the communication protocol startup process of a power protocol development system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the protocol message reception and processing flow of a power protocol development system provided in an embodiment of this application; Figure 5This is a schematic diagram of the active data upload processing flow of a power protocol development system provided in an embodiment of this application; Figure 6 This is a schematic diagram of the protocol termination and resource release process of a power protocol development system provided in an embodiment of this application; Figure 7 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] 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 can 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.

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

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

[0024] 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]."

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

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

[0027] In the field of substation automation in power systems, the gateway (or station control layer communication management unit) serves as the core hub for data interaction, requiring it to establish communication links with intelligent electronic equipment in the substation bay layer and dispatch control centers at all levels. To achieve interoperability between heterogeneous devices, the gateway must integrate and run multiple power communication protocols at the application layer, primarily including MMS / CMS defined by the IEC 61850 standard, IEC 60870-5-101 / 104, and MODBUS.

[0028] In recent years, with the advancement of the construction of new power systems, a large number of new energy sources such as distributed power sources and energy storage systems have been connected to the power grid, resulting in a more diversified range of communication protocol types. The demand for protocol adaptation has shown a significant growth trend in both type and quantity.

[0029] In existing technical practices, the implementation of the aforementioned protocol access requirements typically adopts the following development model: for each new protocol or different vendor implementation variants of the same protocol, a complete set of protocol message processing code is independently designed and written, including all aspects such as link layer framing / framing, application layer data parsing, service data mapping, and operation control processes. This model has the following technical drawbacks: First, the specification development process involves duplication of effort and inefficient reuse.

[0030] Different protocols share highly similar processing logic in areas such as communication flow control, connection management, timeout retries, and message framing and reassembly. However, under traditional development methods, these common processing steps are repeatedly implemented with the development of each new protocol. Even protocols within the same family with highly similar application-layer service definitions still require separate coding and implementation of their link-layer and application-layer control flows, making it impossible to directly reuse existing development results at the binary code level. When the system operating environment or underlying platform changes, the accumulated protocol code resources need to be re-adapted and ported, further exacerbating the duplication of effort.

[0031] Second, the workload for protocol debugging and anomaly troubleshooting is high.

[0032] The specific implementations of the same specification standard across different vendors' devices exhibit numerous non-standard differences. These include variations in information object address arrangement, inconsistent semantic extensions of cause transmission reasons, and differences in the enabling or disabling of optional functions (such as selection confirmation mechanisms and call cycles). These differences cannot be eliminated at the specification text level and must be addressed through line-by-line adaptation development. Each new device type introduced signifies a new round of specification difference debugging. Furthermore, anomalies caused by issues such as underlying communication links and multi-threaded resource contention during debugging are often intertwined with the specification logic itself, increasing the complexity of problem localization.

[0033] Third, the management costs of expanding specification functions and maintaining versions have increased.

[0034] When the same specification needs functional expansion due to changes in application scenarios, or when new application variants need to be generated due to the integration of new manufacturers' equipment, existing development methods typically generate independent new specification versions through methods such as branch copying or conditional compilation. As the number of integrated specifications increases, the number of specification variants in the code repository grows linearly or even superlinearly. It becomes difficult to synchronize and trace back the defects and functional upgrades of common parts among the variants, resulting in chaotic version management and increased maintenance risks.

[0035] To address the aforementioned issues, some existing technical solutions have proposed improvements. For example, an object-oriented specification design framework is adopted, abstracting the specification processing into a finite state machine model and organizing the code structure in a modular manner, thereby improving code readability and maintainability to some extent. Another approach introduces a configuration script mechanism, separating the specification's message structure definition from its parsing and execution logic, aiming to adapt to different specifications by modifying configuration files rather than the source code. However, these improvements still fail to fundamentally resolve the following technical contradictions: the lack of a standardized runtime assembly mechanism between the specification's general processing flow and specific business semantics prevents the developed specification functional units from being dynamically combined and flexibly deployed in a plug-and-play manner. When the specification's general processing flow remains unchanged, and only some of its business semantics (such as data transmission content or operation control methods) need to be adjusted, the entire specification module still needs to be recompiled and replaced, rather than simply changing the modified parts.

[0036] In view of this, the present application provides a power protocol development system that can achieve plug-and-play and flexible expansion of protocol function modules through a fixed engine framework and a runtime architecture that dynamically loads modules according to configuration, thereby improving development efficiency and maintenance convenience.

[0037] The technical solutions of the embodiments of this application are described below with reference to the examples in the accompanying drawings.

[0038] This application provides a power protocol development system, which can be divided into three layers at the software architecture level: a protocol processing core engine layer, a dynamic loading library layer, and a protocol configuration layer. The protocol processing core engine layer encapsulates basic services such as communication connection management, thread scheduling, and resource management, and defines standardized protocol processing scheduling interfaces. The dynamic loading library layer can contain multiple independent dynamic loading library files, each of which can encapsulate the binary executable code of one or more protocol function modules. The protocol configuration layer can record the combination information of the dynamic loading libraries referenced by the target communication protocol through a protocol configuration file. During runtime, the system can dynamically load the corresponding dynamic loading libraries according to the protocol configuration file and load the protocol function module interfaces from each dynamic loading library onto the scheduling interface of the protocol processing core engine, thereby assembling a complete protocol processing function instance.

[0039] Figure 1 This is a schematic diagram of the system architecture of a power protocol development system provided in an embodiment of this application. Figure 1 As shown, the power protocol development system provided in this application embodiment includes a protocol processing core engine module 100, a dynamic loading library storage module 200, a protocol configuration generation module 300, and a protocol operation management module 400.

[0040] The protocol operation management module 400 is connected to the protocol processing core engine module 100, the dynamic loading library storage module 200, and the protocol configuration generation module 300. These connections include communication connections and / or data connections, used to enable data interaction and control command transmission between the modules.

[0041] The reduction processing core engine module 100 provides the basic functional framework for reduction processing. This basic functional framework defines multiple reduction processing scheduling interfaces.

[0042] For example, the specification processing core engine module 100 can encapsulate the following basic services: Communication Connection Management Service: Establishes and manages physical communication links based on the communication ports associated with the target communication protocol, including unified management of various communication methods such as TCP / IP socket connections and serial port connections. The service monitors the activity of established communication connections, periodically sends link test messages to confirm link status, and performs a link reset operation when an anomaly is detected.

[0043] Thread scheduling service: Responsible for the creation, scheduling, and destruction management of task threads during protocol processing, ensuring reasonable allocation of processor time when multiple protocols run concurrently. The thread scheduling service performs differentiated scheduling of processing tasks for different protocol instances according to the processing priorities set in the protocol configuration file.

[0044] Resource Management Service: Responsible for the allocation, use, and reclamation management of basic resources such as memory buffers, timers, and semaphores required during protocol operation, preventing resource leaks and resource contention.

[0045] Figure 2 This application provides a schematic diagram of the engine specification processing flow for a power specification development system. In one specific implementation, the specification processing core engine module 100 defines multiple specification processing scheduling interfaces, such as... Figure 2 As shown, it specifically includes: Message receiving and framing scheduling interface: It can be used to assemble message frames from the received raw data stream according to the feature words and protocol specifications.

[0046] Message parsing, classification, and scheduling interface: This can be used to extract the protocol service category and corresponding data content from the assembled message according to the protocol rules.

[0047] Data transmission frame scheduling interface: It can be used to package and frame the data to be sent according to the protocol rules, and supplement the protocol link control and application layer control information.

[0048] Data upload processing and scheduling interface: It can be used to upload data parsed from protocol messages to the system data bus after converting the format according to the system data model requirements.

[0049] Subsequent data upload scheduling interface: Used to continue uploading the processed data to the target module according to the data upload trigger conditions and subsequent data upload targets set in the specification configuration file.

[0050] Operation and Mutual Exclusion Control Scheduling Interface: This interface can be used to process operation control commands from the control center or local system, and to control the mutual exclusion relationship between multiple operations under the same protocol.

[0051] Priority management and scheduling interface: It can be used to perform differentiated scheduling of multiple data queues to be sent according to the priority parameters set in the specification configuration file.

[0052] Timeout control scheduling interface: It can be used to process messages that do not receive a response within a specified time according to the timeout parameters set in the protocol configuration file.

[0053] In one specific implementation, the protocol processing core engine module 100 also encapsulates a standardized protocol registration interface, a protocol initialization interface, a protocol startup interface, and a protocol stop interface.

[0054] The protocol registration interface can be used to register protocol processing function instances with the system when the system starts. The registration information includes the protocol instance identifier, protocol name, communication port number, running status, etc. The system uses the registration information to manage all running protocol instances in a unified manner.

[0055] The protocol initialization interface can be used to perform initialization operations after the protocol function modules are loaded. Initialization operations include: allocating the buffer resources required for operation to the function modules in each dynamically loaded library, setting protocol operation parameters (such as link address, station address, timeout, etc.), and creating sockets or serial port handles for communication connections.

[0056] The protocol startup interface can be used to trigger the protocol processing function instance to start running. Startup operations include: creating and starting the communication receiving thread and the protocol processing thread, and enabling the data transmission and reception functions of the communication link.

[0057] The protocol stop interface can be used to stop the operation of a protocol processing function instance. Stop operations include: terminating the communication receive thread and the protocol processing thread, closing the communication connection, and releasing held buffer resources and timer resources.

[0058] In one specific implementation, the protocol processing core engine module 100 may also include a runtime status monitoring unit and an exception handling unit. The runtime status monitoring unit collects runtime status information for each protocol function instance at a preset time period (e.g., once per second). This runtime status information includes, but is not limited to: communication link status (connected / disconnected), cumulative number of received packets, cumulative number of sent packets, cumulative number of abnormal events, and last communication time. The exception handling unit executes corresponding exception handling operations when an abnormal state is detected, including: automatic reconnection when a link is abnormal, recording an error log and discarding the abnormal packet when packet parsing is abnormal, and retransmitting the packet or sending a timeout alarm to the system when a timeout occurs.

[0059] The dynamic library storage module 200 can be used to store multiple dynamic libraries. At the file system level, the dynamic library storage module 200 provides a unified storage directory and access interface for each dynamic library. Each dynamic library contains the binary executable code of one or more specification function modules. For example... Figure 2 As shown, the specification function modules include two categories: specification normative function modules and specification service function modules.

[0060] The protocol specification module is used to implement message format processing for a single communication protocol. Each protocol specification module uniquely corresponds to one communication protocol; that is, there is one and only one protocol specification module in the system for the same communication protocol. This uniqueness ensures that the message format processing logic is consistent for any protocol, avoiding processing confusion caused by the existence of multiple versions of specification modules.

[0061] Protocol service function modules are used to implement one or more protocol application service functions. There are multiple protocol service function modules, each corresponding to a different type of message service within the communication protocol. Specifically, the protocol service function modules implement the following functions: Data upload processing function: After parsing the message, the data obtained is converted into a format according to the requirements of the system data model and then uploaded to the system data bus.

[0062] Subsequent data upload function: According to the data upload trigger conditions (such as data change trigger, periodic upload trigger, etc.) and subsequent data upload targets set in the specification configuration file, the data will continue to be uploaded to the subsequent processing module.

[0063] Operation control and mutual exclusion handling functions: Process remote control and remote adjustment operation commands from the control center or local system, and ensure that the mutual exclusion relationship between multiple operation requests under the same protocol is properly managed.

[0064] In one specific implementation, for the parts of the application layer service definitions that are the same in the IEC 101 and IEC 104 protocol families, the same protocol service function module is developed and a single dynamically loaded library file is provided for reference by the protocol configuration files of both protocols. For example, the telemetry transmission service in IEC 101 and IEC 104 is completely identical in data structure and business logic. After developing this service into an independent dynamic library file, both the IEC 101 and IEC 104 protocol configuration files can reference this dynamic library, thereby achieving cross-protocol reuse of function modules.

[0065] The protocol configuration generation module 300 is used to generate a protocol configuration file. The protocol configuration file records the combination information of the dynamically loaded libraries corresponding to the target communication protocol. In one specific embodiment of this application, the protocol configuration file can be stored as an XML file. In another specific embodiment of this application, the protocol configuration file is stored as a JSON file. Both XML and JSON formats are structured data description formats, possessing good readability and extensibility, and are easy for manual editing and program parsing.

[0066] When the specification configuration generation module 300 generates the specification configuration file, it records the following information in the specification configuration file: the path identifier of the dynamically loaded library, the type identifier of each dynamically loaded library, and the calling relationship between each dynamically loaded library.

[0067] The protocol operation management module 400 is connected to the protocol processing core engine module 100, the dynamic loading library storage module 200, and the protocol configuration generation module 300. The protocol operation management module 400 reads the corresponding protocol configuration file when the target communication protocol starts, loads the corresponding dynamic loading library from the dynamic loading library storage module 200 according to the combination information in the protocol configuration file, and loads the protocol function modules from each dynamic loading library onto the corresponding scheduling interface in the protocol processing core engine module 100.

[0068] In one specific implementation, the protocol operation management module 400 loads the protocol function modules from each dynamically loaded library onto the corresponding scheduling interface in the protocol processing core engine module 100, specifically including the following steps: First, the protocol execution management module 400 calls the dynamic loading interface provided by the operating system based on the dynamic library path identifier recorded in the protocol configuration file. Second, after the dynamic library is successfully loaded, the protocol execution management module 400 obtains the addresses of exported functions from the dynamic library through symbol lookup. Finally, the protocol execution management module 400 assigns the obtained function pointers to the corresponding scheduling interface function pointer variables in the protocol processing core engine module 100, thereby establishing a call association.

[0069] In one specific implementation, after reading the specification configuration file and before loading the dynamic loading library, the specification operation management module 400 also performs a configuration verification step. The configuration verification step may include the following three types of verification: Existence verification (completeness check): Traverse all dynamically loaded library path identifiers recorded in the specification configuration file, and check whether the corresponding dynamically loaded library file exists and is readable in the file system for each path. If any dynamically loaded library file does not exist or is unreadable, the verification fails, the specification runtime management module records the missing file path and terminates the startup process.

[0070] Interface signature consistency verification (interface matching check): When performing symbol lookup to obtain function pointers for dynamically loaded libraries, the function signature (including function return type, number of parameters, and parameter types) of the obtained function pointers is verified to be consistent with the function signatures required by each scheduling interface in the specification processing core engine module 100. If the signatures do not match, loading fails, and the specification runtime management module 400 records the name of the function with the mismatched signature and terminates the startup process. This verification can be achieved by defining a unified data structure (containing function pointer type definitions) for each scheduling interface during the development phase and performing type checking at runtime.

[0071] Mapping Uniqueness Verification: This verifies whether the mapping relationship between protocol message types and service function modules recorded in the protocol configuration file is unique, i.e., whether the same message type is mapped to multiple service function modules. If duplicate mappings are found, the verification fails, the protocol operation management module 400 records the duplicated message types, and terminates the startup process. This uniqueness ensures that for any given message type, the system has one and only one service function module responsible for processing it, avoiding uncertainty in the processing logic.

[0072] The complete workflow of the power protocol development system of this application is described below with reference to the accompanying drawings.

[0073] During the system startup and protocol instance creation phase, after the communication device starts, the system reads the project configuration file according to the actual engineering application, and obtains the list of communication protocols to be used and the communication port information corresponding to each protocol. When the application starts, for each communication protocol in the communication protocol list, the system starts the communication protocol according to the protocol name and protocol identifier in the configuration.

[0074] Figure 3 A schematic diagram of the communication protocol startup process of a power protocol development system provided in this application embodiment. When starting a specific communication protocol, the following steps are executed: Step S301: Based on the protocol name and protocol identifier, locate the corresponding protocol configuration file in the protocol configuration generation module 300.

[0075] Step S302: Generate a specification instance identifier based on the specification configuration file.

[0076] Specifically, using the found protocol configuration file and corresponding communication port parameters as input, the protocol registration interface of the protocol processing core engine module 100 is called to register a new protocol instance with the system and obtain a unique protocol instance identifier.

[0077] Step S303: The protocol operation management module 400 reads the protocol configuration file and performs a configuration verification step on the configuration file.

[0078] For details on the configuration verification steps, please refer to the previous description of the protocol operation management module 400, which includes existence verification, interface signature consistency verification, and mapping uniqueness verification.

[0079] Step S304: After the verification is passed, the protocol operation management module 400 loads the corresponding dynamic library files into the process address space in sequence according to the dynamic library path identifier in the configuration file.

[0080] Only one normative functional module is loaded (i.e., the only normative functional module dynamic library recorded in the specification configuration file), while several service functional modules are loaded (i.e., all service functional module dynamic libraries recorded in the specification configuration file).

[0081] Step S305: Based on the dynamic library type identifier, the specification operation management module 400 loads the functions of the specification module, such as framing and parsing, and the functions of the service module, such as data uploading and control, into the corresponding scheduling interface of the core engine.

[0082] According to the type identifier of each dynamically loaded library, the protocol operation management module 400 loads the exported functions (receive frame assembly function, parse classification function, send frame assembly function) of the normative function module onto the corresponding scheduling interface of the protocol processing core engine module 100; and loads the exported functions (data upload processing function, subsequent upload function, operation control function, etc.) of each service function module onto the corresponding scheduling interface of the engine according to the message type mapping relationship.

[0083] Step S306: The specification processing core engine module 100 calls the specification initialization interface to perform initialization operations on each loaded functional module.

[0084] Specifically, this includes: allocating buffer resources required for each module to run, setting protocol running parameters, creating sockets or serial port handles for communication connections, and initializing timer resources.

[0085] Step S307: The protocol processing core engine module 100 calls the protocol startup interface to create and start the communication receiving thread and the protocol processing thread.

[0086] Specifically, it is used to enable the data transmission and reception function of the communication link and to register the functional instance of this protocol with the system, so that the system can monitor and manage the operational status of the protocol through the operational status monitoring unit.

[0087] Figure 4 This is a schematic diagram illustrating the protocol message reception and processing flow of a power protocol development system provided in this application embodiment. After the protocol processing function instance starts running, the following processing flow is executed for each received communication message: Step S401: The communication connection management component receives the raw message data stream through the established communication link and stores the received raw data into the message receiving buffer.

[0088] Step S402: The message receiving component retrieves the original data from the buffer and calls the message receiving frame scheduling interface of the protocol processing core engine module 100.

[0089] The scheduling interface further calls the receive framing function implemented in the protocol specification module to framing the original data stream according to the corresponding frame header features and protocol specifications. Frame verification is performed synchronously during the framing process, including frame length verification, CRC verification, or checksum verification. If framing is successful and verification passes, a complete protocol message frame is obtained and the frame type is recorded; if framing fails or verification fails, the current data segment is discarded and an exception log is recorded, and subsequent data processing continues.

[0090] Step S403: Protocol processing core engine module 100 calls the message parsing, classification and scheduling interface.

[0091] Specifically, this interface further calls the message parsing and classification function implemented in the specification's normative function module to perform application-layer parsing on the complete message frame. The parsing process extracts the service category identifier and data content from the message according to the application-layer specifications of the specification, and classifies the message accordingly to obtain the message type code.

[0092] Step S404: According to the mapping relationship between message types and service function modules recorded in the protocol configuration file, find the protocol service function module that processes the message type.

[0093] According to the message type code obtained in step S203, the protocol processing core engine module 100 finds the corresponding protocol service function module for processing the message type by looking up a table, based on the mapping relationship between message type and service function module recorded in the protocol configuration file.

[0094] Step S405: The specification processing core engine module 100 calls the various function functions in the found specification service function modules in sequence according to the timing coordination relationship between the multiple specification service function modules recorded in the specification configuration file.

[0095] Specifically, this includes data upload processing, subsequent data upload, operation control, and mutual exclusion handling. For message types that do not require certain processing, the corresponding processing step can be configured as a no-operation (i.e., the function returns success directly without performing any actual processing).

[0096] Step S406: If the message type involves operation control, perform operation mutual exclusion check and operation execution.

[0097] If the message type involves operation control (such as remote control or teleading commands), the operation and mutual exclusion control scheduling interface is invoked, and the corresponding service function module performs operation mutual exclusion verification (checking whether other operations are currently being executed) and operation execution (sending operation commands to the target device).

[0098] Step S407: If the message type is a request message and a response is required, then the response data is packaged and framed to generate a complete response message frame.

[0099] If the message is a request message and requires a response, the data sending and framing scheduling interface is called. The sending and framing encapsulation function implemented by the protocol specification function module packages and frams the response data, supplements the protocol link control information, and generates a complete response message frame.

[0100] Step S408: The message sending component calls the sending interface of the communication connection management component to send the framed reply message to the peer device through the communication link.

[0101] Figure 5 This is a schematic diagram of the active data upload processing flow of a power protocol development system provided in an embodiment of this application. For data that needs to be actively uploaded by the protocol (such as change telemetry, fault telemetry, etc.), the following processing flow is executed: Step S501: The active upload processing function in the protocol service function module queues the data that needs to be actively uploaded according to the priority set in the protocol configuration file.

[0102] Specifically, proactively uploaded data is treated as a special message type, and all proactively uploaded data is sent sequentially from highest to lowest priority. Within the same priority level, data is sent in a first-in, first-out (FIFO) order.

[0103] Step S502: The priority management scheduling interface retrieves the highest priority data to be sent from the active data upload queue and determines the sending timing according to the priority parameters set in the protocol configuration file.

[0104] Step S503: Call the data transmission frame scheduling interface. The transmission frame encapsulation function implemented by the protocol specification function module packages and assembles the data to be transmitted to generate a complete active transmission message frame.

[0105] Step S504: The message sending component sends the framed active upload message to the peer device through the communication link.

[0106] Step S505: If actively sending a message requires waiting for an acknowledgment response from the peer device (i.e., the application layer acknowledgment mechanism is defined in the protocol specification), then start a timeout timer. If no acknowledgment response is received within the timeout period set in the protocol configuration file, the timeout control scheduling interface is triggered, and the corresponding service function module performs timeout processing operations, including message retransmission (up to a set number of retransmissions), recording the timeout event, and sending a timeout alarm.

[0107] Figure 6This application provides a schematic diagram of a protocol termination and resource release process for a power protocol development system. When it is necessary to terminate a communication protocol (such as during system shutdown or protocol configuration change), the following steps are executed: Step S601: The system calls the protocol stop interface, the protocol processing core engine module 100 stops the corresponding communication receiving thread and protocol processing thread, and waits for the threads to completely exit.

[0108] Step S602: The protocol processing core engine module 100 closes the communication connection socket or serial port handle it holds and releases the communication link resources.

[0109] Step S603: The protocol processing core engine module 100 calls the resource release function in each dynamically loaded library (each protocol function module implements the corresponding resource release callback function in its dynamic library) to release the memory buffer and timer resources occupied during protocol operation.

[0110] Step S604: The specification runtime management module 400 unloads the loaded dynamic library from the process address space.

[0111] On Windows, the `FreeLibrary` function is called; on Linux, the `dlclose` function is called. After uninstallation, the code and data segment resources occupied by the dynamically loaded library are released.

[0112] Step S605: The protocol processing core engine module 100 calls the protocol deregistration interface to deregister the protocol function instance from the system. The system removes the protocol instance from the running status monitoring list and stops monitoring the running status of the protocol.

[0113] In some implementations, the specification configuration file is not limited to XML or JSON files; it can also be generated by dedicated specification configuration management software. This software provides a graphical user interface, through which developers select the dynamically loaded library files to be referenced, configure the type identifiers of each module, and the calling relationships. The software automatically generates a specification configuration file that conforms to the required format.

[0114] In some implementations, the specification configuration management software automatically performs rule checks when generating specification configuration files. In addition to the existence check, interface signature consistency check, and mapping uniqueness check mentioned above, the software also performs relationship checks, that is, checks whether there are circular dependencies or deadlock risks in the timing coordination relationships between multiple specification service function modules. For example, if module A's timing order precedes module B, and module B's timing order precedes module A, a circular dependency is formed. The software detects this cycle during verification and prompts the user to modify the configuration. The software also performs a linkage check between the configuration and dynamically loaded libraries, that is, checks whether the dynamic library combination information recorded in the configuration file matches the actual set of exported function interfaces in each dynamic library. If a function referenced in the configuration file does not exist in the corresponding dynamic library, the verification fails and the user is prompted.

[0115] In some implementations, the same protocol service function module can be referenced simultaneously by protocol configuration files of multiple different protocols. For example, the IEC 101 and IEC 104 protocols share many similarities in data structure definitions and business processing logic for application layer services such as telemetry, telecontrol, and remote control. These shared service functions can be developed into a general protocol service function module, which can then be referenced by both the IEC 101 and IEC 104 protocol configuration files. When the system runs IEC 101 and IEC 104 instances, each independently loads the same dynamic library file into its respective process address space (or shares the same code segment), thereby maximizing the reuse of protocol function modules across different protocols.

[0116] In some implementations, the protocol processing core engine module 100 also supports the output of operational status monitoring information. The operational status monitoring unit collects operational status information (including communication link status, message transmission and reception statistics, task execution status, abnormal event records, etc.) of each protocol function instance at a preset collection cycle, and outputs the status information to the system monitoring platform or human-machine interface through standardized output interfaces (such as shared memory, message queue or system log interface) to facilitate system operation and maintenance personnel to monitor the system operation status and locate faults.

[0117] This application can be widely used in the field of power system substation automation. Specifically, this application can be deployed on workstations, monitoring hosts, or gateway devices at the substation control layer to enable power communication protocol access between various intelligent electronic devices within the substation and control centers at all levels.

[0118] In the construction, renovation, and expansion of various substations and new energy power plants, for the access requirements of various communication protocols, the flexible and scalable modular development system and method for power protocols described in this application can be adopted. Based on the core protocol processing engine, specific modular protocol components and maintenance management can be realized by developing corresponding dynamic function libraries and writing protocol configuration files. This application can not only significantly improve the efficiency of protocol development, realizing the development of new protocol access with extremely low coding workload, but also significantly reduce the workload of function debugging and the difficulty and workload of subsequent protocol maintenance and management.

[0119] The functions of all or part of the modules in the above system embodiments can be implemented by hardware related to computer program instructions. The aforementioned computer program can be stored in a computer-readable storage medium, and when executed by a processor, it implements the functions of each module in the system described in this application. The computer-readable storage medium can be any medium capable of storing program code, such as a read-only memory (ROM), random access memory (RAM), magnetic disk, optical disk, or flash memory.

[0120] In the technical solution provided in this application embodiment, the protocol processing core engine module provides a unified and fixed basic functional framework and scheduling interface, and sets up a dynamic loading library storage module to store reusable protocol function modules, as well as a protocol configuration generation module and a protocol operation management module. When the target protocol starts, the corresponding function modules are dynamically loaded and assembled onto the engine's scheduling interface according to the configuration file, realizing modular and configurable development of protocol functions. This eliminates the need to repeatedly develop the engine part when a new protocol is connected, and only the module combination and configuration need to be adjusted when there are differences between different manufacturers of the same protocol or when functions are expanded. This effectively solves the technical problems of low development efficiency, high debugging difficulty, and difficult maintenance and management in the prior art, and improves the development efficiency, debugging convenience, and maintenance flexibility of power communication protocols.

[0121] It should be understood that, provided there are no logical conflicts, the above-described embodiments can be combined and implemented to adapt to actual application needs. These combined embodiments or implementation schemes are still within the scope of protection of this application.

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

[0123] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0124] Based on the same inventive concept, embodiments of this application also provide an electronic device.

[0125] Figure 7 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 70 of this embodiment includes: at least one processor 710 ( Figure 7 The processor 710 contains only one of the following components: a memory 720, a communication module 730, and a computer program 740 that may run on the processor 710. When the processor 710 executes the computer program 740, it implements the steps described in the above-described power protocol development system embodiment. The communication module 730 may be a separate communication unit used to communicate with an external server or terminal device.

[0126] Electronic device 70 may include, but is not limited to, a processor 710 and a memory 720. Those skilled in the art will understand that... Figure 7 This is merely an example of electronic device 70 and does not constitute a limitation on electronic device 70. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 70 may also include input transmitting devices, network access devices, buses, etc.

[0127] The processor 710 can be a Central Processing Unit (CPU), or 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.

[0128] In some embodiments, memory 720 may be an internal storage unit of electronic device 70, such as a hard disk or memory of electronic device 70. Memory 720 may also be an external storage device of electronic device 70, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., provided on electronic device 70. Memory 720 may include both internal and external storage units of electronic device 70. Memory 720 is used to store operating system, applications, bootloader, data, and other programs, such as the program code of computer program 740. Memory 720 may also be used to temporarily store data that has been sent or will be sent.

[0129] Furthermore, 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. In the various embodiments of this application, each functional unit 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.

[0130] This application provides a computer-readable storage medium storing a computer program that, when run on an electronic device, causes the electronic device to perform the steps described in the various method embodiments above.

[0131] This application provides a chip, which includes a processor and a memory. The memory stores a computer program, which, when executed by the processor, implements the steps in the various method embodiments described above.

[0132] This application provides a computer program product that, when run on an electronic device, causes the electronic device to execute the steps described in the various method embodiments above.

[0133] It should be understood that the processor mentioned in the embodiments of this application can be a Central Processing Unit (CPU), or 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. A general-purpose processor can be a microprocessor or any conventional processor.

[0134] It should also be understood that the memory mentioned in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

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

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

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

[0138] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units 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 an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

[0139] The units described 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.

[0140] Furthermore, the functional units in the various embodiments of this application 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.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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 of this application 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 large-screen device, 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. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0142] Finally, it should be noted that the above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A power protocol development system, characterized in that, The system includes: The core engine module for reduction processing provides a basic functional framework for reduction processing, which defines multiple reduction processing scheduling interfaces. A dynamic loading library storage module is used to store multiple dynamic loading libraries, each of which contains one or more specification function modules; The specification configuration generation module is used to generate a specification configuration file, which records the combination information of the dynamically loaded library corresponding to the target communication specification. The protocol operation management module is connected to the protocol processing core engine module, the dynamic loading library storage module, and the protocol configuration generation module, respectively. It is used to read the corresponding protocol configuration file when the target communication protocol is started, load the corresponding dynamic loading library from the dynamic loading library storage module according to the combination information, and load the protocol function modules in each dynamic loading library onto the corresponding scheduling interface in the protocol processing core engine module.

2. The power protocol development system according to claim 1, characterized in that, The protocol operation management module loads the protocol function modules from each dynamically loaded library onto the corresponding scheduling interface in the protocol processing core engine module, including: The corresponding dynamic loading library is loaded into the process address space of the specification processing core engine module, and the function exported from the dynamic loading library is associated with the scheduling interface by means of symbol lookup or function pointer binding.

3. The power protocol development system according to claim 1, characterized in that, The reduction processing core engine module defines multiple reduction processing scheduling interfaces, including: The interface includes: message receiving and framing scheduling interface, message parsing and classification scheduling interface, data sending and framing scheduling interface, data uploading and processing scheduling interface, subsequent data uploading scheduling interface, operation and mutual exclusion control scheduling interface, processing priority management scheduling interface, and timeout control scheduling interface.

4. The power protocol development system according to claim 1, characterized in that, In the dynamically loaded library, the specification function module includes: The protocol specification module is used to implement message format processing for a single communication protocol; A specification service function module is used to implement one or more specification application service functions. The specification module uniquely corresponds to a communication protocol and is used to implement the link layer message framing verification, application layer message parsing and classification, and message framing and encapsulation functions of the communication protocol. The protocol service function module consists of multiple modules, each corresponding to a different type of message service of the communication protocol, used to implement application service functions including data uploading and processing, subsequent data uploading, operation control, and mutual exclusion processing.

5. The power protocol development system according to claim 1, characterized in that, When the specification configuration generation module generates the specification configuration file, it records in the specification configuration file the path identifier of the dynamically loaded library, the type identifier of each dynamically loaded library, the calling relationship between each dynamically loaded library, the corresponding mapping relationship between the specification service function module and the specification message type, the timing coordination relationship between multiple specification service function modules, and the connection relationship between the data uploading trigger condition of each specification service function module and the subsequent data uploading target; the type identifier is used to distinguish whether the dynamically loaded library belongs to the specification normative function module or the specification service function module.

6. The power protocol development system according to claim 1, characterized in that, After reading the specification configuration file and before loading the dynamic library, the specification operation management module also performs a configuration verification step, including: The existence of dynamically loaded library files referenced in the specification configuration file is verified, the consistency of interface signatures between each scheduling interface and the loaded functional modules is verified, and the uniqueness of the mapping relationship between specification message types and service functional modules is verified.

7. The power protocol development system according to claim 1, characterized in that, The configuration file generated by the protocol configuration generation module can be modified or newly created to redetermine the combination information of the dynamic loading library corresponding to the target communication protocol, so as to adapt to the application differences of different manufacturers of the same communication protocol or the protocol function expansion requirements; the protocol processing core engine module remains unchanged during the adaptation process.

8. The power protocol development system according to any one of claims 1 to 7, characterized in that, The protocol processing core engine module also encapsulates a protocol registration interface, a protocol initialization interface, a protocol startup interface, and a protocol stop interface, which are used to uniformly manage the registration, initialization, startup, and stop of the loaded protocol processing function instances. The protocol processing core engine module also includes a running status monitoring unit and an exception handling unit, which are used to monitor the running status of the protocol processing function instances and perform exception handling when an exception occurs.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the processor is used to execute a computer program stored in the memory to perform the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system as described in any one of claims 1-8.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it performs the functions of the protocol processing core engine module, the dynamic loading library storage module, the protocol configuration generation module, and the protocol operation management module in the power protocol development system as described in any one of claims 1-8.

Images