A cross-system document intelligent coding method and system based on a dynamic rule engine

Abstract

The application discloses a kind of cross-system document intelligent coding method and system based on dynamic rule engine, by obtaining the metadata information of to-be-coded document, call dynamic rule engine from configurable rule base and match coding rule, rule engine supports multi-dimensional condition matching and priority dynamic calculation, and provide visual configuration interface to realize the real-time adjustment and version management of rule;Adopt three-level mapping strategy to convert the metadata of PDMS, BIM, SCADA and other heterogeneous systems into unified equipment and facility list ID without loss, combined with improved Levenshtein distance algorithm to calculate the similarity of equipment name, form the dual conflict detection mechanism of equipment ID accurate matching and equipment name similarity calculation, trigger artificial review when conflict is detected, review result is fed back to knowledge base to realize self-learning optimization, while establishing coding life cycle management;The application realizes the automation, intelligentization and traceability of cross-system document coding, significantly improves coding consistency and standard adaptation efficiency.

Description

Technical Field

[0001] This invention belongs to the field of document encoding technology, and in particular relates to a cross-system intelligent document encoding method and system based on a dynamic rule engine. Background Technology

[0002] In large-scale engineering construction projects, document coding is fundamental to ensuring document uniqueness, traceability, and cross-system sharing. Documents are typically managed using a PDMS system during the design phase, a BIM system during the construction phase, and a SCADA system during the operation and maintenance phase. Each system employs an independent identification system: PDMS uses DesignID + professional code as the core identifier, BIM relies on IfcGUID + component type, and SCADA uses AssetID + equipment number. This heterogeneity leads to inconsistent document coding rules for the same equipment at different stages. For example, the design phase code might be "DES-Wind Turbine-001," the construction phase code might be "CON-Wind Generator-001," and the operation and maintenance phase code might be "OPE-1# Wind Turbine-001." There is a lack of automated correlation mechanisms between the three, relying solely on manual mapping using Excel tables. As projects progress and the number of documents surges, manual coding methods gradually reveal problems such as inefficiency, error-proneness, and lagging standard adaptation. In particular, when international standards such as IEC 61355 update document classifications, existing coding systems require the development of new modules for adaptation, resulting in long response times and severely impacting project schedules. Furthermore, the significant differences in device names make it difficult to detect encoding conflicts, leading to frequent instances of duplicate and incorrect encodings, which poses a major obstacle to subsequent document retrieval and data fusion.

[0003] To address the aforementioned issues, existing technologies primarily employ the following methods: First, manually defining coding rules. Document administrators assign codes to each document based on project phases and professional requirements, recording the correspondence between systems in an Excel spreadsheet. This method lacks flexibility and is prone to information loss due to personnel changes. Second, using simple coding mapping tools to convert metadata from different systems into a unified format according to preset static rules. For example, scripts can be used to extract fixed-position numbers from the DesignID in PDMS and concatenate a fixed prefix as the code; or the first few digits of the IfcGUID in BIM can be hashed and used as the identifier. These tools are typically customized for specific projects and cannot adapt to changing project requirements. Third, conflict detection based on keyword matching is used to determine whether the code is duplicated by comparing strings. However, this method has weak ability to identify variants of device names and has a high false positive rate. Fourth, some professional software has built-in encoding rule bases, but the rule bases are statically configured and cannot be dynamically adjusted. When the IEC61355 standard is updated or the project is adjusted, it is necessary to contact the developer to modify the code, which is time-consuming and labor-intensive. In recent years, a few solutions have also tried to introduce rule engines, but most of them are fixed rule matching, lacking priority dynamic calculation and self-learning optimization mechanisms, making it difficult to cope with complex cross-system encoding scenarios.

[0004] The existing methods described above have significant drawbacks: First, manual coding is inefficient and cannot guarantee consistency across systems, leading to difficulties in document association across design, construction, and operation phases, thus impacting data fusion throughout the entire lifecycle. Second, static rule mapping tools can only handle simple string extraction and cannot cope with complex conversions of heterogeneous metadata. Furthermore, once rules are fixed, they are difficult to adapt to standard updates, requiring redevelopment for each standard change. Third, conflict detection relies solely on string comparison, exhibiting poor recognition capabilities for synonyms and word order variations in device names, resulting in high false negative and false positive rates and significant workload for manual review. Fourth, the lack of knowledge accumulation and self-learning capabilities means that historical conflict cases cannot be used to optimize subsequent detection, hindering continuous improvement in system performance.

[0005] Therefore, based on the aforementioned widespread technical problems, it is necessary to propose a cross-system document intelligent encoding method based on a dynamic rule engine to solve these problems. Summary of the Invention

[0006] The technical problem this invention aims to solve is to provide a cross-system document intelligent coding method based on a dynamic rule engine. By constructing a dynamic rule engine, it supports visual configuration and version management of coding rules, enabling real-time adaptation to standard updates. A three-level mapping strategy is established to losslessly convert heterogeneous metadata into a unified equipment and facility list ID through precise matching, feature extraction, and hash association, supplemented by a metadata dictionary to unify equipment names. An improved Levenshtein distance algorithm is introduced to accurately identify the similarity of equipment names, and a dual verification mechanism is combined to improve conflict detection accuracy. A conflict handling knowledge base is constructed, and self-learning optimization is achieved through manual review and feedback, making the system more accurate with use. Simultaneously, a coding lifecycle management system is established to achieve full-process traceability of coding at each stage of design, construction, and operation and maintenance, fundamentally solving the problems of uniformity and traceability in cross-system document coding.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A cross-system intelligent document encoding method based on a dynamic rule engine includes the following steps: Obtain the metadata information of the document to be encoded, including project stage, responsible specialty, equipment identifier, and document type; Based on metadata information, the dynamic rule engine is invoked to match the corresponding encoding rules from the configurable rule base. The encoding rules define the composition order and value source of each part of the encoding. Based on the matched encoding rules and the cross-system metadata mapping results, the document encoding is generated; The generated document encoding is checked for conflicts, and a manual review process is triggered when a potential conflict is detected. After review, the final document encoding is output and stored in the encoding record library.

[0008] Furthermore, the project phases are divided into one or more of the following according to the ISO21500 standard: initiation phase, planning phase, execution phase, monitoring phase, and closing phase; the responsible disciplines include one or more of the following: electrical, mechanical, and civil engineering; the document types match the document classification system specified in the IEC61355 standard; equipment identifiers are bound to equipment and facility list IDs, and the format of the equipment and facility list IDs is "unit code-system code-equipment code-serial number".

