Edge computing and end-cloud cooperative high-altitude operation intelligent safety helmet data processing method

Abstract

This invention belongs to the field of high-altitude operation safety monitoring technology, and discloses a data processing method for intelligent safety helmets used in high-altitude operations based on edge computing and end-cloud collaboration. The intelligent safety helmet collects operation data to generate raw data frames. Edge computing nodes perform time alignment, missing data completion, and noise suppression on the raw data frames to form standard data frames. The standard data frames are segmented into events, and a first joint confidence score and a second joint confidence score are calculated. Supplementary sampling is performed on low-confidence candidate event segments. For candidate event segments that pass confidence gating, pre-defined discrimination and model discrimination are performed in parallel to obtain fused risk scores, risk levels, and consistency differences. The upload mode is determined based on the risk level, consistency difference, slope of change of fused risk scores, and link level. Cloud nodes perform spatiotemporal correlation, conflict resolution, and parameter updates, and perform event sequence summary consistency verification with edge computing nodes.

Description

Technical Field

[0001] This invention belongs to the field of high-altitude operation safety monitoring technology, specifically a data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration. Background Technology

[0002] High-altitude work sites are typically characterized by dispersed work locations, frequent personnel movement, and significant environmental disturbances. Smart safety helmets, serving as on-site monitoring terminals, usually integrate functions such as posture sensing, positioning, environmental detection, and personnel status data collection to identify, record, and report abnormal conditions during the work process.

[0003] In existing data processing solutions for smart safety helmets used for high-altitude operations, the common practice is to collect data such as angular velocity, acceleration, positioning, environmental parameters, and physiological parameters from the helmet tip, perform preliminary local processing, and then upload the data to the edge or cloud platform. The platform then completes event identification, alarm generation, and record management based on preset rules, threshold judgments, or model analysis. For scenarios with fluctuating transmission links, some solutions use local caching and delayed retransmission to maintain basic reporting. For situations where multiple terminals report simultaneously, the processing method of merging data by time or location is often adopted.

[0004] In actual high-altitude operations, multi-source data acquisition is prone to increased noise, partial missing data, time sequence misalignment, and quality fluctuations due to factors such as obstruction, vibration, short-term disconnection, and changes in terminal attitude. At the same time, the status of the on-site link may also be unstable in stages. Under the superposition of data quality fluctuations and link fluctuations, existing solutions often fail to produce stable, consistent, and traceable processing results for the same real event at the edge and in the cloud, thus affecting subsequent alarm handling and data utilization. Summary of the Invention

[0005] The purpose of this invention is to provide a data processing method for intelligent safety helmets used in high-altitude operations based on edge computing and end-to-cloud collaboration, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, this invention provides the following technical solution: Addressing the issues of data quality fluctuations, unstable network links, and a resurgence of false alarms after parameter updates in high-altitude work scenarios, this invention proposes a smart safety helmet data processing method based on edge computing and end-cloud collaboration. This method first completes data reliability screening at the edge, then performs risk assessment and hierarchical uploading, completes cross-node event correlation and parameter correction in the cloud, and returns the correction results to the edge for parallel verification and controlled switching, thereby forming a closed-loop data processing flow.

[0007] The present invention adopts the following technical solution The smart safety helmet collects work data according to the sampling period and generates raw data frames. The raw data frames contain frame sequence number, task identifier and timestamp. Edge computing nodes perform time alignment, missing data filling and noise suppression on the raw data frames to obtain standard data frames. The edge computing nodes perform event segmentation on the standard data frames according to the frame sequence number to obtain candidate event fragments.

[0008] For each candidate event segment, a first joint confidence score is first calculated. When the first joint confidence score is lower than the first confidence threshold, supplementary sampling is performed, and a second joint confidence score is calculated based on the supplementary sampling data. When the second joint confidence score is still lower than the first confidence threshold, the candidate event segment is marked as an invalid segment and risk discrimination is terminated. When the second joint confidence score is not lower than the first confidence threshold, risk discrimination is initiated.

[0009] The candidate event fragments that pass the confidence gating are subjected to parallel discrimination and model discrimination to obtain rule scores and model scores. Based on these scores, the fusion risk score, risk level and discrimination consistency difference are calculated. The edge computing node determines the upload mode based on the risk level, discrimination consistency difference, fusion risk score change slope and link level, and uploads the corresponding event data to the cloud node. The link level is determined by uplink rate and packet loss rate.

[0010] The cloud node performs spatiotemporal correlation and conflict resolution on event data uploaded by multiple edge computing nodes within the same work area, generates parameter update packages, and distributes them to the corresponding edge computing nodes. The edge computing nodes process the same event stream in parallel using the current parameters and the parameter update packages within the same verification sample window. When the updated parameters meet the switching conditions, the parameter update package is activated. When the updated parameters do not meet the switching conditions, the current parameters are maintained and the reason for the rollback and the corresponding indicators are reported. The switching conditions include at least the false alarm rate, the false negative rate, and the average discrimination latency being no worse than the current parameters.

[0011] Edge computing nodes and cloud nodes each generate event sequence summaries and perform summary consistency checks according to event identifiers. If the checks match, an early warning command is output; if the checks do not match, a retransmission and review are triggered. If the checks still do not match after reaching a preset limit of number of reviews, a manual review flag is output.

[0012] The beneficial effects of this invention are as follows: First, by using a two-level gating system with first and second joint confidence levels, low-confidence event fragments are isolated before risk assessment, reducing misjudgments introduced by missing and noisy data.

[0013] Secondly, by integrating rule-based discrimination and model-based discrimination in parallel, and using the discrimination consistency difference and link level together for upload mode decision-making, risk discrimination and transmission scheduling are coordinated to reduce the probability of missed transmission of critical events.

[0014] In addition, by using cloud-based correction, edge parallel verification, controlled switching, and rollback reporting mechanisms, the risk of performance regression caused by parameter updates is reduced, and the consistency and verifiability of event records between edge nodes and cloud nodes are improved through digest consistency verification.

[0015] To address the issues of misjudgment caused by noise and missing data in high-altitude operation scenarios, unstable uploading of critical events due to communication link fluctuations, and performance regression in judgment caused by online parameter updates, a smart safety helmet data processing method based on edge computing and end-cloud collaboration is proposed. This method completes data trust screening, risk identification, and hierarchical uploading at the edge computing node, completes cross-node event correlation, conflict resolution, and parameter correction at the cloud node, and performs parallel verification and controlled switching at the edge computing node, forming a closed-loop processing flow.

[0016] The smart safety helmet collects operational data and generates raw data frames according to a sampling period. Operational data includes angular velocity, linear acceleration, relative altitude, positioning coordinates, temperature, humidity, gas concentration, heart rate, and wearing status. Relative altitude is obtained by fusing barometric altitude and ranging altitude, and positioning coordinates are obtained by fusing satellite positioning coordinates and near-range positioning coordinates. The raw data frame contains at least a frame number, task identifier, and timestamp. Edge computing nodes perform fixed-time-window alignment, missing data completion, and noise suppression on the raw data frames to generate standard data frames and form data quality markers. The operational status is jointly determined by the task identifier, positioning coordinates, and motion characteristics.

[0017] Edge computing nodes segment standard data frames into events according to frame sequence numbers; when the absolute value of angular velocity exceeds the starting threshold, or the positioning point enters the electronic fence boundary area, or the operation status changes from climbing status to operation status, a candidate event segment is established; when the absolute value of angular velocity is lower than the ending threshold and continues for a first duration, or the positioning point leaves the electronic fence boundary area and continues for a second duration, the candidate event segment is closed.

[0018] First, a first joint confidence score is calculated for each candidate event segment. The joint confidence score is obtained by weighting the sensor consistency coefficient, temporal integrity coefficient, and feature validity coefficient. The weighting coefficients are non-negative and their sum is one. When the first joint confidence score is lower than the first confidence threshold, the sampling frequency is increased and supplementary sampling is performed for a preset sampling period. Then, a second joint confidence score is calculated. When the second joint confidence score is still lower than the first confidence threshold, the candidate event segment is marked as an invalid segment and the risk assessment is terminated. When the second joint confidence score is not lower than the first confidence threshold, the risk assessment process is initiated.

[0019] For candidate event fragments that pass confidence gating, the prescribed discrimination and model discrimination are performed in parallel to obtain rule scores and model scores. The fusion risk score is calculated by the rule score and model score according to the fusion weight. The fusion weight is determined according to the operation status and data quality label. The discrimination consistency difference is determined by the absolute difference between the rule score and the model score. The risk level is obtained by comparing the fusion risk score with the second risk threshold and the third risk threshold. The reason code is determined by the risk feature that exceeds the threshold the most after normalization. When they are in parallel, they are determined according to the preset priority.

[0020] Edge computing nodes determine the upload mode based on risk level, discrimination consistency difference, fusion risk score change slope, and link level. The link level is determined by uplink rate and packet loss rate. The upload modes include summary upload, feature fragment upload, and raw fragment upload. When the link is interrupted, the data to be uploaded is written to the local persistent queue according to the event identifier. After the link is restored, the data is re-uploaded in the order of the event identifier, and the corresponding cache record is deleted after receiving confirmation from the cloud node.

[0021] The cloud node performs spatiotemporal correlation and conflict resolution on event data uploaded by multiple edge computing nodes within the same work area. For event data with the same time window and spatial overlap, the conflict priority is calculated based on joint confidence, risk level, and event freshness. Event freshness is determined by the time difference between the current time and the event's end time. The cloud node retains the event with the highest conflict priority as the master event and treats the remaining events as slave events and establishes a correlation. Based on this, a parameter update package is generated and distributed to the corresponding edge computing node. The parameter update includes threshold correction parameters, weight correction parameters, upload strategy correction parameters, target device range, version number, effective time period, and rollback version number.

[0022] Edge computing nodes process the same event stream in parallel using current parameters and parameter update packages within the same verification sample window. Parameter switching is performed only when the parameter update package simultaneously satisfies the following conditions: false alarm rate is not higher than current parameters, false negative rate is not higher than current parameters, average discrimination latency is not higher than latency upper limit, and the number of verification samples reaches the lower limit of samples. If any condition is not met, the current parameters are maintained and the reason for rollback and the corresponding indicators are reported.

[0023] Edge computing nodes and cloud nodes each generate event sequence summaries and perform consistency checks based on the event identifier. The event sequence summary is calculated using a one-way hash function from the previous event sequence summary, the current event's key field set, the current event's timestamp, and the current event's random number. The current event's key field set includes the event identifier, event start time, event end time, risk level, and reason code. If the checks match, an alert is output; if they do not match, a re-transmission and review are triggered. After the number of reviews reaches a preset limit, a manual review flag is output.

