A HUD Emergency Event Display and Processing Method and System

Abstract

This invention discloses a method and system for handling emergency events displayed on a head-up display (HUD). The method uses multi-source data fusion to predictively assess driving risks and driver intentions, and calculates an urgency coefficient. It employs a dual-core MCU hardware architecture and a resource preemptive scheduling strategy. When an emergency event is determined, the high-performance main core, dedicated to emergency tasks, immediately preempts the regular display resources managed by the auxiliary core through inter-core communication, ensuring that emergency alerts are rendered with a deterministic delay of microseconds. Simultaneously, the solution introduces dynamic visual enhancement technology, enabling warning icons to move dynamically according to the direction of danger, change their shape and flashing frequency according to the risk level, and adapt their brightness according to the driver's attention level, thereby actively guiding the driver's gaze and enhancing risk perception. This invention upgrades the HUD from a passive information display to an active safety assistant, significantly improving driving safety.

Description

TECHNICAL FIELD

[0001] The present application relates to a HUD display processing technology, and in particular to a HUD emergency event display processing method and system. BACKGROUND

[0002] Vehicle head-up display (HUD) is a key human-machine interaction component in intelligent driving, which can project vehicle driving parameters, navigation information and emergency danger prompts and other key content to the driver's front field of view, reduce visual transfer and improve driving safety. Among them, for the prompt of lane deviation, collision warning and other emergency danger events, the real-time and effectiveness of the display are directly related to the emergency reaction time of the driver, which is the core link to avoid traffic accidents.

[0003] However, as the safety requirements of intelligent driving systems continue to increase, existing HUDs have gradually revealed several bottlenecks in emergency event display and processing, making it difficult to meet the ultimate safety demands of "early prediction, rapid response, and strong alerts" for danger. Existing technical solutions mainly have the following limitations: 1. Delayed response mechanism, unable to achieve instantaneous warning: Most existing solutions use a single-core processor or a simple multi-core homogeneous design. All tasks (including routine information display and emergency event processing) share computing and display resources and are uniformly refreshed according to a fixed rendering frame rate (such as 30fps or 60fps). When an emergency event (such as an alarm signal from the CAN bus) occurs, the generation and display of the warning information must wait for the next fixed refresh cycle, resulting in a response delay of up to tens of milliseconds. In critical scenarios where every second counts, such as high-speed driving, this delay may directly lead to an unavoidable accident, and the system cannot guarantee the deterministic real-time output of emergency alerts. 2. Passive recognition logic, lacking pre-emptive prediction capability: The emergency triggering of existing solutions mostly relies on the passive reception and response to single, explicit vehicle network signals (such as lane departure warning (LDW) messages), which is a "post-event alarm." It lacks the ability to integrate and analyze vehicle dynamics (CAN bus data), surrounding environment (ADAS perception data), and driver status (DMS monitoring data) to understand intent. This prevents proactive risk prediction and early warning when the driver is distracted, fatigued, or when the vehicle exhibits a risk trend but hasn't reached the physical alarm threshold, thus missing valuable warning windows. 3. Static display format, insufficient alerting effect and guidance: Existing emergency alerts are typically presented as static icons, fixed locations, and preset colors. This single display method has significant drawbacks: visibility is easily affected by complex road lighting backgrounds; it cannot dynamically guide the driver's gaze based on the direction of the hazard source; and it cannot adaptively adjust the warning intensity (such as brightness and flashing frequency) based on risk level or driver attention status. Therefore, in emergency situations, static alerts are easily ignored or misinterpreted by drivers, and the perception and effectiveness of the warnings need significant improvement. 4. Insufficient system reliability assurance: In traditional architectures, a failure in a single computing core often leads to the failure of the entire HUD display function, including the emergency alert function, which does not meet high standards of functional safety.

[0004] In summary, existing HUD emergency event display solutions have room for improvement in terms of real-time performance, predictability, interactive effectiveness, and reliability. Summary of the Invention

[0005] Purpose of the invention: The first purpose of the invention is to provide a HUD emergency event display and processing method that is fast-responding, provides proactive early warning, has a significant warning effect, and is robust. The second purpose of the invention is to provide a system for implementing the method.

[0006] Technical solution: The HUD emergency event display processing method of the present invention is executed by a dual-core microprocessor including a main core and a secondary core, and includes the following steps:

[0007] (1) Initialize the main core and the auxiliary core, configure the main core for security monitoring and decision-making, configure the auxiliary core for regular display rendering, and establish a communication and mutual inspection mechanism between the two cores;

[0008] (2) The main core continuously fuses multi-source data of vehicle status, environmental perception and driver status, and calculates the urgency coefficient based on the fusion result to achieve predictive judgment of emergency events;

