Method, device and vehicle for manual takeover of a highly automated vehicle

Abstract

This invention provides a method, apparatus, and vehicle for manual takeover of a highly automated driving vehicle. The method is applied to a vehicle equipped with highly automated driving capabilities, the vehicle being fitted with control components for manual driving, which are locked when the highly automated driving function is activated. The method includes: when the highly automated driving function is activated, in response to a takeover request initiated by the driver, verifying the driver's takeover authority over the vehicle; after successful authority verification, unlocking the control components; triggering the vehicle to enter a takeover transition control phase when the driver is ready, and detecting the driver's vehicle control actions on the control components; and deactivating the highly automated driving function when the actions meet preset takeover success conditions. This method enables the vehicle to have strong anti-interference capabilities at Level 4 automated driving while allowing authorized drivers with manual driving skills to smoothly take over the vehicle.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving, and more particularly to a method, device, and vehicle for manual takeover of a highly automated driving vehicle. Background Technology

[0002] With the rapid development of intelligent driving technology, more and more vehicles support intelligent driving. For more advanced autonomous driving technologies, the industry typically classifies them into several levels of autonomous driving based on their degree of automation. Level 3 (or conditional autonomous driving) means that the vehicle can achieve safe autonomous driving within its operational design domain (ODD), but a human driver is required as a backup and ready to take over at any time. Level 4 (or highly automated driving) means that the vehicle can drive completely autonomously in a limited area / scenario (such as a park or the city center) without the need for human driver intervention.

[0003] In certain special circumstances (such as when the vehicle is damaged and needs repair, or when it enters the blind spot of the Level 4 autonomous driving function), the autonomous driving system of a vehicle may require human intervention to control the vehicle through manual driving. Therefore, such vehicles are usually equipped with control components for manual driving (such as steering wheel, accelerator pedal, brake pedal, etc.).

[0004] However, the occupants may not have received specialized driving training. Therefore, if the occupants touch the aforementioned controls when the Level 4 autonomous driving function is activated, it may interfere with the normal execution of DDT (Dynamic Driving Task) by the ADS (Automated Driving System), posing a significant safety hazard to the vehicle's operation and urgently requiring improvement. Summary of the Invention

[0005] In view of this, the present invention provides a method, apparatus and vehicle for manual takeover of a highly automated vehicle, in order to overcome the shortcomings of related technologies.

[0006] Specifically, the present invention is achieved through the following technical solution:

[0007] According to a first aspect of the present invention, a method for manual takeover of a highly automated driving vehicle is provided, applicable to a vehicle equipped with a highly automated driving function, the vehicle being fitted with a control mechanism for manual driving, the control mechanism being locked when the highly automated driving function is activated; the method includes:

[0008] After the authorization verification is successful, the lock on the control unit is released, and the current state of the driver is detected; and if the current state is a takeover ready state, the vehicle is triggered to enter the takeover transition control phase, and the driver's vehicle control operation behavior on the control unit is detected.

[0009] If the vehicle control operation meets the preset takeover success conditions, the highly automated driving function is deactivated, allowing the driver to manually drive the vehicle.

[0010] According to a second aspect of the present invention, a manual takeover device for a highly automated driving vehicle is provided, applicable to a vehicle equipped with a highly automated driving function, the vehicle being fitted with a control for manual driving, the control being locked when the highly automated driving function is activated, the device comprising:

[0011] The authorization verification unit is used to verify the driver's authorization to take over the vehicle in response to a takeover request initiated by the driver when the highly automated driving function is activated.

[0012] The takeover preparation unit is used to unlock the control unit after the authorization verification is passed and to detect the current state of the driver; and, if the current state is a takeover preparation ready state, to trigger the vehicle to enter the takeover transition control phase and to detect the driver's vehicle control operation behavior on the control unit.

[0013] The takeover success unit is used to deactivate the highly automated driving function when the vehicle control operation meets the preset takeover success conditions, so that the driver can manually drive the vehicle.

[0014] According to a third aspect of the invention, a vehicle is provided, the vehicle having a highly automated driving function and equipped with controls for manual driving, the vehicle being used to implement the method as described in the first aspect.

[0015] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having computer instructions stored thereon that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0016] According to a fifth aspect of the present invention, a computer program product is provided, comprising a computer program and / or instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0017] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0018] In this scheme, a vehicle equipped with highly automated driving capabilities (i.e., Level 4 autonomous driving) is fitted with a control mechanism for manual driving, which is locked when the highly automated driving capability is activated. Specifically, when the capability is activated, the vehicle responds to a takeover request from the driver, verifies the driver's takeover authority, unlocks the control mechanism after successful authorization, and detects the driver's current state. If the driver is in a takeover ready state, the vehicle enters a takeover transition control phase, and the driver's vehicle control actions via the control mechanism are detected. Finally, if the vehicle control actions meet preset takeover success conditions, the highly automated driving capability is deactivated, allowing the driver to manually drive the vehicle (i.e., enabling the driver to perform dynamic driving tasks via the control mechanism).

[0019] Understandably, because the controls are locked when the highly automated driving function is activated, occupants cannot interfere with its normal operation. Furthermore, after a driver requests takeover, the vehicle does not unconditionally allow control. Instead, it gradually assesses whether the driver has the authority to take over, is ready to take over, and whether the takeover is successful. Only after successful takeover is the highly automated driving function deactivated, allowing the driver to resume manual driving.

[0020] On the one hand, with Level 4 autonomous driving enabled, the system prevents occupants from effectively operating the controls, thus preventing them from interfering with the normal execution of DDT by the ADS (Autonomous Driving System). On the other hand, the Level 4 function is deactivated after the driver successfully takes over, allowing the driver to smoothly perform dynamic driving tasks and achieve manual driving through the controls. It is evident that this solution, through locking and releasing the controls, verifying driver permissions and status, and releasing the controls only after successful permission verification, entering the transition control phase only after the driver is ready, and deactivating the Level 4 function only after successful driver takeover, provides a progressive judgment and processing flow. This allows the vehicle to have strong anti-interference capabilities in Level 4 autonomous driving while allowing authorized drivers with genuine manual driving skills to smoothly take over the vehicle. This effectively solves the driving safety issues of Level 4 autonomous driving and meets the need for manual takeover in necessary situations, demonstrating significant improvement. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the present invention, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0022] Figure 1 This is a schematic diagram of the architecture of an autonomous driving system shown in an embodiment of the present invention;

[0023] Figure 2 This is a flowchart illustrating a method for manual takeover of a highly automated vehicle according to an embodiment of the present invention;

[0024] Figure 3 This is a flowchart illustrating another method for manual takeover of a highly automated vehicle, as shown in an embodiment of the present invention.

[0025] Figure 4 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention;

[0026] Figure 5 This is a block diagram illustrating a human intervention device for a highly automated vehicle according to an embodiment of the present invention. Detailed Implementation

[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the present invention.

[0028] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. The singular forms “a,” “the,” and “the” used in this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0029] It should be understood that although the terms first, second, third, etc., may be used in this invention to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of this invention, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0030] With the rapid development of intelligent driving technology, more and more vehicles support intelligent driving. For more advanced autonomous driving technologies, the industry typically classifies them into several levels of autonomous driving based on their degree of automation. Level 3 (or conditional autonomous driving) means that the vehicle can achieve safe autonomous driving within its operational design domain (ODD), but a human driver is required as a backup and ready to take over at any time. Level 4 (or highly automated driving) means that the vehicle can drive completely autonomously in a limited area / scenario (such as a park or the city center) without the need for human driver intervention.

