An automatic driving takeover control method and device, and a vehicle

Abstract

The application relates to the technical field of automatic driving control, and discloses an automatic driving takeover control method and device and a vehicle, the method comprising the following steps: acquiring driver state information, vehicle surrounding environment information and takeover event information; according to the driver state information, the cognitive load margin of the driver is evaluated; according to the vehicle surrounding environment information and the takeover event information, the takeover remaining time is determined; according to the cognitive load margin, the scene risk value and the takeover remaining time, the optimal takeover time window is determined; the takeover prompt information is distributed to multiple time periods of the optimal takeover time window, and the takeover prompt information is output according to the time periods. The application can fully consider the cognitive state of the driver, and can avoid takeover failure.

Description

Technical Field

[0001] This application relates to the field of vehicle-mounted human-machine interaction technology, and in particular to an autonomous driving takeover control method, device and vehicle. Background Technology

[0002] With the rapid development of autonomous driving technology, the SAE J3016 standard classifies autonomous driving systems into six levels, from L0 to L5. Level 3 (Conditional Automated Driving) systems can perform all dynamic driving tasks within their Operational Design Domain (ODD), but when the system encounters situations exceeding its capabilities or is about to exit the ODD, it needs to request the driver to take over vehicle control. Level 4 (Highly Automated Driving) systems, while requiring no human intervention within the ODD, still need to transfer control to the driver or enter a Minimum Risk Condition (MRC) in transitional areas at ODD boundaries or during system malfunctions. Before transferring control, the system needs to alert the driver. However, existing technologies do not adequately consider the driver's actual cognitive state when determining the timing of these alerts. For drivers who are fatigued or inattentive, the lack of an effective transition during takeover leads to takeover failure. Summary of the Invention

[0003] This application provides an autonomous driving takeover control method, device, and vehicle to solve the problem of takeover failure caused by insufficient consideration of the driver's cognitive state in the prior art.

[0004] To achieve the above objectives, this application adopts the following technical solution: In a first aspect, embodiments of this application provide an autonomous driving takeover control method, comprising: acquiring driver status information, vehicle surrounding environment information, and takeover event information; assessing the driver's cognitive load margin based on the driver status information; determining the remaining takeover time based on the vehicle surrounding environment information and the takeover event information; determining an optimal takeover time window based on the cognitive load margin, scenario risk value, and the remaining takeover time; and distributing takeover prompt information to multiple time periods within the optimal takeover time window and outputting it according to the time periods.

[0005] In some embodiments, assessing the driver's cognitive load margin includes: calculating the cognitive load margin by weighting the driver's attention level, alertness, and the complexity of the current driving-irrelevant task, wherein the complexity of the driving-irrelevant task has the largest weight.

[0006] In some embodiments, determining the remaining takeover time includes: identifying the event type of the takeover event information, the event type including at least one of vehicle malfunction, autonomous driving system malfunction, and the vehicle about to exceed its designed operating domain; determining the corresponding takeover risk time based on the event type; and determining the remaining takeover time based on the takeover risk time and vehicle surrounding environment information.

[0007] In some embodiments, determining the optimal takeover time window includes: calculating the time required for cognitive recovery based on the cognitive load margin and the scenario risk value; and determining the larger of the remaining takeover time and the time required for cognitive recovery as the optimal takeover time window.

[0008] In some embodiments, the step of distributing the takeover prompt information to multiple time periods within the optimal takeover time window includes: determining the driver's currently acceptable information density based on the cognitive load margin; determining a preset element quantity threshold for multiple time periods based on the information density; and distributing the takeover prompt information to the multiple time periods, wherein the number of information elements in each time period does not exceed the preset element quantity threshold for the corresponding time period.

[0009] In some embodiments, when the optimal takeover time window is compressed due to the remaining takeover time, the number of information elements in the second time period is compressed first, while the number of information elements in the first and third time periods is retained.

[0010] In some embodiments, the step of distributing the takeover prompt information to multiple time periods for output further includes: distributing information elements of each time period to different modal channels for output, including distributing temporal information elements to the voice channel, spatial information elements to the visual channel, and warning information elements to the tactile channel.

[0011] In some embodiments, when the cognitive load margin is lower than a preset threshold, or when the optimal takeover time window reaches the system upper limit but still cannot meet the time required for cognitive recovery, a cognitive load reduction strategy is initiated, including: requesting the driver to terminate the current irrelevant task, compressing the total number of information elements to a preset minimum value, transferring visual information to the tactile channel output, or requesting an extension of the remaining takeover time.

[0012] In some embodiments, the method further includes: determining the driver's actual information processing rate based on the driver's actual response time, and optimizing the assessment parameters of cognitive load based on the deviation between the actual information processing rate and the expected information density.

[0013] Secondly, embodiments of this application provide an autonomous driving takeover control device, comprising: an acquisition module configured to acquire driver state information, vehicle surrounding environment information, and takeover event information; an evaluation module configured to evaluate the driver's cognitive load margin based on the driver state information; a determination module configured to determine the remaining takeover time based on the vehicle surrounding environment information and the takeover event information; an optimization module configured to determine an optimal takeover time window based on the cognitive load margin, scenario risk value, and the remaining takeover time; and an output module configured to distribute takeover prompt information to multiple time periods within the optimal takeover time window and output it by time period.

[0014] Thirdly, embodiments of this application provide a vehicle, including: a memory for storing a computer program; and a processor for executing the computer program to implement the autonomous driving takeover control method described in the first aspect.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the autonomous driving takeover control method described in the first aspect.

[0016] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements the autonomous driving takeover control method described in the first aspect.

[0017] One or more of the above technical solutions determine the remaining takeover time based on vehicle surrounding environment information and takeover event information, assess the driver's cognitive load margin based on the driver's state, and then comprehensively determine the takeover time window based on the current scenario risk. This ensures that the length of the takeover time window matches the current driver's state, allowing the driver to complete the takeover task within their cognitive processing capacity and reducing the takeover failure rate. Simultaneously, by optimizing the takeover time window, reminder information is allocated to avoid cognitive mismatch problems such as ample time but information overload or time pressure but insufficient information. Attached Figure Description

