Vehicle take-over reminding method and device in automatic driving scene and electronic equipment

By fusing multi-source data from wearable detection devices, roadside equipment, and vehicle-side devices, and utilizing majority voting and Bayesian posterior probability, the blind spot problem in driver state monitoring in L3 autonomous driving was solved, improving the accuracy of takeover decisions and the safety of autonomous driving.

CN121789490APending Publication Date: 2026-04-03GAC HONDA AUTOMOBILE CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-01-08
Publication Date
2026-04-03

Smart Images

  • Figure CN121789490A_ABST
    Figure CN121789490A_ABST
Patent Text Reader

Abstract

The invention discloses a vehicle takeover reminding method and device in an automatic driving scene and electronic equipment, and the method comprises the steps: obtaining the physiological state data, behavior state data and eye state data of a driver through wearable monitoring equipment, and carrying out the takeover decision, and obtaining a first takeover decision result; obtaining driving environment data and traffic condition data of the vehicle through the roadside equipment, and performing takeover decision to obtain a second takeover decision result; driving state data and hardware state data of the vehicle are obtained through the vehicle end, a takeover decision is made to obtain a third takeover decision result, and a takeover judgment result is determined based on majority voting and Bayesian posterior probability according to the first takeover decision result, the second takeover decision result and the third takeover decision result; and performing takeover reminding according to the takeover judgment result. According to the invention, the accuracy of takeover judgment is improved, so that the safety of automatic driving and the reliability of accident liability affirmation are improved, and the method can be applied to the technical field of automatic driving.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of autonomous driving technology, and in particular to a vehicle takeover warning method, device, and electronic device in an autonomous driving scenario. Background Technology

[0002] In relevant standards for autonomous driving, Level 3 is defined as "conditional automated driving," meaning that within a specific designed operating area, the system can completely take over dynamic driving tasks, allowing the driver to truly "take their hands off and eyes off the road." This means that after activating Level 3, the driver can use their mobile phone in the driver's seat, operate the in-vehicle screen for entertainment or work, talk to passengers, or even take a short break. Only when the system issues a takeover request will the driver need to regain control of the vehicle within a specified time.

[0003] At present, L3 autonomous driving technology is not yet mature, especially in terms of risk warning and takeover reminder before danger occurs and liability determination after an accident. Existing technologies still lack perfect monitoring methods to achieve real-time monitoring and redundant arbitration of driver status with zero blind spots, zero escape from malfunctions, and zero disputes over liability, which affects the safety of autonomous driving and the reliability of accident liability determination.

[0004] The above problems urgently need to be addressed. Summary of the Invention

[0005] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0006] Therefore, one objective of this invention is to provide a vehicle takeover alert method in an autonomous driving scenario. This method first makes takeover decisions independently through wearable detection devices, roadside devices, and vehicle-side devices, and then obtains the takeover determination result based on majority voting and Bayesian posterior probability fusion. This reduces the risk caused by single device failure, improves the accuracy of takeover determination, and thus improves the safety of autonomous driving and the reliability of accident liability determination.

[0007] Another objective of this invention is to provide a vehicle takeover warning device for autonomous driving scenarios.

[0008] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include: On one hand, embodiments of the present invention provide a vehicle takeover alert method in an autonomous driving scenario, comprising the following steps: The driver's physiological state data, behavioral state data, and eye state data are acquired through wearable monitoring devices. A takeover decision is made based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, which is then sent to the vehicle. The vehicle's driving environment data and traffic condition data are acquired through roadside equipment. A takeover decision is made based on the driving environment data and traffic condition data to obtain a second takeover decision result, which is then sent to the vehicle. The vehicle's driving status data and hardware status data are obtained through the vehicle terminal. A takeover decision is made based on the driving status data and hardware status data to obtain a third takeover decision result. The takeover judgment result is determined based on the first takeover decision result, the second takeover decision result, and the third takeover decision result, using majority voting and Bayesian posterior probability. Based on the takeover determination result, a takeover reminder is issued, and the physiological state data, behavioral state data, eye state data, driving environment data, traffic state data, driving state data, hardware state data, and takeover decision log are uploaded to the cloud.

[0009] Furthermore, in one embodiment of the present invention, the step of acquiring the driver's physiological state data, behavioral state data, and eye state data through a wearable monitoring device, and making a takeover decision based on the physiological state data, the behavioral state data, and the eye state data to obtain a first takeover decision result, specifically includes: The physiological state data and behavioral state data are obtained through a smartwatch, and the eye state data is obtained through smart glasses; The physiological state data, the behavioral state data, and the eye state data are input into a pre-trained first takeover decision model to obtain the first takeover decision result; The physiological state data includes heart rate variability, blood oxygen saturation, and skin conductance; the behavioral state data includes hand movement data and hand tremor status; the eye state data includes eye tracking data, pupil response data, and eyelid closure degree; the first takeover decision model is trained based on an LSTM neural network according to the driver state sample and the corresponding takeover decision label; and the first takeover decision result is either takeover is possible or not.

[0010] Furthermore, in one embodiment of the present invention, the process of acquiring vehicle driving environment data and traffic condition data through roadside equipment, and then making a takeover decision based on the driving environment data and the traffic condition data to obtain a second takeover decision result: The driving environment data is acquired through roadside sensors, and the traffic condition data is acquired through a roadside V2X communication unit. The driving environment data and the traffic state data are input into a pre-trained second takeover decision model to obtain the second takeover decision result. The driving environment data includes weather conditions and road conditions, and the traffic conditions data includes traffic light status data, traffic flow density data, and surrounding vehicle trajectory data. The second takeover decision model is trained based on a convolutional neural network using driving environment samples, traffic conditions samples, and corresponding takeover decision labels. The second takeover decision result is either takeover is possible or not.

