Driver fatigue detection method and system in online car-hailing scene

By analyzing driver order behavior and geographical information, dynamically setting fatigue thresholds and rest time, the problem of high cost and low accuracy of driver fatigue detection in the prior art is solved, and low cost and high accuracy driver fatigue monitoring is achieved.

CN120525291APending Publication Date: 2025-08-22BEIJING YUNXING ONLINE SOFTWARE DEV CO LTD
View PDF 6 Cites 0 Cited by

Patent Information

Application Number
CN202510981381.4
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-07-16
Publication Date
2025-08-22

AI Technical Summary

Technical Problem

In the prior art, driver fatigue detection relies on camera and image processing, and is costly and has low accuracy, making it difficult to effectively identify driver fatigue status.

Method used

By analyzing the driver's order behavior data and time and geographical information, dynamically set the fatigue time threshold and rest time, combining urban rules and individual fatigue laws, we can judge and remind the driver's fatigue status.

Benefits of technology

It realizes low-cost, non-invasive driver fatigue monitoring, improves the accuracy and adaptability of fatigue detection, reduces intrusion on driver privacy, and is suitable for vehicles that do not have advanced vehicle systems.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120525291A_ABST
    Figure CN120525291A_ABST
Patent Text Reader

Abstract

The invention relates to a driver fatigue detection method and system in an online car-hailing scene, and the method comprises the steps: carrying out the statistics of the active duration of a driver after a last rest period when a current order is finished; the active time length comprises the picking-up time length and the service time length with different weight ratios; determining a fatigue time threshold and default rest duration according to the current location and the current time; judging whether the active duration exceeds a fatigue duration threshold or not; if the active duration exceeds a fatigue duration threshold value, judging that the driver is in a fatigue state, performing fatigue driving reminding on the driver, stopping dispatching an order to the driver, and counting the inactive duration of the driver after the last rest period; the inactive duration comprises order listening duration and waiting duration; according to the default rest duration and the inactive duration, determining the rest duration required by the driver, and entering a rest period; and after the current rest period is ended, reminding the driver of ending the rest period, and returning to normal order sending for the driver.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the technical field of driver fatigue detection, and in particular to a driver fatigue detection method and system in an online car-hailing scenario. Background Art

[0002] In the ride-hailing industry, driver fatigue is a serious safety hazard. Existing fatigue detection methods primarily rely on cameras and image processing technology. For example, a camera captures images of the driver while driving. A facial detection module processes the captured images and determines the driver's fatigue level based on eye movements and / or behavior. Alternatively, data training and analysis of images of the driver while driving can be used to determine the driver's fatigue level through image comparison.

[0003] The existing method for judging driver fatigue requires real-time acquisition of images of the driver while driving, which has high acquisition costs and low accuracy in judging whether the driver is fatigued based on images. Summary of the Invention

[0004] In order to at least to some extent overcome the problem in related technologies of high cost and low accuracy in judging driver fatigue based on driver images, the present application provides a driver fatigue detection method and system in an online car-hailing scenario.

[0005] The scheme of this application is as follows: According to a first aspect of an embodiment of the present application, a method for detecting driver fatigue in an online ride-hailing scenario is provided, comprising: At the end of the current order, the driver's active time after the last rest period is counted; the active time includes the pick-up time and service time with different weight ratios; Determine fatigue time threshold and default rest time based on current location and current time; Determining whether the active duration exceeds the fatigue duration threshold; If the active time exceeds the fatigue time threshold, the driver is judged to be in a fatigued state, a fatigue driving reminder is issued to the driver, orders are stopped from being dispatched to the driver, and the driver's inactive time since the last rest period is counted; the inactive time includes: the time of listening for orders and the time of waiting for passengers; Determine the required rest time for the driver based on the default rest time and the inactive time, and enter the rest period; After the current rest period ends, the driver will be reminded that the rest period has ended and normal dispatching will resume for the driver.

