A wind turbine whole machine simulation model file parsing and checking method and system

Abstract

The application relates to the technical field of power system data processing, and discloses a wind turbine whole machine simulation model file analysis and verification method and system, which comprises the following steps: obtaining a set of model files to be analyzed, identifying a format type and a file reference relationship; calling a format adapter to perform format pre-checking, coding conversion and version compatibility judgment; scheduling a physical domain analyzer to extract simulation model parameters and map the simulation model parameters to a unified model object; performing cross-module reference checking, unit normalization and parameter range checking; generating a hierarchical verification result based on file-level, module-level and parameter-level verification, and outputting the unified model object, an analysis metadata report or an error diagnosis report. The technical scheme of the application realizes unified analysis and hierarchical quality verification of multi-source heterogeneous simulation model files, and improves model migration efficiency and data integrity verification accuracy.

Description

Technical Field

[0001] This invention belongs to the field of power system data processing technology, specifically relating to a method and system for parsing and verifying simulation model files of wind turbine generator sets. Background Technology

[0002] Wind turbine whole-machine simulation is a crucial step in wind turbine design, control strategy verification, load analysis, and digital testing. As the capacity of individual wind turbines continues to increase, blade length, tower height, transmission chain complexity, control logic complexity, and coupling factors from the marine environment also increase. Whole-machine simulation models typically need to simultaneously describe multiple types of parameters, including aerodynamics, structure, control, electrical, environmental, transmission chain, and simulation configuration. These parameters are scattered across different model files, module files, or project files, and there are strong cross-module relationships between them.

[0003] Existing wind turbine simulation software typically uses its own model file system to store model data. For example, different simulation platforms may organize model parameters using binary project files, combinations of main input files and submodule files, text configuration files, or user-defined intermediate files. During cross-platform migration, version iteration, or model quality checks, engineers usually need to rely on manual document review, calling platform-specific interfaces, writing temporary scripts, or comparing parameter tables item by item to complete document reading and parameter verification.

[0004] However, existing model file processing methods still suffer from insufficient adaptability and integrity control. On the one hand, different simulation platforms have significant differences in file formats, encoding methods, version fields, parameter naming, and file reference relationships, making manual conversion prone to parameter loss, unit inconsistencies, or incorrect reference paths. On the other hand, existing verification methods mostly remain at the level of single-file readability checks or overall file verification, making it difficult to pinpoint the specific dependencies that cause errors, and also difficult to detect parameter anomalies that are formatted correctly but have unreasonable physical meanings. Furthermore, during multiple version iterations of model files, if only some module parameters are modified, existing methods usually still require extensive and repetitive checks, impacting engineering verification efficiency.

[0005] Therefore, there is an urgent need for a method for parsing and verifying the simulation model files of wind turbine generators, in order to improve the automation level of multi-source heterogeneous model file processing, the ability to locate data integrity verification, and the reliability of model cross-platform migration. Summary of the Invention

[0006] This invention provides a method for parsing and verifying simulation model files of wind turbine generator sets. The solution of this invention solves the problems in the prior art of difficult unified processing of multi-format model files, difficulty in detecting cross-module parameter errors, and lack of location support for verification results by performing format recognition, standardized parsing, semantic checking, and hierarchical integrity judgment on multi-source model files in the simulation model of wind turbine generator sets.

[0007] In a first aspect, the present invention provides a method for parsing and verifying a simulation model file of a wind turbine generator set, the method comprising: Obtain the set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format identification results; Based on the format recognition result, the corresponding format adapter is called to perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and preprocessed file data is generated. Based on the preprocessed file data, the physical domain resolver extracts simulation model parameters, maps the simulation model parameters to multiple data domains of a unified model object, and generates intermediate model data. Based on the intermediate model data, cross-module reference checks, physical unit normalization, and parameter reasonableness range checks are performed to generate semantic verification results. Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity verifications are performed to generate hierarchical verification results.

[0008] By adopting the above scheme, the wind turbine whole-machine simulation model file parsing and verification method of the present invention achieves unified determination of the parsing object of multi-source heterogeneous simulation model files by identifying the format type and file reference relationship of the set of model files to be parsed; by using format adapter, physical domain parser and data domain mapping of unified model object, it realizes the conversion of model parameters from different sources to standardized intermediate model data; furthermore, by using progressive verification at the file level, module level and parameter level, it identifies problems such as file corruption or missing necessary structures, incomplete data domain parameters and inconsistent cross-domain physical relationships, thereby improving the completeness, traceability and engineering applicability of the wind turbine whole-machine simulation model file parsing results.

[0009] In some embodiments of the present invention, the step of identifying the format type and file reference relationship of the model files in the set of model files to be parsed, and generating a format identification result, includes: Read the file extension of the model file and generate candidate format types; Read the file header features of the model file, confirm the candidate format types based on the file header features, and generate a format confirmation result; Read the local structure of the model file according to the trial parsing rules corresponding to the format verification result, and generate the format verification result; Based on the format confirmation result and the format verification result, the format type is determined, and the reference paths between the model files are parsed to generate a format identification result that includes the format type and the file reference relationship.

[0010] In some embodiments of the present invention, the step of calling the corresponding format adapter based on the format recognition result to perform format pre-detection, encoding conversion, and version compatibility judgment on the set of model files to be parsed, and generating preprocessed file data, includes: When the format type is Bladed project format, the Bladed adapter is called to read the data block identifier, data block length, header field and payload data, and generate binary block structure data; When the format type is OpenFAST input file format, the OpenFAST adapter is invoked to establish a file reference topology based on the main input file and submodule files, and generate text file tree data. When the format type is a custom text format, the custom format adapter is invoked to generate structured mapping data based on the key path mapping template or the hierarchical mapping template; The binary block structure data, the text file tree data, or the structured mapping data are subjected to syntax pre-checking, encoding conversion, and version compatibility judgment to generate the preprocessed file data.

[0011] In some embodiments of the present invention, the step of mapping the simulation model parameters to multiple data domains of a unified model object to generate intermediate model data includes: The physical domain mapping rules determine the blade geometry domain, control parameter domain, environmental parameter domain, structural parameter domain, transmission chain parameter domain, electrical parameter domain, and simulation configuration domain. The target data domain is determined based on the parameter name, parameter path, data dimension, and physical unit of the simulation model parameters; The simulation model parameters are written into the target data domain in the form of key-value pairs, wherein the value type of the key-value pairs includes at least one of scalar, one-dimensional array, two-dimensional matrix and interpolation table; The multiple data fields that have been written are assembled into the unified model object to generate the intermediate model data.

[0012] In some embodiments of the present invention, the step of performing cross-module reference checks, physical unit normalization, and parameter reasonableness range checks based on the intermediate model data to generate semantic verification results includes: Extract parameter reference identifiers between different data fields in the intermediate model data, determine whether the referenced parameters exist, and generate a reference integrity check result. Identify the source units corresponding to the physical quantities in the intermediate model data, convert the source units into preset standard units, and generate unit-normalized data. Based on the wind turbine design parameter range library, the reasonable range of key parameters is determined, and the parameter range check results are generated according to the unit normalized data and the reasonable range. The semantic verification result is generated by summarizing the reference integrity check result, the unit normalized data, and the parameter range check result.

[0013] In some embodiments of the present invention, file-level, module-level, and parameter-level integrity checks are performed based on the intermediate model data and the semantic verification results, wherein file-level integrity checks include: Calculate the file checksum for each model file in the set of model files to be parsed, and generate the file integrity check result; Based on the format type in the format identification result, determine the required files, required data segments, or required data blocks, and generate a list of required structures. The set of model files to be parsed is compared with the list of required structures to generate a file structure integrity check result; Based on the file integrity check results and the file structure integrity check results, a file-level verification result is generated.

[0014] In some embodiments of the present invention, file-level, module-level, and parameter-level integrity checks are performed based on the intermediate model data and the semantic verification results, wherein the module-level integrity check includes: Deterministic serialization processing is performed on multiple data domains of the unified model object to generate data domain serialization results; Calculate the module-level checksum for the serialization result of the data field and generate the module integrity check result; Count the number of parameters successfully parsed and mapped to the unified model object in each data domain, and generate parameter coverage based on the preprocessed file data or the list of format specification field definitions in the source file to count the total number of parameters actually existing in the source file. Module-level verification results are generated based on the module integrity check results and the parameter coverage.

[0015] In some embodiments of the present invention, file-level, module-level, and parameter-level integrity checks are performed based on the intermediate model data and the semantic verification results, wherein the parameter-level integrity check includes: Power parameters, aerodynamic parameters, blade geometry parameters, blade mass parameters, and operating frequency parameters are extracted from the intermediate model data to generate a set of key parameters; Based on the set of key parameters, power balance relationship verification, blade quality self-consistency verification, and resonance avoidance condition verification are performed to generate cross-domain consistency check results. Based on the cross-domain consistency check result and the parameter-level alarm level, a parameter-level verification result is generated, and the parameter-level verification result is written into the hierarchical verification result.

