Automatic auditing method for GIM model data of transformer substation

Abstract

The invention discloses an automatic auditing method for GIM model data of a transformer substation. The automatic auditing method comprises the steps that 1, a GIM file is decompressed; 2, checking whether the decompressed CBM, DEV, MOD and PHM folders are complete or not, and if not, decompressing again; 3, checking the format and the name of the GIM file; 4, checking the integrity of the CBM file; 5, checking the data range and precision in the CBM file; step 6, checking attribute data in the FAM file; 7, checking a model code in the FAM file; the problems that due to the fact that GIM data auditing mainly depends on manual work, coding errors of attribute data and model codes are difficult to check in detail, errors and omissions often exist and are not found, data defects of errors, omissions, inconsistency and the like often exist in transferred GIM model data, and when an operation and maintenance unit uses the GIM data, the operation and maintenance efficiency is high are solved. And a lot of time and manpower need to be spent for manual verification.

Description

An automatic verification method for GIM model data of substations Technical Field

[0001] This invention belongs to the field of substation GIM model data technology, and particularly relates to an automatic verification method for substation GIM model data. Background Technology

[0002] GIM models are the primary means of recording substation design outcomes. These models provide a hierarchical, graphical, and attribute-based description of the entire power transmission and transformation project, including the main station, areas, systems, equipment, and components. However, current GIM data review relies mainly on manual processes, making it difficult to thoroughly check for errors in attribute data and model coding. Errors and omissions often go undetected, resulting in frequently flawed GIM model data after handover, including errors, omissions, and inconsistencies. Operation and maintenance units must then spend significant time and manpower manually verifying GIM data before use. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide an automatic verification method for substation GIM model data, so as to solve the problem that the existing GIM data verification mainly relies on manual labor, which makes it difficult to conduct a detailed check for errors in attribute data and model coding. Errors and omissions are often not discovered, resulting in GIM model data with errors, omissions and inconsistencies after handover. The operation and maintenance unit needs to spend a lot of time and manpower to manually verify the GIM data when using it.

[0004] Technical solution of the present invention:

[0005] An automatic verification method for GIM model data of substations, the method comprising:

[0006] Step 1: Unzip the GIM file;

[0007] Step 2: Check if the CBM, DEV, MOD, and PHM folders are complete after decompression. If not, decompress again.

[0008] Step 3: Check the GIM file format and naming;

[0009] Step 4: Verify the integrity of the CBM file;

[0010] Step 5: Verify the data range and accuracy in the CBM file;

[0011] Step 6: Verify the attribute data in the FAM file;

[0012] Step 7: Verify the model encoding in the FAM file.

[0013] Checking the GIM file format and naming includes: checking for non-compliant file types in each folder of CBM, DEV, MOD, and PHM; and checking whether each file name conforms to the naming requirements of a 128-bit GUID.

[0014] Methods for verifying the integrity of CBM files include:

[0015] Step 4.1: Verify the integrity of the project.cbm file. The project.cbm file includes the keywords BLHA, SUBSYSTEM, SCH, and TYPE; and the format of each keyword must conform to the specifications.

[0016] Step 4.2: Verify the integrity of the project-level CBM file; the project-level CBM file must contain ENTITYNAME, BASEFAMILY, SUBSYSTEMS.NUM, and SUBSYSTEM. <n>、IFC.NUM、IFC <n>And MATERIALSHEET, and the format of each keyword conforms to the specifications;

[0017] Step 4.3: Verify the integrity of the professional-level CBM files; the second-level *.cbm files must be correctly referenced by the first-level *.cbm files, and the files must contain the keywords ENTITYNAME, SYSCLASSIFYNAME, BASEFAMILY, SUBSYSTEMS.NUM, and SUBSYSTEM. <n>、IFC.NUM、IFC <n>For MATERIALSHEET, key fields must exist in the file and each keyword must be formatted according to specifications;

[0018] Step 4.4: Verify the integrity of the system-level CBM files; the third-level *.cbm files must be correctly referenced by the second-level *.cbm files, and the files must contain all the specified keywords and the format of each keyword must conform to the specifications;

[0019] Step 4.5: Verify the integrity of the device-level CBM file; the level 4 *.cbm file must be correctly referenced by the level 3 *.cbm file, the file must contain all the specified keywords, the key fields must exist in the file and the format of each keyword must conform to the specification;

[0020] Step 4.6: Verify the structure and integrity of the component-level CBM files; the level 5 *.cbm file must be correctly referenced by the level 4 *.cbm file; the file must contain all the specified keywords, and the format of each keyword must conform to the specification.

[0021] Verifying the data range and precision in the CBM file includes:

[0022] Step 5.1: Check the numerical values, range requirements, and data precision in the project.cbm file;

[0023] Step 5.2: Check the data range and accuracy of the project-level CBM file;

[0024] Step 5.3: Check the numerical range and data precision of the professional-grade CBM file;

[0025] Step 5.4: Check the numerical range and data precision of the system-level CBM file;

