Vehicle control system

Abstract

The present invention provides a vehicle control device that can suggest to the driver that they take a break when certain conditions are met, and that determines whether or not the conditions are met without using the driver's biometric information. [Solution] The processor of the vehicle control device determines, based on map data configured to distinguish between a first area consisting of public roads and a second area consisting of other areas, that the current location is included in the first area and assumes that the driver is driving. The processor acquires the duration of this state as driving time and stores this driving time as driving history. When the driver starts driving again, the processor acquires a rest suggestion timing, which is the timing at which the next rest suggestion process should be executed, based on the first driving time, which is the duration of the previous drive; the rest time, which is the time the driver rested immediately after the previous drive; and the second driving time, which is the total of the driver's driving time from a predetermined point in the past to the present.

Description

[Technical Field]

[0001] The present invention relates to a vehicle control device having a function of proposing to a vehicle driver that the driver interrupt driving and take a break. [Background Art]

[0002] A vehicle control device including a function of proposing to a vehicle driver that the driver interrupt driving and take a break (a break proposal function) has been proposed (see, for example, Patent Document 1 below). This device (hereinafter referred to as "conventional device") includes a sensor that acquires biological information of the driver. The conventional device acquires the fatigue level of the driver based on the biological information, and causes an image display device to display the position of a nearby rest facility when the fatigue level exceeds a threshold value. [Prior Art Documents] [Patent Documents]

[0003] [Patent Document 1] Japanese Unexamined Patent Application Publication No. 2023-172749 [Summary of the Invention]

[0004] As described above, the conventional device acquires the biological information of the driver using a sensor. Here, the biological information of the driver is personal information. Therefore, there are cases where the driver does not permit the acquisition of biological information by the sensor. In this case, the driver cannot use the break proposal function.

[0005] One object of the present invention is to provide a vehicle control device capable of proposing to a driver to take a break when a predetermined condition is satisfied, wherein the vehicle control device determines whether the condition is satisfied without using biological information of the driver.

[0006] In order to achieve the above object, the vehicle control device (1) of the present invention: A vehicle control device comprising a processor (30, 10) configured to perform a rest suggestion process that controls a predetermined notification device (20) so that when predetermined conditions are met, information is provided to the driver of the vehicle prompting them to stop driving and take a rest, Includes a position sensor for sequentially acquiring the current location of the vehicle, The processor determines, based on map data (MD) configured to distinguish between a first region (Ra) consisting of public roads and a second region (Rb) consisting of other areas, that the current location is included in the first region, and assumes that the driver is driving. The time during which this state continues is obtained as driving time (DT), and this driving time is stored as driving history (HST). When the driver starts driving again, the processor obtains a rest suggestion timing (Tc) as the timing (Tc) at which the next rest suggestion process should be executed, based on the first driving time (DT1), which is the duration of the previous drive; the rest time (RT1), which is the time the driver rested immediately after the previous drive; and the second driving time (DT2), which is the total driving time of the driver during the period (T) from a predetermined past time (Tb) to the present time (T0). The processor determines that the predetermined conditions have been met when the current time reaches the rest suggestion timing.

[0007] The vehicle control device according to the present invention determines the timing of the next rest suggestion based on the driving time and rest time within a predetermined period. In other words, according to the present invention, the success or failure of the conditions for executing a rest suggestion is determined without using the driver's biometric information. Therefore, even drivers who do not permit the vehicle control device to acquire biometric information (personal information) can use the rest suggestion function. In addition, generally, when driving and resting are repeated, drivers may have difficulty realizing that fatigue is accumulating or that their fatigue level is increasing. The vehicle control device determines the timing of the rest suggestion based not only on the first driving time, which is the duration of the previous driving session, and the rest time immediately following it, but also on the total driving time within a predetermined period (including the previous driving period). As a result, the rest suggestion is executed at an appropriate time, taking into account the increasing fatigue level that the driver may have difficulty realizing.

[0008] In a vehicle control device according to one aspect of the present invention, The processor selects the larger of two values: the value obtained by multiplying the rest time by a predetermined first coefficient (k1) and subtracting that value from the first operating time, and the value obtained by dividing the second operating time by a predetermined second coefficient (k2). The processor then obtains the time at which the time obtained by subtracting the selected value from a predetermined standard time has elapsed from the present moment as the suggested rest timing.

