Hydrogen energy supervision method and system based on big data processing

CN122819941APending Publication Date: 2026-09-25南京弘竹泰信息技术有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611312003.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-08-27
Publication Date
2026-09-25

AI Technical Summary

Technical Problem

在通信中断或数据质量下降期间,若仅依据最新测量值解除预警,可能导致状态提前恢复

Benefits of technology

1、本发明通过在边缘侧将不同协议的测点数据归一化为同时包含事件标识、资产与批次标识、事件时间、质量标志及版本字段的统一事件包,并由云侧在同一事件时间窗口内读取该统一事件包进行特征计算和追溯建边,能够使制氢、储氢、输氢、加氢和用氢数据保持一致的时间、单位与身份关系;风险证据、批次流向和数量变化能够沿同一记录进行关联,从而减少了跨环节数据孤立以及单点告警难以定位上下游影响范围的问题。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122819941A_ABST
    Figure CN122819941A_ABST
Patent Text Reader

Abstract

The present application relates to hydrogen energy data processing technical field, specifically relates to a kind of hydrogen energy supervision method and system based on big data processing.The present application is by in edge side different protocol's measuring point data is normalized as the uniform event package containing event identification, asset and batch identification, event time, quality mark and version field simultaneously, and is read by cloud side in the same event time window this uniform event package carries out feature calculation and traces edge, can make hydrogen production, hydrogen storage, hydrogen transport, hydrogenation and hydrogen data keep consistent time, unit and identity relationship;Risk evidence, batch flow direction and quantity change can be associated along the same record, thereby reducing the problem of cross-link data isolation and single-point alarm difficult to locate upstream and downstream influence range.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention belongs to the field of hydrogen energy data processing technology, specifically relating to a hydrogen energy regulatory method and system based on big data processing. Background Technology

[0002] Different stages of the hydrogen energy industry chain are equipped with data acquisition devices for concentration, pressure, temperature, liquid level, flow rate, leakage, equipment status, or on-board data. These data sources cover hydrogen production equipment, hydrogen storage facilities, hydrogen transportation facilities, hydrogen refueling stations, and hydrogen consumption terminals. Due to differences in communication protocols, asset codes, units of measurement, and sampling cycles used at different stages, the collected data is typically stored scattered across various sites or business systems. This makes it difficult to correlate events occurring during the production, storage, transportation, refueling, and use of the same batch of hydrogen using a unified identifier and timeline.

[0003] During risk identification, when judgments are made based on a single measurement point and a fixed threshold, changes in the normal baseline of the equipment and alterations in environmental conditions can affect the judgment results. Conversely, when thresholds are updated solely based on historical data, persistently abnormal or low-quality data may be included in the baseline. Furthermore, concentration changes may be related to multiple factors such as sensor status, pressure variations, inlet / outlet flow differences, and communication quality; relying on a single dimension is insufficient to effectively distinguish between actual leaks, sensor anomalies, and transmission anomalies. The edge computing side needs to promptly generate on-site judgments, while the cloud side needs to complete cross-site calculations, end-to-end traceability, and multi-entity response. When the rule versions and input event sets used on both sides are inconsistent, contradictory regulatory situations can arise.

[0004] After an early warning message is issued, it is also necessary to associate records of confirmation, handling, retesting, observation, and closure with the original event, risk evidence, and the batches involved. If the warning is lifted solely based on the latest measurement during a communication outage or data quality degradation, the status may be prematurely restored.

[0005] To address the aforementioned issues, this invention proposes a hydrogen energy regulatory method and system based on big data processing. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, the present invention aims to provide a hydrogen energy regulation method and system based on big data processing.

[0007] To achieve the above-mentioned objectives, the technical solution adopted by this invention is as follows: A hydrogen energy regulatory method based on big data processing includes: Data from various points in the hydrogen energy industry chain are collected, and after protocol parsing and identifier binding, a unified event package is generated and uploaded to the cloud. The edge side and the cloud side perform window sorting and data quality judgment on the unified event package according to the same data contract to form a multi-dimensional feature vector. Risk scores are calculated based on the multidimensional feature vectors and dynamic thresholds constrained by fixed security boundaries. The risk calculation results on the edge side and the cloud side are verified, and risk events are output. A directed traceability relationship is established based on the batch association identifiers in the risk events, and the risk impact subgraph is expanded. Based on the risk events and the risk impact subgraph, risk status migration is performed, tiered early warning and handling work orders are generated, and recovery counts are maintained when data quality degrades; abnormal data is isolated based on the handling feedback results, candidate baselines are formed and version parameter packages are generated, and after being verified and activated at the edge, they enter the next regulatory cycle.

[0008] Preferably, measurement data from various stages of the hydrogen energy industry chain are collected, and after protocol parsing and identifier binding, a unified event package is generated, including: Collect measurement values ​​or equipment status from hydrogen production, storage, transportation, refueling and utilization processes; the multi-protocol data access gateway parses the original protocol based on the asset mapping table. Edge computing nodes are converted to indicator codes, units, and time bases, which are then bound to enterprise, site, asset, sensor, and available batch, container, or vehicle identifiers. Global event identifiers are generated using site, sensor, sampling time, and serial number; only one valid record is retained for the same event identifier. A unified event package should include at least the event identifier, event type, raw value and unit, standard value and unit, sampling time, reception time, sequence number, quality flag, sensitivity level, and data contract version. In the event of duplicate, out-of-order, or network outage, the edge computing node deduplicates the events according to the event identifier and writes the events into the circular buffer. After communication is restored, the events are retransmitted in order starting from the next event after the last confirmed sequence number on the cloud side.

[0009] Preferably, the edge side and cloud side perform window sorting and data quality assessment on the unified event package according to the same data contract, forming a multi-dimensional feature vector, including: Edge computing nodes and cloud-based monitoring and processing platforms use the same data contract and window configuration, sorted by assets, indicators, event time, and water level; late events within the correction period are allowed to update unclosed windows, while events exceeding the time limit are only audited and played back offline; Data coverage is the ratio of valid and non-repeating events to the total number of events that should be received in the window; when the data coverage is less than the preset first coverage threshold, a degraded status is output and the recovery count is paused; when the data coverage is greater than or equal to the first coverage threshold but less than the preset second coverage threshold, the calculation result is retained and marked as low confidence; when the data coverage is greater than or equal to the second coverage threshold, it is processed as a valid window.