[0026] Step 5.5: Check the numerical range and data precision of the device-level CBM file;

[0027] Step 5.6: Check the numerical range and data precision of the component-level CBM file.

[0028] Methods for verifying attribute data in FAM files include: compliance verification of attribute data, including whether the data is required, data type, precision, numerical range, and unit.

[0029] The model coding in the verification FAM file adopts a hierarchical and progressive model coding attribute verification method. By checking the preparation of the data to be reviewed, whether the verification code is filled in, whether the number of digits of the verification code is correct, whether each digit of the verification code is compliant, and whether the verification classification code is compliant, the automatic identification and location of coding errors are achieved.

[0030] The beneficial effects of this invention are:

[0031] This invention significantly shortens the GIM model review cycle and avoids the risk of GIM model errors being passed down to downstream stages by automatically reviewing the file structure, equipment attributes, and model coding of the GIM model. In summary, using this invention for automatic verification of GIM model files provides a more reliable model data foundation, significantly improves model quality and delivery efficiency, and provides a more trustworthy digital basis for substation operation and maintenance.

[0032] This addresses the issue that existing GIM data review relies primarily on manual processes, making it difficult to thoroughly check for errors in attribute data and model coding. As a result, errors and omissions often go undetected, leading to frequent data defects such as errors, omissions, and inconsistencies in the GIM model data after handover. This also addresses the technical problems that require maintenance units to spend a significant amount of time and manpower on manual verification when using GIM data. Attached Figure Description

[0033] Figure 1 is a flowchart of the automatic GIM file review process of the present invention;

[0034] Figure 2 is a flowchart of the model coding review process of this invention. Detailed Implementation

[0035] An automatic verification method for GIM model data of substations includes:

[0036] STEP 1: Unzip the GIM file

[0037] After decompressing the GIM file, you should get four folders: CBM, DEV, MOD, and PHM. The files within these folders may have encountered problems or errors during transmission or storage, therefore, it's necessary to use a computer program to automatically verify the GIM file.

[0038] STEP 2: Check the four folders

[0039] After decompressing the GIM file, you should get four folders: CBM, DEV, PHM, and MOD. If the folder names do not meet the requirements for four folders after decompression, the verification will fail and the files will need to be reorganized and checked.

[0040] STEP 3: Check the GIM file format and naming

[0041] In checking the format and naming of GIM files, the first step is to ensure that the file types in the folders strictly conform to the specifications. As shown in Table 1, the four folders (CBM, DEV, PHM, MOD) obtained after decompressing the GIM file should contain specific file types.

[0042] Table 1 GIM File Format Table

[0043]

[0044] The system needs to check each folder for non-compliant file types.

[0045] Secondly, when naming CBM, DEV, PHM, and MOD files, the file naming should follow the following format: <guid><Extension>. Each filename is a 128-bit GUID to ensure its global uniqueness across the system or network. Therefore, each filename should be checked to ensure it conforms to the 128-bit GUID naming requirement. This dual check of format and naming ensures the structural integrity and data consistency of the GIM file.

[0046] STEP 4: Verify the integrity of the CBM file

[0047] (1) Completeness of project.cbm file

[0048] Each CBM folder must contain a project-level project.cbm file, which serves as the entry point for analyzing the entire GIM model. This file must contain the necessary keywords, including BLHA, SUBSYSTEM, SCH, and TYPE. These key fields must be present in the file, and the format of each keyword must conform to the specifications.

[0049] (2) Integrity of project-level CBM files

[0050] Level 1 (project-level) *.cbm files must be placed in the specified CBM folder and correctly referenced in the project.cbm file to ensure the model can load and recognize the project structure smoothly. Project-level CBM files must contain all required keywords, including ENTITYNAME, BASEFAMILY, SUBSYSTEMS.NUM, and SUBSYSTEM. <n>、IFC.NUM、IFC <n>And MATERIALSHEET, these key fields must exist in the file, and the format of each keyword must conform to the specifications.

[0051] (3) Integrity of professional-grade CBM files

[0052] Level 2 (professional level) *.cbm files must be correctly referenced by Level 1 *.cbm files to ensure the integrity of the model hierarchy and proper data loading. The files must contain all required keywords, including ENTITYNAME, SYSCLASSIFYNAME, BASEFAMILY, SUBSYSTEMS.NUM, and SUBSYSTEM. <n>、IFC.NUM、IFC <n>The key fields, such as MATERIALSHEET, must exist in the file, and the format of each keyword must conform to the specifications.

[0053] (4) System-level CBM file integrity

[0054] Level 3 (system-level) *.cbm files must be correctly referenced by Level 2 *.cbm files to ensure the integrity of the model hierarchy and the hierarchical transfer of data. The files must contain all required keywords, including ENTITYNAME, SYSCLASSIFYNAME, SYSTEMNAME1-4, BASEFAMILY1-4, SUBSYSTEMS.NUM, and SUBSYSTEM. <n>、IFC.NUM、IFC <n>The key fields, such as MATERIALSHEET, must exist in the file, and the format of each keyword must conform to the specifications.