[0009] According to this, the processor can determine the timing of the next break suggestion by performing relatively simple calculations.

[0010] In another aspect of the present invention, a vehicle control device, The processor, when a destination is set, obtains a route (R) from the current location to the destination, estimates the point the vehicle will reach at the suggested rest time when the vehicle proceeds along the route from the current location, and if the distance from the estimated point to a first facility where the vehicle can be parked exceeds a threshold, it refers to the map data to search for a second facility that is closer than the first facility, and executes the suggested rest process when the vehicle reaches a predetermined point before the second facility.

[0011] For example, if a rest stop is suggested immediately after passing a rest stop while driving on a highway, the next rest stop may be relatively far away, potentially resulting in a longer driving time. The present invention can prevent such a situation from occurring.

[0012] In another aspect of the present invention, a vehicle control device, The processor, at the suggested rest timing, acquires a route (R) to a facility where the vehicle can be parked and displays the route on a predetermined display device.

[0013] According to this, when the vehicle control system suggests taking a break, the driver can avoid the hassle of operating the navigation system or other means to search for a rest facility. In other words, the driver can reach the rest facility by driving their vehicle along the route displayed on the display device. [Brief explanation of the drawing]

[0014] [Figure 1] Figure 1 is a block diagram of a vehicle control device according to one embodiment of the present invention. [Figure 2] Figure 2 is a conceptual diagram of driving history data, which is a record of driving time and rest time. [Figure 3] Figure 3 is a flowchart of the first program executed by the CPU to implement the break suggestion function. [Figure 4] Figure 4 is a flowchart of the second program executed by the CPU to implement the break suggestion function. [Figure 5] Figure 5 is a flowchart of the third program executed by the CPU to implement the break suggestion function. [Figure 6] Figure 6 is a block diagram of a modified vehicle control device according to the present invention.

[0015] (Summary) A vehicle control device 1 according to one embodiment of the present invention is applied to a vehicle V0 equipped with an automatic driving function (hereinafter referred to as "the vehicle"). The vehicle control device 1 includes a rest suggestion function that suggests to the driver to interrupt driving and take a break when the automatic driving function of the vehicle is disabled and the driver is performing manual driving operations, and when predetermined conditions are met.

[0016] (Specific configuration) Next, the configuration of the vehicle control device 1 will be described in detail. As shown in Figure 1, the vehicle control device 1 includes an ECU 10 and a notification device 20 as devices mounted on the vehicle. Furthermore, the vehicle control device 1 includes a smartphone 30 as a device carried by the driver.

[0017] The ECU 10 includes a microcomputer (SOC) provided with a CPU 10a, a ROM 10b, a RAM 10c, a timer 10d, and the like. Furthermore, the ECU 10 includes a communication device 10e. The communication device 10e complies with a predetermined short-range wireless communication protocol (for example, Bluetooth (registered trademark)), and is connected to a smartphone 30 described later via a wireless communication line.

[0018] The notification device 20 includes a display device and an audio device. The display device displays an image in accordance with a display command acquired from the ECU 10. The audio device reproduces audio in accordance with an audio reproduction command acquired from the ECU 10.

[0019] The smartphone 30 includes a microcomputer including a CPU, a ROM, a RAM, a timer, and the like. Here, the timer is configured from a plurality of timer circuits (timers Tα, Tβ, Tγ described later), and can simultaneously measure a plurality of types of time. Furthermore, the smartphone 30 is provided with a communication device, an image display device, an audio device, a touch panel, and the like. A predetermined break proposal application is installed in the ROM of the smartphone 30.

