Fuel cell vehicle operation monitoring device based on flow calculation

Abstract

The invention relates to the technical field of fuel cell vehicles, and discloses a flow calculation-based fuel cell vehicle operation monitoring device, which comprises a data acquisition layer configured to acquire operation data from a plurality of sensors of a fuel cell vehicle in real time; the stream processing layer is used for carrying out real-time preprocessing and complex event processing on the operation data based on an Flink stream processing engine; the calculation and analysis layer is configured to execute multi-dimensional real-time state calculation and fault mode recognition; the visual output layer is configured to dynamically display the battery state and fault information; the early warning triggering layer is configured to trigger graded early warning according to the calculation and analysis result; the data acquisition layer, the stream processing layer, the computational analysis layer, the visual output layer and the early warning trigger layer are sequentially coupled to jointly form a real-time data stream processing architecture.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of fuel cell vehicle, in particular to a fuel cell vehicle operation monitoring device based on stream computing. BACKGROUND

[0002] With the rapid development of fuel cell vehicles, the time series data generated in the vehicle operation process, such as battery state, power system parameters, and environmental data, has shown an explosive growth. At present, the industry generally uses offline analysis systems based on batch processing or simple monitoring solutions based on traditional message queues to process vehicle operation data. Due to the high requirements of fuel cell systems on safety and stability, real-time monitoring of vehicle operation state with millisecond-level response is needed.

[0003] The prior art solutions are mainly divided into two categories: A timing polling scheme based on a relational database: periodically collect the data reported by the vehicle and store it in the database, and the monitoring system queries the database for the latest state at regular intervals, which has a delay of minutes.

[0004] A scheme based on a traditional stream processing framework: use Kafka message queue to receive data, and cooperate with Storm / SparkStreaming to perform simple threshold alarm, but it cannot support complex event processing and multi-dimensional real-time analysis.

[0005] However, the current technical solutions have some problems: High data processing delay: the batch processing mode causes a delay of minutes from data generation to monitoring display, which cannot meet the real-time response requirements of fuel cell system failures.

[0006] Limited computing power: the throughput and state management capability of the traditional stream processing framework is insufficient, and when the vehicle scale reaches the level of ten thousand, serious performance bottlenecks occur. SUMMARY

[0007] In view of the deficiencies of the prior art, the present application proposes a fuel cell vehicle operation monitoring device based on stream computing to solve the above technical problems.

[0008] The fuel cell vehicle operation monitoring device based on stream computing comprises: A data acquisition layer configured to acquire operation data from a plurality of sensors of a fuel cell vehicle in real time; A stream processing layer for real-time preprocessing and complex event processing of the operation data based on a Flink stream processing engine; A computing and analysis layer configured to perform multi-dimensional real-time state calculation and fault mode recognition; A visual output layer configured to dynamically display battery state and fault information; An early warning trigger layer configured to trigger a hierarchical early warning according to the result of the calculation and analysis; The data collection layer, the stream processing layer, the calculation and analysis layer, the visual output layer and the early warning trigger layer are sequentially coupled to form a real-time data stream processing architecture.

[0009] Further, the data collection layer comprises: A vehicle-mounted protocol adapter supporting multiple interface protocols to access sensor data; A broken line continuation cache queue based on RocksDB to realize state backup, for temporarily storing data and realizing data continuation when the network is abnormal.

[0010] Further, the stream processing layer comprises: A data verification module configured to perform range threshold filtering on the data; A null value filling module based on a sliding window mean for data interpolation; A data standardization module configured to perform normalization processing on the data.

[0011] Further, the stream processing layer further comprises: A distributed time window controller configured to process out-of-order events in the stream data.

[0012] Further, the calculation and analysis layer comprises: A state index calculation module configured to calculate battery health and system efficiency indicators in real time; A complex event detection module configured to identify multiple failure modes based on a CEP pattern.