[0055] Within a system (region) level CBM file, there can be a maximum of four sub-level files, represented by the four fields SYSTEMNAME1, SYSTEMNAME2, SYSTEMNAME3, and SYSTEMNAME4. The values ​​of these four fields correspond to the values ​​of the four sub-level CBM files. At the same time, the attribute files corresponding to the four sub-level CBM files are the values ​​of the fields BASEFAMILY1, BASEFAMILY2, BASEFAMILY3, and BASEFAMILY4.

[0056] (5) Integrity of device-level CBM files

[0057] Level 4 (device-level) *.cbm files must be correctly referenced by Level 3 *.cbm files to ensure the integrity of the entire model hierarchy and accurate data transfer. The files must contain all required keywords, including ENTITYNAME, SYSCLASSIFYNAME, BASEFAMILY, TRANSFORMMATRIX, OBJECTMODELPOINTER, SUBDEVICES.NUM, and SUBDEVICE. <n>The key fields IFCFILE and IFCGUID must exist in the file, and the format of each keyword must conform to the specification.

[0058] (6) Component-level CBM file structure and integrity

[0059] The Level 5 (part-level) *.cbm file must be correctly referenced by the Level 4 *.cbm file to ensure that part information can be accurately integrated into the overall model structure. The file must contain all required keywords, including ENTITYNAME, PARTNAME, BASEFAMILY, and OBJECTMODELPOINTER. These key fields must exist in the file, and the format of each keyword must conform to the specifications.

[0060] STEP 5: Verify the data range and precision in the CBM file.

[0061] (1) Check the numerical values, range requirements, and data precision in the project.cbm file.

[0062] In the project.cbm file, the BLHA format consists of four numerical values ​​separated by commas. The first three values ​​represent the absolute geographic coordinates of the origin of the engineering model's coordinates: latitude, longitude, and altitude. The latitude and longitude values ​​must be within a reasonable geographic range (e.g., latitude -90 to 90, longitude -180 to 180). The altitude value must also be within a reasonable range (e.g., -100 meters to 100 meters). Latitude and longitude are accurate to eight decimal places, and altitude is accurate to two decimal places. The fourth value is the angle of the engineering model relative to true north, ranging from 0 to 360 degrees, accurate to three decimal places.

[0063] SUBSYSTEM is used to reference first-level (project-level) *.cbm files, with the format SUBSYSTEM= followed by the corresponding filename. SCH is used to reference the project.sch file in the first-level directory, with the format SCH=project.sch. TYPE is used to define the type of substation project, which is divided into three categories: substation, series compensation station, and converter station.

[0064] (2) Check the data range and accuracy of the project-level CBM file.

[0065] In project-level CBM files, the ENTITYNAME field has a fixed identifier and value, which must be F1SYSTEM, used to identify the file as a Level 1 project-level model file. The BASEFAMILY field specifies the attribute file corresponding to the current *.cbm file. This attribute file must actually exist in the CBM folder; if the file is not found in the CBM folder, a file reference error will occur. SUBSYSTEMS.NUM represents the number of referenced Level 2 (professional-level) *.cbm files. This value must be a non-negative integer and must match the actual number of existing SUBSYSTEM files. <n>The number of rows must be exactly the same; this field must exist and be assigned a value of 0 even if no secondary files are referenced. SUBSYSTEM <n>Used to specifically reference second-level *.cbm files, where <n>The indexes must be consecutive, starting from 0 and increasing sequentially; skipped or duplicate numbers are not allowed. (SUBSYSTEM) <n>The number of references, n, must be exactly the same as the value NUM defined in SUBSYSTEMS.NUM; IFC.NUM represents the number of *.ifc files referenced, and must also be a non-negative integer, and must match the actual number of IFC files. <n>The number of rows must remain consistent; even if there is no reference, the field should still be retained and set to 0. IFC <n>Used to reference specific *.ifc files, <n>Similarly, numbers should start from 0 and increment sequentially, without skipping or repeating numbers. Referenced content must be a valid IFC filename. Likewise, IFC... <n>The reference count n must also be consistent with the IFC.NUM value NUM. The MATERIALSHEET field is used to link to supplementary material lists. Although it is not a required field, the field itself must exist. Its value can be empty or point to a valid *.xml file to support the expansion of material information.

[0066] (3) Check the numerical range and data precision of the professional-grade CBM file.