[0024] The purpose of this method is to: first filter low-confidence events through two-level joint confidence gating to reduce misjudgments caused by missing and noisy data; improve the stability of critical event uploads by jointly driving the upload mode with the consistency difference and link level; suppress performance regression caused by parameter updates through the switching mechanism of cloud correction and edge parallel verification; and ensure the consistency and verifiability of event records between edge computing nodes and cloud nodes through digest consistency verification and retransmission review mechanism.

[0025] The beneficial effects of this invention are as follows: 1. This invention performs time alignment, missing data completion, and noise suppression on multi-source operational data collected by smart safety helmets, ensuring that the data entering the subsequent judgment link maintains good integrity and comparability under a unified time reference. Simultaneously, through an event segmentation mechanism, continuously collected data is divided into candidate event segments based on actual operational behavior. Furthermore, a two-level gating system using first and second joint confidence scores is applied to these candidate event segments. Low-confidence segments undergo supplementary sampling before being considered for risk judgment. This restricts abnormal data caused by missing data, jitter, and short-term interference to the front-end screening stage, thereby reducing misjudgments caused by local noise and temporal misalignment, and improving the data quality and event boundary accuracy entering the subsequent risk analysis stage.

[0026] 2. This invention performs predefined discrimination and model discrimination in parallel on candidate event fragments using confidence gating. Based on the rule scores and model scores, it calculates the fused risk score, risk level, and discrimination consistency difference. This allows the edge side to retain the interpretability of rule discrimination while leveraging the ability of model discrimination to identify complex feature combinations. Furthermore, the risk level, consistency difference, slope of the fused risk score change, and link level are used together to determine the upload mode. This ensures that the upload decision no longer relies solely on a single risk level but simultaneously considers the urgency of the event, the degree of discrimination divergence, the risk evolution trend, and the link carrying status. This allows for control of the amount of uploaded data when the link is limited, and for retaining more sufficient event information when there is high risk or significant divergence, thereby improving the timeliness, continuity, and effectiveness of critical event uploads.

[0027] 3. This invention performs spatiotemporal correlation and conflict resolution on multiple event data within the same work area through cloud nodes. It determines the master and slave events based on joint confidence, risk level, and event freshness, enabling the same real event to form a unified master index in the cloud and retaining multi-source correlation records, reducing duplicate counting and duplicate alarms. Simultaneously, cloud nodes generate parameter update packages based on the master event statistical results. Edge computing nodes perform parallel verification of the current parameters and parameter update packages within the same verification sample window. Switching is only performed when the false alarm rate, false negative rate, average discrimination latency, and sample size simultaneously meet the conditions; otherwise, the current parameters are maintained and a rollback is initiated. Combined with the event sequence summary consistency verification and retransmission review mechanism between the edge and cloud sides, the event records maintain a consistent and traceable verification chain before and after version updates, thereby improving the stability and verifiability of the entire data processing chain. Attached Figure Description

[0028] Figure 1 This is a flowchart of the data processing method for the intelligent safety helmet for high-altitude operations based on edge computing and end-to-cloud collaboration according to the present invention. Figure 2 This is a flowchart of the cloud-based event processing and parameter update edge verification process of the present invention. Detailed Implementation

[0029] 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.

[0030] like Figures 1 to 2 As shown, this embodiment of the invention provides a data processing method for intelligent safety helmets used in high-altitude operations based on edge computing and end-to-cloud collaboration. In this embodiment, the data processing link consists of a smart safety helmet, an edge computing node, and a cloud node. The smart safety helmet is responsible for on-site data collection, the edge computing node is responsible for real-time judgment and uploading of decisions, and the cloud node is responsible for cross-node fusion, parameter correction, and consistency verification.

[0031] The smart safety helmet collects operational data and generates raw data frames at a fixed sampling period. The raw data frames contain at least a frame number, a task identifier, and a timestamp. The operational data includes angular velocity, linear acceleration, relative altitude, positioning coordinates, temperature, humidity, gas concentration, heart rate, and wearing status. The relative altitude is obtained by fusing barometric altitude and ranging altitude, and the positioning coordinates are obtained by fusing satellite positioning coordinates and near-range positioning coordinates.

[0032] After receiving the raw data frame, the edge computing node sequentially performs time alignment, missing data completion, and noise suppression to obtain a standard data frame. Time alignment uses a fixed time window; missing data completion uses the previous valid sample to retain and write missing data markers; noise suppression uses sliding window mid-range filtering. Subsequently, the edge computing node segments the standard data frame into event segments according to the frame sequence number to generate candidate event segments. The triggering conditions for establishing a candidate event segment are: the absolute value of the angular velocity exceeds the starting threshold, or the positioning point enters the electronic fence boundary area, or the operation status changes from climbing status to operation status. The triggering conditions for closing a candidate event segment are: the absolute value of the angular velocity is lower than the ending threshold and lasts for a first duration, or the positioning point leaves the electronic fence boundary area and lasts for a second duration.

[0033] For each candidate event segment, the edge computing node first calculates the first joint confidence score, which is obtained by weighting the sensor consistency coefficient, temporal integrity coefficient, and feature validity coefficient. When the first joint confidence score is lower than the first threshold, the edge computing node performs supplementary sampling and recalculates the second joint confidence score. Supplementary sampling is achieved by increasing the sampling frequency to an integer multiple of the basic sampling frequency and continuously for a preset sampling period. When the second joint confidence score is still lower than the first threshold, the candidate event segment is marked as an invalid segment and the risk judgment is terminated. When the second joint confidence score is not lower than the first threshold, the risk judgment process is initiated.

[0034] For candidate event fragments that pass confidence gating, edge computing nodes perform predefined discrimination and model discrimination in parallel to obtain rule scores and model scores. The fusion risk score is calculated by weighting the rule score and model score. The discrimination consistency difference is determined by the absolute difference between the rule score and the model score. The risk level is determined based on the comparison between the fusion risk score and the preset classification threshold. The cause code is determined based on the risk feature that exceeds the threshold the most after normalization. In the case of parallel events, the final cause code is determined according to the preset priority table.

[0035] Edge computing nodes determine their upload modes based on risk level, discriminant consistency difference, fusion risk score change slope, and link level, and then upload event data to cloud nodes. Upload modes include summary upload, feature fragment upload, and raw fragment upload; link level is determined by uplink rate and packet loss rate; when a link is unavailable, the edge computing node writes the data to be uploaded to a local persistent queue according to the event identifier; after the link is restored, the data is re-uploaded in the order of the event identifier, and the corresponding cached record is deleted after receiving confirmation from the cloud node.

[0036] The cloud node performs spatiotemporal correlation and conflict resolution on event data uploaded by multiple edge computing nodes within the same work area. For multiple event data that overlap in space within the same time window, the cloud node calculates the conflict priority based on joint confidence, risk level, and event freshness. Event freshness is determined by the time difference between the current time and the event's end time. The cloud node retains the event data with the highest conflict priority as the master event, marks the remaining event data as slave events, and establishes a correlation. Based on the correlation results and statistical results, it generates a parameter update package and sends it to the corresponding edge computing node. The parameter update package includes at least threshold correction parameters, weight correction parameters, upload strategy correction parameters, target device range, version number, effective time period, and rollback version number.

[0037] Edge computing nodes process the same event stream in parallel with current parameters and parameter update packages within the same verification sample window. The switching conditions are as follows: the parameter update package simultaneously meets the following conditions: the false alarm rate is not higher than the current parameters, the false negative rate is not higher than the current parameters, the average discrimination latency is not higher than the latency upper limit, and the number of verification samples is not less than the preset sample lower limit. When the switching conditions are met, the parameter update package is enabled; when the switching conditions are not met, the current parameters are maintained and a rollback report is performed.

[0038] Edge computing nodes and cloud nodes generate event sequence summaries respectively, and perform summary consistency checks according to event identifiers. The event sequence summary is generated by a one-way hash function from the previous event sequence summary, the current event key field set, the current event timestamp, and the current event random number. The current event key field set includes event identifier, event start time, event end time, risk level, and reason code. When the verification is consistent, an early warning command is output; when the verification is inconsistent, a retransmission and review are triggered; after the number of reviews reaches a preset limit, a manual review mark is output.

[0039] Through the above processing chain, low-confidence data can be filtered out at the edge first, then risk assessment and hierarchical uploading can be performed, and cross-node data decomposition and parameter correction can be completed in the cloud. Finally, the consistency of event records between edge computing nodes and cloud nodes can be ensured through digest consistency verification, thereby improving the stability and verifiability of high-altitude operation early warning.

[0040] In this embodiment, the initial operational risk level is determined by the task issuance information, which includes at least the operational type, operational height range, and operational area level. After entering the operation phase, the operational risk level is updated on a rolling basis according to the output results of the previous judgment cycle, and the sampling frequency of height data and positioning data is determined by the sampling strategy table corresponding to the current operational risk level.

[0041] In this embodiment, the fusion weights for barometric altitude and ranging altitude are calculated from their respective quality scores. The barometric altitude quality score is determined based on the fluctuation amplitude and missing rate within a short time window, while the ranging altitude quality score is also determined based on the fluctuation amplitude and missing rate within a short time window. Both are normalized and used as the fusion weights. Positioning coordinate fusion employs the same method. The satellite positioning quality score is determined by positioning accuracy and update continuity indicators, while the near-range positioning quality score is determined by base station coverage status and update continuity indicators.

[0042] In this embodiment, the data quality label adopts a hierarchical coding, which includes at least three states: normal, degraded, and failed. Normal means that the current data can be directly used for fusion calculation, degraded means that the current data can participate in fusion but the weight is limited, and failed means that the current data does not participate in fusion and triggers the replacement strategy.

[0043] In this embodiment, when both satellite positioning and near-range positioning fail simultaneously, the system outputs the nearest valid positioning coordinates only within the maximum holding time and simultaneously writes a positioning failure flag; after the maximum holding time is exceeded, the system stops outputting valid positioning results and triggers a positioning anomaly report. The maximum holding time is preset by the task parameters and issued before the task begins.

[0044] In this embodiment, the event freshness is calculated by the time difference between the current time and the event end time. The smaller the time difference, the higher the event freshness. The conflict priority is calculated by the joint confidence, risk level and event freshness according to a preset weight. The preset weight is calibrated offline by historical labeled samples and distributed to edge computing nodes and cloud nodes before the task starts.

[0045] In this embodiment, the edge computing node performs preprocessing on the raw data frames uploaded by the smart safety helmet in a fixed order. The processing order is time alignment, missing data completion, and noise suppression. After processing, a standard data frame is output and sent to the event segmentation module. The preprocessing order remains unchanged during task execution to avoid inconsistencies in the time boundaries of the same event in different modules due to changes in the processing order.

[0046] The raw data frames uploaded by the smart safety helmet contain at least the frame sequence number, task identifier, timestamp, and sampled values ​​for each channel. The edge computing nodes use the task start time as a unified reference time and map each sampled value to a fixed time window. The fixed time window length is issued by the task configuration and remains unchanged within the task cycle. The window sequence number is obtained by subtracting the reference time from the current timestamp, dividing by the fixed time window length, and rounding down.

