A method and system for generating a power distribution terminal configuration file, and a medium

Abstract

This application provides a method, system, and medium for generating configuration files for power distribution terminals, relating to the field of power distribution automation technology. The method includes: constructing a unified configuration structure description file based on the device type of the power distribution terminal and the protection functions to be executed; automatically generating a configuration template file to form a first intermediate format configuration file; performing correlation verification on external input values ​​according to logical association constraints, and filling the external input values ​​into the first intermediate format configuration file; inputting the second intermediate format configuration file into a compiler, and compiling it into a binary format configuration file after successful verification; and distributing it to the power distribution terminal as a whole in the form of data blocks. This application solves the technical problems of low parsing efficiency, large memory consumption, and poor cross-platform compatibility in existing technologies due to reliance on manual intervention and lack of logical and syntax verification during the configuration process, thereby improving the correctness, consistency, and overall operation and maintenance efficiency of power distribution terminal configuration.

Description

Technical Field

[0001] This application relates to the field of power distribution automation technology, specifically to a method, system, and medium for generating power distribution terminal configuration files. Background Technology

[0002] With the continuous advancement of smart grid construction, the number of distribution automation terminals has increased dramatically. The management and generation of their configuration files have become critical factors affecting system deployment efficiency and operational reliability. Currently, distribution terminal configuration generally relies on manual item-by-item verification and manual data entry, which is not only inefficient but also highly susceptible to human error. Existing configuration tools can only perform basic syntax checks and lack constraints and verification mechanisms for the inherent logical relationships between configuration parameters. This results in many logical errors only being exposed during equipment commissioning or load testing. Once protection fails to operate or cascades malfunction, it directly threatens the safe and stable operation of the power grid. Furthermore, each vendor uses proprietary configuration formats, requiring the master station system to maintain multiple heterogeneous templates, further increasing the complexity of system integration and maintenance. In terms of practical application of configuration data, existing solutions often use text formats such as JSON or XML for configuration description and transmission. Upon receiving the data, terminal devices must perform complete text parsing, string matching, and memory allocation operations, which can cause significant CPU overhead and memory fragmentation for resource-constrained embedded terminals. Text-based configuration files lack version self-description capabilities. When terminal firmware upgrades cause changes to the configuration structure, older configuration files often become unusable, requiring manual adjustments based on firmware change notes, resulting in extremely chaotic version management. Furthermore, plaintext configurations such as JSON lack effective integrity protection and source authentication mechanisms during transmission and storage, posing a security risk of unauthorized tampering.

[0003] In summary, existing technologies suffer from low parsing efficiency, high memory consumption, and poor cross-platform compatibility due to reliance on manual intervention during configuration and a lack of logic and syntax validation, which further impacts operational efficiency. Summary of the Invention

[0004] The purpose of this application is to provide a method, system, and medium for generating configuration files for power distribution terminals, in order to solve the technical problems in the prior art that result in low parsing efficiency, large memory consumption, and poor cross-platform compatibility due to reliance on manual intervention and lack of logic and syntax verification during the configuration process, which further affects the efficiency of operation and maintenance.

[0005] To achieve the above objectives, this application provides a method, system, and medium for generating power distribution terminal configuration files.

[0006] Firstly, this application provides a method for generating a power distribution terminal configuration file. This method is implemented through a power distribution terminal configuration file generation system. The method includes: constructing a unified configuration structure description file using a general description language independent of specific communication protocols and hardware platforms, based on the device type and protection functions to be executed of the power distribution terminal; automatically generating an intermediate format configuration template file according to the configuration structure description file, and forming a first intermediate format configuration file based on the hierarchical framework and preset default values ​​of each configuration parameter in the configuration parameter set contained in the configuration template file; obtaining external input values, performing association verification on the external input values ​​according to the logical association constraints in the configuration template file, filling the verified configuration parameter values ​​from the external input values ​​into the first intermediate format configuration file, and generating a second intermediate format configuration file; inputting the second intermediate format configuration file into a compiler, which performs verification on the second intermediate format configuration file according to the configuration structure description file, and after all verifications pass, compiling the second intermediate format configuration file into a binary format configuration file; and distributing the binary format configuration file as a whole to the power distribution terminal in the form of data blocks.

[0007] Optionally, the configuration structure description file defines a set of configuration parameters according to a hierarchical relationship. The set of configuration parameters includes device identity parameters, network communication parameters, protection setting parameters, and function enable / disable parameters, and limits the data type and value range of each configuration parameter.

[0008] Optionally, according to the data type definition of each configuration parameter in the configuration structure description file, each configuration parameter is arranged and stored sequentially with a fixed byte width, and the parameter name tag, hierarchical structure tag and separator mark in the second intermediate format configuration file are removed; at the same time, the original value of each configuration parameter is directly written into the corresponding storage location in binary numerical form, so that the data structure of the binary format configuration file is consistent with the configuration parameter storage structure of the power distribution terminal at the byte level.

[0009] Optionally, integrity verification information is written into the header of the binary format configuration file; the power distribution terminal verifies the integrity and source legitimacy of the configuration file based on the integrity verification information, and directly maps the binary format configuration file to the memory space through memory mapping after the verification is passed; the running program of the power distribution terminal directly reads the configuration parameter values ​​from the memory space and applies them to the corresponding protection functions.

[0010] Optionally, the integrity verification information includes at least a cyclic redundancy check (CR) value and digital signature information. The power distribution terminal verifies the integrity and source legitimacy of the configuration file based on the integrity verification information, including: calculating the CR value of the received binary format configuration file and comparing it with the CR value in the integrity verification information to obtain a first comparison result; if the comparison matches according to the first comparison result, verifying the digital signature information based on a preset public key; if the verification passes, confirming the source legitimacy of the binary format configuration file.

[0011] Optionally, version identification information is written to the header of the binary format configuration file; when the power distribution terminal loads the configuration file, it compares its own firmware version information with the version identification information to obtain a comparison result; according to the comparison result, if the versions are consistent, all configuration parameters are applied completely; according to the comparison result, if the versions are inconsistent, the power distribution terminal identifies the parameter structure differences between the old and new versions according to the built-in version adaptation rules, extracts a subset of configuration parameters compatible with the current firmware version from the binary format configuration file according to the parameter structure differences and applies them, while replacing incompatible parameter items with default safe values.

[0012] Optionally, after the power distribution terminal completes the application of configuration parameters, it extracts all currently effective configuration parameters from the running memory and reorganizes them according to an intermediate format to generate a readback configuration file in an intermediate format; the readback configuration file is compared item by item with the second intermediate format configuration file; if all configuration parameters are consistent, the configuration is confirmed to be successful; if there are differences, a difference report is generated and a reconfiguration process is triggered.

[0013] Optionally, a set of power distribution terminals is constructed; the set of power distribution terminals is clustered according to the constraints of equipment type and protection function requirements to obtain a power distribution terminal cluster; a predetermined binary format configuration file of the power distribution terminal cluster is obtained, and the predetermined binary format configuration file is used as a shared configuration file; the shared configuration file is encapsulated according to the communication address of each power distribution terminal in the power distribution terminal cluster to reduce the amount of data redundancy when sending data in batches.

