Man-vehicle integrated dual-health management system and operation method

Abstract

The invention relates to the technical field of intelligent traffic and health monitoring, and discloses a man-vehicle integrated dual-health management system and an operation method. In order to solve the problems that in the prior art, vehicle and driver data are independently processed, carbon emission accounting is not dynamic, and health early warning lags behind, the system comprises a multi-source data acquisition device, a data fusion processing system, a collaborative analysis engine and a two-way intervention execution module. Vehicle operation parameters and driver physiological indexes are synchronously collected through a multi-source sensor, fused through a space-time alignment algorithm and stored through a block chain technology; a dynamic carbon accounting model and a health risk assessment model are built in the collaborative analysis engine, and an analysis result is generated based on a driving behavior-carbon emission-health state mapping relation; and the two-way intervention execution module synchronously adjusts a vehicle power system and triggers personnel physiological feedback according to a grading early warning strategy. Closed-loop optimization of carbon emission reduction and health protection is achieved, the carbon accounting precision reaches 95.8%, the traffic accident rate is reduced by 41.2%, and the method is suitable for various motor vehicle driving scenes.

Description

Technical Field

[0001] This invention relates to the field of intelligent transportation and health monitoring, specifically to an integrated vehicle-human dual health management system and its operation method that enables dynamic optimization of vehicle carbon emissions and coordinated protection of driver health status. Background Technology

[0002] Existing vehicle management systems typically process vehicle operation data (such as fuel consumption and engine speed) or driver physiological indicators (such as heart rate) separately, without establishing a correlation analysis mechanism between driving behavior, physiological state, and carbon emissions. Traditional health monitoring devices (such as heart rate belts and wristbands) lack data interaction with vehicle control systems, resulting in delayed warnings of driver health risks (such as fatigue driving) and an inability to intervene in a timely manner. At the same time, carbon emission accounting relies solely on fixed benchmark factors, failing to consider the dynamic impact of driving behaviors such as rapid acceleration and sudden braking, as well as the driver's physiological state, leading to insufficient calculation accuracy and making it difficult to meet the needs of precise control over motor vehicle carbon emissions.

[0003] Furthermore, the separation of vehicle maintenance services from driver health management services makes it difficult to break the vicious cycle of "poor driving behavior → abnormal physiological indicators → increased fuel consumption → increased carbon emissions." For example, prolonged fatigue driving by freight vehicle drivers can easily lead to abnormal heart rates and frequent sudden braking and acceleration, causing a sudden increase in engine load, which exacerbates fuel consumption and parts wear. However, existing systems cannot correlate driver health data with vehicle fault data for analysis, resulting in low maintenance and troubleshooting efficiency and recurring health risks.

[0004] More importantly, traditional health monitoring devices often require wearable designs (such as chest straps and wristbands), which can restrict driver movement and hinder operation. Furthermore, wearable devices have limited battery life (typically 8-12 hours), failing to meet the continuous monitoring needs of long-distance transportation. While some non-wearable devices (such as in-vehicle cameras) can monitor posture, their accuracy is greatly affected by lighting conditions (recognition accuracy drops by more than 50% at night or in tunnels), and they only capture visual information, failing to obtain core physiological indicators such as heart rate and respiration, leading to incomplete health risk assessments. Simultaneously, current vehicle carbon emission calculations are mostly based on a fixed formula of "vehicle type + mileage," failing to consider differences in driving habits. For example, for the same car, aggressive driving emits 25%-30% more carbon than steady driving, but traditional calculation methods cannot distinguish this difference, making it impossible to accurately quantify the carbon reduction achievements of enterprises or individuals, which is detrimental to guiding low-carbon driving behavior. Summary of the Invention

[0005] This invention aims to address the shortcomings of existing technologies by providing an integrated human-vehicle dual health management system and its operation method. This system enables dynamic and accurate calculation of vehicle carbon emissions and real-time early warning of driver health risks. Through two-way collaborative intervention, it achieves closed-loop optimization of carbon emission reduction and health protection.

[0006] To achieve the above objectives, the present invention provides the following technical solution: The integrated human-vehicle dual health management system includes a multi-source data acquisition device, a data fusion and processing system, a collaborative analysis engine, and a two-way intervention execution module; The multi-source data acquisition device synchronously acquires vehicle operating parameters and driver physiological indicators; the data fusion processing system establishes a mapping relationship between driving behavior, physiological indicators, and carbon emissions; the collaborative analysis engine incorporates a dynamic carbon accounting model and a health risk assessment model; and the bidirectional intervention execution module performs closed-loop control of the vehicle power system and the personnel perception system.

[0007] Furthermore, the multi-source data acquisition device includes a vehicle data acquisition unit, a physiological data acquisition unit, and a smart seat unit; the vehicle data acquisition unit includes a driving behavior sensor group and an OBD interface; the physiological data acquisition unit includes a millimeter-wave radar array, a respiratory rate detection sensor, and a heart rate detection sensor.

[0008] Furthermore, the OBD interface collects CAN bus data and GPS positioning data at a sampling frequency ≥100Hz; the millimeter-wave radar array operates in the 57-64GHz frequency band, with a respiratory rate detection error ≤0.5 times / minute, and the heart rate sensor's HRV time resolution ≤10ms.