[0020] (Break Proposal Function) When the driver activates the rest suggestion application on the smartphone 30 and gets into the vehicle with the smartphone 30 in their possession, the smartphone 30 connects to the ECU 10 via a wireless communication line. In this state, the smartphone 30 acquires GPS signals from multiple GPS satellites and obtains the current location P (latitude and longitude) of the smartphone 30 based on these GPS signals. The rest suggestion application also includes map data MD. The map data MD includes information representing the areas Ra and Rb occupied by public roads and other areas (rest facilities where the vehicle can be parked). The smartphone 30 refers to the map data to identify the area (public roads / other areas) that includes the current location P. When the smartphone 30 is connected to the ECU 10 via a wireless communication line, if the current location P is included in area Ra (public roads), the smartphone 30 assumes that the driver is driving the vehicle. Also, when the current location P is included in area Rb (rest facilities), the smartphone 30 assumes that the driver has stopped driving and is taking a rest. When the smartphone 30 is connected to the ECU 10 via a wireless communication line, it determines that the driver has started driving when the current location P enters area Ra from area Rb. Also, when the smartphone 30 is connected to the ECU 10 via a wireless communication line, it determines that the driver has stopped driving and started taking a break when the current location P enters area Rb from area Ra. Note that when the smartphone 30 is not connected to the ECU 10 via a wireless communication line, it assumes that the driver has gotten out of the vehicle and is taking a break. The smartphone 30 may also determine that the driver has started taking a break when the time the current location P remains stationary within area Rb exceeds a threshold. Furthermore, the smartphone 30 may sequentially acquire shift position information from the ECU 10 within area Rb, and based on this information, determine that the driver has started taking a break when it detects that the vehicle's shift position has transitioned to the parking position. The smartphone 30 measures the duration of the driver's driving state (time from the start of driving to the start of a break) using timer Tα, and acquires the measurement result as driving time DT (see Figure 2).In addition, the smartphone 30 measures the duration of the driver's rest period (time from the start of the rest to the start of driving) using a timer Tβ, and acquires the measurement result as a rest time RT. Every time the smartphone 30 acquires a driving time DT and a rest time RT, it stores them as driving history data HST.

[0021] Incidentally, the longer the continuous driving time of the driver (driving time DT), the higher the driver's fatigue level. Therefore, when the driving time DT increases to a certain extent, it is preferable that the driver interrupts driving to take a rest. Even if the driver interrupts driving to take a rest, if the rest time is insufficient, there is a risk that the driver's fatigue will not be sufficiently recovered. In addition, the longer the total driving time in the period T from a predetermined past time point to the current time point, the easier it is for the driver's fatigue level to increase, so it is preferable to shorten the subsequent driving time DT (increase the frequency of rests).

[0022] Accordingly, the smartphone 30 executes a rest suggestion process for suggesting to interrupt driving and take a rest when a predetermined condition regarding the driver's continuous driving time (driving time DT) and the driver's continuous rest time (rest time RT) is satisfied. Specifically, at time point T0 (see FIG. 2) when it is determined that the driver has started driving, the smartphone 30 refers to the driving history data HST and acquires the duration of the previous driving as a driving time DT1. Further, the smartphone 30 refers to the driving history data HST and acquires the time from the time point Ta when the previous driving was interrupted and the rest started to the current time point (time point T0) as a rest time RT1. Furthermore, the smartphone 30 acquires the total of each driving time DT from a predetermined past time point Tb to the current time point T0 as a driving time DT2.

[0023] At time T0, the smartphone 30 obtains time Tx by subtracting the value obtained by multiplying the rest time RT1 by a predetermined coefficient k1 from the driving time DT1. If the time Tx obtained as a result of this calculation is less than "0", the smartphone 30 considers time Tx to be "0". The smartphone 30 also obtains time Ty by dividing the driving time DT2 by a predetermined coefficient k2. Next, the smartphone 30 compares time Tx and time Ty. Next, the smartphone 30 obtains time Tz (=Max[Tx,Ty]) as the larger of time Tx and time Ty. Then, the smartphone 30 obtains the value obtained by subtracting time Tz from the standard time Tstd as the remaining time Δt (=Tstd-Max[Tx,Ty]) from the current time T0 (the time when it is determined that the driver has started driving) to the timing Tc when the next rest suggestion process will be executed. In other words, the smartphone 30 is configured to, in principle, execute the next rest suggestion process when a predetermined standard time Tstd has elapsed from time T0. However, if the rest time RT1 is insufficient for the driving time DT1, the timing Tc is advanced by a time Tx corresponding to the shortfall. However, if the driving time DT2, which is the total driving time DT during the period T (the period from time Tb to time T0), is relatively large, the driver's fatigue level is likely to increase. Therefore, the smartphone 30 compares the time Ty corresponding to the driving time DT2 with time Tx, and if time Ty is greater than time Tx, the timing Tc is advanced by that time Ty.

