Dynamic processing method of configuration file

Abstract

The application provides a dynamic processing method of a configuration file, relates to the technical field of computer data processing, and comprises the following steps: obtaining an xml template and constructing a template syntax tree; obtaining the capability characteristics of a target device, and performing node pruning on the template syntax tree based on the capability characteristics to obtain a target syntax tree; in an initial configuration scene, generating an initial xml configuration file based on the target syntax tree and configuration data; and in a configuration update scene, performing syntax tree difference comparison on an original xml configuration file and update configuration data based on the target syntax tree to extract changed nodes, and incrementally adding the changed nodes to the original xml configuration file. The application can dynamically adapt the configuration structure according to the device capability, support incremental update, reduce the parsing load, and improve the configuration maintenance efficiency.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, specifically to a method, apparatus, computer equipment, storage medium, and a rail transit host computer control system for dynamic processing of configuration files. Background Technology

[0002] In complex industrial control and human-machine interaction systems, the operation of host computer software heavily relies on configuration files in formats such as XML. Current technologies typically generate configuration files by filling data into fixed templates. However, with the diversification of device functional modules and the rapid iteration of software versions, this static generation method reveals significant drawbacks: Firstly, general templates often contain numerous redundant nodes specific to certain versions or functions, leading to excessive parsing load on low-end or older devices during configuration loading, and even causing operational anomalies due to the identification of invalid nodes. Secondly, when software versions are upgraded or business processes change, the lack of a difference comparison mechanism based on structured data usually necessitates manual rewriting or modification of the entire configuration file, which is not only inefficient but also prone to formatting errors or parameter loss due to manual operation, making it difficult to meet the needs of large-scale deployment and high-frequency iteration. Therefore, there is an urgent need for a configuration file processing solution that can dynamically adapt the configuration structure according to device capabilities and support efficient incremental updates. Summary of the Invention

[0003] To address the problems of poor compatibility of configuration file generation and high cost of version upgrade and maintenance in existing technologies, this application realizes lightweight configuration generation and incremental updates based on syntax tree through a dynamic processing method, device, computer equipment, storage medium, and rail transit host computer control system for configuration files.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A dynamic processing method for configuration files includes: obtaining an XML template and constructing a template syntax tree based on the XML template; obtaining capability characteristics of a target device and pruning nodes in the template syntax tree based on the capability characteristics to obtain a target syntax tree; in an initial configuration scenario, generating an initial XML configuration file for the target device based on the target syntax tree and the obtained configuration data; in a configuration update scenario, comparing the syntax tree differences between the original XML configuration file of the target device and the updated configuration data based on the target syntax tree, extracting changed nodes, and incrementally merging the changed nodes into the original XML configuration file of the target device to obtain an updated XML configuration file.

[0005] Preferably, the step of pruning the template syntax tree based on the capability features to obtain the target syntax tree includes: identifying logical control nodes in the template syntax tree; evaluating the execution conditions of the logical control nodes based on the capability features; and removing the logical control nodes and their associated subtrees that do not meet the execution conditions to obtain the target syntax tree.

[0006] Preferably, the logical control node includes a condition judgment node and a loop node; the step of evaluating the execution conditions of the logical control node based on the capability features includes: for the condition judgment node, extracting the target parameter value from the capability features, matching the target parameter value with the branch condition expressions of the condition judgment node, and determining the branch that satisfies the branch condition expressions as the target branch; for the loop node, obtaining the list data associated with the loop node in the capability features, and determining the data length of the list data as the loop count; the step of removing the logical control node and its associated subtree that do not satisfy the execution conditions includes: retaining the subtree corresponding to the target branch and removing the subtrees in the condition judgment node that are not corresponding to the target branch; when the loop count is zero, removing the loop node and all its loop body subtrees.

[0007] Preferably, the step of comparing the syntax tree differences between the original XML configuration file and the updated configuration data of the target device based on the target syntax tree, extracting changed nodes, and incrementally merging the changed nodes into the original XML configuration file of the target device includes: parsing the original XML configuration file of the target device into a source syntax tree, and generating an updated syntax tree based on the updated configuration data and the target syntax tree; comparing the node paths and attribute values ​​of the source syntax tree and the updated syntax tree to identify added nodes, deleted nodes, and modified nodes; determining the merging order of the added nodes, deleted nodes, and modified nodes based on the dependencies between nodes; and performing node writing, removal, and attribute update operations in the source syntax tree according to the merging order.

[0008] Preferably, after performing node writing, removal, and attribute update operations in the source syntax tree according to the merge order, the method further includes: optimizing the structure of the source syntax tree after the operations, wherein the structure optimization includes: traversing the source syntax tree after the operations, checking whether the starting tag and closing tag of each node match, and automatically completing the closing tag based on preset syntax rules if a closing tag is missing; identifying empty nodes that do not have child nodes and no attribute values, and removing the empty nodes from the source syntax tree; assigning a corresponding number of indentation spaces to each node based on the node's level depth in the source syntax tree to standardize the node indentation format; and performing format verification on the optimized source syntax tree, wherein the format verification includes verifying whether the serialized file meets the preset syntax specifications and the configuration loading specifications of the target device, and if the verification passes, serializing the source syntax tree into the updated XML configuration file.

