An industrial equipment edge cloud cooperative fault prediction and early warning system

Abstract

The application discloses an industrial equipment edge cloud cooperative fault prediction and early warning system and relates to the technical field of industrial equipment early warning. The cloud side generates an immutable release list and signs the list by combining candidate models, inference pipelines, thresholds, dependencies and compatible information. The edge side verifies the signature and enters a queue to be verified through engineering / compliance gating. The edge side establishes a production flow ring buffer, generates time slices and event slices, replays the inference under the constraint of a real-time budget scheduler, and outputs a three-state risk gate with the minimum sample size / confidence constraint. After the gate passes, online shadow verification and small-range double-slot atomic switching are performed. A self-check window monitors a rollback trigger set and can locally rollback or degrade to a safe state. Finally, a reason vector is written into a hash chain evidence chain log, offline cache is supplemented, and the cloud side makes a compliance determination, supporting batch promotion or isolated reproduction. The method reduces drift risk, reduces interference with the main inference, and improves traceable operation and maintenance capabilities.

Description

Technical Field

[0001] This invention relates to the field of industrial equipment early warning technology, specifically to an industrial equipment edge-cloud collaborative fault prediction and early warning system. Background Technology

[0002] In industrial production settings such as discrete manufacturing, critical equipment like CNC machine tools, machining centers, spindles, and bearings often have multiple sensors for vibration, temperature, and current. Edge gateways on the production line side preprocess, extract, and perform inference operations on high-frequency data, and integrate with cloud management platforms for fault prediction and early warning. These systems generally require low latency, low power consumption, availability in weak network conditions, and high reliability, and must meet compliance constraints such as batch deployment across multiple production lines and devices, access control, and security auditing. Furthermore, as operating conditions shift, components wear out, and algorithms iterate, the on-site model and operating environment are constantly upgraded and migrated in batches. Therefore, projects often introduce containerization and centralized operation and maintenance platforms for deployment, updates, monitoring, and rollback, allowing unified operation of numerous edge nodes within a maintenance window.

[0003] For example, Chinese patent document CN118227271A (June 21, 2024) discloses a terminal all-in-one machine operation and maintenance method and device based on a container cloud platform. This method unifies terminal management through an operation and maintenance platform center and operation and maintenance clients, groups the terminals, packages the application system and its corresponding environment into image files, and deploys, updates, and runs them in terminal containers. Simultaneously, operation and maintenance are performed, and when problems are found, a specified version is selected for batch rollback. US patent document US1035550B2 (July 16, 2019) discloses technology related to the gradual deployment of "canary instances," analyzing the software's running status during the gradual deployment process and terminating candidate instances when anomalies are detected. The group standard T / CICC35020—2025 "Maintainability Technical Requirements for Complex Intelligent Systems" (November 20, 2025) specifies the objects and quantitative and qualitative requirements for the maintainability of complex intelligent systems.

[0004] However, in practical applications of fault prediction and early warning in industrial edges, model improvement often involves more than just the model itself. Improvements also involve changes in preprocessing and features, alarm threshold strategies, runtime version dependencies, and computing resource consumption. Differences in the multi-condition and noise disturbance conditions of model training data, along with adjustments to thresholds or post-processing strategies, can lead to significant variations in alarm frequency and alarm levels, resulting in substantial downtime and maintenance costs. Furthermore, continuous production lines limit the convertible window, restricting the computing power, storage, and network bandwidth of edge nodes, potentially causing intermittent interruptions. Distributed nodes may also frequently go offline or be located in different security domains, leading to issues such as inconsistent versions, interrupted updates, or incomplete rollback execution.

[0005] Existing image-level deployment, health monitoring, and version rollback operation and maintenance methods primarily focus on operational status indicators such as process survival and resource utilization. They lack direct, actionable, and reproducible criteria for judging changes in early warning behavior under real-world conditions after model updates. When candidate versions experience false alarms, missed important signs, or reduced early warning lead times, it may lead to downtime for inspection, delays in risk handling, or interruptions in the monitoring link. Subsequent investigations are further hampered by difficulties in replaying on-site data, incompatible node versions, and missing update records, making risk control and fault localization for batch upgrades even more challenging. Therefore, existing technologies struggle to achieve controllable online deployment and reliable rollback of model updates without interrupting early warning services. Summary of the Invention

[0006] (a) Technical problems to be solved

[0007] To address the shortcomings of existing technologies, this invention provides an edge-cloud collaborative fault prediction and early warning system for industrial equipment. After verification and signature at the cloud edge, the system is entered into a verification queue via engineering / compliance gating. A production flow circular buffer is established at the edge, generating time slices and event slices. Under the constraints of a real-time budget scheduler, inference is replayed, and a three-state risk gating is output with minimum sample size / confidence constraints. After gating passes, online shadow verification and small-scale dual-slot atomic switching are performed. A self-checking window monitors the rollback trigger set and allows for local rollback or degradation to a safe state. Finally, the cause vector is written to the hash chain evidence chain log, and the system is re-transmitted after network outage and performs cloud-side compliance judgment, reducing drift risk, minimizing interference with main inference, and improving traceable operation and maintenance capabilities. This solves the technical problems described in the background section.

[0008] (II) Technical Solution

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] An industrial equipment edge-cloud collaborative fault prediction and early warning system includes: generating and signing an immutable release list containing model hashes and pipeline and threshold configuration fingerprints on the cloud side; and verifying the signature on the edge side, adding candidate versions to the queue to be verified and generating release list fingerprints through engineering / compliance gating.

[0011] A production flow ring buffer is established at the edge and time slices and event slices are saved. The candidate runtime replays the reasoning under the permission of the real-time budget scheduler. The gating evaluator outputs the gating conclusion and evidence snapshot of pass / reject / uncertainty.

[0012] When the gating conclusion passes, online shadow verification is performed and the online traffic pointer is switched using a dual-slot atomic switching mechanism during the small-scale switching phase. Within the self-test window, the local atomic rollback or downgraded security state is executed by pressing the rollback trigger set.

[0013] The cause vector is written to the evidence chain log and kept sequentially consistent through a hash chain. It is cached locally when the network is down and retransmitted to the cloud-side audit aggregation service after the network is restored. After verification by the cloud side, it outputs batch promotion or isolation decisions and generates the freeze reason and the slice index or summary required for reproduction when the isolation occurs.

[0014] Furthermore, the immutable release list also includes dependency set fingerprints, compatibility vectors, validity periods, and rollback targets; after the signature verification is passed, the edge side performs consistency verification on the model hash and pipeline and threshold configuration fingerprints. The minimum audit record includes the release list fingerprint, engineering / compliance gating results, queuing timestamps, and candidate version identifiers.

[0015] Furthermore, the engineering / compliance gating verifies the security domain and window, compatibility vector, resource level, and network disconnection policy in a fixed order. If any verification fails, the edge side keeps the candidate version as a local cache and generates a delay reason containing the gating item identifier, which is then sent back to the cloud side without entering the verification queue.

[0016] Furthermore, the production flow ring buffer consists of sequentially numbered segmented files. Each segmented file includes a segment header and a segment body. The segment header records the segment sequence number, time range, channel set, and segment body checksum. Before overwriting the oldest segment, the edge side writes an overwrite forecast containing the segment sequence number into the slice index ledger.

[0017] Furthermore, time slices are generated using a fixed-period sampling window, and event slices are triggered when the online warning score reaches a threshold. The slice index ledger records the slice number, slice type, time range, and segment range.

[0018] Furthermore, the real-time budget scheduler uses the main inference latency percentile, main inference processor occupancy, and main inference storage level as budget observations. When the budget observations reach the real-time budget limit, the real-time budget scheduler interrupts the replay inference of the candidate runtime and writes the slice sequence number and stop reason code into the evidence snapshot.

[0019] Furthermore, the gating evaluator performs minimum sample size constraints and gating confidence constraints when generating the model risk gating report; when the constraints are not met, the gating conclusion is output as uncertain and sampling continues; when the constraints are met and the model risk gating report meets the pass decision, the gating conclusion is output as pass; when the constraints are met and the model risk gating report meets the rejection decision, the gating conclusion is output as rejection, and a snapshot of the key indicators is written to the minimum audit record.

[0020] Furthermore, in the online shadow verification phase, the edge side copies the real-time input to the candidate runtime according to the controlled sampling ratio, and increases the controlled sampling ratio within the time range corresponding to the event slice; the candidate runtime verifies the consistency between the pipeline and threshold configuration fingerprint and the published list fingerprint before performing inference.

[0021] Furthermore, during the small-scale switchover phase, a small-scale object list is generated based on the device group identifier and written to the minimum audit record; the dual-slot atomic switchover mechanism updates the online traffic pointer file to point the online traffic pointer from the known stable version to the candidate version, and the update of the online traffic pointer file adopts atomic replacement writing.

[0022] Furthermore, the rollback trigger set consists of system triggers, business triggers, and consistency triggers. System triggers include latency percentile exceeding limits and resource level exceeding limits. Business triggers include alarm rate mutation and critical alarm consistency decline. Consistency triggers include release manifest fingerprint mismatch and dependency set fingerprint inconsistency. When any trigger is hit, a local atomic rollback is performed and the candidate version is frozen.

[0023] Furthermore, the downgraded safety state is entered when a rollback anomaly is detected after the rollback trigger set is hit. After entering, the candidate runtime is stopped and the main inference is run with rules and thresholds as a fallback. The controlled sampling ratio of the online shadow verification stage is set to zero and the update is locked.