[0014] Secondly, this application also provides a power distribution terminal configuration file generation system for executing a power distribution terminal configuration file generation method as described in the first aspect. The power distribution terminal configuration file generation system includes: a structure description file configuration module, used to construct a unified configuration structure description file based on the device type of the power distribution terminal and the protection functions to be executed, using a general description language independent of specific communication protocols and hardware platforms; and a first configuration module, used to automatically generate an intermediate format configuration template file according to the configuration structure description file, and to form a first intermediate format configuration file according to the hierarchical framework of each configuration parameter in the configuration parameter set contained in the configuration template file and preset default values. The second configuration module is used to acquire external input values, perform association verification on the external input values ​​according to the logical association constraints in the configuration template file, fill the configuration parameter values ​​that pass the verification in the external input values ​​into the first intermediate format configuration file, and generate a second intermediate format configuration file; the file verification module is used to input the second intermediate format configuration file into the compiler, the compiler performs verification on the second intermediate format configuration file according to the configuration structure description file, and after all verifications pass, compiles the second intermediate format configuration file into a binary format configuration file; the data delivery module is used to deliver the binary format configuration file to the power distribution terminal in the form of data blocks.

[0015] Thirdly, a computer-readable storage medium storing a computer program that, when executed, implements the steps of the method for generating a power distribution terminal configuration file as described in any one of the first aspects above.

[0016] One or more technical solutions provided in this application have at least the following technical effects or advantages: A unified configuration structure description file is constructed using a general description language independent of specific communication protocols and hardware platforms, based on the device type and protection functions to be executed in the power distribution terminal. An intermediate format configuration template file is automatically generated based on the configuration structure description file, and a first intermediate format configuration file is formed based on the hierarchical framework and preset default values ​​of each configuration parameter in the configuration parameter set contained in the configuration template file. External input values ​​are obtained, and the external input values ​​are validated according to the logical association constraints in the configuration template file. Validated configuration parameter values ​​from the external input values ​​are filled into the first intermediate format configuration file to generate a second intermediate format configuration file. The second intermediate format configuration file is input into a compiler, which performs validation on the second intermediate format configuration file according to the configuration structure description file. After all validations pass, the second intermediate format configuration file is compiled into a binary format configuration file. The binary format configuration file is then distributed to the power distribution terminal as a whole in the form of data blocks. In other words, by using a general description language independent of communication protocols and hardware platforms to structurally model equipment types and protection functions, establishing logical association constraints between parameters and performing pre-consensus verification on external inputs, and then having the compiler perform secondary syntax and data type verification based on the structure description file, the configuration data that has passed the double verification is finally compiled into binary data blocks and distributed to the power distribution terminal as a whole in the form of data blocks. This intercepts configuration errors at the offline host computer stage, eliminates protection risks caused by parameter logic mismatch, simplifies the on-site debugging process, shortens the project deployment cycle, and significantly improves the correctness, consistency and overall operation and maintenance efficiency of the power distribution terminal configuration.

[0017] The above description is merely an overview of the technical solution of this application. To better understand the technical means of this application and to facilitate its implementation according to the description, and to make the above and other objects, features, and advantages of this application more apparent, specific embodiments of this application are described below. It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent through the following description. Attached Figure Description

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

[0019] Figure 1 This is a flowchart illustrating a method for generating a power distribution terminal configuration file according to this application.

[0020] Figure 2 This is a flowchart illustrating the process of compiling a binary format configuration file in a method for generating a power distribution terminal configuration file according to this application.

[0021] Figure 3 This is a schematic diagram of the structure of a power distribution terminal configuration file generation system according to this application.

[0022] Explanation of reference numerals in the attached diagram: Structure description file configuration module 11, first configuration module 12, second configuration module 13, file verification module 14, data distribution module 15. Detailed Implementation

[0023] This application provides a method, system, and medium for generating configuration files for power distribution terminals. It addresses the technical problems in existing technologies where low parsing efficiency, high memory consumption, and poor cross-platform compatibility, all stemming from reliance on manual intervention and a lack of logical and syntactic validation during configuration, ultimately impacting operational efficiency. By employing a general description language independent of communication protocols and hardware platforms to structurally model device types and protection functions, establishing logical relationship constraints between parameters, and performing pre-processing validation on external inputs, the compiler performs secondary syntactic and data type validation based on the structure description file. Finally, the double-validated configuration data is compiled into binary data blocks and distributed to the power distribution terminal as a whole. This intercepts configuration errors at the offline host computer stage, eliminating protection risks caused by parameter logic mismatches. Simultaneously, it simplifies on-site debugging processes, shortens project deployment cycles, and significantly improves the correctness, consistency, and overall operational efficiency of power distribution terminal configuration.

[0024] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. It should be understood that this application is not limited to the exemplary embodiments described herein. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application. It should also be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all of them.

[0025] Example 1, please refer to the appendix. Figure 1 This application provides a method for generating a power distribution terminal configuration file. The method is applied to a power distribution terminal configuration file generation system and specifically includes the following steps: Based on the equipment type of the power distribution terminal and the protection functions to be performed, a unified configuration structure description file is constructed using a general description language that is independent of specific communication protocols and hardware platforms.

[0026] Furthermore, this application also includes the following steps: the configuration structure description file defines a set of configuration parameters according to a hierarchical relationship, the set of configuration parameters includes device identity parameters, network communication parameters, protection setting parameters, and function enable / disable parameters, and limits the data type and value range of each configuration parameter.

[0027] Specifically, based on the actual needs of the distribution network automation project, the specific equipment type of the distribution terminal to be configured is determined, and a list of all protection functions that the terminal needs to perform during field operation is specified. The equipment type is attribute information used to uniquely identify the product model or functional category of the distribution terminal, determining the number of telemetry / telecommunication / remote control points supported by the terminal, the list of configurable protection functions, the communication interface type, and hardware storage capacity. The protection functions to be performed are one or more types of relay protection logic functions that the distribution terminal is required to operate in specific engineering applications, including but not limited to three-stage overcurrent protection, overvoltage protection, undervoltage protection, zero-sequence overcurrent protection, reclosing protection, directional overcurrent protection, and overload protection. The combination of protection functions required varies in different engineering scenarios; for example, pure cable lines may not require reclosing functionality, while overhead lines must be equipped with reclosing.

[0028] Based on the hardware specifications and dispatching operation procedures of the power distribution terminal, a summary of all configuration parameters that this type of terminal needs to support is compiled, including device identity parameters, network communication parameters, protection setting parameters, and function enabling / disabling parameters.

[0029] The configuration structure description file is written using a general description language. During the writing process, the file declares the device type names to which the configuration file applies and the protected functional domains it covers. The parameter structure is defined hierarchically from top to leaf nodes: the top-level container node represents the overall terminal configuration; second-level container nodes are created below it; third-level container nodes are further created; and specific leaf parameter nodes are defined under each third-level container node.

[0030] When defining each leaf parameter, the data type is explicitly specified using the type system of the description language. For example, `type uint16` specifies the terminal ID as a 16-bit unsigned integer, `type float32` specifies the setpoint as a single-precision floating-point number, and `type boolean` specifies the enable state as a boolean type. Simultaneously, the range constraint statements provided by the description language specify the legal value range for numeric parameters, such as specifying a range of 0.5 to 5000A for the overcurrent setpoint, with a step size of 0.01A; enumerated values ​​are specified for function enable / disable parameters through enumeration type definitions. After completing all parameter definitions, the designer performs a syntax check on the configuration structure description file, and after confirming there are no formatting errors, stores it in the system-specified directory.

[0031] An intermediate format configuration template file is automatically generated based on the configuration structure description file, and a first intermediate format configuration file is formed based on the hierarchical framework of each configuration parameter in the configuration parameter set contained in the configuration template file and the preset default values.