[0011] Furthermore, in one embodiment of the present invention, the step of acquiring the vehicle's driving status data and hardware status data through the vehicle terminal, and performing a takeover decision based on the driving status data and the hardware status data to obtain a third takeover decision result specifically includes: The driving status data is obtained through on-board sensors, and the hardware status data is obtained through the vehicle controller. The driving status data and the hardware status data are input into a pre-trained third takeover decision model to obtain the third takeover decision result. The driving status data includes vehicle speed, acceleration, yaw rate, and motor torque. The hardware status data includes radar point cloud quality, camera occlusion rate, and computing chip operating data. The third takeover decision model is trained based on gradient boosting decision tree based on driving status samples, hardware status samples, and corresponding takeover decision labels. The third takeover decision result is either takeover is possible or not.

[0012] Furthermore, in one embodiment of the present invention, the step of determining the takeover decision based on majority voting and Bayesian posterior probability according to the first takeover decision result, the second takeover decision result, and the third takeover decision result specifically includes: A majority voting vector is constructed based on the first takeover decision result, the second takeover decision result, and the third takeover decision result, and an initial judgment result is determined based on the majority voting vector. Based on historical autonomous driving data, determine the first prior probability of takeover capability and the second prior probability of non-takeover capability in autonomous driving scenarios. Determine the first conditional probability of the wearable monitoring device making a correct decision when takeover capability is possible, the second conditional probability of making an incorrect decision when takeover capability is possible, the third conditional probability of making a correct decision when non-takeover capability is possible, and the fourth conditional probability of making an incorrect decision when non-takeover capability is possible. Determine the fifth conditional probability of the roadside equipment making a correct decision when takeover capability is possible, the sixth conditional probability of making an incorrect decision when takeover capability is possible, the seventh conditional probability of making a correct decision when non-takeover capability is possible, and the eighth conditional probability of the vehicle-side equipment making a correct decision when takeover capability is possible, the tenth conditional probability of making an incorrect decision when takeover capability is possible, the eleventh conditional probability of making a correct decision when non-takeover capability is possible, and the twelfth conditional probability of the vehicle-side equipment making an incorrect decision when takeover capability is possible. Then, construct a likelihood probability matrix based on the first conditional probability to the twelfth conditional probability. The takeover posterior probability corresponding to the majority voting vector is calculated based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix. The takeover determination result is determined based on the initial determination result and the posterior probability of takeover.

[0013] Further, in one embodiment of the present invention, the step of calculating the takeover posterior probability corresponding to the majority voting vector based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix specifically includes: The first voting value of the wearable monitoring device, the second voting value of the roadside device, and the third voting value of the vehicle are determined based on the majority voting vector. If the first vote value is 1, the first conditional probability is determined to be the first probability factor and the fourth conditional probability is determined to be the second probability factor; if the first vote value is 0, the second conditional probability is determined to be the first probability factor and the third conditional probability is determined to be the second probability factor. If the second vote value is 1, the fifth conditional probability is determined to be the third probability factor and the eighth conditional probability is determined to be the fourth probability factor; if the second vote value is 0, the sixth conditional probability is determined to be the third probability factor and the seventh conditional probability is determined to be the fourth probability factor. If the third vote value is 1, the ninth conditional probability is determined to be the fifth probability factor and the twelfth conditional probability is determined to be the sixth probability factor; if the third vote value is 0, the tenth conditional probability is determined to be the fifth probability factor and the eleventh conditional probability is determined to be the sixth probability factor. The takeover conditional probability corresponding to the majority voting vector is determined by the product of the first probability factor, the third probability factor, and the fifth probability factor, and the non-takeover conditional probability corresponding to the majority voting vector is determined by the product of the second probability factor, the fourth probability factor, and the sixth probability factor. The joint probability of takeover corresponding to the majority voting vector is determined by the product of the takeover conditional probability and the first prior probability, and the joint probability of non-takeover corresponding to the majority voting vector is determined by the product of the non-takeover conditional probability and the second prior probability. The total probability corresponding to the majority voting vector is determined based on the sum of the takeover joint probability and the non-takeover joint probability, and the takeover posterior probability is determined based on the ratio of the takeover joint probability to the total probability.

[0014] Furthermore, in one embodiment of the present invention, determining the takeover determination result based on the initial determination result and the takeover posterior probability specifically includes: Determine the corresponding probability threshold based on the initial determination result; When the posterior probability of takeover is greater than or equal to the probability threshold, the takeover determination result is determined to be takeoverable; When the posterior probability of takeover is less than the probability threshold, the takeover determination result is determined to be untaken. Wherein, the probability threshold corresponding to the initial determination result being takeoverable is less than the probability threshold corresponding to the initial determination result being non-takeoverable.

[0015] On the other hand, embodiments of the present invention provide a vehicle takeover warning device for autonomous driving scenarios, comprising: The wearable monitoring device decision module is used to acquire the driver's physiological state data, behavioral state data, and eye state data through the wearable monitoring device, make a takeover decision based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, and send the first takeover decision result to the vehicle end. The roadside equipment decision module is used to acquire vehicle driving environment data and traffic condition data through roadside equipment, make a takeover decision based on the driving environment data and traffic condition data to obtain a second takeover decision result, and send the second takeover decision result to the vehicle end; The vehicle-side decision module is used to acquire the vehicle's driving status data and hardware status data through the vehicle terminal, make a takeover decision based on the driving status data and hardware status data to obtain a third takeover decision result, and determine the takeover judgment result based on the first takeover decision result, the second takeover decision result and the third takeover decision result, using majority voting and Bayesian posterior probability. The takeover alert and data upload module is used to issue a takeover alert based on the takeover determination result, and upload the physiological state data, behavioral state data, eye state data, driving environment data, traffic state data, driving state data, hardware state data, and takeover decision log to the cloud.