[0010] Preferably, the risk score is calculated based on the multidimensional feature vector and a dynamic threshold constrained by a fixed safety boundary, and the risk calculation results on the edge side and the cloud side are verified to output risk events, including: For indicators where an increase in value indicates an increase in risk, a robust scaling factor is calculated based on the baseline median and median absolute deviation. The product of the robust scaling factor and the sensitivity coefficient is added to the baseline median and compared with a fixed safety boundary. The smaller value is taken as the dynamic warning threshold. The set of baselines used to determine the dynamic threshold consists of a window with normal risk status, valid data quality, and complete traceability. The degree of exceeding the threshold is determined by the degree of deviation of the current monitoring value from the dynamic early warning threshold and the fixed safety boundary. The rate of change characteristic is determined by the positive rate of change of the current monitoring value relative to the previous effective window monitoring value. The supporting characteristics are determined by the pressure deviation indication value and the flow imbalance indication value. The fusion risk score is obtained by weighted summing of the degree of exceeding the threshold, the rate of change characteristic, the supporting characteristics and the asset consequence coefficient. When the current monitoring value reaches the fixed safety boundary or the equipment hard alarm is effective, an emergency risk event is directly formed; when the calculation results on the edge side and the cloud side are inconsistent, the higher risk level is retained and a version verification event is generated.

[0011] Preferably, a directed traceability relationship is established based on the batch association identifier in the risk event, and the risk impact subgraph is expanded, including: Using batches, containers, vehicles, sites, and equipment as nodes, and production, loading, transfer, receiving, filling, consumption, batch splitting, and batch merging as directed edges, the risk impact subgraph is formed by reverse tracing of the source batch from the risk asset and forward tracing of the downstream receiving or using node. When splitting a batch, the quality allocation from the parent batch to multiple sub-batches is saved, and when merging a batch, the quality allocation from multiple parent batches to one sub-batch is saved. Calculate the quality balance residual, which is the ratio of the absolute value of the difference between the input and output, inventory change and correction to the input. When the input is zero or a key measurement is missing, the quality balance state is taken as uncalcifiable and the missing quantity is listed.

[0012] Preferably, risk state transitions are performed based on the risk event and risk impact subgraph, generating tiered early warning and handling work orders, and maintaining recovery counts during data quality degradation, including: Risk status includes normal, attention, warning, and emergency; when the risk score of a consecutive preset number of valid windows is in the first risk range, it changes from normal to attention; when the risk score of a consecutive preset number of valid windows is in the second risk range, it changes to warning; when the risk score of a single valid window reaches the third risk range or triggers a fixed safety boundary, it changes to emergency. Upon recovery, the emergency status is converted to a warning after obtaining manual confirmation and the risk score of a consecutive preset number of valid windows is lower than the first preset threshold. The warning status is converted to a concern status after the risk score of a consecutive preset number of valid windows is lower than the second preset threshold. The concern status is converted to a concern status after the risk score of a consecutive preset number of valid windows is lower than the third preset threshold. The risk recovery conditions, responsible person confirmation and evidence completeness of the current work order are checked. If all are met, the current work order is closed and the risk status is changed to normal. When the data quality status is downgraded or isolated, the current recovery count is maintained, and new effective risks can still drive the status upgrade; the work order records the status in sequence as open, confirmed, processing, under observation and closed. During the observation period, if the same risk reaches the warning condition again, a reopen status is generated and associated with the original work order.

[0013] Preferably, based on the feedback results of the handling, abnormal data is isolated, candidate baselines are formed, and a version parameter package is generated. After activation through edge-side verification, it enters the next regulatory cycle, including: Confirmed real anomalies, sensor malfunctions, communication failures, and false alarms are stored separately; the window of observation period from the occurrence of an anomaly to the closure of the work order is entered into the isolated sample set. Candidate baselines are formed from windows with normal risk status, valid data quality, and complete traceability; after performing offline replay on the candidate dynamic thresholds or models, the risk level, hard boundary events, and version differences are compared between the original version and the candidate version; Once the candidate version maintains the level of all hard boundary events and passes the review, a signature parameter package containing the version number, effective time, applicable asset scope, feature definition, verification summary, and rollback version is generated. After receiving the signature parameter packet, the edge computing node verifies the signature, applicable asset scope, and effective time, and returns receipts in sequence: received, verified, and activated. If the verification or activation conditions are not met, the most recent valid version is restored.

[0014] This invention also provides a hydrogen energy regulatory system based on big data processing, comprising: The data acquisition unit is used to collect measurement data from various points in the hydrogen energy industry chain. Edge computing nodes are used to perform protocol parsing and identifier binding on measurement point data, generate unified event packets, and perform data quality judgment and risk calculation according to the currently activated window configuration and parameter version. The cloud-based monitoring and processing platform is used to receive unified event packets, sort them by window according to the same data contract, and determine data quality to form a multi-dimensional feature vector. The dynamic threshold and risk calculation unit is used to calculate risk scores based on multi-dimensional feature vectors and dynamic thresholds constrained by fixed security boundaries, and to verify the risk calculation results on the edge side and the cloud side, and output risk events. The traceability and accounting unit is used to establish directed traceability relationships based on batch association identifiers in risk events and to expand the risk impact subgraph. The early warning and work order unit is used to perform risk status migration based on risk events and risk impact subgraphs, generate hierarchical early warning and handling work orders, and maintain recovery counts when data quality degrades. The parameter feedback and version management unit is used to isolate abnormal data based on the handling feedback results, form candidate baselines and generate version parameter packages, which are then activated by edge side verification and enter the next regulatory cycle.

[0015] Preferably, the edge computing node binds the enterprise, site, asset, sensor, and available batch, container, or vehicle identifier to each measurement event, generating event identifier, serial number, event time, initial quality standard, sensitivity level, and version fields; the unified event package includes at least the event identifier, process type, original value and unit, standard value and unit, sampling time, receiving time, serial number, quality mark, sensitivity level, and data contract version; Edge computing nodes also perform idempotent deduplication, short window aggregation, fixed security boundary fast judgment, and risk calculation to generate edge risk results with a summary of the input event set, data contract version, and rule version, and perform network outage caching. When communication is interrupted, the most recently valid version parameter package is used to perform fixed security boundary judgment and cache unified event packages. After communication is restored, the data is retransmitted in sequence starting from the next item after the last confirmed sequence number on the cloud side.