[0024] Furthermore, the cause vector includes version fingerprint, gating conclusion, key indicator snapshot, state machine path, trigger hit record and rollback reason. The evidence chain log generates records in an append-only manner and maintains record order consistency with a hash chain; the evidence chain log is stored in a rolling manner.

[0025] Furthermore, when the network is down, the edge side writes the evidence chain log to the retransmission retry queue and segments it in a block transmission manner. After the network is restored, the cloud side audit aggregation service verifies the integrity of the hash chain and makes a compliance judgment. If the compliance is met, it outputs a batch promotion decision. If the compliance is not met, it outputs an isolation decision and generates the reason for freezing and the slice index and summary required for reproduction.

[0026] (III) Beneficial Effects

[0027] This invention provides an edge-cloud collaborative fault prediction and early warning system for industrial equipment, which has the following beneficial effects:

[0028] The immutable release list generated and signed on the cloud side is used to solidify the model hash, pipeline and threshold configuration fingerprint, dependency set fingerprint, and compatibility vector. After verification and hash validation on the edge side, it is input into the engineering / compliance gate, enqueued and written to the minimum audit record to avoid unpredictable behavior on the edge side through drift and configuration drift. The edge side generates a production flow circular buffer and time slices and event slices. The slice index ledger records the sequence number, type and time range, so that the production input becomes replayable and locatable verification material when the main inference runs.

[0029] During candidate runtime, the real-time budget scheduler allows reading slice replay inference and is preempted when the main inference approaches the real-time budget limit. The gating evaluator outputs a pass, reject, or indeterminate gating conclusion and solidifies evidence snapshots. Degradation identification does not crowd out the main inference alarm output rhythm and is traceable.

[0030] After the gating conclusion is passed, the edge-side online shadow verification phase will be controlled sampling and copying to the candidate runtime in real time and constrained by the real-time budget scheduler. During the small-scale switching phase, the online traffic pointer will be updated through dual-slot atomic switching and enter the self-check window, allowing the candidate version to be verified and switched online within a controlled range.

[0031] Within the self-inspection window, the rollback trigger sets of system, business, and consistency classes are continuously monitored. When a hit occurs, a local atomic rollback is executed and the candidate version is frozen. If a rollback fails, the system enters a degraded safety state and runs with rules / thresholds as a fallback. In case of anomalies, early warnings and risk localization can still be implemented. Attached Figure Description

[0032] Figure 1 This is the overall architecture diagram of the edge-side candidate version verification and audit closed-loop system of the present invention;

[0033] Figure 2 This is a flowchart of the immutable release list fingerprint generation and signature verification gating process of this invention;

[0034] Figure 3 This is a schematic diagram of the production flow ring buffer segment disk and slice index ledger structure of the present invention;

[0035] Figure 4 This is a timing diagram of the replay inference and budget pressure preemption scheduling for the candidate version of this invention;

[0036] Figure 5 This is the state machine diagram for determining the three-state conclusion of the gating evaluation in this invention;

[0037] Figure 6 This is a topology diagram of the mirror sampling and bypass comparison for online shadow verification in this invention;

[0038] Figure 7 This is a schematic diagram of the dual-slot small-range switching and flow pointer file atomic replacement of the present invention;

[0039] Figure 8 This is a state machine diagram of the self-test window rollback trigger set and the degraded safety state of the present invention;

[0040] Figure 9 This is a schematic diagram of the evidence chain log hash chain, network outage retransmission, and cloud-side audit review of the present invention. Detailed Implementation

[0041] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0042] Please see Figures 1-9 This invention provides an edge-cloud collaborative fault prediction and early warning system for industrial equipment, comprising:

[0043] Step 1: Transform the candidate version from a loose set of files into a verifiable, gated, and queued immutable release object, and output the release list fingerprint and gating conclusion, so that Step 2 can directly carry out production slice playback verification based on this.

[0044] In discrete manufacturing workshops, edge-side inference nodes typically continuously read vibration, temperature, and current sensor data and output alarms via container processes. On-site model iterations often involve changes in preprocessing order, feature configuration, alarm threshold strategies, and runtime dependent versions. If only overlay updates are used, dependency drift or configuration drift may introduce unpredictable alarm discrepancies at the edge, and these discrepancies often do not manifest as process crashes, but are easily exposed only after batch releases. Furthermore, production lines have prohibited switching windows, and the edge may be in a weak or offline network state. Without consistency checks and execution gating, updates may occur at inappropriate times, resulting in a lack of common benchmarks for subsequent replay verification, shadow verification, and rollback. Therefore, step one first solidifies candidate versions as immutable release objects, and then uses engineering / compliance gating to control when they enter the verification queue, thus providing a traceable input anchor for step two.

[0045] Candidate versions typically consist of model files, inference pipeline configurations, alarm thresholds and policy configurations, runtime dependency lists, and compatibility information. To ensure that edge-side inference nodes maintain the same consistency across different file paths and packaging orders, normalized serialization is performed before writing these elements into the immutable release manifest. The normalized serialization process fixes the field set, field order, and field encoding, making the release manifest fingerprint unaffected by changes in path names, line breaks, or key-value order. This transforms consistency verification from a file system format to a content semantic format.

[0046] The cloud-based release management node generates model artifact fingerprints from the model file content. It then generates configuration fingerprints by performing rules such as whitespace removal, comment removal, key sorting, and unit conversion on the inference pipeline configuration and threshold strategy configuration. Finally, it generates dependency fingerprints by sorting the runtime dependency list by image digest and library version. Finally, it encodes compatibility information into compatibility vectors according to field completeness rules.

[0047] Subsequently, the cloud-side release management node writes the aforementioned fingerprint and compatibility vector into the immutable release manifest body, generates a normalized byte sequence according to a preset field order, and then calculates the release manifest fingerprint. The calculation of the release manifest fingerprint uses domain-separated tags to avoid semantic ambiguity when the same hash function is reused for different purposes.

[0048]

[0049] In the formula: the fingerprint of the published list Fixed-length bit strings used to uniquely identify immutable published lists; hash function operators Deterministic mapping maps an input bit string to a fixed-length bit string, with the output bit width determined by the selected instance; hash function operator. Select a one-time hash algorithm with collision resistance; optionally, use SHA-256, SM3 or a hash algorithm with equivalent collision resistance; the cloud-side publishing management node and the edge-side inference node use the same algorithm identifier and output bit width.

[0050] Domain Separation Tags Fixed-length or variable-length bit strings are used to distinguish whether this hash is a published list fingerprint, and their values ​​are within the range of system-preset constants; field separation labels. A pre-defined constant byte string is used to distinguish between the release list fingerprint and the evidence chain log record digest; for example, a UTF-8 byte string of ReLEASE-ManIFESt-V1 can be used.

[0051] Canonical byte sequence A bit string generated from the immutable release manifest body according to field order and encoding rules; it must contain at least the model artifact fingerprint, inference pipeline configuration fingerprint, threshold policy configuration fingerprint, dependency fingerprint, compatibility vector, and rollback target version; a canonical byte sequence. The generation rules are as follows: Represent the immutable release list body as a key-value structure; sort key names in ascending lexicographical order; represent numeric fields in decimal and prohibit scientific notation; represent text in UTF-8 and replace newline characters with LF; remove all whitespace indentation and comments; map Boolean and enumeration fields to preset integer codes; and concatenate the sorted key sequence into a canonical byte sequence. .

[0052] Specifically, the compatibility vector is generated using a field completeness priority rule: the processor architecture field uses enumeration encoding, the kernel version range specifies the endpoint inclusion relationship, and the container runtime version range specifies the comparison rules; the runtime dependency manifest preferably uses the image digest as the image identifier rather than the image tag, so that the dependency fingerprint is bound to the actual content.

[0053] To avoid invisible character differences in configuration text across different editors, the inference pipeline configuration and threshold strategy configuration perform unified encoding and line break normalization before generating configuration fingerprints, and then serialize the keys in lexicographical order. If the configuration uses a hierarchical structure, the hierarchical paths are first expanded into full path keys and then sorted to ensure that the insertion order of different levels does not change the normalized byte sequence. The cloud-side release management node also writes a read order list into the immutable release list. This list guides the edge-side inference nodes in recalculating the rules and order when recalculating the normalized byte sequence, and specifies the normalization version number used, so that historical versions can still be recalculated when rules are upgraded in the future.

[0054] The release manifest fingerprint is independent of file paths and packaging order, and edge-side inference nodes can still obtain verification conclusions even when the disk write format is different. Domain separation labels distinguish different hash uses of the release manifest fingerprint, avoiding misuse of the same hash result in different contexts; compatibility vectors and dependency fingerprints are written into the manifest body, providing input boundaries for subsequent gating judgments, and preventing runtime failures from replacing compatibility judgments.

[0055] Once the release list fingerprint is fixed, if the release payload is replaced or truncated during cross-security domain forwarding, breakpoint resumption, or manual handling, the edge-side inference node may receive an incomplete payload without its knowledge.

[0056] To this end, the immutable release list and the candidate version file list summary are included in the signature input, and edge-side inference nodes are required to complete a closed-loop verification of signature verification, recalculation, and consistency comparison before entering the engineering / compliance gating. If any link fails, the node shall not enter the verification queue.

[0057] The cloud-side release management node uses its private key to generate a manifest signature for the signature input and writes the manifest signature and public key identifier into the release payload. After receiving the payload, the edge-side inference node first matches the public key identifier in its local trusted key store and completes the signature verification; if the signature verification fails, the candidate version is marked as frozen and written to the audit rejection record.

