An event order and fresh evidence-based inspection exception processing method and system

Abstract

The present application relates to home Internet of Things inspection, and discloses an inspection abnormality processing method and system based on event order and fresh evidence. The system calculates a fingerprint for abnormal code, target resource and standardized description, aggregates repeated observations into abnormal events with event orders, and confirms recovery only when the source range corresponding to the event is effectively observed in the current inspection batch and the abnormality does not occur for a predetermined number of consecutive times. The system generates idempotent tasks according to event identification, event order and standardized action, checks the event state and order before execution and when the result is submitted, and prevents invalid task writing by using task attempt identification, execution receipt and cross-storage state barrier. The scheme is suitable for heterogeneous home device inspection, and can reduce repeated disposal, false recovery caused by source offline and old task pollution.

Description

Technical Field

[0001] This invention belongs to the fields of IoT device inspection, abnormal event lifecycle management, and distributed task consistency. In particular, it relates to a method and system for handling inspection anomalies using event generations and effective observation evidence. It is applicable to the aggregation, recovery judgment, and handling of anomalies in heterogeneous devices, sensors, gateways, and service interfaces in a home IoT environment. Background Technology

[0002] Home IoT systems typically connect to various sources simultaneously, including lighting, curtains, HVAC, water usage, security sensors, sleep sensors, and energy consumption data. Each source has different data acquisition protocols, update cycles, and online statuses, so the observation results obtained by the monitoring system may cover the entire batch or only a portion of the data sources.

[0003] Current inspection methods typically convert each anomaly observation directly into an alarm. When the same anomaly repeatedly occurs during continuous inspections, it generates a large number of duplicate events, duplicate notifications, and duplicate handling tasks. If events are distinguished solely based on real-time values ​​in the anomaly description, such as treating "there are still 2 faults" and "there are still 5 faults" as different events, it will also fragment the continuous state of the same root cause.

[0004] On the other hand, the absence of an anomaly report in a particular inspection does not necessarily indicate that the anomaly has been resolved. Anomalies will not appear in the results if the data source is offline, the interface times out, the corresponding range has not been queried, or the returned data is invalid. Directly disabling events under these circumstances could misjudge missing observations as normal recovery.

[0005] Inspection events and handling tasks may be stored in different storage locations. When a task consumer retryes, a lease expires, a process crashes between two storage writes, or an abnormal event recurs after recovery, the old task may repeatedly invoke the device, or it may write the execution results of the old generation of events into the new generation of events. Simply relying on a successful action invocation cannot prove that the original exception has disappeared.

[0006] Therefore, a processing solution is needed that can aggregate the same anomaly, identify valid observations within the same range, isolate events of different generations, and prevent the writing of invalid results during cross-storage task execution. Summary of the Invention Technical problems to be solved

[0007] This invention aims to solve the following problems: reduce data bloat and duplicate tasks caused by repeated anomaly observations; avoid false recovery caused by unavailable data sources; isolate old and new processing tasks when restarting after event recovery; and improve the consistency and recoverability of task execution results when event storage and action task storage are independent of each other. Technical solution

[0008] To address the aforementioned technical problems, this invention provides a method for handling inspection anomalies based on event generation and freshness evidence. The method receives a current inspection observation batch generated by the inspection system. The current inspection observation batch includes at least a set of anomaly observations, the batch generation time, and the observation status of the data source. The observation status indicates whether the corresponding source was actually queried, whether the query was successful, whether data blocks were skipped, and whether the batch as a whole is complete.

[0009] Normalization is performed on each anomaly observation in the anomaly observation set. The normalization fields include at least the anomaly code, target resource identifier, and anomaly description. The target resource identifier can be a device identifier, room identifier, gateway identifier, or service resource identifier. Consecutive whitespace in the anomaly description is merged, character case is standardized, and numerical values ​​that vary with the observation are replaced with uniform placeholders. A summary is calculated based on the normalization results to obtain a reproducible anomaly fingerprint.

[0010] In one implementation, the anomaly fingerprint F is generated according to the following formula: F = H(C∥0∥E∥0∥M), where H is the digest function, C is the normalized anomaly code, E is the normalized target resource identifier, M is the normalized anomaly description, 0 represents the field separator, and ∥ represents the concatenation operation. The digest function can be SHA-256 or other digest functions with collision resistance.