[0009] Preferably, the configuration data is derived from a structured table file; the target device is a rail transit host computer, and the capability characteristics include at least one of the host computer version number, supported functional module types, and communication protocol types.

[0010] Furthermore, the present invention also provides a dynamic processing apparatus for configuration files, applicable to the dynamic processing method for configuration files as described above, comprising: a template parsing module for obtaining an XML template and constructing a template syntax tree based on the XML template; a syntax tree pruning module for obtaining capability features of a target device and pruning nodes of the template syntax tree based on the capability features to obtain a target syntax tree; an XML generation module for generating an initial XML configuration file for the target device based on the target syntax tree and the obtained configuration data in an initial configuration scenario; and an incremental merging module for performing a syntax tree difference comparison between the original XML configuration file of the target device and the updated configuration data based on the target syntax tree in a configuration update scenario, extracting changed nodes, and incrementally merging the changed nodes into the original XML configuration file of the target device to obtain an updated XML configuration file.

[0011] In addition, the present invention also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the dynamic processing method of the configuration file as described above.

[0012] In addition, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the dynamic processing method for the configuration file as described above.

[0013] In addition, the present invention also provides a rail transit host computer control system, including a host computer body and a dynamic processing device for configuration files as described above, wherein the dynamic processing device for configuration files is configured to generate or update XML configuration files required for the operation of the host computer body.

[0014] Beneficial effects: This invention prunes nodes by parsing an XML template into a syntax tree and combining this with the target device's capability characteristics. This allows for the removal of logical branches and redundant subtrees that are incompatible with the current device from the underlying data structure during the configuration file generation stage, resulting in a lightweight target syntax tree. Compared to traditional fixed template filling methods, this mechanism ensures that the generated configuration file contains only the valid nodes actually required for device operation. This fundamentally reduces the computational load and memory consumption during configuration parsing by the host computer, while also avoiding parsing errors caused by invalid nodes, thus improving compatibility and operational stability across multiple device versions.

[0015] Furthermore, in configuration update scenarios, this invention compares the differences between the original configuration and the updated data based on a syntax tree structure, and determines the merging order to execute incremental updates according to node dependencies. This mechanism changes the traditional mode of full rewriting or manual modification, ensuring that when software versions are upgraded or business changes occur, only the changed nodes need to be accurately merged to retain the original valid configuration. This avoids the data loss risk and human error caused by full reconstruction, and significantly shortens the maintenance cycle of configuration files, meeting the needs of high-frequency iteration and large-scale deployment of complex systems. Attached Figure Description

[0016] Figure 1 This is a flowchart of an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0019] Example 1 like Figure 1 As shown, this embodiment provides a dynamic processing method for configuration files. This method achieves full lifecycle management of configuration files through a unified underlying data structure, covering the complete process from initial generation to subsequent updates. Specifically, the method includes the following steps: Step S1: Obtain the XML template and construct a template syntax tree based on the XML template.

[0020] Specifically, the system first reads a pre-set XML template file, which defines the standard skeleton and variable logic of the configuration file. Unlike traditional text-replacement template engines, this embodiment parses the XML template into a tree-like data structure in memory, namely a template syntax tree. This template syntax tree consists of multiple node objects, each encapsulating information such as tag names, attribute sets, a list of child nodes, and node type identifiers. It should be understood that the template syntax tree here is not only the result of parsing the XML file, but also the direct computation object for all subsequent trimming, comparison, and generation operations. By transforming the static text template into a dynamic in-memory object model, subsequent processing can directly operate on the data structure, avoiding the overhead of repeated text parsing and serialization, and laying a data foundation for efficient processing.

[0021] Step S2: Obtain the capability characteristics of the target device, and prune the nodes of the template syntax tree based on the capability characteristics to obtain the target syntax tree.

[0022] Specifically, the system acquires capability characteristics representing the current hardware and software state of the target device, such as device model, software version number, installed functional modules, or supported communication protocols. Then, using these capability characteristics as constraints, it traverses the template syntax tree, identifies nodes and their associated subtrees that do not match the current device's capabilities, and physically removes them from the tree structure. It is crucial to emphasize that this node pruning involves a substantial modification of the tree structure in memory; that is, it completely removes references and data to redundant nodes, rather than merely skipping these nodes during file generation or logically masking them at runtime. This physical pruning operation ensures that the final target syntax tree contains only the effective configuration structure actually required for the target device's operation, fundamentally eliminating the occupation of device parsing resources by invalid nodes and achieving lightweight adaptation of the configuration file.

[0023] Step S3: In the initial configuration scenario, based on the target syntax tree and the acquired configuration data, generate the initial XML configuration file for the target device.

[0024] Specifically, when the target device is detected to be in its initial deployment or reset state, an initial configuration scenario is triggered. The system maps and populates the configuration data obtained externally into the corresponding leaf nodes or attributes of the target syntax tree. Since the target syntax tree has already been pruned in step S2, the data population process does not require any further conditional checks or filtering; valid data is directly injected into the valid structure. Finally, the populated target syntax tree is serialized into a standard XML file format and output as the target device's initial XML configuration file. This mechanism ensures that the generated configuration file conforms to XML syntax specifications and perfectly matches the current capabilities of the target device, avoiding slow startup or parsing errors caused by configuration redundancy.

