Incremental reloading method and system for structured archive

Abstract

The invention discloses a structured archive increment reloading method and system, and the method comprises the steps: reading the latest version of a stored project, and comparing the latest version of the stored project with the current version of a currently running project; based on a version comparison result, an object which changes between the current version of the project and the latest version of the project is screened out from an object modification record table, an incremental change data set is constructed, and the construction step comprises object-level change screening, modification object content-level difference positioning and change influence network construction; executing a corresponding data change operation according to the incremental change data set; and after the change operation is completed, updating the current version of the project to the latest version of the project. According to the method, only the changed data in the configuration archive is loaded, the changed data is fused into the currently running archive system, the loading time consumption is short, and as only the changed data is loaded, the impact on system resources can be reduced, the stability and the performance of the system can be improved, and timely updating of the data can be ensured.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and in particular to an incremental reloading method and system for structured archiving. Background Technology

[0002] In the field of control systems, the data archive generated during the configuration process is called a configuration archive. This configuration archive needs to be deployed to the runtime system for debugging and operation. Structured archives adapt to the strong regularity of configuration data, support precise data location and extraction, and can support the real-time and efficient parsing requirements of the runtime. Furthermore, its standard format allows for easy data transfer and sharing between different software or systems, providing cross-system compatibility. Therefore, configuration archives are typically structured archives. After configuration and deployment are completed, the runtime system loads the configuration archive, executes control tasks according to the preset configuration logic, and provides feedback on the operational status. Simultaneously, engineers adjust and optimize the configuration archive based on the operational status, re-deploy the configuration archive, and then have the runtime system load and run it, forming a closed loop of "configuration-operation-optimization." During debugging, very frequent modification and deployment operations are required. If the runtime system were to perform a full reload of the configuration archive each time—that is, regardless of whether the data has changed, loading the complete configuration archive into memory or storage at once, completely overwriting the old version data—it would be time-consuming, repeatedly loading unchanged data, consuming redundant system resources, and hindering debugging and system stability.

[0003] The Chinese patent document "A Configuration Update Method, Apparatus, Electronic Device, and Storage Medium for a Cloud-based Control System," publication number CN120711054A, published on September 26, 2025, describes a cloud-based control system comprising a communication card and multiple controllers connected to the communication card. The specific update scheme involves responding to a system configuration update request by downloading configuration update information to the communication card, enabling the communication card to perform a configuration update operation based on this information. Simultaneously, while the communication card performs the configuration update, configuration update information is synchronously sent to each controller via multicast, allowing the controllers to synchronously perform configuration update operations based on this information. After the communication card completes sending the configuration update information, multicast data transmission resumes immediately. This technology enables synchronous configuration updates between the communication card and controllers in a very short time, thereby resolving the problem of abnormal input / output data jumps during the configuration update process of the cloud-based control system and avoiding threats to the stable operation of industrial systems. However, this technology addresses system stability issues by mitigating abnormal jumps in input and output data. Its specific configuration update method remains a full update mode, which cannot overcome the problems of long loading times, redundant system resources, and difficulties in debugging and system stability when repeatedly loading unchanged data during full updates. Summary of the Invention

[0004] This invention aims to overcome the problems in existing technologies where full reloading of configuration archives during debugging and operation requires repeatedly loading unchanged data, which is time-consuming, consumes redundant system resources, and is detrimental to debugging and system stability. It provides an incremental reloading method and system for structured archives.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: An incremental reloading method for structured archives includes: Read the latest version of the stored project and compare it with the current version of the currently running project; Based on the version comparison results, objects that have changed between the current version of the project and the latest version of the project are selected from the object modification record table, and an incremental change dataset is constructed. The construction steps include object-level change filtering, modification object content-level difference location, and change impact network construction. Execute the corresponding data change operation based on the incremental change dataset; After completing the change operation, update the current version of the project to the latest version.