[0047] When multiple sample values ​​exist in the same channel within the same time window, the sample value with the largest timestamp is retained first; if the timestamps are the same, the sample value with the largest frame number is retained and an overwrite mark is written.

[0048] When there are no sampled values ​​in the same channel within the same time window, a missing candidate flag is first written, and then the missing completion process begins.

[0049] Missing data is filled using the previous valid sample retention method. For channel data missing in the current time window, the edge computing node calls the most recent valid sample value of that channel to fill it. If no valid sample value has appeared after the task starts, the task initialization value is used to fill it, and the initialization fill value flag is written.

[0050] The criteria for determining a valid sample value are: the sensor range check passes, the communication verification passes, and the timestamp is valid.

[0051] Each time a data is supplemented, a missing data marker is written. The missing data marker includes at least the channel identifier, window number, and source of the supplementation. The edge computing node synchronously maintains a continuous missing data count: when the continuous missing data count reaches the first missing data threshold, the data quality marker of the channel is set to downgraded; when the continuous missing data count reaches the second missing data threshold, the data quality marker of the channel is set to invalid. Invalid channels do not participate in the corresponding feature calculation, but only retain their status for subsequent alarms and equipment maintenance prompts. If the key channels required for joint confidence calculation are invalid at the same time, the time window directly outputs a low confidence conclusion and triggers the supplementary data collection process.

[0052] Noise suppression employs sliding window median filtering. For numerical channels, edge computing nodes extract samples from adjacent windows centered on the current time window, sort them by value, and take the median value as the output value for that time window. The filtering window length is an odd number, configured by the task, and the boundary time windows are supplemented with endpoint replication to make up the window length.

[0053] For non-numerical state channels, median filtering is not performed, the original state values ​​are passed through, and missing data markers and data quality markers are retained.

[0054] The standard data frame consists of the following fields: frame number, task identifier, timestamp, preprocessing results for each channel, overlay marker, missing marker, consecutive missing count, and data quality marker. The standard data frame is output in ascending order of frame number and can be directly called by the event segmentation, joint confidence calculation, and risk discrimination modules.

[0055] When a clock jump, window sequence number reversal, or consecutive window loss reaches the third missing threshold, the edge computing node performs resynchronization processing. During resynchronization, the previous valid standard data frame is output and a resynchronization flag is written, while the mapping between the reference time and the window sequence number is reconstructed. After resynchronization is completed, normal output is restored. Through this mechanism, subsequent modules will not experience segment miscutting or continuous misjudgment due to sudden changes in the time base.

[0056] In this embodiment, the fixed time window length, the first missing threshold, the second missing threshold, the third missing threshold, the filter window length, and the task initialization value are all sent from the cloud node to the edge computing node before the task starts. The edge computing node only updates the above parameters after receiving the new task configuration, and does not temporarily rewrite them during task execution.

[0057] Through the above implementation method, time alignment, missing padding and noise suppression are completed continuously within the same time grid, and the labeling information generated by preprocessing can be directly entered into the subsequent discrimination link, enabling those skilled in the art to reproduce the experimental process and stably implement the invention.

[0058] In this embodiment, the edge computing node performs event segmentation based on the preprocessed standard data frame to generate candidate event fragments. The standard data frame is obtained by the aforementioned time alignment, missing data completion and noise suppression processing, and is output in ascending order of frame number. Event segmentation is performed under a unified time window index system. The start and end boundaries of the candidate event fragments are represented by the time window number and the corresponding timestamp, so that the subsequent joint confidence calculation, rule discrimination and model discrimination use the same time boundary.

[0059] The parameters used for event segmentation are distributed from the cloud node to the edge computing node before the task begins and remain unchanged during the task cycle. These parameters include at least the start threshold, end threshold, first duration, second duration, width of the electronic fence boundary area, number of trigger de-jitter windows, and maximum duration of the segment. The end threshold is less than the start threshold to form threshold hysteresis, which reduces the frequent opening and closing of candidate event segments caused by fluctuations in angular velocity near the threshold. The first duration and second duration are represented by the number of time windows and are used to determine whether the conditions are met continuously.

[0060] The angular velocity is taken from the angular velocity field in the standard data frame. The absolute value of the angular velocity is the absolute value of the angular velocity. The positioning coordinates are taken from the positioning coordinate field in the standard data frame. The standard data frame contains a data quality flag. When the data quality flag corresponding to the angular velocity or positioning coordinates is invalid, this time window does not participate in the corresponding trigger condition judgment and continuous satisfaction count.

[0061] The electronic fence is configured by the task and is a closed polygon boundary. The edge computing node calculates the shortest distance from the positioning coordinates to the electronic fence boundary in each time window. When the shortest distance is not greater than the width of the electronic fence boundary area, the positioning coordinates are determined to be in the electronic fence boundary area. When the shortest distance is greater than the width of the electronic fence boundary area and the positioning coordinates are inside the polygon, they are determined to be in the fence interior area. When the positioning coordinates are outside the polygon and the shortest distance is greater than the width of the electronic fence boundary area, they are determined to be in the fence exterior area.

[0062] The operation status includes at least the climbing status and the operation status. The operation status is determined by the task identifier, positioning coordinates and motion characteristics. The motion characteristics include at least the absolute value of angular velocity, the amplitude of linear acceleration and the rate of change of relative height. The edge computing node writes the operation status into the status field and writes a status switching flag in the time window when the climbing status is switched to the operation status, which can be directly called by the event segment.

[0063] Establishment of candidate event fragments Edge computing nodes maintain fragment status, initially with no candidate event fragments established. When any of the following conditions are met and the de-jitter triggering requirements are satisfied, a candidate event fragment is established, and the fragment's start time window number and start timestamp are recorded, along with the initial trigger type: If the absolute value of the angular velocity exceeds the initial threshold, in order to avoid false triggering caused by single-point spikes, the edge computing node requires that the absolute value of the angular velocity exceeds the initial threshold within several time windows of the consecutive triggering debouncing window before a candidate event segment is established.

[0064] The location coordinates enter the electronic fence boundary area. The entry determination is based on the regional state change of adjacent time windows: when the location coordinates in the previous time window are not in the electronic fence boundary area and the location coordinates in the current time window are in the electronic fence boundary area, the entry condition is met.

[0065] When the work status changes from climbing status to work status, the edge computing node establishes candidate event segments based on the status change marker, with the segment starting point being the time window where the status change marker is located.

[0066] When a candidate event segment has been established, if the establishment condition occurs again, a new candidate event segment will not be established again. The edge computing node adds a trigger record to the segment metadata and retains the earliest segment start time window number as the segment start point to avoid the same real event being split into multiple segments.

[0067] Closure of candidate event segments After candidate event segments are established, edge computing nodes continuously monitor closure conditions. When any of the following conditions are met and the continuous judgment requirement is satisfied, the candidate event segment is closed, the segment end time window number and end timestamp are recorded, and the closure trigger type is recorded: The absolute value of the angular velocity is below the termination threshold and remains below it for a first duration. The first duration is counted in time windows, and closure is determined only if the absolute value of the angular velocity is below the termination threshold for each consecutive time window of the first duration.

[0068] The location coordinates leave the electronic fence boundary area and remain there for a second duration. The departure determination is based on the change in the regional state of adjacent time windows: the departure condition is met when the location coordinates in the previous time window are in the electronic fence boundary area and the location coordinates in the current time window are not in the electronic fence boundary area. The candidate event segment is closed only after the departure state is maintained for a second duration.

[0069] To avoid the impact of prolonged non-closure of candidate event fragments on subsequent processing in extreme cases, the edge computing node adopts a maximum fragment duration constraint. When the duration of a candidate event fragment reaches the maximum fragment duration, the edge computing node forcibly closes the candidate event fragment and writes a forced closure marker. The forced closure marker is used as one of the fragment status fields. The subsequent joint confidence calculation reads the fragment status field and lowers the feature validity coefficient of the fragment by a preset coefficient.

[0070] Output and consistency constraints of candidate event fragments After the candidate event segment is closed, the edge computing node outputs segment index information, including segment identifier, segment start and end time window number, segment start and end timestamp, start trigger record, closure trigger record, and the standard data frame range corresponding to the segment. This segment index information serves as the input boundary for subsequent joint confidence calculation, rule discrimination, and model discrimination. Subsequent modules only extract features and calculate risk scores within the candidate event segment range to avoid interference from noise outside the segment on the discrimination results.

[0071] By segmenting events as described above, angular velocity threshold triggering, changes in electronic fence boundary status, and switching of work status are consistently determined under a unified time window indexing system. The start and end of candidate event segments are controlled by threshold hysteresis, duration determination, and trigger de-jitter mechanism, making the boundaries of candidate event segments closer to the boundaries of actual work behavior, thus providing stable input for subsequent confidence gating, risk identification, and upload mode selection.

[0072] In this embodiment, after a candidate event segment is closed, the edge computing node first calculates a first joint confidence score for that segment. When the first joint confidence score is lower than a first threshold, supplementary sampling is triggered, and a second joint confidence score is calculated after the supplementary sampling is completed. The first and second joint confidence scores use the same calculation formula, the difference being that the input data for the second joint confidence score includes standard data frames added during the supplementary sampling phase. The calculation objects and input constraints of joint confidence The joint confidence score is calculated based on the sequence of standard data frames corresponding to a single candidate event segment. The standard data frames are obtained through the aforementioned time alignment, missing data completion, and noise suppression processes, and include frame number, timestamp, missing data marker, and data quality marker.

[0073] In this embodiment, the key channels used for joint confidence calculation include at least angular velocity, linear acceleration, relative altitude, positioning coordinates, gas concentration, and heart rate. If the data quality of a key channel within a candidate event segment is marked as faulty, that channel will not participate in the calculation of the sensor consistency coefficient and feature validity coefficient. If all key channels are faulty, supplementary sampling will not be triggered; instead, the candidate event segment will be directly marked as an invalid segment, and a device anomaly flag will be output for subsequent alarms and maintenance prompts.

[0074] The first joint confidence level and the second joint confidence level are both calculated using the following formula: ,in, The sensor consistency coefficient. The time sequence integrity coefficient. The feature effectiveness coefficient, These are non-negative weighting coefficients, and ; The task is distributed from the cloud node to the edge computing node before the task begins and remains unchanged throughout the task cycle. The calculation method for the sensor consistency coefficient: The sensing consistency coefficient is used to characterize the degree of physical consistency between multi-source data within a candidate event segment. In this embodiment, the sensing consistency coefficient is calculated based on at least the height consistency term, the positioning consistency term, and the motion consistency term, and is normalized to between zero and one.