[0013] Further, the battery health calculation formula is: SOH_real-time = a · (1 - R_act / R_init) + β · (C_discharge / C_nominal) + γ · (1 - ΔV_charge / ΔV_new) Wherein, SOH_real-time represents real-time health, a, β, γ represent dynamic weight coefficients, R_act represents the current internal resistance, R_init represents the initial internal resistance, C_discharge represents the current discharge capacity, C_nominal represents the rated capacity, ΔV_charge represents the charging voltage rise slope, and ΔV_new represents the full state voltage rise slope.

[0014] Further, the visual output layer comprises: A three-dimensional heat map rendering module configured to use an incremental update strategy and sharding rendering to update the battery state; A fault propagation graph module is configured to dynamically render the fault nodes and influence paths in a graph structure; A multi-terminal adaptive layout module is configured to dynamically adjust the canvas size by listening to the viewport changes.

[0015] Further, the early warning trigger layer includes: A multi-level early warning condition judgment module is configured to trigger different levels of early warning according to a plurality of preset conditions; An alarm deduplication and upgrade logic module is configured to deduplicate alarms for the same fault within a specified window based on a cache mechanism, and to automatically upgrade the early warning level according to the early warning duration and the influence range; An artificial confirmation mechanism is configured to require the operation and maintenance system to confirm the secondary and higher level early warning before triggering again.

[0016] Further, it further includes: An edge computing node is deployed near the vehicle and is configured to preprocess and aggregate the collected data; A cloud collaborative computing module is connected with the edge computing node and is used for receiving the aggregated data for deep analysis, model training and result storage.

[0017] Further, the running data types collected by the data collection layer include: Battery voltage, current, temperature, hydrogen pressure, impedance spectrum frequency point and complex impedance value.

[0018] The application adopting the above technical solution has the following advantages: The application realizes millisecond-level full-dimensional state perception and intelligent early warning capability for the fuel cell system, and through the fusion of multi-source real-time data collection, streaming processing engine, dynamic calculation model and three-dimensional visualization technology, a battery health management system with high throughput and low delay characteristics is constructed; the Flink+CEP is used to realize microsecond-level complex event detection (20 times the throughput of the traditional scheme), the edge-cloud collaborative architecture is used to reduce the network load by 60%, the dynamic scalable calculation model is used to evaluate 12 types of health indicators (such as the dynamic weight SOH algorithm) in real time, and the three-dimensional heat map and fault propagation graph are used to realize abnormal positioning; the hierarchical early warning mechanism (including multi-level trigger conditions and intelligent upgrade logic) significantly improves the fault prediction accuracy, and finally achieves the comprehensive protection goal of early discovery, precise diagnosis and fast response of battery safety risks. BRIEF DESCRIPTION OF DRAWINGS

[0019] In order to more clearly illustrate the specific embodiments of the present application, the following will briefly introduce the drawings needed in the specific embodiments. In all the drawings, the elements or parts are not necessarily drawn according to the actual proportions.

[0020] Figure 1Flowchart of the flow computing-based fuel cell vehicle operation monitoring device of the present application; Figure 2 Flowchart of the flow processing layer in the flow computing-based fuel cell vehicle operation monitoring device of the present application; Figure 3 Flowchart of the computing analysis layer in the flow computing-based fuel cell vehicle operation monitoring device of the present application; Figure 4 Flowchart of the visual output layer in the flow computing-based fuel cell vehicle operation monitoring device of the present application; Figure 5 Flowchart of the early warning triggering layer in the flow computing-based fuel cell vehicle operation monitoring device of the present application. DETAILED DESCRIPTION

[0021] The technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0022] The terms "first", "second", and the like in the specification and claims of the present application and the above-described drawings are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but can optionally include steps or units not listed, or can optionally include other steps or units inherent to the process, method, product, or device.

[0023] In the present application, the phrase "embodiment" means that the specific features, structures, or characteristics described in conjunction with the embodiment can be included in at least one embodiment of the present application. The appearance of this phrase at various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment to other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described in the present application can be combined with other embodiments.