[0006] This invention transforms the traditional full data overwrite mode into a precise incremental update mode through a read-compare-build-execute-update process, solving the core problems of time-consuming full reload and redundant system resource consumption mentioned in the background technology. Because it only processes changed data, the impact on critical resources such as memory, CPU, and I / O of the runtime system is minimized, improving system stability. This is crucial for control systems requiring high availability and continuity, ensuring smooth system operation during data updates. From version comparison to the final update of the current version, an automated and self-consistent closed-loop management process is formed. Based on the closed-loop and reliable nature of the process, errors that may be caused by human operation are avoided, and the consistency between the system state and the data version after each reload is ensured.

[0007] Preferably, the version comparison is based on the project version number; the project version number is generated when the configuration software is released, with an initial value of 0, and increments by 1 with each release. The object modification record table records the object modification records for each release of the project; the latest version of the project is read from the project version information table.

[0008] Preferably, the version comparison results include: If the current version of the project is the same as the latest version of the project, then there is no need to reload; If the current version number of the project is less than the latest version number of the project, then incremental reload will be executed; If the current version number of the project is greater than the latest version number of the project, or if the project version number is abnormal, then a full reload will be performed.

[0009] Preferably, the object-level change filtering includes: Filter modification records of the target type based on object type; Filter records where the project version number is greater than the current project version and less than or equal to the latest project version; Filter the record with the highest object version number among the modified objects; Based on the modification identifier, objects are categorized and stored in the new object set, deleted object set, or modified object set.

[0010] Preferably, the modified object content-level difference location includes: The structured data of the object is parsed into a hierarchical node model, the model nodes are traversed, and the changes of each field in the old and new versions are compared. Changes are categorized into critical and non-critical modifications based on the semantic role of the fields; critical modifications trigger a full object replacement, while non-critical modifications only update the changed fields.

[0011] As a preferred approach, if the changed field is a structured field, the structured data of that field is parsed into a hierarchical node model, the changes of each subfield in the old and new versions are recursively compared, the changes of the subfields are classified, and corresponding modifications are made according to the classification of the subfields.

[0012] Preferably, the changes affecting network construction include: Parent-child hierarchy propagation: During deletion, child objects are recursively traversed downwards and marked as deleted; during addition, ancestor objects are traced upwards and missing parent objects are filled in and marked as added. Instantiation relationship synchronization: When a template object is modified, all corresponding instantiated objects are marked as modified; Conflict resolution: When there are multiple tags for the same object, they are processed in descending order of priority: addition, deletion, and modification.

[0013] An incremental reload system for structured archiving includes: The version comparison module reads and compares the latest version number of the project with the current version number of the project, triggering the incremental reload process. The incremental change dataset construction module filters and analyzes changed objects from the object modification record table based on the version comparison results to construct the incremental change dataset. The change operation execution module performs data change operations based on the incremental change dataset. The version update module updates the current version of the project to the latest version after the change operation is completed.

[0014] Preferably, the incremental change dataset construction module includes: The difference analysis unit performs object-level change filtering and modifies the object content-level difference location. Modify network units, construct the network affected by the changes, and integrate the logic for handling parent-child hierarchical relationships and instantiation relationships.

[0015] As a preferred option, it also includes a data generation module that interacts with the configuration software, which generates a new project version number, new version data of the modified objects, object modification record data, and project version information after the configuration software releases the project. The object modification record data is stored in the object modification record table, and the project version information is stored in the project version information table.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. Improve system stability and performance: Only the changed data is integrated into the currently running data system, the loading time is short, and the conflict and impact on the current system are reduced.

[0017] 2. Supports cross-version release reload: Regardless of the release frequency, by analyzing the modification records between the current project version and the latest version, it can incrementally reload all the changes between the two versions at once, without having to iterate and reload version by version, thus improving update efficiency and flexibility. Attached Figure Description

[0018] Figure 1 This is a flowchart of an incremental reloading method for structured archiving in this invention.

[0019] Figure 2 This is a schematic diagram illustrating the modification of object content-level difference positioning in this invention.