[0075] The high consistency term is the proportion of time windows in which the absolute value of the difference between the relative altitude sequence obtained from the change in air pressure altitude and the relative altitude sequence obtained from the change in distance altitude within the same time window is not greater than the high consistency threshold.

[0076] The positioning consistency item is the proportion of time windows in which the coordinate difference between satellite positioning coordinates and near-range positioning coordinates within the same time window is not greater than the positioning consistency threshold.

[0077] The motion consistency term is the trend consistency ratio of the motion characteristics formed by changes in linear acceleration and angular velocity and the rate of change in relative height within the same time window in the candidate event segment; when the two trends are opposite and continuously exceed the preset window number, the corresponding time window is not included in the consistency ratio.

[0078] The sensor consistency coefficient Cs is obtained by weighting the three consistency items according to the proportion of their effective time windows. When the number of effective time windows of a certain consistency item is less than half of the total number of time windows of the candidate event segments, the consistency item is not included in the calculation, and its weight is distributed proportionally to the other consistency items.

[0079] The calculation method for the timing integrity coefficient: The temporal integrity coefficient is used to characterize the completeness and continuity of data within a candidate event segment in the time dimension.

[0080] In this embodiment, the edge computing node calculates the missing ratio and the continuous missing intensity based on the missing marker. The missing ratio is the proportion of time windows in which the critical channel within the candidate event segment is missing and filled in; the continuous missing intensity is the maximum length and average length of the continuous missing critical channel.

[0081] The temporal integrity coefficient Ct is obtained by mapping the missing proportion and the intensity of consecutive missing events, and normalized to between zero and one. The smaller the missing proportion and the intensity of consecutive missing events, the larger Ct is. If the standard data frame corresponding to the candidate event segment contains a resynchronization marker, Ct is adjusted down by a preset coefficient, which is issued by the task configuration.

[0082] The calculation method for the feature effectiveness coefficient: The feature validity coefficient is used to characterize whether the features used for risk assessment within the candidate event segment meet the validity conditions. In this embodiment, the edge computing node extracts the feature set required for risk assessment from the candidate event segment and checks the range validity, change validity and label consistency item by item. If the candidate event segment has a forced closure mark or a positioning failure mark, the features dependent on the corresponding channel are determined to be invalid and removed from the valid feature set.

[0083] The feature effectiveness coefficient Cf is taken as the proportion of the number of effective features to the total number of features, and normalized to between zero and one.

[0084] Triggering, Execution, and Persistence Boundaries of Supplemental Sampling When the first joint confidence level is lower than the first threshold, the edge computing node sends a supplementary sampling instruction to the smart helmet. The supplementary sampling instruction includes at least the supplementary sampling multiple K and the number of continuous sampling periods T, where K is an integer greater than one and T is a positive integer. K and T are determined by the supplementary sampling strategy table issued by the cloud node before the task starts.

[0085] After receiving the supplementary sampling instruction, the smart safety helmet increases the sampling frequency of the key channel to K times the basic sampling frequency and continues for T sampling cycles. After the supplementary sampling is completed, the smart safety helmet uploads the original data frames generated in the supplementary sampling stage to the edge computing node according to the original timestamp rules. The edge computing node performs the same time alignment, missing data filling and noise suppression processing on the original data frames in the supplementary sampling stage as on regular data.

[0086] In this embodiment, the supplementary sampling data is preferentially used to replace the time window with the highest missing completion ratio in the candidate event segment; when the candidate event segment still has continuous missing intensity exceeding the preset upper limit after replacement, several time windows adjacent to the end time of the segment in the supplementary sampling stage are added to the end of the candidate event segment, and the segment end time window number and end timestamp are updated accordingly.

[0087] The Coordination Relationship Between the Second Joint Confidence and Subsequent Links The edge computing nodes recalculate the sensing consistency coefficient, temporal integrity coefficient, and feature validity coefficient based on the updated candidate event fragments to obtain the second joint confidence score.

[0088] When the second joint confidence level is still lower than the first threshold, the candidate event fragment is marked as an invalid fragment, and the rule discrimination and model discrimination of the candidate event fragment are terminated; when the second joint confidence level is not lower than the first threshold, the candidate event fragment is allowed to enter the subsequent risk discrimination and upload mode determination process.

[0089] By using a two-level joint confidence level and supplementary sampling mechanism, low-confidence segments can be re-acquired and re-evaluated before risk assessment, making the input data for risk assessment more stable and limiting false triggers caused by missing data and noise to the confidence gating stage.

[0090] In this embodiment, the edge computing node extracts a discriminative feature sequence from the candidate event segment. The discriminative feature sequence includes at least the absolute value change feature of angular velocity, the linear acceleration amplitude change feature, the relative height change rate, the distance change between the positioning coordinates and the electronic fence boundary, the gas concentration change feature, the heart rate change feature, and the wearing status change feature. All of the above features are derived from the standard data frame corresponding to the candidate event segment, and invalid features corresponding to the failed channel are filtered in combination with data quality markers.

[0091] Rule discrimination is based on a pre-set rule set, which is distributed from the cloud node to the edge computing node before the task begins and remains unchanged during the task cycle. Each rule corresponds to a risk triggering scenario, including at least: high-altitude boundary approach rule, abnormal attitude change rule, rapid altitude change rule, environmental anomaly rule, and physiological load anomaly rule. The edge computing node matches each rule with the candidate event fragment, calculates the trigger intensity of each rule, and merges all rule trigger intensities into a rule score Rr. The rule score Rr is normalized and limited to between zero and one, with a larger value indicating a higher risk in the rule discrimination.

[0092] The model discrimination is based on the risk discrimination model stored locally on the edge computing node. The risk discrimination model and the rule discrimination use the discrimination feature sequence of the same candidate event segment as input, output the risk probability of the candidate event segment, and normalize the risk probability into the model score Rm. The model score Rm is also limited to between zero and one. The larger the value, the higher the risk that the model considers.

[0093] To avoid incomparable results due to different inputs used for rule-based discrimination and model-based discrimination, edge computing nodes uniformly use the same batch of feature sequences for both types of discrimination and complete the calculation within the same discrimination period.

[0094] Method for determining fusion weights In this embodiment, the fusion weight α is determined by a lookup table based on the job status and data quality label. The edge computing node locally stores the fusion weight lookup table relationship, with the row index of the lookup table relationship being the job status and the column index being the data quality level.

[0095] The operational status includes at least the climbing status, the operational status, and the evacuation status.

[0096] Data quality levels include at least three categories: normal, degraded, and restricted. In normal cases, all key channels within a candidate event segment can be directly involved in the discrimination. A downgrade indicates that some key channels are missing and the proportion of missing channels is relatively high, but it can still form an effective judgment. A restricted status indicates that although not all critical channels have failed, there are instances of forced closure markers, location failure markers, or continuous missing data approaching the upper limit.

[0097] The edge computing node first reads the job status corresponding to the current candidate event segment, then reads the overall data quality level of the candidate event segment, and then determines the fusion weight α according to the table lookup relationship.

[0098] When the job status is "job status" and the data quality level is "normal", the fusion weights prioritize maintaining the model's discrimination weights. When the data quality level is downgraded or restricted, the fusion weight increases the rule discrimination weight to reduce the impact of low-quality data on the stability of the model output.

[0099] The fusion weight α ranges from zero to one, and only one fixed value is taken for the same candidate event segment, without repeated changes within the same segment.

[0100] Calculation of integrated risk score and consistency difference In this embodiment, the edge computing node calculates the fusion risk score using the following formula: ; Where R is the fusion risk score, For the rule score, For model scores, The fusion weights are calculated in this way, so that both rule-based discrimination and model-based discrimination participate in the final risk assessment, and their participation ratio is constrained by both the job status and the data quality level. This ensures that the fusion result retains both the interpretability of rule-based discrimination and the ability of model-based discrimination to identify complex feature combinations.

[0101] The consistency difference of edge computing nodes is calculated using the following formula: Where D is the consistency difference, which is used to represent the degree of discrepancy between rule-based discrimination and model-based discrimination on the same candidate event segment. The larger D is, the greater the difference between the two discrimination results; the smaller D is, the more consistent the two discrimination results are. In this embodiment, the consistency difference is not directly used to determine the risk level, but serves as an important input for subsequent upload mode classification and conflict review, so as to retain more event information for further processing by cloud nodes when there is a large discrepancy between the rule judgment and the model judgment results.

[0102] Determining the risk level In this embodiment, the edge computing node compares the fusion risk score R with the second threshold and the third threshold to determine the risk level; the second threshold and the third threshold are issued by the cloud node before the task starts, and the second threshold is less than the third threshold.

[0103] When R is less than the second threshold, it is classified as a level 1 risk. When R is greater than or equal to the second threshold and less than the third threshold, it is judged as a level 2 risk; When R is greater than or equal to the third threshold, it is judged as a level three risk.

[0104] To ensure consistency in risk classification standards throughout this task period, the second and third thresholds will not be temporarily rewritten during the execution of this task, but will only be updated after the new task configuration is issued.

[0105] In this embodiment, after generating the risk level, the edge computing node further determines the cause code based on the normalized threshold calculation results of each risk feature within the candidate event segment.

[0106] The so-called normalized over-threshold refers to the ratio of the magnitude by which the current value of a certain risk feature exceeds its corresponding trigger threshold to the preset range of the feature. The edge computing node calculates the normalized over-threshold for each risk feature and takes the risk feature with the largest normalized over-threshold as the dominant risk feature. The code corresponding to the dominant risk feature is the cause code.

[0107] If two or more risk characteristics have the same normalized threshold, the reason code is determined according to the preset priority table. The preset priority table is issued by the cloud node before the task starts. Its priority can be sorted at least according to the degree of safety impact. For example, the location out-of-bounds category is higher than the posture abnormality category, the posture abnormality category is higher than the environmental abnormality category, and the environmental abnormality category is higher than the physiological abnormality category.

[0108] In this way, the cause code directly corresponds to the most important source of risk in this candidate event segment, rather than simply recording the over-limit result of a single sensor, thus facilitating subsequent conflict resolution and manual review by cloud nodes.

[0109] Exception Branches and Boundary Handling In this embodiment, if either the rule score Rr or the model score Rm is not generated within the preset discrimination time limit, the edge computing node marks the candidate event fragment as a discrimination-restricted fragment, increases the rule discrimination weight, and recalculates the fusion risk score; if neither is generated within the preset discrimination time limit, the candidate event fragment does not enter the normal fusion calculation, directly outputs the discrimination anomaly mark, and enters the high-fidelity upload mode.

[0110] If a candidate event segment has a forced closure marker, a location failure marker, or a high proportion of missing markers after supplementary sampling, the edge computing node will keep the original formula unchanged when calculating the fusion risk score, but will downgrade the candidate event segment by at least one level when determining the data quality level, so as to ensure that the fusion weight lookup result reflects the actual credibility of the candidate event segment.