[0031] In certain special circumstances (such as when the vehicle is damaged and needs repair, or when it enters the blind spot of the Level 4 autonomous driving function), the autonomous driving system of a vehicle may require human intervention to control the vehicle through manual driving. Therefore, such vehicles are usually equipped with control components for manual driving (such as steering wheel, accelerator pedal, brake pedal, etc.).

[0032] However, the occupants may not have received specialized driving training. Therefore, if the occupants touch the aforementioned controls when the Level 4 autonomous driving function is activated, it may interfere with the normal execution of DDT (Dynamic Driving Task) by the ADS (Automated Driving System), posing a significant safety hazard to the vehicle's operation and urgently requiring improvement.

[0033] To address this issue, this invention proposes a manual takeover scheme for highly automated vehicles. By locking and releasing control components and verifying driver permissions and status, the scheme aims to enable the vehicle to maintain strong anti-interference capabilities at Level 4 autonomous driving while allowing authorized drivers with manual driving skills to smoothly take over the vehicle. This solves the driving safety issues of Level 4 autonomous driving and meets the need for manual takeover when necessary. The specific implementation process of this scheme will be described in detail below with reference to the accompanying drawings and embodiments.

[0034] Figure 1 This is a schematic diagram of the architecture of an autonomous driving system provided in an exemplary embodiment. For example... Figure 1As shown, from a hardware perspective, the system may include only vehicle 11, or it may include both vehicle 11 and cloud server 13. From a software perspective, the autonomous driving system may include the autonomous driving system deployed in vehicle 11, and may also include a cloud service module deployed in cloud server 13 for interacting with the autonomous driving system. Specifically, the driver assistance system of vehicle 11 may be deployed in the domain controller 116 (such as an intelligent driving domain controller ADCU) installed in vehicle 11. It is understood that the driver assistance system is an in-vehicle system, and this system can even operate offline.

[0035] In addition to the domain controller 116, the vehicle 11 is also equipped with various sensors, such as environmental sensing devices for collecting data on the external environment and behavior sensing devices for detecting the behavior of the driver 12 inside the vehicle. This application embodiment does not limit the number of these devices or their installation locations. For example, the environmental sensing devices may include image acquisition devices (such as a front-view camera 111, a side-view camera 112, a rear-view camera 113, etc.), ranging radar 114 (such as a lidar, millimeter-wave radar, ultrasonic radar, etc.); the behavior sensing devices may include a camera 115 (such as a visible light camera, an infrared camera, etc.) installed above the driver's seat to detect the direction of the driver 12's eyes, and / or a torque sensor, pressure sensor, etc., installed on the steering wheel to collect the driver 12's hand movements (this sensor is used to implement the hands-off detection (HOD) function). The aforementioned behavior sensing devices and corresponding control devices can constitute the vehicle's DMS system (Driver Monitoring System).

[0036] Of course, the vehicle may also be equipped with at least one other sensor in a suitable location, including but not limited to rain and fog sensors outside the vehicle (such as rain sensors, particulate matter sensors, haze sensors, etc.), cameras, microphones, biosensors, odor sensors, etc. inside the vehicle, to realize corresponding vehicle functions. This application embodiment does not limit this.

[0037] In cases where the vehicle's autonomous driving system includes a cloud server 13 or there is a need to interact with the cloud server 13, the vehicle 11 can establish a network connection with the cloud server 13 via a wireless communication module to exchange data. For example, if the cloud server 13 locally maintains pre-stored biometric information of authorized users (such as fingerprint information of authorized users), the vehicle 11 can upload the biometric information to be verified input by the driver to the cloud server 13. The cloud server 13 then compares the biometric information to be verified with the pre-stored biometric information of each authorized user and returns the comparison result to the vehicle as a reliable basis for the vehicle to determine whether the driver has the authority to operate the vehicle. The cloud server 13 can be a physical cloud server containing an independent host, or it can be a virtual cloud server or a cloud-to-cloud server hosted by a host cluster. Furthermore, this application does not limit the number, type, or specific interaction method between the cloud servers 13 and the vehicle 11. As for the network 10 for interaction between the vehicle 11 and the cloud server 13, it can be based on the communication methods supported by the corresponding devices, specifically selecting the appropriate type of wireless network for communication; this application does not limit this.

[0038] Furthermore, the vehicle described in this application (such as vehicle 11) can be a pickup truck, sedan, SUV (Sport Utility Vehicle), campervan, or truck, in terms of its functional form; and it can be a gasoline-powered vehicle or a new energy vehicle (such as a hybrid vehicle, pure electric vehicle, hydrogen fuel cell vehicle, or methanol fuel cell vehicle), in terms of its power source. This invention does not limit the specific form of the vehicle. The driver 12 described in this embodiment is a passenger sitting in the driver's seat of vehicle 11.

[0039] It is worth noting that, in addition to possessing highly automated driving capabilities (i.e., supporting Level 4 automated driving), the vehicle described in this application may also possess conditional automated driving capabilities (i.e., supporting Level 3 automated driving). Therefore, the aforementioned automated driving system deployed in this vehicle can be used to achieve both Level 4 and Level 3 automated driving. In other words, the highly automated driving capabilities of the vehicle described in this application are compatible with conditional automated driving capabilities.

