A system and method applied to the health management of a flying car

Abstract

This invention relates to the field of aircraft health management technology, and discloses a system and method for health management of flying cars, including an airborne terminal deployed on the flying car and a ground terminal connected to it in communication. The airborne terminal includes: a scalable data acquisition unit, employing a programmable architecture to access and acquire health data from newly added or non-standardized functional modules; a traditional data acquisition unit, used to acquire operational data from key subsystems; and an airborne processing unit, integrating an artificial intelligence processing module, used to run a health management model trained and lightweighted by the ground terminal, realizing local real-time processing, feature extraction, and risk prediction of multi-source health data. The ground terminal is used to receive and store airborne data, perform training and optimization of the health management model based on historical and real-time data, and deploy the optimized model to the airborne processing unit in a lightweight manner. This invention possesses high-performance airborne processing capabilities, flexible scalability, and intelligent analysis capabilities.

Description

Technical Field

[0001] This invention relates to the field of aircraft health management technology, and specifically to a system and method for health management of flying cars. Background Technology

[0002] The electric flying car health management system is a core supporting technology in the low-altitude economy, with its core function focusing on the real-time monitoring and dynamic evaluation of the flying car's operational status. This system monitors key dimensions such as motor performance, battery energy storage status, and electrical system operating conditions in real time. Combined with data acquisition, transmission, and fusion analysis from multiple sensors, it achieves a quantitative assessment of the flying car's overall health status, providing core data support for flight safety assurance and operational strategy decisions. However, as a manned transportation vehicle, flying cars have significantly higher requirements for system safety and reliability than traditional drones. Furthermore, their overall size is larger, their power system structure is more complex, and the number of battery cells, motors, and related components increases significantly, resulting in an exponential increase in the amount of operational status and health monitoring data generated during flight.

[0003] Against this backdrop, the core challenge facing the flying car health management system lies in how to achieve real-time processing and accurate evaluation of massive monitoring data under the triple constraints of onboard computing power, communication bandwidth, and system scalability, while still ensuring flight safety under extreme conditions such as limited communication.

[0004] From the perspective of current technological development, drone health management systems for unmanned scenarios have a relatively mature technical framework. However, their data transmission mode mostly involves data offloading via USB interface after the flight mission, which not only requires manual intervention for physical connection of the equipment, but also involves cumbersome and time-consuming procedures and cannot meet the real-time monitoring needs of low-altitude flight scenarios. To meet the real-time monitoring requirements of aircraft operating status, the industry subsequently proposed air-ground integrated real-time monitoring systems, deploying core functions such as health monitoring and risk warning on the ground to reduce the computing load and data transmission volume of the airborne end, thereby reducing the transmission pressure of the air-ground data link and the processing pressure of the airborne equipment. These systems have solved the real-time monitoring problem to a certain extent, but their design logic is still rooted in the application scenario of drones, assuming that the airborne end only needs to undertake data collection and forwarding tasks, while leaving complex analysis and decision-making functions to the ground.

[0005] However, flying cars and traditional drones differ fundamentally in their application scenarios and system architectures, which presents multiple structural bottlenecks when migrating existing technologies to flying cars. On the one hand, as a manned transportation vehicle, flying cars have significantly higher requirements for system safety and reliability than drones. Onboard equipment needs to possess a certain level of local data processing and decision-making capabilities to reduce reliance on communication link quality and to achieve timely and effective safety responses even under extreme conditions such as communication limitations or anomalies. If health monitoring relies solely on the flight control system, the computing power and interface capabilities of the flight control hardware will be limited, making it difficult to achieve real-time collection and processing of all monitoring data. On the other hand, if data analysis and health assessment are primarily based on existing integrated air-to-ground real-time monitoring, the system's operation is highly dependent on the stability and bandwidth quality of the air-to-ground communication link. Once the communication link is interfered with, congested, or interrupted, the health assessment and risk warning functions will fail, creating potential safety hazards in manned operation scenarios.