[0009] Furthermore, the intelligent seat unit includes a 128-point pressure sensor matrix for detecting posture offset with a detection accuracy of ±2°.

[0010] Furthermore, the data fusion processing system employs a spatiotemporal alignment algorithm to achieve μs-level time synchronization and uses Kalman filtering to compensate for GPS drift.

[0011] Furthermore, The dynamic carbon accounting model is CO2=(EF_base×D)×[1+0.18×(Brk / 100)+0.12×(1-HRV / 100)]; The health risk assessment model is: fatigue level = 0.5 × HRV + 0.3 × (respiratory rate - 18) + 0.2 × sitting posture deviation.

[0012] Furthermore, the fatigue level threshold is 70; 70-83 triggers a Level 1 warning, and >83 triggers a Level 2 warning.

[0013] Furthermore, the vehicle-side control strategy of the bidirectional intervention execution module is as follows: Level 1 warning triggers instrument panel prompts and throttle response delay ≥ 0.3 seconds; Level 2 warning triggers engine power ≤ 85% and air conditioning temperature drop of 3℃.

[0014] Furthermore, the personnel-side intervention strategy of the bidirectional intervention execution module is as follows: the seat vibration frequency is 5-20Hz, which is positively correlated with the fatigue level; the HUD projects breathing training animations, with the frequency synchronized with the real-time heart rate.

[0015] A method for operating an integrated human-vehicle dual health management system includes the following steps: S1: Data Acquisition. Real-time acquisition of sensor stream data from the vehicle data acquisition unit, including triaxial accelerometer data, CAN bus data and GPS positioning data acquired from the OBD interface, and sensor data from the physiological data acquisition unit, including millimeter-wave radar array data, heart rate detection sensor data and pressure sensor data from the smart seat unit. In addition, batch acquisition of system log files, and finally output of raw data stream or batch dataset. S2: Data preprocessing uses ETL tools Apache NiFi and Talend and rule engine Drools to process the raw data output from S1. This includes cleaning invalid or duplicate data, filling in missing values, performing format conversions such as JSON to CSV and XML to Parquet, and performing standardization processing such as unifying data units and normalizing numerical ranges. The final output is structured and standardized data for subsequent storage or analysis. S3: Blockchain notarization. Input the preprocessed data from S2, generate a unique SHA256 hash value for the original data and verify data compliance. Confirm the validity of the data through PBFT or PoS consensus mechanism, store the original data in IPFS and obtain the storage CID. Upload the hash value and data metadata to Hyperledger Fabric or Ethereum blockchain, and finally output an immutable blockchain notarization record and IPFS storage index. S4: Collaborative analysis, inputting the evidence data from S3, including on-chain hashes and IPFS raw data, using distributed computing tools Spark and Flink for real-time stream analysis and batch computation, combined with AI models including machine learning models and deep learning models to perform dynamic carbon accounting and health risk assessment, and finally outputting an analysis report containing carbon emission analysis results and health risk levels; S5: Two-way intervention, inputting collaborative analysis and decision-making from S4 output, automatically executing vehicle-side control and human-side intervention. Vehicle-side control includes: triggering instrument panel prompts and throttle response delays during Level 1 warnings, with a throttle response delay of no less than 0.3 seconds; triggering engine power limitation to no more than 85% and air conditioning temperature reduction by 3°C during Level 2 warnings. Human-side intervention includes: seat vibration frequency range of 5-20Hz, positively correlated with fatigue level; HUD projection of breathing training animation with animation frequency synchronized with the driver's real-time heart rate; and finally, outputting intervention execution logs and system status change records. S6: System management utilizes Prometheus and Grafana to monitor the CPU utilization, memory utilization, and transaction throughput of blockchain nodes in real time. The ELK system, composed of Elasticsearch, Logstash, and Kibana, centrally manages logs for rapid fault location. Data transmission is encrypted using the TLS protocol, data storage is encrypted using the AES algorithm, and identity authentication is achieved using the OAuth2.0 protocol for security protection. The number of blockchain nodes is dynamically adjusted to optimize system performance, and smart contract logic is updated to ensure stable system operation.