[0020] Figure 3 This is a schematic diagram illustrating how changes affect the network in this invention. Detailed Implementation

[0021] The present invention will now be further described with reference to the accompanying drawings and specific embodiments.

[0022] like Figure 1 As shown, an incremental reloading method for structured archiving includes: Read the latest version of the stored project and compare it with the current version of the currently running project; Based on the version comparison results, objects that have changed between the current version of the project and the latest version of the project are selected from the object modification record table, and an incremental change dataset is constructed. The construction steps include object-level change filtering, modification object content-level difference location, and change impact network construction. Execute the corresponding data change operation based on the incremental change dataset; After completing the change operation, update the current version of the project to the latest version.

[0023] This invention transforms the traditional full data overwrite mode into a precise incremental update mode through a read-compare-build-execute-update process, solving the core problems of time-consuming full reload and redundant system resource consumption mentioned in the background technology. Because it only processes changed data, the impact on critical resources such as memory, CPU, and I / O of the runtime system is minimized, improving system stability. This is crucial for control systems requiring high availability and continuity, ensuring smooth system operation during data updates. From version comparison to the final update of the current version, an automated and self-consistent closed-loop management process is formed. Based on the closed-loop and reliable nature of the process, errors that may be caused by human operation are avoided, and the consistency between the system state and the data version after each reload is ensured.

[0024] The method of this invention requires generating structured archived project version data after release, and then reloading the data according to the project version during runtime to quickly identify archive differences between different versions, thereby accurately locating the incrementally modified structured object data. Structured archives refer to data organized and stored according to a predefined format and structure, where each data unit contains multiple fields, each with a specific data type and meaning. Incremental reloading refers to updating only the changed data during data processing, rather than reloading and updating all data.

[0025] After release, structured archive data is generated. That is, after adding, modifying, or deleting objects in the configuration software, the project release is executed, which requires generating a new project version number, new version data of the modified structured object data, object modification record data, and project version information.

[0026] The project version number is generated when the configuration software is released, with an initial value of 0. After each release, the current version number plus 1 is used as the new project version number. The object ID is used as a unique identifier to identify objects. After release, a new object version number is generated for all modified objects. The object version number is initially 0, and after each modification, the current version number plus 1 is used as the new object version number.

[0027] The new version data for an object includes the object ID, the new version number, and the new structure data. Object modification record data includes the new project version number, object ID, new version number, object type (control modules, equipment modules, control units, process units, service nodes, controllers, communication modules, etc., are all objects in a project, and these objects are classified by object type), and the object's modification identifier, which is divided into three types: added, modified, and deleted. Project version information includes the latest project version number after each release and the project release time.

[0028] During system startup, an object modification record table and a project version information table are created in the storage space. The object modification record table records object modification data for each project release, while the project version information table records the project version information after each release.

[0029] After configuration is published, the new version data of modified objects is updated to the runtime storage space according to their original data structure, forming the new version data for the entire project together with the data of unmodified objects. The object modification record data published during configuration is stored as row data in the object modification record table (row data is the smallest data unit in a database table used to store complete information about a single entity or event; one object modification record is one row of data in the object modification record table). The project version information published during configuration is stored as row data in the project version information table.

[0030] Before reloading a project version, the version numbers of the two versions are compared. If they match, no reload is needed. If the latest version number is less than the current version number, a full reload is performed, and the current version is updated to the latest version. Conversely, if the latest version number is greater than the current version number, an incremental reload is performed. For incremental reload, the changed objects are first identified between the latest and current versions, and an incremental change dataset is built based on their change records. Based on this dataset, corresponding add, modify, or delete operations are performed to complete all incremental changes; after completion, the current version is updated to the latest version.