[0032] Specifically, the built-in parser is invoked to perform lexical and syntactic analysis on the configuration structure description file, extracting all the information defined therein, including the names of all configuration parameters, the parent-child hierarchical relationship between parameters, the data type definition of each parameter, the value range constraints such as the minimum / maximum / enumerated value list of each parameter, and the preset default value of each parameter.

[0033] After parsing, a parameter tree is constructed in memory, with the root node representing the entire configuration of the terminal. Under the root node, child nodes and leaf nodes expand level by level according to the hierarchical relationship defined in the configuration structure description file. Once the parameter tree is constructed, it is traversed in a depth-first manner, visiting each leaf parameter node in turn. For the currently visited leaf parameter, it is checked whether a preset default value is defined in the configuration structure description file. If it exists, the preset default value is used as the current valid value of the parameter and filled into the corresponding value field of the parameter tree. If it does not exist, meaning the parameter does not have a default value defined in the structure description file, a type-safe null value is assigned according to the parameter's data type: 0 for numeric types (such as uint16, float32, etc.), false for boolean types, an empty string for string types, and the first enumeration value in the enumeration list for enumeration types.

[0034] Perform the above assignment operation on all leaf nodes until every leaf node in the entire parameter tree has been assigned a definite initial value. After the assignment is complete, serialize the parameter tree in memory into a human-readable structured text format, such as JSON or XML. During serialization, maintain the parent-child indentation relationship between parameters to make the hierarchical framework clearly distinguishable in the text; at the same time, automatically attach comments next to each parameter node, including the data type, value range, unit of measurement, and Chinese function description, to facilitate understanding of the meaning and filling requirements of each parameter. After serialization is complete, output the generated text file and save it to the specified storage directory; this file is the first intermediate format configuration file.

[0035] The intermediate format configuration template file is a semi-finished configuration file automatically generated from the configuration structure description file. It has a complete parameter hierarchy skeleton, and each leaf parameter has been assigned a preset default value, but the actual operating values ​​for the specific project site have not yet been filled in. The hierarchical framework is a tree-like skeleton organized according to the parent-child relationship of all parameters defined in the configuration structure description file. The preset default value is an initial value automatically assigned to each configuration parameter when the template file is generated. The first intermediate format configuration file is a complete configuration file formed by filling all leaf parameters with preset default values ​​based on the hierarchical skeleton of the configuration structure description file. It has all the parameter structures for configuration, and each parameter has a definite initial value. It represents a general template rather than a personalized finished product. The format of the first intermediate format configuration file is the same as the configuration template file, the difference being that it has completed the filling of default values ​​and is no longer an empty skeleton.

[0036] Obtain external input values, perform association verification on the external input values ​​according to the logical association constraints in the configuration template file, fill the configuration parameter values ​​that pass the verification in the external input values ​​into the first intermediate format configuration file, and generate the second intermediate format configuration file.

[0037] Specifically, maintenance personnel input the required configuration values ​​for the power distribution terminal at the actual engineering site through a visual configuration interface. Input can be done by entering parameters one by one or by submitting a complete set of parameters at once. Each received parameter input value undergoes basic independent parameter validation, including two steps: data type validation, checking whether the data type of the input value matches the type defined in the configuration structure description file (e.g., overcurrent settings must be floating-point numbers, and IP addresses must conform to dotted decimal string format); and value range validation, checking whether the input value is between its own independently defined minimum and maximum values ​​(e.g., overcurrent stage I settings must be between 0.5A and 5000A). After passing the basic validation, the parameter value is temporarily stored in a buffer, but it has not yet been written to the configuration file.

[0038] After the maintenance personnel complete the input of all parameters, the core process of logical association verification is initiated. All parameter values ​​that have passed independent verification are treated as a whole set, and each value is substituted into each logical association constraint rule extracted from the configuration structure description file for judgment. If the value range of one protection setting parameter depends on the value state of another configuration parameter, the following judgment logic is executed: When the value of parameter A changes, the value range limit of parameter B is dynamically adjusted, and it is checked whether the actual input value of B falls within this dynamic range. For example, after reading the overcurrent stage I setting value as 5.2A, the minimum value of the overcurrent stage II setting is dynamically set to 5.2 + 0.25 = 5.45A (a quadratic value). Then, it is checked whether the overcurrent stage II setting value of 6.8A input by the maintenance personnel is greater than or equal to 5.45A. If so, it passes; otherwise, an error is reported. When the enable status of a function's enable / disable parameter determines whether a set of associated protection setting parameters participate in configuration generation, the following judgment logic is executed: When the enable parameter of a certain protection function is detected to be false, the verification flag of all setting parameters associated with that function is automatically set to skip, meaning that no matter what value is entered for these setting parameters, no error will be triggered regarding the value range; when the enable parameter is true (enabled), it is mandatory that all its associated setting parameters have been entered with valid values ​​and have all passed their respective value range verifications. At the same time, it is also necessary to additionally check whether there are other preconditions that meet the functional linkage requirements, such as at least one overcurrent protection being enabled when reclosing is enabled.

[0039] Logical association constraints are the logical dependencies and linkage rules between different configuration parameters predefined in the configuration structure description file. They go beyond checking the independent value range of individual parameters, focusing instead on whether the parameter combination is logically reasonable and self-consistent within the electrical protection logic. For example, the settings of each stage of overcurrent protection must satisfy a hierarchical coordination relationship; the setting of stage II must be greater than the setting of stage I, and its delay time must be greater than the delay time of stage I. Alternatively, the activation of the reclosing function must depend on at least one overcurrent protection being activated. The process involves treating all external values ​​input by maintenance personnel as a whole and substituting them into each predefined logical association constraint rule in the configuration structure description file for automated judgment. Association verification differs fundamentally from conventional independent parameter verification: the latter is point verification, while the former is surface verification, checking whether the combination relationship between parameters meets the preset logical rules. If all logical association constraints are satisfied, the entire set of input values ​​passes the verification; if any rule is violated, the current input parameter set is refused to be written to the configuration file, and a clear error message is returned to the maintenance personnel to guide their correction.

[0040] If all logical constraints are satisfied, the current input value is considered to have passed the validation. Then, all valid parameter values ​​are sequentially filled into the corresponding parameter positions in the first intermediate format configuration file, replacing the original default values. If any logical constraint is violated, the write operation is immediately terminated without modifying any content in the first intermediate format configuration file. Simultaneously, a detailed error report is returned to the operations and maintenance personnel, clearly indicating which constraint rule was violated, the names of the parameters involved, and the specific deviation between the current input value and the constraint conditions, guiding the operations and maintenance personnel to make targeted corrections and resubmit. After all validations pass and the value replacement is completed, the updated file is saved with a new filename; this file becomes the second intermediate format configuration file.

[0041] The second intermediate format configuration file is input into the compiler, which performs verification on the second intermediate format configuration file according to the configuration structure description file. After all verifications pass, the second intermediate format configuration file is compiled into a binary format configuration file.

[0042] Further details are attached. Figure 2 As shown, this application also includes the following steps: according to the data type definition of each configuration parameter in the configuration structure description file, each configuration parameter is arranged and stored sequentially with a fixed byte width, and the parameter name tag, hierarchical structure tag and separator mark in the second intermediate format configuration file are removed; at the same time, the original value of each configuration parameter is directly written into the corresponding storage location in binary numerical form, so that the data structure of the binary format configuration file is consistent with the configuration parameter storage structure of the power distribution terminal at the byte level.