[0058] After successful signature verification, the edge-side inference node recalculates the normalized byte sequence and recalculates the release list fingerprint according to the read order list in the immutable release list. If the recalculated release list fingerprint is inconsistent with the release list fingerprint in the payload, the candidate version is frozen and the reason for freezing is returned, and it does not enter the gating process. Only when the signature verification is successful and the release list fingerprint is consistent will the edge-side inference node generate a minimum audit record and be granted eligibility for queuing.

[0059] The minimum audit record is appended, not writing the original content of the candidate version, but recording an evidence summary and action result. The minimum audit record must include at least the release list fingerprint, candidate version identifier, signature verification result, consistency comparison result, reception timestamp, current security domain identifier, and disk path fingerprint. This record is written to local persistent storage, allowing traceability of the candidate version reception and verification process even in the event of a network outage. To prevent the same release payload from being repeatedly delivered, causing audit record bloat, the edge-side inference node queries the most recent record in local persistent storage using the release list fingerprint before writing the minimum audit record. If the same release list fingerprint is found and its status is frozen or enqueued, the duplicate write is rejected and the reason for the duplicate delivery is returned. This deduplication behavior does not affect subsequent steps reading the queue head index because the queue only maintains one enqueue event.

[0060] In use, signature verification and fingerprint recalculation simultaneously lock the integrity of the payload and the consistency of its content, ensuring that candidate versions have a traceable basis of authenticity before entering the gating system. The freezing strategy blocks inconsistent payloads before gating, reducing duplicate downloads and disk writes caused by differences being exposed only after candidate versions have entered the verification queue.

[0061] Passing the verification of a candidate version does not equate to immediate entry into verification. Limitations in industrial settings include restrictions on window switching, security domain isolation, rising resource levels, and network outage policies. Ignoring these limitations could lead to a large number of disk writes during periods of high production line load, or alter the operating environment during network outages when rollback conditions are incomplete, thus delaying the exposure of risks until steps two and three. Therefore, engineering / compliance gating is expressed as a recalculated violation degree, and the window boundaries corresponding to the violation degree are written into the gating cause vector, providing a clear basis for delays and allowing for reassessment of triggering conditions.

[0062] Edge-side inference nodes break down engineering / compliance gating into four quantities: security domain violation, compatibility violation, resource level violation, and network disconnection policy violation. These are then aggregated using the largest operator to form the gating violation score. A gating violation score of zero indicates successful gating, while a non-zero score indicates delay or rejection. The security domain violation score is generated by comparing the current security domain identifier with the list of allowed domains issued by the cloud. The compatibility violation score is generated by comparing the processor architecture, instruction set extensions, kernel version, container runtime version, and compatibility vector field-by-field collected by the edge-side inference nodes. The resource level violation score is generated based on the main inference latency percentile, CPU usage, memory usage, and storage level mapping. The network disconnection policy violation score is generated based on network connectivity and local rollback capability availability indicators. The gating violation score is the maximum of the four values, ensuring that if any one of these serious violations exists, the system will not enter the verification queue.

[0063]

[0064] Where: Gating violation degree : Non-negative real number, used to summarize the most serious violations of engineering / compliance gating; security domain violation degree : A non-negative real number indicating whether the current security domain allows candidate versions to enter the verification queue; the edge-side inference node reads the local security domain identifier (e.g., from the device certificate domain, network partition label, or local configuration file). If the security domain identifier is in the allowed domain list, then... ,otherwise And write the most serious violation as security domain mismatch.

[0065] Compatibility violation : A non-negative real number representing the deviation of the current node's compatibility information from the compatibility vector; Read the processor, kernel, container runtime version, instruction set extension identifier, and critical dependency library version (obtainable from system information and container runtime interface), compare each field with the compatibility vector, and if a required field does not satisfy the range relationship, then... ,otherwise If further subdivision is needed, the number of fields that do not meet the requirements can be written into the reason vector.

[0066] Resource water level deviation : A non-negative real number, representing the degree of deviation of the current resource level from the gate boundary; Reuse Budget Pressure Index The observation interface obtains the percentile of the main inference latency. Main inference processor usage Main inference storage level .like and and but ,otherwise And write the out-of-limit items into the cause vector. Network disconnection policy violation degree. : A non-negative real number representing the degree of deviation between the network status and the network outage policy requirements; network connectivity indicators (e.g., heartbeat status to the cloud-side deployment management node) and local rollback capability availability indicators (e.g., the health status of the first slot, the writable status of the traffic pointer file). If the network is unavailable and local rollback capability is unavailable, then ,otherwise ;when You are prohibited from switching to step three at this time.

[0067] Specifically, the resource level violation does not directly use instantaneous sampled values, but uses aggregated values ​​within a fixed time slice as the observation, to avoid short-term spikes locking candidate versions in a delayed state for a long time; the aggregated values ​​can be formed by the latency percentile and resource usage statistics read by the edge-side inference nodes from the main inference runtime, and the statistical window is consistent with the sampling window of the main inference, so that the gating judgment and the main inference load change are kept on the same time scale.

[0068] Window locking can prevent gating conclusions from frequently flipping due to short-term fluctuations; after calculating the gating violation, the edge-side inference node writes the start and end boundaries of the currently prohibited switching window and the gating violation into the gating cause vector, but the gating conclusion remains unchanged; it is recalculated when the window expires or the compatibility field changes; the gating cause vector uses structured field storage, writing the most severe violation field along with the gating violation, so that operations and maintenance personnel can directly read which violation caused the delay, thereby deciding whether to change the maintenance window or resource quota.

[0069] In use, gating violation unifies various engineering constraints into a recalculated expression, making delays or rejections explainable and reducing blind retries by maintenance personnel. Window locking binds the prohibition of switching windows to the gating conclusion, reducing repeated evaluations and disk writes caused by short-term resource jitter.

[0070] Furthermore, step two requires using the release list fingerprint as the version anchor point to select a slice from the production flow circular buffer and perform replay verification. If step one only outputs unstructured text conclusions, step two will find it difficult to determine whether the current candidate version has passed gating, whether it remains consistent, and what its rollback target version is, thus making it difficult to form a traceable verification chain.

[0071] Therefore, after the gating is passed, a queue token to be verified is generated, and the token is persistently bound locally with the release list fingerprint, gating reason vector, and minimum audit record.

[0072] When the gating violation is zero and the node is within the allowed switching window, the edge-side inference node changes the candidate version status from deferred to enqueued and generates a queue token to be verified. The queue token to be verified contains at least the release manifest fingerprint, candidate version identifier, rollback target version identifier, gating reason vector summary, and enqueuing timestamp. The edge-side inference node writes the queue token to be verified to the head index of the queue to be verified and appends the same token to the current segment of the evidence chain log to maintain its order with the minimum audit record. For the deferred state, the edge-side inference node does not generate a queue token to be verified, but writes the gating reason vector to the evidence chain log and sends it back to the cloud side; for the rejected state, the edge-side inference node writes a freeze flag and refuses to enqueue again. The freeze flag contains the release manifest fingerprint and the freeze reason, and the freeze flag is preferentially written to local persistent storage to resist duplicate delivery after network outage recovery.

[0073] After passing gating, edge-side inference nodes generate a queue token to be verified and bind it to the release list fingerprint, gating reason vector, and minimum audit record, writing it to the queue and evidence chain log. For delays and rejections, the reason vector is solidified or the flag is frozen, respectively. The head index of the queue to be verified uses a monotonically increasing sequence number to mark the enqueue order, allowing edge-side inference nodes to proceed with verification sequentially even in the event of a network outage. When the network is restored and data is retransmitted to the cloud, the cloud-side release management node re-enqueues the events using the same sequence number, thus avoiding ambiguity caused by inconsistencies between the cloud-side recorded order and the actual edge-side order.

[0074] The differentiated solidification of delayed and frozen tokens maintains the header index unchanged, preventing duplicate deliveries from causing queue pollution and verification errors. Token and evidence chain logs are appended from the same source, and subsequent replay verification, shadow verification, and switchover rollback restore the event order in the same sequence.

[0075] Step 2: Publish the list fingerprint while the main inference continues to run. Anchor candidate versions, perform replay reasoning based on time slices and event slices generated by the production flow circular buffer, and output confidence constraint model risk gating conclusions and evidence snapshots.

[0076] Even if candidate versions in industrial environments are implemented on edge inference nodes, they may experience sudden changes or shifts in critical alarm timing under real-world conditions due to differences in preprocessing order, feature settings, or threshold strategies. Problems generally do not cause process crashes and are difficult to detect promptly based solely on resource availability. Simultaneously, if playback verification competes with main inference for processor and storage, it will conversely cause alarm output delays. Step two, to limit verification input to production slices, mandates preemptive verification execution, and sets a three-state verification conclusion with confidence, ensuring that pre-deployment risk identification and continuous production line operation are simultaneously achieved.

[0077] If multi-channel sensor data is not aligned during writing, channel misalignment will occur during playback, making the feature vectors of the candidate runtime and the main inference runtime incomparable. To avoid treating alignment errors as model degradation, a unified time base is first established before disk segmentation, ensuring that any playback slice can be located within a continuous frame range.

[0078] The edge-side inference node adds a monotonically increasing timestamp to each channel sampling point and constructs a data frame with the channel set. When a channel loses a sample, the edge-side inference node fills it in according to the order-preserving filling rule, preferably using piecewise linear interpolation, and writes an interpolation mark in the frame header so that the source of the filling can be identified during the playback stage.