[0016] On the other hand, embodiments of the present invention provide an electronic device, including: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements the above-described vehicle takeover alert method in an autonomous driving scenario.

[0017] On the other hand, embodiments of the present invention also provide a computer-readable storage medium storing a processor-executable computer program that, when executed by a processor, implements the above-described vehicle takeover alert method in an autonomous driving scenario.

[0018] On the other hand, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the above-described vehicle takeover alert method in an autonomous driving scenario.

[0019] The advantages and beneficial effects of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention: This invention employs wearable monitoring devices to acquire driver physiological, behavioral, and eye condition data. Based on these data, a takeover decision is made to obtain a first takeover decision result, which is then sent to the vehicle. Roadside equipment acquires vehicle driving environment and traffic condition data, and a second takeover decision is made based on this data, also sent to the vehicle. The vehicle then acquires driving and hardware condition data, and a third takeover decision is made based on this data. Finally, a takeover judgment is determined using majority voting and Bayesian posterior probability, based on the first, second, and third takeover decisions. A takeover alert is issued based on the judgment result, and the physiological, behavioral, eye condition, driving environment, traffic, and hardware condition data, along with the takeover decision log, are uploaded to the cloud. In this embodiment of the invention, takeover decisions are made independently by wearable detection devices, roadside devices, and vehicle-side devices. Then, the takeover determination result is obtained based on majority voting and Bayesian posterior probability fusion. This reduces the risk of single device failure, improves the accuracy of takeover determination, and thus improves the safety of autonomous driving and the reliability of accident liability determination. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the embodiments of the present invention are described below. It should be understood that the drawings described below are only for the convenience of clearly describing some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating the steps of a vehicle takeover alert method in an autonomous driving scenario, as provided in an embodiment of the present invention; Figure 2 This is a structural block diagram of a vehicle takeover warning device in an autonomous driving scenario provided by an embodiment of the present invention; Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of this invention; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this invention as detailed in the appended claims.

[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein is for the purpose of describing embodiments of the invention only and is not intended to limit the invention.

[0024] The vehicle takeover alert method for autonomous driving scenarios provided in this invention can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or in-vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application that implements the vehicle takeover alert method for autonomous driving scenarios, but is not limited to the above forms.

[0025] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0026] It should be noted that in various specific embodiments of the present invention, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of the present invention require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to a confirmation page. Only after obtaining the user's separate permission or consent is the necessary user-related data for the normal operation of the embodiments of the present invention acquired.

[0027] Reference Figure 1 This invention provides a vehicle takeover alert method in an autonomous driving scenario, specifically including the following steps: S101. Obtain the driver's physiological state data, behavioral state data, and eye state data through wearable monitoring devices, make a takeover decision based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, and send the first takeover decision result to the vehicle terminal. S102. Obtain vehicle driving environment data and traffic condition data through roadside equipment, make a takeover decision based on the driving environment data and traffic condition data to obtain a second takeover decision result, and send the second takeover decision result to the vehicle terminal. S103. Obtain vehicle driving status data and hardware status data through the vehicle terminal, make a takeover decision based on the driving status data and hardware status data to obtain a third takeover decision result, and determine the takeover judgment result based on the first takeover decision result, the second takeover decision result and the third takeover decision result, using majority voting and Bayesian posterior probability. S104. Based on the takeover determination result, issue a takeover reminder and upload physiological status data, behavioral status data, eye status data, driving environment data, traffic status data, driving status data, hardware status data, and takeover decision log to the cloud.

[0028] In this embodiment of the invention, takeover decisions are made independently by wearable detection devices, roadside devices, and vehicle-side devices. Then, the takeover determination result is obtained based on majority voting and Bayesian posterior probability fusion. This reduces the risk of single device failure, improves the accuracy of takeover determination, and thus improves the safety of autonomous driving and the reliability of accident liability determination.

[0029] As a further optional implementation, the driver's physiological state data, behavioral state data, and eye state data are acquired through wearable monitoring devices. A takeover decision is then made based on these data to obtain a first takeover decision result, which specifically includes: S1011. Obtain physiological and behavioral data through a smartwatch and eye status data through smart glasses; S1012. Input physiological state data, behavioral state data, and eye state data into the pre-trained first takeover decision model to obtain the first takeover decision result; The physiological state data includes heart rate variability, blood oxygen saturation, and skin conductance; the behavioral state data includes hand movement data and hand tremor; and the eye state data includes eye tracking data, pupil response data, and eyelid closure. The first takeover decision model is trained on an LSTM neural network based on driver state samples and corresponding takeover decision labels. The first takeover decision result is either takeover is possible or not.

[0030] Specifically, wearable monitoring devices are implemented through smartwatches and smart glasses. Smartwatches are used to acquire physiological and behavioral data, while smart glasses are used to acquire eye condition data, as detailed below: 1) Physiological state data Heart rate variability (HRV): Heart rate variability is monitored using a PPG sensor to assess driver stress levels and fatigue. Blood oxygen saturation (SpO2): Real-time monitoring of blood oxygen levels to prevent drowsiness or cognitive decline caused by hypoxia; Electrical skin activity (EDA): Detects changes in skin conductivity to identify emotional fluctuations such as tension and anxiety.

