Industrial safety event automatic notification and rectification double-track verification method and system

Abstract

The application discloses an industrial safety event automatic notification and rectification double-track verification method and system, and belongs to the field of industrial safety management. The method comprises the following steps: S1, collecting and normalizing a plurality of source safety alarms; S2, calling a safety treatment intelligent agent to aggregate and denoise alarm records, and generating a unique safety event object; S3, automatically generating a structured safety notification; S4, manually verifying and confirming a key node, and then issuing the safety notification to a responsible unit and creating a rectification task; S5, receiving a rectification report submitted by the responsible unit; S6, performing double-track verification of rectification results in parallel; S7, fusing and comparing the double tracks, and generating a verification conclusion; and S8, performing closed-loop control according to the verification conclusion: if the verification is passed, archiving the event is closed; if the verification is not passed, automatically generating a rejection notice and starting the next round of rectification. The application further discloses an industrial safety event automatic notification and rectification double-track verification system. The application can realize minute-level automatic closed-loop treatment of industrial safety events.

Description

Technical Field

[0001] This invention relates to the field of industrial network security and information security technology, and in particular to a dual-track verification method and system for automatic reporting and rectification of industrial security incidents. Background Technology

[0002] In industrial security operations, various security protection devices, such as situational awareness platforms, firewalls, intrusion detection systems, industrial control system security audits, vulnerability scanners, and log auditing systems, continuously generate a large number of security alerts. Existing handling methods mainly include the following categories:

[0003] (1) Manual assessment and handling mode: In this mode, safety analysts need to review the alarm information generated by various safety devices one by one, judge the authenticity and severity of the alarms based on their personal experience, manually write safety notices and issue them to the responsible units; after the rectification is completed, the management personnel conduct written acceptance based on the rectification report submitted by the responsible units. This mode relies heavily on the professional experience of the analysts, has low handling efficiency and slow response, and is difficult to achieve 24 / 7 continuous operation.

[0004] (2) SOAR Automated Orchestration Mode: The Security Orchestration and Automated Response (SOAR) platform can automatically create work orders, send notifications, and call handling interfaces based on pre-set scripts. However, alarm correlation and noise reduction in this mode usually rely on fixed rules. When facing alarm storms, there are many duplicate alarms and the correlation analysis capability is weak, so a lot of manual intervention is still required.

[0005] (3) Work order / GRC rectification management mode: After the enterprise submits the rectification report, the management personnel mainly conduct a formal review of the document content. There is a lack of automatic retesting of the actual security status of the target assets, network environment, configuration status, etc., making it difficult to identify the situation where "the content of the rectification report is inconsistent with the actual situation".

[0006] (4) AI-assisted analysis mode: Although existing solutions can generate analysis suggestions or report texts with the help of large language models or intelligent analysis tools, they mostly remain at the level of assisting writing and have not yet formed a complete technical closed loop from alarm aggregation, automatic notification, manual verification, rectification and issuance, dual-track verification to automatic rejection iteration.

[0007] In summary, existing technologies suffer from at least the following technical problems: ① severe alarm redundancy; ② delayed notification generation; ③ formalistic rectification and acceptance; ④ incomplete closed-loop processing; and ⑤ lack of human-machine collaboration mechanisms. Therefore, this invention urgently needs to design an industrial safety incident handling method that can achieve efficient automated processing, retain manual confirmation interfaces at key nodes, and simultaneously verify rectification results using both document-based and real-state-based verification. Summary of the Invention

[0008] The purpose of this invention is to overcome the above-mentioned shortcomings of the prior art and provide a dual-track verification method and system for automatic notification and rectification of industrial safety incidents. This system enables intelligent aggregation and noise reduction of multi-source alarms, automatic generation of structured safety notifications, and parallel execution of document compliance review and real safety status retest after the introduction of a manual verification and confirmation mechanism. It automatically determines whether the notification is approved or rejected, drives multiple rounds of rectification until the loop is closed, and ultimately achieves minute-level automated emergency response to industrial safety incidents.

[0009] The technical solution of this invention is:

[0010] The present invention provides a dual-track verification method for automatic reporting and rectification of industrial safety incidents, comprising the following steps:

[0011] S1: Collect multi-source security alarm information, normalize the alarm information, and obtain a unified alarm record;

[0012] S2: Invoke the security handling agent to aggregate and reduce noise in the unified alarm record and generate a unique security event object;

[0013] S3: Automatically generate a structured security notification based on the security event object;

[0014] S4: At a preset key node before the structured security notification is issued, in response to the received manual verification and confirmation instruction, the structured security notification is issued to the responsible unit, and a rectification task is created;

[0015] S5: Receive the rectification report submitted by the responsible unit, and generate a rectification report object based on the rectification report;

[0016] S6: In response to the generation of the rectification report object output in step S5, track A verification is initiated to conduct a document compliance review on the rectification report object; at the same time, according to the target object involved in the structured security notification output in step S3, track B verification is initiated to automatically retest the actual security status of the target object; track A and track B are executed in parallel, and the document track verification result and the actual status track verification result are output respectively.

[0017] S7: Perform a fusion comparison analysis on the document track verification result and the actual state track verification result to generate a verification conclusion object;

[0018] S8: Execute closed-loop control based on the verification conclusion object: if the verification passes, the event is archived and closed-loop; if the verification fails, a rejection notice is automatically generated and iterative rectification is initiated, returning to step S5, until the verification passes or the preset maximum rectification round is reached.

[0019] Furthermore, the unified alarm record includes at least the alarm identifier, alarm source, occurrence time, associated asset identifier, original severity level, alarm type, alarm content, and evidence citation information.

[0020] Furthermore, step S2 specifically includes:

[0021] S21: The unified alarm records are preprocessed using a rule engine to output a set of candidate alarm groups;

[0022] S22: Use a large language model to perform semantic association on the candidate alarm group set, and output a semantically associated alarm group set;

[0023] S23: Use a machine learning model to score the confidence level of the semantic association alarm group set and output a high-confidence event candidate list;

[0024] S24: Perform noise reduction processing on the high-confidence event candidate list to generate a security event object.

[0025] Furthermore, step S2 further includes:

[0026] S21: Map the unified alarm record to a standard field, group them according to at least three-level grouping keys within a preset time window, merge alarm records with the same grouping key into the same candidate alarm group; compare each group of alarms with the asset database to supplement asset attribute information, remove alarms that match the preset whitelist or alarms that meet the false alarm conditions, and output a set of candidate alarm groups.

[0027] S22: For each alarm in each candidate alarm group, the alarm content is encoded into a vector using a large language model and the cosine similarity is calculated. When the similarity is not less than a preset threshold, the two alarms are determined to be semantically related. For different candidate alarm groups, if the asset identifier is the same or there is an asset dependency relationship and the semantic similarity is not less than a preset threshold, they are merged. The large language model outputs a set of semantically related alarm groups and the preliminary event type of each group.