[0067] In professional-level .cbm files, the identifier and value of ENTITYNAME are fixed and must be F2SYSTEM, used to identify the file as a second-level professional-level model file. SYSCLASSIFYNAME represents the professional code corresponding to this second-level *.cbm file, and its value should conform to the provisions of "Classification and Coding Rules for Three-Dimensional Design Models of Power Transmission and Transformation Engineering" (NB / T 11198-2023). The value of the BASEFAMILY field represents the corresponding attribute file, but its value can be empty. SUBSYSTEMS.NUM represents the number of referenced third-level (system or region-level) .cbm files; this value must be a non-negative integer. <n>Index in <n>The values ​​should start from 0 and increment sequentially, without skipping or repeating numbers; even if no third-level file is referenced, this field must be retained and assigned a value of 0. And it must be consistent with the actual existing SUBSYSTEM. <n>The number of rows is exactly the same; SUBSYSTEM <n>Used to specifically reference third-level *.cbm files, where <n>The indexes are sequentially incremented, starting from 0. Each referenced filename should be a 128-bit GUID with the .cbm extension. IFC.NUM represents the number of referenced *.ifc files, which must also be a non-negative integer and correspond to the actual number of IFC files. <n>The number of rows must be consistent; if there is no reference, the field must still exist and be set to 0. IFC <n>Used to reference specific *.ifc files, <n>Starting from 0, numbers must be incremented sequentially without skipping or repeating. Referenced content must be a valid filename. The MATERIALSHEET field is used to link to supplementary material sheets. Although not mandatory, the field must exist. Its value can be empty or point to a valid *.xml file to support the supplementation and management of material information.

[0068] (4) Check the numerical range and data precision of the system-level CBM file.

[0069] In the system-level .cbm file, the identifier and value of ENTITYNAME are fixed and must be F3SYSTEM, used to identify the file as a Level 3 system (region) level model file. SYSCLASSIFYNAME represents the system code corresponding to this Level 3 *.cbm file, and its value should conform to the provisions of "Classification and Coding Rules for Three-Dimensional Design Models of Power Transmission and Transformation Engineering" (NB / T 11198-2023). SYSTEMNAME1 to SYSTEMNAME4 are used to define the four levels of subsystems, where SYSTEMNAME4 can be empty if there is no corresponding subsystem. BASEFAMILY1 to BASEFAMILY4 correspond to the attribute files of the four sub-level systems respectively. SUBSYSTEMS.NUM represents the number of Level 4 (equipment or facility level) .cbm files referenced, must be a non-negative integer, and must match the actual existing SUBSYSTEM. <n>The number of rows must be exactly the same; even if no level 4 files are referenced, this field must be retained and assigned a value of 0. SUBSYSTEM <n>Used to reference specific level 4 *.cbm files, where <n>The indexes must be consecutive, starting from 0 and increasing sequentially. Numbers must not be skipped or repeated. Each referenced filename should be a 128-bit GUID with the .cbm extension. IFC.NUM represents the number of referenced *.ifc files, which must also be a non-negative integer and correspond to the actual number of IFC files. <n>The number of rows must remain consistent; if there is no reference, the field must still exist and be set to 0. IFC <n>Used to reference specific *.ifc files, <n>Starting from 0, numbers must be incremented sequentially. Skipping numbers or using the same number repeatedly is not allowed. Reference formats must be valid filenames. MATERIALSHEET is a supplementary material sheet field; its value can be empty or filled with valid content, depending on the actual situation.

[0070] (5) Check the numerical range and data precision of the device-level CBM file.

[0071] In equipment-level CBM files, the identifier and value of ENTITYNAME are fixed and must be F4SYSTEM, used to identify the file as a Level 4 equipment (facility) level model file. SYSCLASSIFYNAME represents the equipment code corresponding to this Level 4 *.cbm file, and its value should comply with the provisions of "Classification and Coding Rules for Three-Dimensional Design Models of Power Transmission and Transformation Engineering" (NB / T 11198-2023). BASEFAMILY is used to specify the attribute file associated with the current *.cbm file, and its attribute items must follow the relevant provisions in the standard according to the specific type of equipment. TRANSFORMMATRIX represents the spatial transformation matrix of the equipment relative to the origin of the substation coordinates, consisting of 16 values ​​in a 4x4 matrix, with each value separated by an English comma. This matrix is ​​used to describe the local positioning and attitude of the equipment. OBJECTMODELPOINTER is used to reference the corresponding *.dev geometric model file. This file is only allowed to contain one record, and the file naming format is a 128-bit GUID plus the .dev extension. SUBDEVICES.NUM represents the number of referenced component-level *.cbm files. It must be a non-negative integer; if no components are referenced, it should be explicitly assigned a value of 0. <n>Index in <n>The references must start from 0 and increment sequentially without skipping or repeating, and must be consistent with the number NUM in SUBDEVICES.NUM. Each referenced filename should be a 128-bit GUID plus the .cbm extension. The value of IFCFILE can be empty, but the field cannot be omitted; it indicates which *.ifc file the facility or component corresponding to the current *.cbm file is stored in. If no IFC file is associated, its value can be empty. The value of the IFCGUID field must be a GUID string conforming to the IFC standard, used to point to the device object in the IFC file.

[0072] (6) Check the numerical range and data precision of the component-level CBM file.