[0111] In this embodiment, the risk score R, risk level, and consistency difference D are integrated as three core outputs for the same candidate event fragment, which are directly called by the subsequent upload mode determination module.

[0112] Among them, the risk level reflects the urgency of the event, the consistency difference reflects the degree of discrepancy between the rule-based judgment and the model-based judgment, and the slope of the fusion risk score change reflects the risk development trend. The edge computing node uses the above results together with the link level to select the summary upload, feature fragment upload, or original fragment upload mode.

[0113] Through this processing link, rule discrimination and model discrimination are no longer output separately. Instead, they are first unified and integrated and dominated risk attribution are completed at the edge computing node, and then they enter the upload mode judgment and cloud association processing. This allows subsequent links to revolve around the unified result of the same candidate event fragment, reducing ambiguity and redundancy caused by the parallel upload of multi-source discrimination results.

[0114] In this embodiment, after calculating the fusion risk score, risk level, and consistency difference, the edge computing node does not directly determine the content to be uploaded based on a single risk threshold. Instead, it combines the consistency difference grading, the fusion risk score change slope grading, and the link level grading to determine the upload mode through a pre-set mapping table. The upload decision also reflects the urgency of the event, the degree of discrepancy between rule judgment and model judgment, the risk change trend, and the current link carrying capacity, so that the data format output by the edge computing node is consistent with the subsequent processing requirements of the cloud node.

[0115] The upload mode determines the amount of input and the categorization method. The edge computing node outputs the risk level, consistency difference, and fusion risk score for each candidate event fragment, and calculates the slope of the fusion risk score change within the current discrimination period.

[0116] Among them, the risk level is the first-level risk, second-level risk, or third-level risk obtained from the aforementioned fusion judgment; The consistency difference is the absolute difference between the rule score and the model score, and its value ranges from zero to one. The edge computing nodes divide the consistency difference into low difference, medium difference and high difference categories according to the preset grading threshold.

[0117] The slope of the fusion risk score change is obtained by dividing the difference between the fusion risk score in the current judgment period and the fusion risk score in the previous judgment period by the judgment period duration. When there is no previous judgment period, the slope of the fusion risk score change is zero. The edge computing node divides the slope of the fusion risk score change into a stable level, an increasing level, and a rapidly increasing level according to the preset grading threshold.

[0118] The link level is determined by the uplink rate and packet loss rate measured by the edge computing node within the current statistical window. The edge computing node first classifies the uplink rate and packet loss rate into different levels, and then outputs the link level based on the combination relationship. The link level includes at least three levels: excellent, limited, and unavailable. Among them, an uplink rate that is not lower than the upload rate threshold and a packet loss rate that is not higher than the packet loss rate threshold is judged as excellent; an uplink rate that decreases or a packet loss rate that increases but still meets the minimum communication requirements is judged as limited; and an uplink handshake that fails to complete for multiple consecutive statistical windows or a continuous heartbeat timeout that reaches the upper limit is judged as unavailable.

[0119] The aforementioned threshold values ​​for tiering, statistical window length, upload rate, packet loss rate, and heartbeat timeout are all distributed from the cloud node to the edge computing node before the task begins and remain unchanged throughout the task cycle.

[0120] Storage and retrieval methods of pre-defined mapping tables In this embodiment, the edge computing node locally stores a pre-set mapping table. The pre-set mapping table uses risk level, consistency difference, fusion risk score change slope, and link level as a joint index, and uses the upload mode as the output result.

[0121] After each candidate event segment is judged, the edge computing node sequentially reads the risk level, consistency difference classification, fusion risk score change slope classification, and link level classification, and queries the pre-set mapping table according to the joint index to obtain the corresponding upload mode.

[0122] The same candidate event segment corresponds to only one upload mode within the same discrimination period. Parallel multi-mode upload is not performed. If the same candidate event segment is re-fused and discriminated due to supplementary sampling, late data addition, or recalculation, the edge computing node will re-query the preset mapping table with the latest joint index result and replace the old upload mode that has not yet been executed with the new upload mode.

[0123] The pre-defined mapping table must satisfy at least the following constraints: when the risk level is high, the slope of the fusion risk score change is high, or the consistency difference is high, the upload mode with higher information content should be prioritized; when the link level drops from good to restricted, the upload data volume should be reduced while ensuring the integrity of the key event fields; when the link level is unavailable, real-time upload should not be performed, and the data should be cached in a local persistent queue.

[0124] The information content order of the upload mode is determined by the following order: original fragment upload > feature fragment upload > feature fragment upload > summary upload.

[0125] Specific details of each upload mode In this embodiment, the upload modes include summary upload, feature fragment upload, and original fragment upload; The uploaded summary should include at least the event identifier, the start and end time window number of the candidate event segment, the risk level, the consistency difference, the fusion risk score, the reason code, the current link level, and the overall data quality level of the candidate event segment. The uploaded summary should not include the complete time series sampling sequence.

[0126] The uploaded feature fragments must include at least the entire summary and the key feature sequences selected from the candidate event fragments. The key feature sequences must include at least the absolute value change of angular velocity, the change of linear acceleration amplitude, the rate of change of relative height, the change of distance between the positioning coordinates and the electronic fence boundary, the change of gas concentration, and the change of heart rate. The uploaded feature fragments do not contain complete standard data frame sequences.

[0127] The content uploaded in the original fragment should include at least all the content uploaded in the feature fragment, as well as the standard data frame sequence corresponding to the candidate event fragment. The original fragment upload is used for situations with high risk level, high consistency difference, or high slope of change in fusion risk score.

[0128] After determining the upload mode, the edge computing node encapsulates the upload payload according to the corresponding mode, and uniformly writes the event identifier, upload mode identifier, payload length and check value into the payload header, so that the cloud node can receive and parse it in a unified format.

[0129] Event identifier generation and local persistent queue writing rules In this embodiment, the event identifier is generated by combining the task identifier, the edge computing node identifier, and the candidate event segment start time window number. For the same edge computing node under the same task, the event identifier monotonically increases according to the start time of the candidate event segments.

[0130] If the upload mode or upload content of the same candidate event segment is updated due to supplementary sampling, late data addition, or recalculation, the original event identifier will still be used, and a new event identifier will not be generated.

[0131] When the link level is unavailable, the edge computing node does not perform real-time upload. Instead, it writes the data to be uploaded into a local persistent queue according to the event identifier. Each record in the local persistent queue includes at least the event identifier, upload mode identifier, payload storage location, write time, retry count, and checksum.

[0132] If an old record with the same event identifier already exists in the local persistent queue, the edge computing node will process it according to the following rules: When the upload mode information content of the new record is higher than that of the old record, replace the old record with the new record. When both records have the same upload mode and the new record was generated later, the new record will overwrite the old record. When an old record has entered the sending state, the old record is retained until the current sending ends, and replacement or overwriting is performed according to the above rules after the sending ends.

[0133] This mechanism ensures that only one valid cached record of the same event is retained during a link outage.

[0134] Retransmission process after link recovery The edge computing node continuously monitors the link status. When the uplink rate recovers to a level no lower than the upload rate threshold, the packet loss rate recovers to a level no higher than the packet loss rate threshold, and the consecutive heartbeat handshakes are successfully completed a preset number of times, the edge computing node updates the link level from unavailable to available and starts the retransmission process.

[0135] During retransmission, the edge computing node reads cached records from the local persistent queue in ascending order of event identifiers and sends them to the cloud node. After sending each record, the edge computing node waits for the cloud node to return an acknowledgment message. The acknowledgment message includes at least the event identifier, the receiving result, and the corresponding checksum.

[0136] When the event identifier returned by the cloud node matches the checksum, the edge computing node deletes the record from its local persistent queue. When the cloud node does not return an acknowledgment message, returns a failure result, or the checksum does not match, the edge computing node retains the record and increments the retry count, then retransmits it in the next retransmission round.

[0137] When the retry count for a record reaches the upper limit, the edge computing node writes a retransmission exception flag and transfers the record to a high-priority sending queue. While the link remains available, the retransmission exception flag and corresponding event identifier are sent before ordinary cached records, so that the cloud node can trigger subsequent manual processing or special review process.

[0138] Collaboration with pre- and post-processing links In this embodiment, the upload mode determines that the slope of the change in risk level, consistency difference, and fusion risk score output from the previous stage is the input. Therefore, the upload mode is consistent with the aforementioned rule discrimination, model discrimination, and fusion calculation results.

[0139] The data payloads generated by different upload modes are directly used as inputs for cloud nodes to perform spatiotemporal correlation, conflict resolution, and parameter updates, enabling edge computing nodes and cloud nodes to process around the same event identifier and the same candidate event segment boundary.

[0140] When the link is interrupted, the edge computing node maintains the order of events through a local persistent queue; after the link is restored, the edge computing node retransmits the events in the order of the event identifiers and uses the confirmation result of the cloud node as the basis for deletion, thereby ensuring that the same event has consistent and traceable processing records on both the edge computing node and the cloud node.

[0141] In this embodiment, after receiving event data from multiple edge computing nodes, the cloud node first performs spatiotemporal correlation and then performs conflict resolution. The purpose of conflict resolution is not to directly delete duplicate events, but to determine a master event from multiple event data corresponding to the same real operational risk while retaining all event records, and to establish a correlation between the master event and the remaining event data as slave events. In this way, the cloud node can avoid the same real event being counted or alarmed repeatedly, and can retain the remaining event data as the basis for subsequent review, parameter correction and manual traceability.

[0142] Input structure and preprocessing of event data In this embodiment, each event data received by the cloud node is encapsulated by the edge computing node according to the aforementioned upload mode. In order to perform spatiotemporal correlation and conflict resolution, the cloud node reads at least the following fields: event identifier, edge computing node identifier, task identifier, candidate event segment start time window number, candidate event segment end time window number, candidate event segment start timestamp, candidate event segment end timestamp, event corresponding location coordinate range, joint confidence, risk level, reason code, upload mode identifier, and receive timestamp.

[0143] The location coordinate range corresponding to the event is provided by the edge computing node during the upload process. It is used to represent the spatial coverage area of ​​the candidate event fragment. The location coordinate range includes at least the minimum boundary, maximum boundary and center coordinates of the location coordinates within the candidate event fragment. After receiving the event data, the cloud node first groups the data according to the task identifier and the work area number. Conflict resolution is only performed within the same task and the same work area to avoid cross-task and cross-region events from affecting each other.

[0144] Method for determining the same time window In this embodiment, the same time window does not refer to the same event identifier, but rather to two or more event data that overlap in the time dimension or belong to the same conflict determination window.

[0145] The cloud node first determines whether there is any overlap in the time window index of different event data based on the start time window number and end time window number of the candidate event segments in the event data; if the time window ranges of two event data overlap, they are directly determined to be time overlap.

