Stream computing-based fuel cell vehicle operation monitoring device

Abstract

This invention relates to the field of fuel cell vehicle technology and discloses a fuel cell vehicle operation monitoring device based on stream computing. The device includes a data acquisition layer configured to acquire real-time operation data from multiple sensors of the fuel cell vehicle; a stream processing layer configured to perform real-time preprocessing and complex event processing on the operation data based on the Flink stream processing engine; a calculation and analysis layer configured to perform multi-dimensional real-time state calculations and fault mode identification; a visualization output layer configured to dynamically display battery status and fault information; and an early warning triggering layer configured to trigger tiered early warnings based on the calculation and analysis results. The data acquisition layer, stream processing layer, calculation and analysis layer, visualization output layer, and early warning triggering layer are sequentially coupled to form a real-time data stream processing architecture.

Description

Technical Field

[0001] This invention relates to the field of fuel cell vehicle technology, and more specifically to a fuel cell vehicle operation monitoring device based on stream computing. Background Technology

[0002] With the rapid development of fuel cell vehicles, the amount of time-series data generated during vehicle operation, such as battery status, powertrain parameters, and environmental data, is increasing explosively. Currently, the industry generally uses offline analysis systems based on batch processing or simple monitoring schemes based on traditional message queues to process vehicle operation data. Due to the high requirements for safety and stability of fuel cell systems, real-time monitoring with millisecond-level response is needed to monitor the vehicle's operating status.

[0003] Existing technical solutions are mainly divided into two categories: The timed polling solution based on relational databases involves periodically collecting data reported by vehicles and storing it in the database. The monitoring system periodically queries the database to obtain the latest status, which results in a delay of minutes.

[0004] The solution based on traditional stream processing frameworks uses Kafka message queues to receive data and Storm / Spark Streaming to perform simple threshold alerts, but it cannot support complex event processing and multi-dimensional real-time analysis.

[0005] However, the current technical solution has certain problems: High data processing latency: Batch processing mode results in a delay of minutes from data generation to monitoring display, which cannot meet the real-time response requirements of fuel cell system faults.

[0006] Limited computing power: Traditional stream processing frameworks have insufficient throughput and state management capabilities, resulting in severe performance bottlenecks when the number of vehicles reaches tens of thousands. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a fuel cell vehicle operation monitoring device based on stream computing to solve the aforementioned technical problems.

[0008] A stream computing-based fuel cell vehicle operation monitoring device includes: The data acquisition layer is configured to acquire operational data in real time from multiple sensors of the fuel cell vehicle; The stream processing layer performs real-time preprocessing and complex event processing on the runtime data based on the Flink stream processing engine. The computational analysis layer is configured to perform multi-dimensional real-time state calculations and fault mode identification. The visualization output layer is configured to dynamically display battery status and fault information. The early warning triggering layer is configured to trigger tiered early warnings based on the calculation and analysis results. The data acquisition layer, stream processing layer, computation and analysis layer, visualization output layer, and early warning triggering layer are coupled in sequence to form a real-time data stream processing architecture.

[0009] Furthermore, the data acquisition layer includes: The vehicle-mounted protocol adapter supports multiple interface protocols for accessing sensor data. Disconnection resume cache queue, based on RocksDB to implement state backup, is used to temporarily store data and resume data transmission when the network is abnormal.

[0010] Furthermore, the stream processing layer includes: The data validation module is configured to perform range threshold filtering on the data. The null value filling module performs data interpolation based on the sliding window mean. The data standardization module is configured to normalize data.

[0011] Furthermore, the stream processing layer also includes: A distributed time window controller configured to handle out-of-order events in streaming data.

[0012] Furthermore, the computational analysis layer includes: The status indicator calculation module is configured to calculate battery health and system efficiency indicators in real time. The complex event detection module is configured to identify multiple fault modes based on the CEP pattern.

[0013] Furthermore, the formula for calculating battery health is as follows: 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 γ all represent dynamic weighting 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] Furthermore, the visualization output layer includes: The 3D heatmap rendering module is configured to use an incremental update strategy and piecewise rendering to update battery status. The fault propagation graph module is configured to dynamically render fault nodes and their impact paths in a graph structure. The multi-terminal adaptive layout module is configured to dynamically adjust the canvas size by listening to changes in the viewport.

[0015] Furthermore, the early warning triggering layer includes: The multi-level early warning condition judgment module is configured to trigger different levels of early warnings based on a variety of preset conditions; The alarm deduplication and escalation logic module uses a caching mechanism to deduplicat alarms for the same fault within a specified window and automatically escalates the alarm level based on the alarm duration and impact range. The manual confirmation mechanism requires confirmation from the operation and maintenance system before a warning of level two or above can be triggered again.