[0016] In some embodiments of the present invention, the method further includes: comparing the hierarchical verification result with preset pass conditions, the preset pass conditions including passing file-level verification, module-level parameter coverage not lower than a preset coverage threshold, and no severe alarms in parameter-level verification; when the hierarchical verification result meets the preset pass conditions, recording the execution time of each parsing stage, the parameter coverage of each data domain, the verification results of each layer, and non-severe alarm information, and generating a parsing metadata report; when the hierarchical verification result does not meet the preset pass conditions, generating error location data based on the failure locations in the file-level, module-level, and parameter-level integrity verification; determining the error type, impact level, and repair suggestions based on the error location data, and generating an error diagnosis report; identifying the modified data domain based on the module-level verification, determining the data domain with cross-domain dependency based on the parameter reference identifier or cross-domain consistency check result in the intermediate model data, performing incremental verification on the modified data domain and the data domain with cross-domain dependency, generating incremental verification results, and updating the hierarchical verification result based on the incremental verification results.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention integrates Bladed project files, OpenFAST input file systems, and custom configuration files such as JSON / YAML into a single parsing entry point by recognizing format types, parsing file reference relationships, performing format pre-detection, encoding conversion, and version compatibility judgment. This enables unified access and preprocessing of multi-source heterogeneous model files, reducing the reliance on manual file recognition and manual parameter conversion during cross-platform model migration in wind turbine simulation models.

[0018] This invention extracts simulation model parameters through a physical domain resolver and maps these parameters to the blade geometry domain, control parameter domain, environmental parameter domain, structural parameter domain, transmission chain parameter domain, electrical parameter domain, and simulation configuration domain of a unified model object. This allows parameters scattered across different files, modules, and formats to form unified intermediate model data. Through cross-module reference checks, physical unit normalization, and parameter reasonableness range checks, the model file undergoes semantic-level quality screening before entering downstream simulation or conversion.

[0019] This invention employs hierarchical integrity verification at the file, module, and parameter levels to classify and determine issues such as file corruption and missing essential structures, insufficient data domain integrity and parsing coverage, inconsistencies in cross-domain parameters, and physical anomalies. Furthermore, by parsing metadata reports, error diagnosis reports, and incremental verification mechanisms, the verification results are made locatable, traceable, and reusable, thereby improving the accuracy of integrity verification of wind turbine whole-machine simulation model files and the efficiency of engineering review.

[0020] A second aspect of the present invention provides a system for parsing and verifying simulation model files of wind turbine generator sets, comprising: The format recognition module is used to obtain a set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format recognition results. The file preprocessing module is used to call the corresponding format adapter based on the format recognition result, perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and generate preprocessed file data. The model parsing module is used to schedule the physical domain parser to extract simulation model parameters based on the preprocessed file data, map the simulation model parameters to multiple data domains of a unified model object, and generate intermediate model data. The semantic verification module is used to perform cross-module reference checks, physical unit normalization, and parameter reasonableness range checks based on the intermediate model data, and generate semantic verification results. The integrity verification module is used to perform file-level, module-level, and parameter-level hierarchical integrity verification based on the intermediate model data and the semantic verification results, and generate hierarchical verification results. The result output module is used to output the unified model object and parsed metadata report when the hierarchical verification result meets the preset pass conditions; and to output an error diagnosis report when the hierarchical verification result does not meet the preset pass conditions.

[0021] In a third aspect, the present invention provides a device for parsing and verifying a wind turbine whole-machine simulation model file. The device includes a computer device, which includes a processor and a memory. The memory stores computer instructions. When the computer instructions are executed, the device implements the method for parsing and verifying the wind turbine whole-machine simulation model file.

[0022] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows, and will also become apparent in part to those skilled in the art upon studying the text, or may be learned by practice of the invention. The objects and other advantages of the invention will become apparent from the description and the accompanying drawings.

[0023] Those skilled in the art will understand that the objectives and advantages achievable with the present invention are not limited to those specifically described above, and that the above and other objectives achievable with the present invention will become clearer from the following detailed description. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0025] In the attached diagram: Figure 1 This is a flowchart illustrating a method for parsing and verifying a wind turbine whole-machine simulation model file, provided in an embodiment of the present invention.

[0026] Figure 2 This is a diagram illustrating the parser module architecture provided in an embodiment of the present invention.

[0027] Figure 3 A flowchart of a three-layer integrity verification process provided for an embodiment of the present invention.

[0028] Figure 4 This is a schematic diagram of a wind turbine whole-machine simulation model file parsing and verification system provided in an embodiment of the present invention.

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0030] The present invention will now be described in detail with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other.

[0031] The following detailed description is exemplary and intended to provide further detailed explanation of the invention. Unless otherwise specified, all technical terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used in this invention is for the purpose of describing particular embodiments only and is not intended to limit the scope of exemplary embodiments according to the invention.

[0032] Figure 1 This is a flowchart illustrating a method for parsing and verifying a wind turbine whole-machine simulation model file, provided by an embodiment of the present invention.

[0033] This embodiment provides a method for parsing and verifying simulation model files of wind turbine generators. It is applicable to scenarios where multi-source heterogeneous model files, such as Bladed project files, OpenFAST main input files and their associated submodule files, custom JSON files, and YAML files, need to be parsed and their integrity verified in a unified manner. This embodiment uses a model file of a 15 MW wind turbine generator as an example for illustration. The Unified Model Object (UMO) represents a standardized intermediate data object formed by organizing model parameters from different sources according to the physical domain of the wind turbine generator; the Parameter Coverage Ratio (PCR) represents the proportion of parameters successfully parsed and mapped to the Unified Model Object to the total number of parameters that should actually be parsed in the source file; and the Critical level indicates the level of verification anomaly that would lead to incomplete model structure, invalid key physical relationships, or distorted simulation results.

[0034] Example 1, such as Figure 1 As shown, the present invention provides a method for parsing and verifying a wind turbine whole-generator simulation model file, the method comprising the following steps: S1. Obtain the set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format identification results; S2. Based on the format recognition result, call the corresponding format adapter to perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and generate preprocessed file data; S3. Based on the preprocessed file data, schedule the physical domain resolver to extract simulation model parameters, map the simulation model parameters to multiple data domains of a unified model object, and generate intermediate model data. S4. Based on the intermediate model data, perform cross-module reference checks, physical unit normalization, and parameter reasonableness range checks to generate semantic verification results; S5. Perform file-level, module-level, and parameter-level integrity checks based on the intermediate model data and the semantic verification results to generate hierarchical verification results.

[0035] By adopting the above scheme, the wind turbine whole-machine simulation model file parsing and verification method of the present invention, by identifying the format type and file reference relationship of the model file, enables single-file binary project structure, multi-file text reference structure and custom hierarchical structure to enter a unified parsing process; through the collaborative processing of format adapter, physical domain parser and unified model object, simulation model parameters of different platforms, different versions and different data organization methods are converted into intermediate model data with consistent structure; through cross-module reference check, unit normalization and parameter range check, parameter references, numerical units and engineering values ​​in the source file are uniformly processed before integrity verification; furthermore, through progressive verification at the file level, module level and parameter level, problems such as file corruption or missing necessary structures, incomplete data domain parameters and inconsistent cross-domain physical relationships are identified respectively, thereby improving the integrity, traceability and engineering applicability of the wind turbine whole-machine simulation model file parsing results.

[0036] This invention first defines a Unified Model Object (UMO) intermediate representation layer, serving as the target data structure for parsing all formats and a unified carrier for subsequent verification. The UMO design follows the "physical domain mapping" principle, meaning its data organization is consistent with the natural physical subsystem division of the wind turbine, including the following seven data domains: (1) Blade Geometry Domain: Contains airfoil section data (section number) Relative thickness Lift coefficient table (etc.), chord length distribution Angle distribution Pre-bending distribution Pre-torsion distribution Discrete nodal coordinates along the blade span. All geometric parameters are represented by a unified dimensionless spanwise position. Parameterization.

[0037] (2) Control Parameter Domain: Contains pitch control parameters (pitch angle range) Pitch rate Generator torque control parameters (speed-torque curve, rated torque) ), Yaw control parameters (yaw angle) Yaw rate ) and filter parameters (cutoff frequency) Damping ratio ).

[0038] (3) Environmental Parameter Domain: Includes wind parameters (reference height) Average wind speed turbulence intensity Wind shear index Wave parameters (effective wave height) Spectral peak period ), ocean current parameters and water surface parameters.

[0039] (4) Structural Parameter Domain: Includes tower geometry and material parameters, foundation stiffness matrix Modal quality Modal damping and stiffness distribution of each section .

[0040] (5) Drive Train Parameter Domain: Includes gearbox transmission ratio Moment of inertia , Bearing stiffness and damping parameters.

[0041] (6) Electrical Parameter Domain: Contains generator parameters (rated power) Rated current (etc.), converter control parameters and collector line parameters.

[0042] (7) Simulation Configuration Domain: Includes time steps Simulation duration Global simulation settings such as output channel list and solver options.

[0043] Parameters within each data domain are stored as key-value pairs, with values ​​supporting four basic types: scalar, one-dimensional array, two-dimensional matrix, and interpolation table. This design ensures that model files of different formats are uniformly represented as a structured UMO after parsing, laying the foundation for subsequent cross-format validation and comparative analysis.

[0044] This invention employs a modular end-to-end parsing pipeline, comprising five standardized stages, each stage being sequentially connected in a pipeline manner.

[0045] In step S1, the set of model files to be parsed consists of the user-specified model entry file and related files discovered based on the model entry file. For the Bladed project format, the model entry file can be a project file with the extension ".prj"; for the OpenFAST input file format, the model entry file can be a main input file with the extension ".fst", and the related files can be submodule files such as AeroDyn, ElastoDyn, BeamDyn, InflowWind, ServoDyn, HydroDyn, SubDyn, and MoorDyn, as well as airfoil data files, structural data files, or controller files referenced by the submodules; for the custom text format, the model entry file can be a JSON file or a YAML file, and the related files can be external parameter files pointed to by the file path field.

[0046] Specifically, in stage 1, format recognition adopts a progressive recognition method, which involves preliminary judgment of file extension, confirmation of file header features, and tentative parsing verification.