[0040] It is also important to emphasize that the autonomous driving functions (whether L3 or L4) implemented by the autonomous driving system described in this application must comply with the relevant laws, regulations, and standards of the corresponding countries and regions (such as the place of sale and / or place of use of the vehicle), and provide relevant personnel (such as drivers, vehicle owners, and back-end administrators) with corresponding operation interfaces to allow them to choose to authorize or refuse use. Furthermore, the user information (including but not limited to user device information, user biometric information, and other personal information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved in this application are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation interfaces must be provided for users to choose to authorize or refuse use.

[0041] Figure 2 This is a flowchart illustrating a method for manual takeover of a highly automated vehicle according to an embodiment of the present invention. This method is applied to vehicles with highly automated driving capabilities (such as…). Figure 1 The vehicle 11 shown can be specifically applied to the vehicle's autonomous driving system and autonomous driving controller (such as...). Figure 1 Domain controller 116 shown.

[0042] The vehicle is equipped with controls (or controls, control accessories) for manual driving. These controls typically possess mechanical operability, such as the ability to rotate, be stepped on, or be tossed. Furthermore, the controls are locked when the highly automated driving function is activated, but can be released (i.e., unlocked) when manual intervention is required, allowing the driver to operate them. It is understood that "the controls being locked" means that the occupant cannot influence the ADS through the controls. Specifically, this could include: the controls being mechanically locked, thus preventing the occupant from effectively operating them; or the controls being software locked, meaning that although the occupant can operate the controls normally, the resulting control signals are not received by the ADS, or the ADS receives the signals but does not respond.

[0043] As can be seen, locking the control components mechanically or through software, so that the control components are locked when the highly automated driving function is activated, effectively decouples the control components from the ADS (Autonomous Controller System). This completely isolates the occupant's operation from the normal operation of the ADS (i.e., the ADS executing DDT). Regardless of how the occupant operates the control components, it will not affect the normal operation of the ADS according to its own logic, thus not interfering with the highly automated driving function. Therefore, locking the control components when the highly automated driving function is activated effectively prevents occupant's human operation (such as intentionally turning the steering wheel or unintentionally pressing the brake pedal) from "driving" the ADS, leading to loss of vehicle control, thus improving the safety of the highly automated driving function operating within its ODD (Optical Distribution Code). For example, the control components may include a foldable steering wheel, a brake pedal and accelerator pedal with pedal force, an electronic shift switch or lever, etc. This application does not limit the type, quantity, or installation position of the control components.

[0044] like Figure 2 As shown, the method includes the following steps 202-206.

[0045] Step 202: When the highly automated driving function is activated, in response to a takeover request initiated by the driver, verify the driver's takeover authority over the vehicle.

[0046] In certain special circumstances, the highly automated driving function of a vehicle may be partially limited or even rendered unusable, requiring manual intervention by a human driver. For example, after a traffic accident (such as a scrape or collision), the cameras, radar, and other sensors installed around the vehicle may be damaged, causing some functions of the highly automated driving system to be limited or even completely disabled. In this case, a human driver must manually drive the vehicle to a designated location (such as a dealership) for repairs. Another example is that the vehicle may enter the blind spot of the highly automated driving function (i.e., a location where the highly automated driving function cannot operate normally). For instance, if the highly automated driving function relies on high-precision maps, the vehicle may drive out of the coverage area of ​​the high-precision map (i.e., the high-precision map signal for the current location has not been pre-collected); or if the highly automated driving function is only applicable to highways, urban elevated roads, urban surface roads, and provincial roads, the vehicle may drive onto rural roads or even unpaved roads. In these situations, the highly automated driving function cannot ensure the safe driving of the vehicle, requiring manual driving to enter the effective area of ​​the highly automated driving function or continue to the destination.

[0047] Given that the vehicle's highly automated driving function is currently activated, manual control of the vehicle is required for manual driving. The vehicle described in this application is equipped with a driver's seat; once a person sits in the driver's seat, that person automatically becomes the driver. For example, the driver could be a maintenance personnel. If the vehicle is an operational vehicle, back-end operations personnel or maintenance personnel from the operating entity can arrive at the vehicle's current location, get in, and become the driver to drive the vehicle to a repair location after taking control. The driver could also be the vehicle owner. If the vehicle is a private car, the owner may be the driver or any passenger, in which case they can take control of the vehicle from the driver's seat and drive it to a preset location. The driver could also be an insurance agent. For example, after a traffic accident is reported to the insurance company, the insurance company can send personnel (such as claims adjusters) to the vehicle's current location to handle insurance-related matters, and after completing the handling, get in, and become the driver to drive the vehicle to a repair location after taking control. The driver can also be any passenger in the vehicle. In case of an emergency such as a traffic accident on the highway, the tow truck or maintenance personnel may arrive slowly. In order to avoid secondary accidents and / or reduce congestion, if any passenger in the vehicle has the qualifications to drive (i.e., holds a valid driver's license), they can come from the back seat to the driver's seat to become the driver, so as to take over the vehicle and drive it to a safe location (such as leaving the highway or entering a service area). Further details are omitted.

[0048] When a driver in the driver's seat needs to take over the vehicle manually, they can send a takeover request to the vehicle, which will then respond to the request and perform subsequent verification work.

[0049] In one embodiment, the driver can initiate the takeover request in various ways to meet the application needs of different scenarios. For example, if the vehicle is equipped with a triggerable takeover device (such as a button, knob, etc.), the driver can trigger the device through a preset operation (such as pressing, rotating, etc.); accordingly, if the vehicle detects that the device has been triggered, it can determine that it has received the takeover request initiated by the driver.

[0050] For example, the vehicle may have voice recognition capabilities. Therefore, to lower the threshold for driver takeover, the driver can be allowed to initiate takeover requests via voice. The vehicle can detect the driver's voice, recognize its semantics, and determine if the voice contains preset takeover semantics (such as the driver saying "Please activate manual driving" or "I want to take over the vehicle"), thus confirming receipt of the driver's takeover request. Since members in different locations within the vehicle may emit different voices, the vehicle can use Sound Source Localization (SSL) technology to determine the sound source location of each received voice, thereby accurately locating the driver's (rather than other occupants') voice. This avoids misinterpreting normal conversations between occupants or voices from other occupants that do not indicate a takeover intent as a driver-initiated takeover request and thus improves the accuracy of the takeover request response.

[0051] For example, the vehicle may be equipped with a display device (such as a central control screen, instrument panel screen, etc.), so that the driver can be provided with an HMI (Human-Machine Interaction) interface related to the vehicle's driving functions through the device. For example, the interface may display takeover controls for the vehicle (triggerable / selectable options, virtual buttons, etc.), and the driver can trigger the control by performing a touch operation. Correspondingly, if the vehicle detects that the takeover control has been triggered, it can determine that it has received the takeover request initiated by the driver.

[0052] For example, the vehicle can establish a connection with a terminal device. This could be a pre-established wireless connection with a general-purpose terminal device used by the driver (such as a mobile phone, tablet, or wearable device like a smartwatch or smart glasses); or a wired connection via a pre-installed wired interface on the vehicle with a dedicated terminal device used by the driver (e.g., a professional maintenance personnel). In this case, the driver can send a takeover signal to the vehicle through the terminal device; correspondingly, the vehicle can determine that it has received the takeover request initiated by the driver upon receiving the takeover signal from the terminal device. This method of takeover request is initiated by the driver through their terminal device, rather than through operation on the vehicle itself, making the initiation method more flexible, such as initiating it before entering the vehicle to reduce waiting time. Furthermore, the vehicle can pre-verify the necessary permissions of the terminal device to prevent unrelated devices from initiating takeover requests, improving the security of subsequent responses.

[0053] Upon receiving the aforementioned takeover request from the driver, the vehicle is in Level 4 autonomous driving mode, meaning the highly automated driving function is activated. In response to this request, the vehicle can first verify the driver's takeover authority to ensure the reliability of subsequent responses.

[0054] In one embodiment, the vehicle can verify the driver's takeover authority through at least one of the following methods to meet the security and privacy requirements in different scenarios.

[0055] For example, the vehicle can collect the driver's biometric information and submit it to a cloud server. The cloud server then compares this biometric information with pre-stored biometric information of authorized users, returning a comparison result. This biometric information may include fingerprints (collected by a fingerprint scanner installed in the vehicle), facial images (collected by a visible light / infrared camera installed in the driver's seat), and voiceprints (collected by a microphone and identified using a corresponding voiceprint recognition algorithm). The authorized user refers to a user pre-verified by the cloud server with takeover rights over the vehicle, such as pre-authenticated backend maintenance personnel or pre-authenticated vehicle owners. This embodiment does not impose such limitations. Furthermore, the result indicating that the driver is an authorized user (i.e., the biometric information is the same as / consistent with the pre-stored biometric information of an authorized user) is considered a necessary condition for successful authorization verification. This method allows for precise verification of whether a driver is an authorized user based on the uniqueness of human biometric information.

[0056] For example, the vehicle can also receive and compare the takeover password entered by the driver with the standard takeover password issued by the cloud server. The fact that the takeover password to be verified matches the standard takeover password is a necessary condition for successful authorization verification. For instance, the driver can establish a connection with the cloud server to obtain the takeover password to be verified, while the cloud server can directly issue the standard takeover password to the vehicle through a preset channel. For example, the driver can use the in-vehicle emergency call function or their mobile phone to call emergency customer service to request takeover. Customer service personnel can then provide the driver with a preset or temporarily generated (e.g., randomly generated according to preset rules) takeover password (as the takeover password to be verified) and trigger the cloud server to issue this takeover password to the vehicle (as the standard takeover password). Alternatively, the driver can log in to a preset function page provided by the cloud server through the vehicle's infotainment system or their mobile phone and view the takeover password displayed on the page (this password, once entered into the vehicle, becomes the takeover password to be verified). The cloud server can then issue this takeover password to the vehicle as the standard takeover password. Further details are omitted. Understandably, for a vehicle, if the takeover password entered by the driver is the same as the standard takeover password directly issued by the cloud server, it indicates that the takeover password is a valid password legally obtained by the driver from the cloud server. Therefore, the legality of the driver's takeover action can be proven, and it can be determined that the driver has takeover authority. This method of takeover password needs to be temporarily generated by the cloud server, resulting in high randomness, timeliness, and strong security.