[0011] The event storage is queried based on the anomaly fingerprint. If no corresponding event exists, a new anomaly event is created and its generation is initialized to the first generation. If an active anomaly event exists, the evidence of this anomaly is aggregated into that event, the occurrence count is increased, and the last observation time is updated. If the severity of this anomaly is higher than the already saved severity, it is updated to the higher severity and the corresponding evidence is retained, without creating a new parallel event.

[0012] An abnormal event's status includes at least an active status and a terminated status. The active status can further include newly created, confirmed, and reopened; the terminated status can include recovered and ignored. When a terminated event exhibits the same abnormal fingerprint again, the original event is reopened and the event generation is incremented. Simultaneously, the confirmed status (applicable only to the previous generation of events), verification results, and most recent action status are cleared.

[0013] For abnormal events, if their abnormal fingerprints do not appear in the current inspection and observation batch, the observation range corresponding to the event is first determined based on the event's abnormal code and existing abnormal evidence. Then, it is determined whether the range meets the valid observation conditions. Valid observation conditions may include: the current inspection and observation batch is marked as complete; the data block of the corresponding data source has been returned without error or skipped markers; or the batch data quality has reached a preset usable state.

[0014] The consecutive absence count of an event is increased only when the corresponding observation range meets the valid observation conditions. When the consecutive absence count reaches a predetermined number N, the event is marked as recovered and recovery evidence is saved. If the data source is offline, data blocks are missing, the query is incorrect, or the data is skipped, this round of observation is an uncertain observation, and the consecutive absence count remains unchanged. The predetermined number N can be set to an integer greater than or equal to 1 based on the anomaly type or deployment strategy.

[0015] For abnormal events requiring diagnosis or handling, an idempotent key K for the action task is generated based on the event identifier I, the standard action A, and the event generation G. In one implementation: K = H(I∥0∥A∥0∥G). Each idempotent key corresponds to only one action task. The action task stores the request body separately; if the idempotent key provided by the caller already corresponds to a different event, different generation, different action, or different request body, an idempotent key conflict is returned, and the original task is not reused.

[0016] Before creating an action task, the system verifies whether the action falls under the handling plan for abnormal events based on the preset action catalog, and reads the action's risk level, whether confirmation is required, whether it is a read-only action, and whether it is on the automatic execution whitelist. Only actions that simultaneously meet the criteria of low risk, no confirmation required, being read-only, and being on the automatic execution whitelist are allowed to be executed automatically; other actions remain in a state requiring approval or manual execution, thereby preventing the inspection process from directly implementing unauthorized physical equipment control.

[0017] Action task consumers acquire execution rights through a task lease with a valid term and record the number of task attempts. Before execution, the target exception event is read from the event store, the event generation carried by the task is compared with the current event generation in the event store, and it is verified that the current event is still in an active state that allows processing. If the event does not exist, the event has terminated, or the generation is inconsistent, the task is canceled and the action executor is not invoked.

[0018] After the action executor completes its task, it first adds the task identifier, number of task attempts, event generation, and standard action to the execution evidence. Event storage only records the action result and execution receipt when the corresponding task attempt is still valid, the event is still active, and the event generation is consistent. The uniqueness of the execution receipt is jointly determined by the event identifier, event generation, task identifier, and number of task attempts.

[0019] To handle situations where the event store and action task store cannot share the same transaction, a cross-store state barrier is employed. Following a unified locking order, a write transaction in the action task store is initiated first, followed by acquiring the target event write lock in the event store. After confirming the existence of the execution acknowledgment, the unchanged event generation, and the validity of the task attempt, the action task's state transition is committed. During the barrier's maintenance, the target event cannot be recovered and reopened, thus preventing mismatches between the task's final state and the event generation.

[0020] If the process terminates when the event store has submitted an execution receipt but the action task store has not yet submitted its final state, the subsequent recovery process queries the execution receipt. If it completely matches the task identifier, number of task attempts, event generation, and specified action, the action task state is restored without calling the action executor again; if the execution receipt does not exist, it is handled according to the task retry policy.

[0021] Successful execution of an action only indicates that the diagnosis or treatment has been completed; the abnormal event remains pending verification by subsequent inspections. Anomaly recovery is confirmed only if subsequent batches of the same inspection period generate valid observations of the same area, and the anomaly does not reappear for a predetermined number of consecutive periods.