[0009] Preferably, after the system receives the metadata of the document to be encoded, the rule engine executes the following matching process: Metadata standardization: Converting input metadata into an internal standard format; Conditional pre-filtering: Select rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set; Conditional matching calculation: Traverse candidate rules, parse the matching condition expression (condition_expression) of each rule, and compare it item by item with the standardized metadata, including: Stage matching: Checks whether the project stage in the metadata is in the rule's stage list; Professional Matching: Check if the responsible professional profession is in the profession list of the rules; Device type matching: Check if the device type (device_type) is in the rule's device_type list; Document type matching: Checks if the document type doc_type is in the rule's doc_type list; The matching rules use AND logic, meaning that all specified fields must match successfully; if a field in the rule condition is an asterisk or an empty list, it means that no restrictions are set for that field. Priority score calculation: For rules that are a perfect match, the priority score calculation stage begins. The engine calculates the priority score for each rule according to the aforementioned formula based on the preset dimension weight table and matching degree coefficient. At the same time, the basic priority of the rule is considered as an additive: final score = basic priority + priority score. Rule conflict resolution: If the rule with the highest score is unique, it will be adopted directly; if multiple rules have the same score or the score difference is less than a set threshold, the rule conflict resolution mechanism will be triggered. Manual intervention: Push conflict alerts to the administrator, who can then select or confirm the rules online; Automatic arbitration: Makes decisions automatically based on preset arbitration strategies; Record conflicts: Store conflict details and arbitration results in a log for future rule optimization reference; Rule enforcement: After selecting the final rule, the `template_expression` of the rule is parsed, and the value retrieval logic of each node is executed sequentially: Stage code: Retrieve the project stage from the metadata, and convert it by querying the stage code table; Professional Code: Retrieve the responsible professional specialty from the metadata, and then query the professional code table to convert it; Device ID: The device / facility list ID after retrieving metadata mapping; IEC Classification Code: Retrieve the IEC 61355 classification code corresponding to the document type; Serial Number: Query the code record database, get the latest serial number under the same rule and increment it by 1; Rule execution log: The rule ID, version, priority score, execution time, and other information of this match are written to the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

[0010] Preferably, the specific method for calculating the priority score is as follows: When a document satisfies multiple encoding rules, the dynamic rule engine uses the following formula to calculate the priority score for each rule: ; in, The final score is based on rule priority. Let be the weight coefficient of the i-th dimension, and let be the dimension weight coefficient. This includes weighting based on project stage, professional responsibility, equipment type, document type, and equipment importance. The basic priority of the rules is given by n, where n is the number of dimensions involved in the calculation. Let be the matching coefficient for the i-th dimension, calculated according to the following rules: Exact match: The metadata value and the rule condition value are exactly the same. =1.0; Range matching: The rule conditions are range values, and the result is calculated based on the degree to which they are met. When fully satisfied =1.0; if partially satisfied, calculate according to the proportion; Fuzzy matching: The rule conditions are a list of device names, which are calculated after mapping through a metadata dictionary. Direct hit: =1.0; Synonym hit: =0.9; Semantic similarity hit: =0.7; Multi-value matching: The rule condition contains multiple optional values, and the metadata matches any one of them. .

[0011] Furthermore, the dynamic rule engine includes a visual configuration interface for the rule base. Through this interface, administrators can add, modify, or delete coding rules and adjust the priority order of each rule. When the IEC61355 standard is updated or the project phase division is adjusted, the visual configuration interface can adapt to the standard changes in real time without the need to redevelop the coding module.

[0012] Preferably, the cross-system metadata mapping further includes a three-level mapping strategy: The first level is exact matching, which directly matches the standard ID in the equipment and facility list using the equipment identifier; The second level is feature extraction and matching, which uses regular expressions to extract feature values ​​from the source system identifier and match them with the corresponding standard IDs in the equipment and facilities list. The third level is hash association matching, which involves performing a hash operation on the source system identifier, extracting the feature value, and associating it with the corresponding standard ID in the equipment and facility list.

[0013] Preferably, the cross-system metadata mapping further includes configuring a confidence score for each mapping, wherein the confidence score for exact matching is 1.0, the confidence score for feature extraction matching is 0.8, and the confidence score for hash association matching is 0.6; the confidence score is used as a weighting factor in conflict detection.

[0014] Preferably, the cross-system metadata mapping further includes: For the PDMS system, feature values ​​are extracted from DesignID using regular expressions and matched with the corresponding standard IDs in the equipment and facilities list. For BIM systems, ifcGUID is hashed and its characteristic value is extracted and associated with the corresponding standard ID in the equipment and facilities list; For SCADA systems, the device number is extracted from AssetID and matched with the corresponding standard ID in the equipment and facility list; Establish a metadata dictionary, which is used to uniformly map the various names of the same device in different systems to a standard name.

[0015] Preferably, document encoding is generated according to the matched encoding rules, specifically including: Parse the encoding rules to obtain the value order and format requirements of each component of the encoding; Extract project phase codes, professional codes, equipment and facilities list IDs, and IEC61355 classification codes from metadata information; Generate a serial number for the current document within the same category. The serial number is automatically incremented based on the number of codes already generated under the same rule in the encoding record library. Assemble the components according to the order defined by the rules to generate a complete document code.

[0016] Preferably, the format of the coding rule is: project phase code + professional code + equipment and facility list ID + IEC61355 classification code + serial number; or other combinations according to project requirements; the project phase code, professional code and IEC61355 classification code are all converted using a predefined standardized coding table.

[0017] Preferably, the collision detection further includes a dual verification mechanism: The first layer of verification is an exact match of the equipment and facilities list ID. When two documents are associated with the same equipment and facilities list ID, it is directly determined as a duplicate code and the conflict handling process is triggered. The second layer of verification is the device name similarity calculation. An improved Levenshtein distance algorithm is used to calculate the similarity between the name of the device associated with the current document and the device name in the encoded document. When the similarity exceeds a preset threshold, the current encoding is marked as a potential conflict.

[0018] Preferably, the improved Levenshtein distance algorithm is the Damerau-Levenshtein distance algorithm, which incorporates character movement distance into the similarity calculation. For cases where the word order is reversed, the similarity of synonymous inversions is identified by calculating the cost of character swapping operations. Specifically, this includes the following steps: set up a and b Given two strings, with lengths of respectively and For all and ,definition for and The distance between Damerau and Levenshtein; Calculated using the following recursive relation: ; in, These are the cost weights for the four operations: deletion, insertion, replacement, and swapping. This is an indicator function that returns 1 if the characters are not equal, and 0 otherwise. After obtaining the edit distance, convert it into a normalized similarity score: ; The similarity score ranges from [0,1], with a higher score indicating that the two strings are more similar.

[0019] Preferably, the preset threshold is dynamically adjusted through a visual configuration interface; for different device types or different project stages, differentiated similarity thresholds are set, with the initial value of the preset threshold being 85%.

[0020] Preferably, the manual review process further includes: Push conflict warnings and conflict details to document administrators; provide a review interface to display comparison information between the code to be reviewed and the conflict code, including device name, device identifier, document type, and project stage; receive review results input by administrators, including pass, reject, or modify; record the conflict reasons and solutions for each review, and feed the review results back to the conflict handling knowledge base.

[0021] Preferably, the conflict detection algorithm is periodically optimized through self-learning based on the conflict handling knowledge base, including: Analyze the distribution of similarity scores in historical conflict cases and dynamically adjust the similarity threshold; Extract frequently conflicting device name patterns and automatically expand the synonym mapping in the metadata dictionary; For device types with a historical conflict rate higher than a preset threshold, automatically increase their similarity detection threshold; Identify coding rule defects that frequently cause conflicts and generate rule optimization suggestions.

[0022] Preferably, it also includes a code lifecycle management step: Associate each generated code with its lifecycle state, including design phase code, construction phase code, and operation and maintenance phase code; The codes for the same equipment at different stages are linked together using the equipment and facility list ID; Supports code traceability; by entering the code for any stage, you can trace back to the corresponding codes for other stages and the device's entire lifecycle documentation. When the device is upgraded or replaced, it supports the obsolescence of existing codes and the generation of new codes, and records the relationship between code changes.

[0023] Furthermore, the dynamic rule engine includes a rule version management mechanism, which supports versioned rule management, allowing new and old rules to coexist. The validity period configuration enables a smooth transition of standard iterations, avoiding impact on the traceability of historical codes.