[0057] Alternatively, the vehicle can receive a takeover password input by the driver and compare it with a standard takeover password pre-stored locally. The matching of the takeover password to the standard takeover password is a necessary condition for successful authorization. The takeover password to be verified can also be obtained by the driver from the cloud server using the aforementioned method, while the standard takeover password is pre-stored locally in the vehicle (e.g., it can be written at the vehicle's manufacturing stage, or it can be retrieved from the cloud server and written locally on a fixed schedule such as daily / weekly / monthly, or a new standard takeover password can be retrieved from the cloud server and written locally after each successful takeover / use). Correspondingly, the cloud server can record the currently written standard takeover password locally (e.g., it can be obtained from the vehicle manufacturer and recorded locally, or it can be recorded locally after each issuance to the vehicle), and provide it to the driver through the aforementioned online customer service or service page. It is understood that this method does not require the cloud server to randomly generate a takeover password, and the password management and verification logic is relatively simple and efficient.

[0058] For example, drivers can also connect to the cloud server through online customer service or web page services to inform it of their takeover request. In this case, the cloud server can issue an emergency command identifier to the vehicle, which informs the driver that manual takeover is required and triggers the vehicle to prepare for takeover. Correspondingly, the vehicle can receive the emergency command identifier issued by the cloud server, where the emergency command identifier (such as a preset identifier like "Manual Takeover" or "Emergency Takeover") is a necessary condition for successful authorization verification.

[0059] It should be noted that each of the above verification methods can be used individually, such as verifying only biometric information; successful verification indicates that the driver has takeover authority over the vehicle. Alternatively, at least two of the above verification methods can be used in combination for authorization verification. In this case, each of the at least two methods must pass verification before the driver is determined to have takeover authority over the vehicle. For example, when verifying biometric information and any takeover password, the driver is only determined to have takeover authority over the vehicle if "the received comparison result indicates that the driver is an authorized user" and "the takeover password entered by the driver is the same as the standard takeover password." If any information verification fails, the driver is determined not to have takeover authority, which will not be elaborated further.

[0060] In one embodiment, if the takeover permission verification fails (i.e., the driver does not have takeover permission), it indicates that the takeover request was initiated by an unauthorized user. In this case, the vehicle can refuse manual takeover for safety reasons. For example, the vehicle can keep the highly automated driving function active, exit the response process for the aforementioned takeover request, and output a takeover refusal message to the driver.

[0061] Step 204: After the permission verification is passed, unlock the control unit and detect the current state of the driver; and if the current state is a takeover ready state, trigger the vehicle to enter the takeover transition control phase and detect the driver's vehicle control operation behavior on the control unit.

[0062] The phrase "authorization verification passed" should be understood as "the verification result shows that the driver has the authority to take over the vehicle." At any time after authorization verification is passed, the driver's current state may be either "takeover ready" (indicating that the driver is ready to take over the vehicle) or "takeover not ready" (indicating that the driver is not yet ready to take over the vehicle).

[0063] After authorization verification is successful, the locking of the control element can be released, allowing the driver to perform corresponding actions on the control element. Releasing the lock on the control element can involve releasing the mechanical lock, allowing the driver to manually operate the component; and / or, it can also release the software lock, enabling the vehicle's actuators (such as steering, power, and braking mechanisms) to respond to control signals issued by the control element (under the driver's control) to control the vehicle's lateral and longitudinal movements.

[0064] In one embodiment, the control element can be unlocked according to an unlocking method corresponding to its type and locking method. For example, if the control element includes a steering wheel, and the steering wheel is hidden and not visible, the steering wheel can be moved to a preset operable position. Some Level 4 autonomous vehicles (such as Robotaxi) automatically retract the steering wheel (e.g., hide it under the dashboard or in the center console area) in autonomous driving mode (i.e., when highly automated driving is enabled) to save space, improve passenger experience, and prevent accidental steering wheel operation. When moving the steering wheel to the preset operable position, a motor drive mechanism can be controlled to extend the steering wheel from its hidden position to a standard driving position (fixed height and angle) so that the driver can grip and operate it normally. And / or, if the control element includes a steering wheel and the steering wheel is locked and cannot be rotated, the lock can be released to allow the steering wheel to rotate. In other words, even when the steering wheel is visible, it may be prevented from turning by electromagnetic locks, mechanical pins, or software shielding (to prevent accidental contact). To address this, the vehicle can unlock the steering wheel by disconnecting the electromagnetic lock power supply, releasing the mechanical lock pin, or restoring the steer-by-wire signal path, so that the steering wheel rotation command can be truly transmitted to the steering actuator (such as the steering motor).

[0065] Similarly, when the control element includes a shift switch (or gear control module), if the shift switch is hidden and not visible, it can be moved to a preset operable position. In autonomous driving models, shift switches such as knobs or levers may automatically retract or be covered by a cover to prevent accidental vehicle movement caused by passengers accidentally shifting gears. This can be achieved by controlling a motor to raise or slide the shift switch to expose the operating interface to the driver (e.g., the P / R / N / D gear indicators illuminate). And / or, if the shift switch is locked and cannot be moved, it can be unlocked to make it movable. Even if the shift switch is visible, force feedback motors or software may prevent the user from shifting gears (e.g., only allowing the system to automatically engage P gear). This can be addressed by removing the torque limitation or enabling gear shifting permissions to allow the driver to manually select R / N / D gears.

[0066] For example, if the control element includes a brake pedal, and the brake pedal is locked and cannot be pressed, the lock can be released to allow the brake pedal to be pressed. In automatic driving mode, the brake pedal may be physically blocked by a limit block (cannot be pressed), or it may be pressable but the signal is blocked (pressing it does not trigger braking). To address this, the physical limit can be released (e.g., a solenoid valve releases a stop block), while simultaneously activating the travel sensor and the brake-by-wire system, allowing the pedaling action to be detected and executed.

[0067] Similarly, in cases where the control includes an accelerator pedal, if the accelerator pedal is locked and cannot be pressed, the lock is released to make the accelerator pedal depressable. For example, the accelerator is typically disabled in autonomous driving mode to prevent accidental pressing by a passenger causing sudden acceleration of the vehicle. This can be achieved by releasing the physical limit (if any), then activating the throttle position sensor, and connecting the signal to the vehicle controller.

[0068] In addition to the types mentioned above, the control components may also include the parking brake (electronic parking brake / EPB), light control switch, windshield wiper control switch, etc., which will not be elaborated further. However, it should be noted that because the takeover is not yet complete at this point, the vehicle can remain unresponsive to corresponding operation signals while the control components are unlocked using the methods described above. In other words, during the unlocking phase, even if the user performs actions such as pressing, flicking, or depressing, the vehicle can block the corresponding control signals. For example, with the brake pedal, "can be pressed" does not equate to "immediate braking," as the vehicle still needs to verify whether the takeover action is effective.

[0069] Understandably, after the locking of the control element is released, the control element is in a ready-to-operate state, at which point the driver can perform corresponding actions (i.e., execute corresponding operations) on the control element. For example, the vehicle can detect the driver's current state by detecting the takeover actions performed by the driver on the control element to determine whether the driver is ready. Alternatively, the vehicle can also detect the driver's vehicle control actions performed by the driver on the control element to determine whether the takeover was successful.