[0028] S23: Extract feature vectors for each alarm group in the semantic association alarm group set, calculate confidence scores using a machine learning model, determine semantic association alarm groups with confidence scores not less than a preset threshold as high-confidence event candidates, otherwise suppress them, and output a list of high-confidence event candidates.

[0029] S24: The overall severity level is the highest level of the original severity level in the group. If the number of alarms with the highest severity level is not less than two, it is increased by one level and the upper limit is the highest level. The alarms in each group are sorted in ascending order by timestamp and deduplicated. The evidence reference information is merged into all evidence. The union of the asset identifiers involved in the alarms in each group is used as the list of affected assets. The security event object is output.

[0030] Further, in step S3, the method for generating the structured security notification includes: determining the rectification completion deadline based on the severity level of the security event object; selecting a corresponding preset notification template based on the preliminary event type in the security event object; filling the fields in the security event object into the placeholders of the selected template; retrieving supplementary information from the knowledge base according to the event type and severity level and filling it into the corresponding placeholders; generating a problem description explanatory text using a large language model; and marking the output structured security notification status as pending verification.

[0031] The structured security notification includes at least the following fields: event overview, scope of impact, problem description and evidence summary, rectification requirements, rectification report submission requirements, and relevant standards or regulations. The event overview includes the event type, severity level, and discovery time. The scope of impact includes information on related assets, production lines, or business systems. The rectification requirements include rectification measures and rectification completion deadlines.

[0032] Furthermore, step S6 specifically includes:

[0033] Track A Verification: Conduct a document compliance review on the rectification report object and output the document track verification result. The document track verification result includes at least a document compliance score, a document issue list, and a document track judgment result; wherein, the document compliance score is obtained by the following formula:

[0034]

[0035] In the formula, n is the total number of items to be reviewed. For the first The weighting coefficients for each review item, with each review item having a maximum score of 100 points; For the first The score for each review item;

[0036] Track B Verification: Based on the rectification requirements and related assets in the structured security notification, a retest task list is automatically generated. For each item in the retest task list, the corresponding retesting method is executed, and the real state track verification result is output. The real state track verification result includes at least the real state verification score, the list of unrepaired items, the real state track judgment result, and the retest evidence list.

[0037] Track A and Track B execute in parallel and independently.

[0038] Furthermore, in the Track B verification, each item in the retest task list includes at least a retest item identifier, a retest item type, a target asset, a retest method, and a severity level; the retest method includes at least one of vulnerability rescanning, port probing, configuration baseline verification, security policy verification, probe data collection, asset fingerprinting, and log backtracking analysis; the single-item judgment rule is: when the execution result of the retest method shows that the corresponding security vulnerability has been eliminated, the retest item is judged to pass; otherwise, it is judged to fail.

[0039] Furthermore, the real-state verification score is obtained using the following formula:

[0040]

[0041] In the formula, m is the total number of repeated test items. For the first The severity level weight of each retest item;

[0042] When the When the verification result of the retest item is pass, =1; otherwise =0; when If ≥60 and all retest items with severity level of high risk or above pass, the real state track verification is deemed successful; otherwise, the real state track verification is deemed unsuccessful.

[0043] Further, in step S7, the document track verification result and the actual state track verification result are fused and compared, including:

[0044] If the document track determination result is negative or the real state track determination result is negative, the initial determination is that it fails; if both are positive, the consistency check is initiated.

[0045] The list of claimed repaired items in the rectification report is matched with the retest results in the real state track verification results to calculate a consistency score; the consistency score is obtained using the following formula:

[0046]

[0047] In the formula, This indicates the number of successfully matched and repaired items. This indicates the total number of items claimed to have been repaired in the rectification report;

[0048] Perform a fusion scoring process, which involves weighting and fusing the document compliance score, the real-state verification score, and the consistency score to obtain a fusion verification score.

[0049] The final judgment rules are as follows: when the document compliance score or real-state verification score is less than 60, it is directly judged as failing; when the consistency score is less than 70, it is judged as inconsistent; if there are unmatched items with a severity level greater than or equal to high risk, it is directly judged as failing; when the fusion verification score is greater than or equal to 80 and all the above conditions are met, it is judged as passing.

[0050] The verification conclusion object is generated based on the fusion verification score and the final judgment rule.

[0051] Further, in step S8, the closed-loop control includes:

[0052] If the final judgment result in the verification conclusion object is "pass", then the event status is updated to "closed loop", the full-link record is archived, and the situational awareness indicators are updated.

[0053] If the final judgment result in the verification conclusion object is "not passed", a rejection notice will be automatically generated and sent to the responsible unit to initiate the next round of rectification.

[0054] The maximum number of rectification rounds is preset. The first N-1 rounds are automatically rejected by the system to drive rectification. If the Nth round still fails, the process will be upgraded to manual intervention.

[0055] When a rectification task is completed but a rectification report is not submitted within the time limit, the system will automatically send a reminder notice, and the supervision will be upgraded after the time limit expires.

[0056] The present invention provides an automatic reporting and rectification dual-track verification system for industrial safety incidents, comprising:

[0057] The alarm access module is used to collect multi-source security alarm information and perform normalization processing to obtain a unified alarm record.

[0058] The intelligent agent aggregation and noise reduction module is used to aggregate and reduce noise from the unified alarm records to generate a unique security event object.

[0059] The notification generation module is used to generate structured security notifications based on the security event object;

[0060] The human-machine collaborative control module is used to receive manual verification and confirmation instructions at preset key nodes before the structured security notification is issued, issue the structured security notification to the responsible unit, and create rectification tasks;

[0061] The rectification management module is used to receive rectification reports submitted by the responsible unit and generate rectification report objects;

[0062] The document track verification module is used to initiate track A verification based on the rectification report object, perform document compliance review on the rectification report object, and output the document track verification result;

[0063] The real state track verification module is used to initiate track B verification based on the target object involved in the structured security notification, automatically retest the real security status of the target object, and output the real state track verification result.

[0064] The dual-track fusion judgment module is used to perform fusion comparison and analysis on the document track verification result and the real state track verification result to generate a verification conclusion object.

[0065] The closed-loop control module is used to perform closed-loop control based on the verification conclusion object. If the verification is passed, the closed loop is archived. If the verification fails, a rejection notice is automatically generated and the next round of rectification is started until the verification is passed or the preset maximum number of rectification rounds is reached.

[0066] The situational awareness linkage module is used to update the situational awareness platform metrics based on the event information during the event archiving closed loop.

[0067] The beneficial effects of this invention are:

[0068] (1) Effectively reduce alarm redundancy: Through the three-layer processing flow of time window aggregation and grouping of rule engine, semantic association of large language model and confidence score of machine learning model, the alarms are effectively merged and noise is reduced, and the original large number of alarms are compressed into a controllable number of security events. This can effectively avoid security analysts being disturbed by invalid information when facing a large number of alarms, and significantly improve the efficiency of alarm handling.

[0069] (2) Significantly improves notification efficiency: Through the automatic generation mechanism of structured notifications, there is no need to manually write the notification content one by one, which can significantly shorten the time window from alarm discovery to notification issuance, and save time for rapid response.

[0070] (3) Improve the reliability of rectification and acceptance: Through parallel document review and actual status retesting, as well as the fusion comparison mechanism, the compliance of the rectification report and the actual elimination of hidden dangers can be verified at the same time. This overcomes the shortcomings of the traditional model, which only conducts formal review of the report, effectively avoids the safety risk of "inconsistency between the report and the actual situation", and significantly improves the reliability and objectivity of rectification and acceptance.

[0071] (4) Achieve true closed-loop handling: By automatically rejecting and driving multiple rounds of iterative rectification when verification fails, combined with the maximum round control and time limit urging upgrade strategy, we ensure that every safety incident goes through a complete handling process until the hidden danger is truly eliminated before it can be archived. This overcomes the drawback of the traditional model where rectification is completed in one go, and achieves a true closed loop from alarm discovery to hidden danger elimination.

[0072] (5) Balancing efficiency and controllability: By setting up a manual verification and confirmation node before the notification is issued, the high efficiency of automated processing and the manual control of key decision points can be balanced. This avoids the problem of slow response in the fully manual mode and the risk of incorrect issuance due to misjudgment in the fully automated mode, thus achieving an effective balance between efficiency and controllability.

[0073] (6) Supports minute-level emergency response: The total time for alarm aggregation analysis in this invention is less than 1 minute, and the total time for the entire process is less than 5 minutes. With the help of one-click issuance, automatic rejection and follow-up supervision mechanisms, it can achieve minute-level automated emergency response when a sudden security incident occurs, significantly shortening the entire process handling time of the security incident.

[0074] (7) Full-process traceability: When the verification is passed, the entire process record is archived, and the step-by-step transmission between each step is based on standardized data structure (alarm record, security event object, structured security notification, rectification report object, document track verification result, real state track verification result, verification conclusion object, etc.). This ensures that every link from the original alarm collection to the final closed-loop handling is stored in the form of structured electronic data. All operations are traceable and auditable, which facilitates post-event review and responsibility identification. This significantly improves the standardization and compliance of industrial security operations, and is particularly suitable for scenarios such as industrial Internet situational awareness platforms and industrial security operation centers (ISOC). Attached Figure Description

[0075] Figure 1 This is a schematic diagram of the overall process of the method according to an embodiment of the present invention;

[0076] Figure 2 This is a block diagram of the system composition according to an embodiment of the present invention. Detailed Implementation

[0077] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0078] like Figure 1 As shown: A dual-track verification method for automatic reporting and rectification of industrial safety incidents, comprising the following steps:

[0079] S1: Collect multi-source security alarm information, normalize the alarm information, and obtain a unified alarm record.

[0080] Specifically, raw security alert information is collected from one or more of the following sources: Industrial Internet Situation Awareness Platform, Firewall / IDS / WAF, Industrial Control System Security Audit System, Industrial Protocol Probe; Vulnerability Scanner, Configuration Baseline Verification System; Host / Terminal Security Agent.

[0081] The raw security alarm information collected from various sources is normalized and converted into a unified alarm record structure. The unified alarm record includes at least the following fields: alarm identifier, alarm source, occurrence time, associated asset identifier, original severity level, alarm type, alarm content, and evidence citation information.

[0082] Understandably, since normalization is a mature technology, it will not be elaborated on here.

[0083] S2: Invoke the security handling agent to aggregate and reduce noise in the unified alarm records and generate a unique security event object.

[0084] In this embodiment, the security handling agent adopts a hybrid implementation combining a rule engine, a large language model, and a machine learning model. These three modules are executed sequentially within the same processing flow. The overall data flow is: normalized alarm records → rule engine preprocessing → candidate alarm groups → large language model semantic association → semantically associated alarm groups → machine learning confidence scoring → high-confidence event candidates → security event objects. Specifically, it includes the following steps:

[0085] S21: Obtain the normalized alarm records obtained in step S1, preprocess the alarm records using a rule engine, and output a candidate alarm group set. Specifically:

[0086] First, standard field mapping is performed, mapping each data item in the alarm record to standard fields required by the rule engine. These standard fields are preferably represented by English identifiers and correspond one-to-one with the fields in the unified alarm record structure described in step S1: for example, `alert_id` corresponds to the alarm identifier, `source` to the alarm source, `timestamp` to the occurrence time, `asset_id` to the associated asset identifier, `severity_raw` to the original severity level, `alert_type` to the alarm type, `content` to the alarm content, and `evidence_ref` to the evidence citation information. Specifically, `asset_id` is matched against the asset database based on IP, MAC, or device name; if a match fails, it is marked as `unknown`. `severity_raw` includes five levels: critical, high-risk, medium-risk, low-risk, and informational. `alert_type` is mapped to a pre-defined dictionary, which includes at least vulnerabilities, intrusions, unauthorized ports, weak passwords, and protocol anomalies. `content` includes the alarm title and description. `evidence_ref` includes log fragments or PCAP summaries.

[0087] Then, time window aggregation and grouping are performed. Since the alarm records output in step S1 are independent, unorganized discrete data streams, processing them directly one by one would be inefficient, as it would be impossible to identify whether multiple alarms point to the same security event. Therefore, this embodiment requires logical merging within a preset time window T using a three-level grouping key. Alarms with the same asset identifier, alarm type, and source and destination IP combinations are grouped into the same candidate alarm group, laying the data foundation for subsequent semantic association and confidence scoring. The source and destination IP addresses are extracted by the rule engine from the content or evidence_ref field.

[0088] The time window T is 10 minutes, but can be adjusted from 5 to 15 minutes depending on the actual scenario. The first-level grouping key is the associated asset identifier (asset_id), the second-level grouping key is the alarm type (alert_type), and the third-level grouping key is the combination of the source IP and the destination IP. Specifically, alarms are first grouped according to the first-level grouping key. If multiple alarms of different alarm types (alert_type) exist within the same group, they are further split into several subgroups according to the second-level grouping key. If they still cannot be distinguished, they are further subdivided according to the third-level grouping key. This grouping is merely a logical merging of alarms based on the grouping key. Each alarm record within each candidate alarm group formed after merging still carries all the original fields from the unified alarm record structure defined in step S1. The grouping operation does not lose any field information. Subsequent steps such as asset association, false alarm filtering, and semantic association using a large language model are all performed on a group-by-group basis. The judgment criteria within each group are derived from the complete field information carried by each alarm record within the group.