[0043] Specifically, the compiler program is invoked. The compiler is a configuration compilation tool, similar in function to a regular programming language compiler, but it focuses on the configuration data domain rather than executable code. Taking the configuration structure description file and the second intermediate format configuration file as input, two core operations are performed: first, verification, which checks the data type matching and value range boundaries of each parameter in the second intermediate format configuration file; second, conversion, which reconstructs the text-formatted configuration data into a compact binary data stream, ensuring that the data structure maintains byte-level alignment with the terminal hardware storage layout.

[0044] The configuration structure description file and the second intermediate format configuration file are passed to the compiler as input parameters. After the compiler starts, it first loads the configuration structure description file and extracts all the information defined in it through the parser, including a complete list of all parameters and their definition order, the data type of each parameter, and the value range constraints of each parameter. Based on the extracted parameter list and order, a parameter metadata table is built in memory. Each row of this table records the metadata information of a parameter, including the parameter name, definition order number, data type, byte width, lower limit of value range, and upper limit of value range.

[0045] The compiler loads the second intermediate format configuration file and begins the validation process. Following the order in the parameter metadata table, it iterates through each parameter one by one, performing two validations on each parameter. It extracts the actual value of the current parameter from the second intermediate format configuration file and checks whether the format of this value matches the front-end data format declared in the parameter metadata table. For example, since the second intermediate format configuration file is a JSON text file, the compiler calls the JSON parser to read the values ​​of each field and uses the type identification results already completed by the JSON parser. The JSON parser can distinguish basic types such as numbers, strings, and booleans, and compares this identification result with the declared type in the metadata table. If the formats match, the process continues; if they do not match, such as a parameter declared as float32 in the metadata table but its actual value in the JSON is a quoted string, or declared as uint16 but its actual value is a floating-point number, the compiler immediately reports an error and terminates the compilation process, returning specific error information.

[0046] After data type validation passes, the compiler further checks whether the actual value of the current parameter falls within the legal range declared in the metadata table. For numeric parameters, the compiler compares the actual value with the preset minimum and maximum values ​​to check if the minimum value ≤ numeric parameter ≤ maximum value. For boolean parameters, it checks whether the actual value is either true or false, and there is no out-of-bounds issue because boolean types only have two legal values. For enumeration parameters, it checks whether the actual value belongs to the predefined enumeration value list. If all parameters pass the value range boundary validation, the compiler outputs a message indicating that all validations passed and continues to the subsequent compilation and conversion stages; if any parameter goes out of bounds, the compiler reports an error and terminates.

[0047] After all verifications pass, the compiler enters the compilation and conversion phase. Based on the data type field of each parameter in the parameter metadata table, the compiler calculates the fixed byte width for each parameter: boolean and uint8 occupy 1 byte, uint16 occupies 2 bytes, uint32, int32, and float32 occupy 4 bytes, and so on. Following the parameter definition order, i.e., the row order of the parameter metadata table, the compiler determines the offset address of each parameter in the output binary file, starting from the first parameter: the starting offset address of the first parameter is 0, and the starting offset address of each subsequent parameter is equal to the starting offset address of the previous parameter plus the byte width of the previous parameter. After all parameter offset addresses are determined, the compiler creates an empty output buffer.

[0048] The compiler extracts the actual value of each parameter one by one from the second intermediate format configuration file. For each parameter, the compiler performs the corresponding binary encoding conversion according to its data type: for float32 type, the floating-point number is converted into a 4-byte binary sequence according to the IEEE 754 single-precision standard; for uint16 and uint32 types, the unsigned integer is converted into the corresponding binary sequence; for boolean type, true is converted to 0x01 and false is converted to 0x00; for enumeration type, its corresponding enumeration index value is converted into a binary sequence. After encoding, the compiler writes these binary values ​​sequentially to the corresponding positions in the output buffer according to the calculated offset addresses, without leaving any gaps or separators between the values.

[0049] When extracting parameter values ​​from the second intermediate format configuration file, only the raw values ​​at each leaf node are extracted, completely ignoring and not outputting any parameter name tags, hierarchy tags, and delimiter markers from the configuration file. The output buffer contains only sequentially arranged binary numerical data and does not contain any character information used to identify parameter names or structures.

[0050] After all parameters have been processed, the compiler treats the contents of the output buffer as a complete binary data block and writes it to a binary configuration file with the .bin extension. The internal data structure corresponds perfectly to the parameter definition order, data type, and byte width in the configuration structure description file, and maintains byte-level alignment with the default configuration parameter storage structure within the power distribution terminal firmware. The compiler also writes auxiliary information, including the file version identifier, CRC32 integrity check value, and digital signature information, into the final output.

[0051] The offset addresses, storage order, and byte width of each parameter in the binary configuration file generated by the compiler are completely consistent with the memory layout used by the power distribution terminal firmware to access configuration parameters. During compilation, the terminal firmware pre-plans the layout structure of the configuration parameter storage area in memory according to the exact same parameter definition order and data type as the configuration structure description file, and hard-codes the access offset for each parameter. When the terminal loads the binary configuration file via memory mapping, the data arrangement in the file corresponds one-to-one with the arrangement expected by the terminal firmware. The content at file offset 0 is read by the terminal firmware as the first parameter, the content at file offsets 1-4 is read as the second parameter, and so on. This byte-level alignment consistency means that when loading the configuration file, the terminal does not need to perform any data parsing, field extraction, type conversion, or memory reorganization operations. It can directly copy the file content to a specified area of ​​memory, or directly read each parameter value using a base address pointer plus an offset, thereby maximizing loading efficiency.

[0052] The binary format configuration file is sent to the power distribution terminal as a whole in the form of data blocks.

[0053] Furthermore, this application also includes the following steps: writing integrity verification information into the header of the binary format configuration file; the power distribution terminal verifying the integrity and source legitimacy of the configuration file based on the integrity verification information, and directly mapping the binary format configuration file to the memory space through memory mapping after the verification is passed; the running program of the power distribution terminal directly reads the configuration parameter values ​​from the memory space and applies them to the corresponding protection functions.

[0054] Furthermore, this application also includes the following steps: the integrity verification information includes at least a cyclic redundancy check value and digital signature information; the power distribution terminal verifies the integrity and source legitimacy of the configuration file based on the integrity verification information, including: calculating the cyclic redundancy check value of the received binary format configuration file and comparing it with the cyclic redundancy check value in the integrity verification information to obtain a first comparison result; according to the first comparison result, if the comparison is consistent, verifying the digital signature information based on a preset public key; if the verification is successful, confirming the source legitimacy of the binary format configuration file.

[0055] Specifically, on the master site, after the compiler generates the binary format configuration file, it first performs a CRC32 checksum calculation on the binary data block (excluding the header information) to obtain a 4-byte cyclic redundancy check value. The master site system then uses its private key to perform a digital signature operation on the overall hash value of the binary data block, generating a digital signature data. The master site system organizes the file version identifier, CRC32 checksum, and digital signature information according to a predetermined header format and writes them into the very beginning of the binary configuration file, forming a complete file ready for distribution.