[0018] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0019] Figure 1 This is a schematic diagram of an example environment 100 in which various embodiments of this disclosure can be implemented; Figure 2 This is a schematic diagram of the process of the autonomous driving takeover control method 200 in several embodiments of this disclosure; Figure 3This is a schematic diagram illustrating the optimal takeover time window process in several embodiments of this disclosure; Figure 4 This is a schematic diagram illustrating the time-segmented information output process in several embodiments of this disclosure; Figure 5 This is a program module architecture diagram of the autonomous driving takeover control device 500 in several embodiments of this disclosure. Detailed Implementation

[0020] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0021] In the description of the embodiments of this application, unless otherwise stated, " / " means "or", for example, A / B can mean A or B; "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. In this embodiment, the terms "first", "second", and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first", "second", and "third" can explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "multiple" means two or more. The term "including" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an embodiment" or "the embodiment" should be understood as "at least one embodiment".

[0022] As described in the background section, when L3 / L4 level autonomous driving systems encounter situations exceeding their processing capacity or are about to exit the ODD (Operational Domain Controller), they issue a reminder to the driver via the onboard domain controller, requesting the driver to take over vehicle control. Existing takeover technologies do not consider the driver's cognitive state when calculating the takeover time, leading to cognitive mismatch problems such as ample time but information overload or time constraints but insufficient information, posing a risk of takeover failure. Based on this, this invention proposes an autonomous driving takeover control scheme that, based on cognitive load margin assessment, ensures that the determination and allocation of reminder timing and content can be adaptively adjusted according to the driver's current state.

[0023] Figure 1A schematic diagram of an example environment 100 in which various embodiments of the present disclosure can be implemented is shown. For example... Figure 1 As shown, the example environment 100 includes an autonomous vehicle 110, a driver monitoring system 120, an on-board domain controller 130, and an on-board actuator cluster 140.

[0024] The autonomous vehicle 110 is a Level 3 or Level 4 autonomous vehicle, equipped with sensors such as cameras, LiDAR, millimeter-wave radar, and GPS modules to collect information about the vehicle's surrounding environment and takeover events. Specifically, the cameras collect road curvature and lane markings, the LiDAR collects obstacle positions and distances, the millimeter-wave radar collects relative obstacle speeds, and the GPS module collects vehicle position and speed. The autonomous vehicle 110 can also be expanded into autonomous trucks, autonomous buses, autonomous robots, and other forms.

[0025] The Driver Monitoring System (DMS) 120 is installed in the autonomous vehicle 110 to collect driver status information in real time, including attention level, alertness, and complexity of the current driving-irrelevant task.

[0026] The vehicle domain controller 130 receives vehicle surrounding environment information and takeover event information collected by the autonomous vehicle 110 and driver status information collected by the driver monitoring system 120, executes the autonomous driving takeover control method of the present invention, generates takeover prompt information, and outputs it through the vehicle actuator cluster 140. The vehicle domain controller 130 can also be expanded into an edge computing node or a distributed computing cluster.

[0027] The vehicle-mounted actuator cluster 140 includes various interactive devices such as an AR-HUD (Augmented Reality Head-Up Display), a central control screen, a steering wheel vibration motor, a seat vibration motor, and speakers. It receives takeover prompts generated by the vehicle-mounted domain controller 130 and outputs them according to a multimodal channel allocation scheme. The AR-HUD and central control screen are used to present visual information, the speakers are used to play voice information, and the steering wheel vibration motor and seat vibration motor are used to output tactile information.

[0028] The driver monitoring system 120 communicates with the vehicle domain controller 130 via vehicle Ethernet, and both are mounted on the autonomous vehicle 110. The vehicle domain controller 130 communicates with the vehicle actuator cluster 140 via CAN bus or vehicle Ethernet. In this embodiment, data collection and processing strictly comply with relevant laws and regulations. The collection of data such as driver attention level, alertness, and task behavior requires authorization and is used only for takeover warnings, not for any other unauthorized purposes.

[0029] It should be understood that the example environment 100 is described for illustrative purposes only and does not imply any limitation on the scope of this disclosure. The present invention can also be applied to other scenarios such as intelligent transportation, remote driving, and driver training. The environment may also include components such as V2X communication modules and cloud data analysis platforms, which are not shown.

[0030] The autonomous driving takeover control method provided in this application will be described in detail below with reference to the accompanying drawings. The steps of this method are as follows: Figure 2 As shown, it includes the following steps: In box 210, driver status information, vehicle surrounding environment information, and takeover event information are acquired. Driver status information refers to the driver's current level of attention, alertness, and the type of driving-irrelevant task being performed. Vehicle surrounding environment information includes road curvature, obstacle location and density, vehicle speed, and distance from the ODD boundary. Takeover event information refers to the type of event that triggers a takeover request, including vehicle malfunction, autonomous driving system functional failure, and the vehicle about to exceed its designed operating domain.

[0031] Driver status information is obtained from the driver monitoring system 120, which collects data in real time via onboard cameras and infrared sensors. Specifically, attention level is acquired through eye-tracking technology, collecting the driver's gaze direction and duration; alertness is acquired through facial feature recognition, calculating PERCLOS (Percentage of Eyelid Closure); and the complexity of driving-irrelevant tasks is determined by identifying the driver's current behavior through onboard cameras and sensors, judging whether the driver is using a mobile phone, the in-vehicle entertainment system, or conversing with passengers. Information about the vehicle's surrounding environment comes from the sensor cluster mounted on the autonomous vehicle 110. Information on takeover events comes from the fault diagnosis module and ODD boundary monitoring module of the autonomous driving system.

[0032] The vehicle domain controller 130 receives the above three types of data via the vehicle Ethernet. In some embodiments, for driver status information, the system acquires eye-tracking data and facial images at a frequency of 10Hz, calculates attention scores and PERCLOS values ​​in real time, and identifies the driver's current behavior type. For vehicle surrounding environment information, the system fuses data from cameras, LiDAR, and millimeter-wave radar to generate a 360-degree environmental perception result around the vehicle, including road curvature κ (unit: m). -1 Number of obstacles Relative velocity of obstacles (Unit: m / s) Vehicle speed (Unit: m / s) Distance from ODD boundary (Unit: m), etc. For takeover event information, the system receives fault types reported by the fault diagnosis module, such as tire blowout, tire leak, sensing failure, planning failure, or boundary transition events reported by the ODD boundary monitoring module. All data is timestamped and aligned to ensure data time consistency.

[0033] The system outputs synchronized and aligned driver status information, vehicle surrounding environment information, and takeover event information, which are then transmitted to subsequent steps. It should be understood that the above data acquisition method is merely illustrative and should not impose limitations on data sources or acquisition frequency. Conversely, other types of sensors or higher acquisition frequencies can also be used to acquire data.