[0031] 2) Behavioral state data Hand motion recognition: Detects whether the hand leaves the steering wheel using a 9-axis IMU sensor (in conjunction with a steering wheel sensor). Microtremor detection: Identifies subtle hand tremors caused by fatigue or medication. Gesture pattern analysis: Identify abnormal gestures such as repeated eye rubbing, covering the mouth, and other signs of fatigue.

[0032] 3) Eye condition data Eye tracking: Monitors eye movement trajectory and blink frequency using EOG sensors; Pupil response: Detects the speed at which the pupil reacts to changes in light to assess alertness; Eyelid closure: Identifying the PERCLOS (percentage of eyes closed per unit time) index.

[0033] The first takeover decision model is trained on an LSTM neural network based on driver state samples and corresponding takeover decision labels. Specifically, multiple driver state samples are determined based on historical autonomous driving data, and takeover decision labels are determined by manual annotation to form a training dataset. This dataset is then input into the LSTM neural network for training to obtain the first takeover decision model. The specific training process of the model will not be elaborated here.

[0034] As a further optional implementation, vehicle driving environment data and traffic condition data are acquired through roadside equipment, and a takeover decision is made based on the driving environment data and traffic condition data to obtain a second takeover decision result: S1021. Obtain driving environment data through roadside sensors and traffic condition data through roadside V2X communication units; S1022. Input the driving environment data and traffic state data into the pre-trained second takeover decision model to obtain the second takeover decision result; The driving environment data includes weather conditions and road conditions, while the traffic conditions data includes traffic light status data, traffic flow density data, and surrounding vehicle trajectory data. The second takeover decision model is trained based on a convolutional neural network using driving environment samples, traffic conditions samples, and corresponding takeover decision labels. The second takeover decision result is either takeover is possible or not.

[0035] Specifically, the roadside equipment is equipped with roadside sensors and roadside V2X communication units. The roadside sensors include roadside radar and roadside cameras, which are used to acquire weather condition data and road condition data. The roadside V2X communication units are used to communicate with all vehicles on the current road and road equipment such as traffic lights to acquire traffic light status data, traffic flow density data, and surrounding vehicle trajectory data.

[0036] The second takeover decision model is trained on a convolutional neural network based on driving environment samples, traffic condition samples, and corresponding takeover decision labels. Specifically, multiple driving environment samples and traffic condition samples are determined based on historical autonomous driving data, and takeover decision labels are determined by manual annotation to form a training dataset. This dataset is then input into the convolutional neural network for training to obtain the second takeover decision model. The specific training process of the model will not be elaborated here.

[0037] As a further optional implementation, vehicle driving status data and hardware status data are acquired through the vehicle terminal, and a third takeover decision is obtained based on the driving status data and hardware status data. This specifically includes: S1031. Obtain driving status data through vehicle-mounted sensors and obtain hardware status data through the vehicle controller; S1032. Input the driving status data and hardware status data into the pre-trained third takeover decision model to obtain the third takeover decision result. The driving status data includes vehicle speed, acceleration, yaw rate and motor torque, while the hardware status data includes radar point cloud quality, camera occlusion rate and computing chip operation data. The third takeover decision model is trained based on gradient boosting decision tree based on driving status samples, hardware status samples and corresponding takeover decision labels. The third takeover decision result is takeover is allowed or not.

[0038] Specifically, vehicle sensors acquire driving status data such as vehicle speed, acceleration, yaw rate, and motor torque, and may also include radar perception data and camera perception data. The vehicle controller acquires hardware status data such as radar point cloud quality, camera occlusion rate, and computing chip operating data.

[0039] The third takeover decision model is obtained by training a gradient boosting decision tree based on driving state samples, hardware state samples, and corresponding takeover decision labels. Specifically, multiple driving state samples and hardware state samples are determined based on historical autonomous driving data. Takeover decision labels are determined by manual annotation to form a training dataset. Then, a gradient boosting decision tree is initialized, and the residual of the gradient boosting decision tree is calculated using the training dataset. The residual is then used as the target value to train a new decision tree, and the gradient boosting decision tree is updated based on this decision tree. The third takeover decision model can be obtained through multiple iterations. The specific training process of the model is not described in detail here.

[0040] As a further optional implementation, the takeover decision is determined based on majority voting and Bayesian posterior probability according to the first takeover decision result, the second takeover decision result, and the third takeover decision result. Specifically, this includes: S1033. Construct a majority voting vector based on the first takeover decision, the second takeover decision, and the third takeover decision, and determine the initial judgment result based on the majority voting vector; S1034. Based on historical autonomous driving data, determine the first prior probability of takeover and the second prior probability of non-takeover in autonomous driving scenarios. Determine the first conditional probability of the wearable monitoring device making a correct judgment when takeover is possible, the second conditional probability of making an incorrect judgment when takeover is possible, the third conditional probability of making a correct judgment when non-takeover is not possible, and the fourth conditional probability of making an incorrect judgment when non-takeover is not possible. Determine the fifth conditional probability of the roadside equipment making a correct judgment when takeover is possible, the sixth conditional probability of making an incorrect judgment when takeover is possible, the seventh conditional probability of making a correct judgment when non-takeover is not possible, and the eighth conditional probability of the vehicle-side equipment making a correct judgment when takeover is possible, the tenth conditional probability of making an incorrect judgment when takeover is possible, the eleventh conditional probability of making a correct judgment when non-takeover is not possible, and the twelfth conditional probability of the vehicle-side equipment making an incorrect judgment when takeover is possible. Then, construct a likelihood probability matrix based on the first to twelfth conditional probabilities. S1035. Calculate the takeover posterior probability corresponding to the majority voting vector based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix. S1036. Determine the takeover decision result based on the initial decision result and the posterior probability of takeover.