[0024] Preferably, a cross-system document intelligent encoding system based on a dynamic rule engine is provided for executing the cross-system document intelligent encoding method based on a dynamic rule engine. The system includes: The metadata acquisition module is used to acquire metadata information of the document to be encoded, including project stage, responsible specialty, equipment identifier and document type; The rules engine module contains a configurable rule library, which is used to match corresponding encoding rules based on metadata information, and provides a visual configuration interface for administrators to dynamically adjust the rules. The metadata mapping module is used to convert heterogeneous metadata from different source systems into a unified equipment and facility inventory standard ID, including a three-level mapping submodule and a metadata dictionary; The encoding generation module is used to generate document encoding based on the matched encoding rules and the mapped metadata; The conflict detection module performs double verification on the generated document encoding, including a device ID precise matching submodule and a device name similarity calculation submodule, and generates warning information when a potential conflict is detected; the conflict detection module includes a threshold dynamic adjustment submodule, which automatically analyzes the similarity score distribution based on historical conflict cases stored in the knowledge base module, and dynamically adjusts the similarity threshold for different device types. The review and processing module provides a manual review interface, receives the review results of the conflict codes from the administrator, and records the cause of the conflict and the solution. The knowledge base module stores coding records and historical conflict resolution cases, forming a conflict resolution knowledge base, and supports self-learning optimization. The lifecycle management module is used to associate codes for each stage of design, construction, and operation and maintenance, and supports full lifecycle traceability. The output module is used to output the final document encoding that has passed the review.

[0025] Preferably, the rules engine module further includes: The metadata processing module is used to convert the input metadata into an internal standard format and filter out rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set. The condition matching calculation module is used to traverse candidate rules, parse the condition_expression of each rule, and compare it item by item with the standardized metadata; The priority score calculation module is used to dynamically calculate the rule priority score based on the weight of project stage, professional responsibility, equipment type, document type, and equipment importance. The rule conflict module is used to execute the rule conflict resolution mechanism when multiple rules have the same score or the score difference is less than a set threshold. It writes information such as the rule ID, version, priority score, and execution time of the matched rule into the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

[0026] Furthermore, it also includes a rule version management submodule to support the coexistence of new and old rules and to achieve a smooth transition of standard iterations through validity period configuration.

[0027] Preferably, a computer device includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the cross-system document intelligent encoding method based on a dynamic rule engine.

[0028] Preferably, a computer-readable storage medium stores computer instructions that cause a computer to execute the cross-system document intelligent encoding method based on a dynamic rule engine.

[0029] The beneficial effects of this invention are as follows: 1. This invention, by constructing a dynamic rule engine and a visual configuration interface, achieves flexible adaptation and real-time effectiveness of coding rules, solving the problems of delayed response to existing technical standard updates and the difficulty in adjusting fixed rules. Specifically, the rule engine supports multi-dimensional condition matching, including project stage, responsible profession, equipment type, and document type, and introduces a dynamic priority calculation mechanism. When the same document meets multiple rules, a score is calculated based on the dimension weight and matching degree coefficient, and the optimal rule is automatically selected. Administrators can add, modify, or disable rules through the visual interface. Rule changes take effect in real time without restarting the system. When the IEC61355 standard is updated, only the rule configuration needs to be adjusted for quick adaptation, significantly shortening the standard iteration cycle and improving the system's flexibility and adaptability.

[0030] 2. This invention significantly improves the accuracy of cross-system metadata conversion and conflict detection precision through a three-level mapping strategy and an improved similarity algorithm, solving the problems of difficulty in identifying equipment name variants and frequent coding conflicts in existing technologies. The three-level mapping strategy, tailored to the identification characteristics of different systems, combines precise matching, feature extraction, and hash association to losslessly convert PDMS's DesignID, BIM's IfcGUID, and SCADA's AssetID into a unified equipment and facility list ID, and assigns a configuration reliability score. The improved Levenshtein distance algorithm introduces adjacent character swapping operations, accurately identifying synonyms with reversed word order, and, combined with alias mapping in the metadata dictionary, forms a dual verification mechanism. Conflict detection is not only based on precise matching of equipment IDs but also identifies potential conflicts through a similarity algorithm. After manual review, feedback is fed back to the knowledge base for self-learning optimization, effectively reducing false positives and false negatives, and ensuring the uniqueness and accuracy of the coding.

[0031] 3. This invention, by constructing a conflict resolution knowledge base and implementing code lifecycle management, achieves system self-learning optimization and full-process traceability, solving the problems of insufficient knowledge accumulation and difficulty in cross-stage document association in existing technologies. The knowledge base module records each conflict detection case and manual review result, periodically analyzes historical data to dynamically adjust the similarity threshold, and automatically expands the synonym mapping of the metadata dictionary, enabling continuous evolution of conflict detection capabilities. The lifecycle management module associates codes generated at each stage of design, construction, and operation and maintenance through equipment and facility list IDs, supporting the input of codes from any stage to trace the entire lifecycle documents of equipment. When equipment is upgraded or replaced, the code change relationship can be recorded to ensure the integrity of the document history. This mechanism lays a solid foundation for data fusion and intelligent analysis throughout the entire project lifecycle. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the process of the present invention; Figure 2 This is a schematic diagram of the system architecture of the present invention; Figure 3 This is a schematic diagram of a computer device in an embodiment of the present invention. Detailed Implementation

[0033] Example 1: like Figure 1 As shown, a cross-system document intelligent encoding method based on a dynamic rule engine includes the following steps: Obtain the metadata information of the document to be encoded, including project stage, responsible specialty, equipment identifier, and document type; Based on metadata information, the dynamic rule engine is invoked to match the corresponding encoding rules from the configurable rule base. The encoding rules define the composition order and value source of each part of the encoding. Based on the matched encoding rules and the cross-system metadata mapping results, the document encoding is generated; The generated document encoding is checked for conflicts, and a manual review process is triggered when a potential conflict is detected. After review, the final document encoding is output and stored in the encoding record library.

[0034] Furthermore, the project phases are divided into one or more of the following according to the ISO21500 standard: initiation phase, planning phase, execution phase, monitoring phase, and closing phase; the responsible disciplines include one or more of the following: electrical, mechanical, and civil engineering; the document types match the document classification system specified in the IEC61355 standard; equipment identifiers are bound to equipment and facility list IDs, and the format of the equipment and facility list IDs is "unit code-system code-equipment code-serial number".