[0006] Preferably, determining the fatigue duration threshold and the default rest duration according to the current location and the current time includes: Determine the driver's city based on the current location and obtain the safe driving rules configured in the driver's city; According to the current time, the fatigue duration threshold and default rest duration of the corresponding period are matched in the obtained safe driving rules.

[0007] Preferably, the method further comprises: Obtain the geographical data of the city and determine the diurnal and night-time variation patterns of the city based on the geographical data; Configure the city's default safe driving rules based on the city's diurnal and nighttime changes; The default safe driving rules are configured with fatigue duration thresholds and default rest durations for different time periods.

[0008] Preferably, the method further comprises: Obtain the city's traffic data and determine the city's traffic peak period based on the city's traffic data; Configure the first duration coefficient corresponding to the city's traffic peak period; Obtaining historical service data of the driver, inputting the historical service data of the driver into a character portrait model, and analyzing the fatigue pattern of the driver through the character portrait model; Determining the driver's fatigue period according to the driver's fatigue pattern, and configuring corresponding second duration coefficients for different fatigue levels of the driver during the fatigue period; Determine whether the current order is during the city's peak traffic period and / or the driver's fatigue period; If the current order is during the city's peak traffic period and / or the driver's fatigue period, the active duration corresponding to the current order is adjusted according to the first duration coefficient and / or the second duration coefficient.

[0009] Preferably, adjusting the active duration corresponding to the current order according to the first duration coefficient and / or the second duration coefficient includes: If the current order is only during the city's peak traffic period, the active duration corresponding to the current order will be adjusted according to the first duration coefficient; If the current order is only in the driver's fatigue period, the active time corresponding to the current order will be adjusted according to the second time coefficient; If the current order is in the city's peak traffic period and the driver's fatigue period, the larger value of the first duration coefficient and the second duration coefficient is selected to adjust the active duration corresponding to the current order.

[0010] Preferably, the method further comprises: If the start time and end time of the current order belong to the same period, the start time of the current order will be used as the statistical time; If the start and end times of the current order do not belong to the same time period, the start or end time of the current order that is closer to the time period boundary will be used as the statistical time; According to the statistical time, the fatigue duration threshold and the default rest duration of the corresponding time period are matched in the obtained safe driving rules.

[0011] Preferably, the method further comprises: If the active duration does not exceed the fatigue duration threshold, calculating the difference between the fatigue duration threshold and the active duration; If the difference between the fatigue duration threshold and the active duration is lower than a first preset value, stop dispatching orders to the driver; If the difference between the fatigue duration threshold and the active duration is higher than a first preset value and lower than a second preset value, the driver's available service mileage is calculated based on the difference between the fatigue duration threshold and the active duration, and the driver is dispatched based on the driver's available service mileage; If the difference between the fatigue duration threshold and the active duration is higher than a second preset value, the driver will be dispatched normally.

[0012] Preferably, the driver is assigned orders based on his available service mileage, including: Prioritize dispatching orders to drivers that match their available mileage among platform orders; If there is no order on the platform that matches the driver's serviceable mileage, orders with a lower serviceable mileage than the driver will be given priority for dispatching to the driver.

[0013] Preferably, determining the required rest time for the driver based on the default rest time and the inactive time includes: Calculating the difference between the default rest period and the inactive period; If the difference between the default rest period and the inactive period is lower than a third preset value; The difference between the default rest time and the inactive time is multiplied by the rest time coefficient to obtain the rest time required by the driver; If the difference between the default rest time and the inactive time is higher than a third preset value, the default rest time is directly used as the rest time required for the driver.

[0014] According to a second aspect of an embodiment of the present application, a driver fatigue detection system in an online car-hailing scenario is provided, comprising: processor and memory; The processor and the memory are connected via a communication bus: The processor is configured to call and execute the program stored in the memory; The memory is used to store a program, and the program is at least used for a driver fatigue detection method in an online car-hailing scenario as described in any one of the above items.