[0041] Specifically, a majority voting vector is constructed based on the first takeover decision, the second takeover decision, and the third takeover decision. The vector format is V = [V1, V2, V3], where V1 represents the first vote value of the wearable monitoring device, V2 represents the second vote value of the roadside device, and V3 represents the third vote value of the vehicle. For example, the majority voting vector [1, 0, 1] indicates that the wearable monitoring device and the vehicle determine "takeover is possible", while the roadside device determines "takeover is not possible".

[0042] The initial judgment result is determined based on the majority voting vector. If at least two devices have a vote value of 1, that is, at least two of the wearable monitoring devices, roadside devices, and vehicle devices have a takeover decision result that is takeoverable, then the initial judgment result is determined to be "takeoverable"; otherwise, it is "not takeoverable".

[0043] Based on historical autonomous driving data, determine the first prior probability of takeover and the second prior probability of non-takeover in autonomous driving scenarios. For example, based on historical autonomous driving data, the first prior probability (takeover prior probability) P(A=1) is 0.7, and the corresponding second prior probability (non-takeover prior probability) P(A=0) is 0.3.

[0044] A likelihood probability matrix is ​​constructed based on historical autonomous driving data, fusing the conditional probabilities of the judgment results from various devices. An example is shown below: The first conditional probability (the probability that the wearable monitoring device makes the correct judgment when it is available for takeover) is P(V1=1|A=1)=0.9; The second conditional probability (the probability that the wearable monitoring device makes an incorrect judgment when it is available for takeover) is P(V1=0|A=1)=0.1; The third conditional probability (the probability that the wearable monitoring device makes the correct judgment when it cannot be taken over) is P(V1=0|A=0)=0.8; The fourth conditional probability (the probability that the wearable monitoring device makes an incorrect judgment when it is unmanageable) is P(V1=1|A=0)=0.2; The fifth conditional probability (the probability that the roadside equipment correctly determines when it is available for connection) is P(V²=1|A=1)=0.85; The sixth conditional probability (the probability that the roadside equipment makes an incorrect judgment when it is available for connection) is P(V2=0|A=1)=0.15; The seventh conditional probability (the probability that the roadside equipment makes the correct judgment when it cannot be connected) is P(V2=0|A=0)=0.9; The eighth conditional probability (the probability that the roadside equipment makes an incorrect judgment when it cannot be taken over) is P(V²=1|A=0)=0.1; The ninth conditional probability (the probability that the vehicle makes the correct judgment when it is capable of taking over) is P(V3=1|A=1)=0.95; The tenth conditional probability (the probability that the vehicle makes an incorrect judgment when it is capable of taking over) is P(V3=0|A=1)=0.05; The eleventh conditional probability (the probability that the vehicle makes the correct judgment when it cannot be taken over) is P(V3=0|A=0)=0.75; The twelfth conditional probability (the probability that the vehicle makes an incorrect judgment when it cannot be taken over) is P(V3=1|A=0)=0.25.

[0045] The likelihood probability matrix can be constructed based on the first to twelfth conditional probabilities mentioned above.

[0046] As a further optional implementation, the takeover posterior probability corresponding to the majority voting vector is calculated based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix. This specifically includes: S10351. Determine the first voting value of the wearable monitoring device, the second voting value of the roadside device, and the third voting value of the vehicle based on the majority voting vector; S10352. If the first vote value is 1, determine the first conditional probability as the first probability factor and the fourth conditional probability as the second probability factor. If the first vote value is 0, determine the second conditional probability as the first probability factor and the third conditional probability as the second probability factor. S10353. If the second vote value is 1, determine the fifth conditional probability as the third probability factor and the eighth conditional probability as the fourth probability factor. If the second vote value is 0, determine the sixth conditional probability as the third probability factor and the seventh conditional probability as the fourth probability factor. S10354. If the third vote value is 1, determine the ninth conditional probability as the fifth probability factor and the twelfth conditional probability as the sixth probability factor. If the third vote value is 0, determine the tenth conditional probability as the fifth probability factor and the eleventh conditional probability as the sixth probability factor. S10355. Determine the takeover conditional probability corresponding to the majority voting vector based on the product of the first probability factor, the third probability factor, and the fifth probability factor, and determine the non-takeover conditional probability corresponding to the majority voting vector based on the product of the second probability factor, the fourth probability factor, and the sixth probability factor. S10356. Determine the joint probability of takeover corresponding to the majority voting vector based on the product of the takeover conditional probability and the first prior probability, and determine the joint probability of non-takeover corresponding to the majority voting vector based on the product of the non-takeover conditional probability and the second prior probability. S10357. Determine the total probability corresponding to the majority voting vector based on the sum of the joint probability of takeover and the joint probability of non-takeover, and determine the posterior probability of takeover based on the ratio of the joint probability of takeover to the total probability.

[0047] Specifically, according to Bayes' theorem, the takeover posterior probability corresponding to the majority voting vector V is: P(A=1|V)=[P(V|A=1)×P(A=1)] / P(V); Where P(V|A=1) represents the takeover conditional probability corresponding to the majority voting vector V, P(A=1) represents the first prior probability (takeover prior probability), and P(V) represents the total probability corresponding to the majority voting vector V. P(V)=P(V|A=1)×P(A=1)+P(V|A=0)×P(A=0) Where P(V|A=0) represents the untaken control conditional probability corresponding to the majority voting vector V, and P(A=0) represents the second prior probability (untaken control prior probability).