[0031] Other existing methods for achieving incremental reload include: full data comparison, which compares all data across the entire project to obtain a list of modified objects, and then processes each modified object individually to achieve incremental data reload. Event-driven logging treats each data modification (addition, deletion, update) as an independent event. This event is immediately sent to a central message queue. The runtime system, acting as a consumer, continuously listens to the queue, and upon receiving an event, parses its content and executes the corresponding data reload operation. This approach has lower control precision, relies on successful event capture and transmission, and may face challenges such as eventual consistency and event order disorder in distributed systems. It also has higher system complexity, requiring the introduction and maintenance of distributed components such as message queues and event consumers, resulting in a more complex architecture. Furthermore, it requires the configuration software to have event generation and push capabilities.

[0032] The incremental reloading method for structured archiving in this invention loads only the changed data in the configuration archive, integrating the changed data into the currently running archive system. This results in a short loading time. Because only changed data is loaded, it reduces the impact on system resources, improving system stability and performance. Simultaneously, it ensures timely data updates.

[0033] In addition to an incremental reloading method for structured archives, this invention also discloses an incremental reloading system for structured archives, comprising: The version comparison module reads and compares the latest version number of the project with the current version number of the project, triggering the incremental reload process. The incremental change dataset construction module filters and analyzes changed objects from the object modification record table based on the version comparison results to construct the incremental change dataset. The change operation execution module performs data change operations based on the incremental change dataset. The version update module updates the current version of the project to the latest version after the change operation is completed.

[0034] By using functional modularization and high cohesion, the system encapsulates incremental overload logic into independent modules with clearly defined responsibilities, reducing system complexity, facilitating independent development, testing, deployment, and maintenance, and improving the system's scalability and maintainability.

[0035] In addition, the incremental reload system also includes a data generation module that interacts with the configuration software. After the configuration software publishes the project, it generates a new project version number, new version data of the modified objects, object modification record data, and project version information. Object modification records are stored in the object modification record table, and project version information is stored in the project version information table.

[0036] By integrating the data generation module into the system as a whole, a complete solution is formed. This enables a seamless automated pipeline from the configuration phase (release) to the runtime phase (reload), reducing manual intervention, lowering the probability of errors, and making incremental reload a standard and reliable infrastructure capability.

[0037] The incremental change dataset building module includes: The difference analysis unit performs object-level change filtering and modifies the object content-level difference location. Modify network units, construct the network affected by the changes, and integrate the logic for handling parent-child hierarchical relationships and instantiation relationships.

[0038] The internal units of the incremental change dataset construction module are further divided. Through separation of responsibilities and performance optimization, the difference analysis unit focuses on calculating and filtering the minimum change set, while the change network unit focuses on ensuring data correlation. This separation allows for targeted optimization of the two computationally intensive tasks, further improving the overall performance of the system.

[0039] As a specific implementation, the incremental reloading method for structured data based on version data of structured object archives includes the following steps.

[0040] S101: Project Version Comparison. The runtime system stores the current version of the loaded, running project, while the latest version of the project is stored in the project version information table within the runtime storage space. The latest version of the project is read from the project version information table and compared with the current project version. If the project version number of the current project version matches the latest project version, no reload is needed; if the project version number of the current project version is less than the latest project version, an incremental reload is performed; if the project version number of the current project version is greater than the latest project version (e.g., storage space data has been cleared) or the project version number of the current project version is abnormal (e.g., the current project version is not recorded), a full reload is triggered. When a full reload is triggered, the latest project version recorded in the project version information table is used as the target for reload.

[0041] Incremental reloading can be divided into two parts: building the incremental change dataset and executing the change operation.

[0042] S102: Constructing the Incremental Change Dataset. All identified newly added, modified, and deleted objects are stored in three datasets: ObjectAddMap (for new objects), ObjectDeleteMap (for deleted objects), and ObjectModifyMap (for modified objects). This process sequentially includes three main steps: object-level change filtering, content-level difference localization of modified objects, and construction of a change impact network.