[0022] This invention also provides an inspection anomaly handling system based on event generations and fresh evidence, including an observation batch receiving module, an anomaly fingerprint generation module, an event lifecycle module, a recovery determination module, an idempotent task module, and a cross-storage state barrier module. Each module can be deployed on the same edge computing device or distributed across home gateways and servers.

[0023] The present invention also provides an electronic device and a computer-readable storage medium. When the processor of the electronic device executes a computer program in the memory, it implements the above-described inspection anomaly handling method. Beneficial effects

[0024] Compared to the approach of creating separate records for each anomaly observation, this invention reduces the number of event logs, notification messages, and tasks by aggregating and repeating observations using stable anomaly fingerprints.

[0025] This invention distinguishes between "no anomalies found this time" and "the same range has been effectively observed and no anomalies found", which can avoid false recovery caused by offline source, interface error or missing observation range.

[0026] This invention writes the event generation to both the abnormal event and the action task, which can identify the old generation task when restarting after the event is recovered, reducing the risk of old tasks calling the device or polluting the state of the new event.

[0027] This invention utilizes task attempt identification, execution receipts, and cross-storage state barriers to handle lease re-acquisition and process interruption, reducing repetitive actions and inconsistent states without requiring event storage and action task storage to share a single database transaction.

[0028] This invention separates the action execution result from the anomaly recovery evidence, ensuring that a successful handling call will not bypass subsequent real-world observation and verification, thereby improving the credibility of the anomaly closure result. Attached Figure Description

[0029] Figure 1This is a schematic diagram of the overall structure of the inspection anomaly handling system of the present invention.

[0030] Figure 2 This is a flowchart illustrating the inspection anomaly handling method of the present invention.

[0031] Figure 3 This is a schematic diagram illustrating the data and state relationships between observation data, event generations, recovery evidence, and action tasks in this invention.

[0032] In the diagram: 10. Inspection observation source; 20. Anomaly fingerprint and event module; 30. Recovery judgment module; 40. Idempotent action task library; 50. Cross-storage state barrier; 60. Action execution and re-inspection module; 201. Observation batch; 202. Anomaly fingerprint; 203. Event and generation; 204. Recovery evidence count; 205. Action task idempotent key; 206. Execution receipt and state barrier. Detailed Implementation

[0033] The present invention will be further described below with reference to the accompanying drawings and embodiments. The following embodiments are used to illustrate the implementation of the present invention, and are not intended to limit the scope of protection. Example 1: Abnormal Fingerprint Generation and Event Aggregation

[0034] In the first embodiment, as Figure 1 As shown, the inspection observation source 10 obtains status information from multiple home IoT platforms, sensors, and service interfaces. The anomaly fingerprint and event module 20 normalizes anomaly observations, generates anomaly fingerprints, and updates events. The recovery judgment module 30 determines whether the corresponding observation range has been effectively observed in the current batch. The idempotent action task library 40 stores action tasks, their leases, number of attempts, and status. The cross-storage state barrier 50 coordinates event storage and action task storage. The action execution and review module 60 executes permitted read-only actions and waits for subsequent inspections to verify whether the anomaly has been recovered.

[0035] Inspection observation source 10 generates a platform interface timeout exception. The exception code example is "Platform interface error," the target resource identifier is the corresponding gateway, and the exception description is text containing the platform name and timeout status. The exception fingerprint is standardized to the character format of event module 20, with whitespace merged and easily changing values ​​replaced, before calculating the exception fingerprint. An event identifier is created upon the first occurrence, and the event generation is set to 1.

[0036] When the same anomaly recurs in the next round of inspections, because the standardized anomaly code, target resource identifier, and anomaly description are consistent, the evidence is added to the original event, increasing the number of occurrences. Even if the number of faults in the anomaly description changes, the same anomaly fingerprint can still be maintained after numerical placeholder processing.

[0037] If the severity of this anomaly is higher than the severity of the original event, the event retains the higher severity and the anomaly evidence is updated. The event identifier and event generation remain unchanged, allowing tasks processing this event to continue using consistent lifecycle identifiers. Example 2: Recovery Judgment Based on Valid Observational Evidence

[0038] In the second embodiment, as Figure 2 As shown, in step 101, the current inspection observation batch with batch time and data source observation status is received; in step 102, anomaly fingerprints are generated and events are aggregated or updated; in step 103, the event is reopened and the event generation is incremented only when the termination event reappears; in step 104, for active anomaly events that do not appear in the current batch, it is determined whether their corresponding observation range meets the valid observation conditions.