[0048] First, the first voting value of the wearable monitoring device, the second voting value of the roadside device, and the third voting value of the vehicle are determined based on the majority voting vector. Then, based on the first, second, and third voting values, the first, third, and fifth probability factors for calculating the takeover conditional probability corresponding to the majority voting vector, and the second, fourth, and sixth probability factors for calculating the non-takeover conditional probability corresponding to the majority voting vector are determined.

[0049] Taking V=[1, 0, 1] as an example, the first and third votes are 1, and the second vote is 0. Therefore, the first probability factor is determined to be the first conditional probability P(V1=1|A=1), the third probability factor to be the sixth conditional probability P(V2=0|A=1), the fifth probability factor to be the ninth conditional probability P(V3=1|A=1), and the second probability factor to be the fourth conditional probability P(V1=1|A=0), the fourth probability factor to be the seventh conditional probability P(V2=0|A=0), and the sixth probability factor to be the twelfth conditional probability P(V3=1|A=0). The corresponding takeover conditional probabilities P(V|A=1) and non-takeover conditional probabilities P(V|A=0) can be expressed as follows: P(V|A=1)=P(V1=1|A=1)×P(V2=0|A=1)×P(V3=1|A=1); P(V|A=0)=P(V1=1|A=0)×P(V2=0|A=0)×P(V3=1|A=0).

[0050] Then, by consulting the likelihood probability matrix obtained in the previous steps, the following calculations can be performed: P(V|A=1)=0.9×0.15×0.95=0.128; P(V|A=0)=0.2×0.9×0.25=0.045.

[0051] Then, substituting the takeover conditional probability P(V|A=1), the non-takeover conditional probability P(V|A=0), the first prior probability P(A=1), and the second prior probability P(A=0) into the aforementioned formula for calculating the takeover posterior probability, we can obtain: P(A=1|V)=(0.128×0.7) / (0.128×0.7+0.045×0.3)≈0.87.

[0052] Therefore, the posterior probability of takeover corresponding to the majority voting vector V=[1, 0, 1] is 0.87.

[0053] As a further optional implementation, the takeover determination result is determined based on the initial determination result and the posterior probability of takeover, specifically including: S10361. Determine the corresponding probability threshold based on the initial judgment result; S10362. When the posterior probability of takeover is greater than or equal to the probability threshold, the takeover determination result is determined to be takeoverable. S10363. When the posterior probability of takeover is less than the probability threshold, the takeover decision is determined to be untaken. The probability threshold for an initial determination that the system is takeoverable is lower than the probability threshold for an initial determination that the system is not takeoverable.

[0054] Specifically, the corresponding probability threshold is determined based on the initial judgment result. For example, the probability threshold corresponding to the initial judgment result being takeoverable is preset to θ=0.6, and the probability threshold corresponding to the initial judgment result being non-takeoverable is preset to θ=0.9. If the posterior probability of takeoverable P(A=1|V)≥θ, then the final takeover judgment result is determined to be takeoverable; if the posterior probability of takeoverable P(A=1|V)<θ, then the final takeover judgment result is determined to be non-takeoverable.

[0055] Taking the majority voting vector V=[1, 0, 1] with a posterior probability of 0.87 that is takeoverable as an example, since the initial judgment result is takeoverable, the corresponding probability threshold is determined to be 0.6. Since P(A=1|V)=0.87≥0.6, the final judgment is "takeoverable".

[0056] It can be recognized that when the initial judgment obtained by majority voting conflicts with the Bayesian posterior probability judgment, the judgment result will be corrected by the Bayesian posterior probability. For example, if the initial judgment result is takeoverable, but the takeoverable posterior probability is less than the corresponding probability threshold (e.g., 0.55 < 0.6), the final takeover judgment result is not takeoverable. Or, if the initial judgment result is not takeoverable, but the takeoverable posterior probability is greater than or equal to the corresponding probability threshold (e.g., 0.91 ≥ 0.9), the final takeover judgment result is takeoverable.

[0057] This invention combines a voting mechanism of multi-source devices with a probability model. This "hardware redundancy + algorithm fault tolerance" design can effectively reduce the risk of single device failure, making the final "takeover / non-takeover" state determination more robust and reliable.

[0058] In some optional embodiments, when the takeover determination result is takeoverable, and the autonomous driving system determines that other takeover triggering conditions are met, a takeover reminder is issued to enable the driver to take over. At the same time, physiological state data, behavioral state data, eye state data, driving environment data, traffic state data, driving state data, hardware state data, and takeover decision log are uploaded to the cloud. The takeover decision log includes the decision logs of the first takeover decision result, the second takeover decision result, and the third takeover decision result, as well as the decision log of the takeover determination result.

[0059] It should be noted that data from wearable detection devices can be uploaded to the cloud via the vehicle; when uploading data from multiple devices to the cloud, hash calculations and the device's private key can be used for signing to prevent data tampering; in addition, the cloud can save the relevant data to the blockchain for post-accident scene reconstruction and liability determination.

[0060] The method steps of the embodiments of the present invention have been described above. It can be understood that the embodiments of the present invention first make takeover decisions independently through wearable detection devices, roadside devices, and vehicle-side devices, and then obtain the takeover determination result based on majority voting and Bayesian posterior probability fusion. This reduces the risk caused by the failure of a single device, improves the accuracy of the takeover determination, and thus improves the safety of autonomous driving and the reliability of accident liability determination.