[0016] Preferably, when an edge computing node loses connection, the cloud-side monitoring and processing platform sets the data quality status to isolation and maintains the highest risk level before the loss of connection. After the node recovers, it checks the clock, rule version, and cache integrity. When a single sensor is abnormal and no similar redundant sensors, pressure, or flow data provide corroboration, the dynamic threshold and risk calculation unit outputs a low-confidence risk event and generates a calibration work order. When multiple independent features provide corroboration, the risk level is determined based on the fusion result or a fixed security boundary. The parameter feedback and version management unit forms candidate baselines from windows with normal risk status, valid data quality, and complete traceability. It performs offline playback on candidate thresholds or models to generate parameter packages with effective time, applicable asset scope, verification summary, and rollback version. After signing, the parameter packages are sent to edge computing nodes, which sequentially return receipt, verification passed, and activation confirmations.

[0017] Beneficial effects 1. This invention normalizes measurement point data from different protocols into a unified event package at the edge, which simultaneously includes event identifier, asset and batch identifier, event time, quality mark, and version fields. The cloud side reads this unified event package within the same event time window for feature calculation and traceability edge construction. This enables hydrogen production, storage, transportation, refueling, and consumption data to maintain consistent time, unit, and identity relationships. Risk evidence, batch flow, and quantity changes can be correlated along the same record, thereby reducing the problems of data isolation across links and difficulty in locating the upstream and downstream impact range of single-point alarms.

[0018] 2. This invention utilizes robust dynamic thresholds formed by historical normal high-quality windows, fixed safety boundaries that cannot be raised by dynamic thresholds, multi-dimensional feature risk scores, and data quality status in a coordinated manner. It also enables the edge side and cloud side to carry the same rule version for recalculation. This allows the thresholds to remain adaptable when the device baseline changes and to directly form an emergency state when a hard boundary is triggered. When data coverage is insufficient, the recovery count is paused while the upgrade path is retained. This reduces the problems of insufficient adaptation of fixed thresholds to changes in operating conditions and risk state shifts caused by abnormal samples entering the baseline.

[0019] 3. This invention uses risk events to drive batch traceability, quality balancing, and carbon accounting input aggregation. Then, it sends the impact sub-graph, data quality status, and disposal evidence into a state machine with manual confirmation and continuous recovery windows. The feedback evaluation results are then isolated, played back offline, and reviewed before being issued. This enables the formation of auditable status records for early warning, confirmation, disposal, observation, closure, and reproduction / reopening. Even when there is a network outage, version mismatch, or data has not yet been recovered after disposal, the corresponding risk or downgraded status can still be maintained. This reduces the problems of scattered disposal records from multiple entities, premature cancellation of early warnings, and online parameter updates polluting the normal baseline. Attached Figure Description

[0020] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a system module diagram of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments. It should be understood that the specific embodiments described herein are merely for explaining the invention and are not intended to limit the scope of protection of the invention.

[0022] Example 1 Please see Figure 1 As shown, this embodiment provides a hydrogen energy regulation method based on big data processing, which includes the following steps: S1. Collect multi-source heterogeneous data, generate a unified event package after protocol parsing and identifier binding, and upload it to the cloud. The data acquisition unit receives measurements or equipment status from hydrogen production, storage, transportation, refueling, and consumption processes. The multi-protocol data access gateway parses the original protocol based on the asset mapping table. Edge computing nodes convert indicator codes, units, and time bases, binding them to enterprise, site, asset, sensor, and available batch, container, or vehicle identifiers. A global event identifier is generated using the site, sensor, sampling time, and serial number; only one valid record is retained for each event identifier.

[0023] A unified event package includes at least the event identifier, event type, raw value and unit, standard value and unit, sampling time, reception time, sequence number, quality flag, sensitivity level, and data contract version, and optionally includes a summary of the previous event and a summary of the current event.

[0024] Edge computing nodes upload data via encrypted access channels after being protected according to sensitivity levels. For events that are duplicated, out of order, or interrupted by network outages, the edge computing nodes deduplicate events based on their event identifiers and write them to a circular buffer. After communication is restored, the data is retransmitted sequentially starting from the next event after the last confirmed sequence number on the cloud side. When the buffer is close to its capacity limit, priority is given to retaining the windows before and after alarms, sensitive events, and work order evidence, while recording the downsampling interval of ordinary high-frequency data. Step S1 outputs a unified event packet, edge buffer, and sequence gaps; the event stream is used by step S2 to form windows, and asset and batch identifiers are used by step S4 to establish traceability relationships, ensuring that risk calculation and traceability use the same event identity.

[0025] S2. The event packets are sorted by window and judged for data quality according to the same data contract on both the edge side and the cloud side, forming a multi-dimensional feature vector. The multidimensional feature vector is an ordered array output for each effective window, with the following elements: concentration monitoring value; concentration change rate, which is the ratio of the change in the concentration monitoring value of the current window relative to the concentration monitoring value of the previous effective window to the window time interval; pressure deviation indication value, a dimensionless Boolean quantity, which is 1 when the pressure monitoring value deviates from the expected pressure range, and 0 otherwise; inlet and outlet flow imbalance indication value, a dimensionless Boolean quantity, which is 1 when the difference between the inlet flow and the outlet flow exceeds the preset imbalance threshold, and 0 otherwise; equipment operating condition code value, a dimensionless integer used to represent the current equipment operating status, preferably 0 for shutdown, 1 for standby, 2 for normal operation, and 3 for fault; quality mark code value, a dimensionless integer determined by the data quality judgment result in step S2, preferably 0 for validity, 1 for low confidence, 2 for degradation, and 3 for isolation.

[0026] The multidimensional feature vectors are arranged in the above order and used as the input vectors for risk calculation in step S3.