[0015] The technical solution provided by this application may have the following beneficial effects: This application proposes a "driver fatigue detection method for online ride-hailing scenarios." Unlike traditional fatigue detection technologies that rely on image recognition and physiological feature analysis, this method infers driver fatigue status through order behavior data and temporal and geographic information, enabling low-cost, non-invasive monitoring of driver fatigue risk. This technical solution eliminates the need for cameras or image recognition modules and can directly detect fatigue using the platform's existing order data and GPS positioning. This reduces intrusion on driver privacy and facilitates large-scale deployment. It is particularly suitable for vehicles without advanced onboard systems, enhancing the solution's universality and feasibility.

[0016] This application assigns different weights to the pick-up time and service time, which can more accurately reflect the driver's workload. The fatigue time threshold and rest time are set dynamically to adapt to the fatigue risk characteristics in different cities, different time periods, and different working environments. It is more adaptive and scalable than fixed thresholds. Compared with existing image recognition technology, this technical solution has a higher accuracy in judging driver fatigue. After identifying the fatigue state, it actively guides the driver to rest and interrupts the driver's fatigue driving through system intervention.

[0017] This technical solution determines the driver's required rest time based on the default rest duration and inactivity period, and then enters the rest period. While waiting for orders or passengers, drivers aren't working, but they're not actually resting either, so they can't be equated with actual rest time. This technical solution incorporates the driver's inactivity period as an auxiliary factor when determining the driver's required rest time, allowing for a more accurate assessment of the driver's rest time needed.

[0018] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0020] Figure 1 This is a flowchart of a method for detecting driver fatigue in an online ride-hailing scenario provided by one embodiment of the present application; Figure 2 This is a flowchart of a method for detecting driver fatigue in an online car-hailing scenario provided by another embodiment of the present application; Figure 3 This is a structural diagram of a driver fatigue detection system in an online car-hailing scenario provided by an embodiment of the present application.

[0021] Reference numerals: processor-21; memory-22. DETAILED DESCRIPTION

[0022] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0023] Example 1 Figure 1 This is a flowchart of a method for detecting driver fatigue in a ride-hailing scenario provided by an embodiment of the present application. Figure 1 , a driver fatigue detection method in an online car-hailing scenario, comprising: S11: At the end of the current order, the driver's active time after the last rest period is counted; the active time includes the pick-up time and service time with different weight ratios; In this technical solution, active time refers to the cumulative working time of the driver since the end of the last rest period before completing the current order. This active time consists of two parts: Pickup time: the time from receiving the order to navigating to the passenger's location; Service time: the time from when the passenger gets on the vehicle to when the trip is completed; Due to the different fatigue intensities in these two periods, different weight coefficients are set to more reasonably reflect the driver's actual fatigue load.

[0024] For example: The set weight ratio is: pick-up time weight: 0.6, service time weight: 1.0.

[0025] In the current order, the pick-up time is 10 minutes and the service time is 25 minutes. The driver's active time is (10×0.6 + 25×1.0) = 31 minutes.

[0026] If the raw time is simply added up (i.e., without weighting), the driver's active time is 35 minutes. After weighting, the fatigue load is 31 minutes, which more accurately reflects the relatively relaxed state during the pickup phase.

[0027] S12: determining a fatigue time threshold and a default rest time according to the current location and the current time; The fatigue duration threshold and default rest duration are determined based on the current location and time, including: Determine the driver's city based on the current location and obtain the safe driving rules configured in the driver's city; According to the current time, the fatigue duration threshold and default rest duration of the corresponding period are matched in the obtained safe driving rules.

[0028] The main purpose of this step is to dynamically adjust the fatigue judgment rules according to different cities and different time periods to adapt to regional differences, policy requirements, traffic environment and the actual work intensity of drivers.

[0029] For example: The platform identifies the driver’s current geographic location as “Shanghai” through the driver’s mobile phone or vehicle GPS positioning.