[0146] If the time windows of two event data do not overlap, but the difference between their end time and the start time of another event is not greater than the preset time tolerance, the cloud node will classify them into the same conflict determination window. The preset time tolerance is configured and issued by the cloud node according to the job type before the task starts, and is used to accommodate the slight offset of the fragment boundary caused by the upload delay of different edge computing nodes.

[0147] Methods for determining spatial overlap In this embodiment, the cloud node determines spatial overlap based on the location coordinate range corresponding to the event.

[0148] For two event data, the cloud node first calculates the distance between their center coordinates and the degree of overlap between their positioning coordinate ranges. If the distance between their center coordinates is not greater than the preset spatial distance threshold and their positioning coordinate ranges overlap, then it is determined to be spatial overlap.

[0149] When the location coordinate range of a certain event data only includes the center coordinates and radius estimate due to the limited upload mode of the edge computing node, the cloud node uses the center coordinate distance not being greater than the sum of the two radius estimates as the condition for spatial overlap determination.

[0150] The preset spatial distance threshold is determined by the scale of the work area, the upper limit of the positioning error, and the size of the work object, and is sent to the cloud node before the task begins.

[0151] In this way, cloud nodes do not use the complete consistency of a single coordinate point as the criterion for judgment. Instead, they use temporal proximity and spatial coverage as the basis for conflict determination, so that multiple reports from different edge computing nodes on the same real event can be merged into the same conflict set.

[0152] Formation of conflict sets In this embodiment, the cloud node scans event data for the same task and the same work area one by one.

[0153] When two or more event data simultaneously meet the conditions of belonging to the same time window range and spatial overlap, the cloud node will classify them into the same conflict set.

[0154] Each conflict set should contain at least the following: conflict set identifier, a list of event identifiers within the set, the time the set was formed, the number of events within the set, and the set status.

[0155] If new event data is subsequently received, and this event data meets the conditions of the same time window range and spatial overlap with any event in an existing conflict set, then the new event data will be merged into the conflict set, instead of creating a new conflict set.

[0156] This rule allows cloud nodes to dynamically expand the conflict set as events continue to arrive, ensuring that conflict resolution is not affected by the order in which edge computing nodes upload data.

[0157] How to calculate event freshness In this embodiment, event freshness is used to characterize the timeliness of a certain event data relative to the current processing time.

[0158] The cloud node uses the time difference between the current processing time and the event's end timestamp as the event latency, and calculates the event freshness based on the event latency. The smaller the event latency, the higher the event freshness.

[0159] To facilitate calculations in conjunction with joint confidence and risk levels, cloud nodes normalize event freshness to between zero and one.

[0160] In one feasible approach, when the event latency is no greater than the first freshness duration, the event freshness is set to a high value range; when the event latency is greater than the first freshness duration but no greater than the second freshness duration, the event freshness decreases by a preset ratio; when the event latency is greater than the second freshness duration, the event freshness is set to a low value range.

[0161] The first and second freshness durations are configured by the cloud nodes before the task begins and are bound to the current task cycle.

[0162] Conflict priority calculation method In this embodiment, the cloud node calculates the conflict priority for each event data in the conflict set.

[0163] Conflict priority is determined by joint confidence level, risk level, and event novelty.

[0164] Among them, the joint confidence level is directly adopted from the joint confidence level value uploaded by the edge computing node; the risk level is first mapped to the numerical level and then normalized; the event freshness is normalized in the aforementioned manner.

[0165] Cloud nodes calculate conflict priority using the following formula: Where P is the conflict priority, C is the joint confidence level, G is the normalized risk level, F is the event novelty, and λ1, λ2 and λ3 are non-negative weight coefficients, and λ1 + λ2 + λ3 = 1.

[0166] The aforementioned weighting coefficients are pre-configured by cloud nodes according to the task type and remain unchanged throughout the task period.

[0167] This calculation method assigns higher conflict priority to event data that are combined with high confidence, high risk level, and high event freshness.

[0168] In this embodiment, if two event data have the same conflict priority, they are processed in parallel in the following order: first, the one with the higher risk level is retained; if the risk levels are still the same, the one with the higher event freshness is retained; if the event freshness is still the same, the one with the smaller event identifier is retained as the main event.

[0169] Through this parallel processing rule, cloud nodes can still output a definite main event when the conflict priorities are the same, and the conflict set will not remain in an unresolved state for a long time due to the parallel results.

[0170] Determining the main event and secondary events and establishing their relationships. In this embodiment, the cloud node selects the event data with the highest conflict priority in each conflict set as the master event, and marks the remaining event data as slave events.

[0171] The main event retains the original event identifier and serves as the main index for subsequent alarm display, statistical counting, parameter correction, and manual review.

[0172] The event is not deleted, but the original event identifier is retained and written to the event tag.

[0173] The cloud node establishes an association between each slave event and the master event. The association includes at least: master event identifier, slave event identifier, association establishment time, conflict set identifier, and association reason. The cause of association should at least be recorded as overlapping time windows and overlapping spaces.

[0174] When new event data is subsequently added to the conflict set, and the conflict priority of the new event data is higher than that of the current master event, the cloud node will promote the new event data to the new master event, re-mark the original master event as a slave event, and update the master event identifier of all slave events in the conflict set.

[0175] Through this dynamic update mechanism, the main event always corresponds to the most reliable, urgent, and timely event data within the current conflict set.

[0176] The synergistic relationship between conflict resolution results and subsequent links In this embodiment, after the cloud node completes the conflict resolution, it only uses the main event as the default event in the subsequent parameter update, risk statistics and external display process.

[0177] The event is not included in the duplicate count, but its content is retained for at least one of the following purposes: First, it is used to verify the consistency between the main event and the secondary event in terms of joint confidence, risk level, and reason code; Second, it can be used to supplement multi-source observation samples of the same real event during subsequent model evaluation; Third, it can be used to trace the differences in judgment of the same real event by different edge computing nodes during manual review.

[0178] Therefore, the conflict resolution in this embodiment is not simply deleting duplicate events, but retaining the secondary events and their relationships while uniformly outputting the main event, so that the cloud node can reduce duplicate alarms and retain a complete multi-source evidence chain.

[0179] Through the above implementation method, cloud nodes construct a conflict set based on the dual conditions of the same time window range and spatial overlap, and then calculate the conflict priority by jointly using confidence, risk level and event freshness, and finally determine the main event and the secondary event and establish the relationship.

[0180] This process is based on the credibility, risk level, and timeliness of the event data itself, without relying on the order of uploads or the results of a single edge computing node, thereby improving the consistency and traceability of cloud event merging.

[0181] In this embodiment, after the cloud node completes the determination of the main event and the association of the slave event, it does not directly send the new parameters to the edge computing node for effect without conditions. Instead, it first forms a parameter update package, and the edge computing node performs parallel verification of the current parameters and the parameter update package within the same verification sample window. The switch is only allowed to take effect when the parameter update package meets the preset switching conditions in the verification results and the current time is within the effective time period corresponding to the parameter update package. If any condition is not met, the edge computing node continues to run with the current parameters and performs a rollback report.

[0182] This processing method ensures that parameter correction, distribution, activation, and rollback are all completed under controlled conditions, avoiding the increase in false alarm rate, false alarm rate, or deterioration of discrimination latency caused by direct parameter replacement at edge computing nodes.

[0183] The generation method and field composition of the parameter update package In this embodiment, cloud nodes aggregate master event data and slave event data for the same task and the same work area according to the statistical period, and combine them with event samples that have been closed-loop processed and manually labeled to generate parameter update packages; the statistical period is preset by the task configuration and remains unchanged within the task period; When generating a parameter update package, the cloud node uses at least the following input data: the joint confidence level, risk level, reason code, upload mode, subsequent manual review results, difference records between the slave event and the master event, and retransmission anomaly records reported by the edge computing node; the cloud node calculates the threshold correction amount, weight correction amount, and upload strategy correction amount based on the above inputs, and encapsulates the correction results into a parameter update package.

[0184] In this embodiment, the parameter update package includes at least the following fields: threshold correction parameter, weight correction parameter, upload strategy correction parameter, target device range, version number, effective period, and rollback version number.

[0185] The threshold correction parameters include at least one correction value from the following: first threshold, second threshold, third threshold, consistency difference threshold, fusion risk score change slope threshold, and link level threshold. The weight adjustment parameters shall include at least one of the following adjustment values: the weight coefficient used for joint confidence calculation, the fusion weight lookup item used for fusion risk score calculation, and the weight coefficient used for conflict priority calculation. The upload strategy correction parameters shall include at least one of the following correction values: the index of the upload mode mapping table, the retry limit for retransmission, and the trigger threshold for the high-priority sending queue.

[0186] The target device scope includes at least the task identifier and the work area number; when it is necessary to refine it to a specific device, it also includes a list of edge computing node identifiers.

[0187] The version number identifies the current version of the parameter update package; the effective period limits the start and end times when the parameter update package is allowed to take effect.

[0188] The rollback version number is used to indicate that after the parameter update package has been switched, the parameters of the previous version should be restored if there are subsequent operational abnormalities.

[0189] To avoid cross-over between different update batches, cloud nodes generate parameter update packages for the same target device range in increments of version number. For parameter update packages with version numbers lower than or equal to the current parameter version number of the edge computing node, the edge computing node does not perform verification, but only records the version ignore mark and reports it to the cloud node.

[0190] How the verification sample window is formed In this embodiment, the edge computing node does not directly determine whether the parameter update package is available based on any arbitrary real-time event, but instead performs parallel verification of the current parameters and the parameter update package within the same verification sample window.

[0191] The verification sample window is established after the cloud node sends the verification window description information. The verification window description information includes at least the verification start time, verification end time, verification sample range, and minimum number of verification samples.

[0192] The scope of verification samples is selected first from candidate event segments that have been closed-loop processed and manually labeled. When the edge computing node still retains the standard data frame sequence of the corresponding candidate event segment locally, the edge computing node reads the local cache according to the event identifier and forms a verification sample window. If the edge computing node is missing some verification samples locally, the cloud node will resend the corresponding standard data frame sequence. The edge computing node will then fill in the missing data frame sequence according to a unified format before participating in the verification.

[0193] In this embodiment, the same verification sample window means that the current parameters and the parameter update package use the same batch of event identifiers, the same batch of candidate event segment boundaries, and the same batch of standard data frame sequences for discrimination. It is not allowed for the two to use different sample sources, different sample numbers, or different boundary definitions. Through this restriction, the verification results of the current parameters and the parameter update package are consistent in terms of time range, sample range, and input data, thereby ensuring that the false alarm rate, false negative rate, and average discrimination delay are comparable.