[0039] A home device platform timed out during this round of inspection, and the corresponding data block was marked as skipped. No device faults from the previous round were found in this round's anomaly set, but the recovery judgment module 30 determined that the fault corresponded to the data source where the timeout occurred; therefore, the recovery evidence count was not increased. The anomaly event remains active.

[0040] When the platform reconnects, and the current inspection observation batch contains a return block from the data source, and the return block has no error or skip flag, and the original anomaly is not in the anomaly set, the system increments the consecutive absence count. After N consecutive times the above conditions are met, in step 105, the event is marked as recovered, and the verification time, verification method, and consecutive count are saved. Example 3: Event Restart and Generational Isolation

[0041] In the third embodiment, if an abnormal event reappears with the same abnormal fingerprint after the first generation has been confirmed as recovered, the event lifecycle module changes the original event status to reopen, increments the event generation from 1 to 2, and clears the recovery verification result of the previous generation.

[0042] The first-generation event generated a read-only diagnostic task that had not yet been executed, carrying event generation 1. After the task consumer obtained the task, it read the event storage in step 106 and found that the current event generation was 2. The system marked the task as canceled and did not call the action executor. The second-generation event needs to generate a new idempotent task separately with event generation 2.

[0043] Therefore, event identifiers are used to associate the historical trajectory of the same root cause, and event generations are used to distinguish different activity cycles. Together, they prevent old handling tasks from entering new event cycles. Example 4: Action Risk Classification and Idempotent Tasks

[0044] In the fourth embodiment, the event module generates a handling plan based on the exception code, which includes re-capturing a read-only snapshot and adapter processing actions requiring manual approval. After verifying that the action belongs to the handling plan, the idempotent task module reads the risk catalog.

[0045] Re-capturing a read-only snapshot that simultaneously meets the conditions of low risk, no confirmation required, read-only, and whitelisting is set to an automatic execution state. Actions that require changes to the state of services or physical devices are set to a state requiring approval or manual execution; inspection tasks cannot be directly executed by consumers.

[0046] In step 106, when creating tasks repeatedly for the same event identifier, the same event generation, and the same canonical action, the same idempotent key is generated and the existing task is returned. If the idempotent key explicitly provided by the caller is already associated with different request subjects or different actions, a conflict is returned to prevent unrelated request aliases from being assigned to the same task. Example 5: Lease Renewal and Task Attempt Fence

[0047] In the fifth embodiment, in step 107, the first task consumer acquires a task lease, and the task attempt count becomes 1. When the action is completed but the result has not yet been submitted, the first task consumer pauses until the lease expires. The second task consumer then acquires the task again, and the task attempt count becomes 2.

[0048] After the first task consumer recovers, it attempts to submit a result with one attempt count. Since the current task attempt count in the action task storage is already two, the system determines that the first task consumer has lost ownership of the task and refuses to write the event execution receipt. Only consumers carrying the current task attempt count can continue to submit. Example 6: Cross-Storage Execution Receipt Recovery

[0049] In the sixth embodiment, in step 108, the current task consumer writes the read-only action result, task identifier, number of task attempts, and event generation to the event store, and the event store generates a persistent execution receipt. If the process terminates after the write is successful but before the action task store submits its final state, the action task temporarily remains in an intermediate state.

[0050] When the recovery consumer reprocesses the intermediate state, it queries the event store within the storage state barrier 50. Upon finding an execution receipt with an exact field match, the recovery consumer sets the action task to a pending review state and does not invoke the read-only action again. If the event has already been recovered, it is set to verified recovery; if the event has been restarted and the generation changed, the original task is canceled.

[0051] After a read-only action is successful, the event itself will not be immediately restored. The system continues to receive the current inspection observation batch and determines restoration according to the effective observation conditions and the number of consecutive absences described in Example 2, forming a closed loop that connects abnormal evidence, handling actions, and new observation verification.

[0052] Those skilled in the art can implement the event storage and action task storage as different relational databases, key-value stores, or log-type stores without departing from the inventive concept; implement the write lock as a database write transaction, version comparison exchange, or distributed lease; and replace the digest function with other stable digest algorithms. All such replacements should maintain the technical relationship that event generation verification, valid observation recovery conditions, task attempt barriers, and action results are not directly equivalent to anomaly recovery.

Claims