[0079] The data frames are then written sequentially into the production stream circular buffer. The circular buffer contains multiple segment files, each containing a segment header and a segment body. The segment header identifies the segment number, start and end timestamps, channel set, sampling rate, and segment body checksum. The segment body uses a continuous sequence of data frames. Once the segment body is full, the next segment file is written. Before overwriting the oldest segment, an overwrite warning is written to the slice index ledger, and subsequent slice references avoid overwriting the data to be overwritten.

[0080] The production flow ring buffer retention boundary is fixed after queuing. The edge-side inference node calculates the number of segments that can be accommodated based on the number of channels, sampling rate identifier, and storage quota, and writes it into the gating cause vector, making the coverage behavior predictable. The production flow ring buffer retention duration preferably covers at least one operating condition switch, and more preferably covers one processing cycle fluctuation, so that the pre-trigger window and post-trigger window of the event slice can fall within the same retention period without premature coverage; the segment body size of the segment file is preferably optimized, and the number of segments spanned by a single event slice is limited, avoiding cross-segment splicing overhead.

[0081] The specific form of the order-preserving and point-filling rule: For piecewise linear interpolation, it can be supplemented by: when the channel is at the timestamp and Sampled values For the missing intermediate moments interpolation value Simultaneously, the interpolation source channel and interpolation interval endpoints should be written to the interpolation marker in the frame header. When splicing slices across segments, it is important to note that slices should be read in ascending order of segment number; reverse reading is prohibited. If a slice covering a segment is covered by a pre-hit, the slice is invalid and will not be counted in the valid sample size. .

[0082] In engineering implementation, segmented files are preferably memory-mapped files and written sequentially. To ensure consistency, edge-side inference nodes first write the segment body and then atomically update the termination timestamp and checksum in the segment header to avoid reading half-written intervals.

[0083] Data frames are constructed using monotonic timestamps by edge-side inference nodes and written to the production stream circular buffer in segment header / segment body order. Before overwriting, an overwrite forecast is written to the slice index ledger and the segment header is updated atomically.

[0084] This ensures that replay slices remain consistent across multi-channel time bases, resulting in comparable input sequences between candidate runtime and main inference runtime. Segment header checksums and atomic updates reduce the probability of half-written data being referenced. Overlay previews provide traceable reasons for slice eviction, facilitating gating uncertainty interpretation.

[0085] Furthermore, retaining only periodic segments may miss short-term shocks, while retaining only triggered segments will lose the normal distribution. To simultaneously cover typical operating conditions and triggered operating conditions, time slices and event slices are generated, and the slice index ledger is used to link the slices with the release list fingerprints. Association ensures that replay sampling of the same candidate version has a unique entry point.

[0086] Time slices are extracted at fixed intervals, with the window length preferably being an integer multiple of the main inference feature window length to avoid boundary clipping. The window length of the time slice is preferably 2 to 20 seconds, more preferably 4 to 10 seconds, to cover multiple feature windows without increasing disk write pressure. The extraction period of the time slice is preferably less than the window length, allowing adjacent time slices to overlap, so that gaps can still be filled in the next slice if playback inference is preempted. Event slices are triggered by the output of the main inference runtime: when the alarm level reaches the trigger level and the interval between the previous trigger and the previous trigger exceeds the trigger suppression time, the edge-side inference node backtracks the pre-trigger window in the production flow ring buffer and expands the subsequent trigger window to form an event slice, and writes the trigger cause code and trigger time mark in the slice header. The pre-trigger window of the event slice is preferably 0.5 to 5 seconds, and the subsequent trigger window is preferably 1 to 15 seconds. The pre-trigger window is used to retain the gradual features before triggering, and the subsequent trigger window is used to retain the decay or continuous vibration segment after triggering, so that the gating evaluator can locate the time period of difference within the same slice. The trigger suppression time varies with the resource level: when the resource level rises, the suppression time is increased to reduce disk writing pressure, and it returns to the baseline value after the resource level recovers.

[0087] The slice index ledger uses append-only writing, and each record must contain at least the slice number, slice type, start and end timestamps, segment number range, slice header checksum, and publication list fingerprint. Regarding retention levels: When the storage water level approaches the gating boundary, the time slice retention level is first lowered and overwriting is allowed, while the event slice retention level remains unchanged; only when it continues to rise is the event slice retention level lowered, and the eviction reason code is written to the ledger. After enqueuing in step one, the edge-side inference node will use the release list fingerprint from the tokens in the queue to be verified. Write the index header to form a token-slice sequence link. Before replaying in step two, you only need to read the index header to locate the slice range of this candidate version.

[0088] Time slices are generated periodically by edge-side inference nodes, and event slices are triggered according to alarm levels. The slice index ledger is appended with the slice sequence number, type, start and end timestamps, and release list fingerprint. The data is categorized by retention level and phased out according to storage level, with a grading reason code written to each category. Both types of slices cover typical and triggering conditions, and the playback sample pool more closely reflects the on-site input distribution. The slice index ledger uses a published list fingerprint. Binding slice sequences reduces the risk of slices being misused for other candidate versions. Tiered elimination and reason codes make insufficient samples traceable, facilitating subsequent confidence constraint judgments.

[0089] The goal of replay inference is to identify risks in candidate versions, rather than to consume resources and cause delays in main inference alerts. To this end, a budget pressure index is used to measure how close the main inference is to the budget limit. When the pressure index reaches the threshold, the candidate version is immediately preempted from execution, and the reason for stopping is written to the evidence snapshot.

[0090] The budget stress index employs a logarithmic barrier, causing the penalty to increase rapidly as observations approach their upper limit.

[0091]

[0092] Where: Budget pressure index : A non-negative real number, representing the degree to which the main inference approximates the budget boundary; the percentile of the main inference delay. : Positive real number, representing the percentile observation of time delay within the main inference statistical window; during the main inference run, start and end monotonic timestamps are recorded at the end of each inference iteration to obtain a single inference time delay sample; a sliding window is used, with a window length ranging from 1 to 30 seconds; the window stores a sequence of time delay samples or a histogram. Optionally, a cumulative histogram distribution can be used for approximation, or the t-digest or P² algorithm can be used to approximate the percentile calculation; subscript This is the percentile parameter, and its value range is... As specified in the configuration.

[0093] Latency Budget Cap : A positive real number, representing the upper percentile of allowed main inference latency; the main inference processor's occupancy. : Positive real number, representing the CPU usage observation within the main inference statistics window; reads the CPU time increment during the main inference runtime within the statistics window from the container runtime or cgrup, and divides it by the window wall clock time and the number of available cores to obtain the usage ratio; if it cannot be read, it is marked as a missing observation and candidate validation is paused.

[0094] processor usage limit : Positive real number, representing the maximum allowed processor usage; main inference memory level. : Positive real number, representing the observed value of storage usage relative to the quota; upper limit of storage level. : Positive real number, representing the upper limit of allowed storage level; taking the partition or quota where the production flow circular buffer is located as the object, read the used bytes and quota bytes and take the ratio; at the same time, read the cumulative usage of the slice index ledger and the evidence chain log for diagnosis.

[0095] logarithmic function The natural logarithm function, defined on the domain of positive real numbers; forms a barrier term in this expression, causing the term value to increase rapidly as the fraction approaches 1; when or or At that time, the budget pressure index This is considered reaching the threshold and triggering a preemptive stop; to avoid numerical overflow, a minimum positive number can be introduced when calculating the fraction. ,Will Lower limit truncation is .

[0096] To ensure the budget pressure index The observations are stable, and the principal inference delay percentile is [not specified]. The statistics window is consistent with the main inference resource sampling window. The optimal statistics window is 1 to 30 seconds to prevent frequent preemption triggered by short-term spikes, while still reflecting load increases promptly as the clock speed changes. Main inference processor usage... With the main inference storage level It is preferable to read from the shared memory counter of the main inference runtime or the export interface of the container runtime. If the read fails, the gating evaluator marks the slice as missing observation and pauses the replay inference to avoid continuing to occupy resources under the condition of observation distortion.

[0097] When the budget pressure index When the data is below the budget threshold, edge-side inference nodes are allowed to read the next slice in slice index ledger order and by release list fingerprint during runtime. After aligning the preprocessing and feature extraction processes, inference is performed, outputting candidate warning scores and candidate alarm levels. If the candidate attempts to reuse the main inference feature vector during runtime, the feature calculation configuration fingerprint and the release list fingerprint must be verified first. The configuration fingerprint must be consistent; otherwise, a recalculation will be forced and the evidence snapshot will be marked as unused.

[0098] When the budget pressure index When the threshold is reached or any observation reaches its upper limit, the edge-side inference node first triggers storage bandwidth limiting and then sends a stop signal to the candidate runtime, pausing slice reading and sending the current slice number, stop reason code, and budget pressure index. The observation summary is written into the evidence snapshot. Candidate runtime processes have lower priority than the main inference runtime, and processor and storage bandwidth quotas are configured separately. Slice reading is performed sequentially across segments, and reverse reading is prohibited to ensure that the playback input sequence is in the same order.

[0099] The budget pressure index is calculated through edge-side inference nodes. Based on this, the candidate runtime replay reasoning is scheduled, and when the threshold is reached, preemption stops and the stop reason code, slice number, and other parameters are recorded. To the evidence snapshot, and simultaneously publish the list fingerprints Constraint feature reuse consistency. This allows candidate replay inference to give way to main inference, reducing interference from replay verification on alarm output. Preemption stop reasons are fixed, facilitating the distinction between budget insufficiency interruptions and candidate degradation rejections. Feature reuse is influenced by the release list fingerprint. Constraints reduce pseudo-degradation introduced by configuration inconsistencies.