[0070] In one embodiment, after authorization verification is passed, the driver's current state can be detected in at least one of the following ways. For example, the driver's current effective field of view can be detected, such as by capturing a real-time image of the driver's face using a camera installed in the cockpit and calculating the driver's current effective field of view (i.e., the industry term "eyes on") based on facial / eye / pupil orientation. The current state is a takeover ready state, which includes the current effective field of view covering a preset driving field of view area. In other words, the current effective field of view covering the preset driving field of view area is a necessary condition for determining that the current state is a takeover ready state; that is, to determine that the current state is a takeover ready state, the driver's current effective field of view needs to cover the preset driving field of view area. The current effective field of view refers to the angle that the driver's eyes can observe at the current moment; while the driving field of view area refers to the area visible to the eyes of an ordinary driver when manually driving a vehicle, such as the field of view range of the left and right rearview mirrors - center console - windshield area. It is understandable that if the current effective field of view is detected to cover the preset driving field of vision area, it means that the driver's eyes are currently observing the key areas around the vehicle that are related to the vehicle's driving safety. Therefore, it can be considered that the driver's eyes are ready for manual driving.

[0071] For example, the system can also detect the driver's takeover maneuvers on the control components. When the control components include a steering wheel, the takeover maneuvers can include gripping the steering wheel. For instance, it can detect whether the driver's hands are gripping the steering wheel, where the current state being a takeover ready state includes the driver's hands gripping the steering wheel. In other words, the driver's hands gripping the steering wheel is a necessary condition for determining that the current state is a takeover ready state; that is, to determine that the driver is ready to take over, their hands must be effectively gripping the steering wheel. The driver can be required to grip the steering wheel with both hands to ensure a high level of alertness through relatively strict detection conditions; of course, the driver can also be allowed to grip the steering wheel with one hand, depending on actual needs. The takeover maneuvers can also include lightly pressing the brake pedal, lightly pressing the accelerator pedal, and / or shifting the gear shift, etc., which will not be elaborated further.

[0072] In one embodiment, after unlocking the control unit, the driver's current state can be continuously monitored. If the current state is detected as ready to take over at any point during the continuous monitoring process, the vehicle can be triggered to enter a takeover transition control state; otherwise, if the current state is still not ready to take over after the continuous monitoring period reaches a first preset duration (i.e., the driver is not ready within the first preset duration of continuous monitoring), the aforementioned takeover request and takeover operation may simply be a driver error. Therefore, the monitoring can be stopped, the control unit can be relocked, and the highly automated driving function can remain activated (i.e., L4 remains unchanged). Afterward, the current takeover process can be exited. The first preset duration can be 30 seconds, 1 minute, 3 minutes, or 5 minutes, etc., and this embodiment does not limit this.

[0073] This method allows for timely exit from the takeover process and restoration to normal L4 operation if the user remains unprepared for an extended period. It effectively filters out takeover requests caused by driver error (which typically occurs when a driver is not truly ready), avoiding driving risks due to driver panic or inability to drive after a successful takeover response to such requests.

[0074] Understandably, this approach prevents the system from remaining in a prolonged "semi-takeover" ambiguity: without a timeout, the system might wait indefinitely for the driver to be "ready," resulting in the vehicle being neither fully controlled by the driver nor the system. The vehicle would remain in a detection state for an extended period, with controls in a "partially activated" state, posing a risk of accidental activation. Furthermore, system resources would be consumed (e.g., the DMS would run at a high load), increasing safety risks. This solution, through timeout rollback, forces the system to return to a clear state: either successful takeover or a return to the safe L4 mode, providing a safety fallback for the takeover preparation process. Additionally, this solution improves system robustness and user experience consistency. Clear timeout rules make the operation predictable and repeatable; for example, the driver knows "the action must be completed within 30 seconds," and the system automatically recovers after failure without manual "cancellation," preventing the vehicle from "getting stuck" on the takeover interface due to driver error. In effect, this is also an operational feedback mechanism, clearly informing the driver that "they are not yet ready, so the system has revoked control."

[0075] If the driver's current state is detected as ready to take over (i.e., the driver is determined to be ready), the vehicle can be triggered to enter the takeover transition control phase.

[0076] In one embodiment, the vehicle may also possess conditional automated driving functionality, meaning that while achieving Level 4 automated driving, it is also compatible with the lower Level 3 automated driving. Based on this, when the vehicle is triggered to enter the takeover transition control phase, different forms of processing can be performed according to the vehicle's current motion state. For example, the vehicle's current motion state can be determined first (e.g., if the vehicle speed is not zero, it is determined to be in a driving state; if the vehicle speed is zero, it is determined to be in a parked state): if the vehicle is currently in a driving state, the highly automated driving function can be deactivated and the conditional automated driving function can be activated (i.e., downgrading from Level 4 to Level 3); while if the vehicle is currently in a parked state, the highly automated driving function can remain activated (of course, even if Level 4 is maintained, the vehicle is still in a parked state).

[0077] Understandably, this solution aligns better with a "scenario-driven" approach, meaning that while the driver cannot directly let go of the controls during driving, the system is first downgraded to Level 3; however, it can be taken over directly after parking. This approach is more in line with functional safety principles (using "whether the vehicle is moving" as the primary decision-making criterion, a common paradigm in autonomous driving design). Before manual takeover during vehicle operation, the system is forcibly downgraded to Level 3 (using Level 3 as a transitional state between Level 4 and manual driving), effectively avoiding the safety risks caused by "driver's mistaken readiness leading to system mis-locking," resulting in higher safety. Moreover, the processing flow in parking scenarios is significantly simplified, helping to improve takeover and maintenance efficiency in this scenario.

[0078] Understandably, this approach is essentially a dynamic takeover strategy based on scenario awareness and safety priority. If the L4 system were to exit and immediately relinquish all control (e.g., the steering wheel or accelerator suddenly becomes active) before the driver is ready, it could easily lead to steering deviation, sudden braking, or loss of control during acceleration. To address this, this solution does not immediately exit L4 while driving, but instead downgrades to L3. In L3 mode, the system still handles the vehicle's longitudinal and lateral control, but enters a "request takeover" state, waiting for the driver to complete the standard takeover actions (i.e., waiting for successful takeover). This effectively creates a "buffer zone": the system controls the vehicle, the driver prepares, and the handover process is controlled, reversible, and safe. Furthermore, downgrading is unnecessary when the vehicle is parked, improving efficiency and simplicity: if the vehicle has already pulled over and is parked (e.g., automatically stopped due to a malfunction), there is no risk of movement, so an L3 transition is unnecessary, and L4 can remain active (maintaining environmental monitoring, communication, etc.). This approach reduces unnecessary mode switching (L4→L3→manual) in parking scenarios, shortening the takeover path; it also avoids activating redundant L3-related modules (such as high-frequency DMS, steering torque monitoring, etc.), saving computing power and energy consumption; furthermore, driver operation is more direct: "authenticate → unlock → drive away," resulting in a more efficient experience. Therefore, this solution allows the system to activate L3 takeover logic only when truly needed (i.e., while driving); in parking scenarios, L3 functions remain completely inactive, reducing system complexity and potential failure surfaces.

[0079] After the vehicle is triggered to enter the takeover transition control phase, the driver's vehicle control actions on the control components can be detected. By determining whether the vehicle control actions meet the preset takeover success conditions, it can be determined whether the driver has successfully taken over the vehicle.

[0080] Step 206: If the manipulation behavior meets the preset takeover success conditions, the highly automated driving function is deactivated so that the vehicle can be manually driven by the driver.