[0194] Parallel verification execution method In this embodiment, the edge computing node establishes independent parameter instances for the current parameters and parameter update packages, and uses the standard data frame sequence in the same verification sample window as input to perform joint confidence calculation, candidate event fragment discrimination, fusion risk score calculation, risk level determination, cause code generation, and upload mode selection in the same order.

[0195] The current parameter instance outputs a set of current verification results, and the parameter update package instance outputs a set of updated verification results. The two sets of verification results are recorded in the local verification result table. The verification result table includes at least the event identifier, judgment result, risk level, reason code, judgment completion time, and parameter version number used.

[0196] In this embodiment, the edge computing node uses the event results that have been processed in a closed loop and manually labeled as a reference to calculate the false alarm rate and false negative rate for the two sets of verification results.

[0197] The false alarm rate was the percentage of samples that were identified as risk events but were manually labeled as non-risk events. The underreporting rate is the percentage of samples that were judged as non-risk events but were manually labeled as risk events.

[0198] The average discrimination delay is the average processing time from the input of a candidate event segment to the output of the discrimination result of that candidate event segment.

[0199] After completing the parallel verification of all samples in the same verification sample window, the edge computing nodes obtain the false alarm rate, false negative rate, and average discrimination latency corresponding to the current parameters, as well as the false alarm rate, false negative rate, and average discrimination latency corresponding to the parameter update package.

[0200] Method for determining switching conditions In this embodiment, edge computing nodes are only allowed to replace current parameters with parameter update packages if the following conditions are met simultaneously, and the current time falls within the effective period corresponding to the parameter update package: First, the false alarm rate corresponding to the parameter update package is not higher than the false alarm rate corresponding to the current parameters; Second, the false negative rate corresponding to the parameter update package is not higher than the false negative rate corresponding to the current parameters; Third, the average discrimination latency corresponding to the parameter update package is not higher than the preset latency limit; Fourth, the number of valid samples within the verification sample window shall not be less than the preset lower limit of samples.

[0201] Among them, the preset latency upper limit and the preset sample lower limit are configured by the cloud node and sent to the edge computing node before the task starts. Valid samples refer to samples that have completed the complete discrimination process within the verification sample window and have clear manual annotation results.

[0202] When the number of validation samples is insufficient, parameter switching is not allowed even if the false alarm rate, false negative rate, and average discrimination delay meet the requirements.

[0203] If the current time is not within the effective period of the parameter update package, the edge computing node will not perform parameter switching and will mark the parameter update package as pending or expired.

[0204] In this embodiment, the edge computing node makes a judgment on each of the above conditions. If any condition is not met, the parameter update package is determined to be unsuitable for switching. In order to avoid false switching due to instantaneous statistical fluctuations, the edge computing node makes a switching judgment only once within the same verification sample window and does not take effect prematurely in the middle of the window.

[0205] Parameter switching execution method When the parameter update package meets the switching conditions and is currently within the effective period, the edge computing node will perform version switching after the current judgment period ends.

[0206] When performing a switchover, the edge computing node first writes the current parameter version number into the historical version record, then writes the version number in the parameter update package into the current parameter record, and loads all the corrected parameters in the parameter update package as the new running parameters at once.

[0207] The switching process uses an atomic update method, which keeps the current parameters in service until the parameter writing is complete, and then the new parameters take over after the parameter writing is complete, thus avoiding a mixed state where some parameters have been updated and some have not been updated during the processing of the same candidate event segment.

[0208] After the parameter update package completes the switch, its rollback version number is retained in the local parameter record for use in case of subsequent runtime anomalies to restore the previous version of parameters.

[0209] Triggers and content of rollback reports When the parameter update package does not meet any switching conditions, or when the current time is not within the effective period corresponding to the parameter update package, the edge computing node does not perform parameter switching, but continues to run with the current parameters and generates a rollback report record.

[0210] The rollback reporting record should include at least the following: task identifier, job area number, edge computing node identifier, current parameter version number, parameter update package version number, rollback version number, unmet conditions, false alarm rate comparison result, false negative rate comparison result, average discrimination delay comparison result, number of valid samples, and rollback reporting time.

[0211] Edge computing nodes will prioritize sending rollback reporting records to cloud nodes. Based on this, cloud nodes will mark the current parameter update package as invalid and can readjust the threshold correction parameters, weight correction parameters, or upload strategy correction parameters according to the reason for failure before generating a new parameter update package.

[0212] In this embodiment, if after the edge computing node has completed parameter switching, it detects that the false alarm rate after parameter update is higher than the baseline value before switching, the missed alarm rate is higher than the baseline value before switching, or the average discrimination delay is higher than the preset delay limit within a number of consecutive statistical windows, then the edge computing node restores to the previous version parameters according to the rollback version number and generates runtime rollback reporting records in the same format.

[0213] Through this mechanism, edge computing nodes are not only subject to controlled verification before switching, but also retain a recoverable path after switching, making the parameter update link traceable and recoverable.

[0214] Collaboration with pre- and post-processing links In this embodiment, the parameter update package is generated primarily based on the main events after the conflict resolution in the previous stage, and the correction is based on the event difference records and manual annotation results. Therefore, the source of parameter updates is consistent with the event merging results of the cloud nodes.

[0215] Before switching, edge computing nodes use the same verification sample window for parallel verification, so that the parameter update package is compared with the current parameters under the same input conditions, thereby ensuring that the switching decision has a consistent comparison basis.

[0216] After a successful switchover, the new threshold correction parameters, weight correction parameters, and upload strategy correction parameters directly affect subsequent joint confidence calculation, fusion risk score calculation, upload mode determination, and conflict priority calculation. If the switchover fails, the edge computing node reports the reason for the failure to the cloud node through a rollback report, so that the parameters can be readjusted in subsequent update cycles.

[0217] Therefore, the parameter update in this embodiment is not a static process that is immediately overwritten after a single distribution, but is completed in a closed-loop link of cloud statistical generation, edge parallel verification, switching when conditions are met, rollback and reporting when conditions are not met, and recovery during runtime, so that the parameter update process is consistent with the entire data processing link.

[0218] With the above implementation method, the parameter update package generated by the cloud node does not take effect immediately after entering the edge computing node. Instead, it first compares the false alarm rate, false negative rate, average discrimination latency and number of valid samples item by item in the same verification sample window, and then determines whether to switch based on the effective time period. This makes the parameter update process have clear effective conditions, rollback basis and version traceability relationship.

[0219] In this embodiment, after the edge computing node and the cloud node complete the candidate event fragment discrimination, upload mode determination, event upload, spatiotemporal correlation and conflict resolution, they respectively generate event sequence summaries for the same event and perform summary consistency verification using the event identifier as an index.

[0220] This process does not simply compare ordinary fields of a single event record, nor does it rely solely on event identifiers to determine consistency. Instead, it concatenates the previous event sequence summary with the key fields of the current event, the current event timestamp, and the current event random number in a fixed order, and then generates a new event sequence summary using the same one-way hash function.

[0221] In this way, edge computing nodes and cloud nodes can perform consistency verification on key event content while preserving the order of events, making event records not only verifiable but also sequentially related.

[0222] Event sequence summary generation objects and generation timing In this embodiment, the event sequence summary is generated in units of individual events.

[0223] After determining the risk level of the current event, generating the cause code, and uploading the payload encapsulation, the edge computing node generates an edge-side event sequence summary of the current event.

[0224] After receiving the uploaded data corresponding to the event and completing the determination of the main event or association with the secondary event, the cloud node generates a cloud-side event sequence summary for the current event.

[0225] Both edge computing nodes and cloud nodes use the same event identifier as an index, so that the same event has a one-to-one corresponding summary record at both ends.

[0226] To ensure the continuity of the summary chain, the event sequence summary is generated one event at a time in the order in which the events occur.

[0227] For the first event within the same task and the same work area, the summary of the previous event sequence uses the task initialization summary value. This task initialization summary value is sent from the cloud node to the edge computing node before the task begins and remains consistent between the edge computing node and the cloud node.

[0228] For events that are not the first event, the previous event sequence summary is taken from the previous event sequence summary generated within the same task and the same work area.

[0229] The cloud nodes arrange events within the same task and the same work area in order of event end time and event identifier. For subsequent events that do not yet have a summary of preceding events, the cloud nodes first write them into the queue to be summarized. After the summary of preceding events is generated, the event sequence summary of the subsequent event is generated.

[0230] The composition and fixed encoding rules of the current event's key field set In this embodiment, the current event key field set At least the following fields should be included: Event Identifier Event start time Event End Time Risk level Reason code All of the above fields are derived from the event processing results already completed by the aforementioned edge computing nodes or cloud nodes, and no new derived fields are generated separately.

[0231] Among them, the event identifier is obtained by combining the task identifier, edge computing node identifier and candidate event segment start time window number as defined above; the event start time and event end time are taken from the start timestamp and end timestamp of the candidate event segment; the risk level and cause code are taken from the results finally determined in the aforementioned fusion discrimination stage.

[0232] To avoid different digests generated by edge computing nodes and cloud nodes due to different field encoding methods, this embodiment adopts a fixed encoding rule for the set of key fields of the current event.

[0233] Fixed encoding rules should include at least: The fields are arranged in a preset order; Numeric fields should be represented using a uniform length or a uniform text format; The time field uses a unified time base and a unified precision. Fields are joined together using a fixed delimiter; Empty fields use fixed null placeholders.

[0234] Both edge computing nodes and cloud nodes use the same encoding rules to convert the set of key fields of the current event into a data string in a fixed format before participating in the event sequence summary calculation.

[0235] How to determine the current event timestamp and the current event random number In this embodiment, the current event timestamp The event end timestamp carried in the current event upload payload is used uniformly. Both edge computing nodes and cloud nodes use this event end timestamp to participate in the event sequence summary calculation, so as to avoid inconsistencies in the summary due to different local processing completion times.

[0236] In this embodiment, the current event random number It is generated by the edge computing node when the payload is first uploaded and encapsulated in the current event.

[0237] The random number for the current event is generated using a local random number generator and corresponds one-to-one with the current event identifier. After generating the random number for the current event, the edge computing node writes it as one of the current event summary fields into the upload payload and uploads it to the cloud node along with the event data.

[0238] Instead of regenerating new random numbers, cloud nodes directly use the random numbers of the current event carried in the current event's uploaded payload to participate in the digest calculation.

[0239] In this way, edge computing nodes and cloud nodes use the same current event random number for the same event, thus ensuring that the input for summary calculation is consistent.

[0240] When the same event is subsequently retransmitted, reviewed, or re-enqueued, the initial random number generated for the current event will still be used, and a new random number will not be generated.

[0241] In this embodiment, both the edge computing node and the cloud node generate an event sequence summary of the current event in the following manner: ; A summary of the event sequence for the current event; This is a summary of the previous event sequence. This is the set of key fields for the current event. This is the timestamp of the current event. A random number for the current event; In this embodiment, the one-way hash function is a preset fixed-length digest algorithm. The edge computing nodes and cloud nodes use the same one-way hash algorithm, and the number of output bits remains consistent.