[0027] Edge computing nodes and the cloud-based monitoring and processing platform handle local events and uploaded events respectively, using the same data contract and window configuration, and sorting by asset, indicator, event time, and water level. Late events within the correction period are allowed to update unclosed windows; events exceeding the time limit only enter auditing and offline playback. The window length is pre-configured based on the dynamic characteristics of the monitored indicator and the sampling period. For example, for concentration monitoring, the window length can be configured to 10 seconds, with a sampling period of 1 second; for pressure or flow monitoring, the window length can be adjusted according to response needs to balance response speed and data stability.

[0028] Let the number of events that the window should receive be . The number of valid and non-repeating events is Data coverage for: In the formula, , , These represent assets, metrics, and window indexes, respectively, with the number of events per item. A dimensionless number between 0 and 1. When When the value is 0.6, output the degraded status and pause the recovery count; when 0.6 ≤ When <0.8, the calculation result is retained and marked as low confidence; when If the value is ≥0.8, it will be treated as a valid window.

[0029] Both sides also detect stagnation, sudden jumps, calibration expiration, clock deviation, and cross-sensor conflicts, generating current concentration values ​​and rates of change, pressure deviations, inlet and outlet flow imbalances, equipment operating conditions, and mass fractions.

[0030] For situations involving sensors exceeding their measurement range, stalling, or abruptly jumping, the cloud-based monitoring and processing platform retains the original events and sets quality flags. When an edge computing node loses connection, the cloud-based platform sets the data status to isolated and maintains the highest risk level prior to the loss of connection. After the node recovers, the clock, rule version, and cache integrity are checked. Step S2 outputs a two-sided multi-dimensional feature vector containing a window identifier, a list of evidence, a summary of the input event set, a version field, and the data quality status. This vector is used in step S3 to calculate the risk, and the data quality status is used in step S5 to control recovery and in step S6 to filter baselines.

[0031] S3. Calculate the risk score based on the multidimensional feature vector and the dynamic threshold constrained by the fixed safety boundary, verify the risk results on both sides, and output the risk event. Edge computing nodes and dynamic threshold and risk calculation units respectively read the multi-dimensional feature vectors on both sides of step S2 and the normal and high-quality baselines in the same activated parameter version. For indicators where increased values ​​indicate increased risk, the robust scaling quantity and dynamic early warning threshold are: In the formula, The baseline median, This represents the median absolute deviation. For robust scalar measurement. To prevent positive numbers with zero variance, 10% of the range can be used. -6 Wherein, the range is the maximum measurable value of the measuring equipment corresponding to the current monitoring indicator, i.e., the full-scale value. It is the sensitivity coefficient and is greater than 0. To fix the upper safety limit; except All external data are in the same unit as the measured indicator. The baseline set used to determine the dynamic threshold consists of windows with normal risk status, valid data quality, and complete traceability. Preferably, the baseline set contains no fewer than 300 normal and high-quality historical windows to ensure the statistical representativeness of the baseline. As a specific configuration of the concentration indicator, the baseline median... It can be set to 0.1%vol, median absolute deviation. It can be set to 0.02%vol to prevent zero variance. It can be set to 0.000001%vol, sensitivity coefficient It can be set to 4, which is the fixed upper safety limit. It can be set to 1%vol, the reference rate of change. It can be set to 0.05%vol / s. The pressure index can be calculated separately for both sides, constrained by a fixed lower and upper safety limit; if the baseline is insufficient, the approved initial parameter package is read from both sides.

[0032] Let the current and previous effective window concentrations be... , Window interval is The reference change rate The degree of exceeding the threshold Positive rate of change characteristics and supporting features for: In the formula, , These are the dynamic concentration threshold and the fixed safety upper limit, respectively. >0; Will Cut off to 0 to 1. , These are the pressure deviation and flow imbalance indication values, respectively. They are set to 1 when the values ​​reach the 2% and 3% thresholds, and 0 otherwise. Keep the denominator positive. When the concentration decreases Negative values ​​are not allowed.

[0033] Let the asset consequence coefficient be... Integrating risk analysis It can be calculated using the following formula: in, , , and asset consequence coefficient All are between 0 and 1. The risk score ranges from 0 to 100; specifically, when the risk score is exactly equal to the boundary values ​​of 30, 60, or 80, it is treated as a higher risk level. Asset Consequence Coefficient The value can be selected between 0.2 and 0.6, depending on the importance of the asset and the severity of the accident consequences. Higher values ​​are used for higher risk levels or more critical assets. An emergency risk event is directly generated when the current value reaches the fixed safety boundary or when the equipment's hard alarm is effective. The input event set summary, data contract version, rule version, and risk level are compared on both sides. If they are inconsistent, the higher level is retained and a version verification event is generated.

[0034] In cases where edge computing results differ from cloud computing results, the early warning and work order units generate handling records based on the higher level. The parameter feedback and version management units compare the data contract version, rule version, model version, and input event set. In cases of version mismatch, the distribution of the candidate version is stopped, the most recent valid version is restored, and the affected window is replayed offline. When the encryption key expires or message authentication fails, the relevant message enters an isolation queue. The edge computing node continues to execute local fixed security boundary rules, re-obtains the key, and verifies it using the event identifier, sequence number, and random number before adding it to the cloud for processing. Step S3 outputs a risk event with risk score, level, triggering factor, evidence, confidence state, and version, for step S4 to expand the scope of impact and for step S5 to migrate the status. S4. Establish a directed traceability relationship based on the batch association identifiers in the risk events, expand the risk impact sub-graph, and form quality balance and carbon accounting details; The traceability and accounting unit receives the risk events output in step S3 and reads the batch, container, vehicle, site, and equipment identifiers related to the risk asset and event time from the unified event package in step S1. Using batches, containers, vehicles, sites, and equipment as nodes, and production, loading, transfer, receiving, filling, consumption, batch splitting, and batch merging as directed edges, the unit traces back from the risk asset to find the source batch and forward to find the downstream receiving or using node, forming a risk impact subgraph. When splitting a batch, the quality allocation from the parent batch to multiple sub-batches is saved; when merging a batch, the quality allocation from multiple parent batches to one sub-batchlet is saved. When the event summary is discontinuous, the missing interval and traceability completeness are output.