[0025] Step S4: In the configuration update scenario, the original XML configuration file of the target device and the updated configuration data are compared based on the target syntax tree to extract the change nodes, and the incremental change nodes are merged into the original XML configuration file of the target device to obtain the updated XML configuration file.

[0026] Specifically, when a target device undergoes a software upgrade or business change, a configuration update scenario is triggered. In this case, the system does not regenerate the entire configuration file. Instead, it parses the target device's existing XML configuration file into a source syntax tree (RST), and simultaneously generates an expected updated syntax tree based on the latest updated configuration data and the current target RST. Then, at the tree structure level, it compares the paths and attribute values ​​of the source and updated RST nodes node by node to accurately identify newly added, deleted, or modified change nodes. Subsequently, these change nodes are incrementally merged into the source RST according to a preset dependency order, rather than performing a text-level replacement or rewrite of the entire file. This node-level operation based on the syntax tree structure effectively preserves unchanged personalized settings or historical data in the original configuration file, avoiding the data loss risk of a full overwrite, and significantly reducing the computational complexity and error probability during large-scale configuration file updates.

[0027] Through the dual-track processing logic described above, this embodiment utilizes the template syntax tree as a unified data carrier, which can achieve lightweight configuration generation through physical pruning in the initial stage and secure and efficient incremental maintenance through structured comparison in the update stage, thereby solving the problems of poor configuration adaptability and high maintenance costs in traditional solutions.

[0028] Example 2 Building upon Example 1, this example further details the specific implementation of node pruning of the template syntax tree based on capability features. Specifically, pruning nodes of the template syntax tree based on capability features to obtain the target syntax tree includes: identifying logical control nodes in the template syntax tree; evaluating the execution conditions of the logical control nodes based on capability features; and removing logical control nodes that do not meet the execution conditions and their associated subtrees to obtain the target syntax tree.

[0029] In this embodiment, logical control nodes do not refer to native tags in the XML standard specification, but rather to special nodes predefined during the template design phase to characterize the configuration generation logic. After constructing the template syntax tree, the system identifies these logical control nodes by traversing the tree structure or querying preset node type indexes. Identification can be based on the node's tag name, the namespace it belongs to, or specific logical identifiers contained in the node's attributes. Once a logical control node is identified, the system treats it as an object to be evaluated, reads its internally encapsulated conditional expressions or loop rules, and performs runtime calculations in conjunction with the capabilities of the current target device. It is important to emphasize that the pruning operation is a structural modification of the syntax tree object model in memory; that is, it directly removes the parent node's reference to child nodes that do not meet the conditions and releases related memory resources, rather than retaining empty tags or comment markers in the final generated XML file. This physical pruning operation ensures that the configuration file generated by subsequent serialization is structurally clean and compact, fundamentally reducing the IO overhead and memory usage when the target device parses the configuration file.

[0030] As a preferred implementation, the logic control nodes include conditional judgment nodes and loop nodes. These two node types cover the vast majority of dynamic adaptation scenarios in the configuration file, corresponding to the two core logics of selective generation and batch generation, respectively.

[0031] For conditional decision nodes, the execution conditions of logical control nodes are evaluated based on capability characteristics. This includes: extracting target parameter values ​​from the capability characteristics, matching the target parameter values ​​with the conditional expressions of each branch of the conditional decision node, and identifying the branches that satisfy the conditional expressions as the target branches. Specifically, a conditional decision node typically contains one or more branch subtrees, each associated with a Boolean expression. During runtime, the system extracts the parameter values ​​referenced by the expression from the capability characteristic set and substitutes them into the expression for evaluation. For example, if a conditional decision node exists in the template with a main branch condition of "version>=2.0" and an alternative branch condition of "version<2.0", and the current device's capability characteristics show a version number of "V2.1", then the system determines that the main branch condition is true and identifies it as the target branch. Subsequently, when removing logical control nodes and their associated subtrees that do not meet the execution conditions, the subtrees corresponding to the target branches are retained, and the subtrees of the conditional decision nodes that do not correspond to the target branches are removed. This means that in the above example, all child nodes under the alternative branches will be directly removed from the syntax tree, and only the configuration structure under the main branch will be retained. In this way, the generated configuration file will not contain any legacy configuration items that are unrelated to the current device version, thus avoiding parsing conflicts or accidental triggering caused by redundant parameters.

[0032] For loop nodes, the execution conditions of logical control nodes are evaluated based on capability characteristics, including: obtaining the list data associated with the loop node from the capability characteristics, and determining the data length of the list data as the loop count. Loop nodes are used to handle a variable number of configuration items, such as sensor channels, communication ports, or user permission lists. During execution, the system retrieves the corresponding list object from the capability characteristics or external configuration data according to the data source path specified by the loop node. The determination of the loop count depends entirely on the actual number of elements in the list object, not the hard-coded value in the template. Accordingly, logical control nodes and their associated subtrees that do not meet the execution conditions are removed, including: when the loop count is zero, the loop node and all its contained loop body subtrees are removed. For example, if a certain model of host computer does not support external expansion modules, then the "extension module list" in its capability characteristics is an empty list with a length of 0. In this case, the system will directly and completely delete the entire loop node used to generate the expansion module configuration and all its internal child nodes from the syntax tree. Conversely, if the list contains N elements, the system will copy the loop subtree N times, replacing the placeholders in each copy with the actual values ​​of the corresponding elements. These N instantiated subtrees will then be attached to the parent node of the original loop node, and finally, the loop node itself will be removed. This mechanism allows the same template to adaptively generate any number of configuration blocks, eliminating the need to maintain multiple template files for different device specifications.