[0073] The ENTITYNAME identifier and value are fixed and must be PARTINDEX, used to identify the file as a component-level index object. PARTNAME represents the component code corresponding to this component-level *.cbm file, and its value should conform to the provisions of "Classification and Coding Rules for Three-Dimensional Design Models of Power Transmission and Transformation Engineering" (NB / T 11198-2023). BASEFAMILY is used to specify the attribute file associated with the current *.cbm file, which must exist in the CBM folder. OBJECTMODELPOINTER is used to reference the corresponding component *.dev file. The file name format is a 128-bit GUID plus the .dev extension, and it must accurately point to a *.dev file that exists in the DEV file.

[0074] STEP 6: Verify the attribute data in the FAM file

[0075] In the CBM folder, in addition to *.cbm files, there are also *.fam files, which are used to represent the engineering properties of the corresponding system, device, or component. Each line in a *.fam file includes three data items, for example, "Projectname=Project Name=Two-Split Spacer", representing the English attribute name, the Chinese attribute name, and the attribute value, respectively. For quantified attribute values, both quantity and unit can be included.

[0076] The compliance verification of the above attribute values ​​includes five aspects: whether the field is required, data type, precision, numerical range, and unit. The following uses some attributes of an oil-immersed transformer (Table 2) as an example to illustrate the data compliance verification method.

[0077] Table 2. Properties of Oil-Immersed Transformers (Partial)

[0078]

[0079] (1) Check whether the attribute value is filled in

[0080] The number of windings in Table 2 is a required field. It clearly indicates the number of windings in the transformer and is a fundamental characteristic of the transformer structure. The number of windings can be 2, 3, or 4. This information is crucial for the transformer's electrical characteristics and operating mode. Its absence will affect subsequent procurement, operation, maintenance, and repair work.

[0081] For example, "High-voltage to low-voltage impedance voltage (maximum tap)" is not a required field. This parameter reflects the short-circuit impedance characteristics of the transformer at the maximum tap position and is mainly used for power flow calculation and short-circuit analysis under specific operating conditions. In engineering design, some general models may not explicitly provide the specific impedance value for this tap, but only provide the data for the required field "High-voltage to low-voltage impedance voltage (rated tap)".

[0082] (2) Verify attribute data type

[0083] In GIM, attribute data types are categorized into character, floating-point (numeric), integer, date, and boolean types. Character attributes store text information such as names, descriptions, or identifiers. Floating-point / numeric attributes store decimal values. Integer attributes store integer-based values, typically representing counts or levels. For example, the number of windings is an integer. Date attributes record time; for example, the installation date of a transformer might be "2023-05-15". Boolean attributes represent logical states, such as whether a test passed or failed.

[0084] (3) Verify the accuracy of attribute data

[0085] Precision refers to the degree of detail in data attributes. It determines the level of detail to which data can be broken down, thus affecting the depth and accuracy of data analysis. For example, "high-voltage-low-voltage impedance voltage (rated range)" is floating-point data with a precision of two decimal places. This parameter is a core input data for power system flow calculations, short-circuit current calculations, and relay protection settings.

[0086] (4) Verify the value range of attribute data

[0087] There are two forms of data range: one is that the data value is limited to a certain number of specific enumerated values; the other is that the data value must be within a specified numerical range. For example, the range for "number of windings" is "2, 3, 4", which belongs to the enumerated value range, meaning that the data must be selected from a predefined finite set. Although the range for "high voltage - low voltage impedance voltage (rated range)" does not list a specific lower limit, it is clearly recommended that the upper limit not exceed 100%, which belongs to the range value range.

[0088] (5) Verify the units of attribute data

[0089] When assigning values ​​to attributes in a GIM model, a string representing the unit is usually added directly after the quantitative data. When checking attribute data, the numerical value and the unit need to be separated first, and then it needs to be determined whether the unit is in the list of units allowed by the GIM model. For example, the unit of the attribute value of "high voltage rated voltage" should be "KV" instead of "V".

[0090] STEP 7: Verify the model encoding in the FAM file

[0091] According to the "Specification for Interaction and Modeling of 3D Design Models for Power Transmission and Transformation Engineering" (NB / T11199-2023), the "Model Code" attribute must be filled in the corresponding attribute file of the professional, system, equipment, and component CBM. This code must comply with the "Classification and Coding Rules for 3D Design Models of Power Transmission and Transformation Engineering" (NB / T 11198-2023). Due to the complexity of the model coding rules, errors are relatively easy to occur when filling in the model code during the GIM design process, therefore, review is required.

[0092] To address this, a hierarchical, progressive model coding attribute verification method is proposed (see Figure 2). This method involves preparing the data to be reviewed, verifying whether the coding is filled in, verifying whether the coding digits are correct, verifying whether each digit of the coding is compliant, verifying whether the classification code is compliant, and achieving automatic identification and location of coding errors.

[0093] (1) Prepare data to be reviewed