1. A method for handling inspection anomalies based on event generation and fresh evidence, characterized in that, include: Receive the current inspection observation batch generated by the home IoT inspection system. The current inspection observation batch includes an abnormal observation set, the batch generation time, and the observation status that respectively represents whether at least one data source is effectively observed. Normalize the abnormal code, target resource identifier, and abnormal description in the abnormal observation set, and generate an abnormal fingerprint based on the normalization result. Based on the abnormal fingerprint, recurring abnormal observations are aggregated into abnormal events, and the abnormal events include at least an event identifier, an event generation, an event state, an anomaly severity, and anomaly evidence; When an abnormal event that has been terminated reappears with a corresponding abnormal fingerprint, the abnormal event is reopened and the event generation is incremented; for active abnormal events that do not appear in the current inspection and observation batch, the observation range corresponding to the active abnormal event is determined, and the number of consecutive absences is increased only when the observation range meets the effective observation conditions in the current inspection and observation batch, and the active abnormal event is marked as recovered when the number of consecutive absences reaches a predetermined number; Based on the event identifier, the event generation, and the standard action, an idempotent key for the action task is generated, and an action task carrying the event generation is created. Before executing the action task, the event generation carried by the action task is compared with the current event generation in the event storage, and the action task is prevented from executing if the two are inconsistent or the current event state does not allow for processing. In the process of writing the action execution result into the action task storage and event storage, the status is checked according to the task identifier, the number of task attempts and the event generation, and the execution receipt corresponding to the current task attempt is recorded in the event storage. In this case, if the action is executed successfully, the abnormal event is not directly marked as recovered.

2. The inspection anomaly handling method according to claim 1, characterized in that, The standardization process includes: converting the exception code into a unified character format; selecting at least one from the device identifier and room identifier as the target resource identifier; performing whitespace merging, case unification, and numerical placeholder processing on the exception description; and concatenating the processed exception code, target resource identifier, and exception description to calculate a digest, thereby obtaining the exception fingerprint.

3. The inspection anomaly handling method according to claim 1, characterized in that, When anomaly observations with the same anomalous fingerprints occur repeatedly, the occurrence count of the corresponding anomalous event is increased and the last observation time is updated; when the severity of the current anomaly is higher than the severity of the previously saved anomaly, the severity of the current anomaly is saved and the corresponding anomalous evidence is retained, without creating a parallel anomaly event.

4. The inspection anomaly handling method according to claim 1, characterized in that, The effective observation conditions include at least one of the following: the current inspection observation batch is marked as complete; the data block corresponding to the observation range has been returned and has not been marked as error or skipped; the data quality status of the current inspection observation batch has reached a preset usable state. If the effective observation conditions are not met, the number of consecutive absences remains unchanged.

5. The inspection anomaly handling method according to claim 1, characterized in that, When creating the action task, the risk level, whether confirmation is required, and whether it is a read-only action are determined according to the preset action catalog. Only standardized actions that simultaneously meet the criteria of low risk, no confirmation required, and being read-only and are located in the automatic execution whitelist are set to the automatic execution state, while other standardized actions are set to the state that requires approval or manual execution.

6. The inspection anomaly handling method according to claim 1, characterized in that, Action task consumers acquire the right to execute action tasks through a task lease with a valid term, and increase the number of task attempts for each acquisition of the right to execute; when the lease expires and another task consumer regains the right to execute, the expired execution result submitted by the previous task consumer is rejected based on the task identifier, the number of task attempts, and the event generation.

7. The inspection anomaly handling method according to claim 1, characterized in that, The state verification includes: first, opening the write transaction of the action task storage according to a preset locking order, and then locking the target abnormal event in the event storage; after confirming that the execution receipt corresponding to the task identifier, the number of task attempts and the event generation exists, and that the current event generation of the target abnormal event has not changed, submitting the state transition of the action task; when the event storage has been written with the execution receipt but the action task storage has not yet completed the state transition, restoring the state of the action task according to the execution receipt without executing the corresponding action again.

8. An inspection anomaly handling system based on event generation and fresh evidence, characterized in that, It includes an observation batch receiving module, an anomaly fingerprint generation module, an event lifecycle module, a recovery determination module, an idempotent task module, and a cross-storage state barrier module; each module is configured to execute the inspection anomaly handling method according to any one of claims 1 to 7.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, which, when executed by the processor, causes the electronic device to perform the inspection anomaly handling method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the inspection anomaly handling method according to any one of claims 1 to 7.

Images