[0047] After receiving the input file, the parsing pipeline performs automatic format recognition. The three-layer decision logic of the recognition algorithm is as follows: (a) Preliminary determination of file extensions (.prj→Bladed, .fst / .dat→OpenFAST, .json→JSON, .yaml→YAML); (b) File header feature byte detection (the header of the Bladed .prj file contains a fixed magic number 0x9E2A83C1, and the first line of the OpenFAST main input file is the feature string "- FAST v"). (c) Trial parsing verification (shallow reading with the parser of the candidate format and checking for parsing anomalies).

[0048] First, the file extensions of the model files are read to generate candidate format types. For example, when the file extension is ".prj", candidate results for the Bladed project format are generated; when the file extension is ".fst" or ".dat", candidate results for the OpenFAST input file format are generated; and when the file extension is ".json" or ".yaml", candidate results for the custom text format are generated. The file extension is only used as a preliminary identification criterion and is not directly used as the final format conclusion to avoid misjudgments when file extensions are incorrectly modified or when the same extension is used on different platforms.

[0049] Furthermore, the file header features of the model files are read. For bladed project files, fixed bytes in the header, the project identifier field, and the version field can be read to determine if header features corresponding to the bladed project structure exist. In one specific implementation, the magic number 0x9E2A83C1 in the header can be detected. For OpenFAST main input files, the first line of the version string and key fields such as FAST_VersionKey, AeroFile, EDFile, and ServoFile can be read. For JSON and YAML files, paired brackets, key-value separators, indentation levels, and document start and end markers can be detected, respectively. Based on the file header features, candidate format types are confirmed, and format confirmation results are generated.

[0050] After obtaining the format confirmation result, the shallow parser corresponding to the candidate format is invoked to read the local structure of the model file. For binary project files, the shallow parser reads the data block identifier and data block length of the first data block, and determines whether the data block length falls within the file boundary. For OpenFAST input files, the shallow parser reads a preset number of parameter lines, and determines whether the parameter values, parameter names, and comment fields meet the line format of the corresponding module. For JSON or YAML files, the shallow parser attempts to build a local document tree, and determines whether the key path and hierarchical structure are parsable. If no structural conflict or parsing anomaly occurs during the shallow parsing process, a format verification pass result is generated. If a data block goes out of bounds, the parameter line format does not match, or the document tree construction fails, the recognition confidence of the corresponding candidate format is reduced or the next candidate format is switched to continue verification.

[0051] For model files containing file references, the format recognition process also parses file reference relationships. In the OpenFAST adaptation scenario, using the ".fst" main input file as the root node, reference fields such as AeroFile, EDFile, ServoFile, InflowFile, HydroFile, SubFile, and MooringFile are extracted. Relative or absolute paths are parsed based on these reference fields, and the reference fields within each submodule file are further read to form a directed file reference topology. In the custom text format scenario, associated file paths are extracted based on the file reference keys defined in the mapping template. Bladed project formats typically encapsulate multiple data blocks in a single project file; therefore, the data block hierarchy within the project file can be recorded as an internal file reference relationship. Finally, the model file's format type, preliminary version information, entry file identifier, associated file paths, and file reference topology are all written into the format recognition result.

[0052] Taking the file "WTG_15MW_v3.prj" as an example, after reading the extension ".prj", a candidate result for the Bladed project format is generated; the first 4 bytes of the file header are read to detect the preset magic number, further confirming that the file is in the Bladed project format; the version field is read to obtain the version number v5.7.3; the first project data block is shallowly read to confirm that the data block identifier and length fields are consistent with the file boundary, generating a format verification pass result. Since the model data in this project file is organized in internal data blocks, no further external submodule files are found. The format identification result marks this project file as the entry file and records its internal data block index relationship.

[0053] In step S2, the corresponding format adapter is invoked based on the format type in the format recognition result. The format adapter is located between the source file organization structure and the physical domain resolver, and is used to convert binary blocks, text parameter lines, or hierarchical key paths in different file formats into a unified accessible data structure without directly changing the physical meaning of the parameters.

[0054] After format recognition in step 1, the process proceeds to stage 2, where a file-level pre-check is performed. (a) Syntax validation: For text formats (OpenFAST .dat, JSON, YAML), perform lexical and syntactic analysis using the corresponding grammar rules to detect format errors; (b) Encoding standardization: uniformly convert to UTF-8 encoding, and perform transcoding mapping for non-ASCII characters; (c) Version identification and compatibility judgment: The version marker fields inside the parser file (such as the version number range of Bladed.prj and the FAST_VersionKey parameter of OpenFAST) are compared with the version range supported by the parser, and an alarm is issued when an incompatibility problem is encountered.

[0055] When the format type is Bladed project format, the Bladed adapter is invoked to read the data block identifier, data block length, header field, and payload data, generating binary block structure data. Each data block in the Bladed project file can be represented as a quadruple of "data block identifier + data block length + header field + payload data". The Bladed adapter maintains a data block mapping table, which records the data block identifier, corresponding physical domain resolver, field offset, field length, numeric type, source unit, and version applicable range. The adapter traverses all data blocks, verifying whether the data block identifier exists in the data block mapping table and verifying whether the declared length of the data block is consistent with the actual payload length. For data blocks containing nested arrays or nested tables, they are recursively expanded according to the parent node field, the number of child nodes, and the length of the child nodes until the leaf node field that can be directly read by the physical domain resolver is obtained. For example, the lift coefficient and drag coefficient in the blade aerodynamic characteristic table can be recursively expanded according to the multi-level index corresponding to the angle of attack, Reynolds number, or relative thickness.

[0056] When the format type is OpenFAST input file format, the OpenFAST adapter is invoked to parse the main input file and associated submodule files. The OpenFAST adapter first constructs a text file tree based on the file reference topology in the format recognition result, with the ".fst" main input file as the root node, and submodule files such as AeroDyn, ElastoDyn, InflowWind, ServoDyn, HydroDyn, SubDyn, and MoorDyn as child nodes. Airfoil data files, blade structure files, controller files, etc., continue to be treated as lower-level nodes. The adapter traverses the text file tree in depth-first order, verifying the validity of its parent reference path before reading the current file, and returning to the parent node after completing the parsing of the current file. For parameter rows in key-value format, parameter values, parameter names, and comments are extracted; for tabular data, the header and data ranges are identified based on the number of header fields, the number of data rows, and blank line boundaries, and multi-row tables are converted into structured arrays or interpolated tables.

[0057] When the format type is a custom text format, the custom format adapter is invoked. For JSON files, the custom format adapter traverses the document tree according to the key path mapping template, for example, mapping the key path "blade.chord[0].value" to the first chord length parameter in the blade geometry domain; for YAML files, a hierarchical document tree is constructed based on the indentation level and node name, and then the correspondence between the source node and the target parameter is determined according to the hierarchical mapping template. The mapping template includes at least the source key path, target data domain, target parameter name, data type, source unit, whether it is required, and default value rules. Therefore, when adding a custom format, adaptation can be completed by updating the mapping template without modifying the physical domain resolver.

[0058] After obtaining binary block structure data, text file tree data, or structured mapping data, the format adapter performs format pre-checking, encoding conversion, and version compatibility checks. Format pre-checking includes checking for binary data blocks exceeding boundaries, the existence of required header fields, whether text parameter lines conform to lexical and syntactic rules, the validity of file reference paths, whether the JSON or YAML document tree is closed, and the existence of required key paths. Encoding conversion identifies the source encoding of the text file and converts it uniformly to UTF-8 encoding. For non-ASCII characters, full-width characters, or platform-specific newline characters, normalization is performed according to a preset encoding table, while preserving the correspondence between the source file location and the converted location to locate the original line number or byte offset in error reports.

[0059] Version compatibility checks are performed by reading the version identifier of the source file and comparing it with the version range supported by the parser. For bladed project files, the version identifier can be obtained from the version field in the project header; for OpenFAST input files, it can be obtained from the main input file version string or FAST_VersionKey; for custom formats, it can be obtained from the version key. When the source file version is within the parser's supported range, the version status is marked as compatible; when the source file version is higher than the highest version supported by the parser but the underlying structure can be recognized, the version status is marked as partially compatible, and unknown fields are retained in the unparsed field list; when version differences cause changes in the meaning of required fields or the structure cannot be parsed, the version status is marked as incompatible. Finally, the adapted structure data, encoding normalization results, version status, field position indexes, and unparsed field list are assembled into preprocessed file data.

[0060] Taking "WTG_15MW_v3.prj" as an example, the Bladed adapter traverses the 18 data blocks in the project file, including the project information block, wind conditions block, three sets of blade geometry blocks, control parameter block, transmission chain block, structural block, and electrical block. The adapter checks the data block identifier and length block by block, and finds no data blocks that are out of bounds or have inconsistent lengths; it reads the version number v5.7.3 and compares it with the highest version supported by the parser, v5.9.0, to determine version compatibility; based on this, it generates preprocessed file data including the structure of the 18 data blocks, field offset indices, and version compatibility status.

[0061] In step S3, the physical domain parser is scheduled to extract simulation model parameters based on the preprocessed file data. The physical domain parser may include a blade geometry parser, a control parameter parser, an environmental parameter parser, a structural parameter parser, a transmission chain parameter parser, an electrical parameter parser, and a simulation configuration parser. Each physical domain parser does not directly read the original file, but instead reads field values, arrays, matrices, or tables through a unified access interface provided by the corresponding format adapter, thereby decoupling the parsing logic from the source file format.