[0035] For batch Let the number of entries within the regulatory period be... Output quantity is Inventory changes Recorded venting or sampling correction amounts are: Quality balance residual for: In the formula, Indicates batch index; , , , and The units are all kilograms. To prevent positive numbers from being divided by zero, The unit is a percentage, and the vertical line indicates an absolute value. When the input is 0 or a key measurement is missing, the mass balance status is set to uncalcifiable and the missing amount is listed. The traceability and accounting unit also associates electricity, fuel, and transportation activities by batch, and writes the source and version of the corresponding emission factors into the carbon accounting input details; when a factor is missing, the activity amount is retained and the status of the factor to be supplemented is output.

[0036] Carbon accounting uses the emission factor method, and the batch is calculated according to the following formula. carbon emissions : In the formula, For batch In the Activity volume within categories of activities (including electricity consumption, fuel consumption, and transport turnover); For the first Emission factors corresponding to this type of activity; This represents the global warming potential coefficient.

[0037] The sources of emission factors are prioritized as follows: measured emission factors, obtained through continuous on-site monitoring or periodic testing; regional power grid emission factors or industry average emission factors, taken from the latest data sources published by national or industry authorities; and default values ​​applicable to the Chinese region from internationally recognized emission factor databases. For each calculation, the source name, issuing agency, version number, and publication date of the emission factor used must be recorded and saved along with the accounting input details. When multiple emission factors are available for the same activity, the one with the most recent data source time is used, and alternative factors and their versions are marked in the details for traceability and replacement during auditing.

[0038] The transition between mass balance results and carbon emissions is as follows: mass balance residuals Used to verify the integrity and consistency of batch quality data; when When the mass measurement of a batch is less than a preset balance threshold (preferably 5%), the corresponding electricity, fuel, and transportation activity amounts are included in carbon accounting; when When the value is greater than or equal to the threshold, the tracing and accounting unit searches for missing or abnormal metering nodes, and rebalances after they are replenished. If rebalancing still fails after replenishment, the carbon accounting input details will indicate that the carbon emissions of this batch are calculated only based on the confirmed activity amount, and the mass difference not included in the accounting will be marked. After the metering system is restored and the mass balance meets the threshold requirements, the carbon emissions of the affected batch will be recalculated and an accounting correction record will be generated.

[0039] For cases of chain breaks or missing emission factors, the traceability and accounting unit retains the batch nodes, energy consumption, and transportation activity volumes already obtained, outputting the missing intervals, uncalculated or supplementary factor statuses. Recalculation is performed once the corresponding event or factor version is complete, and the unit provides accounting inputs and calculation processes with source and version information. Step S4 outputs a risk impact sub-map, mass balance results, traceability completeness, and detailed carbon accounting inputs. The risk impact sub-map, together with the risk level from step S3, is used in step S5 to determine the notification recipients and work order scope.

[0040] S5. Perform risk status migration based on risk events and impact subgraphs, generate graded early warning and handling work orders, and maintain recovery counts when data quality degrades. The early warning and work order unit reads the risk events output in step S3, the risk impact sub-graph output in step S4, and the data quality status output in step S2, and queries existing work orders for the same asset and the same triggering factor. Risk status includes Normal, Attention, Early Warning, and Emergency; data status includes Available, Degraded, and Isolated. As a state transition method, when the risk score for three consecutive valid windows is between 30 and 60, it transitions from Normal to Attention; when the risk score for two consecutive valid windows is between 60 and 80, it transitions to Early Warning; and when the risk score for a single valid window reaches 80 or triggers a fixed safety boundary, it transitions to Emergency.

[0041] The early warning and work order unit sends tiered messages to on-site personnel, the station's management center, the regulatory body, and the enterprise based on the impact sub-graph, and generates work orders that include the risk level, involved assets and batches, evidence events, current status, responsible roles, and closure conditions. For situations where sensors exceed their range, stagnate, or suddenly jump, if a single sensor malfunctions and no similar redundant sensors, pressure, or flow data provide corroboration, the dynamic threshold and risk calculation unit outputs a low-confidence risk event and generates a calibration work order; when multiple independent features simultaneously provide corroboration, the risk level is determined according to the fusion result or a fixed safety boundary.

[0042] During recovery, an emergency status transitions to a warning status after manual confirmation and a risk score below 70 for six consecutive valid windows. A warning status transitions to a watch status after a risk score below 50 for 12 consecutive valid windows. In the watch status, after a risk score below 20 for 30 consecutive valid windows, the warning and work order units verify the risk recovery conditions, responsible person confirmation, and evidence completeness of the current work order, and verify that there are no other unclosed work orders for the same asset and triggering factor. If all conditions are met, the current work order is closed within the same status transaction, and the risk status is changed to normal. When the data status is downgraded or isolated, the current recovery count is maintained; new valid risks can still drive status escalation. Work orders are recorded sequentially as open, confirmed, processing, under observation, and closed. During the observation period, if the same type of risk reaches the warning conditions again, a reopened status is generated and associated with the original work order. Step S5 outputs a warning message, evidence snapshot, work order, and status change record. The confirmation, retesting, and classification results of the handling personnel serve as input for the baseline and parameter version evaluation in step S6, ensuring that status recovery and parameter updates use the same evidence.

[0043] S6. Based on the feedback results of the handling, isolate abnormal data, form candidate baselines and generate version parameter packages. After being activated by edge side verification, enter the next cycle. The parameter feedback and version management unit reads the processing results and manual classification labels output in step S5, and simultaneously reads the data quality snapshot from step S2, the risk events from step S3, and the traceability completeness from step S4. Confirmed real anomalies, sensor failures, communication failures, and false alarms are saved separately; the window from the occurrence of an anomaly to the closure of the work order is entered into the isolated sample set.

[0044] The parameter feedback and version management unit forms candidate baselines from windows with normal risk status, valid data quality, and complete traceability. The number of normal samples required to form a candidate baseline is preferably preset to 300 windows. Offline playback and version review of candidate parameters are only performed after the number of normal samples meets this configuration condition, ensuring the statistical representativeness and robustness of the baseline. After performing offline playback on the candidate dynamic thresholds or models, the risk level, hard boundary events, and version differences under the original version and the candidate version are compared. When a new risk event has the same asset and the same triggering factor as an observed or closed work order, a work order recurrence label is generated.