[0089] Next, asset association is performed. After time window aggregation and grouping, alarms within each group have been initially merged according to asset identifiers. However, asset identifiers are only device numbers or IP addresses, lacking business-dimensional contextual information (such as which production line or workstation the device belongs to). This information is crucial for assessing the scope of event impact and determining handling priorities. Therefore, each group of alarms needs to be compared with the asset database to supplement the alarms with production line and workstation information, forming candidate alarm groups G carrying richer contextual information. Each group carries a group_id, an alarm list, a list of associated assets, and time span information.

[0090] Finally, false alarm filtering is performed. After asset association is completed, alarms within each group have complete asset context information. At this point, quality screening is required to remove alarms that obviously do not require action, in order to avoid the subsequent processing of invalid data by the large language model and machine learning module, thereby improving overall processing efficiency. Specifically, alarms that meet any of the following conditions are removed: alarms that hit the maintenance window whitelist (i.e., alarms generated during the planned maintenance period), alarms that hit the process fluctuation whitelist (i.e., alarms triggered by normal process fluctuations), alarms with severity_raw as "information" and no associated high-risk or medium-risk alarms (i.e., low-priority and isolated information alarms), and alarms with duplicate alert_ids within the time window (i.e., the same alarm is reported repeatedly).

[0091] After the above processing, the candidate alarm group set G={G1,G2,…,G} is output.

[0092] S22: Obtain the candidate alarm group set output in step S21, use a large language model to perform semantic association on the candidate alarm group set, and output a semantically associated alarm group set.

[0093] Specifically, while time window aggregation and grouping can group alarms with the same asset identifier, alarm type, and source IP and destination IP combination into the same candidate alarm group, it is still necessary to further determine whether multiple alarms within the same candidate alarm group semantically point to the same security event. Furthermore, if different candidate alarm groups involve the same asset or have asset dependencies, the alarms they contain may also be semantically related, requiring identification and merging. Therefore, this embodiment requires the use of a large language model to perform semantic-level correlation analysis on the candidate alarm group set.

[0094] Specifically, for each alarm within a candidate alarm group, the text of its alarm content (content field) is obtained, and a pre-trained language model is used to encode the content text of each alarm into a vector. For any two alarms a and b within the same candidate alarm group, the cosine similarity is calculated, and the similarity function is:

[0095]

[0096] In the formula, and These are the vectors output by the pre-trained language model after encoding the alarm content text of alarm a and alarm b, respectively. A preset similarity threshold is used: when sim ≥ 0.85, the content texts of the two alarms are considered semantically related and belong to the same event description; when sim < 0.85, the two alarms are considered semantically unrelated.

[0097] Regarding cross-group association, if different candidate alarm groups have the same asset identifier (asset_id) or have an asset dependency relationship, and the semantic similarity of alarms in the two groups is ≥0.85, the relevant candidate alarm groups will be merged, so that alarms that are scattered in different groups but actually point to the same security event can be aggregated.

[0098] After the semantic association and merging process described above, multiple related alarms have been aggregated in each group. At this time, the large language model matches and outputs the event type from the preset dictionary mentioned in step S21 based on the alarm content and semantic features of each alarm in each group, as the preliminary event type of the alarm group.

[0099] It should be noted that in this step, the large language model is only responsible for semantic association judgment and preliminary determination of event type. It does not involve the generation of notification text or the parsing of rectification report, so as to avoid the large language model generating the notification content to be released to the public before manual verification and confirmation, and to ensure the final review right of the manual verification node for the notification content.

[0100] After the above processing, the semantic association alarm group set G' and the preliminary event types of each group are output.

[0101] S23: Obtain the semantically related alarm group set output in step S22, use a machine learning model to score the confidence of the semantically related alarm group set G', and output a list of high-confidence security event candidate objects.

[0102] Specifically, after time window aggregation and grouping in step S21 and semantic association processing using the large language model in step S22, alarms within each group have been merged and aggregated at the grouping key and semantic levels. However, the semantically associated alarm groups formed after the above processing still differ in importance: some groups have a large number of alarms, high severity levels, and involve core industrial control assets, making them more likely to constitute real security events; while other groups may have fewer alarms, lower severity levels, or involve non-core assets, making them less likely to constitute real security events. Therefore, it is necessary to use a machine learning model to perform confidence quantification scoring on each semantically associated alarm group to distinguish between high-confidence events and low-confidence events, thereby achieving further noise reduction in alarms.

[0103] Specifically, a feature vector X=[x1, x2, x3, x4, x5] is extracted for each group of alarms. The dimensions of each feature are defined as follows: x1 is the number of alarms in the group; x2 is the highest severity level in the group, where critical = 4, high risk = 3, medium risk = 2, low risk = 1, and information = 0; x3 is the time span in the group, that is, the time difference between the latest alarm and the earliest alarm in the group; x4 is the asset criticality weight, where core industrial control assets = 1.0, general assets = 0.6, and unknown assets = 0.3; x5 is the mean semantic similarity in the group, that is, the average cosine similarity between all pairs of alarms in the group.

[0104] The confidence score is calculated using a logistic regression model, and the formula is as follows:

[0105]

[0106] Where w is the weight vector, X is the feature vector extracted from each alarm group, and b is the bias term. When confidence ≥ 0.75, it is determined as a high-confidence event candidate and enters the event generation process; when confidence < 0.75, it is suppressed.

[0107] After the above processing, a list of high-confidence security event candidates is output. Each candidate event in the list carries all alarm information, confidence score and feature vector of its corresponding group.

[0108] S24: Obtain the list of high-confidence security event candidates, perform noise reduction processing on them, and generate security event objects.

[0109] Specifically, the overall severity level is the highest level of severity_raw within the group. If the number of alarms with the highest level is ≥2, the severity level is increased by one level, but the upper limit does not exceed the "critical" level. The aggregated alarm list is sorted in ascending order by the timestamp field and deduplicated. The evidence chain merges all evidence_refs. The list of affected assets is the union of asset_ids. The final output is a Security Event Object (SIO), which includes at least the following fields: incident_id (unique event identifier), aggregated_alerts[] (aggregated alarm list), incident_type (event type, i.e., the preliminary event type output by the large language model in S22), severity, affected_assets[] (list of affected assets), impact_scope (scope of impact), root_evidence (core evidence summary), confidence (confidence level), status (event status), and created_at (creation time).

[0110] In this embodiment, the total time taken for the processing flow of the rule engine, large language model and machine learning model to complete alarm aggregation analysis and review is less than 1 minute.