[0016] Furthermore, it also includes: Edge computing nodes, deployed near the vehicle, are configured to preprocess and aggregate the collected data; The cloud-based 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.

[0017] Furthermore, the data acquisition layer acquires the following types of operational data: Battery voltage, current, temperature, hydrogen pressure, impedance spectrum frequency points, and complex impedance values.

[0018] The invention employing the above technical solution has the following advantages: This invention achieves millisecond-level, full-dimensional state perception and intelligent early warning capabilities for fuel cell systems. By integrating multi-source real-time data acquisition, streaming processing engines, dynamic computing models, and 3D visualization technology, it constructs a battery health management system with high throughput and low latency. It utilizes Flink+CEP to achieve microsecond-level complex event detection (20 times higher throughput than traditional solutions), reduces network load by 60% based on an edge-cloud collaborative architecture, and evaluates 12 types of health indicators in real time through a dynamic and scalable computing model (such as the dynamic weighted SOH algorithm). It also combines 3D heatmaps and fault propagation maps to achieve anomaly localization. Its hierarchical early warning mechanism (including multi-level triggering conditions and intelligent upgrade logic) significantly improves the accuracy of fault prediction, ultimately achieving a comprehensive protection goal of early detection, precise diagnosis, and rapid response to battery safety risks. Attached Figure Description

[0019] To more clearly illustrate the specific embodiments of the present invention, the accompanying drawings used in the specific embodiments will be briefly described below. In all the drawings, the elements or parts are not necessarily drawn to scale.

[0020] Figure 1This is a flowchart of the fuel cell vehicle operation monitoring device based on stream computing according to the present invention; Figure 2 This is a flowchart of the stream processing layer in the stream computing-based fuel cell vehicle operation monitoring device of the present invention. Figure 3 This is a flowchart of the computational analysis layer in the fuel cell vehicle operation monitoring device based on stream computing of the present invention. Figure 4 This is a flowchart of the visualization output layer in the fuel cell vehicle operation monitoring device based on stream computing of the present invention; Figure 5 This is a flowchart of the early warning triggering layer in the fuel cell vehicle operation monitoring device based on stream computing of the present invention. Detailed Implementation

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

[0022] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0023] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application can be combined with other embodiments.

[0024] like Figures 1-5 As shown, the fuel cell vehicle operation monitoring device based on stream computing of the present invention includes: The data acquisition layer is configured to acquire operational data in real time from multiple sensors of the fuel cell vehicle; The stream processing layer performs real-time preprocessing of runtime data and complex event processing based on the Flink stream processing engine. The computational analysis layer is configured to perform multi-dimensional real-time state calculations and fault mode identification. The visualization output layer is configured to dynamically display battery status and fault information. The early warning triggering layer is configured to trigger tiered early warnings based on the calculation and analysis results. The data acquisition layer, stream processing layer, computation and analysis layer, visualization output layer, and early warning triggering layer are coupled in sequence to form a real-time data stream processing architecture.

[0025] Preferably, the system achieves millisecond-level, full-dimensional state perception and intelligent early warning capabilities for fuel cell systems. By integrating multi-source real-time data acquisition, streaming processing engines, dynamic computing models, and 3D visualization technology, a battery health management system with high throughput and low latency is constructed. Flink+CEP is used to achieve microsecond-level complex event detection (20 times higher throughput than traditional solutions), and the network load is reduced by 60% based on an edge-cloud collaborative architecture. A dynamic and scalable computing model is used to evaluate 12 types of health indicators in real time (such as the dynamic weighted SOH algorithm), and anomaly localization is achieved by combining 3D heat maps and fault propagation maps. Its hierarchical early warning mechanism (including multi-level triggering conditions and intelligent upgrade logic) significantly improves the accuracy of fault prediction, ultimately achieving the comprehensive protection goal of early detection, precise diagnosis, and rapid response to battery safety risks.

[0026] In some embodiments, the data acquisition layer includes: The vehicle-mounted protocol adapter supports multiple interface protocols for accessing sensor data. Disconnection resume cache queue, based on RocksDB to implement state backup, is used to temporarily store data and resume data transmission when the network is abnormal.

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

[0028] In some embodiments, it also includes: Edge computing nodes, deployed near the vehicle, are configured to preprocess and aggregate the collected data; The cloud-based collaborative computing module connects to edge computing nodes and is used to receive aggregated data for in-depth analysis, model training, and result storage.

[0029] Preferably, the data acquisition layer is deployed within the vehicle terminal (T-Box) and is responsible for acquiring sensor data from the fuel cell system in real time. Specifically, the vehicle 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 hydrogen system.

[0030] The 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 100 ms / time.