[0024] As shown in Figures 1-5 The flow computing-based fuel cell vehicle operation monitoring device of the present application comprises: a data acquisition layer configured to acquire operation data in real time from a plurality of sensors of a fuel cell vehicle; a flow processing layer configured to perform real-time preprocessing and complex event processing on the operation data based on a Flink flow processing engine; a computing analysis layer configured to perform multi-dimensional real-time state calculation and failure mode identification; a visualization output layer configured to dynamically display battery state and failure information; an early warning triggering layer configured to trigger a hierarchical early warning according to the computing analysis result; The data acquisition layer, the stream processing layer, the computing analysis layer, the visualization output layer, and the early warning triggering layer are sequentially coupled to jointly constitute a real-time data stream processing architecture.

[0025] Preferably, the millisecond-level full-dimensional state perception and intelligent early warning capability of the fuel cell system is realized, and a battery health management system with high throughput and low delay characteristics is constructed by fusing multi-source real-time data acquisition, stream processing engine, dynamic calculation model, and three-dimensional visualization technology; microsecond-level complex event detection is realized by Flink+CEP (20 times the throughput of traditional schemes), 60% network load is reduced based on an edge-cloud collaborative architecture, 12 types of health indicators are evaluated in real time by a dynamic scalable calculation model (such as a dynamic weight SOH algorithm), and abnormal positioning is realized in combination with a three-dimensional thermal map and a failure propagation map; the hierarchical early warning mechanism (including multi-level triggering conditions and intelligent upgrade logic) significantly improves the fault prediction accuracy, and finally achieves the comprehensive protection goal of early discovery, precise diagnosis, and fast response of battery safety risks.

[0026] In some embodiments, the data acquisition layer includes: a vehicle-mounted protocol adapter supporting multiple interface protocols to access sensor data; a broken line continuation cache queue based on RocksDB to realize state backup, for temporarily storing data and realizing data continuation when the network is abnormal.

[0027] In some embodiments, the types of running data collected by the data acquisition layer include: battery voltage, current, temperature, hydrogen pressure, impedance spectrum frequency point, and complex impedance value.

[0028] In some embodiments, further comprising: an edge computing node deployed near the vehicle and configured to preprocess and aggregate the collected data; a cloud collaborative computing module connected with the edge computing node for receiving the aggregated data for in-depth analysis, model training, and result storage.

[0029] Preferably, the data acquisition layer is deployed in a vehicle-mounted terminal (T-Box) and is responsible for real-time acquisition of sensor data of the fuel cell system. Specifically, the vehicle-mounted protocol adapter supports multiple industrial interface protocols such as CAN bus and RS485 to parse and receive data from ECU units such as the battery management system (BMS) and the hydrogen system.

[0030] Operational data includes but is not limited to: battery voltage, current, temperature, hydrogen pressure, impedance spectrum frequency points, and complex impedance values. The acquisition frequency can reach 100ms / time.

[0031] To ensure data reliability, the resumable upload cache queue is built on RocksDB. When a network anomaly occurs, collected data is temporarily stored on the local disk. Once the network is restored, the data is automatically resumed from the point of disconnection, ensuring data is not lost.

[0032] In some embodiments, the stream processing layer includes: A data validation module configured to perform range threshold filtering on the data; Null value filling module, which performs data interpolation based on the sliding window mean; The data normalization module is configured to perform normalization processing on the data.

[0033] In some embodiments, the stream processing layer further includes: A distributed time window controller configured to handle out-of-order events in streaming data.

[0034] Preferably, the stream processing layer is built on the Apache Flink stream processing engine. After the raw data is transmitted to the Flink Job via the MQTT protocol, it first enters the data preprocessing pipeline: Data Verification Module: This module applies range threshold filtering to input data. For example, if the voltage value exceeds the reasonable range of [2.5V, 4.5V], it is considered invalid and filtered.

[0035] The Null Value Filling module uses a mean interpolation algorithm based on a sliding time window (e.g., 10 seconds). Missing values ​​in the sequence are filled with the mean of the valid data within the window.

[0036] Data normalization module: uses the Z-score normalization method to convert the original data into a standard distribution with a mean of 0 and a standard deviation of 1.

[0037] Distributed Time Window Controller: This controller handles out-of-order events that may be caused by network latency. This approach leverages Flink's EventTime feature and Watermark mechanism to allow data to arrive out of order within a certain timeframe, ensuring the accuracy of window calculations.