[0111] S3: Automatically generate structured security notifications based on the security event object.

[0112] Specifically, firstly, the severity level of the notification is determined based on the severity field in the security incident object. The mapping relationship between the notification severity level and the rectification completion deadline is shown in Table 1:

[0113] Table 1. Mapping Relationship between Severity Level of Notification and Rectification Completion Deadline

[0114]

[0115] Then, the notification generation is performed, which includes four parts: template selection, field auto-fill, knowledge base retrieval enhancement, and large language model generation of explanatory content.

[0116] Regarding template selection: A pre-set notification template is selected based on the `incident_type` in the security event object. For example, template TPL-001 is selected when `incident_type` is "illegal port exposure," and template TPL-002 is selected when `incident_type` is "weak password." The pre-set notification template contains several placeholders.

[0117] Regarding automatic field filling: the fields in the security event object are filled into the placeholders of the selected template. For example, the severity level and event type are combined and filled into the title placeholder, and the rectification completion deadline is determined by looking up Table 1 and filled into the deadline placeholder.

[0118] Enhanced knowledge base retrieval: Based on event type and severity level, retrieve relevant security standards, regulations, or best practices from the knowledge base and populate the standard reference placeholders with the search results.

[0119] Regarding the generation of explanatory content using the large language model: In step S3, the large language model is only used to generate explanatory text such as problem descriptions, without changing structured fields such as the severity level of the notification and the deadline for rectification completion.

[0120] After the above processing, a structured security notification is output. This notification includes at least the following fields: event overview (including event type, severity level, and discovery time), scope of impact (including information on related assets, production lines, or business systems), problem description and evidence summary, rectification requirements (including specific rectification measures and completion deadlines), rectification report submission requirements, and relevant standards or regulations. The generated structured security notification is marked as "Pending Verification" and must be manually verified and confirmed in subsequent step S4 before it can be issued.

[0121] For example: Input SIO: incident_type=illegal port exposure, severity=high risk, affected_assets=[PLC-host-192.168.10.5], impact_scope=Production Line A / Welding Station. The mapped output is: title=

High Risk

[0122] S4: At a preset key node before the structured security notification is issued, in response to the received manual verification and confirmation instruction, the structured security notification is issued to the responsible unit, and a rectification task is created.

[0123] Specifically, at key pre-set points before the notification is issued, the system pushes the structured security notification to the technical personnel review interface, where technical personnel review the incident's nature, scope of impact, and rectification requirements. The system prohibits automatic issuance until manual confirmation is obtained. Once confirmed, the notification is issued to the responsible unit with one click, simultaneously creating a rectification task, recording the issuance time, responsible person, and rectification deadline, and updating the incident status from "Pending Verification" to "In Progress."

[0124] S5: Receive the rectification report submitted by the responsible unit, and generate a rectification report object based on the rectification report.

[0125] Specifically, the rectification report should at least include a description of the rectification measures, the rectification completion time, the person responsible for the rectification, and supporting documentation. After receiving the rectification report, the system encapsulates it into a rectification report object. This object should include at least the following fields: report_id (rectification report identifier), associated incident_id (associated event identifier), claimed_fixed_items[] (list of claimed fixed items), attachments[] (list of attachments), and submit_time (submission time). Each item in claimed_fixed_items[] should include at least item_id (fixed item identifier), item_type (fixed item type), target_asset (target asset), claimed_action (rectification measures taken), and severity (severity level). After encapsulation, the event status is updated to "pending verification".

[0126] S6: In response to the generation of the rectification report object output in step S5, track A verification is initiated to conduct a document compliance review of the rectification report object; at the same time, according to the target object involved in the structured security notification output in step S3, track B verification is initiated to automatically retest the actual security status of the target object; track A and track B are executed in parallel, and the document track verification result and the actual status track verification result are output respectively.

[0127] Specifically, the two verification paths, Track A and Track B, are independent of each other and are carried out simultaneously, respectively verifying the document compliance of the rectification report object and the actual security status of the target object.

[0128] Track A - Rectification Report Document Track Verification:

[0129] The input to this path is the rectification report object, used to verify the compliance and completeness of the rectification report itself, and does not involve the detection of the actual state of the target assets. First, automatic parsing is performed on the rectification report object: the structured form fields in the rectification report object are extracted using Schema parsing, the uploaded attachments (such as screenshots, PDFs, etc.) are extracted using OCR text extraction, and the rectification description in natural language form is extracted using a large language model to extract information, extracting the claimed_fixed_items[] list of items claimed to have been fixed in the rectification report object, and cross-validating it with the form fields to identify any inconsistencies or contradictions between the two.

[0130] Next, a compliance review and scoring are conducted. The formula for calculating the document compliance score is as follows:

[0131]

[0132] Where n is the total number of items to be reviewed. For the first The weighting coefficients for each review item, with each review item having a maximum score of 100 points; For the first The score for each review item.

[0133] The compliance review and scoring rules are shown in Table 2:

[0134] Table 2 Compliance Review and Scoring Rules

[0135]

[0136] When score_doc ≥ 60 and the scores of each review item reach the preset compliance threshold, the document track verification is deemed passed (doc_pass = Yes); otherwise, the document track verification is deemed failed (doc_pass = No). The document track verification result is output, which includes at least the document compliance score_doc, the document issue list doc_issues[], and the document track judgment result doc_pass, that is: output document track verification result D_result = {score_doc, doc_issues[], doc_pass}.

[0137] Track B -- Real-world track verification:

[0138] The input to this path is the structured security bulletin output by S3, used to proactively retest the actual security status of the target objects involved in the bulletin, in order to verify whether the rectification measures have effectively eliminated security risks. Based on the rectification requirements `rectification_req` and security event-related assets in the structured security bulletin, a retest task list `retest_items[]` is automatically generated. Each item in the retest task list includes at least the following structure: `{item_id, item_type, target_asset, check_method, severity}`. Here, `check_method` represents the retesting method, which includes at least one or more of the following: vulnerability rescanning, port probing, configuration baseline verification, security policy verification, probe data collection, asset fingerprinting, and log backtracking analysis. Specifically, the process involves: rescanning vulnerabilities to verify if they still exist; port probing to verify if unauthorized ports are still open; configuration baseline verification to verify if the configuration has been restored or hardened to a compliant state; security policy verification to verify if firewall, ACL, and other policies are effective; probe data collection to verify if industrial protocol anomalies have been eliminated; asset fingerprinting to verify if unauthorized components or software still exist; and log backtracking analysis to verify if abnormal behavior has stopped.