[0043] S201: Object-level Change Filtering. Filter object modification records from the object modification record table based on the target object type. The runtime system consists of different runtime services, each requiring different object types. Filtering by object type allows for quick selection of the required object type. For example, diagnostic services require loading device objects such as controllers and communication modules; alarm services require loading factory domain objects such as control modules, equipment modules, control units, and process units.

[0044] Filter modification records between the current project version and the latest project version based on the project version number, and select all records with project version numbers greater than the current project version and less than or equal to the latest project version; filter the latest modification records of objects based on the object version, that is, the records with the largest object version number.

[0045] Incremental comparison is achieved by comparing all modification records between the current and latest versions of the project, eliminating the need for a full comparison of all project data between the current and latest versions. For example, if a project has 100 objects and has been released 5 times (i.e., 5 versions), with only one object modified each time, and a certain running node only has data from version 2 and needs to be updated to version 5, filtering modification records only requires comparing the three modified objects from versions 3 to 5. Directly comparing versions 2 and 5 would require comparing all 100 objects.

[0046] After filtering is completed, the objects are categorized and stored in ObjectAddMap, ObjectDeleteMap, or ObjectModifyMap based on the modification identifier of the filtered objects.

[0047] S202: Modify object content-level difference positioning. For example... Figure 2 As shown, if an object is modified, the new version of the object's data is loaded from the storage space based on the object's ID, and a detailed attribute comparison is performed based on the object's original data structure to conduct a multi-dimensional difference analysis.

[0048] S202.01: Parse the structured data of an object into a hierarchical node model, and compare the value changes of each field in the old and new versions by traversing the model nodes.

[0049] S202.02: Based on the semantic role of fields, such as required attributes and dependencies, categorize field value changes into critical and non-critical modifications. Critical modifications are major changes that require a full object replacement. For example, if an object's encoding is modified (the encoding is the object's identifier attribute), and the system cannot recognize the object based on the original encoding, the original object must be deleted and then reloaded based on the new version of the object to completely replace the old version. For this type of modification, the object must be removed from the modified object dataset ObjectModifyMap and stored in both the deleted object dataset ObjectDeleteMap and the added object dataset ObjectAddMap. Non-critical modifications only require replacing the changed fields. For example, if the object's description is modified, it does not affect system operation; only the description attribute value needs to be updated. For this type of modification, the object must be stored in the modified object dataset ObjectModifyMap, and the list of modified attributes of the object must be recorded and stored.

[0050] S202.03: Recursive Difference Analysis of Structured Fields. If the field is structured data, such as a control module, it includes field codes, descriptions, variables, and alarms. Codes and descriptions are basic data types, while variables and alarms are structured data types. This is because variables themselves also contain attributes such as codes, descriptions, and initial values. For structured fields, steps S202.01-S202.02 are applied recursively. First, referring to step S202.01, the structured data of the field is parsed into hierarchical nodes. By traversing the model nodes, the value changes of each sub-field in the old and new versions are compared. Then, referring to step S202.02, the value changes of the sub-fields are categorized. For critical modifications to the sub-fields, the sub-fields are added to the field's delete and add attribute list; for non-critical modifications to the sub-fields, the sub-fields are added to the field's modified attribute list.

[0051] S203: Changes affect network architecture. For example... Figure 3 As shown, by parsing the relationships between objects (parent-child hierarchy, instantiation dependencies), a change impact propagation network is constructed to ensure that change operations are accurately transmitted along the relationship chain and to avoid missing any modified objects.

[0052] S203.01: Changes in Parent-Child Hierarchical Relationships. For parent-child hierarchical relationships between objects, when the system has specific object loading conditions, such as the system exposing object data externally through OPCUA services, an additional list of exposed objects needs to be configured based on the original project data. Simultaneously, the system needs to load the complete object hierarchy structure (the object hierarchy structure is configured in the configuration software; for example, two control modules A and B can be grouped as siblings, i.e., A and B are parallel, or they can be grouped as parent and child). Managing objects in a hierarchical manner means that the addition and deletion of objects are also affected by their parent and child hierarchical objects, as well as the objects in their parent and child hierarchical levels. This is handled according to the principle of "parent deletes, child follows; child adds, parent creates."