[0056] Integrity verification information is a set of auxiliary data appended to the header (or footer) of a binary format configuration file to verify data integrity and source legitimacy. Its purpose is to ensure that the distribution terminal can confirm, before loading the configuration file, that the file has not been damaged or tampered with during transmission and storage, and that it indeed originates from a legitimate distribution network master station system. Integrity verification information includes at least a Cyclic Redundancy Check (CRC) value and digital signature information, corresponding to the two dimensions of integrity verification and source legitimacy verification, respectively. The Cyclic Redundancy Check (CRC) value is a hash verification algorithm based on the principle of polynomial division, used to detect whether bit errors or data loss have occurred during the transmission or storage of data blocks. After generating the binary configuration file, the master station system calculates a fixed-length CRC check value for the entire binary data block (excluding the header verification information itself), typically CRC32, outputting a 32-bit (4-byte) verification result, and writes it to the file header. Upon receiving the file, the distribution terminal independently recalculates the CRC value for the data block and compares it with the CRC value stored in the header. If they match, the data is intact; if they do not match, the data has been damaged during transmission, and the distribution terminal should discard the file and request a retransmission. CRC checksums are characterized by high detection rate, fast computation speed, and simple implementation, making them suitable for resource-constrained embedded terminals. Digital signature information is a data source authentication mechanism based on asymmetric cryptography. The master station system uses its private key to encrypt a binary configuration file, generating a digital signature and writing it to the file header. Digital signatures are unique and unforgeable; only a legitimate master station holding the corresponding private key can generate a valid signature. The signature is verified using a pre-set legitimate master station public key. If the verification passes, it proves that the configuration file indeed originated from a legitimate network distribution master station system and has not been tampered with by a third party during transmission. The difference between digital signatures and CRC checksums is that CRC can only detect whether data has been accidentally corrupted, such as bit flips caused by channel noise, while digital signatures can detect whether data has been maliciously tampered with, such as an attacker intentionally modifying fixed parameters, and can also authenticate the issuer's identity. The combination of the two forms a dual security protection system against accidental damage and malicious tampering.

[0057] The master station system distributes the complete binary configuration file as data blocks to the target distribution terminal via the distribution network communication network. The distribution terminal receives the data frames through the communication interface, reassembles the frames locally, and stores the complete binary configuration file in the file cache area of ​​the distribution terminal's non-volatile memory.

[0058] The CRC32 checksum and digital signature information are extracted from the header of the configuration file. Then, the CRC32 value is independently calculated for the data portion of the configuration file, i.e., the valid configuration data area after the header. The calculated result is compared with the CRC32 value extracted from the header. If they do not match, it indicates that a bit error or data loss occurred during transmission or storage. The distribution terminal discards the configuration file, returns a configuration verification failure response, and requests the master station to retransmit. If the CRC comparison matches, it proves that the physical integrity of the data is good, and the distribution terminal proceeds to the next stage of verification.

[0059] The digital signature data stored in the header is read, and the signature is decrypted using the master station public key pre-installed in the terminal's secure storage area, resulting in a decrypted digest value. Simultaneously, the distribution terminal independently performs a SHA-256 hash calculation on the data portion of the configuration file, obtaining a local digest value. The distribution terminal compares the decrypted digest with the local digest. If they match, the signature verification passes, proving that the file indeed originates from the distribution network master station system holding the legitimate private key and that the file content has not been tampered with by a third party during transmission. If they do not match, the distribution terminal refuses to load the configuration file, records a security alarm log, and reports the signature verification failure to higher authorities.

[0060] After both CRC verification and digital signature verification pass, the power distribution terminal confirms that the integrity and legality of the configuration file meet the requirements. The power distribution terminal then maps the binary configuration file to a memory address space accessible to the running program via memory mapping. For power distribution terminal systems supporting a memory management unit, the memory mapping interface is called to map N consecutive bytes from the Flash cache starting at a physical address to the virtual address space of the currently running process. After mapping, the operating system returns a virtual address pointer as the starting access address of the mapped region. For bare-metal embedded systems, the running program directly obtains the starting physical address of the file cache as the configuration data base address pointer and directly accesses physical memory. Regardless of the method used, its core characteristic is zero-copy; the configuration data remains stored in its original storage location, and the running program accesses it directly through the base address pointer without performing any data copying operations.

[0061] After memory mapping is established, the power distribution terminal's runtime program obtains a directly accessible configuration data base address pointer, pointing to the starting position of the valid portion of the configuration data in the mapped area, i.e., the starting address of the configuration parameter area after skipping the header integrity check information. The power distribution terminal firmware includes a pre-defined parameter offset table, which records two key pieces of information for each configuration parameter: the number of bytes offset from the configuration data base address pointer, and the byte width corresponding to the parameter's data type. The parameter offset is a constant determined during the development and compilation of the power distribution terminal firmware, perfectly consistent with the parameter arrangement order and byte width used by the compiler when generating the binary file, thus ensuring a precise correspondence between the power distribution terminal's read position and the file storage location.

[0062] The program iterates through each entry in the parameter offset table. For the current entry, it calculates the specific memory address of the parameter by adding the offset byte count recorded in the parameter offset table to the configuration data base address pointer. It then reads a fixed-width sequence of raw binary data from this address and interprets it directly into the corresponding configuration value according to the parameter's data type. For example, for a parameter defined as `float32`, the program reads four consecutive bytes from the calculated address, interprets them as a floating-point number according to the IEEE 754 single-precision floating-point standard, and assigns it to a temporary `float` variable. For a parameter defined as `boolean`, the program reads one byte, interpreting 0x01 as `true` and 0x00 as `false`. For a parameter defined as `uint16`, the program reads two bytes and interprets them as a 16-bit unsigned integer.

[0063] Throughout the entire traversal and reading process, the program relies entirely on fixed offset addresses and fixed byte widths for data extraction. It does not perform any JSON / XML text parsing operations, does not call any string-to-number conversion functions, and does not call any dynamic memory allocation functions. Each read operation is essentially a series of CPU pointer dereference instructions, completed directly at the hardware level, taking only a few CPU clock cycles.

[0064] After the program completes reading all configuration parameters, it writes each parameter value into the corresponding protection algorithm module's runtime variable. The read enable flag value is assigned to the enable switch variable of the corresponding protection module, and the read setpoint and delay time are assigned to the threshold register and timer register of the corresponding protection module. Once all parameter values ​​are written, the distribution terminal reinitializes the state machine of each protection algorithm module, making the new configuration take effect immediately. The distribution terminal then enters normal operation according to the newly loaded configuration parameters, executing corresponding overcurrent protection, zero-sequence protection, reclosing logic, and other protection functions.

[0065] Furthermore, this application also includes the following steps: writing version identification information into the header of the binary format configuration file; when the power distribution terminal loads the configuration file, it compares its own firmware version information with the version identification information to obtain a comparison result; according to the comparison result, if the versions are consistent, all configuration parameters are fully applied; according to the comparison result, if the versions are inconsistent, the power distribution terminal identifies the parameter structure differences between the old and new versions according to the built-in version adaptation rules, extracts a subset of configuration parameters compatible with the current firmware version from the binary format configuration file according to the parameter structure differences and applies it, while replacing incompatible parameter items with default safe values.

[0066] Specifically, while encapsulating integrity verification information, the version number of the configuration structure description file upon which the binary format configuration file is based is written into the file header as a version identifier field. This version number is assigned when the configuration structure description file is created or revised, such as V3.1.2. The first digit is the major version number (indicating major structural changes that are incompatible), the second digit is the minor version number (indicating backward-compatible feature additions), and the third digit is the patch version number (indicating bug fixes with no structural changes). The version identifier, CRC32 checksum, and digital signature information are all written into the header of the binary configuration file to form a complete file to be distributed.

[0067] The complete binary configuration file is sent to the distribution terminal as a whole in the form of data blocks. After receiving the file, the distribution terminal first performs CRC check and digital signature verification to confirm the integrity and legality of the file's source, and then enters the configuration loading and version adaptation stage.