[0081] Understandably, since the control unit has been unlocked and the aforementioned process has confirmed that the driver is ready and has successfully taken over, the driver can perform DDT by manipulating the control unit after the highly automated driving function is turned off, thereby achieving manual driving.

[0082] In one embodiment, the vehicle control operation satisfies a preset takeover success condition under at least one of the following conditions. For example, when the control element includes a steering wheel, the duration for which the driver's hands hold the steering wheel is not less than (i.e., greater than or equal to, the same below) a second preset duration, such as the driver continuously holding the steering wheel with both hands / one hand for 3 seconds. Whether the driver is holding the steering wheel and the duration of holding it can be detected by a pressure sensor and / or a capacitance sensor on the steering wheel, or it can be determined by detecting the steering torque applied to the steering wheel, which will not be elaborated further. As another example, when the control element includes a brake pedal, the driver's foot depresses the brake pedal within a third preset duration, such as the driver's foot depressing the brake within 3 seconds. As yet another example, when the control element includes an accelerator pedal, the driver's foot depresses the accelerator pedal within a fourth preset duration, such as the driver's foot depressing the accelerator within 3 seconds. For example, when the control element includes a shift switch (or gear selector), the shift switch is placed in a preset gear by the driver, such as the driver setting the current gear to D or N by operating the gear selector.

[0083] The second to fourth preset durations can be flexibly set according to actual needs, and this application embodiment does not limit this. In one embodiment, when the control components include a steering wheel and a brake pedal, the third preset duration may not exceed the second preset duration, and both start at the same time. Similarly, when the control components include a steering wheel and an accelerator pedal, the fourth preset duration may not exceed the second preset duration, and both start at the same time. This method allows the driver to take over the vehicle / trigger vehicle movement by pressing the brake or accelerator while holding the steering wheel, conforming to the manual driving habits of most drivers and helping to improve takeover efficiency and the accuracy of manual driving operations. For example, the second to fourth preset durations can all be 3 seconds or 5 seconds.

[0084] In one embodiment, after the vehicle enters the takeover transition control phase, the driver's vehicle control behavior regarding the control components can be continuously monitored. Based on this, if the vehicle control behavior still fails to meet the takeover success conditions after a fifth preset monitoring period (i.e., the driver fails to successfully take over within the fifth preset monitoring period), the aforementioned operation may be a misoperation or the driver may not currently possess takeover capabilities. Therefore, monitoring can be stopped and the control components can be relocked. Furthermore, if the vehicle is currently in motion, the highly automated driving function is restored (i.e., corresponding to the aforementioned downgrade from L4 to L3, here L3 can be restored / upgraded back to L4). If the vehicle is currently parked, the highly automated driving function is deactivated, and the takeover process can then be exited. The fifth preset monitoring period can be the same as at least one of the second to fourth preset monitoring periods, or it can be longer than any of the aforementioned preset monitoring periods. For example, the fifth preset monitoring period can be 30 seconds, 1 minute, 3 minutes, or 5 minutes, etc., and this embodiment does not limit this.

[0085] In the aforementioned embodiments, the vehicle equipped with highly automated driving capabilities (i.e., Level 4 automated driving) is fitted with a control mechanism for manual driving, which is locked when the highly automated driving capability is activated. Specifically, when the capability is activated, the vehicle responds to a takeover request initiated by the driver, verifies the driver's takeover authority, unlocks the control mechanism after successful authorization verification, and detects the driver's current state. If the driver is in a takeover ready state, the vehicle is triggered into a takeover transition control phase, and the driver's vehicle control actions via the control mechanism are detected. Finally, if the vehicle control actions meet preset takeover success conditions, the highly automated driving capability is deactivated, allowing the driver to manually drive the vehicle (i.e., enabling the driver to perform dynamic driving tasks via the control mechanism).

[0086] Understandably, because the controls are locked when the highly automated driving function is activated, occupants cannot interfere with its normal operation. Furthermore, after a driver requests takeover, the vehicle does not unconditionally allow control. Instead, it gradually assesses whether the driver has the authority to take over, is ready to take over, and whether the takeover is successful. Only after successful takeover is the highly automated driving function deactivated, allowing the driver to resume manual driving.

[0087] On the one hand, with Level 4 autonomous driving enabled, the system prevents occupants from effectively operating the controls, thus preventing them from interfering with the normal execution of DDT by the ADS (Autonomous Driving System). On the other hand, the Level 4 function is deactivated after the driver successfully takes over, allowing the driver to smoothly perform dynamic driving tasks and achieve manual driving through the controls. It is evident that this solution, through locking and releasing the controls, verifying driver permissions and status, and releasing the controls only after successful permission verification, entering the transition control phase only after the driver is ready, and deactivating the Level 4 function only after successful driver takeover, provides a progressive judgment and processing flow. This allows the vehicle to have strong anti-interference capabilities in Level 4 autonomous driving while allowing authorized drivers with genuine manual driving skills to smoothly take over the vehicle. This effectively solves the driving safety issues of Level 4 autonomous driving and meets the need for manual takeover in necessary situations, demonstrating significant improvement.

[0088] Figure 3 This is a flowchart illustrating another method for manual takeover of a highly automated vehicle, as shown in an embodiment of the present invention. Figure 3 As shown, the process includes the following steps 301 to 315.

[0089] Step 301: After the driver arrives, he takes his seat in the driver's seat and issues a takeover request.

[0090] At the start of this program, the vehicle is in Level 4 autonomous driving mode (i.e., conditional autonomous driving function is activated). If an abnormal scenario occurs that requires manual intervention, the driver can then arrive and make a request.

[0091] Step 302: After the driver enters verification information (such as their own biometric information, a takeover password obtained from a preset channel, etc.), the vehicle verifies the driver's takeover authority accordingly.

[0092] Step 303: The vehicle judges the verification result: if the driver does not have takeover authority, proceed to step 304; otherwise, if the driver has takeover authority, proceed to step 304.

[0093] Step 304: The vehicle remains in L4 mode and exits the takeover process.

[0094] The driver lacks takeover authority, indicating that the takeover request was initiated by an unauthorized user. For safety reasons, the vehicle can refuse manual takeover. Therefore, the vehicle can remain in L4 mode and exit the takeover process, i.e., exit the response process for the aforementioned takeover request.

[0095] In addition, to ensure the driver's right to know and improve the user experience, relevant rejection prompts can be displayed to the user through text pop-ups, voice playback, etc., such as "You do not have the right to take over the vehicle" or "No takeover authority, takeover failed".

[0096] Step 305: The vehicle is unlocked from the control components so that the driver can perform the corresponding control actions (such as taking over control or controlling the vehicle).

[0097] Step 306: The vehicle continuously monitors the driver's current status.

[0098] Step 307: The vehicle determines the driver's current status: if the driver is in a ready-to-take-over state, proceed to step 308; otherwise, if the driver is not in a ready-to-take-over state, proceed to step 310.

[0099] Step 308: The vehicle enters the takeover transition control state.

[0100] First, determine the current motion state of the vehicle (e.g., if the vehicle speed is not zero, it is determined to be in a moving state; if the vehicle speed is zero, it is determined to be in a stationary state), and then make a judgment:

[0101] If the vehicle is currently in motion, it will be downgraded from L4 to L3. After downgrading, some advanced driving functions will be restricted, and the vehicle will be controlled automatically according to the preset L3 autonomous driving logic. For example, after downgrading to L3, the lateral movement of the vehicle will no longer be controlled, only the longitudinal movement (such as controlling following the vehicle at a preset distance). In addition, corresponding downgrade prompts can be output to the user, such as "Downgraded to L3 autonomous driving, please be prepared to take over at any time," etc.