[0030] Example of safe driving rules (Shanghai):

[0031] The above data can be set by the transportation authority or platform based on historical driving safety data.

[0032] Current time: 08:30 At this time, the system matches according to the current time and rule table: The current time period is: 07:00–09:00; The fatigue duration threshold is: 90 minutes; The default break duration is 20 minutes.

[0033] If a driver starts accepting orders at 7:00 am and his total active time is 95 minutes by the end of the current order, the system will determine that he has exceeded the fatigue time threshold (90 minutes), activate the fatigue reminder mechanism, remind the driver to rest, and suspend order dispatch. The system will determine the rest time required by the driver based on the default rest time (20 minutes) and the driver's inactive time. Furthermore, the method further comprises: Obtain the geographical data of the city and determine the diurnal and night-time variation patterns of the city based on the geographical data; Configure the city's default safe driving rules based on the city's diurnal and nighttime changes; The default safe driving rules are configured with fatigue duration thresholds and default rest durations for different time periods.

[0034] This technical solution does not require manual setting of driving rules for each city. It can be dynamically generated based on geographical features, and takes into account the changes in day and night time caused by the latitude differences of cities, thereby improving the rationality of driving safety rules.

[0035] For example: During the summer in Guangzhou (a low-latitude city), sunrise is at 05:30 and sunset is at 19:00, which greatly extends the daylight hours. The system may set the following rules:

[0036] The system now allows drivers to have longer continuous working hours during the day, but nighttime restrictions remain strict.

[0037] S13: Determine whether the active duration exceeds the fatigue duration threshold; S14: If the active time exceeds the fatigue time threshold, the driver is judged to be in a fatigued state, a fatigue driving reminder is issued to the driver, orders are stopped from being dispatched to the driver, and the driver's inactive time since the last rest period is counted. The inactive time includes the time spent listening for orders and the time spent waiting for passengers. S15: Determine the required rest time for the driver based on the default rest time and the inactive time, and enter the rest period; S16: After the current rest period ends, the driver is reminded that the rest period has ended and normal dispatching of orders is resumed for the driver.

[0038] It should be noted that traditional technologies rely on cameras to capture images of the driver and infer fatigue status through visual features such as facial expressions, eye movement frequency, and eye closure time. However, this method often leads to recognition errors due to the following problems: Lighting changes, occlusions (such as sunglasses and masks), posture deviations, etc. can easily interfere with recognition; there are large differences in facial expressions between different individuals, and the model's generalization ability is insufficient; image processing results are highly dependent on real-time and model algorithms, resulting in reduced accuracy in mobile scenarios.

[0039] In contrast, this technical solution is based on the driver's real service behavior data (pickup, service) and platform positioning and dispatch records. It is not affected by image quality, hardware equipment or external environment, and has higher stability and adaptability.

[0040] This technical solution assigns different weights to pickup and service duration, more accurately reflecting the driver's workload. Fatigue duration thresholds and rest periods are dynamically set to adapt to fatigue risk characteristics in different cities, time periods, and working environments, making it more adaptable and scalable than fixed thresholds. Compared to existing image recognition technologies, this technical solution more accurately determines driver fatigue. After identifying fatigue, it proactively guides the driver to rest, interrupting fatigued driving through system intervention.

[0041] This technical solution determines the driver's required rest time based on the default rest duration and inactivity period, and then enters the rest period. While waiting for orders or passengers, drivers aren't working, but they're not actually resting either, so they can't be equated with actual rest time. This technical solution incorporates the driver's inactivity period as an auxiliary factor when determining the driver's required rest time, allowing for a more accurate assessment of the driver's rest time needed.

