Nuclear power station code analysis method and device and electronic equipment
By combining the Drools engine with a pre-defined encoding rule base, the rule conflict problem in SSC encoding parsing of nuclear power plants was solved, achieving highly accurate encoding parsing results and ensuring the consistency and reliability of the parsing results.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-26
- Publication Date
- 2026-04-10
AI Technical Summary
Existing technologies suffer from rule conflicts in the parsing of SSC codes in nuclear power plants, leading to erroneous parsing results and affecting the accuracy of the parsing.
The Drools engine is used for encoding segmentation and parsing, and a preset encoding rule library is used for parsing to ensure that each segment number corresponds to a unique semantic and structural format. Combined with a visual interface, rule conflict detection and deep comparison are performed to generate accurate parsing results.
This improves the accuracy of nuclear power plant code parsing, avoids erroneous parsing caused by rule conflicts, and ensures the consistency and reliability of parsing results.
Smart Images

Figure CN121835599A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of encoding processing technology, specifically relating to a method, apparatus, and electronic equipment for encoding parsing in nuclear power plants. Background Technology
[0002] Rule engines like Drools can automatically identify the meaning of each field in an SSC (Structure System Component) code through a predefined set of rules (such as numbering structure specifications, field meanings, and naming logic). They can also perform semantic decomposition of the code to determine whether it conforms to standardization requirements. Therefore, it is widely used in standardized classification and cataloging systems for asset management (such as aerospace and nuclear power).
[0003] Currently, when parsing SSC codes for nuclear power plants using a rule engine, there is a problem of incorrect parsing results caused by rule conflicts, which affects the accuracy of nuclear power plant code parsing. Therefore, further optimization is needed. Summary of the Invention
[0004] The technical problem to be solved by this application is to provide a nuclear power plant code parsing method, apparatus and electronic equipment to address the above-mentioned shortcomings of the existing technology. Using the nuclear power plant code parsing method, the accuracy of nuclear power plant code parsing is improved.
[0005] In a first aspect, embodiments of this application provide a nuclear power plant code parsing method, including: Obtain at least one target code to be parsed; the target code is the SSC code for structure, system, and component. The target code is segmented and cut according to the field segment number structure using a rule engine, generating multiple fields; Each field is parsed according to the preset encoding rule library to generate the corresponding parsing results; there are no rule conflicts in the preset encoding rule library, and each field corresponding to each segment number is configured with a unique semantic and structural format.
[0006] In some implementations of the first aspect, the rule engine is the Drools engine; the field segment number structure includes predefined field lengths and delimiters; The target code is segmented and cut using a rule engine based on the field segment number structure, generating multiple fields, including: The Drools engine is used to segment the target encoding according to the field length and delimiter, generating multiple fields.
[0007] In some implementations of the first aspect, each field is parsed according to a preset encoding rule library to generate corresponding parsing results, including: Determine the registered field definitions in the preset encoding rule library that match each field; Determine whether the corresponding field meets the rule requirements based on the registered field definition; If it is determined that the rule requirements are met, the standard semantic definition and corresponding field name are extracted from the preset encoding rule library; The standard semantic definition, field name, field content, and segment number of each field are combined to generate the parsing result.
[0008] In some implementations of the first aspect, before parsing each field according to a preset encoding rule library and generating the corresponding parsing result, the method further includes: In response to the user's coding rule creation operation in the visual rule configuration interface, an initial coding rule library is generated; Each field rule in the initial encoding rule base is converted into a format statement supported by the Drools engine to generate a preset encoding rule base; The Drools engine is used to load a preset encoding rule library, and rule conflict detection is performed on all fields in the preset encoding rule library to generate corresponding rule conflict detection results. If the rule conflict detection result is that there is no rule conflict, then the step of parsing each field according to the preset encoding rule library and generating the corresponding parsing result will be executed.
[0009] In some implementations of the first aspect, rule conflict detection is performed on all fields in the preset encoding rule base, and corresponding rule conflict detection results are generated, including: Cross-semantic comparison is performed on the segment numbers of all fields in the preset encoding rule library. If two segment numbers assign different semantics to the same field, a semantic conflict is determined. The character set settings of all segment numbers in the preset encoding rule library are compared. If the character sets of two segment numbers partially overlap and their corresponding semantic meanings are also different, then a potential ambiguity problem is identified. Perform a duplicate check on all fields of the rules in the preset encoding rule base. If duplicate rules are found, then a duplicate rule problem is identified. Generate corresponding rule conflict detection results.
[0010] In some implementations of the first aspect, after generating the corresponding rule conflict detection result, the method further includes: The result of the rule conflict detection is displayed in a view in the preset graphical interface; The system will display the rule conflict detection results to the user.
[0011] In some implementations of the first aspect, after parsing each field according to a preset encoding rule library and generating the corresponding parsing result, the method further includes: The parsing results are compared in depth using a historical standard encoding library to generate corresponding comparison results; the deep comparison includes field quantity consistency comparison, field order consistency comparison, and field value semantic consistency comparison. If the comparison result meets the structural anomaly condition, the target code is marked as structural anomaly.
[0012] In some implementations of the first aspect, after parsing each field according to a preset encoding rule library and generating the corresponding parsing result, the method further includes: Based on the parsing results, determine the matching historical standard codes from the historical standard code library; Determine the differences between the parsing results and historical standard codes; Generate and suggest corresponding corrections based on the differences.
[0013] In some implementations of the first aspect, after combining the standard semantic definitions, field names, field contents, and segment numbers corresponding to each field to generate the parsing result, the method further includes: For each field, check for semantic contradictions between the current field and the preceding fields; the preceding fields are all fields that precede the current field. Based on a pre-defined inter-segment logical dependency graph, determine whether the current field supports the validity of subsequent field logic; subsequent fields are all fields following the current field. If there is a semantic contradiction and / or the subsequent field logic is not supported, the target encoding will be marked as an illegal encoding and the user will be prompted.
[0014] In some implementations of the first aspect, the target is encoded as multiple entries; After parsing each field according to the preset encoding rule library and generating the corresponding parsing results, it also includes: For each target code, the following processing is performed: Convert all segment number fields of the current encoding into corresponding numerical vectors; The device classification number of the current code is calculated based on the numerical vector using a linear mapping function. The field position mapping function is used to generate a sorting weight corresponding to the current encoding based on the position of each field in the encoding and the character combination. Sort all target codes in ascending order of sorting weight; A device list is generated based on all sorted target codes, all parsing results, and all device category numbers.
[0015] Based on the same inventive concept, in a second aspect, embodiments of this application also provide a nuclear power plant code parsing device, comprising: The acquisition module is used to acquire at least one target code to be parsed; the target code is the Structure, System and Component SSC code. The segmentation module is used by the rule engine to segment and cut the target code according to the field segment number structure, generating multiple fields. The parsing module is used to parse each field according to the preset encoding rule library and generate the corresponding parsing results. There are no rule conflicts in the preset encoding rule library, and each field corresponding to the segment number is configured with a unique semantic and structural format.
[0016] In some implementations of the second aspect, the rule engine is the Drools engine; the field segment number structure includes predefined field lengths and delimiters; The segmentation module is specifically used for: The Drools engine is used to segment the target encoding according to the field length and delimiter, generating multiple fields.
[0017] In some implementations of the second aspect, the parsing module is specifically used for: Identify the registered field definitions that match each field in the preset encoding rule library; determine whether the corresponding field meets the rule requirements based on the registered field definitions; if it meets the rule requirements, extract the standard semantic definition and corresponding field name of the field from the preset encoding rule library; combine the standard semantic definition, field name, field content and segment number of each field to generate the parsing result.
[0018] In some embodiments of the second aspect, the apparatus further includes: The generation module is used to respond to the user's encoding rule creation operation in the visual rule configuration interface, generate an initial encoding rule library; convert each field rule in the initial encoding rule library into a format statement supported by the Drools engine to generate a preset encoding rule library; load the preset encoding rule library using the Drools engine, and perform rule conflict detection on all fields in the preset encoding rule library to generate corresponding rule conflict detection results; if the rule conflict detection result is that there are no rule conflicts, then execute the step of parsing each field according to the preset encoding rule library to generate corresponding parsing results.
[0019] In some implementations of the second aspect, when the generation module performs rule conflict detection on all fields in the preset encoding rule base and generates corresponding rule conflict detection results, it is specifically used for: A cross-semantic comparison is performed on the segment numbers of all fields in the preset encoding rule base. If two segment numbers assign different semantics to the same field, a semantic conflict is identified. The character set settings of all segment numbers in the preset encoding rule base are compared. If two segment numbers have partially overlapping character sets and different semantic meanings, a potential ambiguity problem is identified. The rules of all fields in the preset encoding rule base are checked for duplication. If duplicate rules are found, a rule duplication problem is identified. The corresponding rule conflict detection results are generated.
[0020] In some embodiments of the second aspect, the generation module is further configured to: The rule conflict detection results are displayed in a view on the preset graphical interface; the user is prompted with the rule conflict detection results.
[0021] In some embodiments of the second aspect, the apparatus further includes: The comparison module is used to perform a deep comparison of the parsing results using a historical standard encoding library and generate corresponding comparison results. The deep comparison includes field quantity consistency comparison, field order consistency comparison, and field value semantic consistency comparison. If the comparison result meets the structural anomaly conditions, the target encoding is marked as structural anomaly.
[0022] In some embodiments of the second aspect, the apparatus further includes: The suggestion module is used to determine the matching historical standard code from the historical standard code library based on the parsing results; determine the differences between the parsing results and the historical standard code; and generate and prompt corresponding correction suggestions based on the differences.
[0023] In some embodiments of the second aspect, the apparatus further includes: The validation module is used to check for semantic contradictions between the current field and the preceding fields for each field; the preceding fields are all fields located before the current field; it determines whether the current field supports the logic of subsequent fields based on a preset inter-segment logical dependency graph; the subsequent fields are all fields after the current field; if there is a semantic contradiction and / or the logic of subsequent fields is not supported, the target encoding is marked as illegal encoding and the user is prompted.
[0024] In some implementations of the second aspect, the target is encoded as multiple entries; The device also includes: The manifest generation module performs the following processing on each target code: Convert all segment number fields of the current code into corresponding numerical vectors; use a linear mapping function to calculate the device classification number of the current code based on the numerical vectors; use a field position mapping function to generate a sorting weight corresponding to the current code based on the position of each field in the code and the character combination; sort all target codes in ascending order of sorting weight; generate a device list based on all sorted target codes, all parsing results, and all device classification numbers.
[0025] Based on the same inventive concept, in a third aspect, embodiments of this application also provide an electronic device, including: a memory and a processor; The memory stores the instructions that the computer executes; The processor executes computer execution instructions stored in memory to implement the nuclear power plant code parsing method as described in any of the first aspects.
[0026] Based on the same inventive concept, in a fourth aspect, embodiments of this application also provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the nuclear power plant code parsing method as described in any of the first aspects.
[0027] According to the nuclear power plant code parsing method, apparatus, and electronic equipment provided in this application, at least one target code to be parsed is obtained. A rule engine is used to segment the target code according to the field segment number structure, generating multiple fields. Simultaneously, each field is parsed according to a preset coding rule library, generating corresponding parsing results. Since the coding rule library is pre-set and there are no rule conflicts, and each field corresponding to a segment number has a unique semantic and structural format, the problem of erroneous parsing results caused by rule conflicts is solved, thus improving the accuracy of nuclear power plant code parsing. Attached Figure Description
[0028] Figure 1 This illustration shows a flowchart of a nuclear power plant code parsing method provided in an embodiment of this application; Figure 2 This illustration shows another flowchart of the nuclear power plant code parsing method provided in an embodiment of this application; Figure 3 This illustration shows an overall flowchart of a nuclear power plant code parsing method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of the nuclear power plant coding parsing device provided in an embodiment of this application. Detailed Implementation
[0029] To enable those skilled in the art to better understand the technical solutions of this application, the application will be further described in detail below with reference to the accompanying drawings and embodiments.
[0030] The features and exemplary embodiments of various aspects of this application will now be described in detail. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain this application and are not configured to limit this application. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application.
[0031] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.
[0032] As described in the background section, current rule engines like Drools allow the definition of numerous complex business rules. When processing SSC codes, if different rules assign different parsing logic to the same field and no effective conflict detection mechanism is set, the system may default to using priority or loading order to determine rule execution, thus outputting incorrect parsing conclusions. For example, although the system has "SSC name display" and "error message" functions, if the result generated by the conflicting rule conforms to basic verification requirements, the system may not trigger an error warning. In this case, the error message is misjudged as a valid result, affecting the accuracy of nuclear power plant code parsing, and therefore, further optimization is needed.
[0033] Example 1
[0034] The nuclear power plant code parsing method provided in this application is applied to an electronic device. This electronic device can be a computer, or a device within a computer used to implement the nuclear power plant code parsing method; this application does not specifically limit this. The following description uses the example of the nuclear power plant code parsing method being executed by an electronic device.
[0035] like Figure 1 As shown, the nuclear power plant code parsing method provided in this application embodiment may include steps S101 to S103.
[0036] S101. Obtain at least one target code to be parsed. The target code is the Structure, System, and Component SSC code.
[0037] For example, the target code can be user input or imported from other devices. The target code includes at least one field, and typically multiple fields.
[0038] S102. The target code is segmented and cut according to the field segment number structure using a rule engine to generate multiple fields.
[0039] For example, the rule engine can use the Drools engine. The field segment number structure includes predefined field lengths and delimiters, etc. The field segment number structure makes it easier to segment the target code. For example, NE01-A5.03-PB-KR-B1 can be segmented into NE01, A5.03, PB, KR, and B1.
[0040] S103. Parse each field according to the preset encoding rule library and generate the corresponding parsing results. There are no rule conflicts in the preset encoding rule library, and each field corresponding to a segment number has a unique semantic and structural format.
[0041] For example, a pre-configured encoding rule base can be set by the user. For instance, a user can create an initial encoding rule base by configuring field rules and selecting field segment numbers through a visual rule configuration interface. During configuration, each field corresponding to a segment number has a unique semantic and structural format, ensuring that there are no semantic conflicts in the encoding rule base. Furthermore, to further ensure that there are no rule conflicts in the encoding rule base, rule conflict detection can be performed on this initial encoding rule base, such as field semantic conflict detection, character set overlap detection, and logical rule duplication detection, thus ensuring that there are no rule conflicts in the encoding rule base.
[0042] For example, before outputting the parsing results, a double check is performed on the accuracy of field semantic mapping and the legality of field combination. If the detection results do not match the encoding rule library, the output is terminated and a parsing failure prompt is triggered on the interface, clearly indicating the erroneous field and the reason for the error.
[0043] According to the nuclear power plant code parsing method provided in this application, at least one target code to be parsed is obtained. A rule engine is used to segment the target code according to the field segment number structure, generating multiple fields. Simultaneously, each field is parsed according to a preset coding rule library, generating corresponding parsing results. Since the coding rule library is pre-set and there are no rule conflicts, and each field corresponding to a segment number has a unique semantic and structural format, the problem of erroneous parsing results caused by rule conflicts is solved, thus improving the accuracy of nuclear power plant code parsing.
[0044] Example 2
[0045] like Figure 2 As shown, the nuclear power plant code parsing method provided in this application embodiment is based on the nuclear power plant code parsing method provided in embodiment 1 of this application, and further describes the method, which may include steps S201 to S207.
[0046] S201. Obtain at least one target code to be parsed.
[0047] It should be noted that the rule engine used in this embodiment is the Drools engine, and the field segment number structure includes predefined field lengths and delimiters.
[0048] S202. The Drools engine is used to segment the target code according to the field length and delimiter to generate multiple fields.
[0049] By segmenting the target encoding, multiple fields can be generated, providing a foundation for subsequent field parsing.
[0050] S203. Determine the registered field definitions in the preset encoding rule library that match each field.
[0051] For example, a registered field is defined as a field rule template in a preset encoding rule library, such as segment number order, value range characteristics, and format requirements. If there is no registered field definition matching each field in the preset encoding rule library, it can be determined that the encoded field has a structural error, which can be marked and prompted to the user.
[0052] In some implementations, the process of constructing a preset coding rule base may also be included before performing nuclear power plant coding parsing, as detailed below: In response to the user's coding rule creation operation in the visual rule configuration interface, an initial coding rule library is generated.
[0053] Each field rule in the initial encoding rule library is converted into a format statement supported by the Drools engine to generate a preset encoding rule library.
[0054] The Drools engine is used to load a preset encoding rule library, and rule conflict detection is performed on all fields in the preset encoding rule library to generate corresponding rule conflict detection results.
[0055] If the rule conflict detection result is that there is no rule conflict, then the relevant steps for nuclear power plant code parsing will be executed.
[0056] For example, the visual rule configuration interface can provide code segment structure configuration functions. Users can select segment numbers according to the template and enter field content, and force the field types and order to conform to the template requirements through preset control logic.
[0057] The visual rule configuration interface has a field linkage validation mechanism that immediately refreshes the optional values of subsequent segment numbers after the user enters content in a certain field.
[0058] The field linkage validation mechanism is based on a predefined inter-segment relationship matrix, which defines the set of subsequent field values allowed by the specific value of the preceding field.
[0059] The system automatically filters out options that do not match the preceding fields through a real-time refresh mechanism, thus preventing the generation of illegal combination codes.
[0060] Meanwhile, the interface configuration includes field prompts, input restrictions, segment previews, and template snapshots. Users can click on field icons to view their semantic descriptions, historical usage frequencies, and classification standards, ensuring that the user configuration process is logically clear, easy to operate, and yields compliant results.
[0061] For example, the encoding rule creation operation includes defining the attributes of each field one by one, specifically the field name, field number order, allowed character set of the field (such as only numbers, only uppercase letters, specific connectors, etc.), upper and lower limits of field length (such as 2 to 5 characters), and the semantic category represented by the field (such as device type, system identifier, installation location, etc.).
[0062] Each encoding segment type is limited by three attributes: field length, allowed character set, and field semantic category, and is initialized and configured through a pre-set template generation wizard.
[0063] Each field's semantic category is uniquely coded and verified for semantic consistency using a semantic dictionary. For the character set, only letters, numbers, and symbols within the ASCII (American Standard Code for Information Interchange) range are allowed, and a blacklist mechanism for prohibited characters is introduced to prevent the generation of illegal character parsing during rule loading.
[0064] Field length is limited by a predefined length range. Each segment number corresponds to a field length configuration upper and lower limit to prevent users from entering abnormally long fields that could disrupt the structural integrity.
[0065] For example, users can set fields such as power plant identification, system, location, equipment, and serial number, and configure unique semantics and structural formats for each field to form a complete multi-segment coding template.
[0066] For example, the Drools engine supports DRL (Drools Rule Language) format statements, which are inference structures of "IF condition - THEN result".
[0067] In the Drools rule engine, the parsing logic for each encoded segment in the preset encoded rule library is loaded one by one to ensure that there is no overlap in the meaning of fields between all rules.
[0068] In some implementations, the process of performing rule conflict detection on all fields in a preset encoding rule base and generating corresponding rule conflict detection results can be as follows: Cross-semantic comparison is performed on the segment numbers of all fields in the preset encoding rule base. If two segment numbers assign different semantics to the same field, a semantic conflict is determined.
[0069] The character set settings of all segment numbers in the preset encoding rule library are compared. If the character sets of two segment numbers partially overlap and their corresponding semantic meanings are different, then a potential ambiguity problem is identified.
[0070] Perform a duplicate check on all fields of the rules in the preset encoding rule library. If duplicate rules are found, then a duplicate rule problem is identified.
[0071] Generate corresponding rule conflict detection results.
[0072] For example, if none of the above-mentioned problems are found after detection, the rule conflict detection result is "no rule conflict." If any of the above-mentioned problems exist, the rule conflict detection result is "the corresponding problem exists."
[0073] For example, two segment numbers can be assigned different semantics to the same field. For instance, segment number 3 can be assigned two interpretations: "installation area" and "device number".
[0074] The character sets of the two segment numbers partially overlap, and their corresponding semantic meanings also differ. For example, if segment number 5 only allows uppercase letters AZ, segment number 6 also allows AZ, but they represent "system type" and "installation location" respectively.
[0075] In cases of duplicate rules, for example, two rules are both "IF segment number=7 AND value='XX'", but they assign different semantics to the fields.
[0076] By detecting the rule conflicts described above, it is possible to determine whether there are still rule conflicts in the preset coding rule base. If rule conflicts still exist, users can optimize the preset coding rule base until there are no rule conflicts.
[0077] In some implementations, after generating the corresponding rule conflict detection results, the following process is also included: The result of the rule conflict detection is displayed in a view in the preset graphical interface.
[0078] The system will display the rule conflict detection results to the user.
[0079] For example, the view can display each conflict detail through color highlighting, field navigation, and semantic comparison. The interface provides the field segment number, conflicting field content, conflict rule identifier, conflict location code, semantic comparison results, and automatically suggested correction strategies (such as changing field names, adjusting field order, splitting field segment numbers, etc.). Users, such as administrators, can quickly locate and batch modify conflicts in this view. After modification, the system can re-execute the detection until all conflicts are cleared.
[0080] For example, it automatically identifies any two rules in the rule set that have overlapping value ranges or execution results in terms of field logic, and displays them in the rule diagram in the form of color markings.
[0081] Users can view the cause of conflict, field location, content of conflicting fields and triggering conditions one by one in the editing interface, and modify them one by one with prompts and then recompile the rule set to ensure that all loaded rules are free from semantic ambiguity and logical duplication.
[0082] S204. Determine whether the corresponding field meets the rule requirements based on the registered field definition.
[0083] For example, the registered field definitions include segment number order, value range characteristics, and format requirements, and it is possible to determine whether the corresponding field meets the rule requirements based on the segment number order, value range characteristics, and format requirements.
[0084] S205. If it is determined that the rule requirements are met, the standard semantic definition and corresponding field name corresponding to the field are extracted from the preset encoding rule library.
[0085] For example, the segment “NE01” is identified as “Nuclear Power Equipment System Code”, with the semantics of “Main System Classification NE01”.
[0086] S206. Combine the standard semantic definitions, field names, field contents, and segment numbers corresponding to each field to generate the parsing result.
[0087] For example, the field content and segment number can be obtained based on the target encoding.
[0088] For example, the parsing result of NE01-A5.03-PB-KR-B1 can be "System: Master device NE01, Location: A5.03, Classification: PB, Functional segment: KR, Installation area: B1".
[0089] In some implementations, after generating the parsing results, a depth comparison process is also included, as detailed below: The parsing results are subjected to a deep comparison using a historical standard encoding library to generate corresponding comparison results. The deep comparison includes field quantity consistency comparison, field order consistency comparison, and field value semantic consistency comparison.
[0090] If the comparison result meets the structural anomaly condition, the target code is marked as structural anomaly.
[0091] For example, field quantity consistency comparison: count whether the number of segments in the current encoding is consistent with the number of segments in the standard samples in the historical standard encoding library. If the number of segments is missing or extra, it is immediately marked as "segment number abnormal".
[0092] Field order consistency comparison: Check whether the order of each field in the encoding conforms to the fixed structural order of the standard template, such as whether it follows the order of "system-location-function-sequence". If they are inconsistent, record the order offset.
[0093] Semantic consistency comparison of field values: The semantic dictionary is invoked to perform a semantic reverse lookup on the current field value to determine whether the value falls within the allowed semantic range of the field. For example, if the "PB" field appears in the location segment but its semantic meaning is "functional identifier", it is determined to be a semantic mismatch.
[0094] In addition, deep comparison can also include semantic combination legality comparison. Based on a preset logical dependency matrix between fields, it determines whether the combination of each field is reasonable. For example, whether a device classification code has a legal dependency relationship with the system type. If not, it is determined to be a combination conflict.
[0095] For example, after the comparison is completed, a "semantic consistency score" can be generated using a weighted model. The score has a maximum of 100 points and includes indicators such as field matching accuracy, semantic validity rate, and combination rationality weight. If the score is lower than a set threshold (e.g., 85 points), it meets the structural anomaly condition, and the code is marked as "structural anomaly".
[0096] In some implementations, after generating the parsing results, a suggested process is also included, as follows: Based on the parsing results, the matching historical standard codes are determined from the historical standard code library.
[0097] Determine the differences between the parsing results and the historical standard encoding.
[0098] Generate and suggest corresponding corrections based on the differences.
[0099] For example, the historical standard codes to be matched can be the three closest high-scoring standard codes. At the same time, the differences between the parsed results and the historical standard codes are determined, and correction suggestions are generated and suggested. If the current input is "NE01-A5.03-PB-KR-B1", the system can suggest: "Segment 'PB' is suggested to be corrected to 'LD'."
[0100] In some implementations, after generating the parsing results, the following process may also be included: For each field, check for semantic contradictions between the current field and the preceding fields. The preceding fields are all fields that come before the current field.
[0101] Based on a pre-defined inter-segment logical dependency graph, it determines whether the current field supports the validity of subsequent field logic. Subsequent fields are all fields following the current field.
[0102] If there is a semantic contradiction and / or the subsequent field logic is not supported, the target encoding will be marked as an illegal encoding and the user will be prompted.
[0103] For example, forward field validity checking involves detecting whether there are semantic contradictions between the current field and the preceding fields, including field semantic dictionary comparison and semantic conflict detection. Backward combination validation determines whether the current field supports the validity of subsequent fields based on a pre-defined inter-segment logical dependency graph. Examples include whether the device category matches the system number, or whether the sequence field is within a specified range.
[0104] If any part of the validation fails, a blocking message will be output, and the current input field will be cleared, prompting the user to re-enter the information to prevent invalid input from continuing to propagate the error logic.
[0105] In some implementations, the target is encoded as multiple entries.
[0106] After generating the parsing results, the process also includes generating a device inventory, as follows: For each target code, the following processing is performed: Convert all segment number fields of the current encoding into corresponding numerical vectors.
[0107] The device classification number of the current code is calculated based on the numerical vector using a linear mapping function.
[0108] The field position mapping function is used to generate a sorting weight corresponding to the current encoding based on the position of each field in the encoding and the character combination.
[0109] Sort all target codes in ascending order of sorting weight.
[0110] A device list is generated based on all sorted target codes, all parsing results, and all device category numbers.
[0111] For example, each parsed target code (i.e., SSC code) is converted into a numerical form, forming a numerical vector, as shown below:
[0112] in, , It is the first SSC encoded field, It is the first The SSC encoding field quantization representation result represents the field encoding in numerical form. It is a hash function. This limits the hash value to between 0 and 99999 to prevent numerical overflow. This represents the total number of SSC-encoded fields.
[0113] The device classification number corresponding to each code is calculated using a linear mapping function, as shown in the following expression:
[0114] in, The field value sequence representing the entire SSC encoding. These are the preset weights corresponding to each segment number. express To maximize the number of categories, It is the equipment classification number.
[0115] Iterate through all the parsed results and count the number corresponding to each device category number. The calculation expression is as follows:
[0116] in, yes The device classification number calculated from the SSC code field. This is the current equipment category number in the statistics. It is an indicator function. This is the total number of encoded samples, i.e., the total number of SSC encoded entries to be processed. This is the final statistical result, indicating that the equipment classification number is... The number of SSC devices.
[0117] For example, the equipment list generation process not only requires the fields under the Drools rules to be semantically correct, but also introduces mathematical structure consistency checks and sorting strategies to achieve dual protection of coding legality and classification rationality, so as to ensure that the final output list meets the engineering control standards in terms of logic, order and data quality.
[0118] The field position mapping function is used to generate a sorting weight corresponding to the current encoding based on the position of each field in the encoding and the character combination, as follows: Each field of each code calculates a mapping value using positional weights. The field positional mapping function includes the following algorithm:
[0119] in, It is the first character of the field. Is the field number One character, It is a character ASCII encoding value, It is the first The length of the SSC encoded field in the segment. It is the first The mapping value of the SSC encoded field of the segment.
[0120] For each code, calculate the integrity check value using the following expression:
[0121] In the formula, It is the total checksum of the entire encoding structure. It involves performing a modulo 97 operation on the weight of each field.
[0122] If satisfied If the structure is valid, it is considered reasonable; otherwise, the coding structure is deemed to deviate from the template specification, marked as invalid, and excluded from the final list.
[0123] To provide a sorting basis for the output list, calculate the sorting weights using the following expression:
[0124] In the formula, It is a sorting weight used to determine the order of codes in the equipment list. The result value is limited to within one billion.
[0125] according to All codes are sorted from smallest to largest, and records with similar values are displayed prominently in the sorting for further manual verification to check whether there are duplicate names / categories for similar devices.
[0126] The nuclear power plant code parsing method in this embodiment achieves high accuracy and consistency in SSC code parsing through the Drools rule engine, enhances error identification and semantic verification mechanisms, effectively prevents hidden risks caused by rule conflicts, and has batch parsing and intelligent list generation capabilities, which greatly improves coding processing efficiency and standardized management level, and is suitable for high reliability engineering scenarios such as nuclear power plants.
[0127] The nuclear power plant code parsing method in this embodiment utilizes the Drools rule engine to accurately load and logically reason about SSC code segment numbers. Through graphical conflict detection and static semantic comparison mechanisms, it effectively avoids logical overlap and execution conflicts between different rules. Compared to traditional manual setting or fixed template parsing methods, this embodiment establishes unique semantic constraints and logical dependencies for each field, ensuring that the code is unambiguous or does not deviate during parsing. This significantly improves the accuracy of code semantic recognition and the consistency of output results, providing high-quality coded data support for the standardized management of critical equipment in nuclear power plants.
[0128] This embodiment introduces a bidirectional semantic verification mechanism and a structural consistency matching model, enabling the system to accurately identify and provide real-time alerts for internal semantic conflicts or field logic anomalies even if certain SSC encoding surface formats conform to the rules. Combined with functions such as field value linkage restrictions, field combination legality checks, and structural anomaly annotation, the system proactively intervenes in the spread of potential erroneous inputs during each parsing and input process, preventing boundary cases from being ignored due to passive rule execution. This mechanism significantly reduces systemic risks such as device classification distortion and information transmission errors caused by parsing errors, strengthening the anti-interference capability of the encoding system in the engineering data chain.
[0129] This embodiment not only achieves accurate parsing of single SSC codes but also possesses batch processing and structured output capabilities. By introducing classification vector mapping and inventory weighting algorithms, the system can intelligently classify, count, and standardize the output of tens of thousands of equipment codes. Simultaneously, a structural anomaly annotation mechanism provides suggestions for manual review, significantly saving manual processing time and auditing costs. The inventory generation process combines multi-dimensional calculation indicators such as field weights, structural integrity, and semantic dependencies to ensure high consistency and business logic in the output results, providing automated and intelligent support for equipment classification, inventory compilation, and standard setting during project implementation.
[0130] To better understand the nuclear power plant coding parsing method provided in this application embodiment, an exemplary description is given below in conjunction with a specific application implementation.
[0131] like Figure 3As shown, the overall process includes: 1. Establishing the encoding rule base. 2. Loading Drools rules and detecting conflicts. 3. Configuring the user interface. 4. Encoding parsing and execution. 5. Error mechanism verification. 6. Data writing and manifest generation.
[0132] The specific process is as follows: In the design and application of the SSC coding parsing system for nuclear power plant equipment, to ensure a high degree of consistency and accuracy in the reasoning process based on the Drools rule engine, all business rules must be comprehensively pre-loaded and conflict detected before the system runs. This implementation method starts from the system initialization stage, explaining in detail the rule base construction process, the Drools loading mechanism, the conflict detection logic, and the visualization feedback methods, ensuring that the subsequent parsing process runs in a stable, conflict-free rule environment, thereby minimizing the risk of coding errors.
[0133] First, during the initial system deployment, the system administrator creates an SSC encoding rule base through a visual rule configuration interface. This interface supports detailed parameter settings at the field segment number level. Administrators can define the attributes of each field segment individually, including field name, segment number order, allowed character sets (e.g., only numbers, only uppercase letters, specific connectors, etc.), upper and lower limits for field length (e.g., 2-5 characters), and the semantic category represented by the field (e.g., device type, system identifier, installation location, etc.). All field settings are bound to a unique field ID (Identifier) and stored in the structured rule database to ensure a consistent field identification basis in subsequent processing.
[0134] Next, the system enters the loading phase of the Drools rule engine. At this stage, the system converts each field rule in the rule database into a DRL format statement supported by Drools, i.e., an inference structure of "IF condition - THEN result". For example, if rule definition field number 2 represents "device classification code", with allowed values "01-99", the system will generate the following rule fragment: "IF field number = 2 AND value ∈ [01..99] THEN field semantic = 'device classification'". The system converts all rule entries into executable rule entities one by one in this manner and loads them in an orderly manner according to field field number order and priority number.
[0135] After the rules are successfully loaded into memory, the system automatically triggers the "static conflict detection module," which is one of the core innovative steps of this implementation method. This module executes the following three main detection logic steps: Field semantic conflict detection: The system performs cross-semantic comparison on all field segment numbers. If two segment numbers are found to assign different semantics to the same field (for example, segment number 3 is assigned two interpretations: "installation area" and "device number"), it is immediately determined to be a semantic conflict and the conflict entry is recorded.
[0136] Character set overlap detection: The system compares the character set settings of all segment numbers. If the character sets of two segment numbers have extensive overlap and significant differences in semantic meaning, they are marked as potentially ambiguous fields. For example, if segment number 5 only allows uppercase letters AZ, and segment number 6 also allows AZ, but represents "system type" and "installation location" respectively, such overlap may lead to parsing ambiguity.
[0137] Logical rule duplication detection: The system analyzes the condition triggering patterns in Drools rules. If multiple rules have the same conditions but different execution results (for example, two rules are both "IF segment number=7 AND value='XX'", but with different semantics assigned to the fields), it is considered that there is a risk of rule duplication or overwriting, and the administrator is required to explicitly retain the priority rule.
[0138] All detection results will be presented in a "Conflict View" in the graphical interface. The system displays the details of each conflict through color highlighting, field navigation, and semantic comparison. The interface provides the field segment number, conflicting field content, conflict rule ID, conflict location code, semantic comparison results, and automatically suggested correction strategies (such as changing field names, adjusting field order, splitting field segment numbers, etc.). Administrators can quickly locate and batch modify conflicts in this view. After modification, the system can re-execute the detection until all conflicts are cleared.
[0139] In addition, to improve rule loading efficiency, the system introduces a "rule version control" mechanism. Each rule update generates an independent version number and retains a change history log. Administrators can roll back, compare, and restore any historical version to avoid global logic chaos caused by accidental operations. The system also provides a "rule draft area," allowing users to simulate loading and pre-check before official release, ensuring that the rules are error-free before pushing them to the official parsing environment.
[0140] After completing rule conflict detection and confirming its accuracy, the Drools rule engine officially enters standby mode, waiting for user-input codes to be parsed. At this time, all inference rules remain active in the system memory, ensuring that any valid SSC code input can be quickly matched and accurately parsed, fundamentally eliminating potential problems at the rule logic level and improving the overall stability and parsing accuracy of the system.
[0141] In summary, this implementation method avoids parsing errors caused by Drools rule conflicts at the source by using rule preloading and conflict pre-detection mechanisms. It constructs a coding rule parsing system with a clear structure, consistent semantics, and high response efficiency, which is especially suitable for nuclear power plant equipment coding systems with extremely high accuracy requirements. It has significant technical reliability and engineering practical value.
[0142] Implementation Method Two: In the practical application of the SSC coding management and standardization system in nuclear power plants, coding input, parsing, and semantic judgment are among the core business functions. This implementation method focuses on the coding parsing process driven by the Drools rule engine, combined with a multi-dimensional semantic consistency analysis mechanism, to comprehensively improve the accuracy of coding structure recognition, the intelligence of coding semantic judgment, and the consistency of historical sample comparison, ensuring that each SSC code has logical compliance, semantic coherence, and standard compatibility.
[0143] In everyday user scenarios, users typically input a complete SSC code through the interface. This code consists of multiple field segments, which may include device type, system category, location identifier, serial number, project code, installation region, and classification tag. For example, an SSC code might be "NE01-A5.03-PB-KR-B1". After the user completes the input, the system will immediately trigger the Drools rules engine to parse the code in real time.
[0144] The Drools engine first segments the code according to the field segment number structure, using predefined field lengths and delimiters. Each segment is then matched against registered field definitions in the rule base. By matching segment number order, value range characteristics, and format requirements, the system determines whether the field meets the rule requirements. Once a match is successful, the system extracts the standard semantic definition of the segment field and records the segment's field name, field content, semantic meaning, and corresponding segment number. For example, segment "NE01" is identified as "Nuclear Power Equipment System Code," with the semantic meaning of "Main System Classification NE01."
[0145] After all fields are parsed, the system will output these fields as structured data objects and concatenate them to form a complete semantic structure description of the SSC device, such as: "System: Master Device NE01, Location: A5.03, Category: PB, Functional Segment: KR, Installation Area: B1". This not only provides users with an intuitive display of structural information, but also provides basic data support for subsequent semantic consistency judgment.
[0146] At this point, the system invokes the built-in "semantic consistency judgment module," which performs a deep comparison between the current encoding parsing structure and the historical standard encoding library. The comparison mechanism includes the following dimensions: Field quantity consistency comparison: The system counts whether the number of segments in the current code is consistent with the number of segments in the standard sample. If the number of segments is missing or extra, it is immediately marked as "segment number abnormal".
[0147] Field order consistency comparison: The system checks whether the order of each field in the encoding conforms to the fixed structural order of the standard template, such as whether it follows the order of "system-location-function-sequence". If they are inconsistent, the order offset is recorded.
[0148] Semantic consistency comparison of field values: The system calls the semantic dictionary to perform a semantic reverse lookup on the current field value to determine whether the value falls within the allowed semantic range of the field. For example, if the "PB" field appears in the location segment but its semantics are "functional identifier", it is determined to be a semantic mismatch.
[0149] Semantic combination legality comparison: The system judges whether the combination of each field is reasonable based on the preset logical dependency matrix between fields. For example, whether a device classification code has a legal dependency relationship with the system type. If not, it is judged as a combination conflict.
[0150] After the comparison is completed, the system generates a "semantic consistency score" using a weighted model. The score has a maximum of 100 points and includes indicators such as field matching accuracy, semantic validity rate, and combination rationality weight. If the score is lower than a set threshold (e.g., 85 points), the system marks the code as "structurally abnormal" and automatically triggers an intelligent error correction mechanism.
[0151] The intelligent error correction mechanism compares the three closest high-scoring standard codes from historical samples, lists the discrepancies, and pushes recommended correction suggestions. For example, if the current input is "NE01-A5.03-PB-KR-B1", the system can prompt: "Segment 'PB' is recommended to be corrected to 'LD'. According to the historical code 'NE01-A5.03-LD-KR-B1', the semantic matching rate is 97.3%." Furthermore, the system also stores such abnormal codes in a "list to be reviewed" for subsequent manual review by engineers.
[0152] To enhance user experience and coding transparency, the system provides a "structural comparison visualization view" in the front-end interface. Users can intuitively view the difference fields, scoring curves, recommended values, and semantic explanations between the current code and historical samples. They can also confirm through the interface whether to adopt the system's suggested correction values or mark the current value for a special purpose to bypass the strong validation logic (administrator approval required).
[0153] This module also integrates a "semantic prediction engine" to assist in generating suggestions for subsequent fields. After the user enters the first few fields, the system will automatically invoke Drools rules and historical sample models to predict the next most likely field value and its semantic description, and display recommended options on the interface for the user to choose from, improving coding efficiency and accuracy.
[0154] In summary, this implementation method achieves a comprehensive coding quality control mechanism from the structural to the semantic level through the collaborative operation of the Drools parsing engine and the semantic consistency judgment module. This method is not only applicable to SSC coding parsing scenarios for complex equipment in nuclear power plants, but also has applicability for other large-scale industrial, manufacturing, and engineering applications, significantly improving the accuracy, standardization, and engineering reliability of coded data.
[0155] Implementation Method 3: In the process of equipment management and data standardization in nuclear power plant projects, challenges arise such as a wide variety of equipment, complex coding structures, and high information granularity. To improve the management efficiency and accuracy of SSC coded data and ensure that each code can be effectively classified, identified, mined, and tracked, the system introduces a "list generation and intelligent mining output module" as an important component of this embodiment. This implementation method systematically describes the entire process from batch parsing, logical verification, automatic classification, edge field identification, sorting weight calculation to final list generation, comprehensively improving the structured management capabilities and intelligent analysis level of coded data.
[0156] Firstly, during the design, procurement, and operation and maintenance phases of nuclear power projects, relevant units import a large amount of SSC (Structure, System, Component) coding information. These codes represent thousands of structures, systems, and components within the system. This system supports batch data import, including CSV format, Excel spreadsheets, and inter-system API interfaces. After importation, the system first calls the Drools rule engine to parse each SSC code one by one, identifying and validating each field based on the field segment number, field value rules, character set, length limits, and semantic definitions configured in the rule base.
[0157] Unlike typical parsing, this module introduces a "two-way semantic verification mechanism" to further validate all fields. This mechanism consists of two steps: The first step is forward verification, where the system checks the validity of each field after identification, including whether the character type, value range, and semantic definition match. The second step is backward verification, where the system checks whether the current field has logical conflicts with its subsequent fields based on the logical dependencies between fields, such as whether the device category matches the system number, or whether the sequence field is within the specified range. If any field in a code fails the two-way verification, the system will immediately mark it as an "illegal code" and isolate it from subsequent processing, prompting the user or administrator for handling.
[0158] For all codes that pass the validity check, the system enters the automatic classification stage. This stage uses a classification vector mapping model to convert the field content of each code into a structured vector, and generates a device classification ID based on vector feature extraction algorithms (such as hash mapping, word vector embedding, etc.). This classification ID is compared with the historical device classification model to achieve intelligent grouping of all devices, such as accurate classification by system affiliation (main pump, heat exchanger, etc.), equipment level, and operating function, and records the classification results and quantity distribution.
[0159] After automatic classification, the valid coded data will enter the list generation process. At this point, the system calls the field position mapping function to convert the position, character combination, and semantic content of each field in the code into a unique sorting weight. The sorting weight is constructed using a weight distribution function, and the weight calculation comprehensively considers factors such as field importance (e.g., the weight of a system segment is greater than that of a connector segment), field length, and the field's order in the structure, thereby ensuring that the final generated list has strict logical sorting characteristics, rather than simple alphabetical sorting or manual process numbering.
[0160] In addition, the system executes a "structural checksum" algorithm during the list generation process to verify the integrity of the field structure of each code. The structural checksum is calculated from the position and content codes of all fields. If the structural checksum of a code does not meet the modular verification standard set by the system, it is regarded as a structural risk item. The system will highlight such codes in the final list and record them as "edge field codes".
[0161] The system outputs a centralized list of all "edge fields" for project engineers to manually review and assess. This mechanism effectively prevents situations where some codes, while formally valid, may have semantic or logical inconsistencies, ensuring the rigor and traceability of the list. For such codes, the system will also suggest possible corrective values and provide optimization recommendations based on historical coding trend analysis for subsequent rule base maintenance and standard iteration updates.
[0162] Ultimately, the system outputs a complete equipment list, which includes multi-dimensional information such as equipment codes, field parsing results, category IDs, sorting values, structural verification status, and edge field markers. It supports exporting to various formats including PDF, Excel, and XML, and automatically integrates with the nuclear power plant engineering management platform, achieving seamless integration of coded data and equipment information. Users can perform advanced operations such as equipment statistics, resource allocation, fault location, and lifecycle management based on the list, providing structured data support for operation and maintenance and project decision-making.
[0163] In addition, the list includes a "rule usage trend analysis" function. The system automatically extracts information such as frequently used field combinations, common variations, and field order deviations in recently added codes, generating a rule evolution trend report to provide quantifiable reference for updating coding standards. Through statistical analysis, the system can identify the usage of standard extensions, helping managers understand the actual operation of the coding system and make targeted adjustments to the standards.
[0164] In summary, this embodiment, through a complete batch processing workflow and intelligent analysis algorithm, achieves a fully automated, highly reliable, and highly intelligent management solution from original code import to manifest generation. This not only improves the efficiency and quality of equipment code management but also provides a solid information foundation for big data governance and decision support in nuclear power engineering. This module has broad applicability and can also be applied to code parsing and data manifest scenarios in industries such as aerospace, rail transportation, and large equipment manufacturing.
[0165] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.
[0166] It is understood that the various method embodiments mentioned above in this application can be combined with each other to form combined embodiments without violating the principle and logic. Due to space limitations, this disclosure will not elaborate further. Those skilled in the art will understand that in the above methods of specific implementation, the specific execution order of each step should be determined by its function and possible internal logic.
[0167] Example 3
[0168] like Figure 4 As shown, the nuclear power plant code parsing device 400 provided in this embodiment is located in an electronic device. The nuclear power plant code parsing device 400 may include: The acquisition module 401 is used to acquire at least one target code to be parsed. The target code is the Structure, System, and Component SSC code.
[0169] The segmentation module 402 is used to segment the target code according to the field segment number structure using a rule engine, generating multiple fields.
[0170] The parsing module 403 is used to parse each field according to a preset encoding rule library and generate corresponding parsing results. The preset encoding rule library contains no rule conflicts, and each field corresponding to a segment number has a unique semantic and structural format.
[0171] In some implementations, the rule engine is the Drools engine. The field segment number structure includes predefined field lengths and delimiters.
[0172] The segmentation module 402 is specifically used for: The Drools engine is used to segment the target encoding according to the field length and delimiter, generating multiple fields.
[0173] In some implementations, the parsing module 403 is specifically used for: Identify the registered field definitions in the preset encoding rule library that match each field. Determine if the corresponding field conforms to the rule requirements based on the registered field definitions. If it conforms, extract the standard semantic definition and corresponding field name from the preset encoding rule library. Combine the standard semantic definition, field name, field content, and segment number for each field to generate the parsing result.
[0174] In some embodiments, the nuclear power plant code parsing device 400 further includes: The generation module responds to user input in the visual rule configuration interface by generating an initial encoding rule library. It then converts each field rule in the initial library into a format supported by the Drools engine, generating a preset encoding rule library. The Drools engine loads this preset library and performs rule conflict detection on all fields, generating corresponding conflict detection results. If no conflict is found, the module parses each field according to the preset encoding rule library, generating corresponding parsing results.
[0175] In some implementations, when the generation module performs rule conflict detection on all fields in the preset encoding rule base and generates the corresponding rule conflict detection results, it is specifically used for: A cross-semantic comparison is performed on the segment numbers of all fields in the preset encoding rule base. If two segment numbers assign different semantics to the same field, a semantic conflict is identified. The character set settings of all segment numbers in the preset encoding rule base are compared. If two segment numbers have partially overlapping character sets and different semantic meanings, a potential ambiguity issue is identified. A duplicate rule check is performed on the rules for all fields in the preset encoding rule base. If duplicate rules are found, a rule duplication issue is identified. Corresponding rule conflict detection results are generated.
[0176] In some implementations, the generation module is also used for: The rule conflict detection results are displayed in a view within the preset graphical interface. The user is then prompted about the rule conflict detection results.
[0177] In some embodiments, the nuclear power plant code parsing device 400 further includes: The comparison module performs a deep comparison of the parsed results using a historical standard encoding library, generating corresponding comparison results. The deep comparison includes field quantity consistency comparison, field order consistency comparison, and field value semantic consistency comparison. If the comparison result meets the structural anomaly criteria, the target encoding is marked as structurally abnormal.
[0178] In some embodiments, the nuclear power plant code parsing device 400 further includes: The suggestion module is used to determine the matching historical standard encoding from the historical standard encoding library based on the parsing results. It identifies the differences between the parsing results and the historical standard encoding. Based on these differences, it generates and provides corresponding correction suggestions.
[0179] In some embodiments, the nuclear power plant code parsing device 400 further includes: The validation module checks for semantic inconsistencies between the current field and preceding fields for each field. "Preceding fields" refers to all fields preceding the current field. It determines whether the current field supports the logic of subsequent fields based on a pre-defined inter-segment logical dependency graph. "Subsequent fields" refers to all fields following the current field. If a semantic inconsistency exists and / or the logic of subsequent fields is not supported, the target encoding is marked as invalid, and the user is notified.
[0180] In some implementations, the target is encoded as multiple entries.
[0181] The nuclear power plant coding analysis device 400 also includes: The manifest generation module performs the following processing on each target code: Convert all segment number fields of the current code into corresponding numerical vectors. Calculate the device category number of the current code using a linear mapping function based on the numerical vectors. Generate a sorting weight corresponding to the current code using a field position mapping function, based on the position of each field in the code and the character combination. Sort all target codes in ascending order of sorting weight. Generate a device list based on all sorted target codes, all parsing results, and all device category numbers.
[0182] The nuclear power plant code parsing device provided in this application has the beneficial effects and implementation methods of the nuclear power plant code parsing method provided in Embodiments 1 and 2 of this application. For details, please refer to the specific descriptions of the nuclear power plant code parsing method in Embodiments 1 and 2 above. This embodiment will not repeat them here.
[0183] Example 4
[0184] This application also provides an electronic device, which is intended to be various forms of devices with data processing capabilities, such as parsing devices and other suitable devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.
[0185] This electronic device includes a processor and memory. The various components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processor processes instructions that execute within the electronic device.
[0186] The memory is the non-transitory computer-readable storage medium provided in this application. The memory stores instructions executable by at least one processor to cause the at least one processor to execute the nuclear power plant code parsing method provided in this application. The non-transitory computer-readable storage medium of this application stores computer instructions for causing a computer to execute the nuclear power plant code parsing method provided in this application.
[0187] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the nuclear power plant code parsing method in the embodiments of this application. The processor executes various functional applications and data processing of the electronic device by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the nuclear power plant code parsing method in the above method embodiments.
[0188] The electronic device provided in this application has the beneficial effects and implementation methods of the nuclear power plant code parsing method provided in Embodiments 1 and 2 of this application. For details, please refer to the specific description of the nuclear power plant code parsing method in Embodiments 1 and 2 above. This embodiment will not repeat the description here.
[0189] Example 5
[0190] This embodiment also provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it implements the nuclear power plant code parsing method in Embodiment 1 or Embodiment 2 above.
[0191] The computer-readable storage medium provided in this application embodiment has the beneficial effects and implementation methods of the nuclear power plant code parsing method in Embodiments 1 and 2 of this application. For details, please refer to the specific description of the nuclear power plant code parsing method in Embodiments 1 and 2 above. This embodiment will not repeat the description here.
[0192] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.
[0193] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.
[0194] It is understood that the above embodiments are merely exemplary implementations used to illustrate the principles of this application, and this application is not limited thereto. For those skilled in the art, various modifications and improvements can be made without departing from the spirit and substance of this application, and these modifications and improvements are also considered to be within the scope of protection of this application.
Claims
1. A method for parsing codes in nuclear power plants, characterized in that, include: Obtain at least one target code to be parsed; The target encoding is the Structure, System, and Component (SSC) encoding; The target code is segmented and cut according to the field segment number structure using a rule engine to generate multiple fields; The fields are parsed according to a preset encoding rule library to generate corresponding parsing results; There are no rule conflicts in the preset encoding rule base, and the field configuration for each segment number has a unique semantic and structural format.
2. The method according to claim 1, characterized in that, The rule engine is the Drools engine; the field segment number structure includes predefined field lengths and separators. The rule engine is used to segment and cut the target code according to the field segment number structure, generating multiple fields, including: The target encoding is segmented and cut according to the field length and the delimiter using the Drools engine to generate multiple fields.
3. The method according to claim 2, characterized in that, The step of parsing each field according to a preset encoding rule library to generate corresponding parsing results includes: Determine the registered field definitions in the preset encoding rule library that match each of the fields; Based on the registered field definition, determine whether the corresponding field meets the rule requirements; If it is determined that the rule requirements are met, the standard semantic definition and corresponding field name corresponding to the field are extracted from the preset encoding rule library; The parsing result is generated by combining the standard semantic definition, field name, field content, and segment number corresponding to each field.
4. The method according to claim 2, characterized in that, Before parsing each field according to a preset encoding rule library and generating the corresponding parsing result, the method further includes: In response to the user's coding rule creation operation in the visual rule configuration interface, an initial coding rule library is generated; Each field rule in the initial encoding rule library is converted into a format statement supported by the Drools engine to generate the preset encoding rule library; The Drools engine is used to load the preset encoding rule library, and rule conflict detection is performed on all fields in the preset encoding rule library to generate corresponding rule conflict detection results; If the rule conflict detection result is that there is no rule conflict, then the step of parsing each field according to the preset encoding rule library and generating the corresponding parsing result is performed.
5. The method according to claim 4, characterized in that, The step of performing rule conflict detection on all fields in the preset encoding rule base and generating corresponding rule conflict detection results includes: Cross-semantic comparison is performed on the segment numbers of all fields in the preset encoding rule library. If two segment numbers assign different semantics to the same field, a semantic conflict is determined. The character set settings of all segment numbers in the preset encoding rule library are compared. If the character sets of two segment numbers partially overlap and their corresponding semantic meanings are also different, then a potential ambiguity problem is identified. The rules for all fields in the preset encoding rule base are checked for duplicates. If duplicate rules are found, it is determined that there is a rule duplication problem. Generate corresponding rule conflict detection results.
6. The method according to claim 5, characterized in that, After generating the corresponding rule conflict detection result, the method further includes: The rule conflict detection results are displayed in a view format on a preset graphical interface; The system will display the result of the rule conflict detection to the user.
7. The method according to claim 3, characterized in that, After parsing each field according to a preset encoding rule library and generating corresponding parsing results, the process further includes: The parsing results are compared in depth using a historical standard encoding library to generate corresponding comparison results; the deep comparison includes field quantity consistency comparison, field order consistency comparison, and field value semantic consistency comparison. If the comparison result meets the structural anomaly condition, the target code is marked as structural anomaly.
8. The method according to claim 3, characterized in that, After parsing each field according to a preset encoding rule library and generating corresponding parsing results, the process further includes: Based on the parsing results, determine the matching historical standard codes from the historical standard code library; Determine the difference between the parsing result and the historical standard encoding; Based on the differences, corresponding correction suggestions are generated and displayed.
9. The method according to claim 3, characterized in that, After combining the standard semantic definitions, field names, field contents, and segment numbers corresponding to each field to generate the parsing result, the method further includes: For each of the fields, check whether there is a semantic contradiction between the current field and the preceding fields; the preceding fields are all fields located before the current field. Based on a preset inter-segment logical dependency graph, it is determined whether the current field supports the logical validity of subsequent fields; the subsequent fields are all fields after the current field. If there is a semantic contradiction and / or the subsequent field logic is not supported, the target encoding will be marked as an illegal encoding and the user will be prompted.
10. The method according to claim 9, characterized in that, The target code consists of multiple entries; After parsing each field according to a preset encoding rule library and generating corresponding parsing results, the process further includes: For each target code, the following processing is performed: Convert all segment number fields of the current encoding into corresponding numerical vectors; The device classification number of the current encoding is calculated based on the numerical vector using a linear mapping function; A field position mapping function is used to generate a sorting weight corresponding to the current encoding based on the position of each field in the encoding and the character combination. Sort all the target codes in ascending order of their sorting weights; A device list is generated based on all the sorted target codes, all the parsing results, and all the device classification numbers.
11. A nuclear power plant code parsing device, characterized in that, include: The acquisition module is used to acquire at least one target code to be parsed. The target encoding is the Structure, System, and Component (SSC) encoding; The segmentation module is used to segment the target code according to the field segment number structure using a rule engine, generating multiple fields. The parsing module is used to parse each field according to a preset encoding rule library and generate corresponding parsing results; There are no rule conflicts in the preset encoding rule base, and the field configuration for each segment number has a unique semantic and structural format.
12. An electronic device, characterized in that, include: Memory and processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the nuclear power plant code parsing method as described in any one of claims 1 to 10.