[0068] The power distribution terminal reads the version identifier information from the header of the configuration file and its own firmware version information from the version storage area within the terminal firmware. The terminal performs a structured comparison of the two version numbers, comparing the major version number, minor version number, and patch version number sequentially. If the two version numbers are completely identical (i.e., the major version number, minor version number, and patch version number are all the same), it indicates that the parameter structure definition of the configuration file perfectly matches the expected structure of the current terminal firmware. All parameter data from the binary configuration file are mapped into memory space using memory mapping. The running program reads all parameter values ​​according to a preset offset table and applies them to the protection function module.

[0069] If the two version numbers are inconsistent, the version adaptation process is initiated. The major version numbers are compared. If the major version number of the configuration file is different from the major version number of the terminal firmware, it indicates that a major incompatible change has occurred in the configuration structure, such as a fundamental change in parameter order, data type, or semantics. The configuration file is refused to be loaded, and a version incompatibility error message is returned. A configuration file matching the current firmware version is requested from the main site.

[0070] If the major version number is the same but the minor version number or patch version number is different, it indicates that the change is within the compatibility range, and the fine-grained adaptation process begins. The version difference mapping table built into the firmware program is read, recording the specific changes in parameter structure from the previous compatible version to the current firmware version, including which parameters are new, which are obsolete, and which parameters have changed in byte width or data type. The version identifier of the current configuration file and its own firmware version number are substituted into the mapping table for querying, obtaining a list of specific parameter structure differences between the configuration file version and the firmware version.

[0071] Based on the specific parameter structure difference list, for items marked as new parameters that exist in the current firmware but not in the configuration file, the power distribution terminal does not read the configuration file. Instead, it directly assigns these parameters to preset default safety values ​​and marks them as using the default values. For items marked as obsolete parameters in the difference list that are no longer used in the current firmware, the power distribution terminal skips the data areas corresponding to these parameters when reading the configuration file and does not apply their values ​​to any protection function modules. For parameter items marked as type changes in the difference list, the power distribution terminal reinterprets the original bytes of the corresponding data area according to the new data type expected in the firmware. For example, if the parameter value originally stored as uint16 is interpreted as float32, the corresponding numerical conversion or range mapping needs to be performed.

[0072] After adaptation, the power distribution terminal extracts a subset of valid parameters compatible with the current firmware version from the binary configuration file. These parameter values ​​are accessed and read via memory mapping. Simultaneously, default safety values ​​are assigned to incompatible or missing parameters, ensuring that all configuration parameters required by the current firmware version have valid values. The power distribution terminal applies all parameters to the corresponding protection function modules, enabling the terminal to operate normally according to the principle of using configuration file values ​​as much as possible and supplementing missing parts with default safety values. The default safety value is a conservative initial value automatically assigned by the power distribution terminal to missing parameters when the configuration file lacks some parameters required by the current firmware version (i.e., the firmware version is higher than the configuration file version and the configuration file lacks some newer version parameters). Even if the default safety value is not the optimal engineering setting value, the power distribution terminal will not produce dangerous actions or damage the equipment when operating at this value. For example, for missing protection enable parameters, the default safety value is set to false (exit), ensuring that protection functions that cannot obtain valid settings will not malfunction due to accidental activation; for missing setting parameters, the default safety value is set to a value far below the action threshold or a conservative intermediate value based on engineering experience. The default security value is the last line of defense in the version adaptation process, ensuring that the power distribution terminal can still start or run in a certain and safe state even if the configuration is incomplete.

[0073] Furthermore, this application also includes the following steps: after the power distribution terminal completes the application of configuration parameters, it extracts all currently effective configuration parameters from the running memory and reorganizes them according to the intermediate format to generate a readback configuration file in the intermediate format; the readback configuration file is compared item by item with the second intermediate format configuration file; if all configuration parameters are consistent, the configuration is confirmed to be successful; if there are differences, a difference report is generated and the reconfiguration process is triggered.

[0074] Specifically, after the power distribution terminal completes the application of configuration parameters, it enters the protection operation state according to the new configuration. It iterates through all the operating variables corresponding to the configuration parameters in the current firmware. The terminal firmware has a pre-set complete parameter variable address mapping table, which records the storage address, data type, and byte width information of each configuration parameter in RAM. The power distribution terminal accesses the RAM variable address corresponding to each configuration parameter sequentially according to the order of this mapping table, reads the current value at that address, and temporarily stores it in a temporary readback buffer. The readback operation reads the current value of the protection module's operating variables in RAM, not the original data of the binary file in the Flash cache. This means that the readback value reflects the actual configuration state of the terminal application, including parameters that use default security values ​​due to version adaptation.

[0075] After all parameters have been read, a complete set of currently effective configuration parameter values ​​is obtained. In local memory, each parameter name and its corresponding readback value are written into a JSON object one by one, following the exact same JSON hierarchy as described above. The parameter hierarchy, naming conventions, and order are consistent with the second intermediate format configuration file. After serialization, the distribution terminal generates a complete readback configuration file and temporarily stores it in the terminal's transmit buffer.

[0076] The configuration file is read back and sent to the master station system via the distribution network communication network. The configuration task ID corresponding to the read back operation is carried in the header of the message so that the master station system can associate and match the read back configuration file with the corresponding second intermediate format configuration file.

[0077] After receiving the readback configuration file, the master station system extracts the task ID from the message header and retrieves the second intermediate format configuration file corresponding to the task ID from the local storage, which is the expected configuration file generated before this configuration is issued.

[0078] The comparison program then begins, traversing the complete parameter trees of both configuration files in a depth-first manner, i.e., reading back the configuration file and the second intermediate format configuration file. The comparison program sequentially visits each leaf parameter node, performing the following comparison operations for each node: comparing parameter names to ensure the same parameter is being compared, and then comparing the actual values ​​of the parameters. For boolean parameters, it directly compares whether true / false are the same; for integer parameters, it compares whether the numerical values ​​are exactly the same; for floating-point parameters, considering the slight rounding differences that may occur in floating-point operations under different compilation environments, the comparison program allows equality within a preset tolerance range, such as ±0.001, and considers values ​​outside this tolerance range as inconsistent; for string parameters, it compares whether the string content is exactly the same.

[0079] If all parameters are determined to be consistent during the item-by-item comparison process, the configuration distribution is confirmed to be completely successful. A configuration success confirmation log is generated, recording the configuration task ID, terminal identifier, configuration version number, and timestamp. This log is saved in the main station database as audit evidence. The main station simultaneously sends a configuration success confirmation response message back to the distribution terminal. Upon receiving this response, the distribution terminal marks the configuration as verified.

[0080] If one or more parameters are found to be inconsistent during the item-by-item comparison, the master station system immediately generates a detailed discrepancy report. The report clearly lists complete information for all inconsistent parameters, including their hierarchical path in the configuration file, expected value, actual value, and the deviation between the two. After the discrepancy report is generated, a reconfiguration process is automatically triggered. The master station system reassembles the configuration parameters based on the report's content, re-executes compiler verification, compilation, distribution, and loading, and then distributes the corrected configuration to the distribution terminals again, triggering the readback and comparison process again. This cycle continues until all parameters are consistent, ensuring final configuration consistency.

[0081] Furthermore, this application also includes the following steps: constructing a set of power distribution terminals; clustering the set of power distribution terminals based on equipment type and protection function requirements to obtain a power distribution terminal cluster; obtaining a predetermined binary format configuration file of the power distribution terminal cluster and using the predetermined binary format configuration file as a shared configuration file; encapsulating the shared configuration file according to the communication address of each power distribution terminal in the power distribution terminal cluster to reduce data redundancy during batch distribution.

[0082] Specifically, it reads information about all power distribution terminals that need to be configured in the current batch, including each terminal's device identifier, device type, current firmware version, communication address, and the protection function requirements to be performed by that terminal. This information is then compiled into a power distribution terminal set.