[0042] Example 2 It should be noted that the method also includes: Obtain the city's traffic data and determine the city's traffic peak period based on the city's traffic data; Configure the first duration coefficient corresponding to the city's traffic peak period; Obtain the driver's historical service data, input the driver's historical service data into the character portrait model, and analyze the driver's fatigue pattern through the character portrait model; Determining the driver's fatigue period according to the driver's fatigue pattern, and configuring corresponding second duration coefficients for different fatigue levels of the driver during the fatigue period; Determine whether the current order is during the city's peak traffic period and / or the driver's fatigue period; If the current order is during the city's peak traffic period and / or the driver's fatigue period, the active duration corresponding to the current order is adjusted according to the first duration coefficient and / or the second duration coefficient.

[0043] Furthermore, the active duration corresponding to the current order is adjusted according to the first duration coefficient and / or the second duration coefficient, including: If the current order is only during the city's peak traffic period, the active duration corresponding to the current order will be adjusted according to the first duration coefficient; If the current order is only in the driver's fatigue period, the active time corresponding to the current order will be adjusted according to the second time coefficient; If the current order is in the city's peak traffic period and the driver's fatigue period, the larger value of the first duration coefficient and the second duration coefficient is selected to adjust the active duration corresponding to the current order.

[0044] In this embodiment, the first duration coefficient of the urban traffic peak period is obtained: The system obtains traffic big data (such as the congestion index released by the traffic management bureau and the platform's own travel speed distribution) to identify urban traffic peak hours:

[0045] The first duration coefficient of 1.3 indicates that due to traffic congestion during this period, the driver's driving tasks are more arduous, and the calculated value of the active duration should be magnified.

[0046] Build a driver portrait model, obtain the driver's fatigue period, and set the second duration coefficient: The platform builds a character portrait model based on the driver's historical behavior data (such as the duration of continuous orders, order frequency, complaint / abnormality rate, night driving habits, etc.) to analyze their individual fatigue rhythm.

[0047] Example of driver fatigue period configuration:

[0048] Example of determining whether the current order is in the above high-risk period: Current example scene: Current time: 13:45; The current order is in: Beijing; The current order is during the driver's afternoon fatigue period (13:30–15:00); The current order is not during the peak traffic period, so only the second duration coefficient of 1.4 is used for adjustment.

[0049] The technical solution in this embodiment is described as follows: Assume that the original order structure is as follows: Pickup time: 10 minutes (weight 0.6); Service duration: 30 minutes (weight 1.0); Original weighted active time: 10×0.6+30×1.0=36 minutes; The active duration adjustment strategy is as follows: Case 1: The order is only during peak traffic hours (for example, the time is 08:30, using the first duration coefficient of 1.3). The adjusted active duration is: 36×1.3=46.8 minutes.

[0050] Case 2: The order is only in the fatigue period (as in the current example, using the second duration coefficient of 1.4). The adjusted active duration is: 36 × 1.4 = 50.4 minutes.

[0051] Case 3: The order is at both peak time and fatigue period (for example, the time is 18:00, and the driver is also at high fatigue period, the first coefficient is 1.2, the second coefficient is 1.5). Select the larger coefficient: max(1.2, 1.5)=1.5, and the adjusted active time is: 36 × 1.5 = 54 minutes.

[0052] The technical solution in this embodiment comprehensively considers environmental pressure (urban peak) and individual status (physiological fatigue), so that fatigue judgment no longer relies on static thresholds, but is based on a multi-dimensional dynamic evaluation model, which can more accurately reflect the driver's actual fatigue load.

[0053] Example 3 It should be noted that the method also includes: If the start time and end time of the current order belong to the same period, the start time of the current order will be used as the statistical time; If the start and end times of the current order do not belong to the same time period, the start or end time of the current order that is closer to the time period boundary will be used as the statistical time; According to the statistical time, the fatigue duration threshold and default rest duration of the corresponding period are matched in the obtained safe driving rules.

[0054] For example:

[0055] The current order time is 08:30–09:10. The start and end times are both in period A. Use the start time 08:30 for matching and apply the A period rules (fatigue threshold: 120 minutes, default rest: 25 minutes).

[0056] Current order time: 10:55–11:30, starting time is in period A, ending time is in period B, and the period boundary is 11:00; Determine which one is closer to the boundary: The start time is 5 minutes away from 11:00, and the end time is 30 minutes away from 11:00, that is, the start time is closer to the time period boundary.

[0057] Therefore: take the start time (10:55) as the statistical time, and apply the fatigue rules of period A (fatigue threshold: 120 minutes, default rest: 25 minutes).

[0058] Through this time period boundary judgment mechanism, for orders across time periods, priority is given to time points that better represent the driver's main activity pressure, avoiding unclear rules and judgment conflicts caused by multiple time period coverage, and enhancing the stability and logical closure of the entire fatigue detection model.

[0059] Example 4 It should be noted that, referring to Figure 2 , the method further comprises: S21: If the active duration does not exceed the fatigue duration threshold, calculate the difference between the fatigue duration threshold and the active duration; S22: If the difference between the fatigue duration threshold and the active duration is lower than a first preset value, stop dispatching orders to the driver; S23: If the difference between the fatigue duration threshold and the active duration is higher than a first preset value and lower than a second preset value, the driver's available service mileage is calculated based on the difference between the fatigue duration threshold and the active duration, and the driver is dispatched based on the available service mileage. S24: If the difference between the fatigue duration threshold and the active duration is higher than a second preset value, the driver is dispatched normally.

[0060] In specific practice, the first preset value can be set to 10 minutes, and the second preset value can be set to 30 minutes.

[0061] If the system sets the fatigue limit for this period to 120 minutes, the driver's current accumulated service time (after weighting) is 113 minutes; The difference between the fatigue time threshold and the active time is 7 minutes. If the difference is less than 10 minutes, the driver is considered to be close to fatigue and is about to exceed the threshold. At this time, no new orders will be dispatched and the system will stop dispatching orders.

[0062] For example, if the system sets the fatigue limit for this period to 120 minutes, and the driver's current accumulated service time (after weighting) is 95 minutes, the difference between the fatigue time threshold and the active time is 25 minutes. 25 minutes ∈ (10, 30), the difference is between 10–30 minutes, which falls into the "serviceable but restricted" range; the system calculates the service range (such as mileage or time) that the driver can still undertake based on the difference, and only matches orders with mileage within this range.

[0063] Assuming the average service time is 3 minutes per 1 km, the maximum service distance a driver can provide is: 25 / 3 ≈ 8.3 km. The system only dispatches orders with a distance of no more than 8 km.

[0064] If the system sets the fatigue limit for this period to 120 minutes, the driver's current accumulated service time (after weighting) is 60 minutes, and the difference between the fatigue time threshold and the active time is 60 minutes, 60>30, indicating that the fatigue margin is large and the driver is currently in a low-load state. The system allocates orders according to the normal dispatching process and no additional control is required.

[0065] This technical solution not only ensures drivers’ healthy driving, but also avoids reducing platform efficiency due to premature cessation of dispatching orders.

[0066] Dispatching drivers based on their available mileage, including: Prioritize dispatching orders to drivers that match their available mileage among platform orders; If there is no order on the platform that matches the driver's serviceable mileage, orders with a lower serviceable mileage than the driver will be given priority for dispatching to the driver.

[0067] The system's order dispatching strategy is as follows: Prioritize matching orders with mileage equal to the available service mileage: Ensure drivers can complete the task within the fatigue threshold; If there is no order of equal value, the order with a lower value will be selected: this further ensures that the driver will not exceed the limit during the execution process; Orders exceeding the serviceable mileage will not be dispatched to avoid the risk of excessive driving fatigue.

[0068] Example 5 It should be noted that the rest time required by the driver is determined based on the default rest time and inactive time, including: Calculate the difference between the default rest time and the inactive time; If the difference between the default rest time and the inactive time is lower than the third preset value; Multiply the difference between the default rest time and the inactive time by the rest time coefficient to get the driver's required rest time; If the difference between the default rest time and the inactive time is higher than the third preset value, the default rest time will be directly used as the rest time required for the driver.

[0069] When a driver is fatigued, the system will require them to rest. However, in reality, the driver may have been inactive (e.g., waiting for orders for a long time, not receiving orders, or the vehicle not moving) long before the system detects fatigue.

[0070] Therefore, it is necessary to consider whether the driver has already had a partial rest and whether the rest period needs to be reduced or a full rest period needs to be made up.

[0071] In actual practice, the rest time coefficient can be set to 1.2. If the default rest time is 20 minutes, the third preset value is set to 16 minutes.

[0072] For example: The default rest time is 20 minutes, and the driver's inactive time is 10 minutes. The difference between the default rest time and the inactive time is 10, and 10 < 16. Therefore, the rest time required for the driver is (20-10) * 1.2 = 12 minutes.

[0073] The default rest time is 20 minutes, and the driver's inactive time is 3 minutes. The difference between the default rest time and the inactive time is 17, and 17>16. At this time, the rest time required for the driver calculated based on the time coefficient is 20.4, which obviously exceeds the default rest time, so it is necessary to use the third preset value to limit it. In this case, the default rest time is directly used as the rest time required for the driver.

[0074] In this embodiment, the balance between driver experience and system utilization is improved by fine-tuning the rest period, which neither ignores the necessity of rest nor avoids waste of resources.

[0075] Example 6 A driver fatigue detection system in the online car-hailing scenario, referring to Figure 3 ,include: Processor 31 and memory 32; The processor 31 and the memory 32 are connected via a communication bus: The processor 31 is used to call and execute the program stored in the memory 32; The memory 32 is used to store programs, and the programs are used to execute at least a driver fatigue detection method in an online car-hailing scenario as described in any of the above embodiments.

[0076] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0077] It should be noted that, in the description of this application, the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In addition, in the description of this application, unless otherwise specified, the meaning of "plurality" refers to at least two.