[0009] (3) When it is determined that an emergency display needs to be triggered, the main core instructs the auxiliary core, and the auxiliary core releases the occupation of the display control hardware resources with a preset deterministic time consumption. Then the main core immediately takes over the resources to ensure the strong real-time performance of the emergency display.

[0010] (4) The resources controlled by the main core are used for emergency display, and at least one visual attribute of the warning content is dynamically adjusted according to the risk assessment results of the emergency event in order to guide danger or enhance attention;

[0011] (5) When the emergency is lifted, the main core instructs the auxiliary core to resume control of the display control hardware resources and routine display rendering tasks, and the system returns to continuous monitoring state.

[0012] Preferably, the mutual inspection mechanism in step (1) is a heartbeat mutual inspection mechanism.

[0013] Preferably, the method further includes redundant steps:

[0014] When the auxiliary core determines that the main core is faulty through the heartbeat mutual check, the auxiliary core initiates a degradation process to output a basic safety prompt.

[0015] When the main core determines that the auxiliary core is faulty through the heartbeat mutual check, the main core takes over the normal display rendering task.

[0016] Preferably, the urgency coefficient in step (2) is obtained by a weighted calculation formula, specifically: multiplying the multiple feature values ​​representing environmental risk, driver state risk, vehicle dynamic risk and environmental interference by the corresponding preset weight coefficients and then summing them to obtain the urgency coefficient.

[0017] Preferably, step (2) of calculating the urgency coefficient based on the fusion result and making a predictive judgment includes:

[0018] The calculated urgency coefficient is compared with a preset first threshold and a second threshold, wherein the first threshold is less than the second threshold;

[0019] When the urgency coefficient is greater than or equal to the first threshold and less than the second threshold, it is determined to be a pre-trigger state, and the main core performs early warning resource preparation but does not trigger the display;

[0020] When the urgency coefficient is greater than or equal to the second threshold, it is determined that an emergency display needs to be triggered immediately.

[0021] Preferably, in step (2), the predictive judgment includes: matching the extracted features with a built-in dangerous scene model library, which contains a variety of predefined dangerous scene models.

[0022] Preferably, the emergency display in step (4) includes: transmitting the pre-stored warning content data directly from the memory to the display controller for display via the direct memory access controller.

[0023] According to the method of claim 1, the visual attribute in step (4) includes:

[0024] Based on the direction of the hazard source, control the movement of the warning content in the HUD display screen;

[0025] Adjust the flashing frequency, color, or display size of the warning content according to the level of urgency;

[0026] When it is determined that the driver's attention is distracted, the brightness or contrast of the warning content is increased.

[0027] The HUD emergency event display and processing system of the present invention is used to implement the method, including:

[0028] A dual-core microprocessor, consisting of a main core and a secondary core;

[0029] Display control hardware resources, including at least a display controller;

[0030] The main core is configured to: perform multi-source data fusion and urgency coefficient calculation, make predictive judgments and decisions based on the calculation results, send instructions to the auxiliary core when it is determined that an emergency display needs to be triggered, and execute an emergency display that integrates dynamic visual enhancement strategies after taking over the display control hardware resources;

[0031] The auxiliary core is configured to perform regular display rendering tasks and, in response to instructions from the main core, release the occupation of the display control hardware resources with a preset deterministic timeout.

[0032] Preferably, the system further includes a shared memory, wherein the shared memory is divided into:

[0033] The main core dedicated area is used to store running programs and emergency warning data;

[0034] A dedicated area for auxiliary cores, used for running routine tasks;

[0035] The spare area is dedicated to preserving the mission context when the auxiliary core releases resources.

[0036] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: (1) It does not need to follow a fixed frame rate, significantly advances the warning time of potential driving risks, and provides drivers with sufficient emergency response time, thus significantly improving driving safety; (2) It optimizes the allocation and utilization efficiency of system resources and improves the overall system performance; (3) In the abnormal situation of a single processor core failure, the minimum safety prompt function is not lost through redundancy design, which significantly enhances the system's operational reliability in complex vehicle environments; (4) It is compatible with HUD systems of various vehicle models, with low modification difficulty and controllable cost, and is easy to apply in batches; (5) Through dynamic and highly guiding visual prompts, it greatly enhances the conspicuousness and perception intensity of warning information, ensuring that drivers can quickly perceive and understand risks in different states and environments; (6) It effectively distinguishes between the driver's active operation and unconscious risks, thereby significantly reducing false alarms and improving the system's credibility and the user's overall experience. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall architecture of the present invention;

[0038] Figure 2 This is a block diagram of the dual-core task division and inter-core communication of the present invention;

[0039] Figure 3 is a flowchart of the urgency coefficient calculation of the present invention;

[0040] Figure 4 is a timing diagram of resource release and display according to the present invention;