[0024] At time T0, the smartphone 30 assigns the remaining time Δt to the output value tγ of timer Tγ and operates timer Tγ as a countdown timer. Then, at time Tc, when the output value tγ of timer Tγ becomes "0", the smartphone 30 executes the rest suggestion process. Specifically, the smartphone 30 transmits a predetermined notification command to the ECU 10 via the wireless communication line. When the ECU 10 receives the notification command, it transmits an image display command to the display device of the notification device 20 to display a predetermined rest suggestion image G, and also transmits an audio playback command to the audio device of the notification device 20 to play a predetermined rest suggestion audio S.

[0025] In this embodiment, the length of the period T from time Tb to the current time T0 is "12 hours". The standard time Tstd is "180 minutes". The coefficient k1 is "6" and the coefficient k2 is "5".

[0026] (Specific example 1) For example, if the driving time DT1 is "180 minutes" and the rest time RT1 is "30 minutes", then the time Tx is "0 = 180 - 30 × 6 minutes". In other words, in this case, the rest time RT1 is considered sufficient for the driving time DT1. Now, if the driving time DT2 is the same as the driving time DT1, which is "180 minutes", then the time Ty is "36 minutes". In this example, since the time Tx is "0", the time Ty is greater than the time Tx. Therefore, the remaining time Δtrest at time T0 is "144 = 180 - 36 minutes".

[0027] (Specific example 2) For example, if the driving time DT1 is "180 minutes" and the rest time RT1 is "20 minutes", then the time Tx will be "60 minutes". In this case, the rest time RT1 is considered insufficient for the driving time DT1. Now, if the driving time DT2 is the same as the driving time DT1, which is "180 minutes", then the time Ty will be "36 minutes". In this example, since the time Tx is "60 minutes", the time Tx is greater than the time Ty. Therefore, the remaining time Δtrest at time T0 is "120 = 180 - 60 minutes".

[0028] (Specific example 3) For example, if the driving time DT1 is "120 minutes" and the rest time RT1 is "60 minutes", then time Tx will be "0 minutes". In this case, the rest time RT1 is considered sufficient for the driving time DT1. Now, if the driving time DT2 is "360 minutes", then time Ty will be "72 minutes". In this example, since time Tx is "0 minutes", time Tx is greater than time Tx. Therefore, the remaining time Δtrest at time T0 is "108 = 180 - 72 minutes".

[0029] Next, the configuration of the rest suggestion application will be described with reference to Figures 3 to 5. The rest suggestion application includes programs PR1 to PR3. When the smartphone 30 is powered on, the CPU of the smartphone 30 (hereinafter simply referred to as "CPU") displays the icon for the rest suggestion application on the home screen. When the CPU detects that the icon has been tapped, it starts the rest suggestion application and executes programs PR1 to PR3 at predetermined intervals (parallel processing). The CPU also executes other programs (not shown) to sequentially determine whether it is possible to connect to the ECU 10 via the wireless communication line. If it is possible to connect to the ECU 10, the CPU executes a predetermined authentication process and establishes the wireless communication connection. On the other hand, if it is not possible to connect to the ECU 10, the CPU determines that the driver has gotten out of the vehicle V0 and is taking a rest.

[0030] (Program PR1) The CPU starts executing program PR1 from step 100 and proceeds to step 101.

[0031] In step 101, the CPU determines whether the driver has started driving. The CPU determines that driving has started if the smartphone 30 is connected to the ECU 10 and the current location P transitions from being in an area other than area Ra to being in area Ra (public road). If the CPU determines that the driver has started driving (101: Yes), it proceeds to step 102. On the other hand, if the CPU does not determine that the driver has started driving (101: No), it returns to step 101.

[0032] In step 102, the CPU sets (initializes) the output value tα of timer Tα to "0". Next, the CPU proceeds to step 103.

[0033] In step 103, the CPU activates timer Tα as a count-up timer. Next, the CPU proceeds to step 104.