[0100] Drawing conclusions prematurely when there is insufficient evidence can easily lead to misjudgment, while accumulating evidence for too long can delay the entry into step three. By constraining the gated decision with the minimum sample size and gate confidence level, and limiting the conclusion to three states: pass, reject, and uncertain, sampling can continue even when evidence is insufficient without disrupting the consistency of the process.

[0101] Gated evaluator to publish inventory fingerprints To aggregate and replay the evaluation results, at least three types of entries are generated for each slice: alarm mutation entries, output drift entries, and critical alarm consistency entries. Each entry is written with the slice number, the time period of the difference occurrence, and the first inconsistency timestamp, and is appended to the gating evaluation ledger.

[0102] The effective sample size is defined as the number of slices that have been evaluated and have not been preempted. Preempted slices are not counted in the effective sample size, but their stop reason codes and slice numbers are recorded in the ledger for traceability. The gating confidence level increases with the saturation of the effective sample size, where:

[0103]

[0104] Where: Gating confidence level A real number between 0 and 1, representing the degree of evidence saturation; effective sample size. : A positive integer, representing the number of slices that were not preempted and completed the evaluation;

[0105]

[0106] Gating confidence threshold A real number between 0 and 1, used to limit the minimum evidence saturation at which an output is allowed to pass or reject; minimum sample size threshold. : A positive integer representing the minimum number of valid samples required to make an irreversible gating decision; saturation sample size Saturated sample size Positive real numbers, used for control Follow The speed of growth; by and The derivation yields the result, which is used to make exist Time to reach ;

[0107] Specifically, the gating evaluator updates the gating confidence level for each new valid sample. When the gate confidence level If the gated confidence threshold is not reached, only "uncertain" can be output along with a statement indicating insufficient evidence; when the gated confidence level is reached... When the gating confidence threshold is reached, the entries are checked for triggering in a fixed order: If a critical alarm consistency entry shows inconsistencies, a rejection is triggered first; if an alarm mutation entry shows a continuously rising alarm level, a rejection is triggered; if output drift entries on multiple time slices remain in the same order and critical alarm consistency entries are not triggered, passage is allowed; otherwise, the output is uncertain and sampling continues, with sampling priority determined by the slice retention level, prioritizing event slices before time slices. Gating conclusion, gating confidence level. Effective sample size The summary of the most serious item and the corresponding slice number range together constitute an evidence snapshot, which is then appended to the audit log so that step three can still be read when the network is disconnected.

[0108] To facilitate subsequent verification, the evidence snapshot should include not only a summary of the most severe item, but also a marker indicating the percentage of slice types covered by this gating assessment and the number of preempted slices. This will enable step three to distinguish between insufficient event slices and insufficient time slices. During the engineering verification phase, gating misjudgment rate, gating waiting time, number of preemptions, and number of triggers of key alarm consistency items can be used as evaluation indicators. The evaluation should be conducted using the same release list fingerprint. The candidate versions are used as objects to run the replay verification process under three boundary scenarios: window switching is prohibited, load surge, and long-term network outage. The comparison process can be set to disable preemption or fix forced passage to compare the source of gate control misjudgment, and then check whether the gate control assessment ledger and audit records can completely reproduce the formation path of the gate control conclusion.

[0109] Release list fingerprint via gate evaluator Aggregate slice entries to maintain effective sample size And calculate the gating confidence level. ,exist Once the gate confidence threshold is reached, output either pass or reject in the fixed order; otherwise, output indeterminate and write the gate conclusion and the summary of the most severe item into the evidence snapshot and append it to the audit log.

[0110] When used, the three-state conclusion avoids irreversible decisions when evidence is insufficient, ensuring the process can continue rather than being forced to switch. Gating confidence level. With effective sample size The evidence is captured in a snapshot, which can be used in step three to determine the adequacy of the gating and decide whether to continue sampling. The item summary and slice number range can be verified, facilitating on-site tracing and the explanation of the causal chain in subsequent invalidity defenses.

[0111] Therefore, edge-side inference nodes locate the slice sequence using the tokens in the queue to be verified, first completing write alignment and segmentation disk generation in the production flow circular buffer and generating the slice index ledger, and then... (The sentence is incomplete and ends abruptly, likely due to an incomplete or corrupted source text.) When allowed, candidate runtime is driven to replay inference sequentially, and finally the gating evaluator evaluates the gating confidence. Upon reaching the gating confidence threshold, a three-state gating conclusion is output and an evidence snapshot is fixed. In addition to piecewise linear interpolation, monotonic spline interpolation can also be used for order-preserving point supplementation; in addition to sequential log files, the slice index ledger can also be implemented using embedded database files.

[0112] Therefore, candidate versions do not face the risk of alarm mutations or inconsistencies in critical alarms in actual production inputs before entering step three; replay inference is not preempted or stopped within budget boundaries and does not affect the alarm output of the main inference; gating conclusions and evidence snapshots are published via list fingerprints. The information is written into the audit log so that subsequent triggers and reviews have the same source of evidence.

[0113] Step 3: In step 2, provide the gating conclusion and the gating confidence level. Under the condition that the gating confidence threshold is reached, the candidate version is advanced to online shadow verification and small-scale switching, and local atomic rollback or freeze and downgrade security state is executed according to the rollback trigger set in the self-check window, so that the early warning link remains recoverable under weak network and abnormal load.

[0114] Step two completes replay inference based on time slices and event slices. However, the replay evidence cannot cover the arrival rhythm changes of the online input stream, the parallel contention between the main inference runtime and the candidate runtime, and the buffer congestion when the triggering event switches to an adjacent operating condition. If the candidate version is switched to a full version directly, any alarm level jitter or critical alarm omission will spread to the entire group of devices in a short period of time. Industrial sites also have situations where the allowable switching window is short, and network outages and weak networks are common. The cloud side cannot guarantee that rollback commands will be issued at any time.

[0115] Therefore, step three involves publishing the list fingerprints. Locking in candidate versions and inference pipelines, based on budget pressure index Constrain shadow validation occupancy to achieve effective sample size and gate confidence To constrain the sufficiency of shadow evidence, a dual-slot atomic switching and rollback trigger set is used to complete the switching rollback in a closed loop at the edge side.

[0116] The core of online shadow verification is to allow candidate runtimes to perceive the real input stream without altering the reading rhythm of the main inference runtime. Directly copying all inputs via shadow copying incurs read / write pressure; if different preprocessing orders are used, input differences will be treated as model differences. Therefore, limiting shadow input copying to controlled sampling and publishing list fingerprints are crucial. Align the candidate runtime inference pipeline. This makes the source of shadow evidence interpretable.

[0117] Edge-side inference nodes establish shadow copy points at the input buffer exit of the main inference runtime. These shadow copy points read data frames with completed timestamp alignment and perform sampling checks. Sampling checks are preferably performed at fixed interval frame numbers to ensure uniform distribution of shadow inputs along the timeline. When the main inference runtime enters the time segment corresponding to an event slice, the shadow copy points temporarily increase the sampling density. After the event ends, sampling at fixed interval frame numbers is restored, and the density switching reason code is written to the shadow evidence snapshot. Before receiving shadow inputs, candidate runtimes must verify the inference pipeline configuration fingerprint and the release manifest fingerprint. The configuration fingerprint must be consistent with the configuration fingerprint in the shared memory; if the consistency check fails, the candidate runtime stops inference and returns the index of inconsistent fields. If the candidate runtime uses the feature reuse path, the feature extraction configuration fingerprint and the release manifest fingerprint must be checked before reading the feature vector from shared memory. If consistent, switch to the local recalculation path and mark the recalculation path in the shadow evidence snapshot if inconsistent.

[0118] Shadow copying points preferably use a single-producer, single-consumer circular queue: during the main inference runtime, references and timestamps are written, and during candidate runtime, the corresponding segments are read from the production stream's circular buffer by reference, thereby reducing memory copying; if direct copying of data frames is used, the copying overhead is included in the budget pressure index. The observation interface ensures that shadow verification can be preempted.

[0119] In this process, edge-side inference nodes establish shadow copy points and sample according to fixed frame numbers. During the event slice time period, the sampling density is increased to record the cause code, and the candidate runtime uses the release list fingerprint. After verifying the consistency of the inference pipeline, shadow input is received. If the feature reuse is inconsistent, the recalculation path is used to write the shadow evidence snapshot.

[0120] Shadow input inheritance timestamp alignment and controlled sampling rhythm prevent shadow verification from disturbing the main inference execution rhythm; configuring consistency constraint chains and recalculation path markers can explain shadow evidence and reduce spurious degradation. Shadow replication points and budget pressure index. The observation interface is bound, and shadow verification does not occupy edge-side inference node resources.

[0121] Furthermore, the output sequence generated by online shadow verification is continuous and relatively long. If only the preceding sequence is retained, it is impossible to determine whether the switching conditions are met within the allowed switching window. Converting shadow evidence into an item summary allows for a smaller, more effective sample size. and gate confidence Constrain shadow gating conclusions to ensure that the conclusion generation process is verifiable and can be generated sequentially with step two. The gating evaluator publishes list fingerprints. A shadow evaluation ledger is established for the key. For each shadow input, the gated evaluator reads the main inference alarm level and candidate alarm levels at the same timestamp alignment point to form an alignment entry. The alignment entries are aggregated into an entry summary by window: if the main inference alarm level is stable but the candidate alarm level changes multiple times, an alarm mutation summary entry is generated; if the main inference triggers an event slice but the candidate does not show the same level increase, a critical alarm consistency summary entry is generated; if the candidate warning score continues to rise while the main inference remains stable, an output drift summary entry is generated.