[0035] Preferably, after the system receives the metadata of the document to be encoded, the rule engine executes the following matching process: Metadata standardization: Converting input metadata into an internal standard format; for example, mapping "wind turbine equipment" to the standard equipment type "wind_turbine" through a metadata dictionary; Conditional pre-filtering: Select rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set; Conditional matching calculation: Traverse candidate rules, parse the matching condition expression (condition_expression) of each rule, and compare it item by item with the standardized metadata, including: Stage matching: Checks whether the project stage in the metadata is in the rule's stage list; Professional Matching: Check if the responsible professional profession is in the profession list of the rules; Device type matching: Check if the device type (device_type) is in the rule's device_type list; Document type matching: Checks if the document type doc_type is in the rule's doc_type list; The matching rules use AND logic, meaning that all specified fields must match successfully; if a field in the rule condition is an asterisk or an empty list, it means that no restrictions are set for that field. Priority score calculation: For rules that are a perfect match, the priority score calculation stage begins. The engine calculates the priority score for each rule according to the aforementioned formula based on the preset dimension weight table and matching degree coefficient. At the same time, the basic priority of the rule is considered as an additive: final score = basic priority + priority score. Rule conflict resolution: If the rule with the highest score is unique, it will be adopted directly; if multiple rules have the same score or the score difference is less than a set threshold, the rule conflict resolution mechanism will be triggered. Manual intervention: Push conflict alerts to the administrator, who can then select or confirm the rules online; Automatic arbitration: Makes decisions automatically based on preset arbitration strategies; Record conflicts: Store conflict details and arbitration results in a log for future rule optimization reference; Rule enforcement: After selecting the final rule, the `template_expression` of the rule is parsed, and the value retrieval logic of each node is executed sequentially: Stage code: Retrieve the project stage from the metadata, and convert it by querying the stage code table; Professional Code: Retrieve the responsible professional specialty from the metadata, and then query the professional code table to convert it; Device ID: The device / facility list ID after retrieving metadata mapping; IEC Classification Code: Retrieve the IEC 61355 classification code corresponding to the document type; Serial Number: Query the code record database, get the latest serial number under the same rule and increment it by 1; Rule execution log: The rule ID, version, priority score, execution time, and other information of this match are written to the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

[0036] Preferably, the specific method for calculating the priority score is as follows: When a document satisfies multiple encoding rules, the dynamic rule engine uses the following formula to calculate the priority score for each rule: ; in, The final score is based on rule priority. Let be the weight coefficient of the i-th dimension, and let be the dimension weight coefficient. This includes weighting based on project stage, professional responsibility, equipment type, document type, and equipment importance. The basic priority of the rules is given by n, where n is the number of dimensions involved in the calculation. Let be the matching coefficient for the i-th dimension, calculated according to the following rules: Exact match: The metadata value and the rule condition value are exactly the same. =1.0; Range matching: The rule conditions are range values, and the result is calculated based on the degree to which they are met. When fully satisfied =1.0; if partially satisfied, calculate according to the proportion; Fuzzy matching: The rule conditions are a list of device names, which are calculated after mapping through a metadata dictionary. Direct hit: =1.0; Synonym hit: =0.9; Semantic similarity hit: =0.7, calculated based on the improved Damerau-Levenshtein distance algorithm; Multi-value matching: The rule condition contains multiple optional values, and the metadata matches any one of them. .

[0037] Furthermore, the dynamic rule engine includes a visual configuration interface for the rule base. Through this interface, administrators can add, modify, or delete coding rules and adjust the priority order of each rule. When the IEC61355 standard is updated or the project phase division is adjusted, the visual configuration interface can adapt to the standard changes in real time without the need to redevelop the coding module.

[0038] Preferably, the cross-system metadata mapping further includes a three-level mapping strategy: The first level is exact matching, which directly matches the standard ID in the equipment and facility list using the equipment identifier; The second level is feature extraction and matching, which uses regular expressions to extract feature values ​​from the source system identifier and match them with the corresponding standard IDs in the equipment and facilities list. The third level is hash association matching, which involves performing a hash operation on the source system identifier, extracting the feature value, and associating it with the corresponding standard ID in the equipment and facility list.

[0039] Preferably, the cross-system metadata mapping further includes configuring a confidence score for each mapping, wherein the confidence score for exact matching is 1.0, the confidence score for feature extraction matching is 0.8, and the confidence score for hash association matching is 0.6; the confidence score is used as a weighting factor in conflict detection.

[0040] Preferably, the cross-system metadata mapping further includes: For the PDMS system, feature values ​​are extracted from DesignID using regular expressions and matched with the corresponding standard IDs in the equipment and facilities list. For BIM systems, ifcGUID is hashed and its characteristic value is extracted and associated with the corresponding standard ID in the equipment and facilities list; For SCADA systems, the device number is extracted from AssetID and matched with the corresponding standard ID in the equipment and facility list; Establish a metadata dictionary, which is used to uniformly map the various names of the same device in different systems to a standard name.

[0041] Preferably, document encoding is generated according to the matched encoding rules, specifically including: Parse the encoding rules to obtain the value order and format requirements of each component of the encoding; Extract project phase codes, professional codes, equipment and facilities list IDs, and IEC61355 classification codes from metadata information; Generate a serial number for the current document within the same category. The serial number is automatically incremented based on the number of codes already generated under the same rule in the encoding record library. Assemble the components according to the order defined by the rules to generate a complete document code.

[0042] Preferably, the format of the encoding rule is: project phase code + professional code + equipment and facility list ID + IEC61355 classification code + serial number; or other combination orders customized according to project requirements; the project phase code, professional code, and IEC61355 classification code are all converted using a predefined standardized coding table.

[0043] Preferably, the conflict detection further includes a double-check mechanism: The first check is an exact match of the equipment and facility list ID. When two documents are associated with the same equipment and facility list ID, it is directly determined that the encoding is repeated and the conflict handling process is triggered; The second check is the calculation of the similarity of equipment names. The improved Levenshtein distance algorithm is used to calculate the similarity between the name of the equipment associated with the current document and the equipment names in the already encoded documents. When the similarity exceeds the preset threshold, the current encoding is marked as a potential conflict.

[0044] Preferably, the improved Levenshtein distance algorithm is the Damerau-Levenshtein distance algorithm, which incorporates the character movement distance into the similarity calculation. For the case of reversed word order, the similarity of synonymous reversed expressions is identified by calculating the cost of character swapping operations.

[0045] The traditional Levenshtein distance algorithm has limitations. In the scenario of intelligent encoding of cross-system documents, the differences in the expressions of equipment names are one of the main reasons for encoding conflicts; for example, for the same wind turbine unit, it may be marked as "wind turbine" in the PDMS system during the design phase, "wind power generator" in the BIM system during the construction phase, and "No. 1 wind turbine" in the SCADA system during the operation and maintenance phase; although these names are expressed differently, they refer to the same physical equipment and must be identified as an associated relationship during encoding generation.

[0046] The traditional Levenshtein distance algorithm measures the string similarity by calculating the minimum number of operations of insertion, deletion, and replacement. However, this algorithm has obvious defects when dealing with the case of reversed word order. For example, for the two strings "wind turbine" and "turbine wind", the calculation process of the traditional Levenshtein distance is as follows: "wind turbine" → "turbine wind": It is necessary to delete the first character "wind" (1 operation), and then insert "wind" at the end (1 operation), and the total edit distance is 2; if calculated by character replacement: replace "wind" with "turbine" once and replace "turbine" with "wind" once, and the distance 2 is also obtained; Intuitively, humans would think that "wind turbine" and "turbine wind" are just the reversal of the order of two characters and should have a high degree of similarity. The limitation of traditional algorithms is that they break down a single adjacent character swap into two independent operations, underestimating the true similarity between strings and resulting in a high false positive rate in device name conflict detection.

[0047] To solve the above problems, this embodiment uses the Damerau-Levenshtein distance algorithm as an improved similarity calculation method. Based on the three operations of the traditional Levenshtein algorithm: insertion, deletion, and substitution, this algorithm adds an adjacent character swap operation, allowing a single adjacent character swap to be counted as one edit operation.

[0048] Algorithm definition: Given two strings s1 and s2, the Damerau-Levenshtein distance d(s1, s2) is defined as the minimum number of operations required to convert s1 into s2, and the allowed operations include: Insertion: Insert a character at any position; Deletion: Delete a character at any position; Substitution: Replace a character at any position with another character; Swap: Swap the positions of any two adjacent characters.