[0078] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0079] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having logic gate circuits for implementing logic functions on data signals, an application-specific integrated circuit having suitable combinational logic gate circuits, a programmable gate array (PGA), a field-programmable gate array (FPGA), etc.

[0080] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0081] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0082] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0083] Throughout this specification, reference to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that a specific feature, structure, material, or characteristic described in conjunction with that embodiment or example is included in at least one embodiment or example of the present application. In this specification, schematic representations 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 any one or more embodiments or examples.

[0084] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A driver fatigue detection method in a ride-hailing scenario, characterized in that: include: At the end of the current order, the driver's active time after the last rest period is counted; The active duration includes the pick-up duration and service duration with different weight ratios; Determine fatigue time threshold and default rest time based on current location and current time; Determining whether the active duration exceeds the fatigue duration threshold; If the active time exceeds the fatigue time threshold, the driver is judged to be in a fatigued state, a fatigue driving reminder is issued to the driver, dispatching orders to the driver is stopped, and the driver's inactive time since the last rest period is counted; The inactive time includes: the time of waiting for orders and the time of waiting for customers; Determine the required rest time for the driver based on the default rest time and the inactive time, and enter the rest period; After the current rest period ends, the driver will be reminded that the rest period has ended and normal dispatching will resume for the driver.

2. The method according to claim 1, characterized in that The fatigue duration threshold and default rest duration are determined based on the current location and time, including: Determine the driver's city based on the current location and obtain the safe driving rules configured in the driver's city; According to the current time, the fatigue duration threshold and default rest duration of the corresponding period are matched in the obtained safe driving rules.