[0122] Effective sample size Count the number of aggregated entry summaries and use the gating confidence from step two. Calculate configuration and saturation sample size Ensure gate confidence The unique mapping. The gating evaluator in gating confidence. If the gate confidence threshold is not reached, the output is uncertain and sampling continues; when a critical alarm consistency summary entry is triggered and the gate confidence level is reached... When the gating confidence threshold is reached, output rejection and freeze candidate versions; when neither entry summary is triggered and the gating confidence is reached... The output passes when the gating confidence threshold is reached. Shadow gating conclusion, gating confidence level. Effective sample size Summary of the most severe items and the most recent budget stress index The observation summaries together constitute a snapshot of shadow evidence and are appended to the audit log; when shadow verification is preempted and stopped, the shadow gating conclusion remains uncertain and the preemption stop reason code is written, allowing evidence to continue to accumulate in the next allow switching window.

[0123] By using the gated evaluator to publish inventory fingerprints Establish a shadow evaluation ledger, align entries by timestamp, and aggregate them into an entry summary using a window, retaining the effective sample size. With gate confidence The unique mapping updates the shadow gating conclusion, and the shadow gating conclusion and gating confidence are then... Effective sample size Item Summary and Budget Stress Index The observation summary is solidified as a shadow evidence snapshot and appended to the audit log.

[0124] When using item summaries, the continuous output is compressed into interpretable evidence, making it easy to locate the time period of difference occurrence within the allowed switching window, and to gate the confidence level. With effective sample size By connecting steps two and three, the shadow gating conclusions can be sequentially linked; preemption stops maintain uncertainty and solidified cause codes, and shadow verification continues from breakpoints without misjudging switching conditions.

[0125] Furthermore, the shadow gating conclusion indicates that even after passing the checkpoint, the switching range still needs to be limited; otherwise, differences in device groups will amplify load fluctuations. Therefore, a small range of objects is first limited, and then the online traffic pointer is switched using a dual-slot atomic switching mechanism, ensuring that both switching and rollback can be completed independently at the edge.

[0126] The edge-side inference node maintains a first slot carrying known stable versions and a second slot carrying candidate versions. Known stable versions are identified by the rollback target version identifier in the token to be verified in step one, while candidate versions are identified by the release manifest fingerprint. Unique positioning. The dual-slot atomic switching mechanism is implemented through a flow pointer file: writes use atomic replacement, and the main inference runtime reads only the flow pointer file to determine the currently active slot. A small-scale object list is written to a shadow evidence snapshot by the gating evaluator, including at least the device group identifier or input route branch identifier. Before the switch, the edge-side inference node recalculates the gating violation. In the case of gate control violation Budget pressure index is 0. When the threshold and shadow gating conclusion are passed, a small range of objects are switched and a switch event log is generated; the switch event log must contain at least the release manifest fingerprint. A small list of objects and the start timestamp of the switch are compiled and written to the audit log.

[0127] As a supplement, atomic replacement of the flow pointer file can be implemented using atomic renaming within the same directory; during the switch, a temporary pointer file is first written and a checksum is completed, then the official pointer file is replaced with an atomic rename; during the main inference runtime, only the official pointer file is read, and if the read fails, it falls back to the first slot. Freeze flags and known stable version identifiers are stored in a dedicated key space in local persistent storage, with freeze flags taking precedence over tokens in the verification queue; when a freeze flag exists, step one rejects fingerprints from the same release manifest. Joining the team.

[0128] The device grouping identifiers for small-scale objects can be issued by the production line management system or generated by the edge-side inference nodes based on the field topology, and are applicable to edge gateway devices with equivalent functions. The size of the small-scale object list is preferably controlled within a range that a single edge-side inference node can independently observe: when a node serves multiple devices, the small-scale object list should preferably include one device initially and then expand to two to five devices after the self-test window ends; when a node serves only a single device, the small-scale object list should preferably include one input routing branch of that device rather than all channels, further limiting the impact of the switchover. The reason for this range selection is that an excessively large small-scale object list will expand the impact area after the rollback trigger set is hit, while an excessively small list may fail to cover typical operating condition changes, making it difficult to close the shadow evidence and self-test evidence.

[0129] The edge-side inference node maintains the first and second slots and implements an atomic switching mechanism for the two slots by atomically replacing the flow pointer file. The gating evaluator outputs a small list of objects, and the edge-side inference node performs gating violation checks. Zero and budget pressure index If the threshold is not reached and the shadow gating conclusion is "pass", only a small range of objects will be switched and a switch event record will be generated and written to the audit log.

[0130] In use, the switching is limited to a small range of objects, and the risk of candidate versions is localized, preventing it from spreading to all devices at once. Atomic replacement of the traffic pointer file allows both switching and rollback to be completed at the edge, and weak or disconnected networks do not hinder recovery. Switching event logs and shadow evidence snapshots are used to publish manifest fingerprints. This association provides a consistent starting point for determining the self-inspection window.

[0131] After a small-scale switch, the candidate version will face continuous operational fluctuations; the self-inspection window is used to expose and roll back risks within a limited time. The rollback trigger set covers system-level, business-level, and consistency-level triggers, and the early warning link is ensured by local atomic rollback, freeze strategies, and degraded security states.

[0132] The self-test window starts from the switchover start timestamp. The optimal length of the self-test window is 2 to 60 minutes, more preferably 5 to 30 minutes. This is because the lower limit covers a short-term fluctuation, while the upper limit avoids occupying an excessively long maintenance window. System triggers use the budget pressure index. Observation interface: When the budget pressure index A rollback is triggered when the threshold is reached and persists. Business-related triggers are continuously summarized by the gating evaluator: a rollback is triggered immediately upon triggering a critical alarm consistency summary entry; an alarm mutation summary entry that appears repeatedly within the self-check window and has a gating confidence level... A rollback is triggered when the gated confidence threshold is reached. To avoid erroneous rollbacks due to insufficient evidence, a sufficient sample size must be met before business-related triggers are activated. The minimum sample size threshold for self-testing is reached, and this threshold is close to the saturation sample size. Use units of the same dimension.

[0133] Consistency triggers are used to capture version drift: periodically verifying the release manifest fingerprint of the traffic pointer file. Release manifest fingerprint of candidate runtime reports Consistency is paramount; any inconsistency triggers a rollback. The rollback operation employs a local atomic rollback: the edge-side inference node performs an atomic replacement of the traffic pointer file, switches the active slot from the second slot back to the first slot, and generates a rollback event record within the same append write transaction. The rollback event record must at least contain the release manifest fingerprint. Trigger type, summary of the most severe entry corresponding to the trigger time, and current gating confidence. Effective sample size and budget pressure index The observation summary allows the rollback cause to be recovered during the audit aggregation in step four. After the rollback is complete, the edge-side inference node generates a freeze marker and persists it to local persistent storage. The freeze marker contains at least the release manifest fingerprint. Trigger type and freeze timestamp; during the freeze period, edge-side inference nodes reject the same release list fingerprint. The re-entry request prevents candidate versions from repeatedly switching when the same defect remains uncorrected.

[0134] When a pointer file verification fails during rollback, the main inference runtime fails to recover alarm output after rollback, or the number of consecutive rollback failures reaches a preset threshold, the edge-side inference node enters a degraded security state. In degraded security state, the edge-side inference node stops candidate runtime but maintains continuous operation in the first slot, limits alarm output to only high-level alarms, reverts the sampling density of shadow copy points to a low density of fixed-interval frame number sampling, and suspends new small-scale switching actions. Upon entering degraded security state, a security state event record is generated and appended to the audit log. The security state event record must at least contain the release manifest fingerprint. Entry reason code, entry timestamp, and current gate violation degree The value of . The release of the safe state requires satisfying the gating violation. If the number remains zero and maintenance personnel confirm on-site that network connectivity has been restored or resource quotas have been released, the cloud-side release management node will then issue a new release list fingerprint. Re-enlist; the corresponding delisting action generates a delisting event record and appends it to the audit log.

[0135] Specifically, the record fields related to rollback and safe state should maintain a fixed order and be in the same release manifest fingerprint. The rollback event logs, freeze flags, and safe state event logs can be replayed in sequence by timestamp.

[0136] Among them, the edge-side inference node monitors system-type triggers, business-type triggers, and consistency triggers within the self-inspection window. System-type triggers are based on the budget pressure index. Business-related triggers use gating confidence levels With effective sample size Constraint triggering, consistency triggers to publish inventory fingerprints Consistency check is triggered; when any trigger is hit, the flow pointer file is atomically replaced back to the first slot and a rollback event record is generated, and a freeze flag is generated at the same time; when the rollback is abnormal or the number of consecutive rollback failures reaches the threshold, the system enters a degraded safe state and a safe state event record is generated.

[0137] When in use, the self-test window limits the risk after switching to a certain period of time. If the trigger is hit, it will roll back to the known stable version. The trigger causes cover three categories: system load, warning behavior, and version inconsistency. The rollback reasons are explainable and verifiable. The freeze mark and downgraded security state will repeatedly fail and be transformed into a manageable state, and no more switching will be required.