[0033] To illustrate the pruning mechanism more clearly, let's demonstrate it using an XML template fragment containing nested logic. Assume the template syntax tree contains a parent node "CommunicationConfig" with a conditional node "IfProtocol" that has two branches: "MVB" and "Ethernet". Under the "MVB" branch, there's a nested loop node "ForPort" used to iterate through the MVB port list. When the target device's capabilities indicate the communication protocol is "Ethernet" and the MVB port list is empty, the pruning process is as follows: First, the "IfProtocol" node is evaluated. Finding a successful match in the "Ethernet" branch, the "MVB" branch subtree is physically deleted. Since the "ForPort" node is located within the deleted "MVB" branch, it is also removed entirely, eliminating the need to evaluate its loop count separately. The final target syntax tree retains only the "Ethernet" related configuration subtree under the "CommunicationConfig" node. This process demonstrates how the present invention efficiently transforms a general full-featured template into a dedicated lightweight configuration structure for a specific device through top-down recursive evaluation and physical pruning, ensuring the accuracy of the configuration content while minimizing file size.

[0034] Example 3 Building upon Example 1, this example further details the incremental merging and post-processing mechanism in configuration update scenarios. Specifically, based on the target syntax tree, a syntax tree difference comparison is performed between the original XML configuration file of the target device and the updated configuration data. Change nodes are extracted, and the incremental merged changes are incorporated into the original XML configuration file of the target device, including the following steps: Step S410 involves parsing the original XML configuration file of the target device into a source syntax tree, and generating an update syntax tree based on the updated configuration data and the target syntax tree. In this step, the system maintains two parallel in-memory data structures. The source syntax tree reflects the current actual configuration state of the target device, which may contain legacy personalized parameters or dynamic data generated during runtime. The update syntax tree is a model of the expected state, constructed based on the target syntax tree (trimmed from capability features in Example 1) and combined with the latest updated configuration data.

[0035] Step S420: Compare the node paths and attribute values ​​of the source and updated syntax trees to identify newly added, deleted, and modified nodes. Specifically, the system uses a depth-first or breadth-first traversal algorithm to simultaneously scan both syntax trees. For each node, first compare its absolute or relative hierarchical path in the tree to determine its identity; then compare the node's attribute set and text content. If a path exists only in the updated syntax tree, it is marked as a newly added node; if it exists only in the source syntax tree, it is marked as a deleted node; if the paths are the same but the attribute values ​​or child node content differ, it is marked as a modified node. This structured path-based comparison method, compared to the traditional text line-level Diff algorithm, can effectively identify pseudo-changes caused by node position movement or format adjustment, significantly reducing the false alarm rate.

[0036] Step S430 determines the merging order of adding, deleting, and modifying nodes based on the dependencies between nodes. This is a key technical means to ensure the legality of the configuration file structure after incremental merging. In XML configuration systems, there are often strict parent-child nesting relationships or cross-node reference dependencies between nodes. If write or delete operations are performed directly without ignoring these dependencies, it is very easy to cause the intermediate structure to be illegal. For example, if you try to insert a child node under a parent node that has not yet been created, or delete a basic definition node that is still referenced by other nodes, it will cause a parsing error. Therefore, in this embodiment, a dependency directed graph is pre-constructed before performing actual operations. By analyzing the parent-child hierarchy and ID reference links between nodes, a safe operation sequence after topological sorting is calculated. It usually follows the principles of creating ancestor nodes before creating descendant nodes, deleting leaf nodes before deleting root nodes, and updating the referenced definition before updating the referrer. Through this dependency-aware sorting mechanism, it is ensured that each merging operation is performed in a legal context, fundamentally eliminating the risk of configuration file corruption caused by improper operation timing.

[0037] In step S440, node write, removal, and attribute update operations are performed in the source syntax tree according to the merge order. The system modifies the memory object of the source syntax tree sequentially based on the safety sequence determined in step S430. For newly added nodes, they are attached to the specified parent node; for deleted nodes, their reference to the parent node is removed and memory is released; for modified nodes, their attribute dictionary or text value is directly updated. The entire process is completed on the tree object in memory, without involving any disk I / O or text stream operations, thus ensuring extremely high processing efficiency and atomicity.