3. The method according to claim 2, characterized in that The method further comprises: Obtain the geographical data of the city and determine the diurnal and night-time variation patterns of the city based on the geographical data; Configure the city's default safe driving rules based on the city's diurnal and nighttime changes; The default safe driving rules are configured with fatigue duration thresholds and default rest durations for different time periods.

4. The method according to claim 1, wherein The method further comprises: Obtain the city's traffic data and determine the city's traffic peak period based on the city's traffic data; Configure the first duration coefficient corresponding to the city's traffic peak period; Obtaining historical service data of the driver, inputting the historical service data of the driver into a character portrait model, and analyzing the fatigue pattern of the driver through the character portrait model; Determining the driver's fatigue period according to the driver's fatigue pattern, and configuring corresponding second duration coefficients for different fatigue levels of the driver during the fatigue period; Determine whether the current order is during the city's peak traffic period and / or the driver's fatigue period; If the current order is during the city's peak traffic period and / or the driver's fatigue period, the active duration corresponding to the current order is adjusted according to the first duration coefficient and / or the second duration coefficient.

5. The method according to claim 4, characterized in that The active duration corresponding to the current order is adjusted according to the first duration coefficient and / or the second duration coefficient, including: If the current order is only during the city's peak traffic period, the active duration corresponding to the current order will be adjusted according to the first duration coefficient; If the current order is only in the driver's fatigue period, the active time corresponding to the current order will be adjusted according to the second time coefficient; If the current order is in the city's peak traffic period and the driver's fatigue period, the larger value of the first duration coefficient and the second duration coefficient is selected to adjust the active duration corresponding to the current order.