[0034] This enables the synchronous collection and alignment of multi-source data, providing a high-quality data foundation for subsequent cognitive load assessment and improving the accuracy of takeover warnings.

[0035] In box 220, the driver's cognitive load margin is assessed based on the driver's state information. Cognitive load margin This refers to the proportion of cognitive resources that the driver can currently use to handle takeover tasks, with a value ranging from [0, 1]. =1 indicates that cognitive resources are completely idle. =0 indicates that cognitive resources are exhausted. Cognitive load margin. The factors are: attention level A, alertness C, and complexity of the current driving-irrelevant task. The decision was made jointly, and the calculation formula is as follows:

[0036] in, , , The contribution coefficient to cognitive load satisfies ,and The specific values ​​were obtained by fitting the data from the actual vehicle experiments using a multi-factor analysis of variance. , , These values ​​indicate that the complexity of driving-irrelevant tasks has the greatest impact on cognitive load (50%), followed by distraction (30%), while alertness has a relatively smaller impact (20%). This allows for a multi-dimensional quantitative assessment of the driver's cognitive state.

[0037] Attention level Data is collected in real time through the driver monitoring system (120). Specifically, ,in Rate the perception of consciousness. The effective number of times a driver looks at the road ahead. Total number of monitoring sessions; The average fixation duration for effective fixation needs to be normalized to [0,1]. and For the weighting coefficients, satisfying In this embodiment, =0.6, =0.4. The value range of is [0, 1]. This indicates that attention is fully focused on the driving task. This indicates that attention is completely scattered. Therefore, by using multi-parameter fusion assessment, the accuracy of attention level assessment is improved.

[0038] Alertness It is obtained through driver facial feature recognition. Specifically, PERCLOS (Percentage of Eyelid Closure) represents the percentage of time the eyes are closed. The percentage of time spent with eyes closed is normalized, and 0.15 is the threshold for severe fatigue. The value range of is [0, 1]. Indicates full consciousness. This indicates severe fatigue. Therefore, based on international standards, an objective quantification of driver alertness has been achieved.

[0039] Driving-related task complexity The driver's current behavior is determined by in-vehicle cameras and sensors. Specific values ​​are as follows: using a mobile phone. Using in-vehicle entertainment system Talking to passengers No task . The value range is [0, 1], with a larger value indicating higher task complexity. This allows for a tiered assessment of the driver's cognitive workload.

