A method for publishing state semantic verification and compliance release of multi-system access of a coal mine
Patent Information
- Application Number
- CN202611141037.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-29
- Publication Date
- 2026-10-30
AI Technical Summary
[0003]然而,现有的校验方法中,直接采用结构校验工具仅能判断字段是否存在,并未结合已发布标准、单位、枚举边界及版本来源进行语义级验证;SHACL等约束语言虽表达力强,但在煤矿业务中缺乏对章节来源、模板版本、实体类别及发布态边界的协同支撑;人工评审效率低下且留痕薄弱,难以适应高频接入与回归测试
本方案将耗时漫长的人工对账转变为可反复执行的自动化机器校验流程;仅对外提供发布态合同,防止编辑态标准外泄;校验输出附带问题清单与整改建议,结果清晰可解释,方便业务复核;采用三级放行判定机制,贴合工程验收场景,摒弃单一的通过或不通过二元判定;同时能够搭载于核心产品查询与发布快照链路,助力数据字典智能体产品持续迭代。
Smart Images

Figure CN123011855A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network security technology in the coal mining industry, and in particular to a method for publishing state semantic verification and compliance release for multi-system access in coal mines. Background Technology
[0002] As a crucial pillar of the energy industry, coal mines are evolving their information technology infrastructure from independent operation of single systems to multi-system data sharing and collaborative operation. During the integration of systems such as coal mining, tunneling, transportation, ventilation, safety, and dispatching into a unified platform, methods such as interface testing tools, structural verification tools (e.g., JSON Schema), knowledge graph constraint languages (e.g., W3CSHACL), and manual review are typically employed. Through field verification, interface document comparison, and confirmation via meeting minutes, a fundamental verification system is built from data access to interface integration.
[0003] However, existing verification methods, such as directly using structural verification tools, can only determine the existence of fields without semantic-level verification based on published standards, units, enumeration boundaries, and version sources. While constraint languages like SHACL are expressive, they lack collaborative support for chapter sources, template versions, entity categories, and published state boundaries in coal mining operations. Manual review is inefficient and leaves weak traces, making it difficult to adapt to high-frequency access and regression testing. Therefore, existing solutions generally lack a "read-only published contract" intermediate layer, which easily exposes edited content or mixes different version standards. This can lead to issues such as inconsistent units, different enumeration definitions, unclear chapter sources, or the use of unpublished fields in interfaces, thus affecting the accuracy of data sharing and the engineering-driven closed loop of access acceptance. Summary of the Invention
[0004] The main objective of this invention is to provide a method for publishing state semantic verification and compliance release for multi-system access in coal mines.
[0005] Another objective of this invention is to propose a release-state semantic verification and compliance release device for multi-system access in coal mines.
[0006] The third objective of this invention is to provide an electronic device.
[0007] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.
[0008] To achieve the above objectives, a first aspect of the present invention proposes a method for publishing state semantic verification and compliance release for multi-system access in coal mines, including: S1 reads the version information, field rules, and source terms of the data dictionary from the published snapshot and generates a read-only verification contract; S2, receive the access materials and extract the field path, field name, example value and unit to form a set of objects to be verified, and calculate the input material summary; S3 matches each object to be verified against the field rules in the verification contract, and performs progressive semantic verification on the successfully matched field pairs; S4 generates risk classification and rectification suggestions based on the results of progressive semantic verification, and gives a compliance release conclusion based on the risk aggregation results; S5 establishes a dynamic commitment and tracking mechanism for conditions being met, generates commitment objects to calculate rectification deadlines, and automatically performs downgrade and freeze processing on access scenarios that fail to rectify within the deadline.
[0009] Optionally, version information, field rules, and source terms of the data dictionary can be read from the release snapshot to generate a read-only validation contract, including: Read the dictionary main object, logical directory, document chapter, information entity, field list, and template source from dict_version_snapshot.snapshot_json, and generate a verification contract C. The structure of the verification contract C is defined as follows:
[0010] in, To verify the unique identifier of the contract, Encoding for the business dictionary, A unique identifier for each version snapshot. This is the dictionary snapshot version number. This is the official release timestamp for the snapshot. For logical directory hierarchy paths, Code the document template. For the document clause index mapping table, For the set of enumeration value indices, A dictionary mapping units of measurement. Configure field validation and conflict determination strategies. To verify the contract hash digest, For a set of field rules, any single field rule At least field encoding is required. Field Name Entity coding Entity Name Information entity types Data type encoding Units of measurement Value range constraints Semantic default value Enumerate the set of optional values Required field marker Read-only tag Source manuscript terms Source data table Display sorting sequence number Business extension attribute hash value ; The formula for generating the contract hash digest is as follows:
[0011] in, It is a one-way hash digest algorithm. This is a binary string concatenation operator. This is a summary of the original release snapshot itself. Perform stable sorting on the set of field rules.
[0012] Optionally, the system receives the access materials and extracts the field paths, field names, example values, and units to form a set of objects to be verified, and calculates the input material summary, including: Extract field paths from access materials Field names Chinese name Example value Declaration type ,unit Enumerated values Required field The object Interface path and source documents This forms a set of objects to be verified. ; For nested JSON, the field paths retain their complete hierarchy; for Excel templates, the table names, column names, and header order are preserved. Input material summary The calculation formula is:
[0013] in, This is a summary of the original content of the material. To perform a stable sort on set X.
[0014] Optionally, each object to be validated is matched against the field rules in the validation contract, including: For each object to be verified Search for candidate fields in the contract field rule set R. The matching score is calculated using the following formula:
[0015] in, , , , , , , These are the non-negative weighting coefficients corresponding to each matching dimension. For field encoding or alias similarity, Similarity between Chinese and English names For entity ownership consistency, For data type consistency, Unit compatibility For consistency of source terms, For structural path similarity, the values of each item range from [0,1]. like If the score is less than 0.60, it is considered a suspected reference to an unpublished field; if there are multiple candidates and the difference between the highest and second-highest scores is less than 0.05, it is considered an ambiguous field and will be transferred to manual confirmation.
[0016] Optionally, progressive semantic validation can be performed on successfully matched field pairs, including: For the matched field pairs ( , Generate verification vectors according to six types of verification:
[0017] in, For field existence, To classify entities, For data types, As a unit, For the range or enumeration, For source terms, each sub-item takes a value of 0, 0.5, or 1; unit checks support declarative, secure conversions; Enumeration verification calculates coverage using the formula :
[0018] in, This is the set of enumerated values extracted from the input data. To verify the predefined standard enumeration set within the contract; when If the value is less than 1 and an unknown key enumeration value appears, it is judged as needing rectification or blocking.
[0019] Optionally, risk classification and rectification suggestions are generated based on the results of progressive semantic verification, and a compliance release conclusion is given based on the risk aggregation results, including: For each issue, three attributes are generated: severity, rectifiable, and evidence. Severity is divided into BLOCK, FIX, and WARN levels. Rectifiable indicates whether the issue can be fixed by unit conversion, enumeration mapping, field renaming, or supplementary source description. Evidence saves the contract fields, input fields, and source clauses that triggered the issue. The formula for calculating the field-level risk score is:
[0020] in, , , , , , These are the non-negative weight coefficients corresponding to each verification dimension. This is a penalty item for serious defects; If the access object references an unpublished field, a missing required field, a critical enumeration out of bounds, or a source clause that does not belong to the current snapshotId, then =1 and directly list it as a blocking item; rectification suggestions are automatically generated according to the problem type; Aggregating field-level risks leads to access-level risks. The calculation formula is:
[0021] in, Let m be the severity weight coefficient for the j-th field, with values of 1.00, 0.50, and 0.20 for BLOCK, FIX, and WARN respectively, and m be the total number of fields to be validated. Release decision The formula is:
[0022] in, This indicates that any field has been found to have a violation level of blocking. This indicates that there is no critical violation at the blocking level. This indicates that all issues to be fixed are of the type that can be automatically corrected.
[0023] Optionally, a dynamic commitment and tracking mechanism can be established based on the conditions met, generating commitment objects and calculating rectification deadlines. For access scenarios that fail to rectify within the deadline, automatic downgrade and freezing processing can be implemented, including: Establish a dynamic commitment and tracking mechanism based on condition approval, and generate commitment objects:
[0024] in, To ensure a globally unique identifier, This is a set of abnormal issues that require rectification, with the owner being the entity responsible for recording the rectification. The deadline for rectification calculated by the system. This refers to the temporary access range permitted during the rectification phase. For the rectification progress tracking indicators, To pre-configure the handling strategies for situations where rectification is not completed by the deadline; The rectification period is calculated as follows:
[0025] in, Number of days for basic rectification and These are the shortest and longest rectification periods, respectively. The number of items requiring rectification. The number of items that can be automatically converted. Based on the importance of the access business, , , This is the corresponding weight adjustment coefficient; the promised object is only allowed temporary access within the allowedScope, and will be automatically downgraded to rejection or frozen access if rectification is not completed by the expiration date. Will , , , The verification time, access system, field matching table, problem list, rectification suggestions, conditional commitments, final conclusions, and operator are written into the acceptance voucher V, and a voucher summary is generated according to the formula. :
[0026] If the dictionary is republished later, the old credentials will still point to the original one. New access must use the new Re-verify.
[0027] To achieve the above objectives, a second aspect of the present invention provides a release-state semantic verification and compliance release device for multi-system access in coal mines, comprising: The read module is used to read version information, field rules, and source terms of the data dictionary from the published snapshot and generate a read-only verification contract; The extraction module is used to receive access materials and extract field paths, field names, example values and units to form a set of objects to be verified, and to calculate the summary of the input materials; The verification module is used to match each object to be verified with the field rules in the verification contract, and to perform progressive semantic verification on the successfully matched field pairs. The suggestion module is used to generate risk classification and rectification suggestions based on the results of progressive semantic verification, and to give a compliance release conclusion based on the risk aggregation results; The rectification module is used to establish a dynamic commitment and tracking mechanism based on the conditions met, generate commitment objects, calculate the rectification period, and automatically perform downgrade and freeze processing on access scenarios that have not been rectified within the time limit.
[0028] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0029] To achieve the above objectives, a third aspect of this application provides an electronic device, including a processor and a memory; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, for implementing the coal mine multi-system access release state semantic verification and compliance release method as described in the first aspect embodiment.
[0030] To achieve the above objectives, the fourth aspect of this application proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the release-state semantic verification and compliance release method for multi-system access in coal mines as described in the first aspect embodiment.
[0031] The embodiments of the present invention have the following beneficial effects: This solution transforms time-consuming manual reconciliation into an automated, repeatedly executable machine verification process; it only provides published contracts to prevent the leakage of edited standards; the verification output includes a problem list and rectification suggestions, with clear and interpretable results for easy business review; it adopts a three-level release judgment mechanism, which fits the engineering acceptance scenario and abandons the single binary judgment of pass or fail; at the same time, it can be integrated into the core product query and release snapshot link to help the data dictionary intelligent body product continuously iterate. Attached Figure Description
[0032] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a method for semantic verification and compliance release of multi-system access in coal mines, provided in an embodiment of the present invention; Figure 2 This is a structural diagram of a coal mine multi-system access release state semantic verification and compliance release device provided in an embodiment of the present invention. Detailed Implementation
[0033] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.
[0034] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.
[0035] The following describes, with reference to the accompanying drawings, a method and apparatus for publishing state semantic verification and compliance release for multi-system access in coal mines, according to embodiments of the present invention.
[0036] Example 1 This invention provides a method for publishing state semantic verification and compliance release for multi-system access in coal mines, such as... Figure 1 As shown, the method includes the following steps: S1 reads the version information, field rules, and source terms of the data dictionary from the published snapshot and generates a read-only verification contract.
[0037] In order to solidify the data dictionary publishing standard and achieve traceability and tamper-proof verification rule versions, this application generates a structured standardized verification contract with hash digest based on the read-only projection of dictionary publishing snapshots, and retains historical versions for compliance review.
[0038] In this embodiment, the system automatically reads the content of the published snapshot stored in a fixed manner, accurately extracts the complete core data stored inside dict_version_snapshot.snapshot_json, specifically covering all dictionary specification information such as the dictionary main object, logical directory, manuscript chapters, information entities, field list, and template source. Based on the above-mentioned original snapshot data, read-only projection processing is completed, thereby generating a standardized verification contract with a standardized structure, complete content, and full traceability, realizing a strong binding between the verification standard and the dictionary published version.
[0039] In this embodiment, the verification contract C generated by this application has a standardized and fixed structure, fully covering core elements such as version identifier, specification path, verification strategy, field rules, and hash tracing. The structure of the verification contract C is defined as follows:
[0040] In this embodiment of the application, each parameter in the above structure plays a different standardized control role, wherein A globally unique identifier for verifying contracts, used to distinguish between different batches and versions of verification contracts; A dedicated code for the business dictionary, used to locate the data dictionary specification for the corresponding business domain; This is a unique identifier for the dictionary version snapshot, enabling a one-to-one binding between the verification contract and the published snapshot; version is the version number corresponding to the dictionary snapshot, used to distinguish version iterations. Record the timestamp of the official snapshot release for tracing the release sequence; The logical directory hierarchy path for the dictionary standard ensures a consistent standard hierarchy. Encode the manuscript template to correspond to a standard template compiled from a dictionary; Create a document clause index mapping table to achieve a precise correspondence between fields and official document clauses; This serves as a set of enumeration value indices, unifying the enumeration standards for various business applications. A dictionary mapping measurement units is used to standardize measurement conversion rules for various business operations; Configure the preset field validation and conflict determination strategies to unify the validation and determination logic; A unique hash digest for verifying contract integrity and tamper-proof verification; It is the core set of field rules, which carries all field validation constraint standards.
[0041] In the embodiments of this application, Any single field rule in the field rule set All are configured with comprehensive and refined constraint parameters, which can fully support subsequent multi-dimensional semantic verification work, and single field rules At least field encoding is required. Field Name Entity coding Entity Name Information entity types Data type encoding Units of measurement Value range constraints Semantic default value Enumerate the set of optional values Required field marker Read-only tag Source manuscript terms Source data table Display sorting sequence number Business extension attribute hash value h. The above parameters fully cover field identity information, type constraints, value constraints, permission constraints, source basis, display rules, and business extension attributes, ensuring the comprehensiveness and accuracy of subsequent field validation.
[0042] In this embodiment of the application, to achieve the tamper-proof, reproducible, and traceable characteristics of the verified contract, this application uses a fixed SHA-256 one-way hash digest algorithm to generate a unique hash digest for the verified contract. The specific calculation formula is as follows:
[0043] Among them, SHA-256(·) is an industry-standard one-way hash digest algorithm that can guarantee that the digest is irreversible and tamper-proof; This is a binary string concatenation operator used to concatenate multiple sets of core trace parameters; This is a hash digest of the original published snapshot itself, enabling a strong binding association between the verification contract and the upstream published snapshot; To perform a stable sorting operation on the entire set of field rules, avoid inconsistencies in hash results caused by differences in field sorting, and ensure that the hash results of the verification contracts generated by the same version snapshot are unique and reproducible.
[0044] In this embodiment, a version iteration retention mechanism is adopted to ensure compliance traceability throughout the entire lifecycle. Whenever the business data dictionary is iterated, updated, and republished, the system automatically generates a completely new version. Version snapshots are generated, and new corresponding verification contracts are automatically generated based on the new snapshots to adapt to the latest dictionary specification standards.
[0045] In this embodiment, the system does not overwrite or discard historical version verification contracts, but instead retains and archives all historical version contracts in their entirety. In subsequent project acceptance, compliance review, problem tracing, version comparison and responsibility determination scenarios, the corresponding historical version verification contracts can be retrieved for verification at any time, which completely solves the defects of traditional verification methods such as no record of standard iteration and inability to review historical acceptance, and comprehensively improves the standardization and traceability of data access compliance verification.
[0046] In this embodiment, a standardized verification contract with multi-dimensional field constraints is constructed by reading the complete data of the dictionary release snapshot. A unique contract digest is generated by combining stable sorting and SHA-256 hash algorithm. At the same time, the old and new versions of the contract are iteratively retained, which lays the foundation for subsequent calculation of the input material digest.
[0047] S2 receives the access materials and extracts the field paths, field names, example values, and units to form a set of objects to be verified, and calculates the input material summary.
[0048] To ensure compatibility with multiple types of data access materials and address issues such as overlapping materials with the same name and difficulty in tracing changes, this application performs structured parsing of the original access materials to generate standardized objects to be verified, and calculates a unique input hash to solidify the material content and bind it to two-way traceability.
[0049] This application has strong compatibility with access materials, covering mainstream data delivery formats in various engineering implementation scenarios. The access materials that the system can reliably receive and identify include field lists, JSON Schema, interface examples, Excel templates, real-time data examples, and system self-description documents. It can adapt to data access scenarios of different business systems, different development teams, and different delivery habits, greatly improving the universality and adaptability of the overall data compliance verification scenario.
[0050] In this embodiment, the system performs refined and comprehensive structured field extraction processing on the received raw access materials, accurately extracting all core field information required for verification, specifically including field paths. Original field name Field Chinese Name Field example values Field declaration type Field measurement units Field enumeration values Required fields Field to Object Hint Data interface path and source documents The system integrates all the standardized field information extracted above to construct a unified and dimensionally complete set of objects to be verified. This set of objects to be verified is uniformly represented as follows: This provides a standardized input data foundation for subsequent field matching, semantic validation, and risk assessment.
[0051] This application sets differentiated and targeted parsing and retention rules for access materials with different structures, effectively avoiding verification and matching failures caused by parsing deviations between different formats. In the embodiments of this application, for access data in nested JSON format, the system fully retains the multi-level nested path structure of fields, strictly restoring the data hierarchy relationship. For example, the real-time voltage field on the low-voltage side of the device fully retains the hierarchical path form of device.lowVoltage.realtimeVoltage, ensuring accurate matching with the structured path of the verification contract in the future. For access materials in Excel template type, the system fully retains the original data table name, data column name, and the original sorting order of the table header, fully restoring the original structural features of the Excel material, ensuring that the parsing result is completely consistent with the accessed original material, and avoiding verification errors caused by structural loss or disordered order.
[0052] In this embodiment, to overcome the technical shortcomings of traditional file tracing methods that rely solely on filenames to identify versions, such as file overwriting with the same name, lack of record-keeping for content updates, and inability to trace changes, this application performs a global summary calculation based on the original complete content of the accessed material to generate a unique and tamper-proof input material summary. In this embodiment, the specific calculation formula for the input material summary is as follows:
[0053] in, To access the overall summary value corresponding to the original complete content of the material, which can uniquely identify the original material content, For the set of objects to be verified Perform stable sorting to eliminate summary disturbances caused by differences in field sorting, ensuring that the same set of access materials can generate a unique and fixed summary regardless of the field display order. This ensures the uniqueness and stability of material version identification.
[0054] In this embodiment, a two-way binding traceability mechanism is established, and all subsequent acceptance certificates generated by the system will be simultaneously bound to it. and This enables two-way locking of data verification standards and access materials, allowing for tracing the official dictionary standard version on which the verification is based and accurately locking the content of the original access materials corresponding to the verification. This achieves a full-link, two-way traceable compliance verification system, comprehensively improving the standardization, credibility, and auditability of data access verification.
[0055] In this embodiment, a standardized set to be verified is constructed by differentially parsing various access materials and extracting all fields. An input digest is generated by combining stable sorting and the SHA-256 algorithm. and Dual binding enables full traceability of verification standards and access materials, laying the foundation for subsequent semantic verification.
[0056] S3 matches each object to be verified against the field rules in the verification contract, and performs progressive semantic verification on the successfully matched field pairs.
[0057] To address the issues of low accuracy and coarse verification logic in single-text matching methods, this application employs a multi-dimensional weighted algorithm to complete field matching and quantitatively evaluates field compliance levels based on progressive six-dimensional semantic verification to identify various types of field anomalies.
[0058] In this embodiment of the application, the system performs verification on each object to be verified. All of them will be fully traversed and searched within the constructed contract field rule set R, comparing each candidate standard field one by one. This approach abandons the crude method of single-dimensional name matching and instead employs a multi-dimensional similarity weighted algorithm to accurately calculate the matching score. This quantifies the degree of fit between the field to be verified and the standard field. The corresponding matching score calculation formula is as follows:
[0059] in, , , , , , , These are the non-negative weighting coefficients corresponding to each matching dimension. Represents the similarity of field codes or aliases. This represents the similarity between Chinese and English names. Represents the consistency of entity affiliation. Represents data type consistency. Representative unit compatibility, Consistency of source terms Representing structural path similarity, all similarity indicators are uniformly constrained to a range of 0 to 1, with values closer to 1 indicating a higher degree of matching fit in the corresponding dimension. This application, combining business verification priorities with actual engineering scenarios, pre-defines an optimal fixed weight ratio. The weight parameters for a1 to a7 are 0.20, 0.20, 0.15, 0.15, 0.15, 0.10, and 0.05, respectively. Through differentiated weight configuration, priority is given to ensuring the matching accuracy of core identifiers such as field codes and names, while also considering key constraints such as entities, types, and units. Simultaneously, the weight ratio of path matching is weakened, aligning with the complex adaptation scenarios of actual data access and making the matching results more in line with business compliance requirements.
[0060] This application sets standardized and quantifiable thresholds for judging matching results to achieve automated identification and classification of field matching anomalies. In an embodiment of this application, when the maximum matching score of a single object to be verified... When the score is less than 0.60, the system determines that the field is a suspected reference to an unpublished field, marks it as an abnormal field, and includes it in the abnormal control queue. If the same object to be verified matches multiple high-scoring candidate standard fields, and the difference between the highest and second-highest scores is less than 0.05, the system determines that the field is an ambiguous field with matching uncertainty. In this case, the system will not automatically release the verification result of the field, but will actively transfer it to the manual confirmation process, effectively avoiding verification errors caused by field matching ambiguity and ensuring the rigor of the verification results.
[0061] In this embodiment of the application, after the system completes the field matching and filtering work, it performs a process for all successfully matched field pairs. A progressive six-dimensional hierarchical semantic verification mechanism is initiated to deeply verify field compliance from multiple dimensions and generate standardized structured verification vectors. The verification vector expression for a single field is as follows:
[0062] in, This is the result of the field existence check. The result of entity category attribution verification. For data type validation results, Unit verification results For the value range or enumeration compliance verification result, The source clause matching and verification results comprehensively cover the core dimensions of field compliance verification.
[0063] In this application embodiment, three standardized scores are set for each verification sub-item: 0 points, 0.5 points, and 1 point, forming a quantitative verification judgment standard. A score of 0 points indicates that the verification dimension fails and there is a fatal compliance anomaly. A score of 0.5 points indicates that there is a slight deviation that can be corrected through conversion adaptation or supplementary explanation. A score of 1 point indicates that the verification dimension is fully compliant and passes the verification. By quantifying the scores, the verification results are standardized and quantifiable, which is completely different from the traditional fuzzy manual judgment method.
[0064] In this embodiment, the unit verification dimension of this application breaks through the limitations of traditional simple string comparison, possessing intelligent unit conversion and adaptation capabilities. The system has built-in preset secure unit conversion logic, which can automatically identify compliant unit magnitude differences and complete adaptation verification. For example, kV and V can be automatically converted and adapted through a fixed ratio of 1000 to determine compliance. Regarding... and In scenarios involving high-precision and error-prone unit conversions such as A and mA, the system does not simply judge compliance or non-compliance. Instead, it accurately identifies unit differences and automatically generates corresponding standardized rectification suggestions and accurate conversion coefficients, providing a clear basis for subsequent field standardization rectification, balancing the rigor of verification with the feasibility of rectification.
[0065] In this application embodiment, for compliance verification scenarios of enumeration-type fields, this application sets a dedicated enumeration coverage calculation formula to accurately quantify the degree of compliance between the input enumeration value and the standard enumeration value:
[0066] in, This is the set of enumerated values extracted from the input data. To verify the predefined standard enumeration set within the contract. When the calculated enumeration coverage is less than 1, and the input materials contain unknown key enumeration values not defined in the contract, the system directly determines that the field has a compliance defect, marks it as an item requiring rectification or a blocking item, and prevents illegal unknown enumeration values from entering the business system from the source, ensuring the uniformity of data enumeration standards.
[0067] In this embodiment, a progressive, step-by-step verification logic is innovatively adopted. The six verification dimensions are not executed independently and in parallel, but are performed step-by-step according to a fixed priority order. The specific verification order is: field existence verification, entity attribution verification, type and unit verification, value range enumeration verification, naming convention verification, and source clause verification. This progressive verification logic has a pre-blocking feature. When a preceding verification dimension determines an anomaly and blocks it, the system directly terminates all subsequent verification processes. For example, after identifying a fatal anomaly such as a non-existent field, subsequent verification operations such as unit conversion and enumeration matching are no longer redundantly executed. Instead, the system is directly included in the unpublished field anomaly handling process, effectively reducing unnecessary calculations, significantly improving the overall verification efficiency, and making anomaly localization more accurate and targeted.
[0068] In this embodiment, a seven-dimensional weighted similarity formula is used to match the field to be verified with the standard field and distinguish the anomaly type. For the successfully matched field, a progressive six-dimensional semantic verification is performed. The compliance status of the field is determined based on the score rules, unit conversion logic and enumeration coverage, which lays the foundation for generating a compliance release conclusion.
[0069] S4 generates risk classification and rectification suggestions based on the results of progressive semantic verification, and gives a compliance release conclusion based on the risk aggregation results.
[0070] To avoid the subjectivity of manual judgment and achieve anomaly classification, risk quantification, and automated compliance decision-making, this application calculates field risk and overall access risk based on semantic verification results, outputs release conclusions according to standardized rules, and automatically generates rectification suggestions.
[0071] In this embodiment, the system automatically classifies the risk level, determines the repairability, and retains evidence of the problem for each field anomaly identified during verification. At the same time, it accurately calculates the risk score of a single field and the overall access risk score based on a multi-level weighted algorithm, outputs a unique and objective compliance release conclusion based on standardized judgment rules, and accurately pushes corresponding rectification and optimization suggestions for various anomaly scenarios, realizing integrated automated processing of data verification, risk assessment, rectification guidance, and compliance decision-making.
[0072] In this embodiment, the system uniformly configures three core control attributes for each anomaly generated during verification: severity (risk level), rectifiable (remediable), and evidence (evidence traceability). The system achieves refined classification and control of anomalies and end-to-end traceability through the combination of these three attributes. In this embodiment, the severity attribute is divided into three standardized risk levels: BLOCK, FIX, and WARN, quantifying the severity of the anomaly. The rectifiable attribute accurately marks whether the current field anomaly can be automatically or manually repaired through standardized methods such as unit conversion adaptation, enumerated value mapping matching, field name redefinition, and supplementary source clause explanations, providing a basis for subsequent conditional release and rectification closure. The evidence (evidence traceability) attribute accurately solidifies the contract standard field information corresponding to the anomaly, the original information of the input anomaly field, and the corresponding source clause content, ensuring that each anomaly can be accurately traced and verified, improving the credibility and auditability of the verification results.
[0073] In this embodiment, a dedicated field-level risk score weighted calculation formula is established. This formula quantifies the severity of anomalies in a single field through multi-dimensional verification results, accurately quantifying the compliance risk level of each field to be verified. The corresponding field-level risk score calculation formula is as follows:
[0074] in, , , , , , These are the non-negative weight coefficients corresponding to each validation dimension, with weight values of 0.30, 0.15, 0.15, 0.15, 0.15, and 0.10 respectively. Through differentiated weight configuration, the risk weights for field existence validation are emphasized, prioritizing the identification of fatal field missing issues; the formula... This is a severe defect penalty item used to increase the risk weight of high-risk, fatal anomalies.
[0075] In this application embodiment, the triggering mechanism for serious defect penalties is clearly defined. When fatal violations occur in the access data to be verified, such as referencing unpublished fields, missing required core fields, out-of-bounds key business enumeration values, or field source terms not matching the current snapshot version, the system will force a value assignment. =1 indicates that the corresponding field is subject to increased risk assessment, and the field is directly marked as a BLOCK-level risk to block high-risk and non-compliant data access from the source, ensuring the standardization and security of data access.
[0076] In this embodiment, the system can automatically generate precise and actionable differentiated rectification suggestions for different types of field anomalies, achieving accurate matching between problems and rectification solutions. In this embodiment, for anomalies involving inconsistent units, the system automatically outputs a linear conversion formula. The system clarifies unit conversion factors and rules; for anomalies such as mismatched enumeration values or insufficient enumeration coverage, it automatically generates a complete mapping table between input enumerations and standard enumerations to guide enumeration standardization correction; for anomalies such as missing fields, the system proactively pushes the candidate standard fields with the highest matching degree and the corresponding source clause information, providing a reference for field rectification; for anomalies such as missing source clauses, the system accurately prompts the dictionary release chapter number and data table number information that need to be supplemented, comprehensively improving the efficiency and standardization of rectification work.
[0077] In this embodiment, after calculating and classifying the risk score of a single field, the application further integrates the risk data of all fields to be verified through a weighted aggregation algorithm to calculate the overall comprehensive risk value of this data access, thereby achieving a quantitative assessment of the overall access compliance. The overall risk calculation formula is as follows:
[0078] in, The system pre-sets standardized weighting rules for the severity weighting coefficients corresponding to different risk level fields. The weight of the BLOCK level field is 1.00, the weight of the FIX level field is 0.50, and the weight of the WARN level field is 0.20. m is the total number of all fields to be verified in this access verification. Through hierarchical weighted aggregation, the system accurately reflects the impact weight of different severity anomalies on the overall access compliance, ensuring that the overall risk assessment results are objective and reasonable.
[0079] In this embodiment, based on the overall risk value and field anomaly type, a standardized compliance release decision mechanism that is fully quantified and free from subjective human intervention is established. A unique compliance decision result is output through a fixed judgment formula. The specific decision logic is as follows:
[0080] in, This indicates that any field has been found to have a violation level of blocking. This indicates that there is no critical violation at the blocking level. This indicates that all issues to be addressed fall into the category of those that can be automatically corrected. This quantitative decision-making system completely eliminates the arbitrariness of manual judgment, ensuring that every compliance conclusion is technically calculable, reproducible, and auditable.
[0081] In this embodiment of the application, multiple control attributes are configured for verification anomalies, a weighted formula is used to calculate the risk of a single field and the overall access risk, REJECT, PASS, and CONDITIONAL decisions are output according to quantitative judgment rules, and the effectiveness of the solution is verified by combining the mobile substation access case.
[0082] S5 establishes a dynamic commitment and tracking mechanism for conditions being met, generates commitment objects to calculate rectification deadlines, and automatically performs downgrade and freeze processing on access scenarios that fail to rectify within the deadline.
[0083] To address the issues of lack of quantitative control over conditional rectification, unconstrained temporary access, easily tampered acceptance records, and mixed use of old and new standards, this application constructs a dynamic rectification commitment mechanism and generates tamper-proof acceptance certificates, forming a complete compliance control closed loop based on version isolation.
[0084] In this embodiment of the application, the system generates a globally unique structured commitment object P for each access scenario where the conditions are met. The structure of the commitment object P is defined as follows:
[0085] in, To ensure a unique identifier across the entire system, used to distinguish different rectification items; This is a set of issue numbers for the abnormal problems that need to be rectified; the owner record records the entity responsible for rectification. The deadline for rectification calculated by the system; Define the scope of temporary access that is permitted during the rectification phase; Indicators for tracking the progress of rectification; Pre-configure the handling strategies for situations where rectification is not completed by the deadline, and ensure that all parameters fully support the access conditions and all control elements of the scenario.
[0086] In this embodiment, to overcome the management chaos caused by arbitrarily setting rectification deadlines manually, this application intelligently calculates the rectification deadline by comprehensively considering multiple factors such as the number of anomalies to be rectified, the type of anomaly repair, and the importance of the business. The formula for calculating the rectification deadline is as follows:
[0087] in, Represents the number of days for basic rectification. , These are the shortest and longest allowable rectification periods, respectively. This represents the number of abnormal items requiring manual intervention for rectification. The number of anomalies that can be automatically converted and repaired based on system rules; Criticism is the importance coefficient of the access service; , , The corresponding weight adjustment coefficient is used to quantify and generate the rectification period based on this formula, ensuring that the period setting is objective and reasonable.
[0088] In this embodiment of the application, the commitment object imposes strict constraints on the scope of temporary access, and access services can only be provided within the specified range. Data interaction should be conducted within defined boundaries. For example, access can be restricted to test databases only, or permissions can be limited to reading non-critical business metrics. This avoids unrestricted data access during the rectification phase, which could lead to system compliance and data risks. Once reached... If the system detects any anomalies before the rectification deadline and the rectification process is not completed, an automatic trigger will be initiated. Pre-defined handling strategies are implemented to perform downgraded operations such as rejecting access requests, freezing access permissions, and blocking data channels, thereby preventing businesses from accessing the system with long-term non-compliance and defects.
[0089] For all access scenarios where verification is complete and rectification is closed-loop, the system uniformly generates a standardized acceptance certificate V. In this embodiment, the acceptance certificate is fully collected. , , , The verification process includes execution time, access system identifier, field matching table, list of abnormal issues, automatically generated rectification suggestions, conditional rectification commitment information, final compliance conclusion, and operator information, achieving complete retention of information across the entire verification chain. In this embodiment, the acceptance certificate uses the SHA-256 one-way hash algorithm to generate a unique and tamper-proof certificate digest. The hash digest ensures the immutability of the acceptance certificate content, meeting audit credibility requirements. The certificate digest calculation formula is:
[0090] In this embodiment, the standardized acceptance certificate has good external interface capabilities and can be directly connected to CI / CD automated pipelines, system integration and debugging record modules, and audit traceability systems to support automated access acceptance and routine compliance audits.
[0091] In this embodiment, a strict version isolation and traceability mechanism is established. After the data dictionary is iteratively updated and republished, the historical acceptance certificate remains bound to the original. And the corresponding old version Historical acceptance records must be kept complete and valid, and can be reviewed and traced at any time; newly launched business access must be based on the new version of the verification contract generated by the new snapshot and the entire verification process must be re-executed to forcibly prevent access parties from continuing to use outdated standards to carry out data docking and causing compliance loopholes.
[0092] In this embodiment, the entire compliance verification process can be lightweighted and upgraded based on the existing product release snapshot system. Based on the existing dict_version_snapshot snapshot storage capability of the system, a contract projection module, a semantic verification module, a rectification commitment management module, and an acceptance certificate generation module are added. The traditional platform's data dictionary release and query capabilities are upgraded into a closed-loop semantic compliance management system that integrates standard solidification, intelligent field verification, risk classification assessment, rectification tracking and control, and certificate version traceability.
[0093] In the embodiments of this application, the complete chain of this application relies on standardized mathematical models, version binding hash mechanisms, and automated closed-loop processes to achieve control, which is different from the fragmented control mode of ordinary data adapters, general interface testing tools, and manual quality access control. It has outstanding technical advantages such as standardized rules, quantifiable risks, full traceability, and sustainable iteration of mechanisms.
[0094] This application uses a real-world mobile substation access scenario as a typical example to verify the implementation of the entire risk classification and compliance decision-making process. Taking mobile substation access as an example, access party X submits 12 fields (including...) , , , (etc.). The system releases a snapshot projection contract from the "Underground Coal Mine Equipment Data Dictionary Mobile Substation" v0.2. , =0x8f3a…. Matches the contract field "Real-time Voltage on Low-Voltage Side" with M=0.92 and Q=(1,1,1,1,1,1). =0; The "leakage current blocking resistor setting value" is matched to M=0.83, with the unit specified in Ω, while the contract requires kΩ. =0.5 (convertible) ≈0.075, severity=FIX, rectifiable=true; The "communication status" M=0.78 matches, but the access party enumeration is 0 / 1 / 2 / 3, and the contract is in three states: online / offline / abnormal. =0.5, ≈0.075, severity=FIX; There is no corresponding field in the contract. =0.42, =0, =1, severity=BLOCK, =1.30. After aggregation ≈0.115, BLOCK exists, Decision=REJECT. The access party deleted it according to the rectification suggestions. After resubmitting, the block was cleared. ≈0.007, Decision=PASS, generate acceptance certificate. =0xc7e1…, binding With the new .
[0095] Example 2 This invention provides a release-state semantic verification and compliance release device 10 for multi-system access in coal mines, such as... Figure 2 As shown, the device includes: The reading module 100 is used to read the version information, field rules and source terms of the data dictionary from the published snapshot and generate a read-only verification contract; The extraction module 200 is used to receive the access materials and extract the field paths, field names, example values and units to form a set of objects to be verified, and to calculate the summary of the input materials; The verification module 300 is used to match each object to be verified with the field rules in the verification contract, and to perform progressive semantic verification on the successfully matched field pairs. Module 400 is used to generate risk classification and rectification suggestions based on the results of progressive semantic verification, and to give a compliance release conclusion based on the risk aggregation results; The rectification module 500 is used to establish a dynamic commitment and tracking mechanism for conditions that have been met, generate commitment objects, calculate the rectification period, and automatically perform downgrade and freeze processing on access scenarios that have not been rectified within the time limit.
[0096] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0097] Example 3 To implement the methods of the above embodiments, the present invention also provides an electronic device, which includes a memory and a processor; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the various steps of the methods described above.
[0098] Example 4 To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.
[0099] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
[0100] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.
[0101] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.
Claims
1. A method for publishing state semantic verification and compliance release in multi-system access in coal mines, characterized in that, include: S1 reads the version information, field rules, and source terms of the data dictionary from the published snapshot and generates a read-only verification contract; S2, receive the access materials and extract the field path, field name, example value and unit to form a set of objects to be verified, and calculate the input material summary; S3 matches each object to be verified against the field rules in the verification contract, and performs progressive semantic verification on the successfully matched field pairs; S4 generates risk classification and rectification suggestions based on the results of progressive semantic verification, and gives a compliance release conclusion based on the risk aggregation results; S5 establishes a dynamic commitment and tracking mechanism for conditions being met, generates commitment objects to calculate rectification deadlines, and automatically performs downgrade and freeze processing on access scenarios that fail to rectify within the deadline.
2. The method according to claim 1, characterized in that, The step of reading version information, field rules, and source terms from the data dictionary in the published snapshot to generate a read-only verification contract includes: Read the dictionary main object, logical directory, document chapter, information entity, field list, and template source from dict_version_snapshot.snapshot_json, and generate a verification contract C. The structure of the verification contract C is defined as follows: in, To verify the unique identifier of the contract, Encode the business dictionary. A unique identifier for each version snapshot. This is the dictionary snapshot version number. This is the official release timestamp for the snapshot. For logical directory hierarchy paths, Code the document template. For the document clause index mapping table, For the set of enumeration value indices, A dictionary mapping units of measurement. Configure field validation and conflict determination strategies. To verify the contract hash digest, For a set of field rules, any single field rule At least field encoding is required. Field Name Entity coding Entity Name Information entity types Data type encoding Units of measurement Value range constraints Semantic default value Enumerate the set of optional values Required field marker Read-only tag Source manuscript terms Source data table Display sorting sequence number Business extension attribute hash value ; The formula for generating the contract hash digest is as follows: in, It is a one-way hash digest algorithm. This is a binary string concatenation operator. This is a summary of the original release snapshot itself. Perform stable sorting on the set of field rules.
3. The method according to claim 1, characterized in that, The process involves receiving access materials and extracting field paths, field names, example values, and units to form a set of objects to be verified, and calculating the input material summary, including: Extract field paths from access materials Field names Chinese name Example value Declaration type ,unit Enumerated values Required field The object Interface path and source documents This forms a set of objects to be verified. ; For nested JSON, the field paths retain their complete hierarchy; for Excel templates, the table names, column names, and header order are preserved. Input material summary The calculation formula is: in, This is a summary of the original content of the material. To perform a stable sort on set X.
4. The method according to claim 1, characterized in that, The process of matching each object to be verified with the field rules in the verification contract includes: For each object to be verified Search for candidate fields in the contract field rule set R. The matching score is calculated using the following formula: in, , , , , , , These are the non-negative weighting coefficients corresponding to each matching dimension. For field encoding or alias similarity, Similarity between Chinese and English names For entity ownership consistency, For data type consistency, Unit compatibility For consistency of source terms, For structural path similarity, the values of each item range from [0,1]. like If the score is less than 0.60, it is considered a suspected reference to an unpublished field; if there are multiple candidates and the difference between the highest and second-highest scores is less than 0.05, it is considered an ambiguous field and will be transferred to manual confirmation.
5. The method according to claim 1, characterized in that, The progressive semantic validation performed on the successfully matched field pairs includes: For the matched field pairs ( , Generate verification vectors according to six types of verification: in, For field existence, To classify entities, For data types, As a unit, For the range or enumeration, For source terms, each sub-item takes a value of 0, 0.5, or 1; unit checks support declarative, secure conversions; Enumeration verification calculates coverage using the formula : in, This is the set of enumerated values extracted from the input data. To verify the predefined standard enumeration set within the contract; when If the value is less than 1 and an unknown key enumeration value appears, it is judged as needing rectification or blocking.
6. The method according to claim 1, characterized in that, The process of generating risk classification and rectification suggestions based on the results of progressive semantic verification, and giving a compliance release conclusion based on the risk aggregation results, includes: For each issue, three attributes are generated: severity, rectifiable, and evidence. Severity is divided into BLOCK, FIX, and WARN levels. Rectifiable indicates whether the issue can be fixed by unit conversion, enumeration mapping, field renaming, or supplementary source description. Evidence saves the contract fields, input fields, and source clauses that triggered the issue. The formula for calculating the field-level risk score is: in, , , , , , These are the non-negative weight coefficients corresponding to each verification dimension. This is a penalty item for serious defects; If the access object references an unpublished field, a missing required field, a critical enumeration out of bounds, or a source clause that does not belong to the current snapshotId, then =1 and directly list it as a blocking item; rectification suggestions are automatically generated according to the problem type; Aggregating field-level risks leads to access-level risks. The calculation formula is: in, Let m be the severity weight coefficient for the j-th field, with values of 1.00, 0.50, and 0.20 for BLOCK, FIX, and WARN respectively, and m be the total number of fields to be validated. Release decision The formula is: in, This indicates that any field has been found to have a violation level of blocking. This indicates that there is no critical violation at the blocking level. This indicates that all issues to be fixed are of the type that can be automatically corrected.
7. The method according to claim 1, characterized in that, The established dynamic commitment and tracking mechanism generates commitment objects, calculates rectification deadlines, and automatically performs downgrade and freeze processing on access scenarios that fail to rectify within the deadline, including: Establish a dynamic commitment and tracking mechanism based on condition approval, and generate commitment objects: in, To ensure a globally unique identifier, This is a set of abnormal issues that require rectification, with the owner being the entity responsible for recording the rectification. The deadline for rectification calculated by the system. This refers to the temporary access range permitted during the rectification phase. For the rectification progress tracking indicators, To pre-configure the handling strategies for situations where rectification is not completed by the deadline; The rectification period is calculated as follows: in, Number of days for basic rectification and These are the shortest and longest rectification periods, respectively. The number of items requiring rectification. The number of items that can be automatically converted. Based on the importance of the access business, , , This is the corresponding weight adjustment coefficient; the promised object is only allowed temporary access within the allowedScope, and will be automatically downgraded to rejection or frozen access if rectification is not completed by the expiration date. Will , , , The verification time, access system, field matching table, problem list, rectification suggestions, conditional commitments, final conclusions, and operator are written into the acceptance voucher V, and a voucher summary is generated according to the formula. : If the dictionary is republished later, the old credentials will still point to the original one. New access must use the new Re-verify.
8. A release-state semantic verification and compliance release device for multi-system access in coal mines, characterized in that, include: The read module is used to read version information, field rules, and source terms of the data dictionary from the published snapshot and generate a read-only verification contract; The extraction module is used to receive access materials and extract field paths, field names, example values and units to form a set of objects to be verified, and to calculate the summary of the input materials; The verification module is used to match each object to be verified with the field rules in the verification contract, and to perform progressive semantic verification on the successfully matched field pairs. The suggestion module is used to generate risk classification and rectification suggestions based on the results of progressive semantic verification, and to give a compliance release conclusion based on the risk aggregation results; The rectification module is used to establish a dynamic commitment and tracking mechanism based on the conditions met, generate commitment objects, calculate the rectification period, and automatically perform downgrade and freeze processing on access scenarios that have not been rectified within the time limit.
9. An electronic device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the method as described in any one of claims 1-7.
10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-7.