[0038] In some embodiments, the battery health calculation formula is: SOH_real−time=α·(1 - R_act / R_init) +β·(C_discharge / C_nominal) +γ·(1 - ΔV_charge / ΔV_new) Wherein, SOH real-time represents real-time health degree, a, b, g all represent dynamic weight coefficient, R act represents current internal resistance, R init represents initial internal resistance, C discharge represents current discharge capacity, C nominal represents nominal capacity, AV charge represents charging voltage rising slope, AV new represents full state voltage rising slope.

[0039] Preferably, the model takes historical operating data of the battery (such as cycle number, average temperature, internal resistance change trend) as input, and real-time predicts the weight distribution that best reflects the current decay mode.

[0040] Complex event detection module: realized based on Flink CEP library. Identify faults by defining complex event patterns (Patterns). For example, the pattern to identify "lithium precipitation" fault can be defined as: within 5 seconds, three conditions of Slope_low > 0.8, temperature < 50℃ and voltage jitter standard deviation > 2mV are detected simultaneously, then a lithium precipitation fault event is triggered.

[0041] In some embodiments, the visualization output layer includes: A three-dimensional heat map rendering module configured to update the battery state using an incremental update strategy and sharded rendering; A fault propagation graph module configured to dynamically render fault nodes and impact paths in a graph structure; A multi-terminal adaptive layout module configured to dynamically adjust the canvas size by listening to viewport changes.

[0042] Preferably, the visualization output layer is built based on the Web technology stack, and its core is to establish a full-duplex communication link with the backend stream processing server through the WebSocket protocol, to realize millisecond-level push and dynamic rendering of monitoring data.

[0043] Three-dimensional heat map rendering module: used to display the temperature or SOH distribution of each monomer in the battery pack in real time.

[0044] Data channel: the server pushes the changed data to the front end in JSON format through WebSocket, and the format example is: {id: "cell_001", x: 1, y: 2, z: 1, value: 45.2}.

[0045] The ECharts instance in the front end uses the setOption method and only inputs the changed data array in series[0].data, to realize incremental update, greatly reducing the network transmission and browser rendering overhead.

[0046] Rendering optimization: Use the heatmap3D component of the ECharts GL library for rendering. Set progressive: 1000 in the configuration item to render large data slices and avoid interface lag.

[0047] At the same time, color mapping calculations (mapping numerical values to colors through the visualMap component) are handled by the WebWorker thread, which does not block the main thread and user interaction.

[0048] Mobile adaptation: Detect the support of WebGL by the current browser by calling the myChart.isDisposed method. If it is not supported (such as some mobile browser), automatically downgrade to a 2D flat heat map to ensure the usability of the function.

[0049] Fault propagation graph module: Intuitively display the fault source and its impact path in the form of graph topology.

[0050] Topology construction: Use the graph component of ECharts.

[0051] Nodes (nodes) represent battery cells or modules that have failed, and edges (edges) represent fault propagation or influence relationships. The layout uses the force-directed algorithm, and by configuring series-graph.force.repulsion and other parameters, it achieves a reasonable distribution of nodes and clearly displays the cluster relationship.

[0052] Interactive drilling: Listen for the 'click' event of the user, and when a node is clicked, the front end triggers a chart update through dispatchAction and requests the next level of data associated with the node from the server (for example, clicking on a module node drills down to display the detailed status of all cells in the module), thereby realizing layer-by-layer drilling analysis from the whole package to the module and then to the cell.

[0053] Multi-terminal adaptive layout module: Ensure that the monitoring dashboard can be displayed and interacted with on devices of different sizes.

[0054] Responsive adaptation: The front end uses the ResizeObserver API to listen for changes in the size of the chart container and automatically calls the myChart.resize method to redraw the chart, perfectly adapting to different views from large screens to laptops.

[0055] Visual normalization: The font and legend size in the chart are set using CSS viewport units (vw, vh) instead of fixed pixels (px), allowing the overall layout to scale smoothly with screen size. At the same time, all interactive events are compatible with touch screen operations.