[0062] Specifically, as the core stage 3 of the end-to-end parsing process, the parsing engine consists of five independent parser modules: BladeGeometryParser, ControlParamsParser, EnvironmentParser, StructureParser, and ElectricalParser. For a specific format, each parser accesses the source data through the corresponding format adapter. (a) Bladed Adapter: The binary data structure of the Bladed.prj file is organized in the form of a quadruple of "block ID + block length + header field + payload data". BladedAdapter maintains a complete mapping table of .prj format data structures, mapping each block ID to the corresponding parser module and data field. For nested data structures (such as the triangular mesh data of lift coefficient \mathbit{C}_\mathbit{l} and drag coefficient \mathbit{C}_\mathbit{d} in the blade aerodynamic characteristics table), the adapter recursively expands until all leaf node fields are extracted.

[0063] (b) OpenFAST Adapter: The OpenFAST file system uses the main input file (.fst) as the root node and forms a file tree through file reference keywords (such as "AeroFile", "EDFile", etc.). OpenFASTAdapter first parses the main input file to build a file reference topology graph, and then traverses and parses all submodule files in depth-first order. For parameter table format data within a submodule (such as AeroTables corresponding to airfoil data in AeroDyn), the adapter automatically identifies the boundaries of the table header and data and converts them into the corresponding interpolation table format in UMO.

[0064] (c) Custom Adapter: For user-defined JSON and YAML format files, the CustomAdapter directly utilizes the structured features of the text format for parsing: JSON uses key-value path mapping rules (e.g., "blade.chord[0].value" maps to airfoil data in the blade geometry domain), and YAML employs an indentation-level-aware document tree traversal strategy. Users can customize the mapping relationship between JSON / YAML key paths and UMO data domains by providing a mapping configuration profile.

[0065] The blade geometry analyzer extracts the airfoil section number, relative thickness, lift coefficient table, drag coefficient table, chord length distribution, twist angle distribution, pre-bending distribution, pre-torsion distribution, and discrete node coordinates along the blade span. Each geometric parameter can be organized using dimensionless spanwise positions, which satisfy the following conditions:

[0066] in, This represents the spanwise distance from the current blade cross-section to the blade root. This indicates the total spanwise length of the blade.

[0067] The control parameter resolver extracts parameters such as pitch angle range, pitch rate upper limit, generator speed-torque curve, rated torque, yaw angle, yaw rate, filter cutoff frequency, and damping ratio. The environmental parameter resolver extracts reference height, average wind speed, turbulence intensity, wind shear index, significant wave height, spectral peak period, ocean current parameters, and water surface parameters. The structural parameter resolver extracts tower geometry parameters, material parameters, foundation stiffness matrix, modal mass, modal damping, and section stiffness distribution. The transmission chain parameter resolver extracts gearbox transmission ratio, rotor moment of inertia, generator moment of inertia, bearing stiffness, and damping parameters. The electrical parameter resolver extracts generator rated power, rated current, converter control parameters, and collector line parameters. The simulation configuration resolver extracts simulation time step, simulation duration, output channel list, and solver options.

[0068] like Figure 2As shown, the simulation model parameters extracted by the physics domain resolver are mapped to seven data domains of a unified model object: blade geometry domain, control parameter domain, environmental parameter domain, structural parameter domain, transmission chain parameter domain, electrical parameter domain, and simulation configuration domain. The blade geometry domain includes airfoil section, chord length, twist angle, pre-bending, pre-torsion, and spanwise node data; the control parameter domain includes pitch, torque, yaw, and filtering parameters; the environmental parameter domain includes wind, wave, and current parameters; the structural parameter domain includes tower, foundation, modal, and section stiffness parameters; the transmission chain parameter domain includes transmission ratio, moment of inertia, bearing stiffness, and damping parameters; the electrical parameter domain includes generator, converter, and collector line parameters; and the simulation configuration domain includes time step, duration, output channels, and solver configuration.

[0069] For each parameter to be mapped, the parser extracts the parameter name, parameter path, data dimension, and physical unit, and determines the target data domain based on physical domain mapping rules. When the parameter name uniquely indicates the physical domain, it is mapped directly. When parameters with the same name exist in different files, the target data domain is determined by combining the source file type and parameter path. When array or matrix parameters span multiple physical domains, they are split according to the field definition list and mapped separately. Parameters are stored in the target data domain as key-value pairs. The key records the standard parameter name and unique parameter path, and the value type includes at least one of scalar, one-dimensional array, two-dimensional matrix, and interpolation table. Each key-value pair can also be associated with the source file identifier, source field position, source unit, target unit, parser version, and confidence status to support subsequent error location and version tracking.

[0070] Taking blade geometry analysis as an example, the blade geometry resolver reads the number of cross sections, spanwise position, chord length, twist angle, airfoil family identifier, and aerodynamic coefficient table from three sets of blade geometry blocks. For each blade, there are 30 cross sections, and each cross section is analyzed according to 15 preset fields. Theoretically, the number of parameters to be analyzed is:

[0071] in, Indicates the number of blade cross sections. This indicates the number of preset fields for each cross-section. In this example, 447 parameters were successfully parsed. The three unparsed fields were undocumented trailing edge modification process parameters. These unparsed fields were added to the unparsed field list to avoid discarding them.

[0072] The control parameter parser extracts 92 control parameters from the control parameter block, including the upper limit of pitch angle, the upper limit of pitch rate, the rated generator speed, and the torque-speed curve; the environmental parameter parser extracts 82 environmental parameters, including wind conditions, waves, and ocean currents; the structural parameter parser extracts 203 structural parameters, including tower, foundation, and modal parameters; and the electrical parameter parser extracts 65 electrical parameters, including generator and converter parameters. Driveline parameters and simulation configuration parameters are written into the driveline parameter domain and simulation configuration domain, respectively. After each parser completes the mapping, the seven data domains are assembled according to a unified object identifier, aircraft type identifier, and model version identifier to generate intermediate model data.

[0073] To quantify the completeness of parsing for each data domain, the number of parameters successfully parsed and mapped to the target data domain and the total number of parameters that should actually be parsed in the source file are counted separately. The result is calculated using the following formula. Parameter coverage of each data domain:

[0074] in, Indicates the first Parameter coverage of each data domain; Indicates the first The number of parameters successfully parsed and mapped to a unified model object in each data domain; Indicates that the source file belongs to the first... The total number of data fields and the total number of parameters that should actually be parsed. The field definition list is determined according to the corresponding format specification; for optional or conditional fields that exist only under specific configurations, they are only included in the total number of parameters when the source file actually contains the field, thereby avoiding unnecessary reduction in parameter coverage when the marine module, turbulence attachment or third-party extension module is not enabled.

[0075] After each module has completed parsing and assembled the UMO, semantic-level verification and normalization are performed, including: (a) Cross-module reference integrity check: Verify that the external data referenced in each data field (such as the blade geometry section number referenced in the control parameter field) actually exists in the target field; (b) Physical Unit System Normalization: Automatically identifies the unit system used in the source file (SI and engineering units), and converts all physical quantities to SI standard units (length → meter, mass → kilogram, force → newton, power → watt, etc.), using standard unit conversion formulas. ; (c) Parameter reasonableness range check: Based on the wind turbine design experience database, the upper and lower limit thresholds of key parameters are checked. For example, the rated wind speed should be within a reasonable range. Inside.

[0076] Specifically, in step S4, cross-module reference checks, physical unit normalization, and parameter reasonableness range checks are performed based on intermediate model data. Cross-module reference checks verify whether a referenced object in a data domain can find a unique underlying definition in the referenced data domain. For example, the blade section number used in the control parameter domain should exist in the blade geometry domain; the airfoil identifier referenced by the AeroDyn aerodynamic table should correspond to valid airfoil data; the output channel declared in the simulation configuration domain should correspond to at least one physical domain parameter; and the node number, material number, and modal number used in the structural parameter domain should exist in the corresponding underlying parameter set. For each reference, the source parameter path, target parameter path, and check status are recorded, generating a reference integrity check result. When a referenced object is missing, duplicated, or of inconsistent type, the corresponding reference chain is marked as abnormal.

[0077] Physical unit normalization is used to convert engineering units used on different platforms into a preset standard unit. In this embodiment, the preset standard unit adopts the International System of Units (SI), with length uniformly expressed as meters, mass as kilograms, force as newtons, power as watts, angles as radians, and rotational speed as radians per second. For any source parameter value, the unit conversion is performed according to the following formula:

[0078] in, This represents the converted SI parameter value; This represents the parameter value in the source file; Indicates the unit ratio conversion factor; Indicates the unit offset. For millimeters to meters, and For converting degrees to radians, and ; Converting revolutions per minute to radians per second, and After conversion, the source value, source unit, target value, target unit, and conversion rules are written together into the unit normalization data.

[0079] The parameter rationality range check is performed based on the wind turbine design parameter range library. This library can be organized according to turbine capacity level, onshore or offshore application type, control system type, and model version, providing reasonable ranges for key parameters such as rated wind speed, blade length, pitch angle range, pitch rate, tower height, generator rated power, foundation stiffness, and simulation time step. For the first... The first data field Given several parameters, perform the following range judgment:

[0080] in, Indicates the first The first data field One normalized parameter value; and These represent the lower and upper limits of the reasonable range for the parameters, respectively. When a parameter value is within the reasonable range, the check status is marked as passed; when a parameter value exceeds the reasonable range but may be due to a specific model configuration, the check status is marked as a non-critical alarm; when a parameter value violates basic physical constraints, such as a negative mass, a time step less than or equal to zero, or a rated power less than zero, the check status is marked as a critical anomaly. Finally, the results of the reference integrity check, unit normalized data, and parameter range check are summarized to generate a semantic verification result.