[0094] Based on the aforementioned reference relationship from project.cbm to component-level CBMs, the hierarchical structure files of the GIM model are parsed, and all CBM files requiring review are extracted, preserving their organizational relationship within the overall architecture. The system searches within the CBM folder for "project.cbm → F1-level CBM files → F2-level CBM files → F3-level CBM files → F4-level CBM files → F5-level CBM files". First, the system searches the SUBSYSTEMS.NUM field within the project.cbm file to obtain the total number of top-level F1 CBM files. Then, the system sequentially reads the keywords SUBSYSTEM0…SUBSYSTEMn, extracts the corresponding F1-level CBM filenames, and pushes them into a queue to be traversed. For each F1-level CBM file in the queue, the above process is repeated to find all F2-level CBM files, recursively searching downwards until all F5-level CBM files are found. For some devices without components, only F5-level CBM files can be found in this case. Create a tree structure of the hierarchical objects to be reviewed and store it as a JSON file.

[0095] Simultaneously, the system converts the *.fam file into a *.csv file with the same name. Then, the system assigns the *.csv filename as an attribute to the hierarchical structure nodes, thereby establishing the association between system-level nodes and attribute information, ensuring that each model node can match its corresponding attribute entry. This process extracts all equipment and component nodes and their attribute information, establishes the mapping relationship between nodes and attributes, and generates a raw encoding table containing all objects to be inspected. This table provides a unified data foundation for subsequent engineering correlation verification, encoding format checking, classification code compliance judgment, and uniqueness verification.

[0096] (2) Check if the model code is filled in

[0097] If the model code is not filled in, no further verification is required, and the system will directly give an error message "model code missing".

[0098] (3) Check whether the number of digits in the code is correct.

[0099] According to the requirements of the substation engineering coding system, all valid codes must be 21-bit strings of fixed length. The system only recognizes a code as passing this stage of review if the code length is exactly 21 bits. If the code length is less than 21 bits, the system determines it as "insufficient code bits"; if the code length is greater than 21 bits, it determines it as "too many code bits".

[0100] (4) Verify the compliance of each bit of the code.

[0101] Next, verify whether each character of the encoding conforms to the predefined rules (see Table 3) to ensure that the format is standardized.

[0102] Table 3. Substation Engineering Coding Structure

[0103]

[0104] As shown in Table 3, the model code only allows letters and numbers. Character type A represents characters, and N represents numbers. The substation engineering code is divided into four parts: professional code, system code, equipment code, and component code. Each part can be further subdivided. The subdivided codes include classification codes and serial numbers.

[0105] For example, the explanation of the equipment code "A0ATA*210GTA*101" for a No. 2 main transformer (phase A) is shown in Table 4 below.

[0106] Table 4 Explanation of Equipment Code for Main Transformer #2 (Phase A)

[0107]

[0108] The component codes in Table 4 are all empty, indicating that a No. 2 main transformer (phase A) is a main device and therefore does not contain component codes.

[0109] (5) Verify the compliance of the classification code

[0110] The model coding for substation engineering includes professional codes, system codes, equipment codes, and component codes. Therefore, the compliance of the professional classification codes, system classification codes, equipment classification codes, and component classification codes is reviewed in four stages.

[0111] a) Extract the first digit from the model encoding as the professional classification code segment (G-code), and check if it exists in the predefined type code list (see Table 5). If the code segment does not appear in the list, it is determined to be non-compliant.

[0112] Table 5. Professional Type Codes for Substation Engineering (Partial)

[0113]

[0114] b) Extract the characters from the 2nd to the 6th position from the model encoding as the system classification code segment (F0F1F2F3F4 encoding), and check if it exists in the predefined system code list (see Table 6). If the code segment does not appear in the list, it is determined to be non-compliant.

[0115] Table 6 System Classification Codes for Substation Projects (Partial)

[0116]

[0117] c) Extract characters from positions 10 to 13 of the model encoding as the device classification code segment (A1A2A3A4 encoding) and check if it exists in the predefined device code list (see Table 7). If the code segment does not appear in the list, it is determined to be non-compliant.

[0118] Table 7. Classification Codes for Electrical Equipment in Substation Projects (Partial)

[0119]

[0120] d) The system extracts characters from the 17th to the 19th position of the code as the component classification code (B1B2B3) and checks whether it exists in the predefined device code list (see Table 8). If the code segment does not appear in the list, it is determined to be non-compliant.

[0121] Table 8. Component Classification Codes for Substation Projects (Partial)

[0122]

[0123] (6) Verification of the uniqueness of the verification number

[0124] After completing the compliance review of the Level 4 classification codes, the uniqueness of the numbers in the model coding also needs to be reviewed. This aims to ensure that the numbers of the same type of system, equipment, and component under the same coding level are not duplicated, thus guaranteeing the uniqueness of the codes throughout the entire project.

[0125] First, the system analyzes the parent-child relationship structure of each node, grouping nodes with the same parent node together to ensure that the uniqueness check of the number is performed within the same model decomposition level. After completing the node grouping, the system sequentially performs the uniqueness check of the number at each level:

[0126] a) Check the uniqueness of the system ID. The system extracts the 7th to 9th characters from the code of each node as the system ID. If multiple nodes in the same parent node group have the same system ID, it is considered a duplicate ID and an error is recorded.