[0034] In step 104, the CPU determines whether the driver has started a break. The CPU determines that the driver has started a break if the current location P transitions from being in area Ra to being in area Rb. If the CPU determines that the driver has started a break (104: Yes), it proceeds to step 105. On the other hand, if the CPU does not determine that the driver has started a break (104: No), it returns to step 103.

[0035] In step 105, the CPU adds the output value tα of timer Tα as the operating time DT to the operating history data HST. The CPU then proceeds to step 106.

[0036] The CPU terminates the execution of program PR1 in step 106.

[0037] (Program PR2) The CPU starts executing program PR2 from step 200 and proceeds to step 201.

[0038] In step 201, the CPU determines whether the driver has started a break. If the CPU determines that the driver has started a break (201: Yes), it proceeds to step 202. On the other hand, if the CPU does not determine that the driver has started a break (201: No), it returns to step 201.

[0039] In step 202, the CPU sets (initializes) the output value tβ of timer Tβ to "0". Then, the CPU proceeds to step 203.

[0040] In step 203, the CPU activates timer Tβ as a count-up timer. Next, the CPU proceeds to step 204.

[0041] In step 204, the CPU determines whether the driver has started driving. If the CPU determines that the driver has started driving (204: Yes), it proceeds to step 205. On the other hand, if the CPU does not determine that the driver has started driving (204: No), it returns to step 203.

[0042] In step 205, the CPU adds the output value tβ of timer Tβ as the rest time RT to the operation history data HST. The CPU then proceeds to step 206.

[0043] The CPU terminates the execution of program PR2 at step 206.

[0044] (Program PR3) The CPU starts executing program PR3 from step 300 and proceeds to step 301.

[0045] In step 301, the CPU determines whether the driver has started driving. If the CPU determines that the driver has started driving (301: Yes), it proceeds to step 312. On the other hand, if the CPU does not determine that the driver has started driving (301: No), it returns to step 301.

[0046] In step 302, the CPU refers to the operation history data HST to obtain the operation time DT1 (latest operation time DT). Then, the CPU proceeds to step 303.

[0047] In step 303, the CPU refers to the driving history data HST to obtain the rest time RT1 (the latest rest time RT). Then, the CPU proceeds to step 304.

[0048] In step 304, the CPU refers to the operation history data HST and calculates the operation time DT2 (the total operation time DT during period T).

[0049] In step 305, the CPU calculates the remaining time Δt (Δt = Tstd - Max[DT1 - RT1 × k1, DT2 / k2]). Then, the CPU proceeds to step 306.

[0050] In step 306, the CPU assigns the remaining time Δt to the output value tγ of timer Tγ. The CPU then proceeds to step 307.

[0051] In step 307, the CPU activates timer Tγ as a countdown timer. Then, the CPU proceeds to step 308.

[0052] In step 308, the CPU determines whether the output value tγ is "0". If the CPU determines that the output value tγ is "0" (308: Yes), it proceeds to step 309. On the other hand, if the CPU does not determine that the output value tγ is "0" (308: No), it returns to step 307.

[0053] In step 309, the CPU executes a break suggestion process. Specifically, the CPU, via the ECU 10, causes the notification device 20 to display a predetermined image and play a predetermined sound. Next, the CPU proceeds to step 310.

[0054] The CPU terminates the execution of program PR3 in step 310.

[0055] (effect) In this embodiment, the vehicle control device 1 determines the timing Tc of the next rest suggestion based on the driving time DT and rest time RT within a predetermined period. In other words, according to this embodiment, the success or failure of the conditions for executing a rest suggestion is determined without using the driver's biometric information. Therefore, even drivers who do not permit the vehicle control device 1 to acquire biometric information (personal information) can use the rest suggestion function. In addition, generally, when driving and resting are repeated, drivers may not be aware that fatigue is accumulating or that their fatigue level is increasing. The vehicle control device 1 determines the timing Tc of the rest suggestion based not only on the driving time DT1, which is the duration of the previous driving, and the rest time RT1 immediately following it, but also on the driving time DT2, which is the total driving time DT within a predetermined period (including the previous driving period). As a result, the rest suggestion is executed at an appropriate timing Tc, taking into account the increasing fatigue level that the driver may not be aware of.