[0049] By introducing the swap operation, the algorithm can more accurately reflect humans' intuitive judgment of string similarity. For example, to convert "wind turbine" to "turbine wind", only one adjacent character swap operation is required, and the edit distance is 1, resulting in a significantly improved similarity score.

[0050] The Damerau-Levenshtein distance algorithm specifically includes the following steps: Let a and b be two strings with lengths and respectively; for all and , define as the Damerau-Levenshtein distance between and ; Calculate through the following recurrence relation: ; where are the cost weights of the four operations of deletion, insertion, substitution, and swap respectively, is an indicator function that takes 1 when the characters are not equal and 0 otherwise; After obtaining the edit distance, convert it into a normalized similarity score: ; The similarity score ranges from [0,1], with a higher score indicating that the two strings are more similar.

[0051] Preferably, the preset threshold is dynamically adjusted through a visual configuration interface; for different device types or different project stages, differentiated similarity thresholds are set, with the initial value of the preset threshold being 85%.

[0052] Taking common equipment name variations in wind power projects as an example, the recognition performance of the traditional Levenshtein algorithm and the improved algorithm is compared in Table 1 below: Table 1: Recognition performance of the traditional Levenshtein algorithm and the improved algorithm;

[0053] As can be seen from the data in Table 1, for scenarios where the word order is reversed, such as "wind turbine" and "machine wind", the similarity score of the improved algorithm increased from 0.33 to 0.67, which is more in line with human intuitive judgment; for partial swaps of longer strings, such as "main transformer" and "transformer main", the improved algorithm can accurately identify it as a swap operation, and the score is significantly improved; for scenarios without swaps, the improved algorithm and the traditional algorithm produce the same results, maintaining compatibility.

[0054] Preferably, the manual review process further includes: Push conflict warnings and conflict details to document administrators; provide a review interface to display comparison information between the code to be reviewed and the conflict code, including device name, device identifier, document type, and project stage; receive review results input by administrators, including pass, reject, or modify; record the conflict reasons and solutions for each review, and feed the review results back to the conflict handling knowledge base.

[0055] Preferably, the conflict detection algorithm is periodically optimized through self-learning based on the conflict handling knowledge base, including: Analyze the distribution of similarity scores in historical conflict cases and dynamically adjust the similarity threshold; Extract frequently conflicting device name patterns and automatically expand the synonym mapping in the metadata dictionary; For device types with a historical conflict rate higher than a preset threshold, automatically increase their similarity detection threshold; Identify coding rule defects that frequently cause conflicts and generate rule optimization suggestions.

[0056] Preferably, it also includes a code lifecycle management step: Associate each generated code with its lifecycle state, including design phase code, construction phase code, and operation and maintenance phase code; The codes for the same equipment at different stages are linked together using the equipment and facility list ID; Supports code traceability; by entering the code for any stage, you can trace back to the corresponding codes for other stages and the device's entire lifecycle documentation. When the device is upgraded or replaced, it supports the obsolescence of existing codes and the generation of new codes, and records the relationship between code changes.

[0057] Furthermore, the dynamic rule engine includes a rule version management mechanism, which supports versioned rule management, allowing new and old rules to coexist. The validity period configuration enables a smooth transition of standard iterations, avoiding impact on the traceability of historical codes.

[0058] Example 2: like Figure 2 As shown, this embodiment provides a cross-system intelligent document encoding system based on a dynamic rule engine. It adopts a B / S architecture, with the backend developed using the Spring Boot framework and the frontend using Vue.js to build a visual configuration interface. The core modules of the system include a metadata collection module, a rule engine module, a metadata mapping module, an encoding generation module, a conflict detection module, a review processing module, a knowledge base module, a lifecycle management module, and an output module. All modules communicate via a RESTful API, and data storage uses a combination of a MySQL relational database, a Redis cache, and an Elasticsearch search engine.

[0059] The system is used to execute the cross-system document intelligent encoding method based on a dynamic rule engine. The system includes: The metadata acquisition module is used to obtain metadata information of the documents to be encoded. This metadata information includes project stage, responsible specialty, equipment identifier, and document type. The metadata acquisition module is provided externally via a Web Service interface, supporting systems such as PDMS, BIM, and SCADA to push metadata via HTTP POST. The interface receives data in JSON format. The module performs format validation and integrity checks on the received metadata, returning error codes and logging when necessary fields are missing. Validated metadata is encapsulated into a unified internal data object, MetaData, and passed to the rule engine module. Simultaneously, the raw metadata is stored in the `raw_metadata` table in MySQL for easy traceability.

[0060] The rules engine module contains a configurable rule library, which is used to match corresponding encoding rules based on metadata information, and provides a visual configuration interface for administrators to dynamically adjust the rules.

[0061] The metadata mapping module is used to convert heterogeneous metadata from different source systems into a unified equipment and facility inventory standard ID, including a three-level mapping submodule and a metadata dictionary; The encoding generation module is used to generate document encoding based on the matched encoding rules and the mapped metadata; The conflict detection module performs double verification on the generated document encoding, including a device ID precise matching submodule and a device name similarity calculation submodule, and generates warning information when a potential conflict is detected; the conflict detection module includes a threshold dynamic adjustment submodule, which automatically analyzes the similarity score distribution based on historical conflict cases stored in the knowledge base module, and dynamically adjusts the similarity threshold for different device types. The review and processing module provides a manual review interface, receives the review results of the conflict codes from the administrator, and records the cause of the conflict and the solution. The knowledge base module stores coding records and historical conflict resolution cases, forming a conflict resolution knowledge base, and supports self-learning optimization. The lifecycle management module is used to associate codes for each stage of design, construction, and operation and maintenance, and supports full lifecycle traceability. The output module is used to output the final document encoding that has passed the review.

[0062] Preferably, the rules engine module further includes: The metadata processing module is used to convert the input metadata into an internal standard format and filter out rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set. The condition matching calculation module is used to traverse candidate rules, parse the condition_expression of each rule, and compare it item by item with the standardized metadata; The priority score calculation module is used to dynamically calculate the rule priority score based on the weight of project stage, professional responsibility, equipment type, document type, and equipment importance. The rule conflict module is used to execute the rule conflict resolution mechanism when multiple rules have the same score or the score difference is less than a set threshold. It writes information such as the rule ID, version, priority score, and execution time of the matched rule into the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

[0063] Furthermore, it also includes a rule version management submodule to support the coexistence of new and old rules and to achieve a smooth transition of standard iterations through validity period configuration.

[0064] Taking the operation and maintenance phase of a wind power project as an example, the specific process is as follows: Metadata collection: SCADA system pushes document metadata: {"sourceSystem":"SCADA","stage":"execution","profession":"electrical","deviceId":"OPE-WT-5678-SCADA","deviceName":"1# fan","docType":"maintenance record"}.

[0065] Metadata Mapping: The metadata mapping module extracts “5678” from OPE-WT-5678-SCADA through feature extraction, matches the equipment facility list ID WT-EL-MA-5678, with a confidence level of 0.8.

[0066] Rule matching: The rule engine matched the rule "Operation and Maintenance Electrical Equipment Coding Rules" (version v2.1), with a priority score of 18.5, and it was selected as the only one.