[0081] Taking the Bladed project file as an example, the length parameter in the source file is in millimeters, the angle parameter is in degrees, and the rotation speed parameter is in revolutions per minute. The semantic validator converts these to meters, radians, and radians per second, respectively. All blade section numbers referenced in the control parameter field can be found in the blade geometry field; all output channels declared in the simulation configuration field correspond to physical domain parameters. Parameter range checks revealed that a leading-edge roughness parameter in the blade geometry field had a value of -1. After field definition confirmation, this value was determined to be a placeholder for "using default value," and therefore recorded as a non-critical alarm to avoid misinterpreting it as a negative physical quantity.

[0082] Furthermore, in this embodiment, it also includes performing a three-layer hierarchical integrity check, serializing the UMO data that has passed all checks into a standardized unified model object representation for use by downstream simulation engines or other analysis tools, and generating a Parse Metadata Report containing metadata of the parsing process, recording the execution time of each stage, the parameter coverage of each parser, the verification results of each layer, and warning information.

[0083] In step S5, as Figure 3 As shown, based on intermediate model data and semantic verification results, file-level integrity verification, module-level integrity verification, and parameter-level integrity verification are performed sequentially. The three-layer verification is performed progressively from underlying byte and structural integrity, data field parameter integrity to cross-domain physical consistency, so that the same anomaly can be located to the source file, data field, or specific parameter path.

[0084] The first layer is file-level integrity verification. For each model file in the set of model files to be parsed, the complete byte stream of the file is read and the file checksum is calculated:

[0085] in, Representation model file SHA-256 checksum, A collection of model files. For the file The complete byte stream, This is a byte-order concatenation operator. SHA-256 is chosen based on its extremely low collision probability (theoretical collision probability). Compared to traditional CRC32, the detection rate of data transmission errors is improved by more than [percentage missing]. .

[0086] When a reference checksum is provided in the version control system, model release package, or user input, The model file is compared with a reference checksum to determine whether bit-level changes have occurred during transmission or storage. If no reference checksum is provided, the current calculation result is written as the model version fingerprint into the parsing metadata report for use in subsequent version comparisons.

[0087] File-level verification also generates a list of required structures based on the format type and version information in the format identification results. For the Bladed project format, the list of required structures may include project information blocks, wind condition blocks, blade geometry blocks, control parameter blocks, and transmission chain blocks; for the OpenFAST input file format, the list of required structures may include the main input file and required submodule files such as AeroDyn, ElastoDyn, and InflowWind, which are enabled by the main input file; for JSON or YAML custom formats, the list of required structures is determined based on the required key paths in the mapping template. The actual files, data segments, or data blocks are compared item by item with the list of required structures to generate a file structure integrity check result. When a required file does not exist, a required data block is missing, the file reference path is invalid, or the data block length exceeds the limit, the file-level verification fails, and the file name, data block identifier, byte offset, or reference path is recorded.

[0088] The second layer is module-level integrity verification. Deterministic serialization is performed on the seven data fields of the unified model object. Deterministic serialization uses fixed field order, fixed numerical precision, fixed character encoding, and fixed null value representation to convert key-value pairs of the same data field into a canonical byte sequence. For the first... For each data field, calculate the module-level checksum using the following formula:

[0089] in, Indicates the first The complete set of parameters for each data field; This represents a deterministic serialization function; Indicates the first Module-level checksums for each data field.

[0090] By using module-level checksums, it is possible to independently compare whether changes have occurred in the blade geometry domain, control parameter domain, or other data domains between different model versions, and to narrow down the inconsistencies from the entire model file to specific data domains.

[0091] Module-level verification simultaneously reads the parameter coverage rate generated in step S3. For each data domain, the parameter coverage rate is compared with a preset coverage threshold; in this embodiment, the preset coverage threshold can be set to 95%. When the parameter coverage rate of a certain data domain is lower than the preset coverage threshold, the list of unresolved fields for that data domain is read to determine whether the unresolved fields are required fields. If a required field is not resolved, the module-level verification result is marked as a failure; if the unresolved field is a non-public debugging field or a conditional field unrelated to the current model configuration, it can be recorded as a non-critical alarm. Module-level verification also combines the parameter range check results in the semantic verification results to summarize the rationality of parameters within the data domain, generating a module-level verification result including the module-level checksum, parameter coverage rate, unresolved fields, and parameter range alarms.

[0092] The third layer is parameter-level integrity verification. Parameter-level verification extracts power parameters, aerodynamic parameters, blade geometry parameters, blade mass parameters, and operating frequency parameters from intermediate model data, and performs cross-domain consistency checks, parameter internal consistency checks, and empirical eigenvalue checks.

[0093] In the power balance verification, the aerodynamic input power and transmission output power are calculated based on the air density and rated wind speed in the environmental parameter domain, the swept area in the blade geometry domain, the power coefficient in the aerodynamic parameters, and the rated speed, rated torque, and efficiency parameters in the transmission chain parameter domain and the electrical parameter domain. The power balance requirement is as follows:

[0094] in, Indicates pneumatic input power; Indicates air density; Indicates the impeller sweep area; This represents the power coefficient at the corresponding operating point; This indicates the wind speed at the corresponding operating point; Indicates the output power of the drive train; Indicates the rated angular velocity; Indicates the rated torque; This indicates the overall efficiency of the transmission chain and generator.

[0095] If the deviation between the two sides of the equation exceeds 5%, a "Power Balance Inconsistency" warning is triggered, and the parameter paths involved in the calculation are recorded. To avoid incorrectly using the maximum power coefficient at the rated operating point, the power coefficient corresponding to the current wind speed and rotational speed is read first during verification; when only the maximum power coefficient exists, the verification result is marked as requiring manual confirmation.

[0096] In checking the internal consistency of blade parameters, the continuity of the chord length distribution is checked first. For adjacent blade sections, the gradient of chord length variation is calculated:

[0097] in, and These represent the chord lengths at two adjacent spanwise positions; and Indicates the corresponding spanning direction position; This indicates the upper limit of the chord length variation gradient. When the chord length variation gradient exceeds the upper limit, the corresponding section number is located and a geometric continuity alarm is generated.

[0098] Furthermore, the blade mass is estimated based on the blade cross-sectional area and material density:

[0099] in, This represents the blade mass calculated based on geometric distribution and material density. Indicates the direction of expansion Equivalent material density at the location; Indicates the direction of expansion The equivalent cross-sectional area of ​​the blade at that location; Indicates the blade length.

[0100] Compare the calculated mass with the blade mass declared in the model file:

[0101] in, This represents the blade mass declared in the model file; This indicates a deviation in the self-consistency of blade quality. When... If the deviation is no greater than 5%, the blade quality self-consistency verification is passed; if the deviation exceeds 5%, a blade quality inconsistency alarm is generated.

[0102] In the empirical eigenvalue check, the risk of resonance near integer multiples of the speed frequency is checked based on the first-order flapping frequency of the blades in the structural parameter domain and the rated speed in the transmission chain parameter domain. If the rated speed... Expressed in revolutions per minute, the rotor rotation frequency is:

[0103] The first-order flapping frequency of the blades should avoid the safe range corresponding to integer multiples of the rotational speed frequency. For example, check whether the first-order flapping frequency of the blades meets the Campbell's diagram resonance avoidance condition:

[0104] in Rated speed, This represents a resonance safety margin (typically 5%). This represents the first-order flapping frequency of the blade. This indicates a multiple of the rotational speed frequency. When the first-order flapping frequency of the blade enters any safe range, the corresponding inspection result will be marked as a critical alarm, and the conflicting multiple, frequency interval, and parameter path will be recorded.

[0105] Parameter-level verification determines alarm levels based on various deviations, alarm types, and their impact on simulation results. File corruption, missing essential structures, absence of critical parameters, severe power mismatch, and failure to meet resonance avoidance conditions can be marked as severe; placeholders, minor out-of-bounds errors in non-critical parameters, or unmapped optional fields can be marked as non-severe. The results of each parameter-level check, alarm level, parameter path, and consistency deviation are assembled into a parameter-level verification result, which, together with the file-level and module-level verification results, constitutes a hierarchical verification result.

[0106] To quantify the completeness of the analysis, this invention defines the parameter coverage ratio (PCR) metric:

[0107] in, The number of parameters successfully parsed and mapped to UMO, This represents the total number of parameters defined in the source file. The parsing engine... The determination is based on the field definition list in the format specification; for fields marked as "optional / conditionally present" in the format specification, if the source file does not contain the field, it will not be included. To avoid reducing the statistical significance of PCR in unsuitable scenarios.

[0108] The method of this invention achieves an automatic parameter parsing coverage of over 95% in typical test scenarios (Bladed 4.x / 5.x format .prj files, OpenFAST v2.x / v3.x complete set of input files). The remaining uncovered parameters (about 5%) are mainly undocumented debug data segments in the Bladed .prj format and custom data blocks extended by third-party tools. These parameters are handled by generating a list of unparsed fields and providing manual mapping suggestions to assist users in processing them.

[0109] In this embodiment, the overall verification is considered passed when the hierarchical verification results meet the following conditions: all file-level verifications pass; the parameter coverage of all seven data fields is not lower than the preset coverage threshold; and there are no severe level alarms in the parameter-level verifications. The overall pass condition can be expressed as:

[0110] in, This indicates that all file-level checks have passed; Indicates the parameter coverage threshold; This indicates the highest alarm level for parameter-level verification; In this embodiment, the severity level threshold is indicated. 95% is acceptable.