[0053] The downward propagation of deletion operations: When a parent object is marked for deletion, the process recursively traverses down the hierarchy, simultaneously marking all its child and descendant objects for deletion and storing them in the ObjectDeleteMap dataset.

[0054] Upward tracing of new operations: When a new child object is added, its ancestor chain is traced backward. If any parent object is not loaded into the system (e.g., not initialized or deleted), it is automatically marked as a new object and stored in the new object dataset ObjectAddMap, thus ensuring the continuity and integrity of the hierarchical structure. Upward tracing only completes missing ancestor objects and does not affect the state of existing parent objects.

[0055] View objects in a parent-child hierarchy as a tree structure, where parent and child objects can be of different types. For example, the parent object could be an equipment module, and the child object could be a control module. Modifying the parent object's properties (such as the permissions of a variable) will not affect the child object; however, deleting the parent object will affect the child object, which must also be deleted.

[0056] When recursively traversing descendant objects or tracing the ancestor chain, if a circular dependency is detected, the traversal or tracing is terminated. A circular dependency refers to a cyclic relationship between objects, such as the parent-child relationship A→B→C→A formed between objects A, B, and C. Detecting circular dependencies here is to prevent abnormal scenarios such as dirty data.

[0057] S203.02: Synchronization of Instantiation Relationship Changes. For the instantiation relationship between objects, that is, using object A as a template to create n objects B, C, etc., each instantiated object B, C, etc., possesses all the attributes of object A, and their attribute values ​​are strongly bound to the template. Due to this strong attribute binding, changes to the template object's attributes will cause changes to the instantiated objects as well. Therefore, when template object A is modified, all instantiated objects created based on that template (such as B, C, etc.) are marked as modified and entered into the modified object dataset ObjectModifyMap. Simultaneously, referring to the modified object content-level difference location in step S202, the list of modified attributes of the instantiated objects is recorded.

[0058] S203.03: Conflict Resolution for Multiple Tags: When the same object is assigned multiple tags, to ensure data integrity, the following priority is applied: "Add" takes precedence over "Delete" over "Modify". Add takes precedence: If an object is marked for both addition and deletion, it is considered not deleted. Delete takes precedence: Deletion operations overwrite modifications, avoiding invalid updates. Modification takes precedence: This only applies when there are no structural changes.

[0059] S103: Based on the object modification type in the incremental change dataset, perform addition, deletion and modification processing respectively to achieve accurate implementation of change data.

[0060] S301: Execution of deletion operation. Iterate through all objects marked for deletion in the ObjectDeleteMap dataset. Remove the corresponding data entity from system memory or persistent storage based on its unique identifier (object id), and trigger cleanup logic for related data (such as removing dependencies, updating indexes, etc.) to ensure data integrity. Specifically, for example, if a control module object previously loaded by the OPCUA service needs to be deleted, the object's data entity needs to be removed from memory, and the variables, alarms, and other data contained within the object also need to be cleaned up. Furthermore, the OPCUA node data created for it in the address space also needs to be cleaned up, and the address space updated.

[0061] S302: Modification operation execution. The system iterates through the modified objects recorded in the ObjectModifyMap dataset, updating only the explicitly changed fields in their "attribute modification list" to avoid full overwrite. Incremental update instructions are dynamically generated by comparing the differences between the old and new versions of the data, minimizing resource overhead.

[0062] S303: Execution of New Operations. Extract the identifier of the new object from the ObjectAddMap dataset, load its new version data into the runtime environment, and execute initialization logic (such as resource allocation) to integrate the new object into the current system data structure. Specifically, for example, if the OPCUA service loads a new control module object, its basic information needs to be loaded into memory, a corresponding OPCUA node needs to be created in the address space, and the corresponding object attributes need to be filled into the node attributes.

[0063] S104: Update the current version of the project. After processing all modified objects, the current version of the project in the runtime system is updated to the latest version and stored.