[0139] For each item in the retest task list `retest_items[]`, execute the corresponding retest method `check_method` to generate a retest result list `retest_results[]`. `retest_results[]` and `retest_items[]` correspond one-to-one through `item_id`, and each item has the structure `{item_id, item_type, target_asset, check_method, severity, verify_result, evidence_ref}`. Output the verification result `verify_result` ∈ {pass, fail} for each item and record the evidence citation information `evidence_ref`. The single-item judgment rule is: when the execution result of the retest method indicates that the corresponding security vulnerability has been eliminated, the retest item `verify_result` is judged as pass; otherwise, it is judged as fail.

[0140] The formula for calculating the real-state verification score is:

[0141]

[0142] Where m is the total number of retested items, For the first The severity level weights for each retest item are as follows: Critical = 4, High Risk = 3, Medium Risk = 2, Low Risk = 1; when the... When the verification result `verify_result` of the retest item is "pass", =1; when verify_result is fail =0.

[0143] The criteria for track B are as follows: when score_real ≥ 60 and all retest items with a severity level of "high risk" or above are passed, the real state track verification is considered successful (real_pass = yes); otherwise, the real state track verification is considered unsuccessful (real_pass = no). The real state track verification result, R_result, is output. This result includes at least the real state verification score score_real, the list of unfixed items unfixed_items[], the real state track determination result real_pass, and the retest evidence list retest_evidence[], i.e.: R_result = {score_real, unfixed_items[], real_pass, retest_results[], retest_evidence[]}. Here, retest_results[] is the list of retest results generated after performing retests on each item in retest_items[].

[0144] S7: Perform a fusion comparison analysis on the document track verification result and the actual state track verification result to generate a verification conclusion object.

[0145] Specifically, the inputs to this step are the document track verification result and the real state track verification result output by S6.

[0146] First, a basic judgment is performed: if doc_pass in the document track verification result is negative, or real_pass in the real state track verification result is negative, then it is initially judged as failing; if both are positive, then the consistency check is performed.

[0147] During consistency verification, the list of claimed fixed items[] in the rectification report object is matched one-to-one with the list of retest results[] in the actual state track verification result R_result. Specifically, the structure of the claimed fixed items[] on the reporting side is: {item_id, item_type, target_asset, claimed_action, severity}; the structure of the retest results[] on the retest side is: {item_id, item_type, target_asset, check_method, severity, verify_result, evidence_ref}. The retest_results[] is the result list generated after performing the retest item by item according to the retest task list retest_items[] in step S6 track B verification; retest_items[] is the retest task input list, and retest_results[] is the retest execution output result list. The two correspond one-to-one through item_id. retest_results[] adds verify_result and evidence_ref fields to the retest_items[] field.

[0148] The matching rules are as follows: Precise matching is prioritized based on `item_id`; for items without a `item_id`, fuzzy matching is performed based on the combination of `target_asset` and `item_type`. When an item in `claimed_fixed_items[]` (denoted as `claimed_item`) successfully matches an item in `retest_results[]` (denoted as `retest_result_item`), and the corresponding `retest_result_item` has `verify_result=pass`, then `claimed_item` is added to the set of successfully matched and fixed items `matched_fixed_items`, indicating that the item has passed the retest verification of the real state track. The consistency score calculation formula is:

[0149]

[0150] in, This indicates the number of successfully matched and repaired items. This indicates the total number of items claimed to have been repaired in the rectification report.

[0151] The inconsistency judgment rules are as follows: If there is a claimed_item in claimed_fixed_items[] that is not included in matched_fixed_items and its severity is greater than or equal to medium risk, it is marked as "inconsistent between the report and the actual status"; if there is a retest result item in retest_results[] that verify_result=fail and its severity is greater than or equal to medium risk, and the item_id, item_type and target_asset combination of this item does not appear in claimed_fixed_items[], it is marked as "incomplete rectification", and the unrepaired assets, hidden danger type, severity level and evidence_ref are recorded.

[0152] Then, a fusion scoring process is performed, weighting and fusing the results from the three dimensions: document compliance score (score_doc), real-state verification score (score_real), and consistency score (score_consistency). This fusion verification score serves as the final quantitative basis for the judgment. The fusion score calculation formula is as follows:

[0153]

[0154] Among them, α=0.25, β=0.50, γ=0.25.

[0155] For unmatched items with a severity level ≥ high risk, a weighting factor of 1.5 is added when the item fails the judgment to increase the penalty weight. The final judgment rule is as follows: when score_doc or score_real is less than 60, it is directly judged as failing; when consistency_score is less than 70, it is judged as inconsistent; when verify_score is greater than or equal to 80 and all the above conditions are met, it is judged as passing. The output verification conclusion object VCO is generated. The verification conclusion object includes at least the final judgment result (final_result), the fusion verification score (verify_score), the rejection type (reject_type), the rejection reason (reject_reason), the unfixed list (unfixed_list), the suggestions for improvement (suggestions), and the evidence chain (evidence_chain), that is: VCO={final_result, verify_score, reject_type, reject_reason, unfixed_list, suggestions, evidence_chain}.

[0156] S8: Perform closed-loop control based on the verification conclusion object: if the verification passes, the event is archived and closed-loop; if the verification fails, a rejection notice is automatically generated and the next round of rectification is started, returning to step S5, until the verification passes or the preset maximum number of rectification rounds is reached.

[0157] Specifically, if the final judgment result in the verification conclusion object is "passed", the current event status will be updated to "closed loop", the entire process record from alarm collection to verification pass will be archived, and the situational awareness indicators will be updated to complete the event closure.

[0158] If the final judgment result in the verification conclusion object is "not passed", a rejection notice will be automatically generated. The rejection notice will include at least the rejection type (reject_type), the rejection reason (reject_reason), the unfixed list (unfixed_list), rectification suggestions (matching a preset template according to the rejection_type), the new round deadline, and the current round number N. The rejection notice will then be sent to the responsible unit to initiate the next round of rectification. The rejection types (reject_type) are distinguished as shown in Table 3.

[0159] Table 3. Distinguishing between rejection types (reject_type)

[0160]

[0161] Regarding iterative control, a maximum number of rectification rounds N is preset. max =3. When the rectification round is in round 1 or 2, the system will automatically reject the application and drive the responsible unit to continue rectification. When the rectification round reaches round 3 and the verification still fails, the incident will be escalated to manual intervention. Regarding time limit management, if a rectification report is not submitted within 24 hours of the deadline, the system will automatically send a reminder notice; if it is still not submitted within 48 hours, the system will automatically escalate the supervision. The sending of rejection notices, time limit reminders, and supervision are all executed automatically by the system without manual intervention.

[0162] In this embodiment, the total time from alarm acquisition to closed-loop handling of a single industrial safety incident is less than 5 minutes, with the total time for the safety handling agent to complete alarm aggregation analysis and verification in step S2 being less than 1 minute. Through the above-mentioned automated rejection and iterative rectification mechanism, a minute-level automated emergency response closed loop for industrial safety incidents is achieved.