[0045] After a candidate version maintains the level of all hard boundary events and passes review, a signature parameter package is generated, containing the version number, effective time, applicable asset scope, feature definition, verification summary, and rollback version. In cases where the calculation results on the edge and cloud sides are inconsistent, the parameter feedback compares the data contract version, rule version, model version, and input event set with the version management unit. In the event of a version mismatch, the issuance of the candidate version is stopped, the most recent valid version is restored, and the affected windows are replayed offline.

[0046] After receiving the signature parameter packet, the edge computing node verifies the signature, applicable asset scope, and effective time, and sequentially returns receipt, verification passed, and activation receipt; if the verification or activation conditions are not met, the most recent valid version is restored. The identifier of the activated version is written into the unified event packet by step S1 in the next cycle, and risk calculation is performed on the edge side and cloud side respectively according to this version by step S3; the work order reproduction tag output by step S6 is returned to step S5 to trigger the reopening judgment. Step S6 outputs an isolated sample set, a replay report, an approved parameter packet, activation or rollback receipt, and a work order reproduction tag, so that the handling feedback affects the next cycle after offline verification and version confirmation, without directly rewriting the edge rules being executed.

[0047] Example 2 Please see Figure 2 As shown, this embodiment provides a hydrogen energy regulatory system based on big data processing, including a data acquisition device group 100, a multi-protocol data access gateway 110, an edge computing node 120, an encrypted access channel 130, a cloud-based regulatory processing platform 200, a dynamic threshold and risk calculation unit 210, a traceability and accounting unit 220, an early warning and work order unit 230, a parameter feedback and version management unit 240, and a regulatory application terminal 300.

[0048] The data acquisition unit group 100 receives equipment measurements and status according to the regulatory process. Specifically, the hydrogen production stage receives concentration, pressure, temperature, and electrolyzer status; the hydrogen storage stage receives pressure, level, and leakage signals; the hydrogen transportation stage receives pressure, flow rate, and leakage signals; the hydrogen refueling stage receives concentration, pressure, temperature, hydrogen refueling machine status, and video events; and the hydrogen consumption stage receives vehicle-mounted data. A multi-protocol data access gateway 110 connects to the data acquisition unit group 100, reads data points from different protocols, and converts the original data points into unified indicator codes and standard units according to the asset mapping table.

[0049] Edge computing node 120 is connected to multi-protocol data access gateway 110. Edge computing node 120 binds enterprise, site, asset, sensor, and available batch, container, or vehicle identifiers to each measurement event, and generates event identifier, serial number, event time, initial quality label, sensitivity level, and version fields; Edge computing node 120 also performs idempotent deduplication, short-window aggregation, data quality assessment, fixed security boundary fast judgment, and risk calculation according to the currently activated window configuration and parameter version, generating an edge risk result with a summary of the input event set, data contract version, and rule version, and performs network outage caching. During communication interruption, edge computing node 120 uses the most recently valid version parameter packet to perform fixed security boundary judgment and cache unified event packets. After communication is restored, it retransmits the packets sequentially starting from the next item after the last confirmed sequence number on the cloud side. The generated unified event packets and edge risk results are sent to the cloud-side monitoring and processing platform 200 via encrypted access channel 130.

[0050] The encrypted access channel 130 employs transmission protection, payload authentication encryption, or field-level envelope encryption based on the sensitivity level, and sends the key identifier and random number with the message, enabling the receiving end to verify the message source and duplicate combinations.

[0051] The cloud-based monitoring and processing platform 200 includes access services, real-time stream processing, a time-series database, a relational database, and a distributed file system. The access service verifies identity, event identifiers, and sequence numbers, distributing valid events and corresponding edge risk results according to asset identifiers and indicator codes. Real-time stream processing uses the same data contract version, window configuration, and activated parameter version as the edge computing node 120, establishing windows based on event time and forming multi-dimensional cloud-based features and data quality status.

[0052] When edge computing node 120 loses connection, the cloud-based monitoring and processing platform 200 sets the data quality status to isolation and maintains the highest risk level before the loss of connection. After the node recovers, the clock, rule version, and cache integrity are checked. Continuous measurement points are written to the time-series database, asset, rule, alarm, and work order records are written to the relational database, and video clips, historical batch data, or model files are written to the distributed file system. Video event indexes are associated with concurrent measurement points through event identifiers, and video events are stored as supplementary evidence. For situations where sensors exceed their range, stagnate, or suddenly jump, the cloud-based monitoring and processing platform 200 retains the original event and sets a quality flag.

[0053] The dynamic threshold and risk calculation unit 210 reads the cloud-side multidimensional features, data quality status, edge risk results and version fields generated by the cloud-side monitoring and processing platform 200, calculates the robust dynamic threshold and cloud-side fusion risk score, and verifies the input event set summary, data contract version, rule version and risk level of both sides; when the verification is consistent, the common result is saved; when the verification is inconsistent, the higher risk level is retained and a version verification event is formed. Then, the risk level, triggering factor, evidence event and rule version are written into the risk event, and the data quality status is forwarded to the early warning and work order unit 230 along with the risk event.

[0054] When a single sensor malfunctions and no other redundant sensors of the same type, pressure, or flow rate provide corroborating evidence, the dynamic threshold and risk calculation unit 210 outputs a low-confidence risk event and generates a calibration work order; when multiple independent features provide corroborating evidence simultaneously, the risk level is determined according to the fusion result or a fixed safety boundary.

[0055] The traceability and accounting unit 220 simultaneously reads batch, container, vehicle, site, and asset identifiers from risk events and unified event packages, establishing directed relationships for production, loading, transfer, receiving, refueling, consumption, and batch splitting / merging. It outputs a risk impact sub-graph, quality balance results, traceability completeness, and detailed carbon accounting inputs with factor versions. For cases of traceability chain breaks or missing emission factors, the traceability and accounting unit 220 retains the already obtained batch nodes, energy consumption, and transportation activity volumes, and outputs missing intervals, uncalculated or pending factor statuses, which are then recalculated after the corresponding event or factor version is completed. Thus, the same unified event package is used both by the dynamic threshold and risk calculation unit 210 for risk calculation and by the traceability and accounting unit 220 for determining the scope of impact; the risk event, risk impact sub-graph, and data quality status are jointly sent to the early warning and work order unit 230.