[0242] Before computation, edge computing nodes and cloud nodes first process H(i-1), The data is concatenated into a single input data string in a preset order, and then a one-way hash operation is performed on the input data string to obtain an event sequence summary of the current event.

[0243] Edge computing nodes write edge-side event sequence summaries to local event summary tables and upload event identifiers, edge-side event sequence summaries, previous event sequence summaries, current event timestamps, and current event random numbers to cloud nodes along with the event data.

[0244] The cloud node writes the cloud-side event sequence summary into the cloud event summary table.

[0245] Both the edge-side event summary table and the cloud-side event summary table must include at least: event identifier, previous event sequence summary, current event timestamp, current event random number, current event sequence summary, and generation time.

[0246] How to perform digest consistency verification In this embodiment, after generating a cloud-side event sequence summary, the cloud node uses the event identifier as an index to search for the edge-side event sequence summary uploaded by the edge computing node.

[0247] When the digest values ​​of the two events are the same, and the digest of the previous event sequence, the timestamp of the current event, and the random number of the current event are all consistent, the current event is determined to have passed the digest consistency check.

[0248] After passing the digest consistency check, the cloud node marks the event as a digest consistent event and allows the event to enter the subsequent statistical summary, parameter correction and manual review process.

[0249] After receiving a summary consistency confirmation message from the cloud node, the edge computing node changes the status of the local summary record corresponding to the current event to "confirmed".

[0250] When a cloud node discovers that the event sequence summary on the edge side is inconsistent with the event sequence summary on the cloud side, or that any of the corresponding previous event sequence summary, current event timestamp, and current event random number are inconsistent, it determines that the current event has failed the summary consistency check and triggers a retransmission and review process.

[0251] Triggering, Execution, and Limit Control of Re-transmission Review In this embodiment, the purpose of retransmission verification is to re-verify the key inputs that cause digest inconsistencies and determine whether the digest differences are caused by transmission loss, field encoding differences, payload corruption, or link anomalies.

[0252] When a cloud node triggers a retransmission review, it sends a review instruction to the corresponding edge computing node. The review instruction includes at least the following: event identifier, current review count, range of fields to be retransmitted, and reason for review triggering.

[0253] The range of fields that need to be retransmitted includes at least: the set of key fields of the current event, the timestamp of the current event, the random number of the current event, and the sequence summary of the previous event. The cloud node reassembles the summary input data string according to the same fixed encoding rules as the edge computing node, and then performs the event sequence summary calculation.

[0254] After receiving the review instruction, the edge computing node re-extracts the local event record according to the event identifier, and re-encapsulates the data within the field range that needs to be retransmitted before sending it to the cloud node.

[0255] After receiving the retransmitted verification data, the cloud node recalculates the cloud-side event sequence digest using the same encoding rules and the same one-way hash function, and performs digest consistency verification again.

[0256] In this embodiment, the maximum number of retransmissions for verification is U, where U is a positive integer. It is written into the task parameter table by the cloud node before the task starts and remains unchanged during the task cycle.

[0257] Failure of the initial digest consistency check is not counted in the number of re-checks. The number of re-checks begins to be counted after the first re-transmission re-check fails.

[0258] The cloud node maintains a counter for the number of re-transmissions for the same event. Each time a re-transmission re-transmission fails, the number of re-transmissions is incremented by one. When the number of re-transmissions is less than U, the cloud node allows the re-transmission re-transmission to continue to be triggered. When the number of re-transmissions reaches U, the cloud node stops the automatic re-transmission re-transmission and outputs a manual re-transmission flag.

[0259] The manual review marker includes at least: event identifier, current review count, reason for digest inconsistency, edge-side event sequence summary, cloud-side event sequence summary, and the last re-transmission review time; events with manual review markers will no longer enter the automatic digest consistency check retry queue, but will be transferred to the manual processing flow.

[0260] Digest consistency verification and its coordination with upstream and downstream links In this embodiment, the event sequence summary is not additional information generated independently of the aforementioned event processing chain, but is directly input from the previous event sequence summary, the current event key field set, the current event timestamp, and the current event random number.

[0261] Among them, the set of key fields of the current event comes from the discrimination results of the aforementioned candidate event segments; the timestamp of the current event comes from the event end timestamp; the random number of the current event is generated when the edge computing node uploads for the first time and remains unchanged; the summary of the previous event sequence comes from the summary record of the previous event in the same task and the same work area.

[0262] Therefore, the event sequence summary naturally inherits the event order, fragment boundaries, risk level and cause code in the aforementioned event processing chain, and will not exist independently of the previous processing results.

[0263] Meanwhile, the results of the digest consistency check directly affect subsequent links: Events with consistent abstracts can directly proceed to the statistical, parameter update, and manual review processes; Events with inconsistent abstracts must first undergo resubmission and verification. Once the maximum number of verifications is reached, the process will be transferred to manual processing.

[0264] In this way, edge computing nodes and cloud nodes not only maintain field consistency when uploading events, but also form a continuously verifiable sequential relationship on the event summary chain, enabling event records within the same task to have continuous verifiable capabilities.

[0265] By using the above implementation method, the summary of the previous event sequence and the key fields of the current event are used as input, so that the summary result of the current event and the summary of the previous event form a continuous summary chain; at the same time, the automatic retry range is limited by the maximum number of retransmissions for review, and a manual review mark is output when the upper limit is reached, so that the summary consistency verification has both automatic verification capability and a clear abnormal exit path.

[0266] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0267] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A data processing method for intelligent safety helmets used in high-altitude operations based on edge computing and end-to-cloud collaboration, characterized in that, include: The smart safety helmet collects work data according to the sampling period and generates raw data frames. The raw data frames contain at least a frame number, a task identifier, and a timestamp. Edge nodes perform time alignment, missing padding, and noise suppression on the original data frame to obtain a standard data frame; Edge nodes segment standard data frames according to frame sequence numbers to obtain candidate event segments; Edge nodes calculate a first joint confidence score for candidate event segments. When the first joint confidence score is lower than a first threshold, additional sampling is performed and a second joint confidence score is calculated. When the second joint confidence score is lower than the first threshold, the candidate event segment is marked as an invalid segment and risk discrimination is terminated. When the second joint confidence score is not lower than the first threshold, risk discrimination is performed. Edge nodes perform predefined discrimination and model discrimination in parallel on candidate event fragments that have passed confidence gating, and obtain rule scores and model scores. Based on the rule scores and model scores, they calculate the fusion risk score, risk level, and consistency difference. Edge nodes determine the upload mode and upload event data to the cloud based on risk level, consistency difference, slope of change of fusion risk score and link level; The cloud performs spatiotemporal correlation and conflict resolution on event data uploaded by multiple edge nodes in the same work area, generates parameter update packages, and sends them to the corresponding edge nodes; Edge nodes process the same event stream in parallel with current parameters and parameter update packages within the same verification sample window. When the switching conditions are met, the parameter update package is enabled. When the switching conditions are not met, the current parameters are maintained and a rollback report is performed. The edge node and the cloud generate event sequence summaries respectively and perform consistency checks according to the event identifier. When the checks are consistent, an early warning command is output. When the checks are inconsistent, a retransmission and review are triggered.

2. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 1, characterized in that: The operational data includes angular velocity, linear acceleration, relative altitude, positioning coordinates, temperature, humidity, gas concentration, heart rate, and wearing status; the relative altitude is obtained by fusing barometric altitude and ranging altitude; the positioning coordinates are obtained by fusing satellite positioning coordinates and near-range positioning coordinates.

3. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 2, characterized in that: The time alignment uses a fixed time window alignment; the missing data completion uses the previous valid sample to retain and record the missing data marker; the noise suppression uses a sliding window mid-value filter.

4. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 3, characterized in that: Event segmentation satisfies the following rules: a candidate event segment is established when any of the following conditions are met: the absolute value of angular velocity exceeds the initial threshold, the positioning point enters the electronic fence boundary area, or the operation status is switched from the climbing state to the operation state; the candidate event segment is closed when any of the following conditions are met: the absolute value of angular velocity is lower than the end threshold and lasts for a first duration, or the positioning point leaves the electronic fence boundary area and lasts for a second duration.

5. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 4, characterized in that: The first joint confidence level and the second joint confidence level are both calculated using the following formula: ,in, The sensor consistency coefficient. The time sequence integrity coefficient. The feature effectiveness coefficient, These are non-negative weighting coefficients, and Supplementary sampling is achieved by increasing the sampling frequency to K times the basic sampling frequency and continuing for T sampling periods, where K is an integer greater than 1 and T is a positive integer.

6. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 5, characterized in that: The risk score is calculated using the following formula: ； The consistency difference is calculated using the following formula: ； in, For the rule score, For model scores, For fusion weights; The risk level is determined by looking up a table based on the work status and data quality markers; the risk level is classified according to the relationship between R and the second and third thresholds; the cause code is determined by the risk feature that exceeds the normalized threshold the largest, and in the case of ties, it is determined according to the preset priority table.

7. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 6, characterized in that: The upload mode is determined by a preset mapping table based on risk level, consistency difference grading, fusion risk score change slope grading, and link level grading; the upload mode includes summary upload, feature fragment upload, and original fragment upload; when the link is unavailable, the edge node writes the data to be uploaded into the local persistent queue according to the event identifier, and re-uploads it in the order of the event identifier after the link is restored, and deletes the corresponding cache record after receiving confirmation from the cloud.

8. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 7, characterized in that: Conflict resolution includes: calculating the conflict priority of multiple event data that are in the same time window and spatially overlapped, wherein the conflict priority is calculated by joint confidence, risk level and event freshness; the cloud retains the event data with the highest conflict priority as the master event, and marks the remaining event data as slave events and establishes a relationship between them.

9. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 8, characterized in that: The parameter update package must include at least the threshold correction parameters, weight correction parameters, upload strategy correction parameters, target device range, version number, effective period, and rollback version number. The switching conditions are: within the same verification sample window, the parameter update package must simultaneously meet the following conditions: the false alarm rate is not higher than the current parameters, the false negative rate is not higher than the current parameters, the average discrimination delay is not higher than the delay limit, and the number of verification samples is not less than the preset sample lower limit N0. If any condition is not met, rollback reporting will be performed.

10. The data processing method for intelligent safety helmets for high-altitude operations based on edge computing and end-to-cloud collaboration according to claim 9, characterized in that, Event sequence summaries are generated using the following formula: ； in, This is a summary of the previous event sequence. This is the set of key fields for the current event. This is the timestamp of the current event. A random number for the current event; The set of key fields of the current event This includes the event identifier, event start time, event end time, risk level, and reason code; the maximum number of re-reviews is U, and a manual review flag is output when the number of reviews reaches U.

Images