[0038] After completing the above incremental merge operation, in order to eliminate structural defects that may be introduced due to node addition, deletion, or modification, this embodiment also introduces a structural self-healing and double-checking mechanism. Specifically, after performing node write, removal, and attribute update operations in the source syntax tree according to the merge order, the method further includes: Step S450 involves structural optimization of the source syntax tree after the operation. This optimization process includes three dimensions of repair actions. First, the source syntax tree after the operation is traversed, and the start tag and closing tag of each node are checked for matching. If a closing tag is missing, it is automatically completed based on preset syntax rules to prevent the generation of illegible XML files during serialization. Second, empty nodes without child nodes and attribute values ​​are identified and removed from the source syntax tree. These empty nodes usually remain after batch deletion of child nodes. If not cleaned up, they not only increase the file size but may also be misjudged as valid configuration items by the host computer parser, triggering an exception. Finally, based on the node's level depth in the source syntax tree, a corresponding number of indentation spaces is assigned to each node to standardize the node indentation format. Although this step does not affect machine parsing, it is crucial for subsequent manual review, version comparison, and debugging and maintenance, significantly improving the readability and maintainability of the configuration file.

[0039] Step S460 involves format validation of the optimized source syntax tree. This validation employs a two-layer strategy. The first layer is a general syntax specification validation, confirming that the file conforms to the XML standard definition and has no basic issues such as nested tags or invalid character encoding. The second layer is a target device configuration loading specification validation, which verifies whether required fields are complete, parameter values ​​are within legal ranges, and node combinations conform to business logic based on the target device's specific definitions or business rules. Only when both layers of validation pass will the system serialize the source syntax tree into an updated XML configuration file. If validation fails, a detailed error report is output, and the system rolls back to the state before merging, preventing incorrect configurations from being sent to the device. This embodiment not only achieves accurate incremental updates of configuration data but also ensures the structural and semantic correctness of the final output configuration file, effectively solving the technical problems of traditional incremental update tools easily generating dirty data and having poor compatibility.

[0040] Example 4 In some embodiments, the configuration data is derived from a structured table file; the target device is a rail transit host computer, and its capability characteristics include at least one of the following: host computer version number, supported functional module types, and communication protocol types.

[0041] Specifically, this embodiment applies the aforementioned general dynamic configuration file processing method to the TCMS host computer configuration management scenario of rail transit trains. In this scenario, structured table files are typically represented as standardized Excel parameter tables, containing multiple worksheets that define configuration items such as basic vehicle information, network topology parameters, display interface layout, and alarm thresholds. By parsing this Excel file, the system can automatically identify the mapping relationship between table headers and data rows, converting discrete cell data into configuration data objects in key-value pair form in memory, thereby providing standardized data input for subsequent syntax tree filling. This data source design based on structured tables allows vehicle engineers without programming expertise to maintain complex configuration parameters using familiar office software, significantly reducing the barrier to entry and error rate for configuration file creation.

[0042] For the target equipment, namely the rail transit host computer, acquiring its capability characteristics is crucial for achieving accurate configuration adaptation. In this embodiment, the host computer version number can be, for example, the release version identifier of the TCMS software; supported functional module types cover optional hardware or software components such as WiFi wireless transmission modules, 4G / 5G mobile communication modules, GPS positioning modules, and passenger information display modules; communication protocol types include MVB multi-function vehicle bus, Ethernet TRDP protocol, CANopen protocol, etc. These capability characteristics can be automatically extracted from the self-test feedback message during host computer startup, or manually selected and specified by engineers on the configuration tool interface. The system combines these multi-dimensional capability characteristics into a feature vector, which serves as the set of constraints for subsequent template syntax tree pruning.

[0043] To more clearly illustrate the actual operation of this invention in this application scenario, a specific case of TCMS host computer configuration generation and upgrade is used for demonstration. Assume that the initial configuration file needs to be generated for a TCMS host computer with version V2.0 software installed, equipped with a WiFi module, and using the MVB protocol. The system first loads a general XML template containing full version and full function definitions and constructs a template syntax tree. Subsequently, node pruning is performed based on the acquired capability characteristics: since the current version is V2.0, the old version compatible node subtree marked "version<=1.5" in the template is physically deleted; since the device only supports WiFi and not a 4G module, the loop nodes related to 4G dialing, APN settings, and signal strength monitoring in the template are completely removed because the association list is empty; at the same time, the conditional judgment branch for the MVB protocol is retained, while the configuration branch related to the EthernetTRDP protocol is removed. The final target syntax tree contains only the minimum complete set of nodes required for WiFi and MVB communication under version V2.0. Next, the system fills the leaf nodes of the target syntax tree with the corresponding data such as IP address, port number, and refresh cycle from the Excel parameter table, and then serializes it to generate a lightweight initial XML configuration file. Compared to the full configuration file without pruning, this initial file is smaller and the parsing time is shortened, effectively avoiding the risk of startup delays or memory overflows caused by loading invalid nodes on the host computer.