[0138] Therefore, in step three, under the constraint of the budget pressure index, the online shadow verification is solidified into a snapshot of shadow evidence. Under the condition that the gating violation is 0 and the shadow gating conclusion is passed, the dual-slot atomic switch of a small range of objects enters the self-test window. In the self-test window, the local atomic rollback is executed according to the rollback trigger set, freezing the candidate version or entering the degraded security state.

[0139] Step 4: Transform the final state and event chain from Step 3 into traceable, reproducible, and batch-manageable evidence chain logs and cloud-side audit aggregation records, and output compliance judgments, promotion or isolation decisions and parameter window suggestions as the baseline for the next round of candidate versions.

[0140] Step three has already limited the candidate versions to a small range of objects through a dual-slot atomic switching mechanism and generated switching event records, rollback event records, freeze flags, and safe state event records within the self-check window. However, if these records only remain in scattered logs, it will be difficult to reconstruct who switched, when, with which version, under what gating conditions, why rolled back, whether there was a network outage, and whether a safe state was entered in a multi-node batch production scenario. In addition, weak networks and network outages will prevent cloud-side release management nodes from obtaining the state machine path of edge-side inference nodes in a timely manner. If there is a lack of verifiable evidence chain logs, the cloud side may promote batch deployment based on incomplete information, introducing uncontrollable risks. Therefore, step four first writes the cause vector into the evidence chain log on the edge side and maintains sequential consistency using a hash chain. Then, on the cloud side, integrity verification, event replay, and compliance judgment are performed on the retransmitted data, making rollback possible in large-scale deployments, thus transforming rollback into auditability, reproducibility, and governance.

[0141] The cause vector is the key carrier that transforms switchover, rollback, and safe state from text logs into searchable records. Defining the cause vector as a fixed set of fields allows each record to be represented by a release list fingerprint. Associated with candidate versions, and by gating violation Budget pressure index Gating confidence Effective sample size A priori explanation is needed to determine why the state machine advances or regresses.

[0142] The field set of the cause vector should at least include: event type field, event timestamp field, and release manifest fingerprint. Fields, First Slot Version Identifier Field, Second Slot Version Identifier Field, Small Scope Object List Field, Trigger Type Field, Most Severe Item Summary Field, Gated Violation Degree Fields, Budget Pressure Index Fields, gate confidence Fields, effective sample size Fields, rollback target version identifier field, freeze flag status field, and security status field.

[0143] The field set must be normalized before being written to disk: the timestamp is a monotonic timestamp plus a clock source identifier; the small-range object list is sorted by device group identifier or input route branch identifier and then serialized; the trigger type field has a pre-defined enumeration code; and the summary of the most serious entry is a combination of slice number range and entry type code to avoid synonyms in free text descriptions.

[0144] To prevent the cause vector from drifting in field meaning between the event records in Step 3, the edge-side inference node strictly references the original fields from the switch event records, rollback event records, and safe-state event records in Step 3 when generating the cause vector. The original fields are written into the cause vector header using a source field index, enabling the cloud-side release management node to locate the original source during event replay. The normalized byte sequence generation rule for the cause vector maintains the same encoding system as the normalization rule for the immutable release list in Step 1, ensuring a consistent field sequence that can be recalculated across different file systems and character sets. The cause vector is written to the evidence chain log using append-only writing. Before appending, the sequence number and termination timestamp of the previous record are read and written into the header of the current record, forming a replayable order.

[0145] Among them, the edge-side inference node encapsulates the cause vector with a fixed set of fields and uses the published list fingerprint. Gating violation Budget pressure index Gating confidence Effective sample size In step three of the field mapping process, the event chain and cause vector are standardized according to unified encoding and sorting rules and then written to the evidence chain log in an append-only manner, carrying the source field index.

[0146] In use, the cause vector field is fixed and searchable, and the cloud-side release management node can summarize the state machine path of the same candidate version based on the release list fingerprint. The source field index binds the cause vector to the original event record, reducing interpretation ambiguity caused by field drift; the append write and sequence header methods make the evidence chain log inherently have a replayable sequence, which can be used to restore events after network outages and retransmissions.

[0147] Furthermore, if the evidence chain log is only appended to without an anti-tampering mechanism, it may be accidentally deleted or overwritten during network outages, making it difficult for the cloud side to determine the integrity of the records. This allows for the reuse of the hash function operator from step one without introducing an additional symbol system. The hash function operator For deterministic mapping, the input byte sequence is mapped to a fixed-length digest. Edge-side inference nodes concatenate the normalized byte sequence of each cause vector with the digest of the previous record to calculate a record digest, which is then written to the end of the evidence chain log, forming a hash chain. To reduce write amplification, the evidence chain log is rolled by segments: each segment contains a fixed number of records, with the segment header containing the segment start digest and segment number, and the segment tail containing the segment end digest and the record count within the segment. The segment size is preferably 64KB to 4MB, more preferably 256KB to 2MB. This is because the lower limit facilitates rapid disk writes and reduces the loss window during network outages, while the upper limit avoids excessively large segments leading to high retry costs due to failed retransmissions.

[0148] For network outage retransmission, a retransmission retry queue is used. After step three of the edge-side inference, the edge-side inference node writes the list of segments to be retransmitted to local persistent storage. The list records the segment number, segment start and end timestamps, segment end summary, and local file offset. The retransmission retry queue adopts a two-level queue structure: the first queue stores segment metadata, and the second queue stores segment data blocks. When the network is available, the metadata is sent first, and the node waits for the cloud-side publishing management node to return the segment receiving window. Then, data blocks are sent in fragments according to the window size. The fragment size is preferably 4KB to 256KB, and more preferably 16KB to 64KB, so that retransmission can still proceed on low-bandwidth links. The retransmission retry interval is preferably 10 seconds to 300 seconds, and more preferably 20 seconds to 120 seconds. When the number of consecutive failures increases, the interval is increased exponentially by backoff, with a backoff limit of no more than 3600 seconds, to avoid frequent retries consuming network resources. Each retransmission failure must be written with a retransmission failure reason code, which must distinguish at least four categories: network unreachable, cloud-side rejection, segment verification failure, and local read failure. If the reason for the failure to re-transmit is that the paragraph verification failed, the edge-side inference node will mark the paragraph as requiring manual review and freeze the automatic update to prevent the continued batch promotion under the condition that the evidence chain is not credible.

[0149] The edge-side inference node concatenates the normalized byte sequence of the cause vector with the digest of the previous record and then uses a hash function operator. Calculate record summaries and form hash chains. The evidence chain log is rolled in segments from 64KB to 4MB and the segment termination summary is written to local persistent storage. When the network is disconnected, maintain a list of segments to be retransmitted and retransmit them in segments using a retransmission retry queue. The segment size is from 4KB to 256KB and the retransmission retry interval is from 10 seconds to 300 seconds with exponential backoff. The failure reason code is written to the audit log. If the segment verification fails, it will trigger a freeze and automatic update.

[0150] Using hash chains and paragraph summaries allows the cloud side to determine whether paragraphs have been tampered with or are missing, providing reliable input for audit aggregation; fragmented retransmission and exponential backoff ensure that retransmission in weak network conditions does not occupy links, paragraph verification failures are automatically updated, and unreliable evidence is transformed into a controllable downtime point rather than a hidden risk.

[0151] If the cloud-side release management node receives the retransmitted segments and then directly aggregates them without performing integrity verification, it might treat missing segments as no events, thus misjudging the stability of the candidate version. Therefore, integrity should be verified segment by segment using the segment termination digest and hash chain, and then the release list fingerprint should be used. Replay the event sequence, and finally base it on the degree of gating violation. Budget pressure index Gating confidence The criteria for compliance are determined in conjunction with the trigger type, ensuring that the basis for the determination is verifiable.

[0152] The cloud-based release management node first verifies the paragraph metadata: the continuity of paragraph numbers, the monotonicity of paragraph start and end timestamps, and the matching of the paragraph termination summary with the record count within the paragraph. Then, it reads the record summary of each record within the paragraph, recalculates it in record order, and compares it with the record tail summary. If any discrepancy occurs, the paragraph is marked as unusable, and a paragraph verification failure reason code is returned. Only records that pass paragraph verification proceed to event replay. Event replay uses the release list fingerprint. For indexing: The cloud side uses the fingerprint of the same release list. The records are sorted by event timestamps, and the state machine phases defined in step three are used as constraints to check whether the event sequence satisfies the following order: shadow evidence snapshot before switch event record, switch event record before rollback event record or solidified event record, and freeze marker and safe state event record can be inserted but must not cross the order after rollback event record. If a violation of the order is found, the list fingerprint is published. Marked as requiring manual review and its promotion blocked.

[0153] The compliance determination rules adopt a combination of hard thresholds and soft consistency. The hard thresholds include: gate violation degree. The threshold must be zero to indicate that the engineering / compliance gating has not been violated; if a safe-state event record appears in the log, it is directly judged as non-compliance; if a rollback event record appears in the log and the trigger type is a critical alarm consistency trigger, it is judged as non-compliance. Soft consistency is used to handle uncertainty and preemption: if the gating confidence level is zero... The gate confidence threshold was not reached and the effective sample size was not met. If the minimum sample size threshold for self-inspection is not met, it is judged as pending observation and further collection of shadow evidence is required; if the budget pressure index If the preemption stop reason code is triggered multiple times, it will be judged as resource-constrained, and adjustments to the maintenance window or resource quota will be required before further evaluation. The compliance determination result will be written into the audit aggregation record, which must at least contain the release list fingerprint. The following are the criteria for determining compliance status, trigger summary, paragraph verification status summary, and list of supplementary evidence items:

[0154] Specifically, the cloud side can simulate network disconnection and reconnection in the test environment: disconnect the connection between the edge-side inference node and the cloud-side release management node, check whether the retransmission retry queue is filled according to the paragraph number, and whether the event replay restores the rollback event record and freeze mark. The evaluation indicators include at least the paragraph verification pass rate, event replay success rate, consistency of the standard judgment, and number of manual reviews.

[0155] The cloud-side release management node verifies the integrity of each re-uploaded segment by segment based on the continuity of the segment number and the hash chain. Records that pass the verification are processed according to the release list fingerprint. The events are aggregated and replayed into a state machine sequence, and then gated by violation degree. Budget pressure index Gating confidence Effective sample size Perform a compliance determination using a combination of hard thresholds and soft consistency with the trigger type, and write the compliance determination result and paragraph validation summary into the audit convergence record.

[0156] In use, integrity checks prevent missing or tampered sections from entering the judgment process, reducing the probability of false judgments on the cloud side. Event replay is constrained by the state machine sequence, ensuring that compliance judgments are based on recoverable processes rather than single-point logs. Hard thresholds and soft consistency distinguish between resource constraints and insufficient evidence, facilitating subsequent adjustments to maintenance windows and sampling strategies.

[0157] The compliance determination is merely a conclusion; large-scale implementation requires translating that conclusion into action. Based on the compliance status, batch promotion or isolation decisions are generated, and the reasons for freezing and the required slice indexes or summaries for reproduction are solidified, allowing for verification of differences of the same candidate version across different edge-side inference nodes. Batch promotion employs a tiered expansion: from the small-scale objects in step three to other devices within the same device group, and then to other edge-side inference nodes on the same production line; each expansion references the audit aggregation record number of the previous expansion, ensuring traceability of the promotion chain. Isolation decisions fingerprint the release list of non-compliant devices. Write it to the quarantine list, which must contain at least the release list fingerprint. The freeze reason code, trigger summary, first discovery timestamp, and suggested review action; after the isolation list is issued to the relevant edge-side inference nodes, if the edge-side inference node discovers the release list fingerprint when the signature verification is passed in step one. Those on the quarantine list are frozen and refused entry to the queue to avoid repeated trial and error.

[0158] The reproduction summary is used to transform non-compliance from an abstract conclusion into reproducible input. The cloud-side release management node reads the slice number range from the summary of the most severe item in the audit aggregation records and generates the slice index or summary required for reproduction: the slice index includes the slice number, start and end timestamps, slice type, and segment number range; the slice summary carries the segment number and segment termination summary without carrying the original data, enabling field personnel to locate the corresponding segment and export the original slice at the edge-side inference node. If cross-plant area verification is required, the cloud side can only issue the slice index without issuing any data summary, thereby reducing cross-domain transmission.

[0159] The parameter window is recommended as a basis for the next candidate version verification to ensure that the next round of candidate versions better conforms to resource boundaries. The cloud-side release management node provides maintenance plans for the window and resource quotas based on the budget pressure index trigger frequency and retransmission retry failure reason codes in the audit aggregation records. If the budget pressure index reaches the threshold multiple times, it is recommended to reduce the shadow replication point sampling density to fixed-interval frame number sampling and shorten the self-check window length. If retransmission retry fails due to network unavailability, it is recommended to increase the segment scrolling frequency to make each segment smaller and to complete it faster after recovery. The above recommendations do not change the terminology used in steps one through three, nor do they change the values ​​in the parameter configuration file, ensuring that the system can be implemented under different production line conditions.

[0160] The cloud-based release management node generates tiered batch promotion or isolation decisions based on the compliance status. The promotion chain references the audit aggregation record number, and the isolation list includes the release list fingerprint. The freeze reason code is sent to the edge-side inference node for direct freezing in step one; simultaneously, the slice sequence range is extracted from the most severe entry summary to generate the slice index or summary required for reproduction, and based on the budget pressure index... It is recommended that the parameter window for the maintenance window and paragraph scrolling configuration, which is formed by the reason code for the retransmission failure, be written into the audit aggregation record.

[0161] When using it, the chain number is linked to the audit aggregation record, batch operations are traceable and can be rolled back by chain; the isolation list is moved to step one to block the source of the non-compliant candidate version, avoid repeated trial and error, and the slice index or summary is reproduced on site, and the reasons for non-compliance are transformed into locatable inputs to facilitate on-site review and repair.

[0162] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0163] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0164] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0165] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0166] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An edge-cloud collaborative fault prediction and early warning system for industrial equipment, characterized in that: include, The cloud side generates and signs an immutable release list containing model hashes and pipeline and threshold configuration fingerprints. After verification and signature at the edge side, the candidate versions are added to the verification queue and a release list fingerprint is generated through engineering / compliance gating. A production flow circular buffer is established at the edge and time slices and event slices are saved. The candidate runtime replays the reasoning under the permission of the real-time budget scheduler. The gating evaluator outputs the gating conclusion and evidence snapshot of pass / reject / uncertainty. When the gating conclusion passes, online shadow verification is performed and the online traffic pointer is switched using a dual-slot atomic switching mechanism during the small-scale switching phase. In the self-test window, the local atomic rollback or downgraded security state is executed by pressing the rollback trigger set. The cause vector is written to the evidence chain log and kept in order through the hash chain. It is cached locally when the network is down and retransmitted to the cloud audit aggregation service after the network is restored. After verification by the cloud side, the batch promotion or isolation decision is output. When the isolation occurs, the freeze reason and the slice index or summary required for reproduction are generated.

2. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 1, characterized in that: The immutable release list also includes dependency set fingerprints, compatibility vectors, validity periods, and rollback targets; after the signature verification is passed, the edge side performs consistency verification on the model hash and pipeline and threshold configuration fingerprints. The minimum audit record includes the release list fingerprint, engineering / compliance gating results, queuing timestamps, and candidate version identifiers.

3. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 2, characterized in that: The engineering / compliance gating verifies the security domain and window, compatibility vector, resource level, and network disconnection policy in a fixed order. If any verification fails, the edge side keeps the candidate version as a local cache and generates a delay reason containing the gating item identifier and sends it back to the cloud side, without entering the verification queue.

4. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 1, characterized in that: The production flow ring buffer consists of sequentially numbered segment files. Each segment file includes a segment header and a segment body. The segment header records the segment number, time range, channel set, and segment body checksum. Before overwriting the oldest segment, the edge side writes an overwrite forecast containing the segment number into the slice index ledger.

5. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 1, characterized in that: Time slices are generated using a fixed-period sampling window. Event slices are triggered when the online warning score reaches a threshold. The slice index ledger records the slice number, slice type, time range, and segment range.

6. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 5, characterized in that: The real-time budget scheduler uses the main inference latency percentile, main inference processor occupancy, and main inference storage level as budget observations. When the budget observations reach the real-time budget limit, the real-time budget scheduler interrupts the replay inference of the candidate runtime and writes the slice number and stop reason code into the evidence snapshot.

7. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 1, characterized in that: The gating evaluator performs minimum sample size constraints and gating confidence constraints when generating model risk gating reports. When the constraints are not met, the gating conclusion is output as uncertain and sampling continues. When the constraints are met and the model risk gating report meets the pass decision, the gating conclusion is output as pass. When the constraints are met and the model risk gating report meets the rejection decision, the gating conclusion is output as rejection, and a snapshot of the key indicators is written to the minimum audit record.

8. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 7, characterized in that: During the online shadow verification phase, the edge side copies the real-time input to the candidate runtime according to the controlled sampling ratio, and increases the controlled sampling ratio within the time range corresponding to the event slice. Before performing inference, the candidate runtime verifies the consistency between the pipeline and threshold configuration fingerprint and the release manifest fingerprint.

9. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 8, characterized in that: During the small-scale switchover phase, a small-scale object list is generated based on the device group identifier and written to the minimum audit record; the dual-slot atomic switchover mechanism updates the online traffic pointer file to point the online traffic pointer from the known stable version to the candidate version, and the update of the online traffic pointer file adopts atomic replacement writing.

10. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 9, characterized in that: The rollback trigger set consists of system triggers, business triggers, and consistency triggers. System triggers include latency percentile exceeding limits and resource level exceeding limits. Business triggers include alarm rate mutation and critical alarm consistency decline. Consistency triggers include release manifest fingerprint mismatch and dependency set fingerprint inconsistency. When any trigger is hit, a local atomic rollback is performed and the candidate version is frozen.

11. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 10, characterized in that: The downgraded safety state is entered when a rollback anomaly is detected after the rollback trigger set is hit. After entering, the candidate runtime is stopped and the main inference is run with rules and thresholds as a fallback. The controlled sampling ratio of the online shadow verification stage is set to zero and the update is locked.

12. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 1, characterized in that: The cause vector includes version fingerprint, gating conclusion, key indicator snapshot, state machine path, trigger hit record and rollback reason. The evidence chain log generates records in an append-only manner and maintains record order consistency with a hash chain; the evidence chain log is stored in a rolling manner.

13. The industrial equipment edge-cloud collaborative fault prediction and early warning system according to claim 12, characterized in that: When the network is down, the edge side writes the evidence chain log to the retransmission retry queue and segments it in block transmission mode. After the network is restored, the cloud side audit aggregation service verifies the integrity of the hash chain and makes a compliance judgment. If the compliance is met, it outputs a batch promotion decision. If the compliance is not met, it outputs an isolation decision and generates the reason for freezing and the slice index and summary required for reproduction.

Images