[0006] Furthermore, existing health management systems also suffer from significant shortcomings in system integration and data fusion. As an emerging technology, flying cars have not yet formed a complete and unified industrial chain and technical standard system. Existing health management solutions largely rely on heterogeneous equipment and interface specifications from different manufacturers, resulting in poor system compatibility. During system function expansion or equipment upgrades, secondary debugging of the original system is often required, sometimes even involving hardware structure adjustments and modifications. This not only prolongs the system integration cycle but also significantly increases system deployment and subsequent maintenance costs. Simultaneously, existing systems primarily rely on fixed threshold judgments and single-parameter anomaly detection, remaining at a relatively rudimentary stage of health management. They fail to fully integrate historical operating data, environmental parameters, and the coupling characteristics of multiple systems for comprehensive analysis. They lack the ability to proactively identify equipment degradation trends, potential failure evolution paths, and system-level risks, making it difficult to fully leverage the application potential of big data and artificial intelligence technologies in health status assessment, lifespan prediction, and operational decision optimization.

[0007] Based on the above analysis, the field of flying cars urgently needs a dedicated health monitoring system with high-performance air processing capabilities, flexible expansion and intelligent analysis capabilities, so as to achieve full-process coverage of key aspects such as real-time air and ground monitoring of flying car operation status, fault early warning and alarm, accurate fault diagnosis and comprehensive health status assessment. Summary of the Invention

[0008] The present invention aims to provide a system and method for health management of flying cars, which has high-performance in-flight processing capabilities, flexible scalability, and intelligent analysis capabilities.

[0009] To achieve the above objectives, the present invention provides the following basic solution.

[0010] Option 1 A system for health management of flying cars includes an airborne terminal deployed on the flying car and a ground terminal communicatively connected to the airborne terminal; The airborne terminal includes: an expandable data acquisition unit, which adopts a programmable architecture design and reserves a hardware interface, for accessing and acquiring health status data of newly added or non-standardized functional modules on the flying car; Traditional data acquisition units are used to collect operational status data of key subsystems of flying cars through standardized protocols; The airborne processing unit is communicatively connected to the expandable data acquisition unit and the traditional data acquisition unit, respectively. The airborne processing unit integrates an artificial intelligence processing module with independent computing power. The artificial intelligence processing module is used to run a health management model that has been trained and lightweighted on the ground to perform local real-time processing, feature extraction and risk prediction on the collected multi-source health status data. The ground terminal is used to receive and store health status data from the airborne terminal, and to train and optimize the health management model based on historical data and real-time uploaded data. The optimized health management model is then lightweighted and deployed to the airborne processing unit.

[0011] Option 2 A method for health management of flying cars, comprising the following steps: (1) Using a system for health management of flying cars as described in Scheme 1. Step 1: Collect health status data of newly added or non-standardized functional modules and standardized operational status data of key subsystems through scalable data acquisition units and traditional data acquisition units deployed on the flying car. Step 2: The airborne processing unit receives the multi-source health status data and uses its integrated artificial intelligence processing module with independent computing power to run a lightweight health management model to perform local real-time processing, feature extraction and risk prediction on the multi-source health status data, and generate real-time health assessment results. Step 3: Upload the health status data and real-time health assessment results to the ground terminal via redundant communication links; Step 4: The ground terminal performs long-term persistent storage of the received health status data, and trains and optimizes the health management model based on historical data and real-time uploaded data. Step 5: The ground-based system performs lightweight processing on the trained and optimized health management model to generate an updated lightweight health management model. Step 6: Deploy the updated lightweight health management model to the airborne processing unit of the flying car to replace the original model for subsequent health status monitoring and analysis.

[0012] The working principle and advantages of this invention are as follows: This invention discloses a system and method for health management of flying cars, possessing high-performance in-flight processing capabilities, flexible scalability, and intelligent analysis capabilities. It enables full-process coverage of key aspects such as real-time air-to-ground monitoring of flying car operating status, fault early warning and alarm, accurate fault diagnosis, and comprehensive health status assessment. The key points are: This solution fundamentally solves the dilemma of achieving both real-time performance and intelligence in the health management of flying cars by constructing an air-ground collaborative system architecture. Its core advantage lies in deploying the high-real-time-requirement health monitoring and risk identification functions on the airborne end, while placing the computationally intensive model training and optimization tasks, which rely on historical data, on the ground end, achieving a reasonable division of labor at the functional level. On the airborne end, an AI processing module with independent computing power can run the intelligent model trained and lightweighted by the ground end. It performs local real-time processing, feature extraction, and risk prediction on multi-source health status data acquired by scalable data acquisition units and traditional data acquisition units. This allows the flying car to still rely on its own computing power to complete the status assessment and fault warning of critical systems under extreme conditions such as limited or interrupted communication links, triggering timely safety responses and significantly improving its autonomous safety assurance capabilities in manned operation scenarios. Simultaneously, local processing on the airborne end avoids transmitting all massive amounts of raw data back to the ground, effectively reducing dependence on the bandwidth and stability of air-ground communication links and overcoming the inherent defect of traditional integrated air-ground monitoring systems failing when communication quality is poor.