[0040] For example, suppose the driver is using a mobile phone ( Slightly distracted () ), PERCLOS=0.10 ( If the cognitive load margin is only 37.7%, the system is under high load and needs to significantly reduce information density and extend the takeover time window. Thus, quantitative assessment enables the identification of the driver's cognitive state.

[0041] The system outputs the driver's cognitive load margin. This information is then transmitted to subsequent steps for calculating the optimal takeover time window and determining the upper limit of information density. It should be understood that the above cognitive load assessment method is merely illustrative and should not impose limitations on the assessment parameters and weighting coefficients. Conversely, the weighting coefficients can be adjusted based on individual differences among drivers or the characteristics of driving scenarios to achieve more accurate personalized assessments.

[0042] This allows for real-time quantification of the driver's cognitive load margin, providing a basis for decision-making regarding the dynamic matching of subsequent takeover time windows and information density with the driver's cognitive abilities, thereby reducing the risk of cognitive overload.

[0043] In box 230, the remaining takeover time is determined based on the vehicle's surrounding environment information and takeover event information. Remaining takeover time This refers to the time interval between the system issuing a takeover request and the driver being required to complete the takeover, determined by the type of takeover event.

[0044] Acquire information about the vehicle's surrounding environment and takeover events. The vehicle's surrounding environment information includes vehicle speed. Distance from ODD boundary .

[0045] The system first identifies the event type of the takeover event information. Event types may include at least one of the following: vehicle malfunction, autonomous driving system functional failure, and the vehicle about to exceed its designed operating domain. Secondly, it determines the corresponding basic takeover risk time based on the event type. Furthermore, based on information about the vehicle's surrounding environment, the initial takeover risk time is dynamically adjusted to obtain the remaining takeover time. .

[0046] Specifically, if the event type is vehicle malfunction, the basic takeover risk time is determined by looking up the table based on the vehicle malfunction type. For example, the basic takeover risk time for a tire blowout is 2 seconds, at which point immediate intervention is required to prevent loss of vehicle control; the basic takeover risk time for a tire leak is 5 seconds, allowing for some buffer time; and the basic takeover risk time for a braking system failure is 3 seconds. Based on these, the system adjusts its response according to the current vehicle speed. and road curvature right Make corrections: , in This is the normalized value for the speed limit ratio. This is the normalized value for road curvature.

[0047] For example, a vehicle experiences a tire leak ( The current speed is 120 km / h, and the road speed limit is 100 km / h. Curve curvature ( ),but Seconds. Thus, high speeds and steep road curvature shorten the remaining take-off time, reflecting the dynamic changes in actual driving risk.

[0048] If the event type is an autonomous driving system functional failure, the basic takeover risk time is determined according to the autonomous driving system functional failure type. For example, the basic takeover risk time for perception failures such as camera or radar malfunctions is 3 seconds; the basic takeover risk time for planning failures caused by path planning module malfunctions is 4 seconds; and the basic takeover risk time for control failures such as steering or braking actuator malfunctions is 2 seconds. Based on this, the system adjusts the takeover risk time according to obstacle density. and weather visibility right Make corrections: , in This is the normalized value of the obstacle density. The normalized value of visibility ( (Unit: meters)

[0049] For example, the sensing module fails ( The three vehicles ahead are within a 500m² area. Visibility in foggy weather: 200m ),but Seconds. Therefore, the complex traffic environment and low visibility extend the remaining takeover time, providing drivers with a greater margin for perception recovery.

[0050] If the event type is that the vehicle is about to exceed the designed operating range, the takeover risk time is determined directly based on the vehicle's current speed and its distance from the boundary of the designed operating range. The calculation formula is: ,in The distance between the vehicle and the ODD boundary (unit: m). This represents the vehicle's current speed (in m / s). For example, if the vehicle is 5000 meters from the ODD boundary and its speed is 100 km / h (approximately 27.78 m / s), then... Seconds. Thus, dynamic calculation of takeover time was achieved based on physical constraints.

[0051] In some embodiments, when multiple takeover events occur concurrently, such as simultaneous vehicle malfunctions that are about to exceed the ODD (Operational Time Limit), the system takes the minimum takeover risk time corresponding to all events as the remaining takeover time to ensure a safety margin. For example, if the vehicle simultaneously experiences a tire leak (after correction)... ) and soon beyond ODD ( Then the system takes Seconds. Therefore, the constraint of the most urgent event is used as the bottom line for system security.

[0052] The system outputs the remaining time for takeover. This data is then transmitted to subsequent steps for calculating the optimal takeover time window. It should be understood that the above method for determining the remaining takeover time is merely illustrative and should not impose limitations on event types, time thresholds, or correction coefficients. Conversely, the basic takeover risk time and environmental correction coefficients can be adjusted according to different vehicle types, road conditions, or driver experience levels to adapt to a wider range of application scenarios.

[0053] In box 240, the optimal takeover time window is determined based on cognitive load margin, scenario risk value, and remaining takeover time. This refers to the takeover preparation time allocated by the system to the driver, determined by the time required for cognitive recovery and the remaining takeover time. Scenario Risk Value This refers to the overall risk level of the current driving scenario, with a value ranging from [0, 1]. For example, such as... Figure 3 As shown, this step further includes: Box 2401 determines the driver's current acceptable information density based on the driver's cognitive load margin. Information density is the number of information elements the driver can receive per unit of time. Considering the dynamics and stress of the driving scenario, the upper limit of information density is the cognitive load margin. The number of information elements that a driver can receive per unit of time is denoted as . For example, it is set to 5 elements / s. Based on the driver's cognitive load margin, the currently acceptable information density for the driver can be determined. : .

[0054] Box 2402 estimates the scenario risk value based on road curvature, vehicle speed, obstacle density, obstacle approach speed, and system health. Scenario Risk Value The calculation, using a cascading exponential risk model, demonstrates that a deterioration in any risk term will lead to an exponential amplification of the overall risk.

[0055] in: This is the normalized value for road curvature. Actual road curvature (unit: m) -1 ), 0.1 is the high curvature threshold; This is the normalized value for the speed limit ratio. This is the actual vehicle speed. Speed ​​limits on roads; This is the normalized value of the obstacle density. To detect the number of obstacles in the area, The area to be detected (unit: m) 2 ), 0.01 is the high-density threshold; This is the normalized value of the obstacle approach speed. This represents relative speed; negative values ​​indicate proximity, with 50 being the high-speed proximity threshold (unit: m / s). For system health, This represents the number of sensors that are functioning normally. This represents the total number of sensors; , , The risk sensitivity coefficient is dynamically determined by the sensor confidence level. , , ,in For camera confidence level, Let ε represent the radar confidence level, and ε be a small positive number to prevent division by zero. When the camera confidence level decreases (e.g., in strong light or backlight), the road curvature risk weight automatically increases; when the radar confidence level increases (e.g., in rainy or foggy weather), the obstacle risk weight automatically increases. The system health factor is introduced in a power-law form. When the health level decreases, it amplifies the risk, thereby achieving a multi-dimensional comprehensive assessment of scene risks and adaptive weight adjustment.

[0056] For example, consider a highway curve scenario: , , There are 3 cars ahead at 500m. 2 Inside, Of the 6 sensors, 5 are functioning normally. , The scenario risk value is calculated as follows: , , , , , , , .

[0057] Box 2403 determines the optimal takeover time window based on the time required for cognitive recovery and the remaining takeover time.

[0058]

[0059] in, The time required for cognitive recovery, by and Joint decision:

[0060] in, The set basic cognitive recovery time, This is the load sensitivity coefficient, used to reflect the negative correlation between cognitive load margin and recovery time. This is the risk sensitivity coefficient, used to reflect the positive correlation between scenario risk value and recovery time. The above formula reflects that a high cognitive load requires more recovery time, and a high risk forces an increase in information density, thus requiring more digestion time.

[0061] The system outputs the optimal takeover time window. and information density limit This information is transmitted to subsequent steps for time-segmented allocation and multimodal output of takeover prompts. It should be understood that the above method for determining the optimal takeover time window is merely illustrative and should not impose limitations on the calculation formulas and parameter values. Conversely, the base recovery time, load sensitivity coefficient, and risk sensitivity coefficient can be adjusted according to the characteristics of different driving scenarios or individual differences among drivers to achieve more precise time window allocation.

[0062] Therefore, by establishing a coupling relationship between cognitive load margin, takeover time window, and information density, dynamic matching of time assessment and information presentation can be achieved, ensuring that the driver completes the takeover task within the scope of cognitive processing ability and reducing the takeover failure rate.

[0063] In box 250, the takeover notification information is distributed to multiple time periods within the optimal takeover time window and output according to these time periods. In some embodiments, such as... Figure 4 As shown, this step further includes: Box 2501 acquires information about the vehicle's surrounding environment, takeover event information, cognitive load margin, and scenario risk value to determine a set of takeover prompt information. The set of takeover prompt information includes takeover reason information, environmental risk description information, operation suggestion information, and action guidance information.

[0064] First, the system determines the takeover reason information based on the takeover event information. Specifically, if the event type is vehicle malfunction, the takeover reason information is a description of the malfunction type, such as "Tire leak detected, autonomous driving is about to disengage"; if the event type is autonomous driving system functional malfunction, the takeover reason information is a description of the malfunctioning module, such as "Perception module failure, unable to recognize the road ahead"; if the event type is the vehicle about to exceed its designed operating range, the takeover reason information is a boundary type description, such as "The road ahead is outside the autonomous driving range", so that the driver is clearly aware of the triggering source of the takeover request.

[0065] Then, the system determines environmental risk description information based on the vehicle's surrounding environment. Specifically, the environmental risk description information includes: the type and distance of obstacles ahead (e.g., "Construction area 200 meters ahead"), road geometry features (e.g., "Continuous curves ahead, curvature 0.08"), traffic participant dynamics (e.g., "Vehicle merging from the left lane"), and the impact of weather and road conditions (e.g., "Visibility 150 meters in foggy weather, please be careful"). The system then determines the environmental risk description information based on the scenario risk value. Prioritize filtering environmental risk description information and retain only The top two risk descriptions with the highest contribution are presented first, highlighting the most critical environmental threats.

[0066] Furthermore, the system determines the risk value based on the scenario. and cognitive load margin Determine the operational recommendations. These recommendations include longitudinal control suggestions (e.g., "Recommend reducing speed to 60 km / h") and lateral control suggestions (e.g., "Please maintain your current lane"). When >0.5 and When <0.5, the operational advice is simplified to a single emergency command (e.g., "Please brake immediately"); when <0.3 and When the value is >0.7, the operation suggestion information is expanded into a detailed operation sequence (such as "Please lightly apply the brake to reduce the speed to 60km / h, and at the same time, slightly adjust the steering wheel to keep it centered"), so as to realize the differentiated generation of operation suggestions and match different risk-load scenarios.

[0067] Finally, the system determines the action guidance information based on the type of takeover event. The action guidance information includes step-by-step action instructions, such as "Step 1: Grip the steering wheel firmly with both hands," "Step 2: Move your right foot to the brake pedal," and "Step 3: Gently apply the brakes to reduce speed." The number of steps in the action guidance information is related to... Positive correlation Output a 3-step guide if the time is ≥ 10 seconds, and if it is ≤ 5 seconds. Output two-step guidance when the time is less than 10 seconds. Output a one-step guide when the time is less than 5 seconds. Thus, it provides progressive action breakdown when there is ample time, and focuses on a single key action when time is tight.

[0068] The aforementioned information on the reason for takeover, environmental risk description, operational suggestions, and action guidance collectively constitute the takeover warning information set. The system further breaks down this set of takeover warning information into discrete information elements. For example, "Tire leak detected, autonomous driving is about to disengage" is broken down into element A1, "Construction area 200 meters ahead" into element A2, "Recommended to reduce speed to 60 km / h" into element A3, "Step 1: Hold the steering wheel firmly with both hands" into element A4, and so on.

[0069] The system outputs a set of element-based takeover prompt messages, which are then transmitted to frame 2502 for multi-time period allocation. It should be understood that the above method for generating takeover prompt messages is merely illustrative and should not impose limitations on information categories, content descriptions, or element granularity. On the contrary, the information content and description can be adjusted according to different vehicle configurations, regional traffic regulations, or driver preferences to adapt to a wider range of application scenarios.

[0070] Box 2502 distributes the takeover notification information set across multiple time periods within the optimal takeover time window. A time period refers to the optimal takeover time window. The application will divide the time periods into sub-time periods. It is divided into three periods: the first period, the second period, and the third period, which correspond to the attention guidance stage, the driver's cognitive stage of the driving environment, and the driver's preparation stage for operation execution, respectively.

[0071] The system first determines preset thresholds for the number of elements over multiple time periods based on the driver's current acceptable information density. Specifically, it sets the optimal takeover time window. The time is divided into three periods, with time proportions of 20%, 50%, and 30% respectively. The number of information elements in each period does not exceed the first preset number, the second preset number, and the third preset number, respectively. The specific allocation is as follows: The first phase (20% of the total time): Outputs no more than a pre-set number of information elements for attention guidance. Typical information content is a brief description of the reason for takeover, for example, "Construction ahead, please take over" or "System malfunction, please take over." The main function of this phase is to quickly and unambiguously activate the driver's directional reflexes, making them aware of the takeover task, avoiding information overload in the initial stage. Thus, rapid driver attention is awakened with minimal information.

[0072] The second time slot (50% of total time): Outputs no more than the second preset number of information elements for driving environment cognition. Typical information includes: ① current vehicle trajectory (e.g., "The vehicle is traveling in the left lane"), ② risk direction (e.g., "There is a slow-moving vehicle 50 meters to the right"), ③ operational suggestions (e.g., "It is recommended to slow down and stay in the lane"). This time slot is allocated the longest processing time and the largest information capacity, helping the driver switch from a "passenger" mindset back to a "driver" identity and rebuild "situational awareness" of the vehicle's surrounding environment and future trajectory. These three information elements can be presented in parallel to convey the richest situational information within a limited time. Thus, the rapid reconstruction of the driver's situational awareness is achieved through the parallel output of multiple elements.

[0073] The third time segment (30% of the total time): Outputs no more than the third preset number of information elements for operational preparation. Typical information includes: ① steering wheel angle (e.g., "turn the steering wheel 15 degrees to the left"), ② braking depth (e.g., "lightly apply the brakes to a speed of 60 km / h"). The information in this segment focuses on guiding specific physical operations, helping the driver initiate and execute the correct "motion procedure." These two information elements are presented sequentially according to the logical order of the operation, conforming to the human cognitive habit of performing continuous actions. Thus, precise execution of driver takeover actions is achieved through operational guidance.

[0074] In some embodiments, when the optimal takeover time window is compressed by the remaining takeover time limit, the system recalculates the total number of information elements that can be carried according to the upper limit of information density, and prioritizes reducing the number of information elements in the second time period, for example, from 3 to 2, while retaining the number of elements in the first and third time periods, to ensure that the driver knows that takeover is to be carried out and knows how to operate.

[0075] The system outputs takeover prompts in time slots, with the number of information elements in each time slot not exceeding a preset threshold. These prompts are then transmitted to subsequent steps for multimodal channel allocation and output. It should be understood that the above-described time-slot information allocation method is merely an illustrative example and should not impose restrictions on the number of time slots, time percentages, or element quantity thresholds. On the contrary, the time slot division and element quantity allocation can be adjusted according to the complexity of different takeover scenarios or the driver's cognitive ability to achieve a more flexible information presentation strategy.

[0076] Therefore, by allocating information in different time periods, the information density of each time period is dynamically matched with the driver's cognitive ability, ensuring that the information density is always within the driver's cognitive processing capacity, and effectively preventing takeover errors caused by cognitive overload.

[0077] In some embodiments, when outputting by time period, it is also necessary to allocate information elements for each time period to the corresponding modal channel. Here, multimodal channels refer to different ways of presenting information, including voice channels, visual channels, and tactile channels. Appropriate allocation of different modalities can prevent the driver from experiencing information overload from a single modality.

[0078] Specifically, the voice channel is suitable for conveying instructional and temporal information. For example, temporal information elements (such as "Please hold the steering wheel firmly" or "Prepare to brake") are assigned to the voice channel and output through a speaker. The visual channel is suitable for conveying spatial and topological information. For example, spatial information elements (such as vehicle trajectory projection, right-front slow vehicle position markings, suggested lane highlighting, and steering wheel angle markings) are assigned to the visual channel and presented through an AR-HUD or central control screen. The tactile channel is suitable for conveying warning and directional information. For example, warning information elements are assigned to the tactile channel; for instance, vibration on the left side of the seat to indicate oncoming traffic or vibration of the steering wheel to indicate the need for immediate intervention, output through a seat vibration motor or steering wheel vibration motor, enabling forced awakening of attention.

[0079] Each modal channel has an independent capacity limit. The number of information elements in each channel within a single time period does not exceed its capacity limit. For example, voice ≤ 2, vision ≤ 3, and touch ≤ 1. The total number of information elements in each time period does not exceed the preset threshold for that time period.

[0080] In some embodiments, when the number of information elements exceeds the total capacity, the system performs information fusion and reduction according to a priority order: tactile channel first, visual channel second, and voice channel third. Information fusion is preferred over simple deletion as the reduction method. For example, the visual channel's "vehicle speed ahead 30km / h" (first element) and "distance 50m" (second element) are fused into "slow vehicle ahead, distance 50m" (one fused element), thereby freeing up the capacity of one element. Thus, information integrity protection under capacity constraints is achieved through information fusion.

[0081] For example, suppose the second time period requires presenting 5 information elements (exceeding the capacity limit), including: ① vehicle trajectory (visual), ② position of the slow vehicle to the right (visual), ③ slow vehicle speed 30km / h (visual), ④ distance 50m (visual), ⑤ suggestion to slow down (voice). After the system performs fusion reduction, ②③④ are merged into "slow vehicle 50m to the right" (1 fused element), ultimately presenting 3 elements: ① vehicle trajectory (visual), ② slow vehicle 50m to the right (visual), ⑤ suggestion to slow down (voice). The total number of elements = 3 ≤ 6, satisfying the capacity constraint. Thus, capacity optimization is achieved while maintaining the integrity of key information.

[0082] It should be understood that the above multimodal channel allocation method is only an example and should not impose restrictions on channel type, capacity limit and allocation principle. On the contrary, the channel allocation strategy can be adjusted according to the type of interactive device configured in the vehicle or the driver's perception preference to achieve a more personalized information presentation.

[0083] Based on one or more of the above embodiments, the method may further include block 260, which involves back-calculating the actual cognitive load and correcting the cognitive load assessment parameters based on the driver's actual response time.

[0084] In some embodiments, the driver operation behavior acquisition unit monitors the signals from the steering wheel torque sensor, brake pedal position sensor, and steering wheel capacitance sensor in real time. When it is detected that the driver has both hands on the steering wheel and the applied steering torque continuously exceeds a set force or the brake pedal travel exceeds a set travel for a continuous period of time, it is determined that the driver has completed takeover, and this moment is recorded as the takeover completion timestamp. The time interval from the issuance of the takeover request to this timestamp is determined as the driver's actual response time. .

[0085] First, based on the actual response time and the number of information elements actually presented Calculate the actual information processing rate. This refers to the actual rate at which the driver processes information elements, measured in elements per second.

[0086] Secondly, the actual information processing speed Information density as expected Compare and determine the direction of cognitive load assessment bias. If This indicates that the actual processing speed is higher than expected. Undervalued, will be improved in the next evaluation. Estimated value; if ,show Overrated, Underrated Estimated value.

[0087] Finally, adjust the cognitive load margin according to the direction of the deviation. The cognitive load contribution coefficient in the equation. For example, if... ,show If overestimated, the system prioritizes increasing the complexity weight γ of driving-irrelevant tasks by a set step size, while compressing α and β proportionally to ensure α + β + γ = 1; conversely, if... If the error is not detected, the adjustment is reversed. Thus, continuous optimization of evaluation accuracy is achieved through cumulative learning.

[0088] It should be understood that the above closed-loop optimization method is only an illustrative example and should not impose limitations on the correction algorithm and learning rate. On the contrary, other machine learning algorithms (such as Kalman filtering, Bayesian update) or adaptive learning rate strategies can also be used to achieve more efficient parameter correction.

[0089] In some embodiments, if the cognitive load margin is lower than a preset threshold or the optimal takeover time window reaches the system's upper limit and still cannot meet the time required for cognitive recovery, the system is triggered to activate a cognitive load reduction strategy. That is, when the driver's cognitive load is too high or time is extremely tight, the system ensures takeover safety by rapidly reducing the driver's cognitive load or extending the takeover time.

[0090] For example, when cognitive load margin or Still unable to satisfy When this happens, the system activates the cognitive load reduction strategy, switching from normal mode to simplified mode. The cognitive load reduction strategy can include the following four sub-strategies: (1) Enabling the driver to focus on the task at hand by reminding them to interrupt the current task. For example, the system requires the driver to immediately terminate the current unrelated task via voice command. For example, when the system detects that the driver is using a mobile phone, it outputs a mandatory command, "Please put down your phone and take over immediately." This strategy aims to quickly free up the driver's cognitive resources occupied by unrelated tasks, enabling them to focus on the task at hand.

[0091] (2) Reduce cognitive load by compressing the number of information elements. For example, the system retains only one element in the first time period (reason for takeover) and one element in the third time period (single action instruction), compressing the total number of elements to 2. For example, the first time period outputs "System malfunction, please take over" and the third time period outputs "Please hold the steering wheel firmly," omitting all contextual information in the second time period. This strategy is suitable for scenarios with extremely high cognitive load and extremely tight time constraints, ensuring that the driver can at least complete the most basic takeover action.

[0092] (3) Reduce cognitive load by redistributing the modalities of information elements. For example, the system transfers visual information to the tactile channel, freeing up visual resources. For example, the "turn left" information originally presented through AR-HUD is replaced by vibration encoding on the left side of the steering wheel (3 short vibrations indicate a left turn), so that the driver can receive the steering command without distracting his visual attention.

[0093] (4) Initiate a time window extension request to extend the takeover time. For example, the system requests an extension of the takeover time from the autonomous driving control unit to strive for... Incremental adjustments. Specific measures may include: ① reducing speed (e.g., from 120 km / h to 80 km / h), ② changing lanes to the emergency lane or slow lane, and ③ issuing warning signals to vehicles behind. This strategy aims to give drivers more time to recover their senses by adjusting the vehicle's driving status.

[0094] Cognitive load reduction strategies can be used to rapidly reduce driver cognitive load or extend takeover time in extreme scenarios, ensuring safe takeover and reducing the risk of traffic accidents. It should be understood that the above cognitive load reduction strategies are merely illustrative and should not limit the type of strategy or triggering conditions. Conversely, other reduction strategies can be designed based on the control capabilities of different vehicle platforms or the constraints of road traffic environments to adapt to a wider range of emergency scenarios.

[0095] In some embodiments, if the above strategies still cannot achieve the desired result... Once the speed reaches a safety threshold, the system will request the autonomous driving control unit to enter a minimum-risk state, executing an emergency pullover or decelerating to a safe speed to avoid traffic accidents caused by forced takeover. Thus, a multi-layered emergency mechanism ensures absolute safety during the takeover process.

[0096] Here's an example scenario: Suppose a vehicle is traveling on a highway, and the autonomous driving system detects road construction 5 kilometers ahead. The ODD (Optical Development Controller) is about to disengage, requiring driver intervention. At this time, the driver is using the in-vehicle entertainment system to watch a video (…). =0.5), moderately inattentive (A=0.6), PERCLOS=0.08 (C=1) 0.08 / 0.15=0.467).

[0097] t=0s: The vehicle domain controller 130 executes block 210 to acquire driver status information, vehicle surrounding environment information, and takeover event information. Among these, vehicle speed... =27.78m / s (100km / h), distance from ODD boundary =5000m, the two cars ahead are at 600m 2 Within the area, the road curvature κ = 0.02m -1 .

[0098] t=0.1s: Vehicle domain controller 130 executes block 220, calculating cognitive load margin: Lcog=1 [0.3×(1 0.6)+0.2×(1 [0.467) + 0.5 × 0.5] = 0.523 t=0.2s: The vehicle domain controller 130 executes boxes 230 and 240 to calculate the scenario risk value and the optimal takeover time window. Assume camera confidence level... =0.9, radar confidence level =0.85, all 6 sensors are functioning normally, then the scenario risk value is... =0.18. Remaining time for takeover. =5000 / 27.78=180s. Time required for cognitive recovery: =5×[1+2.0×(1 0.523)]×[1+1.5×0.18]=12.4s Optimal takeover time window: T_opt = min(180, 12.4) = 12.4 s. Upper limit of information density. ≤0.523×5=2.615 elements / s.

[0099] At t=0.3s: The vehicle domain controller 130 executes frame 250, planning information for three time periods: the first period (0~2.5s, 20%) outputs 1 information element; the second period (2.5s~8.7s, 50%) outputs 3 information elements; and the third period (8.7s~12.4s, 30%) outputs 2 information elements, for a total of 6 elements. The number of elements in each period does not exceed the corresponding modal channel capacity limit (voice ≤ 2, vision ≤ 3, haptic ≤ 1), so there is no need to trigger fusion reduction.

[0100] t=0s~2.5s (first period): The vehicle domain controller 130 outputs wake-up information through the tactile channel (seat vibrates 3 times) and the voice channel. The seat vibration activates the driver's directional reflex, and at the same time the speaker outputs "Construction ahead, please prepare to take over".

[0101] t=2.5s~8.7s (Second Time Period): The vehicle domain controller 130 outputs contextual information through visual and voice channels. AR-HUD displays: ① Projection of the vehicle's current trajectory (Element 1), ② Marking of a construction area 2km ahead (Element 2), ③ Highlighting of the suggested lane (right lane) (Element 3). Simultaneously, the voice channel outputs "Suggest switching to the right lane and reducing speed to 80km / h" (this voice element is fused with the visual information of Element 3 across modalities without consuming additional voice capacity). The driver reconstructs contextual awareness through multimodal information.

[0102] t=8.7s~12.4s (Third Time Period): The vehicle domain controller 130 outputs operation guidance through visual and tactile channels. The central control screen displays the suggested steering wheel angle (5 degrees to the right, element 1), and the right side of the steering wheel vibrates slightly to indicate the steering direction (element 2). The driver completes the steering and deceleration operations according to the guidance.

[0103] t=10.0s: The system determines that the takeover is complete and records this moment as the takeover completion timestamp.

[0104] After t=10.0s: Vehicle domain controller 130 executes block 260 to calculate the actual response time. =10.0s. Actual information processing rate: =6 / 10.0=0.6 elements / s because This indicates that the system overestimates the driver's cognitive load. Adjusting the complexity weight γ of driving-irrelevant tasks from 0.50 to 0.52, and proportionally normalizing the attention weight α and alertness weight β, will improve performance in the same scenario in subsequent tests. The estimate was reduced by about 4% to match the driver's actual cognitive processing ability.

[0105] Figure 5 A schematic block diagram of an autonomous driving takeover control device 500 according to some embodiments of the present invention is shown. The device 500 may be implemented as or included in... Figure 1 In the vehicle domain controller 130. Device 500 may include multiple modules for performing, for example... Figure 2 The corresponding actions in method 200 discussed herein. Device 500 includes: an acquisition module 510 configured to acquire driver status information, vehicle surrounding environment information, and takeover event information; an evaluation module 520 configured to evaluate the driver's cognitive load margin based on the driver status information; a determination module 530 configured to determine the remaining takeover time based on the vehicle surrounding environment information and the takeover event information; an optimization module 540 configured to determine the optimal takeover time window based on the cognitive load margin, scenario risk value, and the remaining takeover time; and an output module 550 configured to distribute takeover prompt information to multiple time periods within the optimal takeover time window and output it by time period.

[0106] In some embodiments, the evaluation module 520 evaluates the driver's cognitive load margin by: weighting the cognitive load margin based on the driver's attention level, alertness, and the complexity of the current driving-irrelevant task, wherein the complexity of the driving-irrelevant task has the largest weight.

[0107] In some embodiments, the determining module 530 determines the remaining takeover time by: identifying the event type of the takeover event information, the event type including at least one of vehicle malfunction, autonomous driving system functional malfunction, and the vehicle about to exceed its designed operating domain; determining the corresponding takeover risk time based on the event type; and determining the remaining takeover time based on the takeover risk time and vehicle surrounding environment information.

[0108] In some embodiments, the optimization module 540 determines the optimal takeover time window by: calculating the cognitive recovery time required based on the cognitive load margin and the scenario risk value; and determining the larger of the remaining takeover time and the cognitive recovery time required as the optimal takeover time window.

[0109] In some embodiments, the output module 550 distributes takeover warning information to multiple time periods within the optimal takeover time window for output, including: determining the driver's currently acceptable information density based on the cognitive load margin; determining preset element quantity thresholds for multiple time periods based on the information density; and distributing the takeover warning information to the multiple time periods, wherein the number of information elements in each time period does not exceed the preset element quantity threshold for the corresponding time period. Preferably, the information elements of each time period are distributed to different modal channels for output, including distributing temporal information elements to the voice channel, spatial information elements to the visual channel, and warning information elements to the tactile channel. Wherein, when the optimal takeover time window is compressed due to the remaining takeover time, the number of information elements in the second time period is compressed first, while the number of information elements in the first and third time periods is retained.

[0110] In some embodiments, when the cognitive load margin is lower than a preset threshold, or when the optimal takeover time window reaches the system upper limit but still cannot meet the time required for cognitive recovery, a cognitive load reduction strategy is initiated, including: requesting the driver to terminate the current irrelevant task, compressing the total number of information elements to a preset minimum value, transferring visual information to the tactile channel output, or requesting an extension of the remaining takeover time.

[0111] In some embodiments, the device 500 further includes a feedback module configured to determine the driver’s actual information processing rate based on the driver’s actual response time, and to optimize the assessment parameters of cognitive load based on the deviation between the actual information processing rate and the expected information density.

[0112] Some embodiments of the present invention also provide an electronic device including a computing unit that can perform various appropriate actions and processes according to computer program instructions stored in random access memory (RAM) and / or read-only memory (ROM) or computer program instructions loaded from a storage unit into RAM and / or ROM. Various programs and data required for device operation may also be stored in the RAM and / or ROM. The computing unit and the RAM and / or ROM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0113] Multiple components within the device are connected to I / O interfaces, including: input units such as a steering wheel angle sensor, pedal position sensor, and ECG acquisition module; output units such as a central control display, speaker, and hazard warning lights; storage units such as a solid-state drive and embedded memory; and communication units such as an in-vehicle Ethernet controller, Bluetooth module, and V2X communication module. The communication units allow the device to exchange information / data with other devices via computer networks such as the Internet and / or various telecommunications networks.

[0114] A computing unit can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of computing units include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit performs the various methods and processes described above, such as method 200. For example, in some embodiments, method 200 may be implemented as a computer software program tangibly contained in a machine-readable medium. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via RAM and / or ROM and / or a communication unit. When the computer program is loaded into RAM and / or ROM and executed by the computing unit, one or more steps of method 200 described above may be performed. Alternatively, in other embodiments, the computing unit may be configured to perform method 200 by any other suitable means (e.g., by means of firmware).

[0115] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a server or terminal, they generate, in whole or in part, the processes or functions described in the embodiments of this application. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic cable, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the server or terminal, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, and magnetic tape), an optical medium (e.g., digital video disk (DVD), etc.), or a semiconductor medium (e.g., solid-state drive).