[0102] Otherwise, if the vehicle is currently parked, then L4 remains on.

[0103] Step 309: Determine if the detection has timed out.

[0104] If the continuous detection time has not reached the first preset time (e.g., 30s), return to step 306 to continue detection; if the continuous detection time reaches the first preset time, proceed to step 310.

[0105] Step 310: Relock the control and return to step 304.

[0106] After relocking, the system can output corresponding relocking prompts to the user, such as "Timeout not ready, steering wheel / accelerator / brake has been relocked, please try again if you need to take over".

[0107] Step 311: Continuously monitor the driver's vehicle control actions on the control components.

[0108] For example, it can detect the duration of the driver's hands holding the steering wheel, the steering torque applied to the steering wheel by the hands, when the driver's foot presses the brake pedal, when the driver's foot presses the accelerator pedal, and whether the shift switch is placed in a preset gear.

[0109] Step 312: Determine whether the vehicle control operation meets the conditions for successful takeover.

[0110] If the condition is met, proceed to step 313; otherwise, if the condition is not met, proceed to step 314.

[0111] Step 313: Disengage L4, manual takeover complete, and from this point on, it will be fully manual driving.

[0112] Step 314: Determine if the detection has timed out.

[0113] If the continuous detection time has not reached the fifth preset time (e.g., 30s), return to step 311 to continue detection; if the continuous detection time reaches the fifth preset time, proceed to step 315.

[0114] Step 315: Relock the control unit; if the vehicle is currently moving (as can be seen from step 308, the vehicle is currently in L3), upgrade L3 to L4; or, if the vehicle is currently stopped (as can be seen from step 308, the vehicle is currently in L4), deactivate L4 and complete automatic parking; finally, exit the takeover process, that is, exit the response process for the aforementioned takeover request.

[0115] In addition, to ensure the driver's right to know and improve the user experience, the corresponding takeover failure prompts can be displayed to the user through text pop-ups, voice playback, etc., such as "You did not take over the vehicle in time. This takeover has failed. Please try again if you need to take over."

[0116] Figure 4 This is a schematic structural diagram of an electronic device according to an embodiment of the present invention. Please refer to it. Figure 4 At the hardware level, the device includes a processor 401, a network interface 402, memory 403, non-volatile memory 404, and an internal bus 405, and may also include other hardware required for business operations. One or more embodiments of the present invention can be implemented in software, for example, the processor 401 reads the corresponding computer program from the non-volatile memory 404 into memory 403 and then runs it. Of course, in addition to software implementation, one or more embodiments of the present invention do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, but can also be hardware or logic devices.

[0117] Figure 5This invention illustrates a block diagram of a manual takeover device for a highly automated vehicle, according to an embodiment of the present invention. Please refer to... Figure 5 This device can be applied to, for example Figure 4 The device shown is used to implement the technical solution described in this invention. This device is applied to a vehicle equipped with highly automated driving capabilities, the vehicle being fitted with controls for manual driving, the controls being locked when the highly automated driving capability is activated, and the device includes:

[0118] The authorization verification unit 501 is used to verify the driver's authorization to take over the vehicle in response to a takeover request initiated by the driver when the highly automated driving function is activated.

[0119] The takeover preparation unit 502 is used to unlock the control unit after the authorization verification is passed and detect the current state of the driver; and, if the current state is the takeover preparation ready state, to trigger the vehicle to enter the takeover transition control phase and detect the driver's vehicle control operation behavior on the control unit.

[0120] The takeover success unit 503 is used to deactivate the highly automated driving function when the vehicle control operation meets the preset takeover success conditions, so that the driver can manually drive the vehicle.

[0121] Optionally, the permission verification unit 501 is specifically used for at least one of the following:

[0122] The system detects a voice message from the driver containing a preset takeover semantics, detects that the takeover device installed in the vehicle is triggered by a preset operation, detects that the takeover control displayed on the display device installed in the vehicle is triggered, and receives a takeover signal from a terminal device connected to the vehicle.

[0123] Optionally, the permission verification unit 501 is specifically used for at least one of the following:

[0124] The system collects the driver's biometric information and submits it to the cloud server. It also receives the comparison result returned by the cloud server after comparing the biometric information with the pre-stored biometric information of authorized users maintained by the server. The comparison result is used as a necessary condition for the driver to be an authorized user and pass the permission verification.

[0125] The system receives and compares the takeover password to be verified entered by the driver with the standard takeover password issued by the cloud server. The fact that the takeover password to be verified is the same as the standard takeover password is a necessary condition for the authorization verification to pass.

[0126] The system receives the takeover password to be verified input by the driver and compares it with the standard takeover password pre-stored locally in the vehicle. The fact that the takeover password to be verified is the same as the standard takeover password is a necessary condition for the authorization verification to pass.

[0127] Receive an emergency instruction identifier issued by the cloud server, wherein the emergency instruction identifier is a preset identifier and is a necessary condition for passing the authorization verification.

[0128] Optionally, the takeover preparation unit 502 is specifically used for at least one of the following:

[0129] In the case where the control element includes a steering wheel, if the steering wheel is hidden and not visible, the steering wheel is moved to a preset operable position; and / or, if the steering wheel is locked and cannot be rotated, the lock is released to allow the steering wheel to rotate.

[0130] In the case where the control element includes a shift switch, if the shift switch is hidden and not visible, the shift switch is moved to a preset operable position; and / or, if the shift switch is locked and cannot be toggled, the lock is released to allow the shift switch to be toggled.

[0131] In the case where the control element includes a brake pedal, if the brake pedal is locked and cannot be pressed, the locking is released so that the brake pedal can be pressed.

[0132] In the case where the control includes an accelerator pedal, if the accelerator pedal is locked and cannot be pressed, the locking is released so that the accelerator pedal can be pressed.

[0133] Optionally, the takeover preparation unit 502 is specifically used for at least one of the following:

[0134] Detect the driver's current effective field of view, wherein the current state is a takeover ready state including the current effective field of view covering a preset driving field of view area;

[0135] When the control element includes a steering wheel, it is detected whether the driver's hands are holding the steering wheel, wherein the current state is a takeover ready state including the driver's hands holding the steering wheel.

[0136] Optional,

[0137] The takeover preparation unit 502 is specifically used to: continuously detect the current state of the driver;

[0138] The device also includes a not-ready-to-exit unit 504, which, if the current state is still not ready to take over when the continuous detection time reaches a first preset time, stops detection, relocks the control unit, and keeps the highly automated driving function activated.

[0139] Optionally, the vehicle also has conditional automated driving capabilities, and the takeover preparation unit 502 is specifically used for:

[0140] Determine the current motion state of the vehicle;

[0141] When the vehicle is currently in motion, the highly automated driving function is deactivated and the conditional automated driving function is activated.

[0142] The highly automated driving function remains activated while the vehicle is currently parked.

[0143] Optionally, the vehicle control operation satisfies a preset takeover success condition, including at least one of the following:

[0144] When the control element includes a steering wheel, the duration for which the driver's hands hold the steering wheel is not less than a second preset duration;

[0145] When the control element includes a steering wheel, the steering torque applied by the driver's hands to the steering wheel is not less than a preset torque;

[0146] When the control element includes a brake pedal, the driver's foot depresses the brake pedal within a third preset duration;

[0147] When the control includes an accelerator pedal, the driver's foot depresses the accelerator pedal within a fourth preset duration.

[0148] When the control element includes a shift switch, the shift switch is placed by the driver in a preset gear position.