[0041] Figure 5 is a schematic diagram of the dynamic visual enhancement (DVE) scene of the present invention. Detailed Implementation

[0042] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0043] As shown in the attached figure, the present invention provides a method for HUD emergency event display and processing. The core design of the method is as follows: a "main-auxiliary" dual-core architecture and a three-level task priority division lay the hardware foundation for emergency event processing; proactive prediction is achieved through multi-source data fusion and driver intention prediction; strong real-time performance is ensured through a deterministic resource preemption and release mechanism; and optimal warning perception is ensured through a dynamic visual enhancement strategy.

[0044] Example 1

[0045] This embodiment describes a method for HUD emergency event display processing executed by a dual-core microcontroller unit (MCU). The MCU includes a high-performance main core (such as Cortex-M7, responsible for complex calculations and emergency tasks) and a high-efficiency auxiliary core (such as Cortex-M0+, responsible for regular input / output and display).

[0046] 1. Design Principles and System Division of Labor

[0047] To achieve strong determinism and real-time performance in emergency response, this method is constructed based on the following principles:

[0048] (1) Hardware core and task division: The Infineon Travelo-II CYT3DL dual-core MCU is used as the control core, which integrates a Cortex-M7 main core and a Cortex-M0+ auxiliary core, wherein:

[0049] Cortex-M7 (High Priority Core): Dedicated to processing high-priority tasks, its core responsibilities include: fusion processing of multi-source data (vehicle CAN data, radar / camera data, driver monitoring system (DMS) data); calculation of driver intent prediction models; identification, judgment, and triggering of emergency and dangerous tasks; unified coordination and allocation of system resources; reception and parsing of emergency commands in the vehicle CAN bus; and resource release control during emergency task execution to ensure that emergency tasks occupy core resources throughout the entire process.

[0050] Cortex-M0+ secondary core (regular task core): It is dedicated to processing low-priority routine tasks. Its core responsibilities include: acquiring and parsing routine sensor data such as GPS navigation and light sensor; rendering and refreshing routine HUD display content (vehicle speed, RPM, navigation information); responding to driver manual operations (brightness adjustment, display switching); performing routine tasks normally when there are no emergency tasks, and receiving instructions from the main core and quickly releasing the occupied system resources when an emergency task is triggered.

[0051] (2) System task priority division

[0052] To prioritize the handling of urgent and dangerous tasks, all tasks within the system are divided into three priority levels, with clearly defined resource usage priorities:

[0053] Highest priority (emergency and dangerous tasks): These include tasks directly related to driving safety, such as lane departure warnings, tire pressure warnings, and vehicle malfunction emergency warnings. These tasks have priority access to all core system resources, and all low-priority tasks will be suspended immediately upon triggering.

[0054] Intermediate priority (core routine tasks): These include basic tasks that ensure the normal operation of the HUD, such as routine CAN bus data parsing and core sensor data acquisition. They are only executed when there are no urgent or dangerous tasks. Resources must be released immediately when an emergency task is triggered.

[0055] Lowest priority (auxiliary routine tasks): Non-core tasks such as adjusting display brightness, switching display content, and recording fault logs can be paused at any time to give way to higher priority tasks.

[0056] 2. Method and Flow

[0057] Based on the above division of labor, the specific process of the method is as follows:

[0058] Step 1: System power-on, initialization, and readiness

[0059] (1) After the system is powered on and reset, the main core and the auxiliary core perform initialization operations respectively to ensure that the system enters a deterministic and safe operating state:

[0060] Main core initialization: Configure the CAN controller driver, interrupt vector table, direct memory access controller, inter-core communication hardware module, load the weights and parameters of the urgency calculation model, and start the resource status monitoring background task.

[0061] Secondary core initialization: Configure the regular sensor interface, display controller refresh timing and layers, brightness adjustment, and preset the spare SRAM partition.

[0062] A dual-core heartbeat mutual check mechanism is established: the primary core and the secondary core exchange startup ready signals and establish a periodic "heartbeat" mutual check mechanism. If either core detects that the other's heartbeat has timed out, it will trigger a system-level error handling process.

[0063] (2) Entering the working cycle: After initialization, the system enters the normal working state.

[0064] The secondary core begins executing its main task loop, continuously rendering and outputting regular display content, such as vehicle speed, navigation, and indicator lights.

[0065] The main core begins its main task loop, continuously reading and monitoring multi-source data from the bus and calculating the urgency coefficient K in real time, but does not initiate any resource preemption at this time.

[0066] Step 2: Multi-source data acquisition, fusion, and risk prediction

[0067] This step is executed within the main core's task loop and is the core of achieving proactive prediction. It includes the following sub-steps:

[0068] (1) Data acquisition: The main core receives vehicle dynamic data (vehicle speed, steering wheel angle, brake pedal depth, turn signal status) via CAN bus; receives ADAS perception data (relative distance to the vehicle in front / obstacle, relative speed, lane curvature) via vehicle Ethernet or other interfaces; and receives driver monitoring system (DMS) data (driver's line of sight, head posture, eye closure / yawning fatigue status) via dedicated interface.

[0069] (2) Data preprocessing: The acquired raw data is filtered to remove noise and normalized to unify the dimensions of different sensors. Subsequently, the multi-source data is spatiotemporally synchronized using timestamp information to ensure that the vehicle status, environmental information and driver status at the same time are aligned.

[0070] (3) Feature extraction and scene matching: Key features (such as lateral speed, distance from lane lines, line deviation angle, and eyelid closure frequency) are extracted from the preprocessed data. The system matches these features with the pre-set dangerous scene models (such as "sudden braking and rear-end collision", "unconscious lane departure", and "vehicle changing lanes in blind spot") in the main core to identify whether the current situation is in a potential dangerous mode (such as following too closely, lingering in the lane, and driver distraction).

[0071] (4) Driver Intent Prediction: Based on the correlation between steering wheel angle, turn signal, driver's line of sight trajectory and road curvature, a classification algorithm is used to determine whether the driver's intent is "active lane change" or "unintentional deviation". This judgment result is the key to achieving intelligent prediction and false alarm filtering.

[0072] (5) Emergency Coefficient Calculation and Hierarchical Decision-Making: This invention transforms passive alarm into proactive prediction. The system inputs feature values ​​representing risk, driver status, vehicle dynamics, and environment into a comprehensive evaluation model. A specific embodiment of this model uses the following weighted calculation formula to quantify the emergency coefficient K:

[0073] K=0.4V risk +0.3D driver +0.2S car +0.1E env

[0074] Among them, V risk D represents environmental risk values ​​(such as the inverse of vehicle distance, lane distance). driver S represents the driver's state risk value (such as time out of sight, fatigue index). car E represents the vehicle's dynamic risk value (such as lateral acceleration). env This represents environmental disturbance factors (such as severe weather coefficient). The weights (0.4, 0.3, 0.2, 0.1) reflect the contribution of different factors to the overall risk.

[0075] Threshold Judgment and Decision-Making: The system compares the calculated real-time K value with a preset threshold, uses dual thresholds to achieve graded response and false alarm filtering, and makes graded decisions based on the results.

[0076] K < 40: The system is deemed to be risk-free and will continue monitoring without any warning preparations.

[0077] 40 ≤ K < 70: The system is determined to enter pre-trigger mode. The main core will load the corresponding emergency warning icon into SRAM in advance to preempt the warning time window, but will not initiate display or interfere with the normal operation of the auxiliary core. If the K value drops during this period, the preparation will be silently canceled, effectively avoiding false alarms.

[0078] K ≥ 70: An emergency event has been officially triggered. The main core will immediately execute step 3 (emergency decision-making and resource preemption) of the process.

[0079] The model weights and thresholds can be calibrated and optimized based on vehicle type, user preferences, or through machine learning.

[0080] Step 3: Resource Coordination and Release

[0081] Once an event is determined to be an emergency (K ≥ 70), the system immediately initiates a deterministic resource coordination and release mechanism, forcibly releasing resources occupied by low-priority tasks and allocating them preferentially to emergency tasks. The process is as follows:

[0082] (1) Resource status scan: The main core uses the system resource monitoring module to detect the current usage of core resources such as CPU, DMA channel, SRAM, LCD-TFT display interface in real time, and to determine which resources are occupied by the auxiliary core's regular tasks.

[0083] (2) Sending release command: The main core sends an emergency resource release command to the auxiliary core through the IPC (inter-core communication of the processor) module. The command specifies the type of resource to be released (such as DMA2 channel, display interface, SRAM partition).

[0084] (3) Auxiliary core fast response and context saving: The auxiliary core's IPC interrupt service routine captures the instruction in real time and immediately performs the following operations:

[0085] Pause all current routine tasks.

[0086] Save the current task's execution context (such as register context, display controller configuration, DMA transfer status) to a pre-allocated spare SRAM.

[0087] Release control of all the aforementioned hardware resources (DMA, display interface, etc.) that are currently in use.

[0088] Send a "resource release complete" confirmation signal back to the main core.

[0089] (4) Timing constraints: The time taken for the entire resource coordination and release process, from the main core sending the instruction to receiving the auxiliary core's confirmation, is designed to be ≤ 0.5μs.

[0090] Step 4: Rapid Display and Dynamic Visual Enhancement of Emergency Events

[0091] After gaining exclusive control of the resources, the main core immediately drives the rapid generation and enhanced display of emergency alerts:

[0092] (1) Resource allocation and data transmission: The main core allocates all the released resources to the emergency display task. Then, it starts the designated DMA channel to directly transfer the emergency prompt icon data preloaded in SRAM in step 2 to the LCD / TFT display interface.

[0093] (2) Deterministic low-latency display: Through this hardware acceleration path, the emergency icon can be overlaid on the top layer of the HUD screen within a very short latency (≤ 2μs).

[0094] (3) Parallel execution of dynamic visual enhancement: While the icon is displayed, the system calls the dynamic visual enhancement module based on the risk assessment results to implement enhanced display through multi-strategy fusion:

[0095] Dynamic position guidance: If the danger comes from the left side of the vehicle, the icon moves smoothly to the left on the screen to guide the driver's line of sight towards the source of the danger.

[0096] Enhanced Appearance and Warnings: In response to collision risks, the icon will enlarge, turn red and highlight, and flash with high-frequency pulses to create a sense of urgency and stimulate the instinct to avoid danger.

[0097] Forced Attention Attraction: If the system determines that the driver is distracted or fatigued, the overall brightness of the icon area will instantly increase by 150%-200%, accompanied by high-frequency flashing, to forcibly attract their attention.

[0098] Step 5: Danger Clearance and Mission Resumption

[0099] (1) The system determines that the danger has been eliminated when any of the following conditions are met:

[0100] The urgency coefficient K has fallen below 40;

[0101] The vehicle's CAN bus sends a clear danger clearance signal;

[0102] Based on sensor information, it is confirmed that the driver has completed the evasive maneuver (such as significantly correcting the direction or effectively braking).

[0103] (2) The recovery process after the danger has passed is as follows:

[0104] Send recovery command: The main core sends a "task recovery" command to the secondary core via IPC.

[0105] Secondary core context recovery: The secondary core reads the previously saved runtime context from the spare SRAM and reconfigures hardware resources such as the display controller and DMA accordingly.

[0106] Take over routine tasks: The auxiliary core resumes control and execution of routine display content rendering, sensor data acquisition, and other tasks.

[0107] System status return: The entire system switches back to the normal operating mode described in step 1, with the main core continuing to monitor in a loop and the auxiliary core responsible for routine display.

[0108] Step 6: Dual-core redundancy and fault protection

[0109] Throughout the system's operation, the dual-core mutual detection module continues to work to achieve functional safety redundancy.

[0110] Heartbeat mutual check mechanism: The main core and the auxiliary core maintain heartbeat communication with a period of 1ms. The main core sends a heartbeat packet to the auxiliary core every 1ms, and the auxiliary core replies with its own status every 1ms.

[0111] Main core failure handling: If the secondary core fails to receive three consecutive jumps from the main core, it is determined that the main core has failed. In this case, the secondary core will immediately activate its embedded simplified emergency identification logic and directly drive the HUD through the SPI interface to provide the minimum emergency alerts (such as collision warning and lane departure warning) to provide the most basic safety assurance.

[0112] Secondary core failure handling: If the primary core does not receive three consecutive calls from the secondary core, it is determined that the secondary core has failed. The primary core will suspend some non-core computing tasks and temporarily take over the simplified rendering of regular display content to ensure that basic driving information is not interrupted and driving safety is not affected.

[0113] Example 2

[0114] This embodiment provides a HUD emergency event display and processing system that implements the above-described method. The system is based on a specific automotive-grade microcontroller and features clearly defined hardware connections and software module divisions.

[0115] 1. Hardware system composition and connection relationships

[0116] This embodiment uses the Infineon Travelo II CYT3DL dual-core MCU as the control core of the entire HUD system. This MCU integrates the following key hardware resources:

[0117] (1) Processor core:

[0118] Cortex-M7 main processor: with a maximum operating frequency of 240MHz, it is specifically designed to perform high real-time and high-complexity computing tasks, such as data fusion, risk prediction, and resource scheduling.

[0119] Cortex-M0+ coprocessor: with a maximum operating frequency of 100MHz, used for handling low-priority, routine background tasks, such as routine interface rendering and sensor acquisition.

[0120] (2) Memory:

[0121] On-chip SRAM: Total 384KB, which is divided into three independent partitions according to function during software initialization: main core dedicated SRAM partition (used to run emergency task code and data), auxiliary core dedicated SRAM partition (used to run regular task code and data), and spare SRAM partition (used to save the auxiliary core's task context during resource preemption).

[0122] On-chip Flash: Includes 4160KB of Code Flash for storing program code and 128KB of Work Flash for storing system configuration and operation logs.

[0123] Direct Memory Access Controller: Integrates multiple independent DMA controllers (including P-DMA0, P-DMA1, M-DMA0), supports high-speed background data transfer, and does not consume CPU resources.

[0124] (3) The system's peripherals and interface connections are as follows:

[0125] (31) CAN communication interface: The two CAN FD controllers built into the MCU (a total of 4 channels) are connected to the vehicle CAN bus through the CAN transceiver to receive in real time: vehicle driving status data (such as vehicle speed, steering wheel angle, braking signal, gear position), ADAS perception data (such as distance to the vehicle in front, lane line information, obstacle position, collision risk level), and driver status data sent by the DMS controller (such as gaze direction, eyelid status, fatigue and distraction index).

[0126] (32) Display output interface: The HUD projection screen is directly driven through the LCD-TFT display controller. The display resolution is 800×480 and the refresh rate is 60fps.

[0127] (33) Conventional sensor interface: Connect ambient light sensor, temperature sensor, etc. via I2C or ADC interface to realize adaptive adjustment of HUD display brightness.

[0128] (34) Inter-core communication mechanism: The main core (Cortex-M7) and the auxiliary core (Cortex-M0+) complete inter-core synchronization, instruction issuance and status feedback through the chip's internal mechanism. This mechanism ensures that the inter-core communication delay does not exceed 0.1μs.

[0129] (35) Power supply and reliability design: The vehicle-mounted 12V to 5V and then to 3.3V power supply architecture is adopted, which supports abnormal power failure protection and watchdog reset.

[0130] 2. Software Architecture and Module Configuration

[0131] The software of this system is developed in C language and built on the FreeRTOS real-time operating system. Task scheduling strategies, interrupt priority management, resource locks, etc., are all strictly configured in accordance with vehicle functional safety requirements.

[0132] The software system is divided into the following six core functional modules on the dual-core processor:

[0133] (1) Dual-core task partitioning module

[0134] The dual-core role binding is completed upon system startup: the primary core is responsible for high-risk calculation and decision-making tasks (such as multi-source data fusion, urgency calculation, danger prediction, resource scheduling, and dynamic visual enhancement); the secondary core is responsible for routine input, output, and display tasks (such as routine display refresh, sensor acquisition, user key presses, and log recording).

[0135] All tasks within the system are divided into three priority levels: urgent (e.g., resource preemption, dynamic enhancement display), core (e.g., data fusion computation), and normal (e.g., log recording), and are strictly scheduled according to the strategy of urgent > core > normal.

[0136] (2) Multi-source data fusion and urgency calculation module

[0137] Running on the main core, this module collects and integrates vehicle dynamics data, ADAS environmental perception data, and DMS driver status data from the CAN bus in real time.

[0138] The module integrates a pre-set library of hazardous scenario models (such as rear-end collisions, lane departures, blind spot lane changes, and obstacle intrusions). By matching the fused feature data with the scenario models and running a weighted calculation formula, the urgency coefficient K is calculated and used as the basis for system decision-making.

[0139] (3) Resource Coordination and Forced Release Module

[0140] It runs in a collaborative manner between the main core and the secondary core. When an emergency task is triggered:

[0141] The main core's resource monitoring unit first detects the usage of critical resources such as CPU, DMA, SRAM, and display interface.

[0142] The primary core then sends a forced resource release command to the secondary core via the IPC channel.

[0143] The auxiliary core responds immediately, performing state saving, task pause, and resource release operations. The design of this module ensures that the entire process from command issuance to resource release completion takes ≤0.5μs.

[0144] (4) DMA high-speed display and transmission module

[0145] During the emergency display phase, this module is configured to transfer the emergency alert icon data stored in SRAM directly from SRAM to the LCD controller via DMA. This process bypasses the CPU, ensuring a display latency of ≤ 2μs.

[0146] (5) Dynamic visual enhancement module

[0147] Running on the main kernel. This module dynamically adjusts the presentation of warning content based on the direction of danger, the level of danger, and the driver's status, including:

[0148] The icon position is moved to guide the viewer in the direction of danger.

[0149] The flickering frequency and pulsation amplitude are used to characterize the urgency of the risk.

[0150] Brightness and saturation are automatically increased when the driver is distracted.

[0151] (6) Dual-core redundancy and mutual detection module:

[0152] The primary and secondary cores send heartbeat packets to each other. When either core detects a heartbeat failure in the other, it will immediately trigger the following operating mode to ensure that emergency alerts are not lost or delayed under any circumstances:

[0153] Primary core failure: The secondary core will take over control, activate its embedded simplified emergency identification logic, and maintain a minimum level of safety alert output.

[0154] Secondary core failure: The primary core will suspend some non-core computing tasks and take over routine tasks to ensure that basic vehicle information is not interrupted and to ensure driving safety.

[0155] Verification Example

[0156] To verify the effectiveness, real-time performance, and security of the above methods and systems, the following three specific quantitative scenarios will be used to illustrate these points.

[0157] Scenario 1: Unintentional Lane Departure Warning

[0158] Scenario Description: The vehicle is traveling straight on a highway at 80 km / h. The driver's gaze is diverted from the road ahead due to distraction, causing the vehicle to gradually move to the left towards the lane line, but not yet reaching the trigger threshold of a traditional lane departure warning system.

[0159] Step 2, Application and Decision-Making: The main core integrates real-time data: vehicle speed (80km / h), lane line lateral deviation (approaching the threshold), driver's line of sight (deviating from the road ahead), and turn signal status (not activated). The calculated urgency coefficient K=71.5, exceeding the trigger threshold (70). The system formally determines this as an emergency and initiates the warning process.

[0160] Steps 3 and 4 are executed as follows: The main core immediately initiates resource preemption, and the auxiliary core completes resource release and saves the current state within 0.42μs. Subsequently, the main core drives the emergency icon display, with a total latency of 1.8μs from the decision to the icon appearing on the HUD. At the same time, dynamic visual enhancement takes effect: the warning icon moves smoothly towards the center of the lane (right) to guide the driver's gaze, and automatically increases its brightness and flashes at a high frequency when the driver's gaze is detected to be deviating from the lane.

[0161] Results and Recovery: Attracted by the prominent, dynamic prompts, the driver promptly noticed the risk and corrected the steering wheel, returning the vehicle to the center of the lane, and the danger was averted. The system then executed step 5 of the recovery process, automatically switching back to the normal display interface.

[0162] In this verification example, compared with the traditional LDW system that relies on physical lane lines for triggering, the present invention can issue an effective warning about 0.6 to 1.2 seconds in advance through multi-source fusion prediction, which significantly increases the driver's reaction time and improves driving safety.

[0163] Scenario 2: Forward Collision Prediction and Warning

[0164] Scenario Description: The vehicle is traveling at 60 km / h in a city road, following another vehicle. The vehicle in front suddenly brakes, and the relative distance between the two vehicles decreases rapidly. The relative deceleration exceeds the safety threshold, but the activation conditions of the automatic emergency braking system have not yet been met.

[0165] Step 2 Application and Decision-Making: Core Fusion Data: Vehicle speed (60km / h), distance to the vehicle in front (rapidly decreasing), relative deceleration (above the safety threshold), driver's line of sight (not continuously looking ahead). The calculated urgency coefficient K=78.3, exceeding the trigger threshold (70), and the system immediately triggers a collision warning.

[0166] Steps 3 and 4 are executed: The resource preemption process is completed within 0.38μs. The collision warning icon appears in the center of the HUD visual center after 1.7μs. The dynamic visual enhancement module activates the highest level warning mode: the icon rapidly enlarges, turns red and pulses at a high frequency, and the brightness is adjusted to the brightest level to generate a strong visual impact and stimulate the driver to brake.

[0167] Results and Recovery: The driver was promptly alerted by the high-intensity warning and applied emergency braking, effectively preventing a rear-end collision. Once the distance to the other vehicle returned to a safe level, the system automatically deactivated the warning.

[0168] This verification example demonstrates that, through its predictive mechanism, the present invention can issue an effective warning 0.5 to 1.0 seconds earlier than traditional early warning systems, significantly reducing the probability of rear-end collisions.

[0169] Scenario 3: Integrated Early Warning Scenario for Driver Fatigue and Trajectory Deviation

[0170] Scenario Description: The vehicle is cruising at 90 km / h on the highway. The driver monitoring system detects that the driver is showing obvious signs of fatigue, such as excessive eye closure and head drooping. At the same time, the vehicle begins to unconsciously and slowly drift towards the right lane.

[0171] Step 2 Application and Decision-Making: Core data fusion: vehicle speed (90km / h), lane departure trend (continuously moving to the right), DMS status (driver's eye-closing time exceeds the limit, fatigue index is high), turn signal (not activated). The system determines this to be a high-risk complex scenario, with an emergency coefficient K=74.6, triggering a comprehensive emergency warning for fatigue and lane departure.

[0172] Steps 3 and 4 were executed: resource release took 0.45 μs, and icon display was delayed by 1.9 μs. A targeted dynamic visual enhancement strategy was activated: a warning icon appeared on the right to indicate the direction of deviation; simultaneously, to combat driver fatigue, the icon brightness was increased by 200% and high-frequency flashing was applied to forcibly awaken the driver's attention.

[0173] Results and Recovery: The bright, flashing warning successfully alerted the driver from fatigue and confusion. The driver then corrected the direction, bringing the vehicle back to the center of the lane and driving stably. The system returned to normal operation after the danger was over.

[0174] This verification example demonstrates that the present invention can provide effective intervention 1.0 to 1.5 seconds in advance when the driver is in an "unconscious" risk state, significantly improving active safety in the high-risk scenario of fatigued driving.

[0175] The three scenarios above fully demonstrate the entire process of the system, from risk prediction (step 2) to deterministic real-time response (step 3) to dynamic enhanced alerts (step 4) to smooth recovery (step 5). By introducing multi-source data fusion and prediction, the system significantly advances the timing of alerts; through a dual-core resource preemption mechanism, it ensures the immediacy and determinism of alerts; and through configurable dynamic visual enhancement strategies, it ensures high perceptibility of alert information and optimal human-computer interaction in different risk scenarios. The entire system, protected by a dual-core redundancy and fault protection (step 6) mechanism, constitutes a reliable, real-time, and intelligent HUD proactive safety solution.

Claims

1. A method for handling emergency events displayed on a HUD, characterized in that, The method is executed by a dual-core microprocessor including a main core and a secondary core, and includes the following steps: (1) Initialize the main core and the auxiliary core, configure the main core for security monitoring and decision-making, configure the auxiliary core for regular display rendering, and establish a communication and mutual inspection mechanism between the two cores; (2) The main core continuously fuses multi-source data of vehicle status, environmental perception and driver status, and calculates the urgency coefficient based on the fusion result to achieve predictive judgment of emergency events; (3) When it is determined that an emergency display needs to be triggered, the main core instructs the auxiliary core, and the auxiliary core releases the occupation of the display control hardware resources with a preset deterministic time consumption. Then the main core immediately takes over the resources to ensure the strong real-time performance of the emergency display. (4) The resources controlled by the main core are used for emergency display, and at least one visual attribute of the warning content is dynamically adjusted according to the risk assessment results of the emergency event in order to guide danger or enhance attention; (5) When the emergency is lifted, the main core instructs the auxiliary core to resume control of the display control hardware resources and routine display rendering tasks, and the system returns to continuous monitoring state.

2. The method according to claim 1, characterized in that, The mutual inspection mechanism mentioned in step (1) is a heartbeat mutual inspection mechanism.

3. The method according to claim 2, characterized in that, The method also includes redundant steps: When the auxiliary core determines that the main core is faulty through the heartbeat mutual check, the auxiliary core initiates a degradation process to output a basic safety prompt. When the main core determines that the auxiliary core is faulty through the heartbeat mutual check, the main core takes over the normal display rendering task.

4. The method according to claim 1, characterized in that, The urgency coefficient mentioned in step (2) is obtained by a weighted calculation formula, specifically: multiplying the multiple feature values ​​representing environmental risk, driver state risk, vehicle dynamic risk and environmental interference by the corresponding preset weight coefficients and then summing them to obtain the urgency coefficient.

5. The method according to claim 1, characterized in that, Step (2) involves calculating the urgency coefficient based on the fusion results and making predictive judgments, including: The calculated urgency coefficient is compared with a preset first threshold and a second threshold, wherein the first threshold is less than the second threshold; When the urgency coefficient is greater than or equal to the first threshold and less than the second threshold, it is determined to be a pre-trigger state, and the main core performs early warning resource preparation but does not trigger the display; When the urgency coefficient is greater than or equal to the second threshold, it is determined that an emergency display needs to be triggered immediately.

6. The method according to claim 5, characterized in that, In step (2), the predictive judgment includes: matching the extracted features with a built-in dangerous scene model library, which contains a variety of predefined dangerous scene models.

7. The method according to claim 1, characterized in that, The emergency display in step (4) includes: transmitting the pre-stored warning content data directly from the memory to the display controller for display via the direct memory access controller.

8. The method according to claim 1, characterized in that, The visual attributes mentioned in step (4) include: Based on the direction of the hazard source, control the movement of the warning content in the HUD display screen; Adjust the flashing frequency, color, or display size of the warning content according to the level of urgency; When it is determined that the driver's attention is distracted, the brightness or contrast of the warning content is increased.

9. A HUD emergency event display and processing system for implementing the method of any one of claims 1 to 8, characterized in that, include: A dual-core microprocessor, consisting of a main core and a secondary core; Display control hardware resources, including at least a display controller; The main core is configured to: perform multi-source data fusion and urgency coefficient calculation, make predictive judgments and decisions based on the calculation results, send instructions to the auxiliary core when it is determined that an emergency display needs to be triggered, and execute an emergency display that integrates dynamic visual enhancement strategies after taking over the display control hardware resources; The auxiliary core is configured to perform regular display rendering tasks and, in response to instructions from the main core, release the occupation of the display control hardware resources with a preset deterministic timeout.

10. The system according to claim 9, characterized in that, The system also includes a shared memory, which is partitioned into: The main core dedicated area is used to store running programs and emergency warning data; A dedicated area for auxiliary cores, used for running routine tasks; The spare area is dedicated to preserving the mission context when the auxiliary core releases resources.

Images