[0061] Reference Figure 2 This invention provides a vehicle takeover warning device for autonomous driving scenarios, comprising: The wearable monitoring device decision module is used to acquire the driver's physiological state data, behavioral state data, and eye state data through the wearable monitoring device, make a takeover decision based on the physiological state data, behavioral state data, and eye state data to obtain the first takeover decision result, and send the first takeover decision result to the vehicle end. The roadside equipment decision module is used to acquire vehicle driving environment data and traffic condition data through roadside equipment, make takeover decisions based on the driving environment data and traffic condition data to obtain a second takeover decision result, and send the second takeover decision result to the vehicle end; The vehicle-side decision module is used to acquire vehicle driving status data and hardware status data through the vehicle terminal, make a takeover decision based on the driving status data and hardware status data to obtain a third takeover decision result, and determine the takeover judgment result based on the first takeover decision result, the second takeover decision result and the third takeover decision result, using majority voting and Bayesian posterior probability. The takeover alert and data upload module is used to issue takeover alerts based on the takeover determination results and upload physiological status data, behavioral status data, eye status data, driving environment data, traffic status data, driving status data, hardware status data, and takeover decision logs to the cloud.

[0062] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0063] Reference Figure 3 This invention provides an electronic device, comprising: At least one processor; At least one memory for storing at least one program; When the above-mentioned at least one program is executed by the above-mentioned at least one processor, the above-mentioned at least one processor implements the above-mentioned vehicle takeover warning method in an autonomous driving scenario.

[0064] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0065] This invention also provides a computer-readable storage medium storing a processor-executable computer program that, when executed by a processor, implements the aforementioned vehicle takeover alert method in an autonomous driving scenario.

[0066] This invention provides a computer-readable storage medium that can execute a vehicle takeover alert method in an autonomous driving scenario provided by an embodiment of the invention. It can execute any combination of the implementation steps of the method embodiment and has the corresponding functions and beneficial effects of the method.

[0067] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described vehicle takeover alert method in an autonomous driving scenario.

[0068] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0069] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0070] The embodiments described in this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems.

[0071] The terms "first," "second," "third," "fourth," etc. (if present) in the specification and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0072] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the aforementioned blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this invention are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0073] Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the aforementioned functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional skill of an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0074] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0075] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0076] More specific examples (a non-exhaustive list) of computer-readable media include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the aforementioned program can be printed, because the aforementioned program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0077] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0078] In the foregoing description of this specification, references to terms such as "one embodiment," "another embodiment," or "some embodiments" indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of the present invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0079] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0080] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of the present invention.

Claims

1. A vehicle takeover alert method in an autonomous driving scenario, characterized in that, Includes the following steps: The driver's physiological state data, behavioral state data, and eye state data are acquired through wearable monitoring devices. A takeover decision is made based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, which is then sent to the vehicle. The vehicle's driving environment data and traffic condition data are acquired through roadside equipment. A takeover decision is made based on the driving environment data and traffic condition data to obtain a second takeover decision result, which is then sent to the vehicle. The vehicle's driving status data and hardware status data are obtained through the vehicle terminal. A takeover decision is made based on the driving status data and hardware status data to obtain a third takeover decision result. The takeover judgment result is determined based on the first takeover decision result, the second takeover decision result, and the third takeover decision result, using majority voting and Bayesian posterior probability. Based on the takeover determination result, a takeover reminder is issued, and the physiological state data, behavioral state data, eye state data, driving environment data, traffic state data, driving state data, hardware state data, and takeover decision log are uploaded to the cloud.

2. The vehicle takeover alert method in an autonomous driving scenario according to claim 1, characterized in that, The process involves acquiring the driver's physiological state data, behavioral state data, and eye state data through wearable monitoring devices, and then making a takeover decision based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, which specifically includes: The physiological state data and behavioral state data are obtained through a smartwatch, and the eye state data is obtained through smart glasses; The physiological state data, the behavioral state data, and the eye state data are input into a pre-trained first takeover decision model to obtain the first takeover decision result; The physiological state data includes heart rate variability, blood oxygen saturation, and skin conductance; the behavioral state data includes hand movement data and hand tremor status; the eye state data includes eye tracking data, pupil response data, and eyelid closure degree; the first takeover decision model is trained based on an LSTM neural network according to the driver state sample and the corresponding takeover decision label; and the first takeover decision result is either takeover is possible or not.

3. The vehicle takeover alert method in an autonomous driving scenario according to claim 1, characterized in that, The process involves acquiring vehicle driving environment data and traffic condition data through roadside equipment, and then making a takeover decision based on the driving environment data and traffic condition data to obtain a second takeover decision result. The driving environment data is acquired through roadside sensors, and the traffic condition data is acquired through a roadside V2X communication unit. The driving environment data and the traffic state data are input into a pre-trained second takeover decision model to obtain the second takeover decision result. The driving environment data includes weather conditions and road conditions, and the traffic conditions data includes traffic light status data, traffic flow density data, and surrounding vehicle trajectory data. The second takeover decision model is trained based on a convolutional neural network using driving environment samples, traffic conditions samples, and corresponding takeover decision labels. The second takeover decision result is either takeover is possible or not.

4. The vehicle takeover alert method in an autonomous driving scenario according to claim 1, characterized in that, The process of acquiring vehicle driving status data and hardware status data via the vehicle terminal, and then making a takeover decision based on the driving status data and hardware status data to obtain a third takeover decision result, specifically includes: The driving status data is obtained through on-board sensors, and the hardware status data is obtained through the vehicle controller. The driving status data and the hardware status data are input into a pre-trained third takeover decision model to obtain the third takeover decision result. The driving status data includes vehicle speed, acceleration, yaw rate, and motor torque. The hardware status data includes radar point cloud quality, camera occlusion rate, and computing chip operating data. The third takeover decision model is trained based on gradient boosting decision tree based on driving status samples, hardware status samples, and corresponding takeover decision labels. The third takeover decision result is either takeover is possible or not.