[0116] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the invention. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0117] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. An automatic driving takeover control method, characterized in that, include: Acquire driver status information, vehicle surrounding environment information, and takeover event information; Based on the driver status information, assess the driver's cognitive load margin; Based on the vehicle's surrounding environment information and the takeover event information, determine the remaining takeover time; The optimal takeover time window is determined based on the cognitive load margin, the scenario risk value, and the remaining takeover time. The takeover notification information is distributed to multiple time periods within the optimal takeover time window and output according to the time period.

2. The automatic driving takeover control method as described in claim 1, characterized in that, The assessment of the driver's cognitive load margin includes: calculating the cognitive load margin by weighting the driver's attention level, alertness, and the complexity of the current driving-irrelevant task, with the complexity of the driving-irrelevant task having the largest weight.

3. The automatic driving takeover control method as described in claim 1, characterized in that, Determining the remaining takeover time includes: identifying the event type of the takeover event information, where the event type includes at least one of vehicle malfunction, autonomous driving system malfunction, and the vehicle about to exceed its designed operating domain; determining the corresponding takeover risk time based on the event type; and determining the remaining takeover time based on the takeover risk time and the vehicle's surrounding environment information.

4. The automatic driving takeover control method as described in claim 1, characterized in that, The process of determining the optimal takeover time window includes: calculating the time required for cognitive recovery based on the cognitive load margin and the scenario risk value; and determining the smaller value between the remaining takeover time and the time required for cognitive recovery as the optimal takeover time window.