[0111] After the results of the above three layers of verification are further merged into a unified verification conclusion, the overall verification must meet the following conditions: all first-layer verifications are passed, the parameter coverage of all data domains in the second layer is not less than 95%, and there are no cross-domain inconsistency detections with a severity level (Severity=Critical) in the third layer.

[0112] Taking "WTG_15MW_v3.prj" as an example, the SHA-256 checksum calculated at the file level is consistent with the reference checksum saved by the version management system, and the project information block, wind condition block, blade geometry block, control parameter block, and transmission chain block all exist. The parameter coverage rates of the seven data fields are 99.3%, 100%, 100%, 98.5%, 100%, 100%, and 100%, respectively, all higher than 95%. In the parameter-level verification, the deviation between the calculated and declared values ​​of the blade mass is 2.8%, which is less than 5%; the first-order flapping frequency of the blade does not enter the safe range corresponding to the 1P, 3P, 6P, or 9P harmonics; except for a leading edge roughness placeholder parameter using the default value, no serious anomalies were found, therefore the overall verification passed.

[0113] In some embodiments of the present invention, a parsed metadata report or an error diagnosis report is further generated after the generation of the hierarchical verification results. When the overall verification passes, the unified model object is serialized into standardized model data according to a fixed field order, which can be used by downstream simulation engines, model conversion tools, or model quality management systems. Simultaneously, the execution time of each stage—format recognition, format pre-check, module parsing, semantic verification, and integrity verification—as well as the parameter coverage of each data domain, file-level checksum, module-level checksum, non-critical alarms, and unparsed fields are recorded, generating a parsed metadata report. The parsed metadata report can be output in a human-readable text format or a machine-parseable JSON format.

[0114] When the overall validation fails, error location data is generated based on the failure locations in file-level, module-level, or parameter-level validations. For binary project files, the error location can be represented by the filename, data block identifier, and byte offset; for OpenFAST text files, the error location can be represented by the filename, parameter name, and line number; for JSON or YAML files, the error location can be represented by the filename and key path. Based on the error location data, the error type, impact level, possible causes, and remediation suggestions are determined, and an error diagnosis report is generated. For example, when a Bladed project file is missing a drivetrain block, the error diagnosis report marks it as "Required structure missing" and suggests importing drivetrain parameters from a template of a similar model or supplementing gearbox transmission ratio, moment of inertia, and bearing parameters; when the pitch rate exceeds the design parameter range, the report provides the current value, reasonable range, and control system type verification suggestions; when the blade natural frequency enters the harmonic safety range, the report marks resonance risk and provides suggestions for checking blade stiffness, mass distribution, and speed settings.

[0115] In model version iteration scenarios, incremental verification can also be performed based on module-level checksums. The module-level checksums of each data domain in the current version are compared with the corresponding checksums of the previous version to identify the modified data domains. Then, based on parameter reference identifiers and parameter-level cross-domain checks in the intermediate model data, data domains that have dependencies on the modified data domains are determined. For example, when only the control parameter domain is modified, the control parameter domain and the blade geometry domain, transmission chain parameter domain, and simulation configuration domain that have parameter references or power relationships with it can be re-verified, without needing to re-verify data domains without dependencies. After incremental verification is completed, the newly generated module-level and parameter-level verification results are used to update the hierarchical verification results and parsed metadata reports.

[0116] To record the operational performance of the parsing pipeline, the total time consumption of the entire parsing process can be calculated using the following formula:

[0117] in, This indicates the total time spent on end-to-end parsing and verification; This indicates the time required for format recognition; This indicates the time spent on format pre-checking, encoding conversion, and version compatibility determination. This indicates the time spent on physical domain parameter resolution and unified model object assembly; Indicates the time spent on semantic verification; This represents the time taken for the three-layer integrity check. The time complexity of format recognition can be expressed as... ,in Let be the number of candidate formats; the time complexity of format pre-detection can be expressed as . ,in For the number of files, Given the average file length; the time complexity of module parsing can be expressed as: The time complexity of semantic and integrity checks involving sorting, deterministic serialization, or cross-domain index references can be expressed as: .

[0118] The time complexity of each stage is shown in the table below:

[0119] In the test scenario of the 15 MW wind turbine bladed project file, the project file size was approximately 2.5MB, with a total of 2314 source file parameters. 2258 parameters were successfully parsed and mapped to the unified model object, resulting in an overall parameter coverage of 97.6%. The total parsing and verification time was approximately 1.8 seconds. The parsed metadata report recorded the parameter coverage of seven data domains, verification results at each layer, two non-critical alarms, and a list of unparsed fields. This provides a unified model object usable by downstream simulation software while retaining complete traceability information from the source file, adapter, physical domain resolver to the verification results.

[0120] Compared with the prior art, the beneficial effects of the present invention are as follows: Firstly, this invention identifies the formats of Bladed project files, OpenFAST input files, and custom JSON or YAML files, and completes file pre-inspection, encoding conversion, version compatibility judgment, and model parameter extraction through a format adapter that matches the corresponding file format. This enables wind turbine whole-machine simulation model files from different sources, with different organizational structures, and with different versions to enter a unified parsing process, reducing the manual format conversion and parameter mapping work required when migrating models across simulation platforms, and improving the parsing efficiency and cross-platform migration capability of multi-source heterogeneous model files.

[0121] Secondly, this invention extracts simulation model parameters by scheduling blade geometry resolvers, control parameter resolvers, environmental parameter resolvers, structural parameter resolvers, and electrical system resolvers. These parameters are then mapped to different data domains of a unified model object according to parameter name, parameter path, data dimension, and physical unit. This allows model parameters scattered across different files, data blocks, and submodules to form structurally consistent intermediate model data. Furthermore, by statistically analyzing the number of parameters successfully resolved and mapped to the unified model object and the total number of parameters actually existing in the source files, the parameter resolution coverage of each data domain can be quantified. This achieves a parameter resolution coverage rate of over 95% in typical model files. Unresolved fields are identified and recorded, improving the completeness and traceability of parameter resolution in the overall simulation model.

[0122] Thirdly, by performing cross-module reference checks, physical unit normalization, and parameter reasonableness range checks on intermediate model data, this invention can identify problems such as missing parameter references, inconsistent physical units, and parameter values ​​exceeding reasonable ranges, avoiding the need to judge the validity of model files solely based on file syntax or data format. Furthermore, by performing power balance relationship verification, blade mass self-consistency verification, and resonance avoidance condition verification on power parameters, aerodynamic parameters, blade geometric parameters, blade mass parameters, and operating frequency parameters, this invention can detect model parameters with correct formats but unreasonable physical meanings, improving the physical consistency of the wind turbine whole-generator simulation model data and the reliability of simulation results.

[0123] Fourthly, this invention constructs a hierarchical integrity verification mechanism at the file, module, and parameter levels. At the file level, it checks the checksum of model files and necessary files, data segments, or data blocks. At the module level, it performs independent checksum calculations and parameter coverage statistics for each data field of a unified model object. At the parameter level, it performs consistency checks on cross-domain related parameters, achieving a progressive verification from file byte integrity and data field integrity to parameter physical rationality. Compared to methods that only perform MD5 or CRC checks on a single file, this invention can detect various types of problems such as file corruption, structural missingness, parameter omissions, cross-module inconsistencies, and abnormal physical relationships, and locate errors to the corresponding files, data segments, data fields, or parameter paths, improving the detection capability and location accuracy of model data errors.

[0124] Fifthly, this invention generates a parsing metadata report, recording the execution time of each parsing stage, the parameter coverage of each data domain, the verification results of each layer, and alarm information, enabling the model file parsing process and verification results to be uniformly recorded and reviewed. By generating an error diagnosis report including error type, impact level, and repair suggestions when verification fails, it provides a basis for model parameter correction and file structure completion. Furthermore, by comparing module-level verification and identifying modified data domains, and performing incremental verification only on modified data domains and data domains with cross-domain dependencies, unnecessary full parsing and repeated verification during model version iteration are reduced, improving the processing efficiency of wind turbine whole-machine simulation model file version updates, quality control, and engineering applications.

[0125] Figure 4 This is a schematic diagram of a wind turbine whole machine simulation model file parsing and verification system provided in an embodiment of the present invention.

[0126] Example 2, as Figure 4 As shown, the present invention also provides a system for parsing and verifying simulation model files of wind turbine generator sets, including: The format recognition module is used to obtain a set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format recognition results. The file preprocessing module is used to call the corresponding format adapter based on the format recognition result, perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and generate preprocessed file data. The model parsing module is used to schedule the physical domain parser to extract simulation model parameters based on the preprocessed file data, map the simulation model parameters to multiple data domains of a unified model object, and generate intermediate model data. The semantic verification module is used to perform cross-module reference checks, physical unit normalization, and parameter reasonableness range checks based on the intermediate model data, and generate semantic verification results. The integrity verification module is used to perform file-level, module-level, and parameter-level hierarchical integrity verification based on the intermediate model data and the semantic verification results, and generate hierarchical verification results. The result output module is used to output the unified model object and parsed metadata report when the hierarchical verification result meets the preset pass conditions; and to output an error diagnosis report when the hierarchical verification result does not meet the preset pass conditions.

[0127] In this embodiment, the format recognition module includes an extension recognition unit, a file header recognition unit, and a trial parsing unit. The file preprocessing module includes a Bladed adapter, an OpenFAST adapter, a custom format adapter, a format pre-detection unit, an encoding conversion unit, and a version compatibility judgment unit. The model parsing module includes a blade geometry parser, a control parameter parser, an environmental parameter parser, a structural parameter parser, a transmission chain parameter parser, an electrical parameter parser, and a simulation configuration parser. The semantic verification module includes a cross-module reference checking unit, a unit normalization unit, and a parameter range checking unit. The integrity verification module includes a file-level verification unit, a module-level verification unit, and a parameter-level verification unit. The result output module includes a unified model object output unit, a parsed metadata report generation unit, an error diagnosis report generation unit, and an incremental verification unit.