[0013] On the other hand, the scalable data acquisition unit adopts a programmable architecture and reserves hardware interfaces, enabling flexible integration of newly added sensors and functional modules during the technological evolution of flying cars without altering the original overall system architecture. As an emerging technology, the industrial chain and standards system of flying cars are still developing, and the monitored objects and data scale continue to expand with technological iterations. Traditional fixed-interface acquisition methods often result in long system integration cycles and high upgrade costs. This solution, through reserved hardware resources and configurable software design, significantly reduces the workload of secondary development and debugging during functional expansion, enabling the health management system to possess strong sustainable evolution capabilities and adapt to the long-term technological upgrade needs of flying cars.

[0014] Furthermore, the centralized storage and management of historical and real-time uploaded data on the ground provides a data foundation for the continuous training and optimization of the health management model. After lightweight processing, the model is back-deployed to the airborne terminal, forming a data-driven closed-loop evolution mechanism. This enables the health status assessment and fault identification capabilities to continuously improve with the accumulation of operational experience, thereby maintaining a high level of analysis accuracy in complex and ever-changing operating environments. Attached Figure Description

[0015] Figure 1This is a schematic diagram of the system structure of a system and method for health management of flying cars according to a first embodiment of the present invention; Figure 2 This is a schematic diagram of the scalable data acquisition unit implementation architecture of a system and method for health management of flying cars according to Embodiment 1 of the present invention; Figure 3 This is a schematic diagram of the airborne processing unit implementation architecture of a system and method for health management of flying cars according to the present invention; Figure 4 This is a schematic diagram of the ground-side health management model training logic in a first embodiment of a system and method for health management of flying cars according to the present invention. Detailed Implementation

[0016] The following detailed explanation illustrates the specific implementation methods: Example 1 The basic implementation examples are as follows: Figure 1 As shown: A system for health management of flying cars includes an airborne terminal deployed on the flying car, and a ground terminal communicatively connected to the airborne terminal. The ground terminal is deployed at a ground operations control center.

[0017] The airborne terminal includes an expandable data acquisition unit, a traditional data acquisition unit, an airborne processing unit, and a communication unit.

[0018] The scalable data acquisition unit is used to address the issue of flexible integration of new sensors and functional modules added to flying cars during technological evolution.

[0019] The scalable data acquisition unit adopts a programmable architecture and reserves hardware interfaces for accessing and acquiring health status data from newly added or non-standardized functional modules on the flying car. Specifically, the scalable data acquisition unit is implemented based on an embedded processing chip and communicates with the airborne processing unit via a CAN bus. It is used to encapsulate the data collected from different newly added sensors into standard CAN data frames before transmission.

[0020] like Figure 2 As shown, in this embodiment, the unit is implemented based on the STM32 series microcontroller. This chip uses an ARM Cortex-M4 core, with a main frequency of up to 168MHz, and features rich peripheral interfaces and programmability. In terms of hardware design, the unit board has multiple reserved general-purpose input / output (GPIO) pins. The unit includes an interface, an SPI interface, and an additional CAN controller, with corresponding pads and connector positions reserved on the circuit board for future expansion with new sensor modules. On the software side, the unit embeds a real-time operating system (RTOS) that supports dynamically loading sensor drivers. When a new sensor is connected, the firmware can be upgraded remotely via a ground terminal or the configuration file can be updated locally by maintenance personnel, achieving plug-and-play functionality.