[0083] The distribution terminal set is grouped using equipment type and protection function requirements as two core constraints. Each terminal in the set is traversed, and its equipment type and protection function requirements are extracted, concatenating these two fields as a clustering key. All terminals with the same clustering key are grouped into the same cluster, with terminals within each cluster having identical parameter structures, protection function on / off states, and sets of setting parameters. Terminals with different clustering keys are grouped into different clusters. After clustering, each cluster is assigned a unique cluster identifier, and a list of communication addresses for all terminals within that cluster is recorded.

[0084] After clustering is completed, a shared configuration file is generated for each cluster. Based on the device type and protection function requirements of the cluster, the configuration structure description file is used as the metadata basis to generate a first intermediate format configuration file. The corresponding setting value for the cluster is filled in, and the setting value is the same for all terminals in the cluster. The compiler verifies and compiles the binary file to finally obtain a complete binary format configuration file, which is the shared configuration file for the cluster.

[0085] The process iterates through each terminal in the cluster and reads its communication address. For each terminal, the data body of the shared configuration file (i.e., binary configuration data, without any terminal-specific header information) is used as the payload. The target address information is then encapsulated in the outer layer according to the requirements of the corresponding communication protocol. For TCP / IP networks, this is encapsulated as an IP / UDP / TCP header containing the target IP address and port number. After encapsulation, an independent data frame for that terminal is formed and injected into the communication network for transmission to the target terminal. This encapsulation and transmission operation is performed on every terminal within the cluster. Throughout the process, only one copy of the shared configuration file's data body is stored in the main station's memory. All terminal transmission operations share this single data content, with only different target address encapsulation information added to its outer layer.

[0086] Compared to generating independent configuration files for each terminal, the shared configuration distribution method reduces the computational load of the main station system from generating N configuration files to generating 1 configuration file and N address encapsulations. The actual amount of data transmitted on the communication line is reduced from N complete configuration data to 1 configuration data and N address headers. Especially when the configuration file itself is large and the number of terminals is large, the redundancy reduction effect of the shared configuration method is extremely significant.

[0087] In summary, the method for generating a power distribution terminal configuration file provided in this application has the following technical effects: A unified configuration structure description file is constructed using a general description language independent of specific communication protocols and hardware platforms, based on the device type and protection functions to be executed of the power distribution terminal; an intermediate format configuration template file is automatically generated according to the configuration structure description file, and a first intermediate format configuration file is formed according to the hierarchical framework and preset default values ​​of each configuration parameter in the configuration parameter set contained in the configuration template file; external input values ​​are obtained, and the external input values ​​are correlated and verified according to the logical association constraints in the configuration template file; the verified configuration parameter values ​​from the external input values ​​are filled into the first intermediate format configuration file to generate a second intermediate format configuration file; the second intermediate format configuration file is input into a compiler, which performs verification on the second intermediate format configuration file according to the configuration structure description file; after all verifications pass, the second intermediate format configuration file is compiled into a binary format configuration file; the binary format configuration file is distributed to the power distribution terminal as a whole in the form of data blocks. In other words, by using a general description language independent of communication protocols and hardware platforms to structurally model equipment types and protection functions, establishing logical association constraints between parameters and performing pre-consensus verification on external inputs, and then having the compiler perform secondary syntax and data type verification based on the structure description file, the configuration data that has passed the double verification is finally compiled into binary data blocks and distributed to the power distribution terminal as a whole in the form of data blocks. This intercepts configuration errors at the offline host computer stage, eliminates protection risks caused by parameter logic mismatch, simplifies the on-site debugging process, shortens the project deployment cycle, and significantly improves the correctness, consistency and overall operation and maintenance efficiency of the power distribution terminal configuration.

[0088] Example 2: Based on the same inventive concept as the method for generating a power distribution terminal configuration file in Example 1, this application also provides a system for generating a power distribution terminal configuration file. Please refer to the appendix. Figure 3The power distribution terminal configuration file generation system includes: a structure description file configuration module 11, used to construct a unified configuration structure description file based on the device type and protection function to be executed of the power distribution terminal using a general description language independent of specific communication protocols and hardware platforms; a first configuration module 12, used to automatically generate an intermediate format configuration template file according to the configuration structure description file, and form a first intermediate format configuration file according to the hierarchical framework and preset default values ​​of each configuration parameter in the configuration parameter set contained in the configuration template file; a second configuration module 13, used to obtain external input values, perform association verification on the external input values ​​according to the logical association constraint relationship in the configuration template file, fill the configuration parameter values ​​that pass the verification in the external input values ​​into the first intermediate format configuration file, and generate a second intermediate format configuration file; a file verification module 14, used to input the second intermediate format configuration file into a compiler, the compiler performs verification on the second intermediate format configuration file according to the configuration structure description file, and after all verifications pass, compiles the second intermediate format configuration file into a binary format configuration file; and a data delivery module 15, used to deliver the binary format configuration file to the power distribution terminal in the form of data blocks.

[0089] Furthermore, the structure description file configuration module 11 in the power distribution terminal configuration file generation system is also used to: define a set of configuration parameters in the configuration structure description file according to the hierarchical relationship, the set of configuration parameters including device identity parameters, network communication parameters, protection setting parameters and function activation / deactivation parameters, and limit the data type and value range of each configuration parameter.

[0090] Furthermore, the file verification module 14 in the power distribution terminal configuration file generation system is also used to: arrange and store each configuration parameter in a fixed byte width according to the data type definition of each configuration parameter in the configuration structure description file, and remove the parameter name tag, hierarchical structure tag and separator mark in the second intermediate format configuration file; at the same time, write the original value of each configuration parameter directly into the corresponding storage location in binary numerical form, so that the data structure of the binary format configuration file is consistent with the configuration parameter storage structure of the power distribution terminal at the byte level.

[0091] Furthermore, the data distribution module 15 in the power distribution terminal configuration file generation system is also used to: write integrity verification information into the header of the binary format configuration file; the power distribution terminal verifies the integrity and source legality of the configuration file based on the integrity verification information, and after verification, directly maps the binary format configuration file to the memory space through memory mapping; the running program of the power distribution terminal directly reads the configuration parameter values ​​from the memory space and applies them to the corresponding protection functions.

[0092] Furthermore, the data delivery module 15 in the power distribution terminal configuration file generation system is also used for: the integrity verification information includes at least a cyclic redundancy check value and digital signature information; the power distribution terminal verifies the integrity and source legitimacy of the configuration file based on the integrity verification information, including: calculating the cyclic redundancy check value of the received binary format configuration file and comparing it with the cyclic redundancy check value in the integrity verification information to obtain a first comparison result; according to the first comparison result, if the comparison is consistent, verifying the digital signature information based on a preset public key; if the verification is successful, confirming the source legitimacy of the binary format configuration file.

[0093] Furthermore, the data delivery module 15 in the power distribution terminal configuration file generation system is also used to: write version identification information into the header of the binary format configuration file; when the power distribution terminal loads the configuration file, it compares its own firmware version information with the version identification information to obtain a comparison result; according to the comparison result, if the versions are consistent, all configuration parameters are fully applied; according to the comparison result, if the versions are inconsistent, the power distribution terminal identifies the parameter structure differences between the old and new versions according to the built-in version adaptation rules, extracts a subset of configuration parameters compatible with the current firmware version from the binary format configuration file according to the parameter structure differences and applies it, while replacing incompatible parameter items with default safe values.