[0067] Encoding generation: Generate the encoding "OPE-EL-WT-EL-MA-5678-M01-0036" based on the template {stage_code}-{prof_code}-{device_id}-{iec_code}-{seq}.

[0068] Conflict Detection: Device ID WT-EL-MA-5678 already contains the code "OPE-EL-WT-EL-MA-5678-M01-0035", triggering the first level of conflict; simultaneously, the similarity between the device name "1# Wind Turbine" and "Wind Generator Set" is calculated to be 0.92 > 85% using the improved Levenshtein, triggering the second level of conflict. The system generates an alert and pushes a review task.

[0069] Manual review: The administrator confirmed that the two codes point to the same device, but the serial numbers are different. This is a normal new version. The administrator selected "Pass" and noted "New document on the same device, serial number increments".

[0070] Output encoding: The system outputs the final encoding and stores it in the encoding record library; the review record is stored in the knowledge base.

[0071] Preferably, a computer device includes a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the cross-system document intelligent encoding method based on a dynamic rule engine.

[0072] Preferably, a computer-readable storage medium stores computer instructions that cause a computer to execute the cross-system document intelligent encoding method based on a dynamic rule engine.

[0073] Example 3: This embodiment provides a specific method for calling a dynamic rule engine to match corresponding encoded rules from a configurable rule base: A dynamic rule engine is a software component that can dynamically parse, match, and execute coded rules based on input parameters at runtime. Its core feature lies in the "dynamic" nature of the rules, which is reflected in the following three aspects: 1. Dynamic loading of rules: Traditional rule engines typically compile rules into fixed code or configuration files, requiring a system restart to modify them. This invention employs a dynamic rule engine based on hot-loading technology. Rules are stored in a database as structured data, and the engine reads the latest rules in real-time with each encoding request. Rule modifications take effect without requiring a service restart. Specifically, Redis is used to cache rule data, combined with a database change monitoring mechanism. When an administrator modifies rules through a visual interface, the cache is automatically updated, ensuring rule changes take effect within seconds.

[0074] 2. Dynamic parsing of rules: The engine has a built-in rule parser that parses rule definitions stored in the database, such as "stage code + professional code + device ID + category code + serial number," into executable encoded instructions. The parser employs an interpreter design pattern, splitting the rule string into an abstract syntax tree and traversing the tree to execute the value retrieval logic of each node sequentially. For example, when parsing the "stage code" node, the engine automatically extracts the project stage field from the metadata and maps it to a predefined stage code table, such as "execution stage" mapping to "OPE."

[0075] 3. Dynamic priority calculation of rules: The engine has a multi-rule conflict resolution mechanism. When the same document satisfies multiple rules, such as when the same document matches both "General Electrical Engineering Rules" and "Wind Turbine Equipment Specific Rules", the engine does not simply rely on a preset order, but dynamically calculates the priority score of each rule.

[0076] Dimension weights include: Project phase weights: Initiation 0.8, Planning 0.6, Execution 1.0, Monitoring 0.7, Closure 0.5, which can be adjusted according to project importance; Professional weights: Electrical 1.0, Mechanical 0.9, Civil Engineering 0.8, etc.; Equipment type weights: Core equipment 1.0, Auxiliary equipment 0.7, General equipment 0.5; Rule specificity coefficients: General rules 0.6, Special rules 1.0.

[0077] The matching score reflects the degree of match between the metadata and the rule conditions. A perfect match is 1.0, while a partial match is calculated based on the number of matched fields. For example, matching 3 fields scores 0.8. The engine selects the rule with the highest score for execution and records the score in the log for administrator auditing.

[0078] 4. Dynamic version management of rules: The engine has a built-in version controller, with each rule associated with a version number and validity period. When the IEC61355 standard is updated, administrators can create new version rules and set their effective start time; older version rules automatically become invalid or are retained until their expiration date. When executing rules, the engine automatically selects the valid version based on the current time, ensuring that historical coding traceability is not affected.

[0079] A configurable rule base refers to a rule storage and management system that stores coded rule definitions in structured data form and provides a visual configuration interface. Its core feature lies in the "configurability" of the rules, which is reflected in the following aspects: 1. Data structure of the rule base: The rule base is stored in a relational database, and the core table structure is shown in Table 2 below: Table 2: Core table structure of the rule base;

[0080] 2. Visual configuration interface for the rule base: The system provides a web-based rule configuration interface, which includes the following functional modules: Rule list view: Displays all rules in a table format, supports filtering by stage, specialty, and status, and displays key information such as rule name, version, validity period, and priority.

[0081] Rule creation / editing interface: Employs a dual-mode system of form and JSON editor. Regular administrators can select conditions such as stage, specialty, and equipment type via dropdown menus, and the system automatically generates conditional expressions. Advanced administrators can directly edit JSON conditional expressions to implement complex logical combinations. Coding templates support drag-and-drop assembly; administrators can drag fields such as stage code, specialty code, and equipment ID from the left-hand "Field Library" to the right-hand template area, and the system automatically generates template expressions.

[0082] Rule priority configuration: Offers two methods for adjusting basic priority: slider and numerical input. It also supports a "rule conflict simulation" function; by inputting test metadata, the system displays the current rule matching results and priority scores in real time, helping administrators verify the configuration's effectiveness.

[0083] Rule version management: Each rule displays a version history icon on the right. Clicking it allows you to view all historical versions and change records, and supports version comparison and rollback operations.

[0084] Rule activation simulation: Input a future date, and the system will simulate the activation status of the rules on that date to ensure that there are no gaps or overlaps when switching between old and new rules.

[0085] 3. Dynamic expansion mechanism of the rule base: The rule base not only supports the configuration of encoding rules, but also supports the following extended capabilities: Custom field extension: Administrators can add custom metadata fields through the interface, such as "voltage level" and "installation location". New fields are automatically added to the field library and can be referenced in the coding template.

[0086] External data source access: The rule base supports accessing equipment classification data from external systems such as ERP and MES, enabling dynamic updates of equipment types. For example, when ERP adds a "energy storage equipment" category, the rule base automatically synchronizes and can be used as a rule condition option.

[0087] Rule Template Library: Built-in industry-standard rule templates, which can be directly imported when starting a new project, reducing the workload of configuring from scratch.

[0088] Example 4: This embodiment provides a specific implementation process for calculating priority scores: Metadata for the document to be encoded: Project phase = "Execution phase", Specialty = "Electrical", Equipment = "Fan", Document type = "Maintenance record"; The two candidate rules are shown in Table 3 below: Table 3: Candidate Rules;

[0089] Step 1: Determine the weighting coefficients, using the default weights: Project phase weight W1=0.8; Responsible specialty weight W2=0.7; Equipment type weight W3=1.0; Document type weight W4=0.6; Step 2: Calculate the matching degree of rule A: Phase Matching: Execute Phase Matching Rule A for “Execution Phase”, M1=1.0; Professional Matching: Electrical matches “Electrical”, M2=1.0; Equipment Matching: Fan matches “Fan”, M3=1.0; Document Type: Rule A has no restrictions, considered a complete match, M4=1.0; Score for Rule A: P A =(0.8×1.0)+(0.7×1.0)+(1.0×1.0)+(0.6×1.0)+10; PA = 0.8 + 0.7 + 1.0 + 0.6 + 10 = 13.1; Step 3: Calculate the matching degree of rule B: Stage Matching: Rule B is unrestricted and considered a complete match, M1=1.0; Professional Matching: Electrical matches "Electrical", M2=1.0; Equipment Matching: Fan does not match "Transformer", M3=0; Document Type: Maintenance Record matches "Maintenance Record", M4=1.0; Score for Rule B: PB=(0.8×1.0)+(0.7×1.0)+(1.0×0)+(0.6×1.0)+15; PB = 0.8 + 0.7 + 0 + 0.6 + 15 = 17.1; Step 4: Rule Selection: Rule B scores 17.1, which is higher than Rule A's score of 13.1. Therefore, the engine selects Rule B to execute. Although the device conditions for Rule B do not match, its basic priority is higher and other dimensions match perfectly, reflecting the administrator's intention to prioritize specific rules for "maintenance record" type documents.