[0021] During data acquisition, the expandable data acquisition unit reads the raw data from each newly added sensor according to a preset sampling period (e.g., 10ms to 100ms, dynamically adjusted according to the sensor type). For analog sensors, the data is converted into digital signals via an on-chip 12-bit successive approximation analog-to-digital converter (ADC); for digital interface sensors, the data is read directly according to the corresponding protocol. After acquisition, the microcontroller performs data format standardization: according to a custom CAN application layer protocol, the sensor ID, timestamp, data value, and checksum are encapsulated into a standard CAN data frame, with the data frame identifier (ID) assigned an independent range based on the sensor type. The encapsulated CAN frame is sent to the CAN bus via the unit's built-in CAN controller at a transmission rate of 500kbps or 1Mbps to ensure real-time performance.

[0022] Through the above design, the system can flexibly expand the monitored objects without changing the original architecture, significantly reducing integration costs.

[0023] The conventional data acquisition unit is used to collect operational status data of key subsystems of the flying car through standardized protocols.

[0024] The conventional data acquisition unit includes a battery management system, a motor ESC data acquisition module, and a flight control data acquisition module.

[0025] The battery management system is used to collect the voltage and temperature parameters of individual battery cells in the flying car's power battery. In this embodiment, the battery management system adopts a distributed architecture, with each battery module equipped with a slave control unit to collect the voltage and temperature of each cell within the module in real time. The voltage acquisition accuracy reaches ±2mV, the temperature acquisition accuracy is ±1°C, and the sampling period is 100ms. The slave control unit aggregates the cell-level data to the master control unit via an internal CAN bus, and the master control unit then sends the data to the onboard processing unit via the vehicle's CAN bus.

[0026] Unlike conventional battery management systems, the data reported by the battery management system in this solution includes not only aggregated parameters such as total module voltage, total current, and state of charge (SOC), but also detailed voltage and temperature information for all individual cells, thus providing a detailed data foundation for cell-level health assessment.

[0027] The motor ESC data acquisition module is used to collect the motor speed, output power, and ESC (electronic speed controller) operating status parameters in the flying car's power system.

[0028] The flight control data acquisition module is used to collect flight attitude information, control command response status information, and the health status information of the flying car's flight control system. In this embodiment, the flight control data acquisition module implements its function based on the flying car's flight control system. The flight control system acquires information such as flight attitude, altitude, speed, control surface position, and control command response status through internal sensors (such as IMU, GPS, and magnetometer) and the control bus, and outputs the above data along with the flight control self-test status (such as CPU load, memory balance, and sensor health indicators) through a dedicated data interface (such as UART or CAN). The onboard processing unit obtains this information by monitoring the flight control data bus or directly reading the flight control log interface.

[0029] The airborne processing unit is connected to the expandable data acquisition unit and the traditional data acquisition unit via a controller area network (CAN) bus, and establishes a bidirectional data link with the ground terminal via a communication unit.