6. The method according to claim 3, characterized in that The method further comprises: If the start time and end time of the current order belong to the same period, the start time of the current order will be used as the statistical time; If the start and end times of the current order do not belong to the same time period, the start or end time of the current order that is closer to the time period boundary will be used as the statistical time; According to the statistical time, the fatigue duration threshold and the default rest duration of the corresponding time period are matched in the obtained safe driving rules.

7. The method according to claim 1, characterized in that The method further comprises: If the active duration does not exceed the fatigue duration threshold, calculating the difference between the fatigue duration threshold and the active duration; If the difference between the fatigue duration threshold and the active duration is lower than a first preset value, stop dispatching orders to the driver; If the difference between the fatigue duration threshold and the active duration is higher than a first preset value and lower than a second preset value, the driver's available service mileage is calculated based on the difference between the fatigue duration threshold and the active duration, and the driver is dispatched based on the driver's available service mileage; If the difference between the fatigue duration threshold and the active duration is higher than a second preset value, the driver will be dispatched normally.

8. The method according to claim 7, characterized in that Dispatching drivers based on their available mileage, including: Prioritize dispatching orders to drivers that match their available mileage among platform orders; If there is no order on the platform that matches the driver's serviceable mileage, orders with a lower serviceable mileage than the driver will be given priority for dispatching to the driver.

9. The method according to claim 1, characterized in that Determine the required rest time for the driver based on the default rest time and the inactive time, including: Calculating the difference between the default rest period and the inactive period; If the difference between the default rest period and the inactive period is lower than a third preset value; The difference between the default rest time and the inactive time is multiplied by the rest time coefficient to obtain the rest time required by the driver; If the difference between the default rest time and the inactive time is higher than a third preset value, the default rest time is directly used as the rest time required for the driver.

10. A driver fatigue detection system in a ride-hailing scenario, characterized by: include: processor and memory; The processor and the memory are connected via a communication bus: The processor is configured to call and execute the program stored in the memory; The memory is used to store a program, and the program is at least used to execute a driver fatigue detection method in an online car-hailing scenario as described in any one of claims 1-9.

Citation Information

Patent Citations

  • Online car-hailing service management method and device, electronic equipment and readable storage medium

    CN112381505A

  • Fatigue calculation method and device, order dispatching method and equipment, and storage medium

    CN113764082A

  • Privacy calculation system and method for total driving duration of online car-hailing driver and application

    CN114722093A

  • Fatigue driving identification method and device for highway vehicle driver and storage medium

    CN117558122A

  • Method and system for calculating driver service order duration in real time based on Flink

    CN119338297A