5. The automatic driving takeover control method as described in claim 1, characterized in that, The step of distributing the takeover prompt information to multiple time periods within the optimal takeover time window includes: determining the driver's current acceptable information density based on the cognitive load margin; determining preset element quantity thresholds for multiple time periods based on the information density; and distributing the takeover prompt information to the multiple time periods, wherein the number of information elements in each time period does not exceed the preset element quantity threshold for the corresponding time period.

6. The automatic driving takeover control method as described in claim 5, characterized in that, The method of distributing takeover prompts to multiple time periods for output also includes: distributing information elements of each time period to different modal channels for output, including distributing temporal information elements to the voice channel, spatial information elements to the visual channel, and warning information elements to the tactile channel.

7. The automatic driving takeover control method as described in claim 5 or 6, characterized in that, When the cognitive load margin is lower than the preset threshold, or when the optimal takeover time window reaches the system limit and still cannot meet the time required for cognitive recovery, a cognitive load reduction strategy is activated, including: requesting the driver to terminate the current irrelevant task, compressing the total number of information elements to a preset minimum, transferring visual information to the tactile channel output, or requesting an extension of the remaining takeover time.

8. The automatic driving takeover control method as described in claim 5, characterized in that, The method further includes: determining the driver's actual information processing rate based on the driver's actual response time, and optimizing the assessment parameters of cognitive load based on the deviation between the actual information processing rate and the expected information density.

9. An automatic driving takeover control device, characterized in that, include: The acquisition module is configured to acquire driver status information, vehicle surrounding environment information, and takeover event information. The assessment module is configured to assess the driver's cognitive load margin based on the driver's state information; The determination module is configured to determine the remaining takeover time based on the vehicle's surrounding environment information and the takeover event information; The optimization module is configured to determine the optimal takeover time window based on the cognitive load margin, the scenario risk value, and the remaining takeover time. The output module is configured to distribute takeover notification information to multiple time periods within the optimal takeover time window and output it by time period.

10. A vehicle, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the autonomous driving takeover control method as described in any one of claims 1-8.

Images