[0056] The Early Warning and Work Order Unit 230 performs status migration based on risk level, impact sub-graph, data quality status, and existing work order status. It pushes relevant messages to on-site personnel, the station's management center, the regulatory end, and the enterprise end, and records confirmation, handling, retesting, observation, and closure evidence. When data quality is in a downgraded or isolated state, recovery counts are maintained, and new valid risks can still drive risk status escalation. For situations where edge-side and cloud-side calculation results are inconsistent, the Early Warning and Work Order Unit 230 generates a handling record based on the higher level. The regulatory application terminal 300 connects to the Early Warning and Work Order Unit 230, reads the trimmed data according to roles, and transmits the handling records back.

[0057] The parameter feedback and version management unit 240 reads the disposal tag, retest window, risk version, data quality snapshot, and traceability completeness. It isolates data from the abnormal period and disposal observation period, forming candidate baselines only from windows with normal risk, valid data quality, and complete traceability. It performs offline replay on candidate thresholds or models, generating a parameter package with effective time, applicable asset scope, verification summary, and rollback version. In cases of inconsistency between edge-side and cloud-side calculation results, the parameter feedback and version management unit 240 compares the data contract version, rule version, model version, and input event set. If a version mismatch occurs, it stops issuing the candidate version, restores the most recent valid version, and replays the affected window offline.

[0058] After being signed, the parameter packet is returned to edge computing node 120 via control direction. Edge computing node 120 sequentially returns receipt, verification passed, and activation receipt. If the activation conditions are not met, the most recent valid version is used and a rollback receipt is returned. When the encryption key expires or message authentication fails, the relevant message enters the isolation queue. Edge computing node 120 continues to execute local fixed security boundary rules, re-obtains the key, and verifies it through event identifier, sequence number, and random number before re-entering it for cloud-side processing.

[0059] The system can be implemented by a processor executing a program in memory on edge computing devices and servers. Edge computing node 120 stores short-term circular cache, recently confirmed sequence number, current rule version, and most recently valid version; cloud-based monitoring and processing platform 200 stores original events, window features, risk events, traceability relationships, state transitions, and parameter versions, enabling monitoring application terminal 300 to reproduce the inputs, intermediate values, and handling records used in a judgment based on event identifiers.

[0060] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A hydrogen energy regulatory method based on big data processing, characterized in that, include: Collect measurement data from various links in the hydrogen energy industry chain, generate a unified event package after protocol parsing and identifier binding, and upload the unified event package to the cloud. The unified event package is sorted by window and judged for data quality by the edge side and the cloud side respectively according to the same data contract, forming a multi-dimensional feature vector; Risk scores are calculated based on the multidimensional feature vectors and dynamic thresholds constrained by fixed security boundaries. The risk calculation results on the edge side and the cloud side are then verified, and risk events are output. Establish a directed traceability relationship based on the batch association identifiers in the aforementioned risk events, and expand the risk impact subgraph; Based on the risk events and the risk impact subgraph, risk status migration is performed, tiered early warning and handling work orders are generated, and recovery counts are maintained when data quality degrades; abnormal data is isolated based on the handling feedback results, candidate baselines are formed and version parameter packages are generated, and after being verified and activated at the edge, they enter the next regulatory cycle.

2. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, Data from various monitoring points across the hydrogen energy industry chain is collected, and after protocol parsing and identifier binding, a unified event package is generated, including: Collect measurement values ​​or equipment status from hydrogen production, storage, transportation, refueling and utilization processes; the multi-protocol data access gateway parses the original protocol based on the asset mapping table. Edge computing nodes are converted to indicator codes, units, and time bases, which are then bound to enterprise, site, asset, sensor, and available batch, container, or vehicle identifiers. Global event identifiers are generated using site, sensor, sampling time, and serial number; only one valid record is retained for the same event identifier. A unified event package should include at least the event identifier, event type, raw value and unit, standard value and unit, sampling time, reception time, sequence number, quality flag, sensitivity level, and data contract version. In the event of duplicate, out-of-order, or network outage, the edge computing node deduplicates the events according to the event identifier and writes the events into the circular buffer. After communication is restored, the events are retransmitted in order starting from the next event after the last confirmed sequence number on the cloud side.

3. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, The edge and cloud sides perform window sorting and data quality assessment on the unified event package according to the same data contract, forming a multi-dimensional feature vector, including: Edge computing nodes and cloud-based monitoring and processing platforms use the same data contract and window configuration, sorted by assets, indicators, event time, and water level; late events within the correction period are allowed to update unclosed windows, while events exceeding the time limit are only audited and played back offline; Data coverage is the ratio of valid and non-repeating events to the total number of events that should be received in the window; when the data coverage is less than the preset first coverage threshold, a degraded status is output and the recovery count is paused; when the data coverage is greater than or equal to the first coverage threshold but less than the preset second coverage threshold, the calculation result is retained and marked as low confidence; when the data coverage is greater than or equal to the second coverage threshold, it is processed as a valid window.

4. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, Risk scores are calculated based on multidimensional feature vectors and dynamic thresholds constrained by fixed security boundaries. The risk calculation results for the edge side and the cloud side are then compared, and risk events are output, including: For indicators where an increase in value indicates an increase in risk, a robust scaling factor is calculated based on the baseline median and median absolute deviation. The product of the robust scaling factor and the sensitivity coefficient is added to the baseline median and compared with a fixed safety boundary. The smaller value is taken as the dynamic warning threshold. The set of baselines used to determine the dynamic threshold consists of a window with normal risk status, valid data quality, and complete traceability. The degree of exceeding the threshold is determined by the degree of deviation of the current monitoring value from the dynamic early warning threshold and the fixed safety boundary. The rate of change characteristic is determined by the positive rate of change of the current monitoring value relative to the previous effective window monitoring value. The supporting characteristics are determined by the pressure deviation indication value and the flow imbalance indication value. The fusion risk score is obtained by weighted summing of the degree of exceeding the threshold, the rate of change characteristic, the supporting characteristics and the asset consequence coefficient. When the current monitoring value reaches the fixed safety boundary or the equipment hard alarm is effective, an emergency risk event is directly formed; when the calculation results on the edge side and the cloud side are inconsistent, the higher risk level is retained and a version verification event is generated.

5. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, Establish directed traceability relationships based on batch association identifiers in risk events, and expand the risk impact subgraph, including: Using batches, containers, vehicles, sites, and equipment as nodes, and production, loading, transfer, receiving, filling, consumption, batch splitting, and batch merging as directed edges, the risk impact subgraph is formed by reverse tracing of the source batch from the risk asset and forward tracing of the downstream receiving or using node. When splitting a batch, the quality allocation from the parent batch to multiple sub-batches is saved, and when merging a batch, the quality allocation from multiple parent batches to one sub-batch is saved. Calculate the quality balance residual, which is the ratio of the absolute value of the difference between the input and output, inventory change and correction to the input. When the input is zero or a key measurement is missing, the quality balance state is taken as uncalcifiable and the missing quantity is listed.

6. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, Based on the risk event and risk impact subgraph, risk status transitions are performed, tiered early warning and handling work orders are generated, and recovery counts are maintained during data quality degradation, including: Risk status includes normal, attention, warning, and emergency; when the risk score of a consecutive preset number of valid windows is in the first risk range, it changes from normal to attention; when the risk score of a consecutive preset number of valid windows is in the second risk range, it changes to warning; when the risk score of a single valid window reaches the third risk range or triggers a fixed safety boundary, it changes to emergency. Upon recovery, the emergency status is converted to a warning after obtaining manual confirmation and the risk score of a consecutive preset number of valid windows is lower than the first preset threshold. The warning status is converted to a concern status after the risk score of a consecutive preset number of valid windows is lower than the second preset threshold. The concern status is converted to a concern status after the risk score of a consecutive preset number of valid windows is lower than the third preset threshold. The risk recovery conditions, responsible person confirmation and evidence completeness of the current work order are checked. If all are met, the current work order is closed and the risk status is changed to normal. When the data quality status is downgraded or isolated, the current recovery count is maintained, and new effective risks can still drive the status upgrade; the work order records the status in sequence as open, confirmed, processing, under observation and closed. During the observation period, if the same risk reaches the warning condition again, a reopen status is generated and associated with the original work order.

7. The hydrogen energy regulation method based on big data processing according to claim 1, characterized in that, Based on the feedback from the handling process, abnormal data is isolated, candidate baselines are formed, and version parameter packages are generated. After activation through edge-side verification, the data enters the next regulatory cycle, including: Confirmed real anomalies, sensor malfunctions, communication failures, and false alarms are stored separately; the window of observation period from the occurrence of an anomaly to the closure of the work order is entered into the isolated sample set. Candidate baselines are formed from windows with normal risk status, valid data quality, and complete traceability; after performing offline replay on the candidate dynamic thresholds or models, the risk level, hard boundary events, and version differences are compared between the original version and the candidate version; Once the candidate version maintains the level of all hard boundary events and passes the review, a signature parameter package containing the version number, effective time, applicable asset scope, feature definition, verification summary, and rollback version is generated. After receiving the signature parameter packet, the edge computing node verifies the signature, applicable asset scope, and effective time, and returns receipts in sequence: received, verified, and activated. If the verification or activation conditions are not met, the most recent valid version is restored.

8. A hydrogen energy regulatory system based on big data processing, characterized in that, include: The data acquisition unit is used to collect measurement data from various points in the hydrogen energy industry chain. Edge computing nodes are used to perform protocol parsing and identifier binding on measurement point data, generate unified event packets, and perform data quality judgment and risk calculation according to the currently activated window configuration and parameter version. The cloud-based monitoring and processing platform is used to receive unified event packets, sort them by window according to the same data contract, and determine data quality to form a multi-dimensional feature vector. The dynamic threshold and risk calculation unit is used to calculate risk scores based on multi-dimensional feature vectors and dynamic thresholds constrained by fixed security boundaries, and to verify the risk calculation results on the edge side and the cloud side, and output risk events. The traceability and accounting unit is used to establish directed traceability relationships based on batch association identifiers in risk events and to expand the risk impact subgraph. The early warning and work order unit is used to perform risk status migration based on risk events and risk impact subgraphs, generate hierarchical early warning and handling work orders, and maintain recovery counts when data quality degrades. The parameter feedback and version management unit is used to isolate abnormal data based on the handling feedback results, form candidate baselines and generate version parameter packages, which are then activated by edge side verification and enter the next regulatory cycle.

9. A hydrogen energy regulatory system based on big data processing according to claim 8, characterized in that, Edge computing nodes bind enterprise, site, asset, sensor, and available batch, container, or vehicle identifiers to each measurement event, generating event identifier, serial number, event time, initial quality standard, sensitivity level, and version fields; a unified event package includes at least event identifier, process type, raw value and unit, standard value and unit, sampling time, receiving time, serial number, quality flag, sensitivity level, and data contract version; Edge computing nodes also perform idempotent deduplication, short-window aggregation, fast judgment of fixed security boundaries, and risk calculation, generating edge risk results with a summary of the input event set, data contract version, and rule version, and performing network outage caching; When communication is interrupted, the most recently valid version parameter package is used to perform fixed security boundary determination and cache unified event packages. After communication is restored, the data is retransmitted in sequence starting from the next item after the last confirmed sequence number on the cloud side.

10. A hydrogen energy regulatory system based on big data processing according to claim 8, characterized in that, When an edge computing node loses connection, the cloud-based monitoring and processing platform sets the data quality status to isolation and maintains the highest risk level before the loss of connection. After the node recovers, it checks the clock, rule version, and cache integrity. When a single sensor is abnormal and there is no corroboration from similar redundant sensors, pressure, and flow, the dynamic threshold and risk calculation unit outputs a low-confidence risk event and generates a calibration work order. When multiple independent features provide corroboration, the risk level is determined according to the fusion result or a fixed security boundary. The parameter feedback and version management unit forms candidate baselines from windows with normal risk status, valid data quality, and complete traceability. It performs offline playback on candidate thresholds or models to form parameter packages with effective time, applicable asset scope, verification summary, and rollback version. After signing, the parameter packages are sent to edge computing nodes, which return receipt, verification passed, and activation receipts in sequence.