[0031] To ensure data reliability, the disconnection resume cache queue is built on RocksDB. When the network is down, the collected data is temporarily stored on the local disk; once the network is restored, it automatically resumes from the point of interruption, ensuring that no data is lost.

[0032] In some embodiments, the stream processing layer includes: The data validation module is configured to perform range threshold filtering on the data. The null value filling module performs data interpolation based on the sliding window mean. The data standardization module is configured to normalize 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 validation module: Performs range threshold filtering on input data. For example, if the voltage value exceeds the reasonable range of [2.5V, 4.5V], it is considered invalid data and filtered out.

[0035] Missing value imputation module: Employs a mean imputation algorithm based on a sliding time window (e.g., 10 seconds). For missing values ​​in the sequence, the mean of the valid data within this window is used to fill in the missing values.

[0036] Data standardization module: The Z-score normalization method is used to transform the original data into a standard distribution with a mean of 0 and a standard deviation of 1.

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

[0038] In some embodiments, the formula for calculating battery health 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 γ all represent dynamic weighting 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.

[0039] Preferably, the model uses historical operating data of the battery (such as cycle count, average temperature, and internal resistance change trend) as input to predict in real time the weight allocation that best reflects the current degradation mode.

[0040] Complex event detection module: Implemented based on the Flink CEP library. Faults are identified by defining complex event patterns. For example, the pattern for identifying a "lithium plating" fault can be defined as follows: if three conditions are simultaneously met within 5 seconds: Slope_low > 0.8, temperature < 50℃, and voltage jitter standard deviation > 2mV, then a lithium plating fault event is triggered.

[0041] In some embodiments, the visualization output layer includes: The 3D heatmap rendering module is configured to use an incremental update strategy and piecewise rendering to update battery status. The fault propagation graph module is configured to dynamically render fault nodes and their impact paths in a graph structure. The multi-terminal adaptive layout module is configured to dynamically adjust the canvas size by listening to changes in the viewport.

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

[0043] 3D thermal map rendering module: used to display the temperature or SOH distribution of each cell in the battery pack in real time.

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

[0045] The front-end ECharts instance uses the setOption method and only passes in the changed data array in series[0].data to achieve incremental updates, which greatly reduces the overhead of network transmission and browser rendering.

[0046] Rendering optimization: Rendering is performed using the heatmap3D component of the ECharts GL library. In the configuration options, setting progressive: 1000 will render large amounts of data in chunks, preventing UI lag.

[0047] Meanwhile, the color mapping calculation (mapping values ​​to colors through the visualMap component) is handled by the WebWorker thread, without blocking the main thread and user interaction.

[0048] Mobile adaptation: The `myChart.isDisposed` method is called to check the current browser's support for WebGL. If it is not supported (such as some mobile browsers), it automatically downgrades to a 2D planar heatmap to ensure the availability of the feature.

[0049] Fault Propagation Map Module: Visually displays the fault source and its impact path in the form of a graph topology.

[0050] Topology construction: using ECharts' graph component.

[0051] Nodes represent faulty battery cells or modules, and edges represent the propagation or impact of the fault. The layout uses a force-directed algorithm, and the reasonable distribution of nodes is achieved by configuring parameters such as series-graph.force.repulsion, clearly showing the cluster relationships.

[0052] Interactive drill-down: Listen for the user's 'click' event. When a node is clicked, the front end triggers a chart update via dispatchAction and requests the next level of data associated with that node from the server (for example, clicking a module node will drill down to display the detailed status of all individual units within that module), thereby enabling drill-down analysis from the whole package to the module and then to the individual units.

[0053] Multi-terminal adaptive layout module: Ensures that the monitoring dashboard can be displayed and interacted with normally 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 sizes in the charts are set using CSS viewport units (vw, vh) instead of fixed pixels (px), allowing the overall layout to scale smoothly with the screen size. Additionally, all interactive events are compatible with touchscreen operation.

[0056] In some embodiments, the warning triggering layer includes: The multi-level early warning condition judgment module is configured to trigger different levels of early warnings based on a variety of preset conditions; The alarm deduplication and escalation logic module uses a caching mechanism to deduplicat alarms for the same fault within a specified window and automatically escalates the alarm level based on the alarm duration and impact range. The manual confirmation mechanism requires confirmation from the operation and maintenance system before a warning of level two or above can be triggered again.

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

[0058] Multi-level alert condition judgment module: It includes a built-in configurable rule engine, allowing operations personnel to drag and drop and arrange alert conditions through a graphical user interface (UI). The rule engine continuously consumes the processed data stream and performs logical judgments. An example is shown below: Level 1 warning: When the rule engine detects conditions such as monomer SOH < 85%, temperature gradient ∇T > 3℃ / cm (lasting for 5 minutes), or internal resistance rise rate ΔR > 10%, a Level 1 warning is triggered.