[0044] Furthermore, when the TCMS host computer software is upgraded from V2.0 to V2.1, the system enters a configuration update scenario. Version V2.1 adds detailed runtime log recording functionality, but the original MVB communication configuration remains unchanged. At this time, the system generates an update syntax tree based on the capabilities of V2.1 and compares it with the existing source syntax tree on the device. The comparison results show that only the "SystemConfig / Logging" path contains newly added nodes such as log levels, storage paths, and rolling strategies, while the communication-related path nodes are completely identical. The system then determines the merging order based on node dependencies, first creating the "Logging" parent node, then writing its child parameter nodes sequentially, and merging these incremental changes into the source syntax tree. During this process, the original MVB communication configuration nodes are unaffected, fully preserving the personalized parameters debugged on-site. After merging, the system automatically performs structural optimization on the source syntax tree, completes any missing closing tags, cleans up empty nodes generated by version iterations, and indents according to hierarchical specifications. Finally, after double verification, it outputs the updated XML configuration file. This process enables seamless and smooth upgrades across versions of configurations, introducing the configuration items required for new features while avoiding the risk of losing existing key parameters due to full coverage, thus fully verifying the practicality and reliability of the invention in complex business scenarios of rail transit.

[0045] Example 5 This embodiment provides a dynamic configuration file processing device. The device adopts a modular architecture design and is suitable for the dynamic configuration file processing method described in the foregoing embodiments. Specifically, the device includes a template parsing module, a syntax tree pruning module, an XML generation module, and an incremental merging module. These modules communicate and collaborate through standardized data interfaces, collectively forming the structured foundation for the full lifecycle management of configuration files.

[0046] The template parsing module is used to obtain XML templates and construct a template syntax tree based on them. Specifically, this module is equipped with an XML parsing engine that not only reads XML template files from disk or network streams, but more importantly, transforms the text-formatted templates into an in-memory object model. During the construction process, this module identifies the tag hierarchy, attribute information, and predefined logical control tags in the template, encapsulating them into a collection of node objects with parent-child reference relationships. This structured transformation allows subsequent trimming and generation operations to be performed directly on the in-memory objects, avoiding repeated text parsing overhead and providing a unified and efficient underlying data representation for the entire device.

[0047] The syntax tree pruning module is used to acquire the capability characteristics of the target device and prune the nodes of the template syntax tree based on these characteristics to obtain the target syntax tree. Specifically, the syntax tree pruning module receives the template syntax tree output from the template parsing module and the device capability characteristic parameters input from the outside. This module is internally configured with a logic evaluator that can traverse the logic control nodes in the template syntax tree, calculate the execution conditions based on the capability characteristics, and perform physical deletion operations on subtrees that do not meet the conditions. It is particularly important to emphasize that the output of the syntax tree pruning module, i.e., the target syntax tree, is the core intermediate product of the entire device. It serves both as the skeleton generated by the XML generation module in the initial configuration scenario and as the comparison benchmark for the incremental merging module in the configuration update scenario. This design ensures strict consistency in the configuration structure between the initial generation and incremental update business paths, effectively preventing configuration drift issues caused by two independent sets of logic.

[0048] The XML generation module is used to generate the initial XML configuration file for the target device based on the target syntax tree and the acquired configuration data in the initial configuration scenario. Specifically, the XML generation module is configured with a data mapper and a serializer. The data mapper is responsible for accurately injecting configuration data from external structured tables or other sources into the corresponding leaf nodes or attributes of the target syntax tree; the serializer is responsible for converting the populated in-memory object model into a standard-compliant XML text stream. Since the input target syntax tree has already undergone lightweight processing by the trimming module, the XML generation module does not need to perform any conditional judgments or redundant filtering, but only needs to perform pure data filling and formatted output, thereby significantly improving the processing efficiency and accuracy of batch configuration file generation.

[0049] The incremental merging module, in configuration update scenarios, compares the syntax tree differences between the original XML configuration file of the target device and the updated configuration data based on the target syntax tree, extracts changed nodes, and incrementally merges these changed nodes into the original XML configuration file of the target device to obtain the updated XML configuration file. Specifically, to support complex incremental update logic, the incremental merging module further integrates a difference comparison unit and a merging execution unit in its internal structure. The difference comparison unit is configured to parse the device's existing original XML configuration file into a source syntax tree and compare it one by one with the updated syntax tree generated based on the latest data, focusing on node-level paths and attribute values, thereby accurately identifying three types of changed nodes: added, deleted, and modified. The merging execution unit is configured to determine a safe operation sequence based on the topological sorting of the dependencies between nodes and sequentially execute the corresponding write, remove, or update operations on the source syntax tree. Furthermore, the merging execution unit also integrates a structure optimization subunit, used to automatically complete tags, clean empty nodes, and standardize indentation format after merging. By encapsulating functions such as difference identification, dependency ordering, atomic operations, and structural self-healing within an independent incremental merging module, this device achieves high cohesion and low coupling in configuration update logic, enabling the system to flexibly respond to various complex version iterations and configuration change requirements while ensuring data security.

[0050] Through the modular architecture described above, this embodiment solidifies the abstract dynamic processing method into a concrete device structure. The responsibilities of each module are clearly defined, and the data flow is explicit. In particular, the connection method centered on the target syntax tree not only technically ensures consistency in configuration generation and updates but also provides a solid engineering foundation for subsequent functional expansion and maintenance. For example, if support for new device types or configuration formats is required, only the rule base of the template parsing module or the extended syntax tree pruning module needs to be adapted, without modifying the core generation and merging logic, fully demonstrating the flexibility and scalability of this device architecture.