[0149] Optional,

[0150] The takeover preparation unit 502 is specifically used to: continuously detect the vehicle control operation behavior performed by the driver on the control components;

[0151] The device further includes a takeover failure exit unit 505, configured to: if the vehicle control operation still fails to meet the takeover success condition after a continuous detection period of five preset durations, stop detection and relock the control unit; and if the vehicle is currently in a driving state, restore the highly automated driving function; and if the vehicle is currently in a parked state, deactivate the highly automated driving function.

[0152] Optionally, a takeover rejection unit 505 is also included, for:

[0153] If the takeover authorization verification fails, the highly automated driving function remains enabled, and a takeover refusal message is displayed to the driver.

[0154] Accordingly, the present invention also provides a vehicle equipped with an environmental perception device and a driver assistance system, which is used to implement the manual takeover method of a highly automated vehicle as described in any of the above embodiments.

[0155] Accordingly, the present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the manual takeover method for a highly automated vehicle as described in any of the above embodiments.

[0156] Accordingly, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the manual takeover method for a highly automated vehicle as described in any of the above embodiments.

[0157] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which can take the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email sending and receiving device, game console, tablet computer, wearable device, or any combination of these devices.

[0158] In a typical configuration, a computer includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0159] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0160] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

Claims

1. A method for manual takeover of a highly automated vehicle, characterized in that The method is applicable to vehicles equipped with highly automated driving and conditional automated driving functions, wherein the vehicles are equipped with controls for manual driving, and the controls are locked when the highly automated driving function is activated; the method includes: When the highly automated driving function is activated, in response to a takeover request initiated by the driver, the driver's takeover authority over the vehicle is verified. After successful authorization verification, the lock on the control unit is released, and the driver's current state is detected; and, if the current state is a takeover ready state, the vehicle is triggered to enter the takeover transition control phase, including: determining the current motion state of the vehicle; if the vehicle is currently in a driving state, disabling the highly automated driving function and enabling the conditional automated driving function; if the vehicle is currently in a parked state, keeping the highly automated driving function enabled and detecting the driver's vehicle control actions on the control unit. If the vehicle control operation meets the preset takeover success conditions, the highly automated driving function is deactivated, allowing the driver to manually drive the vehicle.

2. The method of claim 1, wherein, Receiving a takeover request initiated by the driver includes at least one of the following: The system detects a voice message from the driver containing a preset takeover semantics, detects that the takeover device installed in the vehicle is triggered by a preset operation, detects that the takeover control displayed on the display device installed in the vehicle is triggered, and receives a takeover signal from a terminal device connected to the vehicle.

3. The method of claim 1, wherein, The verification of the driver's takeover authority over the vehicle includes at least one of the following: The system collects the driver's biometric information and submits it to the cloud server. It also receives the comparison result returned by the cloud server after comparing the biometric information with the pre-stored biometric information of authorized users maintained by the server. The comparison result is used as a necessary condition for the driver to be an authorized user and pass the permission verification. The system receives and compares the takeover password to be verified entered by the driver with the standard takeover password issued by the cloud server. The fact that the takeover password to be verified is the same as the standard takeover password is a necessary condition for the authorization verification to pass. The system receives the takeover password to be verified input by the driver and compares it with the standard takeover password pre-stored locally in the vehicle. The fact that the takeover password to be verified is the same as the standard takeover password is a necessary condition for the authorization verification to pass. Receive an emergency instruction identifier issued by the cloud server, wherein the emergency instruction identifier is a preset identifier and is a necessary condition for passing the authorization verification.

4. The method of claim 1, wherein, The unlocking of the control element includes at least one of the following: In the case where the control element includes a steering wheel, if the steering wheel is hidden and not visible, the steering wheel is moved to a preset operable position; and / or, if the steering wheel is locked and cannot be rotated, the lock is released to allow the steering wheel to rotate. In the case where the control element includes a shift switch, if the shift switch is hidden and not visible, the shift switch is moved to a preset operable position; and / or, if the shift switch is locked and cannot be toggled, the lock is released to allow the shift switch to be toggled. In the case where the control element includes a brake pedal, if the brake pedal is locked and cannot be pressed, the locking is released so that the brake pedal can be pressed. In the case where the control includes an accelerator pedal, if the accelerator pedal is locked and cannot be pressed, the locking is released so that the accelerator pedal can be pressed.

5. The method according to claim 1, characterized in that, The detection of the driver's current state includes at least one of the following: Detect the driver's current effective field of view, wherein the current state is a takeover ready state including the current effective field of view covering a preset driving field of view area; When the control element includes a steering wheel, it is detected whether the driver's hands are holding the steering wheel, wherein the current state is a takeover ready state including the driver's hands holding the steering wheel.

6. The method according to claim 1, characterized in that, The detection of the driver's current state includes: continuously detecting the driver's current state; The method further includes: if the current state is still not ready for takeover when the continuous detection time reaches a first preset time, then stop the detection, relock the control unit and keep the highly automated driving function activated.

7. The method of claim 1, wherein, The vehicle control operation meets the preset takeover success conditions, including at least one of the following: When the control element includes a steering wheel, the duration for which the driver's hands hold the steering wheel is not less than a second preset duration; When the control element includes a steering wheel, the steering torque applied by the driver's hands to the steering wheel is not less than a preset torque; When the control element includes a brake pedal, the driver's foot depresses the brake pedal within a third preset duration; When the control includes an accelerator pedal, the driver's foot depresses the accelerator pedal within a fourth preset duration. When the control element includes a shift switch, the shift switch is placed by the driver in a preset gear position.

8. The method according to claim 1, characterized in that, The detection of the driver's vehicle control actions performed on the control components includes: continuously detecting the driver's vehicle control actions performed on the control components; The method further includes: if the vehicle control behavior still fails to meet the takeover success condition after a continuous detection period of five preset durations, then stop the detection and relock the control unit; and if the vehicle is currently in a driving state, then restore the highly automated driving function; and if the vehicle is currently in a parked state, then deactivate the highly automated driving function.

9. The method of claim 1, wherein, Also includes: If the takeover authorization verification fails, the highly automated driving function remains enabled, and a takeover refusal message is displayed to the driver.

10. An apparatus for manual takeover of a highly automated vehicle, characterized by Applied to vehicles equipped with highly automated driving and conditional automated driving functions, the vehicles are equipped with controls for manual driving, the controls being locked when the highly automated driving function is activated, the device comprising: The authorization verification unit is used to verify the driver's authorization to take over the vehicle in response to a takeover request initiated by the driver when the highly automated driving function is activated. The takeover preparation unit is used to unlock the control components after authorization verification and detect the driver's current state; and, if the current state is a takeover ready state, to trigger the vehicle to enter a takeover transition control phase and detect the driver's vehicle control behavior on the control components; wherein, when triggering the vehicle to enter the takeover transition control phase, the takeover preparation unit is specifically used to: determine the vehicle's current motion state; if the vehicle is currently in a driving state, to disable the highly automated driving function and enable the conditional automated driving function; if the vehicle is currently in a parked state, to keep the highly automated driving function enabled. The takeover success unit is used to deactivate the highly automated driving function when the vehicle control operation meets the preset takeover success conditions, so that the driver can manually drive the vehicle.

11. A vehicle having a highly automated driving function and equipped with controls for manual driving, the vehicle being used to implement the method as described in any one of claims 1-9.

12. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-9.

13. A computer program product comprising computer programs and / or instructions, characterized in that, When the computer program and / or instructions are executed by a processor, they implement the steps of the method as described in any one of claims 1-9.

Images