[0030] Specifically, such as Figure 3 As shown, the airborne processing unit is built on the Linux operating system, has standardized data interfaces and modular expansion capabilities, and its functions include: (1) Real-time decoding and preprocessing of the acquired multi-source health status data: By real-time monitoring of the CAN bus, all CAN frames from the scalable data acquisition unit and the traditional data acquisition unit are received. The receiving thread runs at the highest priority to ensure no frame loss. Each frame of data is parsed to extract sensor ID, timestamp, value, and other information, and stored in a shared memory circular buffer according to sensor type. The preprocessing stage includes outlier removal, data interpolation (linear interpolation is used for brief packet loss), and time alignment (timestamp synchronization of each sensor data is performed using the system's high-precision clock).

[0031] (2) Operational status monitoring and anomaly identification based on preset threshold rules: The airborne processing unit has a built-in dynamic threshold management module that stores multiple levels of thresholds (warning thresholds, danger thresholds) for key parameters (such as the upper and lower limits of single cell voltage, motor temperature thresholds, etc.). The thresholds can be automatically switched according to the flight phase (such as takeoff, cruise, landing). For example, the monitoring threshold for motor current is relaxed during takeoff, while it is tightened during cruise. When real-time data triggers a threshold, the unit immediately generates an alarm event of the corresponding level and notifies the alarm management module through the internal event queue.

[0032] (3) Complete the risk assessment, alarm generation and operation status management of critical systems: This function is completed by an artificial intelligence processing module with independent computing power integrated in the airborne processing unit.

[0033] The artificial intelligence processing module is used to run a health management model that has been trained and lightweighted on the ground to perform local real-time processing, feature extraction, and risk prediction on the collected multi-source health status data.

[0034] The artificial intelligence processing module is implemented based on a GPU architecture and is used to support the operation of the health management model on the airborne end to perform trend analysis on the operating status of the key subsystems of the flying car. The computing power of the artificial intelligence processing module is configured to be 248 TOPS, and its GPU core adopts the NVIDIA Ampere architecture, which includes 2048 CUDA cores and 64 Tensor Cores. The GPU has a maximum operating frequency of 1.2GHz and the overall computing power reaches 248 TOPS (INT8).

[0035] Taking battery health prediction as an example, the model can use a Temporal Convolutional Network (TCN) or a Long Short-Term Memory Network (LSTM). The input is the voltage, temperature, and total current data of all cells within a past time window (e.g., 5 minutes). The output is the probability of each cell experiencing voltage anomalies within the next 10 minutes and the predicted value of the remaining usable capacity (SOH) of the battery. Model inference is completed on the GPU with millisecond-level latency.

[0036] After the health management model outputs the risk probability, the threshold monitoring results are integrated with the output risk probability, and a comprehensive risk level is determined using fuzzy logic or a decision tree. Risk levels are divided into four categories: "Healthy," "Caution," "Warning," and "Danger." Once the risk level reaches "Warning" or higher, the system issues a voice alarm to the pilot via onboard speech synthesis equipment, and simultaneously packages the alarm information and transmits it to the ground via the communication unit. All processing results (including raw data snapshots, feature values, risk levels, and alarm logs) are stored locally on the onboard solid-state drive with a storage capacity of no less than 256GB, capable of storing complete data from the most recent 100 flight hours.

[0037] The communication unit adopts a redundant communication architecture that combines radio communication and cellular network communication, and is equipped with an adaptive link switching mechanism to realize data transmission between the airborne processing unit and the ground terminal.

[0038] The adaptive link switching mechanism includes: real-time monitoring of the communication quality indicators of each communication link, including signal strength, latency, and packet loss rate; and dynamically selecting the current optimal communication link between the radio link and the cellular network link based on the communication quality indicators.

[0039] In this embodiment, the radio link communication quality index is set as follows: The 4G link communication quality index is The link selection strategy can then be expressed as: .

[0040] When the flight altitude is within clear airspace or the radio communication quality is better than the cellular network communication quality, the system uses the radio link for data transmission; when the flight altitude is close to the ground and the cellular network communication quality is better than the radio communication quality, the system switches to the cellular network link for communication.

[0041] Among them, the radio link communication quality index is The quality indicators for 4G link communication are All are obtained by weighting three sub-indicators: signal strength (RSSI normalized value S, range 0~1), average delay (D, unit ms, normalized to 0), and average latency (D). , To accommodate the maximum tolerable latency, this embodiment sets it to 500ms; packet loss rate (L, the percentage of packets lost in the last 10 seconds, normalized to) The weighting coefficients are dynamically adjusted according to the flight phase. For example, during takeoff and landing, when latency requirements are higher, the latency weight can be increased; during cruise, when bandwidth requirements are higher, the signal strength weight can be increased. That is, the link communication quality index Q is calculated using the following formula: A higher indicator value indicates better link quality.

[0042] , and These are the weighting coefficients for signal strength, average latency, and packet loss rate, respectively; in this embodiment, they can be set to 0.4, 0.4, and 0.3. The communication unit calculates this every second. and .

[0043] The ground terminal is used to receive and store health status data from the airborne terminal (including all raw data, feature data, alarm events and flight logs summarized by the airborne processing unit), and to perform training and optimization of the health management model based on historical data and real-time uploaded data. The optimized health management model is then lightweighted and deployed to the airborne processing unit.

[0044] In this embodiment, data received at the ground station is buffered via a Kafka message queue and then written to a distributed time-series database (such as InfluxDB) and object storage (such as MinIO) for long-term persistent storage. The database is indexed by aircraft number and time partition, supporting fast retrieval and playback.

[0045] likeFigure 4 As shown, the ground terminal constructs a health management model based on a reinforcement learning model. The reinforcement learning model provides feedback guidance on the model's decision results by constructing a reward function, thereby achieving continuous optimization of the flying car's health status determination strategy.

[0046] In this embodiment, the reinforcement learning model is specifically a Deep Q-Network (DQN) or an improved version thereof (such as DuelingDQN). The model state space is defined as the health feature vector extracted from airborne data (such as the cell voltage inconsistency coefficient, motor vibration characteristic frequency amplitude, flight control IMU deviation, etc.); the action space is defined as the classification judgment of the current health status (healthy, minor fault, serious fault, fatal fault).

[0047] The reward function includes a judgment accuracy reward item and a high-risk identification reward item; the high-risk identification reward item is used to give positive incentive to the decision-making behavior of the health management model in correctly identifying serious fault conditions or fatal fault conditions, so as to enhance the health management model's ability to identify high-risk working conditions.

[0048] In this embodiment, the reward function is expressed as: ; in, H represents the health status level labeled in history; H represents the health status level output by the model; A represents the health status classification judgment action. , These are weighting coefficients used to adjust the impact of different reward items on the model optimization process.

[0049] Among them, the accuracy reward of the judgment This is used to measure the consistency between the model output and the historically labeled health status. It is based on graded accuracy, but a graded error penalty is introduced to consider the proximity between adjacent grades. The specific calculation formula is as follows: ; The health rating here can be represented by a number from 1 to 4 (healthy = 1, minor fault = 2, serious fault = 3, fatal fault = 4).

[0050] The high-risk identification reward Used to enhance the model's ability to identify severe and fatal fault states, when the actual classification... For serious or fatal faults, an additional reward is given if the model correctly identifies them. The specific calculation formula is as follows: ; It is a positive number greater than 0, serving as an additional reward coefficient for correctly identifying high-risk states.

[0051] By assigning differentiated reward feedback to different health status classification results, the reinforcement learning model is guided to prioritize the identification of high-risk operating conditions during the decision-making process, thereby improving its ability to identify abnormal operating conditions and potential safety risks.

[0052] The lightweight processing strategy implemented by the ground end on the trained health management model includes at least one of model distillation, parameter compression, feature selection optimization, and computation graph optimization, which is used to reduce the consumption of computing resources when deploying on the airborne end while ensuring the accuracy of health status determination.

[0053] Specifically, model distillation involves using a well-trained complex model as the teacher network to train a smaller student network with a simpler structure (e.g., using fully connected layers instead of convolutional layers to reduce the number of layers and neurons), so that the student network approximates the output distribution of the teacher network.

[0054] The parameter compression specifically involves converting the model weights from 32-bit floating-point quantization to 8-bit integers (INT8), using the NVIDIA TensorRT tool for quantization calibration, and compressing the model size to 1 / 4 of its original size while maintaining an accuracy loss of less than 1%.

[0055] The computation graph optimization specifically involves: removing redundant computation nodes, merging adjacent operations (such as merging Conv+BN+ReLU into a single operator), and reducing memory access and computational overhead during inference.

[0056] Feature selection optimization specifically involves: based on feature importance analysis, removing features that contribute little to health classification, reducing the model input dimension, and further reducing the model size.

[0057] The lightweighted model has lower inference latency and smaller model file size, making it suitable for real-time operation on airborne devices.

[0058] This embodiment also provides a method for health management of flying vehicles, which uses a system for health management of flying vehicles as described above; it includes the following steps: Step 1: Collect health status data of newly added or non-standardized functional modules and standardized operational status data of key subsystems through scalable data acquisition units and traditional data acquisition units deployed on the flying car. Step 2: The airborne processing unit receives the multi-source health status data and uses its integrated artificial intelligence processing module with independent computing power to run a lightweight health management model to perform local real-time processing, feature extraction and risk prediction on the multi-source health status data, and generate real-time health assessment results. Step 3: Upload the health status data and real-time health assessment results to the ground terminal via redundant communication links; Step 4: The ground terminal performs long-term persistent storage of the received health status data, and trains and optimizes the health management model based on historical data and real-time uploaded data. Step 5: The ground-based system performs lightweight processing on the trained and optimized health management model to generate an updated lightweight health management model. Step 6: Deploy the updated lightweight health management model to the airborne processing unit of the flying car to replace the original model for subsequent health status monitoring and analysis.

[0059] This embodiment provides a system and method for health management of flying cars, which has high-performance air processing capabilities, flexible expansion and intelligent analysis capabilities, and can achieve full-process coverage of key aspects such as real-time air-to-ground monitoring of flying car operating status, fault early warning and alarm, accurate fault diagnosis and comprehensive health status assessment.

[0060] Example 2 A system for health management of flying cars, based on Embodiment 1, further designs the artificial intelligence processing module of the airborne processing unit, and introduces a distributed heterogeneous computing architecture and a multi-model collaborative reasoning mechanism.

[0061] Specifically, the artificial intelligence processing module is not a single GPU unit, but a composite processing system composed of multiple heterogeneous computing units, including a neural network processor (NPU) for processing time-series data, a vision processing unit (VPU) for processing image and video data, and a programmable gate array (FPGA) for processing vibration and acoustic emission signals. The onboard processing unit dynamically allocates computing tasks to the optimal heterogeneous computing unit based on the data source and type characteristics. The timing data of the battery system, such as voltage, current, and temperature, are processed by the NPU, which uses a lightweight temporal convolutional network or a long short-term memory network for trend prediction. The vibration and noise signals of the motor and rotor system are processed by the FPGA, which implements fast Fourier transform and feature frequency extraction at the hardware level. The visual data of the flight environment is processed by the VPU, which performs real-time perception of obstacles and weather conditions.

[0062] The airborne processing unit incorporates a multi-model collaborative inference engine, which can dynamically select or combine different lightweight models according to the flight phase and operating conditions. For example, during takeoff and landing, the system simultaneously runs a health management model, a power system fault diagnosis model, and a flight control status monitoring model, and integrates the output results of each model using a weighted voting mechanism to generate a comprehensive risk score; during cruise, it switches to a model combination primarily based on predictive maintenance of the power system.

[0063] When the confidence level of a model output is lower than a preset threshold, the airborne processing unit actively requests the ground terminal to send the latest version of the model or supplementary training data to achieve online model updates.

[0064] The confidence level calculation method varies depending on the model type: classification models use the maximum output probability of Softmax; regression models use the deviation of the prediction variance from the historical error distribution; and anomaly detection models use the distance between the anomaly score and the threshold. When the average confidence level of a model falls below a preset threshold (e.g., 0.65) over multiple consecutive inference cycles (e.g., 10 cycles, 100ms each), the model's applicability under the current conditions is deemed to have decreased, triggering an online update request.

[0065] The online update request includes the current operational condition label, model version number, confidence score, and the most recent 100 sets of input feature samples. This request is sent to the ground station via the communication unit. The ground-based model repository searches for a higher version or a model better suited to the current operational condition based on the request information. If found, the model is distributed to the airborne terminal via a secure, encrypted channel; otherwise, the ground station marks the request as a model optimization request and proceeds to the subsequent training process. After receiving the new model, the airborne terminal completes a hot-swap before the start of the next flight cycle; the update process does not affect the health monitoring of the current flight mission.

[0066] When the airborne terminal detects a potential anomaly but the local model's confidence level is insufficient (e.g., below 0.7), key feature data can be uploaded to the ground terminal via the communication unit. The ground terminal then runs a more complex model for in-depth analysis and feeds back the analysis results to the airborne terminal. Simultaneously, the ground terminal dynamically adjusts the model training strategy based on the received edge inference results and confidence level information, increasing the weight of training samples in low-confidence scenarios to achieve targeted optimization of the model.

[0067] This embodiment provides a system and method for health management of flying cars. Compared to Embodiment 1, it achieves professional and parallel processing of multi-source heterogeneous data under the premise of limited airborne computing power through a heterogeneous computing architecture and a multi-model collaborative mechanism, improving the accuracy and robustness of health assessment under complex operating conditions. Simultaneously, the collaborative reasoning mechanism between the airborne and ground ends leverages the real-time response advantage of the airborne end while retaining the deep analysis capabilities of the ground end, enabling a more refined intelligent division of labor.

[0068] The above descriptions are merely embodiments of the present invention. Commonly known structures and characteristics of the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent.

Claims

1. A system for health management of flying cars, characterized in that, This includes an airborne terminal deployed on the flying car, and a ground terminal that is communicatively connected to the airborne terminal; The airborne terminal includes: an expandable data acquisition unit, which adopts a programmable architecture design and reserves a hardware interface, for accessing and acquiring health status data of newly added or non-standardized functional modules on the flying car; Traditional data acquisition units are used to collect operational status data of key subsystems of flying cars through standardized protocols; The airborne processing unit is communicatively connected to the expandable data acquisition unit and the traditional data acquisition unit, respectively. The airborne processing unit integrates an artificial intelligence processing module with independent computing power. The artificial intelligence processing module is used to run a health management model that has been trained and lightweighted on the ground to perform local real-time processing, feature extraction and risk prediction on the collected multi-source health status data. The ground terminal is used to receive and store health status data from the airborne terminal, and to train and optimize the health management model based on historical data and real-time uploaded data. The optimized health management model is then lightweighted and deployed to the airborne processing unit.

2. The system for health management of flying cars according to claim 1, characterized in that, The scalable data acquisition unit is implemented based on an embedded processing chip and communicates with the airborne processing unit via a CAN bus. It is used to encapsulate the data acquired from different newly added sensors into a standard CAN data frame before sending it.

3. The system for health management of flying cars according to claim 1, characterized in that, The artificial intelligence processing module is implemented based on a GPU architecture and is used to support the operation of the health management model on the airborne end to perform trend analysis on the operating status of the key subsystems of the flying car. The computing power of the artificial intelligence processing module is configured to be 248 TOPS, and its GPU core adopts the NVIDIA Ampere architecture, which includes 2048 CUDA cores and 64 Tensor Cores.

4. The system for health management of flying cars according to claim 1, characterized in that, The conventional data acquisition unit includes a battery management system, which is used to collect the voltage and temperature parameters of individual cells in the power battery of the flying car.

5. A system for health management of flying cars according to claim 1, characterized in that, The airborne terminal also includes a communication unit, which adopts a redundant communication architecture combining radio communication and cellular network communication, and is equipped with an adaptive link switching mechanism to realize data transmission between the airborne processing unit and the ground terminal.

6. A system for health management of flying cars according to claim 5, characterized in that, The adaptive link switching mechanism includes: real-time monitoring of the communication quality indicators of each communication link, including signal strength, latency, and packet loss rate; and dynamically selecting the current optimal communication link between the radio link and the cellular network link based on the communication quality indicators.

7. A system for health management of flying cars according to claim 1, characterized in that, The ground terminal constructs a health management model based on a reinforcement learning model. The reinforcement learning model uses a reward function to provide feedback guidance on the model's decision-making results, thereby achieving continuous optimization of the flying car's health status assessment strategy.

8. A system for health management of flying cars according to claim 7, characterized in that, The reward function includes a judgment accuracy reward item and a high-risk identification reward item; the high-risk identification reward item is used to give positive incentive to the decision-making behavior of the health management model in correctly identifying serious fault conditions or fatal fault conditions, so as to enhance the health management model's ability to identify high-risk working conditions.

9. A system for health management of flying cars according to claim 1, characterized in that, The lightweight processing strategy implemented by the ground end on the trained health management model includes at least one of model distillation, parameter compression, feature selection optimization, and computation graph optimization, which is used to reduce the consumption of computing resources when deploying on the airborne end while ensuring the accuracy of health status determination.

10. A method for health management of flying cars, characterized in that, The system for flight vehicle health management, as described in any one of claims 1-9, includes the following steps: Step 1: Collect health status data of newly added or non-standardized functional modules and standardized operational status data of key subsystems through scalable data acquisition units and traditional data acquisition units deployed on the flying car. Step 2: The airborne processing unit receives the multi-source health status data and uses its integrated artificial intelligence processing module with independent computing power to run a lightweight health management model to perform local real-time processing, feature extraction and risk prediction on the multi-source health status data, and generate real-time health assessment results. Step 3: Upload the health status data and real-time health assessment results to the ground terminal via redundant communication links; Step 4: The ground terminal performs long-term persistent storage of the received health status data, and trains and optimizes the health management model based on historical data and real-time uploaded data. Step 5: The ground-based system performs lightweight processing on the trained and optimized health management model to generate an updated lightweight health management model. Step 6: Deploy the updated lightweight health management model to the airborne processing unit of the flying car to replace the original model for subsequent health status monitoring and analysis.

Images