[0051] Example 6 This embodiment provides a computer device, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the dynamic processing method for configuration files as described in any of the preceding embodiments 1 to 6. Specifically, this computer device, as a hardware entity carrier for executing the method of this invention, is not limited in form and can be an independent server, industrial control computer, personal computer, mobile terminal, or a dedicated computing unit embedded in a rail transit host computer control system. The memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device, for persistently storing the program code implementing the above-mentioned dynamic processing logic for configuration files and temporary data generated during operation. The processor may be a central processing unit, microcontroller, digital signal processor, or field-programmable gate array, etc., which drives hardware resources to complete operations such as template syntax tree construction, node pruning, difference comparison, and incremental merging by reading instruction sequences from the memory. Through this hardware and software combined architecture, the abstract processing method is solidified into a specific product function, enabling the technical solution of this invention to be implemented in practical applications by selling or deploying this computer device.

[0052] This embodiment also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the dynamic processing method of the configuration file as described in any of embodiments 1 to 6 above. It should be specifically noted that the computer-readable storage medium referred to in this application means any tangible medium capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. Specific examples include, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any combination thereof, such as read-only memory, random access memory, erasable programmable read-only memory, flash memory, hard disk, floppy disk, magnetic tape, optical disk, USB flash drive, portable hard disk, and various memory cards. It should be understood that this computer-readable storage medium explicitly excludes transient propagation signals such as radio waves, free-space optical signals, light pulses propagating in optical fibers, or electrical pulses transmitted in wires, to ensure compliance with the statutory requirements for patentable subject matter. By recording the program carrying the method of the present invention in such a tangible medium, the technical solution can be independently distributed, backed up and migrated. Even without directly accessing computer equipment, relevant rights can be asserted through the circulation of the software carrier, thereby constructing a multi-dimensional intellectual property protection system.

[0053] Example 7 This embodiment provides a rail transit host computer control system, including a host computer body and a dynamic processing device for configuration files as described in the previous embodiment. The configuration processing device is configured to generate or update the XML configuration files required for the operation of the host computer body.

[0054] Specifically, this embodiment materializes the aforementioned dynamic configuration file processing technology into a complete industrial control system product. In this system, the host computer, as the object being configured, typically refers to the human-machine interface terminal or central control unit in a train control and management system. Its normal operation highly depends on the internally loaded XML configuration file that defines the interface layout, communication protocol stack, alarm thresholds, and business logic rules. The configuration processing device, as the core configuration management engine of the system, can be embedded in the host computer's operating system as a software module or deployed as an independent maintenance tool on an external industrial control computer or server. Regardless of the physical deployment form, a tight data interaction loop is established between the configuration processing device and the host computer to ensure that the generated configuration file accurately adapts to the current operating state of the host computer.

[0055] During system operation, the interaction between the configuration processing device and the host computer mainly involves two aspects: automatic acquisition of capability characteristics and accurate loading of configuration files. On one hand, when the host computer starts up or receives a configuration refresh command, it feeds back its current operating status information to the configuration processing device via its internal bus or network interface. This information constitutes the capability characteristics mentioned in the previous embodiments. For example, the host computer can report its firmware version number, a list of activated functional module IDs, and the status of currently connected MVB or Ethernet ports. After receiving this real-time feedback, the configuration processing device inputs it as constraints into the syntax tree pruning module, thereby ensuring that the constructed target syntax tree fully matches the actual hardware and software environment of the host computer, avoiding parsing failures or functional abnormalities caused by mismatch between configuration and device capabilities. On the other hand, the XML configuration file generated by the configuration processing device is transmitted to the host computer via a standardized file transfer protocol or shared memory mechanism. When the built-in XML parsing engine of the host computer loads the file, since the file has undergone lightweight pruning and structural optimization based on the syntax tree, the parser only needs to traverse the valid configuration nodes and does not need to handle a large number of redundant condition branches or empty tags. This significantly reduces CPU usage and memory consumption, effectively solving the problem of slow startup caused by bloated configuration files in traditional host computers.

[0056] Furthermore, the system is specifically optimized for version upgrade scenarios. When the host computer undergoes software iteration, the configuration processing device utilizes an incremental merging mechanism to write only the change nodes required for the new version into the existing configuration file, while fully preserving the personalized parameters debugged on-site. This mechanism fundamentally avoids the risk of data loss caused by full configuration overwrite and solves the problems of business interruption and repeated debugging caused by configuration reset in traditional upgrade processes. In addition, the configuration file, which undergoes structural self-healing and dual verification, ensures good structure at the syntactic level and conforms to the loading specifications of the host computer at the semantic level, further improving the success rate and stability of system upgrades.

[0057] It should be understood that although this embodiment uses a rail transit host computer as an example, the scope of protection of this invention is not limited thereto. In other embodiments, this control system can also be applied to fields such as power monitoring, industrial automation, and medical equipment, as long as it includes the configured device itself and a device with the aforementioned dynamic configuration processing capability. Furthermore, the method by which the configuration processing device generates or updates the configuration file is not limited to online real-time processing; it can also include offline generation of the configuration file and importing it into the host computer via a storage medium. As long as the system architecture includes functional components capable of executing the aforementioned dynamic processing method, regardless of changes in the triggering timing and data transmission path, it should be covered within the scope of protection of this invention.