[0064] The above embodiments are further elaborations and descriptions of the present invention to facilitate understanding, and are not intended to limit the present invention in any way. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An incremental reloading method for structured archiving, characterized in that, include: Read the latest version of the stored project and compare it with the current version of the currently running project; Based on the version comparison results, objects that have changed between the current version of the project and the latest version of the project are selected from the object modification record table, and an incremental change dataset is constructed. The construction steps include object-level change filtering, modification object content-level difference location, and change impact network construction. Execute the corresponding data change operation based on the incremental change dataset; After completing the change operation, update the current version of the project to the latest version.

2. The incremental reloading method for structured archiving according to claim 1, characterized in that, The version comparison is based on the project version number; the project version number is generated when the configuration software is released, with an initial value of 0, and increments by 1 with each release. The object modification record table records the object modification records for each release of the project; the latest version of the project is read from the project version information table.

3. The incremental reloading method for structured archiving according to claim 1 or 2, characterized in that, The version comparison results include: If the current version of the project is the same as the latest version of the project, then there is no need to reload; If the current version number of the project is less than the latest version number of the project, then incremental reload will be executed; If the current version number of the project is greater than the latest version number of the project, or if the project version number is abnormal, then a full reload will be performed.

4. The incremental reloading method for structured archiving according to claim 1 or 2, characterized in that, The object-level change filtering includes: Filter modification records of the target type based on object type; Filter records where the project version number is greater than the current project version and less than or equal to the latest project version; Filter the record with the highest object version number among the modified objects; Based on the modification identifier, objects are categorized and stored in the new object set, deleted object set, or modified object set.

5. The incremental reloading method for structured archiving according to claim 4, characterized in that, The modified object content-level difference location includes: The structured data of the object is parsed into a hierarchical node model, the model nodes are traversed, and the changes of each field in the old and new versions are compared. Changes are categorized into critical and non-critical modifications based on the semantic role of the fields; critical modifications trigger a full object replacement, while non-critical modifications only update the changed fields.

6. The incremental reloading method for structured archiving according to claim 5, characterized in that, If the field that is changing is a structured field, the structured data of that field is parsed into a hierarchical node model. The changes of each subfield in the old and new versions are recursively compared, and the changes of the subfields are classified and modified accordingly.

7. The incremental reloading method for structured archiving according to claim 1, 2, 5, or 6, characterized in that, The changes affect network construction in the following ways: Parent-child hierarchy propagation: During deletion, child objects are recursively traversed downwards and marked as deleted; during addition, ancestor objects are traced upwards and missing parent objects are filled in and marked as added. Instantiation relationship synchronization: When a template object is modified, all corresponding instantiated objects are marked as modified; Conflict resolution: When there are multiple tags for the same object, they are processed in descending order of priority: addition, deletion, and modification.

8. A structured archive incremental reloading system, applicable to the incremental reloading method as described in any one of claims 1-7, characterized in that, include: The version comparison module reads and compares the latest version number of the project with the current version number of the project, triggering the incremental reload process. The incremental change dataset construction module filters and analyzes changed objects from the object modification record table based on the version comparison results to construct the incremental change dataset. The change operation execution module performs data change operations based on the incremental change dataset. The version update module updates the current version of the project to the latest version after the change operation is completed.

9. The incremental reloading system for structured archiving according to claim 8, characterized in that, The incremental change dataset construction module includes: The difference analysis unit performs object-level change filtering and modifies the object content-level difference location. Modify network units, construct the network affected by the changes, and integrate the logic for handling parent-child hierarchical relationships and instantiation relationships.

10. An incremental reloading system for structured archiving according to claim 8 or 9, characterized in that, It also includes a data generation module that interacts with the configuration software, which generates a new project version number, new version data of modified objects, object modification record data, and project version information after the configuration software publishes the project. The object modification record data is stored in the object modification record table, and the project version information is stored in the project version information table.

Images