[0056] (Variation 1) The values ​​assigned to the standard time Tstd and coefficients k1 and k2 are not limited to the above embodiment. These values ​​may be set (changed) by the driver. For example, if a driver tends to need a relatively long time to recover from fatigue, the driver may assign relatively small values ​​to the standard time Tstd and / or coefficient k1. This increases the frequency of rest suggestions. Also, for example, if a driver tends to become fatigued easily after starting to drive, the driver may assign relatively small values ​​to the standard time Tstd and / or coefficient k2. This increases the frequency of rest suggestions. Furthermore, the smartphone 30 may learn the frequency of rests taken by the driver based on the driving history data HST, and automatically adjust the standard time Tstd and coefficients k1 and k2 based on the learning results.

[0057] (Modification 2) As shown in Figure 6, an in-vehicle navigation system 40 may be used as a device having the same functions as the notification device 20 and smartphone 30 of the above embodiment.

[0058] (Variation 3) The map data may allow the driver to input (set) a destination. In this case, the smartphone 30 obtains a route R from the current location P to the destination, and estimates the point Pc that the vehicle will reach at timing Tc when the rest suggestion process is initiated, assuming the vehicle travels along route R from the current location P. For example, the smartphone 30 estimates the point Pc that the vehicle will reach by assuming the vehicle travels at a predetermined average speed. The smartphone 30 advances timing Tc if the distance Δd from point Pc to a facility A1 where the vehicle can be parked (for example, a service area while driving on a highway) exceeds a threshold Δdth. For example, the smartphone 30 searches for a facility A2 that is closer than facility A1 by referring to the map data, and executes the rest suggestion process when the vehicle reaches a point slightly before facility A2.

[0059] (Modification 4) At the timing Tc in which the rest suggestion process is executed, the smartphone 30 acquires the route R to facility A1 where its vehicle can be parked and displays the route R on the display device of the notification device 20. [Explanation of Symbols]

[0060] 1...Vehicle control unit, 10...ECU, 20...Notification device, 30...Smartphone, V0...Vehicle (own vehicle)

Claims

1. A vehicle control device comprising a processor configured to perform a rest suggestion process that controls a predetermined notification device so that, when predetermined conditions are met, the driver of the vehicle is provided with information prompting him to stop driving and take a break, Includes a position sensor for sequentially acquiring the current location of the vehicle, The processor is configured to determine, based on map data configured to distinguish between a first area consisting of public roads and a second area consisting of other areas, that the driver is driving when the current location is included in the first area, and to acquire the duration of this state as driving time, and to store this driving time as driving history. When the driver starts driving, the processor acquires a rest suggestion timing, which is the timing at which the next rest suggestion process should be executed, based on the first driving time, which is the duration of the previous drive, the rest time, which is the time the driver rested immediately after the previous drive, and the second driving time, which is the total of the driver's driving time during the period from a predetermined point in the past to the present. The vehicle control device is configured to determine that the predetermined conditions have been met when the current time reaches the rest suggestion timing.

2. In the vehicle control device according to claim 1, The vehicle control device is configured such that the processor selects the larger of the following two values: a value obtained by subtracting from the first operating time the value obtained by multiplying the rest time by a predetermined first coefficient, and a value obtained by dividing the second operating time by a predetermined second coefficient, and acquires the time when the time obtained by subtracting the selected value from a predetermined standard time has elapsed from the present moment as the suggested rest timing.

3. In the vehicle control device according to claim 1, The vehicle control device is configured such that, when a destination is set, the processor obtains a route from the current location to the destination, estimates the point the vehicle will reach at the suggested rest time when the vehicle is traveling along the route from the current location, and if the distance from the estimated point to a first facility where the vehicle can be parked exceeds a threshold, it refers to the map data to search for a second facility that is closer than the first facility, and executes the suggested rest process when the vehicle reaches a predetermined point before the second facility.

4. In the vehicle control device according to claim 1, The aforementioned processor is configured to acquire a route to a facility where the vehicle can be parked at the suggested rest time and to display the route on a predetermined display device, thereby enabling vehicle control.

Images