[0058] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Those skilled in the art should understand that various modifications, equivalent substitutions, or improvements can be made to the present invention without departing from its spirit and principles. For example, the specific syntax format of the XML template, the identification method of logical control nodes, the traversal algorithm for syntax tree difference comparison, the specific rules for structural optimization, and the type of target device, etc., can all be adaptively adjusted or equivalently replaced according to actual business needs. As long as it adopts the core concept of lightweight configuration generation based on syntax tree pruning and incremental updates based on structured comparison, it should be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for dynamically processing configuration files, characterized in that, include: Obtain the XML template and construct a template syntax tree based on the XML template; The capability characteristics of the target device are obtained, and the template syntax tree is pruned based on the capability characteristics to obtain the target syntax tree; In the initial configuration scenario, based on the target syntax tree and the acquired configuration data, an initial XML configuration file for the target device is generated; In the configuration update scenario, the original XML configuration file of the target device and the updated configuration data are compared based on the target syntax tree, the change nodes are extracted, and the incremental change nodes are merged into the original XML configuration file of the target device to obtain the updated XML configuration file.

2. The dynamic processing method for configuration files according to claim 1, characterized in that, The step of pruning nodes in the template syntax tree based on the capability features to obtain the target syntax tree includes: Identify the logical control nodes in the template syntax tree; The execution conditions of the logical control node are evaluated based on the aforementioned capability characteristics; The target syntax tree is obtained by removing the logical control nodes and their associated subtrees that do not meet the execution conditions.

3. The dynamic processing method for configuration files according to claim 2, characterized in that, The logic control node includes a condition judgment node and a loop node; The evaluation of the execution conditions of the logical control node based on the capability characteristics includes: For the condition judgment node, extract the target parameter value from the capability feature, match the target parameter value with the condition expression of each branch of the condition judgment node, and determine the branch that satisfies the condition expression as the target branch. For the loop node, obtain the list data associated with the loop node in the capability features, and determine the data length of the list data as the number of loops; The process of removing logical control nodes and their associated subtrees that do not meet the execution conditions includes: Retain the subtree corresponding to the target branch, and remove the subtrees that are not corresponding to the target branch in the condition judgment node; When the number of iterations is zero, the loop node and all its contained loop subtrees are removed.

4. The dynamic processing method for configuration files according to claim 1, characterized in that, The step of comparing the syntax tree differences between the original XML configuration file and the updated configuration data of the target device based on the target syntax tree, extracting the changed nodes, and incrementally merging the changed nodes into the original XML configuration file of the target device includes: The original XML configuration file of the target device is parsed into a source syntax tree, and an update syntax tree is generated based on the updated configuration data and the target syntax tree; By comparing the node paths and attribute values ​​of the source syntax tree and the updated syntax tree, newly added nodes, deleted nodes, and modified nodes are identified. The order in which the newly added node, the deleted node, and the modified node are merged is determined based on the dependencies between nodes; Node write, removal, and attribute update operations are performed in the source syntax tree according to the merge order.

5. The dynamic processing method for configuration files according to claim 4, characterized in that, After performing node write, removal, and attribute update operations in the source syntax tree according to the merge order, the method further includes: The source syntax tree after the operation is executed is structurally optimized. The structural optimization includes: traversing the source syntax tree after the operation is executed, checking whether the start label and closing label of each node match, and automatically completing the closing label based on the preset syntax rules if the closing label is missing; identifying empty nodes that have no child nodes and no attribute values, and removing the empty nodes from the source syntax tree; and assigning a corresponding number of indentation spaces to each node based on the node's level depth in the source syntax tree to standardize the node indentation format. The optimized source syntax tree is subjected to format verification, which includes verifying whether the serialized file meets the preset syntax specifications and the configuration loading specifications of the target device. If the verification passes, the source syntax tree is serialized into the updated XML configuration file.

6. The dynamic processing method for configuration files according to claim 1, characterized in that, The configuration data is derived from a structured table file; The target device is a rail transit host computer, and the capability characteristics include at least one of the following: host computer version number, supported functional module types, and communication protocol types.

7. A dynamic processing apparatus for configuration files, applicable to the dynamic processing method for configuration files as described in any one of claims 1-6, characterized in that, include: The template parsing module is used to obtain an XML template and construct a template syntax tree based on the XML template. The syntax tree pruning module is used to obtain the capability characteristics of the target device and prune the nodes of the template syntax tree based on the capability characteristics to obtain the target syntax tree; The XML generation module is used to generate the initial XML configuration file of the target device based on the target syntax tree and the acquired configuration data in the initial configuration scenario. The incremental merging module is used to compare the syntax tree differences between the original XML configuration file of the target device and the updated configuration data based on the target syntax tree in the configuration update scenario, extract the changed nodes, and incrementally merge the changed nodes into the original XML configuration file of the target device to obtain the updated XML configuration file.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the dynamic processing method for the configuration file as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the dynamic processing method for the configuration file as described in any one of claims 1 to 6.

10. A host computer control system for rail transit, characterized in that, The system includes a host computer and a dynamic processing device for the configuration file as described in claim 7, wherein the dynamic processing device for the configuration file is configured to generate or update the XML configuration file required for the operation of the host computer.

Images