[0094] Furthermore, the power distribution terminal configuration file generation system is also used for: after the power distribution terminal completes the application of configuration parameters, extracting all currently effective configuration parameters from the running memory and reorganizing them according to an intermediate format to generate an intermediate format readback configuration file; comparing the readback configuration file with the second intermediate format configuration file item by item; if all configuration parameters are consistent, the configuration is confirmed to be successful; if there are differences, a difference report is generated and a reconfiguration process is triggered.

[0095] Furthermore, the power distribution terminal configuration file generation system is also used for: constructing a power distribution terminal set; clustering the power distribution terminal set according to equipment type and protection function requirements to obtain a power distribution terminal cluster; obtaining a predetermined binary format configuration file of the power distribution terminal cluster and using the predetermined binary format configuration file as a shared configuration file; and encapsulating the shared configuration file according to the communication address of each power distribution terminal in the power distribution terminal cluster to reduce data redundancy during batch distribution.

[0096] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The method and specific example for generating a power distribution terminal configuration file in the foregoing embodiment one are also applicable to the power distribution terminal configuration file generation system of this embodiment. Through the foregoing detailed description of the method for generating a power distribution terminal configuration file, those skilled in the art can clearly understand the power distribution terminal configuration file generation system of this embodiment. Therefore, for the sake of brevity, it will not be described in detail here.

[0097] In embodiment three, based on the same inventive concept as the method for generating a power distribution terminal configuration file in embodiment one, this application also provides a computer-readable storage medium storing a computer program, which, when executed, implements the steps of the method for generating a power distribution terminal configuration file as described in any one of embodiments one above.

[0098] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0099] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for generating a power distribution terminal configuration file, characterized in that, include: Based on the equipment type of the power distribution terminal and the protection functions to be executed, a unified configuration structure description file is constructed using a general description language that is independent of specific communication protocols and hardware platforms. An intermediate format configuration template file is automatically generated based on the configuration structure description file, and a first intermediate format configuration file is formed based on the hierarchical framework of each configuration parameter in the configuration parameter set contained in the configuration template file and the preset default values. Obtain external input values, perform association verification on the external input values ​​according to the logical association constraints in the configuration template file, fill the configuration parameter values ​​that pass the verification in the external input values ​​into the first intermediate format configuration file, and generate the second intermediate format configuration file. The second intermediate format configuration file is input into the compiler. The compiler performs verification on the second intermediate format configuration file according to the configuration structure description file. After all verifications pass, the second intermediate format configuration file is compiled into a binary format configuration file. The binary format configuration file is sent to the power distribution terminal as a whole in the form of data blocks.

2. The method for generating a power distribution terminal configuration file according to claim 1, characterized in that, The configuration structure description file defines a set of configuration parameters according to a hierarchical relationship. The set of configuration parameters includes device identity parameters, network communication parameters, protection setting parameters, and function enable / disable parameters, and limits the data type and value range of each configuration parameter.

3. The method for generating a power distribution terminal configuration file according to claim 2, characterized in that, Compile the second intermediate format configuration file into a binary format configuration file, including: According to the data type definition of each configuration parameter in the configuration structure description file, each configuration parameter is arranged and stored in order with a fixed byte width, and the parameter name tag, hierarchical structure tag and separator mark in the second intermediate format configuration file are removed. At the same time, the original values ​​of each configuration parameter are directly written into the corresponding storage location in binary numerical form, so that the data structure of the binary format configuration file is aligned with the configuration parameter storage structure of the power distribution terminal at the byte level.

4. The method for generating a power distribution terminal configuration file according to claim 3, characterized in that, Before sending the binary format configuration file as a whole to the power distribution terminal in the form of data blocks, the following steps are also included: Integrity verification information is written to the header of the binary format configuration file; The power distribution terminal verifies the integrity and legality of the configuration file based on the integrity verification information, and after the verification is successful, directly maps the binary format configuration file to the memory space through memory mapping. The operating program of the power distribution terminal directly reads the configuration parameter values ​​from the memory space and applies them to the corresponding protection functions.

5. The method for generating a power distribution terminal configuration file according to claim 4, characterized in that, The integrity verification information includes at least a cyclic redundancy check value and digital signature information. Based on the integrity verification information, the power distribution terminal verifies the integrity and source legitimacy of the configuration file, including: Calculate the cyclic redundancy check value of the received binary format configuration file and compare it with the cyclic redundancy check value in the integrity check information to obtain a first comparison result; If the comparison matches based on the first comparison result, the digital signature information is verified based on the preset public key. If the verification is successful, the source of the binary format configuration file is confirmed to be legitimate.

6. The method for generating a power distribution terminal configuration file according to claim 3, characterized in that, After the binary format configuration file is distributed to the power distribution terminal as a whole in the form of data blocks, the following steps are also included: Version identification information is written to the header of the binary format configuration file; When loading the configuration file, the power distribution terminal compares its own firmware version information with the version identifier information to obtain the comparison result. Based on the comparison results, if the versions are consistent, all configuration parameters will be applied in full. According to the comparison results, if the versions are inconsistent, the power distribution terminal identifies the parameter structure differences between the old and new versions based on the built-in version adaptation rules, extracts a subset of configuration parameters compatible with the current firmware version from the binary format configuration file based on the parameter structure differences and applies them, while replacing incompatible parameter items with default safe values.

7. The method for generating a power distribution terminal configuration file according to claim 6, characterized in that, This also includes: After the power distribution terminal completes the application of configuration parameters, it extracts all currently effective configuration parameters from the running memory and reorganizes them according to the intermediate format to generate a readback configuration file in the intermediate format. The readback configuration file is compared item by item with the second intermediate format configuration file. If all configuration parameters are consistent, the configuration is confirmed to be successful. If there are differences, a difference report is generated and the reconfiguration process is triggered.

8. The method for generating a power distribution terminal configuration file according to claim 1, characterized in that, Also includes: Establish a distribution terminal set; The set of power distribution terminals is clustered based on equipment type and protection function requirements to obtain power distribution terminal clusters. Obtain a predetermined binary format configuration file for the power distribution terminal cluster, and use the predetermined binary format configuration file as a shared configuration file; The shared configuration file is encapsulated according to the communication address of each power distribution terminal in the power distribution terminal cluster to reduce data redundancy during batch distribution.

9. A system for generating configuration files for power distribution terminals, characterized in that, The step of implementing the method for generating a power distribution terminal configuration file according to any one of claims 1 to 8, wherein the system for generating the power distribution terminal configuration file comprises: The structure description file configuration module is used to construct a unified configuration structure description file based on the equipment type of the power distribution terminal and the protection function to be executed, using a general description language that is independent of specific communication protocols and hardware platforms. The first configuration module is used to automatically generate an intermediate format configuration template file based on the configuration structure description file, and to form a first intermediate format configuration file based on the hierarchical framework of each configuration parameter in the configuration parameter set contained in the configuration template file and the preset default values. The second configuration module is used to obtain external input values, perform association verification on the external input values ​​according to the logical association constraint relationship in the configuration template file, fill the configuration parameter values ​​that pass the verification in the external input values ​​into the first intermediate format configuration file, and generate the second intermediate format configuration file. The file verification module is used to input the second intermediate format configuration file into the compiler. The compiler performs verification on the second intermediate format configuration file according to the configuration structure description file. After all verifications pass, the second intermediate format configuration file is compiled into a binary format configuration file. The data distribution module is used to distribute the binary format configuration file as a whole to the power distribution terminal in the form of data blocks.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the steps of the method for generating a power distribution terminal configuration file as described in any one of claims 1 to 8.

Images