[0163] The following are three specific embodiments of the present invention:

[0164] Example 1: Illegal Port Exposure Incident in Industrial Control Network

[0165] In this embodiment, the situational awareness platform collected 6 alarms. After serial processing by the security handling agent in step S2, the 6 alarms were aggregated into one high-risk security event, with AI processing taking 40 seconds. Step S3 generated a structured security report titled "[High-Risk] Illegal Port Exposure Security Incident Notification," which was then issued after verification and confirmation by the engineer in step S4. After the responsible unit submitted a rectification report, step S6 performed dual-track verification. The first round of verification results were: score_doc=90, score_real=30, consistency_score=40; rejection_type=REPORT_REALITY_MISMATCH, indicating automatic rejection; and the second round of rectification was initiated. After the second round of rectification was completed and the retest passed, the event archiving was closed, and the total process time was 4 minutes and 30 seconds.

[0166] Example 2: Weak Password Rectification Incident

[0167] In this embodiment, the vulnerability scanner reports 5 weak password alerts. After serial processing by the security handling agent in step S2, the 5 alerts are aggregated into 1 security event, with AI processing taking 35 seconds. Step S3 generates a structured security notification titled "[Medium Risk] Weak Password Security Event Notification" according to the severity level mapping rules, which is then issued after verification and confirmation by the engineer in step S4. After the responsible unit submits a rectification report, step S6 performs dual-track verification. Step S7 merges and compares the results, which are score_doc=92, score_real=95, consistency_score=100, and verify_score=93, indicating a one-time pass. Step S8 archives the event to close the loop, with the entire process taking 3 minutes.

[0168] Example 3: Multiple rejections until closed-loop event

[0169] In this embodiment, the security alarm involves a workstation failing to uninstall unauthorized software. After steps S2 to S4 complete the notification generation and distribution, and the responsible unit submits a rectification report, step S6 performs dual-track verification. The first round of verification results in score_doc=88, but the real status track verification fails (real_pass=no), rejection_type=REPORT_REALITY_MISMATCH, automatically rejecting the second round of rectification. After the second round of rectification is completed, both the document track verification and the real status track verification pass, the event archiving loop is closed, and the total process time is 5 minutes.

[0170] The above three embodiments correspond to typical scenarios of two-round closed-loop for high-risk events, one-round closed-loop for medium-risk events, and multiple rounds of rejection until closed-loop, respectively, verifying that the present invention can achieve minute-level automated closed-loop processing under different types of safety events and different rectification quality conditions.

[0171] like Figure 2 As shown: This embodiment also includes a dual-track verification system for automatic reporting and rectification of industrial safety incidents, comprising:

[0172] The alarm access module is used to collect multi-source security alarm information and perform normalization processing to obtain a unified alarm record.

[0173] The intelligent agent aggregation and noise reduction module is used to aggregate and reduce noise from the unified alarm records to generate a unique security event object.

[0174] The notification generation module is used to generate structured security notifications based on the security event object;

[0175] The human-machine collaborative control module is used to receive manual verification and confirmation instructions at preset key nodes before the structured security notification is issued, issue the structured security notification to the responsible unit, and create rectification tasks;

[0176] The rectification management module is used to receive rectification reports submitted by the responsible unit and generate rectification report objects;

[0177] The document track verification module is used to initiate track A verification based on the rectification report object, perform document compliance review on the rectification report object, and output the document track verification result;

[0178] The real state track verification module is used to initiate track B verification based on the target object involved in the structured security notification, automatically retest the real security status of the target object, and output the real state track verification result.

[0179] The dual-track fusion judgment module is used to perform fusion comparison and analysis on the document track verification result and the real state track verification result to generate a verification conclusion object.

[0180] The closed-loop control module is used to perform closed-loop control based on the verification conclusion object. If the verification is passed, the closed loop is archived. If the verification fails, a rejection notice is automatically generated and iterative rectification is started until the verification is passed or the preset maximum rectification round is reached.

[0181] The situational awareness linkage module is used to update the situational awareness platform metrics based on the event information during the event archiving closed loop.

[0182] In summary, this invention differs from the SOAR platform's fixed-rule architecture by introducing a security handling intelligent agent to achieve intelligent aggregation and noise reduction of alarms, and adopts a dual-track verification mechanism; it differs from the formal review mode of the work order / GRC system by automatically retesting the actual security status and rejecting alarms based on type; and it differs from the limitations of existing AI solutions that only assist in writing reports by leading the entire process from alarm aggregation, notification generation, dual-track verification to rejection iteration, forming a complete automated closed-loop handling system.

Claims

1. A dual-track verification method for automatic reporting and rectification of industrial safety incidents, characterized in that, Includes the following steps: S1: Collect multi-source security alarm information, normalize the alarm information, and obtain a unified alarm record; S2: Invoke the security handling agent to aggregate and reduce noise in the unified alarm record and generate a unique security event object; S3: Automatically generate a structured security notification based on the security event object; S4: At a preset key node before the structured security notification is issued, in response to the received manual verification and confirmation instruction, the structured security notification is issued to the responsible unit, and a rectification task is created; S5: Receive the rectification report submitted by the responsible unit, and generate a rectification report object based on the rectification report; S6: In response to the generation of the rectification report object output in step S5, track A verification is initiated to conduct a document compliance review on the rectification report object; at the same time, according to the target object involved in the structured security notification output in step S3, track B verification is initiated to automatically retest the actual security status of the target object; track A and track B are executed in parallel, and the document track verification result and the actual status track verification result are output respectively. S7: Perform a fusion comparison analysis on the document track verification result and the actual state track verification result to generate a verification conclusion object; S8: Perform closed-loop control based on the verification conclusion object: if the verification passes, the event is archived and closed-loop; if the verification fails, a rejection notice is automatically generated and the next round of rectification is started, returning to step S5, until the verification passes or the preset maximum number of rectification rounds is reached.

2. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 1, characterized in that, The unified alarm record includes at least the alarm identifier, alarm source, occurrence time, associated asset identifier, original severity level, alarm type, alarm content, and evidence citation information.

3. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 2, characterized in that, Step S2 specifically includes: S21: The unified alarm records are preprocessed using a rule engine to output a set of candidate alarm groups; S22: Use a large language model to perform semantic association on the candidate alarm group set, and output a semantically associated alarm group set; S23: Use a machine learning model to score the confidence level of the semantic association alarm group set and output a high-confidence event candidate list; S24: Perform noise reduction processing on the high-confidence event candidate list to generate a security event object.

4. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 3, characterized in that, Step S2 further includes: S21: Map the unified alarm record to a standard field, group them according to at least three-level grouping keys within a preset time window, merge alarm records with the same grouping key into the same candidate alarm group; compare each group of alarms with the asset database to supplement asset attribute information, remove alarms that match the preset whitelist or alarms that meet the false alarm conditions, and output a set of candidate alarm groups. S22: For each alarm in each candidate alarm group, the alarm content is encoded into a vector using a large language model and the cosine similarity is calculated. When the similarity is not less than a preset threshold, the two alarms are determined to be semantically related. For different candidate alarm groups, if the asset identifier is the same or there is an asset dependency relationship and the semantic similarity is not less than a preset threshold, they are merged. The large language model outputs a set of semantically related alarm groups and the preliminary event type of each group. S23: Extract feature vectors for each alarm group in the semantic association alarm group set, calculate confidence scores using a machine learning model, determine semantic association alarm groups with confidence scores not less than a preset threshold as high-confidence event candidates, otherwise suppress them, and output a list of high-confidence event candidates. S24: The overall severity level is the highest level of the original severity level in the group. If the number of alarms with the highest severity level is not less than two, it is increased by one level and the upper limit is the highest level. The alarms in each group are sorted in ascending order by timestamp and deduplicated. The evidence reference information is merged into all evidence. The union of the asset identifiers involved in the alarms in each group is used as the list of affected assets. The security event object is output.

5. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 4, characterized in that, In step S3, the method for generating the structured security notification includes: determining the rectification completion deadline based on the severity level of the security event object; selecting a corresponding preset notification template based on the preliminary event type in the security event object; filling the fields in the security event object into placeholders in the selected template; retrieving supplementary information from the knowledge base based on the event type and severity level and filling it into the corresponding placeholders; generating a problem description text using a large language model; and marking the output structured security notification as pending verification. The structured security notification includes at least the following fields: event overview, scope of impact, problem description and evidence summary, rectification requirements, rectification report submission requirements, and relevant standards or regulations. The event overview includes the event type, severity level, and discovery time. The scope of impact includes information on related assets, production lines, or business systems. The rectification requirements include rectification measures and rectification completion deadlines.

6. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 1, characterized in that, Step S6 specifically includes: Track A Verification: Conduct a document compliance review on the rectification report object and output the document track verification result. The document track verification result includes at least a document compliance score, a document issue list, and a document track judgment result; wherein, the document compliance score is obtained by the following formula: ； In the formula, n is the total number of items to be reviewed. For the first The weighting coefficients for each review item, with each review item having a maximum score of 100 points; For the first The score for each review item; Track B Verification: Based on the rectification requirements and related assets in the structured security notification, a retest task list is automatically generated. For each item in the retest task list, the corresponding retesting method is executed, and the real state track verification result is output. The real state track verification result includes at least the real state verification score, the list of unrepaired items, the real state track judgment result, and the retest evidence list. Track A and Track B execute in parallel and independently.

7. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 6, characterized in that, In the Track B verification, each item in the retest task list includes at least a retest item identifier, a retest item type, a target asset, a retest method, and a severity level; the retest method includes at least one of vulnerability rescanning, port probing, configuration baseline verification, security policy verification, probe data collection, asset fingerprinting, and log backtracking analysis; the single item judgment rule is: when the execution result of the retest method shows that the corresponding security vulnerability has been eliminated, the retest item is judged to pass; otherwise, it is judged to fail. The real-state verification score is obtained using the following formula: ； In the formula, m is the total number of repeated test items. For the first The severity level weight of each retest item; When the When the verification result of the retest item is pass, =1; otherwise =0; when If ≥60 and all retest items with severity level of high risk or above pass, the real state track verification is deemed successful; otherwise, the real state track verification is deemed unsuccessful.

8. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 7, characterized in that, In step S7, the document track verification result and the actual state track verification result are fused and compared, including: If the document track determination result is negative or the real state track determination result is negative, the initial determination is that it fails; if both are positive, the consistency check is initiated. The list of claimed repaired items in the rectification report is matched with the retest results in the real state track verification results to calculate a consistency score; the consistency score is obtained using the following formula: ； In the formula, This indicates the number of successfully matched and repaired items. This indicates the total number of items claimed to have been repaired in the rectification report; Perform a fusion scoring process, which involves weighting and fusing the document compliance score, the real-state verification score, and the consistency score to obtain a fusion verification score. The final judgment rules are as follows: when the document compliance score or real-state verification score is less than 60, it is directly judged as failing; when the consistency score is less than 70, it is judged as inconsistent; if there are unmatched items with a severity level greater than or equal to high risk, it is directly judged as failing; when the fusion verification score is greater than or equal to 80 and all the above conditions are met, it is judged as passing. The verification conclusion object is generated based on the fusion verification score and the final judgment rule.

9. The dual-track verification method for automatic reporting and rectification of industrial safety incidents according to claim 8, characterized in that, In step S8, the closed-loop control includes: If the final judgment result in the verification conclusion object is "pass", then the event status is updated to "closed loop", the full-link record is archived, and the situational awareness indicators are updated. If the final judgment result in the verification conclusion object is "not passed", a rejection notice will be automatically generated and sent to the responsible unit to initiate the next round of rectification. The maximum number of rectification rounds is preset. The first N-1 rounds are automatically rejected by the system to drive rectification. If the Nth round still fails, the process will be upgraded to manual intervention. When a rectification task is completed but a rectification report is not submitted within the time limit, the system will automatically send a reminder notice, and the supervision will be upgraded after the time limit expires.

10. A dual-track verification system for automatic reporting and rectification of industrial safety incidents, characterized in that, include: The alarm access module is used to collect multi-source security alarm information and perform normalization processing to obtain a unified alarm record. The intelligent agent aggregation and noise reduction module is used to aggregate and reduce noise from the unified alarm records to generate a unique security event object. The notification generation module is used to generate structured security notifications based on the security event object; The human-machine collaborative control module is used to receive manual verification and confirmation instructions at preset key nodes before the structured security notification is issued, issue the structured security notification to the responsible unit, and create rectification tasks; The rectification management module is used to receive rectification reports submitted by the responsible unit and generate rectification report objects; The document track verification module is used to initiate track A verification based on the rectification report object, perform document compliance review on the rectification report object, and output the document track verification result; The real state track verification module is used to initiate track B verification based on the target object involved in the structured security notification, automatically retest the real security status of the target object, and output the real state track verification result. The dual-track fusion judgment module is used to perform fusion comparison and analysis on the document track verification result and the real state track verification result to generate a verification conclusion object. The closed-loop control module is used to perform closed-loop control based on the verification conclusion object. If the verification is passed, the closed loop is archived. If the verification fails, a rejection notice is automatically generated and iterative rectification is started until the verification is passed or the preset maximum rectification round is reached. The situational awareness linkage module is used to update the situational awareness platform metrics based on the event information during the event archiving closed loop.

Images