[0056] In some embodiments, the early warning trigger layer comprises: a multi-level early warning condition judgment module configured to trigger different levels of early warning according to preset conditions; an alarm deduplication and escalation logic module that performs alarm deduplication for the same fault within a specified window based on a caching mechanism, and automatically escalates the early warning level according to the early warning duration and impact range; an artificial confirmation mechanism configured to require confirmation by an operation and maintenance system for a secondary or higher level of early warning before triggering again.

[0057] Preferably, the early warning trigger layer receives an event stream from the computing and analysis layer, and performs multi-level judgment, alarm management, and notification triggering according to a preconfigured rule base.

[0058] Multi-level early warning condition judgment module: built-in a configurable rule engine that supports operation and maintenance personnel to arrange early warning conditions through a graphical interface (UI). The rule engine continuously consumes the processed data stream and performs logical judgment. Examples are as follows: Level 1 early warning: when the rule engine detects conditions such as single SOH < 85%, temperature gradient ∇T > 3℃ / cm (for 5 minutes), or internal resistance rise rate ΔR > 10%, it triggers a level 1 early warning.

[0059] Level 2 early warning: when SOH < 80%, voltage fluctuation σV > 5mV, or 3 consecutive single cells in the same module trigger a level 1 early warning, a level 2 early warning is triggered.

[0060] Level 3 early warning: when the single cell temperature T > 65℃ and dT / dt > 2℃ / s, voltage drop ΔV > 10% (within 0.5s), or thermal runaway model confidence > 90%, a level 3 early warning is triggered immediately.

[0061] Alarm deduplication and escalation logic module: based on distributed caching (such as Redis) to realize intelligent alarm management.

[0062] Deduplication mechanism: whenever a new alarm is generated, the system will generate a unique hash value using the battery ID and fault type as the key (Key), and store it in Redis with a 10-minute expiration time (TTL). Within the TTL, if the same fault of the same battery is triggered again, the system checks that the key exists and will suppress repeated alarms, ensuring that the highest level of alarm is triggered only once within 10 minutes.

[0063] Upgrade logic: The system adds a timestamp to each alert and continues to monitor. For example, if a first-level alert is not restored within 30 minutes after it is generated and is not confirmed (acknowledged) by the operation and maintenance personnel, the system will automatically upgrade it to a second-level alert. Similarly, when the system detects that more than 50% of the batteries in the same module trigger a second-level alert, it will forcibly upgrade the alarm of the module to a third-level alert and start the highest level of emergency response.

[0064] Manual confirmation mechanism: To ensure the seriousness and effectiveness of the alarm, for second-level and above alerts, a manual confirmation link is introduced. The alert information is pushed to the operation and maintenance management platform and marked as "unconfirmed" state. Only after the operation and maintenance personnel click the "confirm" button through the interface, the system will allow the fault point to trigger the alarm again (i.e. reset the de-duplication judgment). This mechanism effectively prevents the system from generating an alarm storm under persistent faults, while ensuring that each important alarm can be manually attended to.

[0065] It should be noted that, for the foregoing method embodiments, in order to simply describe, they are all expressed as a series of action combinations, but those skilled in the art should know that the present application is not limited to the action sequence described, because according to the present application, certain steps can be performed in other sequences or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification all belong to preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0066] In the above embodiments, the description of each embodiment is focused on, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0067] In several embodiments provided by the present application, it should be understood that the disclosed device can be implemented by other means. For example, the device embodiments described above are only schematic, and the division of the units is only a logical function division, and there can be another division manner in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interfaces, devices or units, and can be electrical or other forms.

[0068] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of network units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

[0069] In addition, each functional unit in the embodiments of the application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software program module.

[0070] When the integrated unit is realized in the form of a software program module and sold or used as an independent product, it can be stored in a computer readable storage medium. Based on such an understanding, the technical solutions of the present application essentially or partially contribute to the prior art, or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various other media that can store program codes.