[0090] Example 5: Taking a wind power project as an example, the project has a construction period of 36 months, involving 5,000 PDMS system documents in the design phase, 8,000 BIM system documents in the construction phase, and 12,000 SCADA system documents in the operation and maintenance phase. The equipment types include wind turbines, substations, submarine cables, etc., and there are many synonyms and variations in equipment names. The coding generation and conflict detection were carried out using manual coding, static rule tools, basic RAG scheme, and the method of this invention, respectively. The comparison results are shown in Table 4 below: Table 4: Comparison of the method of the present invention with existing technical methods;

[0091] As shown in Table 4 above, this method significantly outperforms existing technologies in all indicators. The coding generation speed reaches 1200 copies / person / day, which is 24 times faster than manual coding, 6 times faster than static rule tools, and 2.4 times faster than the basic RAG scheme. This is attributed to the automated matching of the dynamic rule engine and the efficient conversion of the three-level mapping strategy. Cross-system coding consistency reaches 99.5%, near perfect, proving that the three-level mapping strategy and metadata dictionary effectively solve the problem of heterogeneous device identifiers, ensuring consistent coding for the same device at all stages. The conflict detection accuracy is 98.2%, far exceeding existing technologies. The improved Levenshtein algorithm and dual verification mechanism accurately identify device name variations, and combined with knowledge base self-learning, significantly reduce false alarms. The standard update adaptation cycle is only 0.5 days, and administrators can complete rule adjustments through a visual interface, while existing technologies require a 15-30 day development cycle, demonstrating the flexibility of the dynamic rule engine. The manual review rate is reduced to 5%, greatly alleviating the burden on administrators. With a 99% success rate in code traceability, the lifecycle management module seamlessly links documents across design, construction, and operation phases, providing a high-quality data foundation for subsequent data analysis and intelligent operation and maintenance. In summary, this invention comprehensively addresses the pain points of cross-system document coding through innovative technologies such as a dynamic rule engine, intelligent mapping, and conflict self-learning, achieving efficient, accurate, and traceable intelligent code management.

[0092] Example 6: like Figure 3 As shown, this embodiment of the invention also provides a computer device, which includes one or more processors 10, a memory 20, and interfaces for connecting the various components, including high-speed interfaces and low-speed interfaces. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory for displaying graphical information of a GUI on external input / output devices, such as display devices coupled to the interfaces. In some alternative embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations, for example, as a server array, a group of blade servers, or a multiprocessor system. Figure 3 Take a processor 10 as an example.

[0093] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0094] The memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

[0095] The memory 20 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the computer device. Furthermore, the memory 20 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, the memory 20 may optionally include memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0096] The memory 20 may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0097] The computer device also includes a communication interface 30 for communicating with other devices or communication networks.

[0098] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded via a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the processes shown in the above embodiments are implemented.

Claims

1. A cross-system intelligent document encoding method based on a dynamic rule engine, characterized in that, Includes the following steps: Obtain the metadata information of the document to be encoded, including project stage, responsible specialty, equipment identifier, and document type; Based on metadata information, the dynamic rule engine is invoked to match the corresponding encoding rules from the configurable rule base. The encoding rules define the composition order and value source of each part of the encoding. Based on the matched encoding rules and the cross-system metadata mapping results, the document encoding is generated; The generated document encoding is checked for conflicts, and a manual review process is triggered when a potential conflict is detected. After review, the final document encoding is output and stored in the encoding record library.

2. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 1, characterized in that, Once the system receives the metadata of the document to be encoded, the rule engine executes the following matching process: Metadata standardization: Converting input metadata into an internal standard format; Conditional pre-filtering: Select rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set; Conditional matching calculation: Traverse candidate rules, parse the matching condition expression (condition_expression) of each rule, and compare it item by item with the standardized metadata, including: Stage matching: Checks whether the project stage in the metadata is in the rule's stage list; Professional Matching: Check if the responsible professional profession is in the profession list of the rules; Device type matching: Check if the device type (device_type) is in the rule's device_type list; Document type matching: Checks if the document type doc_type is in the rule's doc_type list; The matching rules use AND logic, meaning that all specified fields must match successfully; if a field in the rule condition is an asterisk or an empty list, it means that no restrictions are set for that field. Priority score calculation: For rules that are a perfect match, the priority score calculation stage begins. The engine calculates the priority score for each rule according to the aforementioned formula based on the preset dimension weight table and matching degree coefficient. At the same time, the basic priority of the rule is considered as an additive: final score = basic priority + priority score. Rule conflict resolution: If the rule with the highest score is unique, it will be adopted directly; if multiple rules have the same score or the score difference is less than a set threshold, the rule conflict resolution mechanism will be triggered. Manual intervention: Push conflict alerts to the administrator, who can then select or confirm the rules online; Automatic arbitration: Makes decisions automatically based on preset arbitration strategies; Record conflicts: Store conflict details and arbitration results in a log for future rule optimization reference; Rule enforcement: After selecting the final rule, the `template_expression` of the rule is parsed, and the value retrieval logic of each node is executed sequentially: Stage code: Retrieve the project stage from the metadata, and convert it by querying the stage code table; Professional Code: Retrieve the responsible professional specialty from the metadata, and then query the professional code table to convert it; Device ID: The device / facility list ID after retrieving metadata mapping; IEC Classification Code: Retrieve the IEC 61355 classification code corresponding to the document type; Serial Number: Query the code record database, get the latest serial number under the same rule and increment it by 1; Rule execution log: The rule ID, version, priority score, execution time, and other information of this match are written to the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

3. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 2, characterized in that, The specific method for calculating priority scores is as follows: When a document satisfies multiple encoding rules, the dynamic rule engine uses the following formula to calculate the priority score for each rule: ； in, The final score is based on rule priority. Let be the weight coefficient of the i-th dimension, and let be the dimension weight coefficient. This includes weighting based on project stage, professional responsibility, equipment type, document type, and equipment importance. The basic priority of the rules is given by n, where n is the number of dimensions involved in the calculation. Let be the matching coefficient for the i-th dimension, calculated according to the following rules: Exact match: The metadata value and the rule condition value are exactly the same. =1.0; Range matching: The rule conditions are range values, and the result is calculated based on the degree to which they are met. When fully satisfied =1.0; if partially satisfied, calculate according to the proportion; Fuzzy matching: The rule conditions are a list of device names, which are calculated after mapping through a metadata dictionary. Direct hit: =1.0; Synonym hit: =0.9; Semantic similarity hit: =0.7; Multi-value matching: The rule condition contains multiple optional values, and the metadata matches any one of them. 。 4. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 1, characterized in that, The cross-system metadata mapping further includes a three-level mapping strategy: The first level is exact matching, which directly matches the standard ID in the equipment and facility list using the equipment identifier; The second level is feature extraction and matching, which uses regular expressions to extract feature values ​​from the source system identifier and match them with the corresponding standard IDs in the equipment and facilities list. The third level is hash association matching, which involves performing a hash operation on the source system identifier, extracting the feature value, and associating it with the corresponding standard ID in the equipment and facility list.

5. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 4, characterized in that, The cross-system metadata mapping further includes configuring a confidence score for each mapping, wherein the confidence score for exact matching is 1.0, the confidence score for feature extraction matching is 0.8, and the confidence score for hash association matching is 0.6; the confidence score is used as a weighting factor in conflict detection.

6. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 4, characterized in that, The cross-system metadata mapping further includes: For the PDMS system, feature values ​​are extracted from DesignID using regular expressions and matched with the corresponding standard IDs in the equipment and facilities list. For BIM systems, ifcGUID is hashed and its characteristic value is extracted and associated with the corresponding standard ID in the equipment and facilities list; For SCADA systems, the device number is extracted from AssetID and matched with the corresponding standard ID in the equipment and facility list; Establish a metadata dictionary, which is used to uniformly map the various names of the same device in different systems to a standard name.

7. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 1, characterized in that, The document encoding is generated based on the matched encoding rules, specifically including: Parse the encoding rules to obtain the value order and format requirements of each component of the encoding; Extract project phase codes, professional codes, equipment and facilities list IDs, and IEC61355 classification codes from metadata information; Generate a serial number for the current document within the same category. The serial number is automatically incremented based on the number of codes already generated under the same rule in the encoding record library. Assemble the components according to the order defined by the rules to generate a complete document code.

8. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 7, characterized in that, The format of the coding rule is: Project Phase Code + Professional Code + Equipment and Facility List ID + IEC61355 Classification Code + Serial Number; or other combinations and orders customized according to project requirements; Project Phase Code, Professional Code and IEC61355 Classification Code are all converted using a predefined standardized coding table.

9. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 1, characterized in that, The collision detection further includes a dual verification mechanism: The first layer of verification is an exact match of the equipment and facilities list ID. When two documents are associated with the same equipment and facilities list ID, it is directly determined as a duplicate code and the conflict handling process is triggered. The second layer of verification is the device name similarity calculation. An improved Levenshtein distance algorithm is used to calculate the similarity between the name of the device associated with the current document and the device name in the encoded document. When the similarity exceeds a preset threshold, the current encoding is marked as a potential conflict.

10. A cross-system document intelligent encoding method based on a dynamic rule engine according to claim 9, characterized in that, The improved Levenshtein distance algorithm is the Damerau-Levenshtein distance algorithm, which incorporates character movement distance into similarity calculation. For cases where the word order is reversed, it identifies the similarity of synonymous inversions by calculating the cost of character swapping operations. Specifically, it includes the following steps: set up a and b Given two strings, with lengths of respectively and For all and ,definition for and The distance between Damerau and Levenshtein; Calculated using the following recursive relation: ； in, These are the cost weights for the four operations: deletion, insertion, replacement, and swapping. This is an indicator function that returns 1 if the characters are not equal, and 0 otherwise. After obtaining the edit distance, convert it into a normalized similarity score: ； The similarity score ranges from [0,1], with a higher score indicating that the two strings are more similar.

11. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 9, characterized in that, The preset threshold can be dynamically adjusted through a visual configuration interface; different similarity thresholds are set for different device types or different project stages.

12. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 11, characterized in that, The manual review process further includes: Push conflict warnings and conflict details to document administrators; provide a review interface to display comparison information between the code to be reviewed and the conflict code, including device name, device identifier, document type, and project stage; receive review results input by administrators, including pass, reject, or modify; record the conflict reasons and solutions for each review, and feed the review results back to the conflict handling knowledge base.

13. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 12, characterized in that, Based on the aforementioned conflict resolution knowledge base, the conflict detection algorithm is periodically optimized through self-learning, including: Analyze the distribution of similarity scores in historical conflict cases and dynamically adjust the similarity threshold; Extract frequently conflicting device name patterns and automatically expand the synonym mapping in the metadata dictionary; For device types with a historical conflict rate higher than a preset threshold, automatically increase their similarity detection threshold; Identify coding rule defects that frequently cause conflicts and generate rule optimization suggestions.

14. The cross-system document intelligent encoding method based on a dynamic rule engine according to claim 1, characterized in that, It also includes code lifecycle management steps: Associate each generated code with its lifecycle state, including design phase code, construction phase code, and operation and maintenance phase code; The codes for the same equipment at different stages are linked together using the equipment and facility list ID; Supports code traceability; by entering the code for any stage, you can trace back to the corresponding codes for other stages and the device's entire lifecycle documentation. When the device is upgraded or replaced, it supports the obsolescence of existing codes and the generation of new codes, and records the relationship between code changes.

15. A cross-system document intelligent encoding system based on a dynamic rule engine, used to execute the cross-system document intelligent encoding method based on a dynamic rule engine as described in any one of claims 1-14, characterized in that the system... include: The metadata acquisition module is used to acquire metadata information of the document to be encoded, including project stage, responsible specialty, equipment identifier and document type; The rules engine module contains a configurable rule library, which is used to match corresponding encoding rules based on metadata information, and provides a visual configuration interface for administrators to dynamically adjust the rules. The metadata mapping module is used to convert heterogeneous metadata from different source systems into a unified equipment and facility inventory standard ID, including a three-level mapping submodule and a metadata dictionary; The encoding generation module is used to generate document encoding based on the matched encoding rules and the mapped metadata; The conflict detection module is used to perform double verification on the generated document encoding, including a device ID precise matching submodule and a device name similarity calculation submodule, and generates warning information when a potential conflict is detected. The conflict detection module includes a threshold dynamic adjustment submodule, which is used to automatically analyze the similarity score distribution based on historical conflict cases stored in the knowledge base module and dynamically adjust the similarity threshold for different device types. The review and processing module provides a manual review interface, receives the review results of the conflict codes from the administrator, and records the cause of the conflict and the solution. The knowledge base module stores coding records and historical conflict resolution cases, forming a conflict resolution knowledge base, and supports self-learning optimization. The lifecycle management module is used to associate codes for each stage of design, construction, and operation and maintenance, and supports full lifecycle traceability. The output module is used to output the final document encoding that has passed the review.

16. A cross-system document intelligent encoding system based on a dynamic rule engine according to claim 15, characterized in that, The rules engine module further includes: The metadata processing module is used to convert the input metadata into an internal standard format and filter out rules from the rule base that are enabled, have a current date within the validity period, and have a basic priority higher than a preset threshold as a candidate set. The condition matching calculation module is used to traverse candidate rules, parse the condition_expression of each rule, and compare it item by item with the standardized metadata; The priority score calculation module is used to dynamically calculate the rule priority score based on the weight of project stage, professional responsibility, equipment type, document type, and equipment importance. The rule conflict module is used to execute the rule conflict resolution mechanism when multiple rules have the same score or the score difference is less than a set threshold. It writes information such as the rule ID, version, priority score, and execution time of the matched rule into the log table to form a rule execution trajectory for subsequent auditing and optimization analysis.

17. A computer device, characterized in that, It includes a memory and a processor, which are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the cross-system document intelligent encoding method based on the dynamic rule engine as described in any one of claims 1 to 14.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the cross-system document intelligent encoding method based on a dynamic rule engine as described in any one of claims 1 to 14.

Images