[0128] To further illustrate the specific application scenario of this embodiment, this embodiment provides a specific process for performing full-link parsing and integrity verification on the DNV GH Bladed .prj model file of a 15MW wind turbine using the method of the present invention.

[0129] Step S11: File format identification. The user specifies the path to the .prj file to be parsed (e.g., "WTG_15MW_v3.prj") through the operation interface. The parsing pipeline first performs format identification: (a) Reads the file extension ".prj", initially determining it to be in Bladed format; (b) Reads the first 4 bytes of the file, detects the magic number 0x9E2A83C1, confirms the Bladed .prj format, and sets the confidence level to C=0.98; (c) Reads the version number segment (offset 0x04-0x07), and parses the file version number to v5.7.3, which is compatible with the maximum version supported by the parser, v5.9.0, and the version compatibility check passes.

[0130] Step S12: Format pre-check and encoding conversion. BladedAdapter performs a binary structure check on the .prj file: iterates through all data blocks in the file, verifying whether the ID field of each data block exists in the format mapping table and whether the data block length field matches the actual data length within the block. The check found that the file contains 18 data blocks (project information block, wind conditions block, blade geometry block ×3 (corresponding to 3 blades), control parameter block, transmission chain block, structural block, power block, etc.), and all data blocks passed the integrity pre-check.

[0131] Step S13: Module-by-module parsing. BladedAdapter schedules each parser module sequentially according to the format mapping table: (a) BladeGeometryParser parses the 3 blade geometry blocks—for each blade, it extracts the number of cross sections. Construct an airfoil section data table (including the spanwise position of each section). chord length Twist (Airfoil family identifiers, aerodynamic coefficient tables, etc.), all extracted data were normalized to SI units. Blade section data includes... Of the parameters, 447 were successfully parsed (99.3% coverage). The three unparsed fields were the trailing edge modification (TE Dimples) process parameter group (used only in the production stage). (b) ControlParamsParser parses control parameter blocks—extracts the upper limit of pitch angle. Upper limit of pitch rate Rated generator speed All 92 control parameters, including rpm and torque-speed curves, were successfully parsed (100% coverage). (c) EnvironmentParser, StructureParser, and ElectricalParser respectively parsed environmental parameters (82 parameters such as wind conditions and waves), structural parameters (203 parameters such as towers and foundations), and electrical parameters (65 parameters such as generators and converters), with each module achieving a parsing coverage rate exceeding 97%.

[0132] Step S14: Semantic verification and unit conversion. The parsed data is first normalized to the unit system: the Bladed.prj file uses engineering units by default (length → mm, angle → degree, speed → rpm), which are then uniformly converted to SI units (length → m, angle → rad, speed → rad / s). The semantic verifier checks the integrity of cross-module references: it verifies that the blade section numbers referenced in the control parameter block (e.g., pitch section Index 5-15) do indeed exist in the blade geometry block, and all references are valid. It also checks the power balance relationship: air density... kg / m³, swept area m², rated wind speed m / s, derived from airfoil data Generator power MW, Derivation of power W = 41.58 MW — A power imbalance alarm was detected. Further investigation revealed... This is the power factor at maximum power, not at rated wind speed, and should be corrected based on the actual operating point. Post-derived power MW, considering transmission chain efficiency and generator efficiency The power balance deviation then decreased to 3.2%, which is below the 5% alarm threshold, and the verification was passed.

[0133] Step S15: Three-layer integrity verification. First layer: File-level verification: Calculate the SHA-256 checksum for the .prj file and compare it with the user-selected reference checksum (from the version management system). It passes. Second layer: Module-level verification: The parameter coverage of the seven data domains are 99.3%, 100%, 100%, 98.5%, 100%, 100%, and 100%, all exceeding the 95% threshold. Parameter range checks in each domain reveal that the leading edge roughness parameter value for section number 7 in the blade geometry domain is -1 (placeholder, indicating the use of the default value), marked as a non-critical alarm. All other parameters are within reasonable ranges. Third layer: Parameter-level verification: Perform cross-domain consistency verification (power balance passed), blade self-consistency verification (geometric calculation quality deviation from declared quality is 2.8%, below the 5% threshold), and resonance avoidance verification (first-order flapping frequency). (Based on Campbell's plot analysis, the 3P frequency is 3.0 Hz, which is a sufficient safety factor), all passed.

[0134] Step S16: Unify model object output by serializing and outputting the UMO data that has passed all validations. The system also generates a parsing metadata report, recording the total parsing time of 1.8 seconds, the total number of parameters of 2314, the number of successfully parsed parameters of 2258 (coverage of 97.6%), the validation results of each layer, and 2 non-critical alarm messages.

[0135] This embodiment also provides a process for performing full-link parsing on an OpenFASTv3.x input file system of an IEA 15MW benchmark wind turbine using the method of the present invention, illustrating the ability to automatically convert from OpenFAST format to a Bladed compatible format.

[0136] Step T1: File System Discovery and Topology Construction. The user specifies the OpenFAST main input file "IEA-15-240-RWT-Monopile.fst". The format recognition module detects the characteristic string "-- FAST v8.16.00a-bjj" in the first line and identifies it as OpenFAST format (confidence C=0.99). OpenFASTAdapter parses the main input file and constructs a file topology graph through file reference keywords: the root node .fst references seven sub-module files: AeroDyn15.dat, ElastoDyn.dat, InflowWind.dat, ServoDyn.dat, SubDyn.dat, HydroDyn.dat, and MoorDyn.dat. Each sub-module file may also have nested references (e.g., AeroDyn15.dat references three airfoil data files), ultimately constructing a reference tree with a depth of 3 containing 14 files.

[0137] Step T2: Full file parsing. OpenFASTAdapter traverses the file tree in depth-first search order, parsing each submodule sequentially. Taking ElastoDyn.dat as an example: The parser first identifies the text line format pattern (ElastoDyn files use keyword-value pair format, with optional inline comments "--"), and scans line by line to extract parameters—the number of blade sections. Based on this value, the array field length is dynamically allocated, and 9 more sets of node data are read (each set contains 12 fields × 9 nodes = 108 parameters, including spanwise position BlFract_i, flapping stiffness FlpStff_i, and tumbling stiffness EdgStff_i). After all submodules are parsed, a total of 2231 parameters are obtained, of which 2187 are successfully parsed (coverage rate 98.0%). The remaining 44 unparsed parameters are advanced parameters added in the new version of the module whose mapping rules have not yet been updated (such as the automatic selection parameters for coupled degrees of freedom in SubDyn). These are recorded by the system in the unparsed list for future expansion and adaptation.

[0138] Step T3: Cross-format conversion. Based on the parsed UMO data, the user selects the Bladed.prj format as the target output format. The conversion engine, according to the Bladed.prj format specification, reverse maps the seven data fields in the UMO into a binary data block structure in Bladed format: the cross-sectional data of the blade geometry field is written into the blade geometry block (BI), the control parameter field is written into the control parameter block (CN), and so on.

[0139] The conversion process involves: (a) inverse unit conversion – converting SI units back to engineering units; (b) data precision adaptation – floating-point numbers in Bladed.prj are single-precision (32-bit), while those in OpenFAST text are double-precision, requiring precision truncation; (c) missing field filling – Bladed-specific fields that do not exist in OpenFAST (such as extreme wind condition attachment parameters in the wind condition block) are filled with default values ​​and marked in the conversion report.

[0140] Step T4: Post-conversion verification. The generated .prj target file undergoes the same re-parsing and three-layer integrity verification process as in Example 1. Successful verification confirms successful cross-format conversion. The entire conversion process takes 2.7 seconds (1.5 seconds for parsing + 1.2 seconds for format reverse mapping). Comparative verification shows that the power curves before and after conversion deviate within the steady-state wind conditions. It meets the accuracy requirements for engineering applications.

[0141] This embodiment also includes: when the verification detects an error in the model data, the system's error location, diagnosis, and repair guidance process.

[0142] Step U1: Error detection is triggered. The user performs a full-link parsing on a 15MW wind turbine model configuration file of unknown origin. The parsing stops at the first-level verification: the file structure integrity check finds that the .prj file is missing a drive chain block (DR), which is a required mandatory data block. The system outputs a first-level verification failure message and requests the user's confirmation on whether to continue subsequent verifications (the user can choose to skip the mandatory block check for in-depth diagnostics).

[0143] Step U2: The user selects to continue with in-depth diagnostics. The system skips the missing block constraint and continues with the second and third layer checks. The second layer check further reveals: the pitch rate upper limit parameter... Exceeding the typical maximum value of the hydraulic pitch system Triggering parameter range alarm; wind shear index Significantly lower than typical values ​​for onshore wind fields (Suspected to be set to marine environment but marine module not selected). Third-layer verification revealed: blade first-order flapping frequency. Hz and 3P frequency interval ( The Campbell diagram does not meet the resonance avoidance requirements, triggering a severe resonance risk warning.

[0144] Step U3: Error Report Generation. The system summarizes the three-layer verification results and generates a structured error diagnosis report, including: (a) an error / alarm classification table (2 critical errors + 3 alarms + 1 suggestion); (b) a detailed description of each error / alarm, including the error location (filename + data segment offset / parameter path), current value, expected range / conditions, possible causes, and recommended repair solutions; (c) error impact assessment—parameter errors that affect simulation convergence or result accuracy are marked with a "high priority repair" tag. The error report output is in human-readable text and machine-parseable JSON format, supporting integration into CI / CD quality control pipelines.

[0145] Step U4: Assisted Repair Guidance. For each error, the system provides specific repair guidance. For example, for a missing drive train block, the system suggests that the user can import default drive train parameters from a template of a similar model, or manually enter key parameters such as gearbox ratio and moment of inertia. For resonance risk alarms, the system recommends increasing the first-order frequency of the blades to [a specific value]. The frequency range (which can be adjusted by increasing blade stiffness or mass distribution) is available, and auxiliary analysis of frequency-parameter sensitivity is provided.

[0146] Example 3: The present invention also provides a device for parsing and verifying the simulation model file of a wind turbine generator set. The device includes a computer device, which includes a processor and a memory. The memory stores computer instructions. When the computer instructions are executed, the device implements the method for parsing and verifying the simulation model file of the wind turbine generator set.

[0147] Example 4, as Figure 5 As shown, the present invention also provides an electronic device 100 for implementing a method for parsing and verifying simulation model files of wind turbine generator sets.

[0148] The electronic device 100 includes a memory 101, at least one processor 102, a computer program 103 stored in the memory 101 and executable on at least one processor 102, and at least one communication bus 104.

[0149] The memory 101 can be used to store the computer program 103. The processor 102 implements the steps of the wind turbine whole machine simulation model file parsing and verification method described in the first aspect of the present invention by running or executing the computer program stored in the memory 101 and calling the data stored in the memory 101.

[0150] The memory 101 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created based on the use of the electronic device 100 (such as audio data), etc. In addition, the memory 101 may include non-volatile memory, such as hard disk, RAM, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0151] At least one processor 102 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 102 may be a microprocessor or any conventional processor. Processor 102 is the control center of electronic device 100, connecting various parts of electronic device 100 via various interfaces and lines.

[0152] The memory 101 in the electronic device 100 stores multiple instructions to implement a method for parsing and verifying a wind turbine whole-machine simulation model file; the processor 102 can execute multiple instructions to achieve the following: Obtain the set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format identification results; Based on the format recognition result, the corresponding format adapter is called to perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and preprocessed file data is generated. Based on the preprocessed file data, the physical domain resolver extracts simulation model parameters, maps the simulation model parameters to multiple data domains of a unified model object, and generates intermediate model data. Based on the intermediate model data, cross-module reference checks, physical unit normalization, and parameter reasonableness range checks are performed to generate semantic verification results. Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity verifications are performed to generate hierarchical verification results.

[0153] Example 5: If the modules / units integrated in the electronic device 100 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, and read-only memory (ROM).

[0154] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0155] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0156] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0157] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0158] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for parsing and verifying a simulation model file of a wind turbine generator set, characterized in that, The method includes: Obtain the set of model files to be parsed for the simulation model of the wind turbine, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format identification results; Based on the format recognition result, the corresponding format adapter is called to perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and preprocessed file data is generated. Based on the preprocessed file data, the physical domain resolver extracts simulation model parameters, maps the simulation model parameters to multiple data domains of a unified model object, and generates intermediate model data. Based on the intermediate model data, cross-module reference checks, physical unit normalization, and parameter reasonableness range checks are performed to generate semantic verification results. Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity verifications are performed to generate hierarchical verification results.

2. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 1, characterized in that, The process of identifying the format type and file reference relationships of model files in the set of model files to be parsed, and generating format identification results, includes: Read the file extension of the model file and generate candidate format types; Read the file header features of the model file, confirm the candidate format types based on the file header features, and generate a format confirmation result; Read the local structure of the model file according to the trial parsing rules corresponding to the format verification result, and generate the format verification result; Based on the format confirmation result and the format verification result, the format type is determined, and the reference paths between the model files are parsed to generate a format identification result that includes the format type and the file reference relationship.

3. The method for parsing and verifying the whole-machine simulation model file of a wind turbine according to claim 2, characterized in that, The step of calling the corresponding format adapter based on the format recognition result to perform format pre-detection, encoding conversion, and version compatibility judgment on the set of model files to be parsed, and generating preprocessed file data, including: When the format type is Bladed project format, the Bladed adapter is called to read the data block identifier, data block length, header field and payload data, and generate binary block structure data; When the format type is OpenFAST input file format, the OpenFAST adapter is invoked to establish a file reference topology based on the main input file and submodule files, and generate text file tree data. When the format type is a custom text format, the custom format adapter is invoked to generate structured mapping data based on the key path mapping template or the hierarchical mapping template; The binary block structure data, the text file tree data, or the structured mapping data are subjected to syntax pre-checking, encoding conversion, and version compatibility judgment to generate the preprocessed file data.

4. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 1, characterized in that, The step of mapping the simulation model parameters to multiple data domains of a unified model object to generate intermediate model data includes: The physical domain mapping rules determine the blade geometry domain, control parameter domain, environmental parameter domain, structural parameter domain, transmission chain parameter domain, electrical parameter domain, and simulation configuration domain. The target data domain is determined based on the parameter name, parameter path, data dimension, and physical unit of the simulation model parameters; The simulation model parameters are written into the target data domain in the form of key-value pairs, wherein the value type of the key-value pairs includes at least one of scalar, one-dimensional array, two-dimensional matrix and interpolation table; The multiple data fields that have been written are assembled into the unified model object to generate the intermediate model data.

5. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 4, characterized in that, The process of performing cross-module reference checks, physical unit normalization, and parameter reasonableness range checks based on the intermediate model data, and generating semantic verification results, includes: Extract parameter reference identifiers between different data fields in the intermediate model data, determine whether the referenced parameters exist, and generate a reference integrity check result. Identify the source units corresponding to the physical quantities in the intermediate model data, convert the source units into preset standard units, and generate unit-normalized data. Based on the wind turbine design parameter range library, the reasonable range of key parameters is determined, and the parameter range check results are generated according to the unit normalized data and the reasonable range. The semantic verification result is generated by summarizing the reference integrity check result, the unit normalized data, and the parameter range check result.

6. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 1, characterized in that, Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity checks are performed, wherein the file-level integrity check includes: Calculate the file checksum for each model file in the set of model files to be parsed, and generate the file integrity check result; Based on the format type in the format identification result, determine the required files, required data segments, or required data blocks, and generate a list of required structures. The set of model files to be parsed is compared with the list of required structures to generate a file structure integrity check result; Based on the file integrity check results and the file structure integrity check results, a file-level verification result is generated.

7. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 4, characterized in that, Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity checks are performed, wherein the module-level integrity check includes: Deterministic serialization processing is performed on multiple data domains of the unified model object to generate data domain serialization results; Calculate the module-level checksum for the serialization result of the data field and generate the module integrity check result; Count the number of parameters successfully parsed and mapped to the unified model object in each data domain, and generate parameter coverage based on the preprocessed file data or the list of format specification field definitions in the source file to count the total number of parameters actually existing in the source file. Module-level verification results are generated based on the module integrity check results and the parameter coverage.

8. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 7, characterized in that, Based on the intermediate model data and the semantic verification results, file-level, module-level, and parameter-level integrity checks are performed, wherein the parameter-level integrity check includes: Power parameters, aerodynamic parameters, blade geometry parameters, blade mass parameters, and operating frequency parameters are extracted from the intermediate model data to generate a set of key parameters; Based on the set of key parameters, power balance relationship verification, blade quality self-consistency verification, and resonance avoidance condition verification are performed to generate cross-domain consistency check results. Based on the cross-domain consistency check result and the parameter-level alarm level, a parameter-level verification result is generated, and the parameter-level verification result is written into the hierarchical verification result.

9. The method for parsing and verifying the simulation model file of a wind turbine generator set according to claim 7, characterized in that, Also includes: The hierarchical verification results are compared with preset passing conditions, which include passing file-level verification, module-level parameter coverage not lower than a preset coverage threshold, and no severe level alarms in parameter-level verification. When the hierarchical verification result meets the preset pass condition, the execution time of each parsing stage, the parameter coverage of each data field, the verification results of each layer and non-critical alarm information are recorded, and a parsing metadata report is generated. When the hierarchical verification result does not meet the preset pass condition, error location data is generated based on the failure locations in the file-level, module-level, and parameter-level integrity verification. Based on the error location data, the error type, impact level, and repair suggestions are determined, and an error diagnosis report is generated. Based on the module-level verification and identification of the modified data domain, the data domains with cross-domain dependencies with the modified data domain are determined based on the parameter reference identifiers or cross-domain consistency check results in the intermediate model data. Incremental verification is performed on the modified data domain and the data domains with cross-domain dependencies, and incremental verification results are generated. The hierarchical verification results are updated based on the incremental verification results.

10. A system for parsing and verifying simulation model files of a wind turbine generator set, characterized in that, The system includes: The format recognition module is used to obtain a set of model files to be parsed, identify the format type and file reference relationship of the model files in the set of model files to be parsed, and generate format recognition results. The file preprocessing module is used to call the corresponding format adapter based on the format recognition result, perform format pre-detection, encoding conversion and version compatibility judgment on the set of model files to be parsed, and generate preprocessed file data. The model parsing module is used to schedule the physical domain parser to extract simulation model parameters based on the preprocessed file data, map the simulation model parameters to multiple data domains of a unified model object, and generate intermediate model data. The semantic verification module is used to perform cross-module reference checks, physical unit normalization, and parameter reasonableness range checks based on the intermediate model data, and generate semantic verification results. The integrity verification module is used to perform file-level, module-level, and parameter-level hierarchical integrity verification based on the intermediate model data and the semantic verification results, and generate hierarchical verification results.

Images