[0071] Those skilled in the art can understand that all or part of the steps of the various methods in the above embodiments can be completed by a program instructing relevant hardware, and the program can be stored in a computer readable storage medium, which can include a flash disk, a read-only memory, a random access memory, a magnetic disk or an optical disk, etc.

[0072] The embodiments of the present application are described in detail above, and the principles and implementation manners of the present application are described by applying specific examples. The above description of the embodiments is only used to help understand the method of the present application and its core idea; meanwhile, for those skilled in the art, according to the idea of the present application, the specific implementation manner and application range can be changed, and the above description of the embodiments should not be understood as a limitation of the present application.

Claims

1. A fuel cell vehicle operation monitoring device based on flow computing, characterized in that: include: a data collection layer configured to collect real-time operating data from multiple sensors of the fuel cell vehicle; The stream processing layer performs real-time preprocessing and complex event processing on the running data based on the Flink stream processing engine; A computing and analysis layer configured to perform multi-dimensional real-time status calculations and fault pattern identification; The visualization output layer is configured to dynamically display battery status and fault information; The warning trigger layer is configured to trigger graded warnings based on the calculation and analysis results; The data acquisition layer, stream processing layer, calculation and analysis layer, visualization output layer and warning trigger layer are coupled in sequence to form a real-time data stream processing architecture.

2. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1 is characterized in that: The data acquisition layer includes: On-board protocol adapter, supporting multiple interface protocols to access sensor data; The disconnection-resume cache queue implements state backup based on RocksDB, and is used to temporarily store data and resume data transmission when network anomalies occur.

3. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1 is characterized in that: The stream processing layer includes: A data validation module configured to perform range threshold filtering on the data; Null value filling module, which performs data interpolation based on the sliding window mean; The data normalization module is configured to perform normalization processing on the data.

4. The fuel cell vehicle operation monitoring device based on flow computing according to claim 3 is characterized in that: The stream processing layer also includes: A distributed time window controller configured to handle out-of-order events in streaming data.

5. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1 is characterized in that: The calculation and analysis layer includes: A status indicator calculation module configured to calculate battery health and system efficiency indicators in real time; A complex event detection module is configured to identify multiple failure modes based on CEP patterns.

6. The fuel cell vehicle operation monitoring device based on flow computing according to claim 5 is characterized in that: The battery health calculation formula is: SOH_real−time=α·(1 - R_act / R_init) +β·(C_discharge / C_nominal) +γ·(1 - ΔV_charge / ΔV_new) Where SOH_real−time represents the real-time health status, α, β, and γ represent dynamic weight coefficients, R_act represents the current internal resistance, R_init represents the initial internal resistance, C_discharge represents the current discharge capacity, C_nominal represents the rated capacity, ΔV_charge represents the charging voltage rising slope, and ΔV_new represents the full-rated state voltage rising slope.

7. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1 is characterized in that: The visualization output layer includes: A 3D heat map rendering module, configured to use an incremental update strategy and tiled rendering to update battery status; The fault propagation graph module is configured to dynamically render fault nodes and impact paths in a graph structure; A multi-terminal adaptive layout module, configured to dynamically adjust the canvas size by monitoring viewport changes.

8. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1 is characterized in that: The early warning trigger layer includes: A multi-level warning condition judgment module is configured to trigger different levels of warnings based on multiple preset conditions; The alarm deduplication and upgrade logic module uses a cache mechanism to deduplicate alarms for the same fault within a specified window and automatically upgrades the alarm level based on the duration and impact range of the alarm. The manual confirmation mechanism is configured so that warnings at level 2 or above must be confirmed by the operation and maintenance system before they can be triggered again.

9. The fuel cell vehicle operation monitoring device based on flow computing according to claim 1, characterized in that: Also includes: Edge computing nodes, deployed near the vehicle, are configured to pre-process and aggregate the collected data; The cloud collaborative computing module is connected to the edge computing node and is used to receive aggregated data for in-depth analysis, model training and result storage.

10. The fuel cell vehicle operation monitoring device based on stream computing according to claim 1, wherein the operation data types collected by the data collection layer include: Battery voltage, current, temperature, hydrogen pressure, impedance spectrum frequency points and complex impedance values.

Images