5. The vehicle takeover alert method in an autonomous driving scenario according to claim 1, characterized in that, The step of determining the takeover decision based on majority voting and Bayesian posterior probability according to the first takeover decision result, the second takeover decision result, and the third takeover decision result specifically includes: A majority voting vector is constructed based on the first takeover decision result, the second takeover decision result, and the third takeover decision result, and an initial judgment result is determined based on the majority voting vector. Based on historical autonomous driving data, determine the first prior probability of takeover capability and the second prior probability of non-takeover capability in autonomous driving scenarios. Determine the first conditional probability of the wearable monitoring device making a correct decision when takeover capability is possible, the second conditional probability of making an incorrect decision when takeover capability is possible, the third conditional probability of making a correct decision when non-takeover capability is possible, and the fourth conditional probability of making an incorrect decision when non-takeover capability is possible. Determine the fifth conditional probability of the roadside equipment making a correct decision when takeover capability is possible, the sixth conditional probability of making an incorrect decision when takeover capability is possible, the seventh conditional probability of making a correct decision when non-takeover capability is possible, and the eighth conditional probability of the vehicle-side equipment making a correct decision when takeover capability is possible, the tenth conditional probability of making an incorrect decision when takeover capability is possible, the eleventh conditional probability of making a correct decision when non-takeover capability is possible, and the twelfth conditional probability of the vehicle-side equipment making an incorrect decision when takeover capability is possible. Then, construct a likelihood probability matrix based on the first conditional probability to the twelfth conditional probability. The takeover posterior probability corresponding to the majority voting vector is calculated based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix. The takeover determination result is determined based on the initial determination result and the posterior probability of takeover.

6. The vehicle takeover alert method in an autonomous driving scenario according to claim 5, characterized in that, The step of calculating the takeover posterior probability corresponding to the majority voting vector based on the majority voting vector, the first prior probability, the second prior probability, and the likelihood probability matrix specifically includes: The first voting value of the wearable monitoring device, the second voting value of the roadside device, and the third voting value of the vehicle are determined based on the majority voting vector. If the first vote value is 1, the first conditional probability is determined to be the first probability factor and the fourth conditional probability is determined to be the second probability factor; if the first vote value is 0, the second conditional probability is determined to be the first probability factor and the third conditional probability is determined to be the second probability factor. If the second vote value is 1, the fifth conditional probability is determined to be the third probability factor and the eighth conditional probability is determined to be the fourth probability factor; if the second vote value is 0, the sixth conditional probability is determined to be the third probability factor and the seventh conditional probability is determined to be the fourth probability factor. If the third vote value is 1, the ninth conditional probability is determined to be the fifth probability factor and the twelfth conditional probability is determined to be the sixth probability factor; if the third vote value is 0, the tenth conditional probability is determined to be the fifth probability factor and the eleventh conditional probability is determined to be the sixth probability factor. The takeover conditional probability corresponding to the majority voting vector is determined by the product of the first probability factor, the third probability factor, and the fifth probability factor, and the non-takeover conditional probability corresponding to the majority voting vector is determined by the product of the second probability factor, the fourth probability factor, and the sixth probability factor. The joint probability of takeover corresponding to the majority voting vector is determined by the product of the takeover conditional probability and the first prior probability, and the joint probability of non-takeover corresponding to the majority voting vector is determined by the product of the non-takeover conditional probability and the second prior probability. The total probability corresponding to the majority voting vector is determined based on the sum of the takeover joint probability and the non-takeover joint probability, and the takeover posterior probability is determined based on the ratio of the takeover joint probability to the total probability.

7. The vehicle takeover alert method in an autonomous driving scenario according to claim 5, characterized in that, The step of determining the takeover determination result based on the initial determination result and the takeover posterior probability specifically includes: Determine the corresponding probability threshold based on the initial determination result; When the posterior probability of takeover is greater than or equal to the probability threshold, the takeover determination result is determined to be takeoverable; When the posterior probability of takeover is less than the probability threshold, the takeover determination result is determined to be untaken. Wherein, the probability threshold corresponding to the initial determination result being takeoverable is less than the probability threshold corresponding to the initial determination result being non-takeoverable.

8. A vehicle takeover warning device for autonomous driving scenarios, characterized in that, include: The wearable monitoring device decision module is used to acquire the driver's physiological state data, behavioral state data, and eye state data through the wearable monitoring device, make a takeover decision based on the physiological state data, behavioral state data, and eye state data to obtain a first takeover decision result, and send the first takeover decision result to the vehicle end. The roadside equipment decision module is used to acquire vehicle driving environment data and traffic condition data through roadside equipment, make a takeover decision based on the driving environment data and traffic condition data to obtain a second takeover decision result, and send the second takeover decision result to the vehicle end. The vehicle-side decision module is used to acquire the vehicle's driving status data and hardware status data through the vehicle terminal, make a takeover decision based on the driving status data and hardware status data to obtain a third takeover decision result, and determine the takeover judgment result based on the first takeover decision result, the second takeover decision result and the third takeover decision result, using majority voting and Bayesian posterior probability. The takeover alert and data upload module is used to issue a takeover alert based on the takeover determination result, and upload the physiological state data, behavioral state data, eye state data, driving environment data, traffic state data, driving state data, hardware state data, and takeover decision log to the cloud.

9. An electronic device, characterized in that, include: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor implements a vehicle takeover alert method in an autonomous driving scenario as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements a vehicle takeover alert method in an autonomous driving scenario as described in any one of claims 1 to 7.