[0127] b) Check the uniqueness of the device number. The system extracts the 13th to 16th characters of the code as the device number and checks for duplicates among nodes in the same group. If the same device number is found to be used by multiple nodes, it is determined as a duplicate device number, and an error is recorded.

[0128] c) Check the uniqueness of the component number. The system extracts the 20th and 21st characters of the code as the component number and performs a uniqueness check between component nodes at the same level. If duplicate numbers exist, it indicates that there is a duplicate component number under the same device level, and an error is recorded.

[0129] (7) Check the consistency between the full encoding of FAM and the fragment encoding of CBM.

[0130] As mentioned earlier, in CBM files at different levels, the professional-level CBM, system-level CBM, and equipment-level CBM all have a SYSCLASSIFYNAME attribute, which is a required field. This attribute records the classification code fragments for the professional engineering, system, and equipment of the substation, respectively. The classification code fragment for the professional engineering corresponds to the level 0 type code (digit 1) of the FAM model encoding; the classification code fragment for the system corresponds to the level 1 system code (digits 2 to 6) of the FAM model encoding; and the classification code fragment for the equipment corresponds to the level 2 equipment code (digits 10 to 13). Therefore, the model encoding in the equipment attribute file (FAM) needs to be verified for consistency with the SYSCLASSIFYNAME attribute in its peer-level equipment CBM file. It also needs to be verified for consistency with the SYSCLASSIFYNAME attribute in its parent-level system CBM file, and further with the SYSCLASSIFYNAME attribute in its grandparent-level professional CBM file. When inconsistencies are found, the error is logged in the audit log file.

[0131] It should be noted that a JSON file was generated during the first step of preparing the data to be reviewed. This file contains a hierarchical model structure: "project.cbm → F1 level CBM file → F2 level CBM file → F3 level CBM file → F4 level CBM file → F5 level CBM file". Specifically, the F2 level CBM file corresponds to the professional CBM file, the F3 level CBM file corresponds to the system CBM file, and the F4 level CBM file corresponds to the equipment CBM file.

[0132] (8) Generate model coding review log

[0133] Table 9. Classification and Description of Coding Errors

[0134]

[0135] The system outputs error information found in each review process to a unified review log file. This file is in CSV format, with each line recording one model coding error. Each line contains three fields, separated by commas. The first field is the "filename," recording the FAM file that malfunctioned. The second field is the "error type code," using a three-digit code (see Table 9) to uniquely identify the error category; for example, 301 and 303 represent "insufficient coding bits" and "excessive coding bits," respectively. The third field is the "error description," providing a semantic explanation of the error in Chinese text. Error records are written to the log file sequentially according to the execution order of the review process.< / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / guid> < / n> < / n> < / n> < / n>

Claims

1. A method for automatic verification of GIM model data of substations, characterized in that: The method includes: Step 1, decompressing the GIM file; Step 2, checking if the CBM, DEV, MOD, and PHM folders are complete after decompression, and decompressing again if incomplete; Step 3, checking the GIM file format and naming; Step 4, verifying the integrity of the CBM file; Step 5, verifying the data range and accuracy in the CBM file; Step 6, verifying the attribute data in the FAM file; Step 7, verifying the model encoding in the FAM file.

2. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: Checking the GIM file format and naming includes: checking for non-compliant file types in each folder of CBM, DEV, MOD, and PHM; and checking whether each file name conforms to the naming requirements of a 128-bit GUID.

3. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: The method for verifying the integrity of CBM files includes: Step 4.1, verifying the integrity of the project.cbm file, which includes the keywords BLHA, SUBSYSTEM, SCH, and TYPE; and the format of each keyword must conform to the specifications; Step 4.2, verifying the integrity of the project-level CBM file; the project-level CBM file must contain ENTITYNAME, BASEFAMILY, SUBSYSTEMS.NUM, and SUBSYSTEM <n>、IFC.NUM、IFC <n>And MATERIALSHEET, and the format of each keyword must conform to the specifications; Step 4.3, verify the integrity of the professional-level CBM file; the second-level *.cbm file must be correctly referenced by the first-level *.cbm file, and the file must contain the keywords ENTITYNAME, SYSCLASSIFYNAME, BASEFAMILY, SUBSYSTEMS.NUM, SUBSYSTEM <n>、IFC.NUM、IFC <n> For the MATERIALSHEET file, key fields must exist in the file and the format of each keyword must conform to the specifications; Step 4.4: Verify the integrity of the system-level CBM file; Level 3 *.cbm files must be correctly referenced by Level 2 *.cbm files, and the files must contain all specified keywords, with each keyword format conforming to the specifications; Step 4.5: Verify the integrity of the device-level CBM file; Level 4 *.cbm files must be correctly referenced by Level 3 *.cbm files, and the files must contain all specified keywords, with key fields existing in the file and each keyword format conforming to the specifications; Step 4.6: Verify the structure and integrity of the component-level CBM file; Level 5 *.cbm files must be correctly referenced by Level 4 *.cbm files, and the files must contain all specified keywords, with each keyword format conforming to the specifications.< / n> < / n> < / n> < / n> 4. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: Verifying the data range and accuracy in CBM files includes: Step 5.1, checking the numerical and range requirements and data accuracy of the project.cbm file; Step 5.2, checking the data range and accuracy of the project-level CBM file; Step 5.3, checking the numerical range and data accuracy of the professional-level CBM file; Step 5.4, checking the numerical range and data accuracy of the system-level CBM file; Step 5.5, checking the numerical range and data accuracy of the equipment-level CBM file; Step 5.6, checking the numerical range and data accuracy of the component-level CBM file.

5. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: Methods for verifying attribute data in FAM files include: compliance verification of attribute data, including whether the data is required, data type, precision, numerical range, and unit.

6. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: The model coding in the verification FAM file adopts a hierarchical and progressive model coding attribute verification method. By checking the preparation of the data to be reviewed, whether the verification code is filled in, whether the number of digits of the verification code is correct, whether each digit of the verification code is compliant, and whether the verification classification code is compliant, the automatic identification and location of coding errors are achieved.

7. The automatic verification method for GIM model data of substations according to claim 1, characterized in that: The method for verifying the model coding in the FAM file includes: Step 7.1: Based on the reference relationship from project.cbm to component-level CBMs, parse the hierarchical structure file of the GIM model, extract all CBM files that need to be reviewed, form a tree structure of the hierarchical objects to be reviewed, and store it as a JSON file; convert the *.fam file to a *.csv file with the same name, assign the *.csv file name as an attribute to the hierarchical structure node, extract all equipment and component nodes and their attribute information, establish the mapping relationship between nodes and attributes, and generate an original coding table containing all objects to be inspected; Step 7.2: Verify whether the model coding is filled in. If the model coding is not filled in... If the code is not found to be valid, no further verification will be performed, and an error message "model code missing" will be directly given. Step 7.3: Check if the number of bits in the code is correct. A valid code is a fixed-length 21-bit string. Step 7.4: Check the compliance of each bit of the code, ensuring that each character conforms to predefined rules and format specifications. Step 7.5: Check the compliance of the classification codes, reviewing the compliance of the professional classification codes, system classification codes, equipment classification codes, and component classification codes respectively. Step 7.6: Check the uniqueness of the numbering, verifying the uniqueness of the numbering in the model code. Step 7.7: Check the consistency between the complete code of FAM and the fragment code of CBM. Step 7.8: Generate a model code review log.

8. The automatic verification method for GIM model data of substations according to claim 7, characterized in that: The method for verifying the compliance of classification codes includes: Step 7.5.1: Extract the first character from the model code as the professional classification code segment and check if it exists in the predefined type code list. If the code segment does not appear in the list, it is determined to be non-compliant; Step 7.5.2: Extract the characters from the 2nd to the 6th position from the model code as the system classification code segment and check if it exists in the predefined system code list. If the code segment does not appear in the list, it is determined to be non-compliant; Step 7.5.3: Extract the characters from the 10th to the 13th position from the model code as the equipment classification code segment and check if it exists in the predefined equipment code list. If the code segment does not appear in the list, it is determined to be non-compliant; Step 7.5.4: Extract the characters from the 17th to the 19th position from the model code as the component classification code and check if it exists in the predefined equipment code list. If the code segment does not appear in the list, it is determined to be non-compliant.

9. The automatic verification method for GIM model data of substations according to claim 7, characterized in that: The method for verifying the uniqueness of the serial number includes: First, analyzing the parent-child relationship structure of each node, grouping nodes with the same parent node into the same group. After completing the node grouping, performing uniqueness checks on the serial numbers at each level sequentially, including: Step 7.6.1, checking the uniqueness of the system serial number; extracting the 7th to 9th characters from the code of each node as the system serial number. If more than one node in the node group contained in the same parent node has the same system serial number, it is considered a duplicate serial number and an error is recorded; Step 7.6.2, checking the uniqueness of the device serial number; extracting the 13th to 16th characters from the code as the device serial number, performing duplicate checks on nodes in the same group. If the same device serial number is found to be used by more than one node, it is determined to be a duplicate device serial number and an error is recorded; Step 7.6.3, checking the uniqueness of the component serial number; extracting the 20th to 21st characters from the code as the component serial number, performing uniqueness checks on component nodes at the same level. If duplicate serial numbers exist, it indicates that duplicate component serial numbers have occurred at the same device level and an error is recorded.

10. The automatic verification method for GIM model data of substations according to claim 7, characterized in that: The method for checking the consistency between the complete encoding of the FAM and the CBM fragment encoding is as follows: the model encoding in the device attribute file FAM is verified for consistency with the SYSCLASSIFYNAME attribute in the device CBM file at the same level, the SYSCLASSIFYNAME attribute in the parent system CBM, and the SYSCLASSIFYNAME attribute in the grandparent professional CBM file; when inconsistencies are found, the error is logged in the audit log file.

Images