[0059] Level 2 warning: When SOH < 80%, voltage fluctuation σV > 5mV, or three consecutive cells in the same module trigger Level 1 warning, Level 2 warning is triggered.

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

[0061] Alarm deduplication and upgrade logic module: Intelligent alarm management based on distributed caching (such as Redis).

[0062] Deduplication mechanism: Whenever a new alarm is generated, the system generates a unique hash value using its battery ID and fault type as the key, stores it in Redis, and sets a 10-minute expiration time (TTL). Within the TTL, if the same fault of the same battery is triggered again, the system will check that the key exists, suppress duplicate alarms, and ensure that only the highest level alarm is triggered once within 10 minutes.

[0063] Upgrade Logic: The system adds a timestamp to each alert and continuously monitors it. For example, if a Level 1 alert is not restored to its original state and is not acknowledged (ack) by maintenance personnel within 30 minutes of its occurrence, the system will automatically upgrade it to a Level 2 alert. Similarly, when the system detects that more than 50% of the batteries in the same module have triggered Level 2 alerts, it will forcibly upgrade all alarms in that module to Level 3 alerts and initiate the highest level of emergency response.

[0064] Manual Confirmation Mechanism: To ensure the seriousness and effectiveness of alerts, a manual confirmation process is introduced for alerts at level two and above. Alert information is pushed to the operations and maintenance management platform and marked as "unconfirmed." Only after operations and maintenance personnel click the "confirm" button on the interface will the system allow the fault point to trigger an alert again (i.e., reset the deduplication judgment). This mechanism effectively prevents the system from generating an alert storm under persistent faults, while ensuring that every important alert receives human attention.

[0065] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0066] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

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

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

[0069] Furthermore, the functional units in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0070] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0071] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory, a random access memory, a magnetic disk, or an optical disk, etc.

[0072] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A fuel cell vehicle operation monitoring device based on stream computing, characterized in that, include: The data acquisition layer is configured to acquire operational data in real time from multiple sensors of the fuel cell vehicle; The stream processing layer performs real-time preprocessing and complex event processing on the runtime data based on the Flink stream processing engine. The computational analysis layer is configured to perform multi-dimensional real-time state calculations and fault mode identification. The visualization output layer is configured to dynamically display battery status and fault information. The early warning triggering layer is configured to trigger tiered early warnings based on the calculation and analysis results. The data acquisition layer, stream processing layer, computation and analysis layer, visualization output layer and early warning triggering layer are coupled in sequence to form a real-time data stream processing architecture. The computational analysis layer includes: The status indicator calculation module is configured to calculate battery health and system efficiency indicators in real time. The complex event detection module is configured to identify multiple fault modes based on the CEP pattern. The formula for calculating battery health is as follows: SOH_real−time=α·(1 - R_act / R_init) +β·(C_discharge / C_nominal) +γ·(1 - ΔV_charge / ΔV_new) Where SOH_real−time represents real-time health, α, β, and γ all represent dynamic weighting coefficients, R_act represents current internal resistance, R_init represents initial internal resistance, C_discharge represents current discharge capacity, C_nominal represents rated capacity, ΔV_charge represents charging voltage rise slope, and ΔV_new represents full-state voltage rise slope. The visualization output layer includes: The 3D heatmap rendering module is configured to use an incremental update strategy and piecewise rendering to update battery status. The fault propagation graph module is configured to dynamically render fault nodes and their impact paths in a graph structure. The multi-terminal adaptive layout module is configured to dynamically adjust the canvas size by listening to changes in the viewport. The early warning triggering layer includes: The multi-level early warning condition judgment module is configured to trigger different levels of early warnings based on a variety of preset conditions; The alarm deduplication and escalation logic module uses a caching mechanism to deduplicat alarms for the same fault within a specified window and automatically escalates the alarm level based on the alarm duration and impact range. The manual confirmation mechanism requires confirmation from the operation and maintenance system before a warning of level two or above can be triggered again.

2. The fuel cell vehicle operation monitoring device based on stream computing according to claim 1, characterized in that, The data acquisition layer includes: The vehicle-mounted protocol adapter supports multiple interface protocols for accessing sensor data. Disconnection resume cache queue, based on RocksDB to implement state backup, is used to temporarily store data and resume data transmission when the network is abnormal.

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

4. The fuel cell vehicle operation monitoring device based on stream computing according to claim 3, characterized in that, The stream processing layer further 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 stream computing according to claim 1, characterized in that, Also includes: Edge computing nodes, deployed near the vehicle, are configured to preprocess and aggregate the collected data; The cloud-based 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.

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

Images