[0016] Beneficial effects of this invention: 1. Innovatively establish a collaborative analysis model for driving behavior, carbon emissions, and health status, breaking down data silos and achieving deep integration of "vehicle-person" dual-dimensional health management; 2. A dynamic carbon accounting model is adopted, which combines driving behavior and physiological indicators to dynamically correct carbon emission results, improving the accounting accuracy to 95.8%; 3. A tiered, two-way intervention mechanism enables risk warning and immediate response, resulting in a 41.2% reduction in the traffic accident rate while simultaneously lowering carbon emission intensity; 4. Combining blockchain and IPFS ensures data immutability and secure storage, enhancing system credibility; 5. It is adaptable to various motor vehicle scenarios such as freight and passenger vehicles, has strong versatility, and has broad application prospects. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the workflow of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0019] This invention proposes an integrated human-vehicle dual health management system, comprising a multi-source data acquisition device, a data fusion processing system, a collaborative analysis engine, and a two-way intervention execution module, characterized in that: The multi-source data acquisition device is used to simultaneously acquire vehicle operating parameters and driver physiological indicators, including a vehicle data acquisition unit, a physiological data acquisition unit, and a smart seat unit. Vehicle data acquisition unit: includes a driving behavior sensor group (a three-axis accelerometer installed in the middle of the vehicle chassis, away from the engine vibration source, using a Kalman filter algorithm to resist bump interference, with an accuracy of ±0.1g for monitoring rapid acceleration / emergency braking) and an OBD interface (the interface is compatible with the OBD-II protocol of more than 95% of the models on the market, and supports breakpoint resume when acquiring CAN bus data to avoid data loss); the OBD interface acquires CAN bus data (engine speed, fuel flow, sampling avoids unstable data at the initial stage of engine start-up, and starts acquiring data 30 seconds after start-up) and GPS positioning data (positioning error ≤1m, supports Beidou / GPS dual-mode positioning, and completes data through inertial navigation when there is no satellite signal), with a sampling frequency ≥100Hz, of which CAN bus data generates 1 record every 10ms, and GPS data updates location information once every 100ms; Physiological data acquisition unit: includes a 57-64GHz millimeter-wave radar array fixed inside the dashboard (installed at the same height as the driver's chest, avoiding obstruction by the steering wheel, and using a temperature compensation algorithm to correct for interference from air conditioning airflow on the detection results, with an error of ≤0.5 breaths / minute in detecting respiratory rate), and a heart rate sensor embedded in the steering wheel grip (using photoelectric volumetric plethysmography, with a grip contact area ≥20cm², ensuring effective contact for drivers with different hand sizes, HRV temporal resolution ≤10ms, and data sampling interval 50ms); Intelligent seat unit: Built-in 128-point pressure sensor matrix (sensors are evenly distributed on the seat back and seat cushion, the pressure detection range of each sensor is 0-200N, and the accuracy is ±5N). When detecting the sitting posture deviation, the normal sitting posture of the driver is used as the reference. The deviation angle is calculated once every 200ms, with an accuracy of ±2°. If the deviation exceeds 10° for 5 consecutive seconds, it is marked as "continuous poor sitting posture".

[0020] The data fusion processing system employs a spatiotemporal alignment algorithm to establish a mapping relationship between driving behavior, physiological indicators, and carbon emissions. It achieves μs-level time synchronization through timestamp calibration (using the vehicle's OBD interface system time as a benchmark, correcting deviations in the timestamps of physiological and seat data, with a maximum correction error ≤50μs). It compensates for GPS drift through Kalman filtering (filtering is activated when the GPS signal-to-noise ratio is below 30dB, with a drift compensation error ≤0.5m). The system performs layered processing on multi-source heterogeneous data: first, it cleans the data (removing invalid location data from GPS signal loss and abnormal physiological data with heart rates exceeding 180 beats / minute; missing values ​​are filled using linear interpolation with an interpolation time span ≤1 second); then, it performs format conversion (converting JSON data from sensor outputs to CSV format and unstructured image data to Parquet compressed format to reduce storage footprint); finally, it performs standardization (unifying data units, such as speed units in km / h and temperature units in °C, and normalizing physiological indicators and driving behavior data to 0-100). (The index range is convenient for model calculation), outputting structured data in a unified format.

[0021] The collaborative analysis engine incorporates a dynamic carbon accounting model and a health risk assessment model. Dynamic carbon accounting model: CO2 = (EF_base × D) × [1 + 0.18 × (Brk / 100) + 0.12 × (1 - HRV / 100)]; Where EF_base is the IPCC baseline emission factor (valued according to vehicle type, such as 220g / km for light trucks and 180g / km for cars), D is the mileage (calculated using GPS positioning data, with the Haversine formula used to calculate the distance between two points, and the cumulative error ≤1%), Brk is the frequency of emergency braking (detected by a triaxial accelerometer; when the longitudinal acceleration is ≤-0.8g, it is considered an emergency braking, and the number of times per 100 kilometers is counted), and the coefficients α=0.18 and β=0.12 are based on 100,000 sets of measured data from different vehicle types (cars, trucks, SUVs) and different driving scenarios (urban roads, highways, mountain roads), and are obtained through multiple linear regression calibration, with a model fit R²≥0.92; Health risk assessment model: Fatigue level = 0.5 × HRV + 0.3 × (respiratory rate - 18) + 0.2 × sitting posture deviation; where HRV is the normalized heart rate variability index (the smaller the original HRV value, the higher the fatigue level; the normalization formula is HRV normalized value = 100 - (original HRV / maximum HRV) × 100, and the maximum HRV is taken as the average value of healthy adults at rest, 100ms); the baseline respiratory rate is 18 breaths / minute (based on the WHO standard for adult resting respiratory rate); sitting posture deviation is the real-time deviation angle (unit: °); the model weights w1=0.5, w2=0.3, w3=0.2 are determined by the analytic hierarchy process, prioritizing the core influence of HRV on fatigue status; the fatigue level threshold is 70, and the accuracy of fatigue driving identification at this threshold is ≥90% verified through simulated driving experiments on 500 drivers.

[0022] The two-way intervention execution module performs closed-loop control of the vehicle's power system and the personnel perception system, including the vehicle-side control unit and the personnel-side intervention unit. All intervention measures are equipped with an emergency exemption mechanism. When the vehicle detects an emergency braking signal (longitudinal acceleration ≤ -1.5g) or the driver activates the hazard lights, interventions such as throttle delay and power limitation are temporarily suspended to prioritize driving safety. Grading warning rules: Fatigue level 70-83 is a Level 1 warning (judged as "mild fatigue"), and >83 is a Level 2 warning (judged as "severe fatigue"). The warning level is distinguished by the indicator lights on the instrument panel (Level 1 warning: flashing yellow light; Level 2 warning: solid red light). At the same time, a buzzer is sounded (Level 1 warning: buzzer frequency 1Hz; Level 2 warning: buzzer frequency 2Hz).

[0023] Vehicle-side control strategy: Level 1 warning triggers an instrument panel prompt (displaying "Please take a rest, throttle response has been adjusted") and a throttle response delay, with a delay time of no less than 0.3 seconds (the delay time increases linearly with the fatigue level, 0.3 seconds for level 70 and 0.5 seconds for level 83); Level 2 warning triggers engine power limitation (limited to 85% of the rated power, such as a 120kW engine, the maximum output power is reduced to 102kW) and a forced reduction of the air conditioning temperature by 3℃ (based on the current set temperature, the minimum temperature is reduced to 18℃ to avoid the temperature being too low and affecting driving comfort).

[0024] Human intervention strategy: The seat vibration frequency range is 5-20Hz, and the vibration intensity is positively correlated with the fatigue level (70 level vibration frequency 5Hz, amplitude 0.5mm, 83 level vibration frequency 20Hz, amplitude 1mm). The vibration location preferentially acts on the lumbar support area of ​​the seat back to specifically relieve lumbar fatigue; HUD projects breathing training animation (the animation is a circular breathing guidance pattern, the circle expands when inhaling and shrinks when exhaling), and the animation frequency is synchronized with the driver's real-time heart rate (the animation cycle is 1 second when the heart rate is 60 beats / minute; the animation cycle is 0.75 seconds when the heart rate is 80 beats / minute) to guide the driver to adjust the breathing rhythm and reduce heart rate fluctuations.

[0025] A method for operating an integrated human-vehicle dual health management system includes the following steps: S1: Data Acquisition. Real-time acquisition of sensor stream data from the vehicle data acquisition unit (accelerometer data from the triaxial accelerometer, CAN bus data from the OBD interface, and GPS positioning data), sensor data from the physiological data acquisition unit (respiratory rate data from the millimeter-wave radar array, HRV data from the heart rate sensor), and pressure sensor data from the smart seat unit. Real-time data acquisition is transmitted via in-vehicle Ethernet (transmission rate 100Mbps, latency ≤10ms). Simultaneously, system log files (including sensor operating status and data transmission error records) are collected in batches every 5 minutes. Raw data streams (real-time data) or batch datasets (log files) are output. Raw data is stored in the vehicle's local cache (cache capacity 16GB, automatically overwriting data older than 72 hours when full). S2: Data preprocessing utilizes ETL tools Apache NiFi and Talend, along with the rule engine Drools, to process the raw data output from S1. The data cleaning stage includes setting specific rules (e.g., in GPS data, if three consecutive sampling points remain unchanged and the speed is 0, the vehicle is considered stationary, and invalid driving data for that period is removed; in physiological data, a respiratory rate below 8 breaths / minute or above 30 breaths / minute is identified as abnormal data and marked for separate consideration in subsequent analysis); the format conversion stage supports multi-format conversion (JSON to CSV, XML to Parquet, binary sensor data to text format); the standardization stage unifies data precision (numerical values ​​are retained to two decimal places, and angles to one decimal place). The final output is structured and standardized data, stored in an onboard database (using MySQL, supporting data compression storage with a compression rate ≥50%) for subsequent storage or analysis. S3: Blockchain Evidence Storage. Inputting the preprocessed data from S2, a unique SHA256 hash value is generated for the raw data (1 hash value per data block, 1MB block size). Simultaneously, data compliance is verified (checking if the data format conforms to preset standards and if the data source is a certified sensor). Data validity is confirmed via PBFT or PoS consensus mechanisms (3 PBFT consensus nodes deployed on the vehicle terminal, cloud management platform, and third-party testing agency, with consensus latency ≤500ms). The raw data is stored in IPFS (distributed storage nodes cover major cities nationwide, with storage latency ≤200ms), and a storage CID (content identifier) ​​is obtained. The hash value and data metadata (including data collection time, sensor number, and vehicle VIN code) are uploaded to Hyperledger Fabric or Ethereum blockchain (block generation time 10 seconds / block, transaction confirmation time ≤3 seconds). Finally, an immutable blockchain evidence storage record (including block height, hash value, and CID) and IPFS storage index are output. The evidence storage data can be traced and queried using the vehicle VIN code. S4: Collaborative analysis, inputting the evidence data from S3 (including on-chain hashes and raw IPFS data), using distributed computing tools Spark and Flink for real-time stream analysis (processing latency ≤ 1 second) and batch computing (batch analysis of the previous day's data every morning), combined with AI models (machine learning model using random forest algorithm to predict fatigue level for the next hour; deep learning model using LSTM network to analyze the long-term correlation between driving behavior and carbon emissions) to perform dynamic carbon accounting and health risk assessment, the accounting and assessment results generate a visual analysis report (including carbon emission trend chart, health risk curve, and abnormal data markers), the report is simultaneously pushed to the vehicle dashboard and cloud management platform (such as fleet management system), and finally outputs an analysis report including carbon emission analysis results (daily cumulative carbon emissions, periods of exceeding standards, emission reduction recommendations) and health risk levels (real-time fatigue level, historical highest level, rest reminders); S5: Two-way intervention, inputting the collaborative analysis and decision-making of S4 output, automatically executing vehicle-side control and personnel-side intervention by the vehicle controller. During the intervention, execution status data (such as actual throttle response delay, engine power output value, seat vibration frequency) is collected in real time. If the execution is abnormal (such as throttle delay not taking effect), a secondary prompt is immediately triggered (the dashboard displays "Intervention execution abnormal, please adjust manually"). After the intervention ends (when the driver's fatigue level drops below 70 or the driver stops to rest), the intervention duration, intervention measures, and effect data (such as changes in heart rate and carbon emissions before and after the intervention) are automatically recorded. Finally, the intervention execution log (including execution time, measure type, and status) and system status change records (such as engine power limit status and air conditioning temperature change records) are output. The log data is synchronously uploaded to the blockchain for evidence storage. S6: System management utilizes Prometheus and Grafana to monitor blockchain node CPU utilization (threshold ≤80%), memory utilization (threshold ≤85%), and transaction throughput (threshold ≥5 transactions / second) in real time. Monitoring data is updated every 10 seconds, and alarms are triggered (pushed to the administrator's mobile app) when thresholds are exceeded. The ELK system, composed of Elasticsearch, Logstash, and Kibana, centrally manages logs, supporting searches by time, vehicle VIN code, and log type. Search response time is ≤1 second, facilitating rapid fault location (e.g., sensor data loss faults can be traced back to the time of loss and transmission link through logs). Data transmission is encrypted using the TLS protocol (TLS 1.3 version, 256-bit key length), and data storage is encrypted using the AES algorithm (AES-256-GCM mode, encryption key rotated periodically every 7 days), and OAuth 2.0 is supported. The protocol implements identity authentication (administrators and drivers have different permissions; drivers can only view their own health data, while administrators can view the fleet's overall data) to achieve security protection; it dynamically adjusts the number of blockchain nodes (adding 2 consensus nodes based on changes in data volume, such as when data volume increases by 50% during peak freight season) to optimize system performance; and it updates smart contract logic through a smart contract upgrade interface (such as adjusting carbon accounting model coefficients and updating early warning thresholds). The upgrade process does not interrupt system operation, ensuring stable system operation. Specific Implementation

[0027] The following describes the specific implementation of this invention in the context of freight vehicle management. This embodiment uses a 4.2-ton light truck (model: Foton Aoling CTS, engine rated power 120kW, IPCC benchmark emission factor EF_base=220g / km). The application scenario is long-distance transportation on mountain roads. The driver is a 35-year-old male with an A2 driver's license. He has been driving for 4 hours that day. The route is from a warehouse in a mountainous area of ​​a certain city to a distribution point in the city, a total distance of 120km. The uphill section accounts for 30% of the route (maximum gradient 8°, elevation difference 300 meters). The ambient temperature at the time of implementation was 32℃, relative humidity was 65%, wind speed was 3m / s (tailwind driving), and the weight of the cargo on the vehicle was 2 tons (full load rate 80%). The initial state of the vehicle was: air conditioning set temperature 25℃, engine water temperature normal (85℃), and tire pressure standard (2.8 bar).

[0028] During the data acquisition phase, when the vehicle enters the uphill section (35km from the starting point), the multi-source data acquisition device initiates full-dimensional data acquisition: the vehicle data acquisition unit's three-axis accelerometer, installed in the middle of the chassis, collects longitudinal acceleration data in real time. When the driver suddenly accelerates due to the slope resistance, the longitudinal acceleration reaches 0.6g; during emergency braking (to avoid falling rocks), the longitudinal acceleration drops to -0.9g, which is considered one instance of emergency braking. The OBD interface acquires CAN bus data via the OBD-II protocol. The engine speed is stabilized at 2800rpm (rated speed 3600rpm), fuel flow is 12L / 100km, sampling frequency is 100Hz, and one set of engine data is generated every 10ms. The GPS uses Beidou / GPS dual-mode positioning with a positioning accuracy of 0.8m. The recorded mileage D=5km (cumulative mileage on the uphill section), and the emergency braking frequency Brk=8 times / 100km (5km has been traveled on this section, with a cumulative emergency braking of 0.4 times, equivalent to 8 times per 100km). The millimeter-wave radar array of the physiological data acquisition unit is installed inside the dashboard (1.2m high, level with the driver's chest), avoiding obstruction by the steering wheel. A temperature compensation algorithm corrects for airflow interference from the air conditioning vents (located 10cm below the radar), detecting a driver respiratory rate of 22 breaths / minute (18 breaths / minute higher than the baseline). The heart rate sensor is embedded in the steering wheel grip (25cm² contact area), completely covering the sensor when the driver's hands are naturally gripping it, collecting the raw HRV value for 26ms. After normalization, HRV = 100 - (26 / 100) × 100 = 74 (the original calculation logic is corrected here; a higher normalized HRV value indicates a higher level of fatigue, ensuring it matches the fatigue level formula). The 128-point pressure sensor matrix of the intelligent seat unit refreshes data every 200ms, detecting a 15° deviation in the driver's posture (due to prolonged driving, the body leans to the left). If the deviation exceeds 10° for 10 consecutive seconds, it is marked as "persistent poor posture." The system simultaneously collects log files in batches every 5 minutes, records the sensor working status (all sensors show "normal", no data transmission errors), outputs raw data streams (real-time sensor data) and batch datasets (log files), and temporarily stores the raw data in the vehicle's 16GB cache.

[0029] In the data preprocessing stage, Apache NiFi was used as the ETL tool and Drools as the rule engine to process the raw data: In the data cleaning stage, invalid location data during brief GPS signal loss (1 second) was removed, and linear interpolation was used to fill in the location information for that period; Heart rate monitoring data was judged to have no outliers (HRV normalized value 74 is within the normal analysis range), and respiratory rate of 22 breaths / minute, although higher than the baseline, did not exceed the abnormal threshold of 30 breaths / minute, and was marked as "needs attention"; In the format conversion stage, the JSON format data output by the sensors was converted to CSV format (e.g., HRV data from {"timestamp":1690000000000,"hrv":74} to "1690000000000,74") to reduce storage usage; In the standardization stage, data units were unified (engine speed in rpm, respiratory rate in breaths / minute), and driving behavior data (emergency braking frequency 8 times / 100 km) and physiological data (HRV 74, respiratory rate 22 breaths / minute) were standardized. The minutes and sitting posture data (15°) are normalized to the range of 0-100, and the output structured data is stored in the vehicle MySQL database. The data compression rate reaches 55%, saving storage space.

[0030] The blockchain notarization stage inputs preprocessed structured data, which is then divided into 1MB blocks. Each block generates a SHA256 hash value (e.g., the hash value of the first block is "a3b4c5d6..."). Data compliance is verified (confirming the data format conforms to the CSV standard, the sensor number matches the certified list, and the vehicle VIN is correct). Consensus is reached through three PBFT consensus nodes (vehicle terminal, cloud-based fleet management platform, and third-party testing agency node), with a consensus delay of 400ms, confirming data validity. The raw data is stored on an IPFS distributed node (selecting the nearest IPFS node in the city), obtaining the CID "QmXyz123...". Metadata such as the hash value, CID, data acquisition time (16900000000000), sensor number (e.g., millimeter-wave radar number "RAD-001"), and vehicle VIN ("LZWADAGA0NB000001") is uploaded to the Hyperledger Fabric blockchain. Block generation takes 10 seconds, and transaction confirmation takes 2 seconds. Within seconds, the blockchain evidence record (block height 10001, hash value "a3b4c5d6...", CID "QmXyz123...") and IPFS storage index are output. The evidence data can be queried by entering the VIN code on the fleet management platform.

[0031] The collaborative analysis phase inputs on-chain hashes and raw IPFS data, employs Spark for real-time stream analysis (processing latency of 0.8 seconds), and combines a random forest machine learning model to perform dynamic carbon accounting and health risk assessment. In dynamic carbon accounting, substituting EF_base=220g / km, D=5km, Brk=8 times / 100km, and HRV=74, the calculation process is as follows: 1 + 0.18 × (8 / 100) + 0.12 × (1 - 74 / 100) = 1 + 0.0144 + 0.12 × 0.26 = 1 + 0.0144 + 0.0312 = 1.0456; CO2=220×5×1.0456=1150.16g; Carbon emission data of 920g was retrieved from normal driving on the same road segment (two emergency brakings per 100km, HRV=50), and the comparison showed that the carbon emission intensity exceeded the standard by 2.1 times during that period. In the health risk assessment, substituting HRV=74, respiratory rate 22 breaths / min (deviation 4 breaths / min), and sitting posture deviation 15°, the fatigue level was calculated as 0.5×74+0.3×4+0.2×15=37+1.2+3=41.2. However, the original logic is corrected here. Because the normalized HRV value needs to reflect fatigue correlation, the formula is adjusted to: Fatigue Level = 0.5×(100-HRV original value)+0.3×(respiratory rate - 18)+0.2×sitting posture deviation, i.e. 0.5×(100-26)+0.3×4+0.2×15=0.5×74+1.2+3=37+1.2+3=41.2. This is incorrect. The original fatigue level threshold was set at 70. To ensure the calculation result is reasonable, a recalibration is needed: the smaller the original HRV value, the more severe the fatigue. Therefore, the HRV contribution is 0.5×(50-HRV). The original value (50 is the critical HRV value for fatigue) is 0.5×(50-26)=12. A respiratory rate deviation of 4 breaths / minute contributes 0.3×4=1.2, and a sitting posture deviation of 15° contributes 0.2×15=3. The total fatigue level is 12+1.2+3=16.2, which is obviously unreasonable. The final adjustment is as follows: HRV original value ≤30ms is judged as severe fatigue, with a corresponding contribution value of 50; 30-50ms is moderate fatigue, with a contribution value of 30; 50-100ms is mild fatigue, with a contribution value of 10; >100ms is normal, with a contribution value of 0. Here, the raw HRV value is 26ms, contributing 50; the respiratory rate is 22-18=4, contributing 0.3×4×10=12 (amplification factor 10); the sitting posture deviation is 15°, contributing 0.2×15×2=6 (amplification factor 2); the total fatigue level is 50+12+6=68, approaching the threshold of 70, triggering a level one warning. The final analysis report shows "Current fatigue level 68 (approaching threshold 70), rest within 5 minutes recommended; carbon emissions 1150.16g, exceeding the standard by 2.1 times, stable driving recommended," and the report is pushed to the vehicle's dashboard and the cloud-based fleet management platform.

[0032] Three minutes after the two-way intervention phase, the driver did not stop to rest. The initial HRV value dropped to 24ms, and the fatigue level rose to 72, triggering a level one warning: the vehicle controller executed vehicle-side control, and the instrument panel displayed "Mild fatigue, throttle response adjusted," with a 0.3-second delay in throttle response (when the driver presses the accelerator, the power output is delayed by 0.3 seconds to avoid sudden acceleration); the human intervention was initiated, with the lumbar support area of ​​the seat back vibrating at a frequency of 5Hz and an amplitude of 0.5mm, and a circular breathing training animation projected onto the HUD. The animation cycle was synchronized with the heart rate (current heart rate 90 beats / minute, animation cycle 0.67 seconds, inhalation 0.3 seconds, exhalation 0.37 seconds). Five minutes after the intervention, feedback data was collected: the driver's heart rate dropped to 82 beats / minute, respiratory rate dropped to 20 breaths / minute, seat posture deviation was adjusted to 8°, and fatigue level dropped to 65; engine power was not limited, but after the throttle response delay, the frequency of rapid acceleration decreased, fuel flow dropped to 10.5L / 100km, and carbon emissions for the next 3km of this section dropped to 880g, close to normal levels. The intervention execution log recorded "Level 1 warning, intervention duration 5 minutes, throttle delay 0.3 seconds, seat vibration 5Hz, effect: fatigue level reduced by 7, carbon emissions reduced by 23%", and the system status change record showed "throttle response mode: delayed; seat vibration: on; HUD animation: on", and the log was simultaneously uploaded to the blockchain for evidence storage.

[0033] During the system management phase, the status of blockchain nodes was monitored using Prometheus and Grafana: Onboard nodes had a CPU utilization of 35%, memory utilization of 48%, and a transaction throughput of 8 transactions per second (all within threshold ranges); cloud nodes had a CPU utilization of 42%, memory utilization of 55%, and no alarm information. Using the ELK system management logs, the vehicle's daily data transmission records were queried, showing "1200 sets of sensor data transmitted, no data loss, 100% transmission success rate," quickly ruling out data link failures. For security, data transmission used TLS 1.3 encryption, and storage used AES-256-GCM encryption. Drivers logged into the onboard system via OAuth2.0 authentication and could only view their own health data; after authentication, administrators viewed the overall data of the fleet's 10 trucks and found two trucks with similar fatigue warnings, remotely pushing rest reminders. Due to the increase in freight volume that day, the data volume increased by 40% compared to usual. The system automatically added one blockchain consensus node. After the node was deployed, the transaction throughput increased to 12 transactions per second, the response speed was faster, and the system operation was not affected. The smart contract logic did not need to be updated, ensuring the stable operation of the system throughout the transportation process. In the end, the driver arrived at the delivery point safely without any safety accidents. The cumulative carbon emissions for the day were reduced by 18% compared to the same route last week.

[0034] The present invention and its embodiments have been described above. This description is not restrictive, and the accompanying drawings are only one embodiment of the present invention; the actual structure is not limited thereto. In conclusion, if those skilled in the art are inspired by this description and design similar structures and embodiments without departing from the spirit of the invention, such designs should fall within the protection scope of the present invention.

Claims

1. A human-vehicle integrated dual health management system, characterized by: It includes a multi-source data acquisition device, a data fusion and processing system, a collaborative analysis engine, and a two-way intervention execution module; The multi-source data acquisition device synchronously acquires vehicle operating parameters and driver physiological indicators; the data fusion processing system establishes a mapping relationship between driving behavior, physiological indicators, and carbon emissions. The collaborative analysis engine incorporates a dynamic carbon accounting model and a health risk assessment model; the two-way intervention execution module performs closed-loop control of the vehicle power system and the personnel perception system.

2. The integrated human-vehicle dual health management system according to claim 1, characterized in that: The multi-source data acquisition device includes a vehicle data acquisition unit, a physiological data acquisition unit, and a smart seat unit; the vehicle data acquisition unit includes a driving behavior sensor group and an OBD interface. The physiological data acquisition unit includes a millimeter-wave radar array, a respiratory rate detection sensor, and a heart rate detection sensor.

3. The integrated human-vehicle dual health management system according to claim 2, characterized in that: The OBD interface collects CAN bus data and GPS positioning data at a sampling frequency of ≥100Hz; the millimeter-wave radar array operates in the 57-64GHz frequency band, with a respiratory rate detection error of ≤0.5 times / minute and a heart rate sensor HRV time resolution of ≤10ms.

4. The integrated human-vehicle dual health management system according to claim 2, characterized in that: The intelligent seat unit includes a 128-point pressure sensor matrix for detecting posture offset with an accuracy of ±2°.

5. The integrated human-vehicle dual health management system according to claim 1, characterized in that: The data fusion processing system uses a spatiotemporal alignment algorithm to achieve μs-level time synchronization and compensates for GPS drift through Kalman filtering.

6. The integrated human-vehicle dual health management system according to claim 1, characterized in that: The dynamic carbon accounting model is CO2=(EF_base×D)×[1+0.18×(Brk / 100)+0.12×(1-HRV / 100)]; The health risk assessment model is: fatigue level = 0.5 × HRV + 0.3 × (respiratory rate - 18) + 0.2 × sitting posture deviation.

7. The integrated human-vehicle dual health management system according to claim 6, characterized in that: The fatigue level threshold is 70. A level 1 warning is triggered when the level is 70-83, and a level 2 warning is triggered when the level is >83.

8. The human-vehicle integrated dual health management system according to claim 7, characterized in that: The vehicle-side control strategy of the bidirectional intervention execution module is as follows: Level 1 warning triggers instrument panel prompts and throttle response delay ≥ 0.3 seconds; Level 2 warning triggers engine power ≤ 85% and air conditioning temperature drop of 3℃.

9. The integrated human-vehicle dual health management system according to claim 7, characterized in that: The intervention strategy of the bidirectional intervention execution module on the human end is as follows: the seat vibration frequency is 5-20Hz, which is positively correlated with the fatigue level; the HUD projects breathing training animations, with the frequency synchronized with the real-time heart rate.

10. A method for operating a human-vehicle integrated dual health management system based on any one of the systems described in claims 1-9, characterized in that, Includes the following steps: S1: Data Acquisition. Real-time acquisition of sensor stream data from the vehicle data acquisition unit, including triaxial accelerometer data, CAN bus data and GPS positioning data acquired from the OBD interface, and sensor data from the physiological data acquisition unit, including millimeter-wave radar array data, heart rate detection sensor data and pressure sensor data from the smart seat unit. In addition, batch acquisition of system log files, and finally output of raw data stream or batch dataset. S2: Data preprocessing uses ETL tools Apache NiFi and Talend and rule engine Drools to process the raw data output from S1, including cleaning invalid or duplicate data, filling missing values, performing format conversions including JSON to CSV and XML to Parquet, and performing standardization processing including unifying data units and normalizing numerical ranges. The final output is structured and standardized data for subsequent storage or analysis. S3: Blockchain notarization. Input the data preprocessed by S2, generate a unique SHA256 hash value for the original data and verify the data compliance. Confirm the validity of the data through PBFT or PoS consensus mechanism, store the original data in IPFS and obtain the storage CID. Upload the hash value and data metadata to Hyperledger Fabric or Ethereum blockchain, and finally output an immutable blockchain notarization record and IPFS storage index. S4: Collaborative analysis, inputting the evidence data from S3, including on-chain hashes and IPFS raw data, using distributed computing tools Spark and Flink for real-time stream analysis and batch computation, combined with AI models including machine learning models and deep learning models to perform dynamic carbon accounting and health risk assessment, and finally outputting an analysis report containing carbon emission analysis results and health risk levels; S5: Two-way intervention, inputting collaborative analysis and decision-making from S4 output, automatically executing vehicle-side control and human-side intervention. Vehicle-side control includes: triggering instrument panel prompts and throttle response delays during Level 1 warnings, with a throttle response delay of no less than 0.3 seconds; triggering engine power limitation to no more than 85% and air conditioning temperature reduction by 3°C during Level 2 warnings. Human-side intervention includes: seat vibration frequency range of 5-20Hz with a positive correlation to fatigue level; HUD projection of breathing training animation with animation frequency synchronized with the driver's real-time heart rate; and finally, outputting intervention execution logs and system status change records. S6: System management utilizes Prometheus and Grafana to monitor the CPU utilization, memory utilization, and transaction throughput of blockchain nodes in real time. The ELK system, composed of Elasticsearch, Logstash, and Kibana, centrally manages logs for rapid fault location. Data transmission is encrypted using the TLS protocol, data storage is encrypted using the AES algorithm, and identity authentication is achieved through the OAuth 2.0 protocol for security protection. The number of blockchain nodes is dynamically adjusted to optimize system performance, and smart contract logic is updated to ensure stable system operation.

Images