JP2014013576A - Driver interface system, method of managing driver interface task, and vehicle - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a vehicle that can facilitate a dialogue between a driver and the vehicle without increasing a driver workload.SOLUTION: A dynamic operation state of a vehicle, a driver input to the vehicle 11 and the like are taken into consideration and thereby one or more measurement values of the driver workload are calculated. Then, in order not to increase the driver workload, execution of a driver interface task is delayed and/or prevented on the basis of the driver workload. As an alternative for the delay an/or the prevention, the driver interface task is schedulable on the basis of the driver workload, and for example, by being executed according to a scheduling, an effect given to the driver workload by the driver interface task can be minimized.

Description

  The present invention relates to a driver interface system, a method for managing driver interface tasks, and a technical field related to a vehicle.

  Certain vehicles may provide infotainment information, navigation information, etc. to improve the driving experience.

  As the interaction between the driver and these vehicles increases, it may be beneficial to facilitate such interaction without increasing the driver's workload.

  The measured value of the driver workload is determined from the driver control action input information. Certain driver interface tasks may be selectively delayed or aborted based on the determined driver workload. Alternatively, the driver interface task may be scheduled based on the determined driver workload and then executed according to the schedule.

FIG. 1 is a block diagram of an exemplary hybrid workload estimation system. FIG. 2 is a graph of vehicle speed, traction, and braking profile. FIG. 3A is a graph of an exemplary vehicle motion state of yaw rate. FIG. 3B is a graph of an exemplary vehicle motion state of yaw rate. FIG. 3C is an exemplary vehicle motion graph of side slip angle. FIG. 4A is a graph of an exemplary yawing operating limit margin. FIG. 4B is an exemplary vertical operational limit margin graph. FIG. 4C is a graph of an exemplary side slipping operational limit margin. FIG. 5 is a graph of an exemplary vehicle speed, traction and braking profile. FIG. 6A is an exemplary vehicle motion graph of yaw rate. FIG. 6B is a graph of an exemplary vehicle motion state of yaw rate. FIG. 6C is an exemplary vehicle motion graph of side slip angle. FIG. 7A is a graph of an exemplary yawing operating limit margin. FIG. 7B is an exemplary vertical operational limit margin graph. FIG. 7C is a graph of an exemplary side slipping operational limit margin. FIG. 8 is an exemplary final operational limit margin and risk graph. FIG. 9 is an exemplary final operational limit margin and risk graph. FIG. 10 is an exemplary accelerator pedal position graph for a high demand situation. FIG. 11 is an exemplary accelerator pedal position graph for low demand situations. FIG. 12 is a histogram of the standard deviation of the accelerator pedal position in FIG. FIG. 13 is a histogram of the standard deviation of the accelerator pedal position in FIG. FIG. 14 is a graph of a curve fitted to the histograms of FIGS. FIG. 15A is an exemplary graph of accelerator pedal position. FIG. 15B is an exemplary graph of handle angle. FIG. 15C is an exemplary graph of a driver control action index (DCA index). FIG. 15D is an exemplary graph of vehicle speed. FIG. 16A is an exemplary graph of direction indicator activity. FIG. 16B is an exemplary graph of air conditioning control activity. FIG. 16C is an exemplary graph of an instrument panel index (IP index). FIG. 17 is a schematic diagram of a vehicle that follows another vehicle. FIG. 18 is an exemplary graph of vehicle speed. FIG. 19 is an exemplary graph of proximity velocity. FIG. 20 is an exemplary graph of ranges. FIG. 21 is an exemplary graph of inter-vehicle time. FIG. 22 is an exemplary graph of an inter-vehicle index (HW index). FIG. 23A is an exemplary graph of a rule-based index. FIG. 23B is an exemplary graph of the IP index. FIG. 23C is an exemplary graph of the DCA index. FIG. 23D is an exemplary graph of a total workload estimation index (WLE index). FIG. 23E is an exemplary graph of vehicle speed. FIG. 24 is an exemplary graph of a membership function that characterizes driver demand based on the WLE index.

I. Introduction The driver workload / request is beyond the primary act of driving and imposes secondary actions on the driver, such as infotainment, phone calls, advance recommendations, etc. May refer to a cognitive request.

  The driver sometimes mistakenly thinks that he can divide his attention between the primary and secondary actions described above. Accordingly, estimating driving demand may be particularly valuable if utilized to coordinate communication with the driver and vehicle system interaction. However, in complex driving situations, an innovative predictive approach to driver workload estimation may be required. In adjusting the Human Machine Interface (HMI) output to the driver, it may be useful to develop an intelligent system that enables identification of the driver workload.

  For continuous workload estimation, it may be useful to design an estimator that estimates the workload under different driving contexts and / or drivers. The configuration of the in-vehicle communication service may be based on the context in which the driving request is predicted and the value for the driver of the service. In addition, it may be beneficial to characterize the driver workload over a period of time (eg, long-term characterization). Such estimation of driver workload not only allows in-vehicle communication technology to be suppressed or delayed within high workload periods, but additionally allows adjustment to long-term driving demands. Might do.

  Certain embodiments described herein may provide methods and systems for workload estimation (WLE). The WLE may perform driver workload state estimation / classification from observable vehicle, driver, and environmental data for adaptive real-time HMI task management. WLE may use a separate real-time technique and / or employ a real-time hybrid approach for workload estimation in certain situations. For example, rule-based algorithms can be supplemented with additional continuous predictions of driver workload based on driver, vehicle, and environmental interactions. The WLE algorithm may incorporate specialized learning and computational intelligence techniques to calculate and predict an overall WLE index (eg, a continuous signal representing workload load estimates for the driver). The driver's driving requirements may be inferred from observable vehicle information including speed variations, acceleration, braking, steering, inter-vehicle distance, instrument panel and / or center stack interaction, as the case may be.

  The WLE index can be used, for example, to set, avoid, limit, or adjust voice commands and / or other tasks / information that are presented to the driver to improve functionality. Certain information for the driver can be limited, adjusted, or blocked during demanding vehicle operation maneuvers, such as during periods of heavy instrument panel operation, under dangerous driving conditions.

  The intelligent hybrid algorithm approach can be useful in the long term as well as short-term driver behavior. The WLE hybrid method may capture driver events, situations, and behaviors to tailor the vehicle to driver communication. These and other techniques described herein assist in predicting a driver's increasing / decreasing cognitive state and may use existing vehicle sensors.

  The WLE index may present a communication hierarchy to the driver based on the driving request / workload. The message priority (eg, low, high, etc.) can determine whether the message is communicated to the driver for a particular moment based on the predicted load. The specific HMI information may be presented to the driver based on the driver's long-term driving request. Alternatively, the hybrid WLE framework may include GPS and digital map databases to describe road scenario conditions and conditions. In addition, information about the driver's physiological state, including heart rate, line of sight, and breathing, may be incorporated as inputs into the WLE framework for anomaly detection. In another example, the predicted WLE index may be communicated to the driver to encourage the driver to avoid secondary tasks under high workload conditions. Other scenarios are possible.

  FIG. 1 is a block diagram of an embodiment of a WLE system 10 for a vehicle 11. The system 10 includes a rule-based workload index subsystem 12, a vehicle, driver and environment tracking and calculation workload index subsystem 13, a context sensitive workload index integration subsystem 14, and a total integration / WLE long-term characterization subsystem. A system 16 may be included. Subsystems 12, 13, 14, 16 may be implemented by one or more controllers / processors or the like (separately or in combination).

  Subsystem 12 (discussed below in Section VII) receives vehicle information, driver information and / or environmental information (eg, available from the vehicle's controller area network (CAN)) as input and receives the driver's workload. A rule-based index can be output. Subsystem 13 (discussed below in Sections III through VI) receives vehicle information, driver information, and / or environmental information (eg, available from the vehicle's CAN) as input and represents the driver's workload. One or more continuous indices (eg, handling limit index (HL index), driver control action index (DCA index), instrument panel index (IP index), inter-vehicle index (HW index)) may be output. Subsystem 14 (described below in Section VIII) may receive as input an index / index group generated by subsystem 13 and output a tracking index (T index). Subsystem 16 (discussed below in Section VIII) may receive a rule-based index and a T-index as input and output long-term features of WLE index and / or WLE index (discussed below in Section IX).

  In other embodiments, the system 10 may be free of subsystems 12, 14, and 16. That is, certain embodiments may only be configured to generate one or more workload indices. As an example, the system 10 may only be configured to generate an IP index based on certain vehicle information (described below). In these situations, aggregate consolidation is not necessary because there is only a single measurement of the driver workload. Therefore, the WLE index is an IP index in this example. In these and other embodiments, dispatcher 18 may be configured to generate long-term characteristics of the WLE index. Other configurations are possible.

  The WLE index may be sent to a dispatcher 18 that may be implemented as one or more controllers / processors or the like. Based on the WLE index, the dispatcher 18 (described later in section X) can act as a filter that blocks / delays information that should be communicated to the driver from reaching the driver. For example, the dispatcher 18 blocks all information intended for the driver if the WLE index is greater than 0.8, and if the WLE index is about 0.5, only the information for entertainment is sent. It behaves like blocking. The dispatcher 18 may schedule transmission of information to be transmitted to the driver based on the WLE index. For example, vehicle maintenance information, text-to-speech, incoming calls, etc. can be delayed during periods of high workload. In addition, the dispatcher 18 may adjust the vehicle output to suit the driver based on long-term WLE index characteristics, as will be described in detail later. For example, the output of certain vehicle systems, including cruise control, adaptive cruise control, music recommendations, configurable HMI, etc., may be based on long-term driving requirements.

  The driver's workload state can be inferred from observable vehicle information including speed fluctuations, acceleration, braking, steering, inter-vehicle distance, instrument panel interaction, and the like. Table 1 shows exemplary features / measures related to driver workload load.

  Table 2a (exemplary information available via CAN) and Table 2b (exemplary system information accessible via CAN) are available / accessible via CANs known in the art. Possible exemplary information is shown.

II. Simple considerations for vehicle stability control Vehicle operability determines the ability of the vehicle to turn and operate. The vehicle needs to be in close contact with the road by the contact surfaces of the four tires in order to maximize the operation performance. Tires that exceed the adhesion limit are spinning, skid or sliding. The condition in which one or more tires exceed their adhesion limit can be referred to as a critical operating condition, and the adhesion limit can be referred to as an operational limit. Once a tire reaches its operating limit, the average driver can usually no longer control it. In the case of so-called understeer, the car operates less than the driver's steering input, its front tires exceed their operating limits, and the vehicle continues straight ahead despite the driver's steering request. In the case of so-called oversteer, the car operates greater than the driver's steering input, its rear tires exceed their operating limits, and the vehicle continues to spin. For safety, most vehicles are designed to be understeered at their operational limits.

  To compensate for vehicle control when the driver is unable to control the vehicle at or beyond the operating limit, an electronic stability control system (ESC system) redistributes the tire forces to redistribute the vehicle. It is designed to generate a moment that can be effectively turned to be consistent with the driver's steering request. That is, controlling the vehicle is to avoid understeer and oversteer.

  Since its introduction in 1995, ESC systems have been implemented on various platforms. Starting in model year 2010 and achieved to be fully equipped by model year 2012, the US Federal Automobile Safety Standard 126 requires an ESC system for all vehicles weighing less than 10,000 pounds. Yes. The ESC system can be implemented as an extension of an anti-lock braking system (ABS) and a full speed traction control system (TCS). The ESC system may provide yaw and lateral stability assistance for vehicle dynamic behavior located near the center of the driver's intention. This system is active such that the brake pressure is assigned to the individual wheel (s) (above or below the driver's applied pressure) to offset the vehicle's unexpected yaw and side slip movements. Generate moments. This leads to improved steering control at the operating limit for any traction surface during braking, acceleration or inertial running. More specifically, current ESC systems compare the driver's intended course with the actual vehicle response inferred from on-board sensors. If the vehicle response is different from the intended course (either understeer or oversteer), the ESC controller brakes the selected wheel (s) and keeps the vehicle on the intended course In order to reduce the engine torque, if necessary, and to minimize the lack of control of the vehicle.

  Since marginal operating conditions can be detected using data already present in the ESC system, a new sensor may not be required. For example, consider a vehicle equipped with an ESC system using a yaw rate sensor, steering wheel sensor, lateral accelerometer, wheel speed sensor, master cylinder brake pressure sensor, longitudinal accelerometer, and the like. Vehicle motion variables are defined in a coordinate system defined by ISO-8855, where the coordinates fixed on the vehicle body are the vertical axis up, the axis along the longitudinal direction (longitudinal direction) of the vehicle body, and It has a lateral axis extending from the passenger seat to the driver seat.

  Generally speaking, vehicle level feedback control is a combination of yaw rate, side slip angle, or arbitration between these and other control commands such as driver braking, engine torque request, ABS and TCS. It can be calculated from individual motion variables such as

Using its yaw rate ω _z along the vertical axis and its side slip angle β _r defined at its rear axle, a well-known bicycle model expresses vehicle dynamics and follows the following equation:

Here, v _x is the moving speed of the vehicle, M and I _z is yaw moment of the total mass and inertia of the vehicle, c _f and c _r is a cornering stiffness of the front tire and the rear tire, b _f and b _r is the distance from the center of gravity of the vehicle to front and rear axle, a _{b = b f + b r,} M z is an active moment applied to the vehicle, [delta] is a steering angle of front wheels It is.

The yaw rate target (target yaw rate) ω _zt and the side slip angle target (target side slip angle) β _rt used to reflect the driver's steering intention are the steering angle δ and the estimated moving speed v _x measured as inputs. And can be calculated from Equation 1. Suppose in such a calculation, the vehicle includes a traveling on a road of the normal road surface condition (e.g., nominal cornering stiffness c high level of friction with the _f and c _r). To fine tune the yaw rate target and the side slip angle target, signal adjustment, filtering and non-linear correction may be performed for steady state limit cornering. These calculated target values (target values) characterize the course intended by the driver on a normal road surface.

The yaw rate feedback controller is essentially a feedback controller calculated from the yaw error (difference between measured yaw rate and yaw rate target). If the vehicle is turning left and ω _z ≧ ω _zt + ω _zdbo (where ω _zdbos is a time-varying dead band) or the vehicle is turning right and ω _z ≦ ω _zt −ω _zdbos If the vehicle is oversteered, the oversteer control function in the ESC is turned on. For example, the active torque request (applied to the vehicle to reduce the oversteer tendency) may be calculated as:

Here, k _os is a speed-dependent gain that can be defined by the following equation, which may be defined as:

Here, the parameters k ₀ , k _dbl , k _dbu , v _xdbl and v _xdbu can be adjusted.

If the vehicle is turning left, ω _z ≦ ω _z −ω _zdbo (where ω _zdbos is a time-varying dead band), or ω _z ≧ ω when the vehicle is turning right _{If z} + ω _zdbos , the understeer control function in the ESC is turned on. The active torque request can be calculated as follows:

Here, k _us is an adjustable parameter.

The side slip angle controller is a feedback controller that supplements the above-described oversteer yaw feedback controller. This compares the side slip angle estimate β _r with the side slip angle target β _rt . If the difference exceeds the threshold β _rdb , side slip angle feedback control is turned on. For example, an active torque request during a left turn is calculated as follows:

Here, k _ss and k _sscmp are adjustable parameters, and those with a dot on β _rmcmp are the time derivatives with compensated side slip angles.

  Other feedback control terms based on variables such as yaw acceleration and side slip gradient can be generated in a similar manner. When the dominant vehicle motion variable is either the yaw rate or the side slip angle, the active torque described above determines the amount of brake pressure to be sent to the required control wheel (s) and the corresponding control wheel (s). It may be used directly to determine. If vehicle dynamics are dominated by multiple motion variables, control arbitration and prioritization is performed. The final arbitrated active torque is then used to determine the final control wheel (s) and corresponding brake pressure. For example, during an oversteer event, the front outer wheel is selected as the control wheel, and during the understeer event, the rear inner wheel is selected as the control wheel. During the case of a large side slip, the front outer wheel is always selected as the control wheel. When side slip and oversteer yawing are occurring simultaneously, the amount of brake pressure can be calculated by integrating both yaw error and side slip angle control commands.

  Except for the above case where the operation limit is exceeded by the driver's steering operation, the vehicle can reach the limit operation condition in the longitudinal movement direction. For example, braking on snowy and frozen roads can lead to wheels being locked, which increases the stopping distance of the vehicle. Opening the throttle on a similar road can cause the drive wheels to idle without moving the vehicle forward. For this reason, operational limits can be used for these non-steering driving conditions. That is, the condition that the longitudinal braking or driving force of the tire reaches the peak value thereof may be included in the definition of the operation limit.

The ABS function monitors the rotational movement of the individual wheels with respect to the speed of movement of the vehicle, which can be characterized by a longitudinal slip ratio λ _i , where i = 1, 2, 3, 4 are left front wheels, right front wheels, Corresponding to the left rear wheel and the right rear wheel, the slip ratio can be calculated as follows.

Here, t _f and t _r is the half track of the front and rear axle, ω _i is the output of the i-th wheel speed sensors, κ _i is the i-th wheel velocity scale factor, v _y is the lateral velocity at the center of gravity of the vehicle, v _min is a preset parameter reflecting the allowable minimum longitudinal velocity. Note that Equation 6 is valid only when the vehicle is not in reverse drive mode. When the driver who started braking generates too much wheel slip (for example, when -λ _i ≧ λ _bp = 20%), the ABS module relaxes the brake pressure at that wheel. Similarly, when a large throttle is applied that produces a large slip on the i th drive wheel, the TCS module requests engine torque reduction and / or brake pressure applied to the opposite wheel in the same axle. As a result, ABS or TCS activation can be predicted by monitoring how close λ _{is is} to λ _bp and λ _tp .

III. Handling of critical indices The aforementioned ESCs (including ABS and TCS) are effective in achieving their safety goals, but further sophistication is still possible. For example, an ESC system extension may be desirable for roll stability control. However, the appropriate corrections that the ESC will make may be countered by the driver or environmental conditions. Even with ESC intervention, a high-speed car whose tire far exceeds the road / tire traction capability may not be able to prevent understeer accidents.

  Generally speaking, an accurate decision to deal with critical conditions is typically measured directly from road and tire characteristics, or intensive information from many related variables if direct measurements are not possible. It is accompanied. Currently, neither of these methods is mature enough for real-time realization.

  Due to its feedback feature, the ESC system can be configured to determine potential critical operating conditions through monitoring vehicle motion variables (vehicle operating parameters) as described in the previous section. When the motion variable deviates from its reference value by a certain amount (eg, beyond a certain dead band), the ESC system may calculate a differential braking control command (s) and begin to determine the control wheel (s) Good. Thereafter, the corresponding brake pressure (s) are sent to the control wheel (s) to stabilize the vehicle. The starting point of ESC activation is considered to be the start of the operating limit.

More specifically, the relative operating limits margin h _x can be defined as:.

  Here, x is a deviation from the reference value of the motion variable, [x1, x2] (x1 represents a variable with a bar under x, and x2 represents a variable with a bar over x. Represents a deadband interval in which x enters without activating ESC, ABS or TCS. x can be any of the control variable groups defined in the previous section (or any other suitable control variable).

The advantage of h _x defined in Equation 7 is that the operating conditions can be characterized quantitatively into different categories. For example, when h _x ≦ 10%, the driving conditions can be categorized into red zone conditions where the driver must take special care or take special action (eg, vehicle deceleration), and 10% When <h _x <40%, the driving conditions can be categorized as yellow zone conditions where the driver needs some level of special attention, and when 40% <h _x ≦ 100% The condition can be characterized as a normal condition. Under normal conditions, the driver only needs to maintain the caution for that normal driving. Of course, different ranges may be used.

More specifically, the calculation of h _x will be discussed using the control variables calculated in the previous section. The yaw operation limit margin h _OS of the vehicle during the oversteer state (where ω _z > ω _zt when the vehicle is turning left and ω _z <ω _zt when the vehicle is turning right) is x By setting = ω _z −ω _zt and x2 = ω _{zdbos −−x1,} it can be calculated from Equation 7. Here, ω _zdbos is an oversteer yaw rate dead band defined by Equation 2.

Similarly, the yaw operation limit margin h _US of the vehicle for the understeer state can be calculated from Equation 7 by setting x = ω _z −ω _zt and x2 = ω _zdbus = −x1. Here, ω _zdbus is an understeer yaw rate dead band defined by Equation 4. Note that the deadband described above can be a function of vehicle speed, yaw rate target magnitude, measured yaw rate magnitude, and the like. The dead bands for the understeer state (x <0) and the oversteer state (x> 0) are different from each other and are adjustable parameters.

The side slip operation limit margin h _SSRA of the vehicle can be calculated from Expression 7 by setting x = β _r −β _rt and x2 = β _rdb = _−x 1.

The longitudinal operation limit of the vehicle is related to a state when either the driving force or the braking force of the tire approaches the operation limit. The traction control operation limit margin h _TCSi for the i th drive wheel can be calculated from Equation 7 by setting x = λ _i , x1 = 0 and x2 = λ _tb . The ABS operation limit margin h _ABSi for the i-th wheel can also be calculated from Equation 7 by setting x = λ _i , x1 = λ _bp and x2 = 0. The final margin for traction and braking operation is

Can be defined by

  Note that further selection states may be used when calculating the operational limit margin described above. For example, the operating margin may be set to zero when one or some combination of the following conditions is satisfied. That is, when the yaw rate target size exceeds a certain threshold, when the measured yaw rate is greater than a certain threshold, when the driver's steering input exceeds a certain threshold, or when the vehicle cornering acceleration is 0. It is an extreme condition such as greater than 5G, vehicle deceleration greater than 0.7G, or the vehicle traveling at a speed exceeding a threshold (eg, 100 miles / hour).

  In order to test the operating margin margin calculations described above and confirm their effects on known driving conditions, vehicles equipped with a research ESC system developed by the Ford Motor Company were used to perform vehicle tests.

The vehicle motion variables measured and calculated for the driving conditions expressed by the vehicle speed, throttling and braking shown in FIG. 2 are shown in FIGS. 3A-3C. The corresponding individual operating limit margins h _US , h _OS , h _TCS , h _ABS and h _SSRA are shown in FIGS. 4A-4C. This test was conducted as a freeform slalom on a snow pad with all ESC calculations performed. The application of brake pressure is turned off to bring the vehicle closer to the true limit operating situation.

For another test, the vehicle ran on a road surface with a high friction level. The vehicle speed, traction and braking profiles for this test are shown in FIG. The vehicle motion state is shown in FIGS. 6A to 6C. The corresponding individual operating limit margins h _US , h _OS , h _TCS , h _ABS and h _SSRA are shown in FIGS. 7A-7C.

  The total variation of all individual operating margins is

Is defined as follows. Taking into account that a sudden change in the overall operating limit margin may be due to signal noise, a low-pass filter F (z) is used to smooth h _env and thereby the final operating limit index (HL index). ) Or a margin can be obtained.

  For the vehicle test data shown in FIGS. 2 and 3A-3C, the final operating limit margin is shown in FIG. 8, while for the vehicle test data shown in FIGS. 5 and 6A-6C, the final A critical operating margin is shown in FIG.

  The HL index can provide a continuous variable between 0 and 1, indicating how close the driver is to its vehicle operating limit (a value of 1 indicates that the driver is at the vehicle operating limit) ). This model-based HL index may provide particularly important driving requirement information, for example, during low μ road surface driving conditions.

  As the vehicle approaches its operating limits, assuming that more visual, physical and cognitive attention is required to maintain vehicle control, the driver's workload information is It can be inferred from the HL index. As the workload on the driver increases, so does the HL index. As the workload on the driver decreases, so does the HL index.

IV. Driver Control Action Index The Driver Control Action Index (DCA Index) is a continuous between 0 and 1 indicating the total variation of the driver's control action for acceleration, braking and steering, for example. Variable can be provided. An increase in the driver's variation from standard driving may reflect an increase in driving demand and vice versa. Thus, the DCA index may provide a measure of variability (driving demand) associated with different drivers having different standards of vehicle control action.

  For example, consider the effect of accelerator pedal variation on driving requirements. Referring to FIGS. 10 and 11, for example, real time accelerator pedal positions are plotted versus time for high demand and low demand situations, respectively. It is clear that the accelerator pedal variation is considerably greater in the case of high demand than in the case of low demand.

  The standard deviations of the accelerator pedal positions in FIGS. 10 and 11 are plotted in FIGS. 12 and 13, respectively.

  Referring to FIG. 14, probability fitting to the distributions of FIGS.

Is generated using

  Here, a is a scale factor, and b is a shape factor. The broken line in FIG. 14 represents the standard deviation distribution of the low driving request, and the solid line represents the standard deviation distribution of the high driving request. These probability distributions of accelerator pedal variation indicate the level of difference between the driving requirement category and the current classification opportunity. For example, a standard deviation of 2% is more likely to be a feature of low driving demand, while a standard deviation of 10% is more likely to be a characteristic of high driving demand. This approach is equally applicable to brake pedal position, steering wheel angle, and / or other driver control action parameters. Therefore, the DCA index can estimate a driving request based on a change in driver action with respect to an accelerator pedal, a brake pedal, a steering wheel, and the like.

  The average of the standard deviation changes shown in FIG. 14 can change if the driver is different. In calculating the DCA index, relative changes may be calculated in consideration of these changing average values. A driver input derivative may also be incorporated to capture the expected action. This variance calculation can be obtained from a determinant analysis of the covariance of each factor (eg, accelerator pedal position / speed, brake pedal position / speed, steering wheel angle position / speed, etc.).

  The DCA index is calculated by iteratively calculating for each factor a covariance determinant that affects driving demands in certain embodiments based on the following equation:

Where x _k is a two-dimensional vector for each of the driver control action and its derivative (at time k), and the variable with a bar on x _k is the average (each driving cycle). May be continuously updated during each operation cycle and reset after each driving cycle), α is the calibrated forgetting factor, G _k is the estimated inverse covariance matrix, and I is the identity matrix Yes, P _k is the estimated covariance matrix, and Δx _k ^T is the transpose of Δx _k in Equation 12.

  The determinant det calculated by iterating the covariance matrix is

Given by.

Here, n is the size of the vector _{x k.} This gives a measure of the estimated variation of the driver's acceleration, braking and / or steering performance relative to the average value of the particular driver for these parameters. This also provides a single dimensional measure of total variance that can be tracked to capture significant changes in the overall variation of driver control actions.

  The final DCA index is scaled to a continuous signal between 0 and 1,

Can be given by.

  Here, APV is accelerator pedal variation, BPV is brake pedal variation, and SV is steering variation.

  The accelerator pedal position plotted in FIG. 15A and the handle angle plotted in FIG. 15B were analyzed using the technique described above. FIG. 15C shows an exemplary output for the DCA index based on the inputs of FIGS. 15A and 15B. The determinant of the covariance matrix (Equation 16), in this example, provides a measure of estimated variation in driver acceleration and steering performance. Each variation is normalized and aggregated by choosing the respective maximum value to produce the DCA index plotted in FIG. 15C. In FIG. 15D, the vehicle speed is plotted for reference. Increasing fluctuations are captured as numbers close to 1 on the DCA index scale (representing relatively high driving demand), while decreasing fluctuations are figures between 0 and 0.2 (relatively low driving demand). It is captured on the scale.

V. Instrument Panel Index The driver's interaction with the instrument panel and / or other touch / voice related interfaces may provide an indication of driver activity. As such driver activity levels increase, cognitive demands on the driver may also increase. As shown in Table 1, as the driver's button press activity increases, the driver's workload may also increase. Frequency of interaction with in-vehicle control unit including wiper control unit, air conditioner control unit, volume control unit, turn indicator, center stack console, window control unit, power seat control unit, voice command interface, etc. it can. The instrument panel index (IP index) thus provides a continuous output (between 0 and 1) that represents the driver's interaction with the instrument panel, electronics, and / or any other HMI.

  For example, if a button / interface device is pressed / on at any time k, its output is

Given by.

  If the button / interface device is not pressed / on, its output is

Given by.

Where BP _i is the pressed / on button / interface tracking value for each button / interface being tracked and α is a calibratable forgetting factor.

  The IP index is

Can be given by.

  Where n is the number of buttons / interfaces being tracked. The IP index may be determined using any of the integration techniques described herein. As an example, a technique similar to that described later with reference to equations 28 and 29 may be used.

  Exemplary direction indicators and air conditioner activity inputs are plotted in FIGS. 16A and 16B, respectively. The resulting IP index is determined according to Equation 18, Equation 19, and Equation 20, and is plotted in FIG. 16C. In this example, the rise time and steady state values are based on the duration of the activity.

VI. Vehicle-to-vehicle index The vehicle-to-vehicle index provides a continuous variable between 0 and 1, indicating how close the vehicle being driven is to its front (or side) vehicle (or other object). As shown in Table 1, it can be inferred that the workload load has increased because the average inter-vehicle time has decreased and / or the minimum interval has decreased.

  The current speed-dependent interval (inter-vehicle time) is obtained from the following equation.

Here, r _p (k) is the position of the preceding vehicle at an arbitrary time k, r _f (k) is the position of the following vehicle, and v _f (k) is the speed of the following vehicle.

The average interval HW _m (k) is

Obtained from.

  Here, α is a time constant for exponential filtering, and can be appropriately selected.

  And HW index (HW Index) is

Obtained from.

Here, γ is the sensitivity gain of the HW index, and HW _MAX is a calibrated value. This gain can be selected / adapted depending on the inter-vehicle time required to satisfy the maximum index of 1.

  In other embodiments, the sensitivity gain may be selected / adapted based on, for example, the type of driver. If the type of driver is known, such as “young”, “elderly”, “teen”, “beginner”, “expert”, the sensitivity gain may be adjusted accordingly. As known in the art, a driver can be identified as “young”, “elderly”, “teen”, etc. based on the token carried by the person. The token can be detected by the vehicle and used to identify the type of driver. Alternatively, the vehicle may be provided with a selection button that allows the driver to identify his type. However, any suitable / known technique for classifying drivers by type can be used. The sensitivity gain for “young” and “teen” may be increased while the sensitivity for a “skilled” driver may be decreased. In other embodiments, the sensitivity gains for “teen” and “beginner” drivers are chosen to be higher, for “expert” drivers, etc., etc. It may be. Therefore, even if the same inter-vehicle distance (inter-vehicle time) is given, the HW index becomes higher for a “teen” driver, lower for a “skilled” driver, and so on. Also good.

  Alternatively (or in addition), the sensitivity gain may be selected / adapted based on environmental conditions. Wet or icy road conditions determined by any suitable / known technique, such as through detection of wheel slip, can lead to increased sensitivity gain. In dry road conditions, the sensitivity gain can be low. Any suitable environmental conditions, including traffic density, geographic location, etc. can be used to select / change the sensitivity gain.

  Proximity to infrastructure, including intersections, road works, high demand road structures, etc., can also be calculated in the same way as calculated by Equation 21, Equation 22 and Equation 23. In such a case, the HW index is

Can be given by.

  Here, n is the number of proximity items that are being tracked and that require high driving. A weighted function for Equation 24 may be used.

  In other embodiments, the increased spacing return due to increased traffic in adjacent lanes can be used as a bias input to the HW index (increased traffic density as shown in Table 1). Can increase driving demand).

  In yet other embodiments, the time to collision may be tracked in an area that is less than 1000 ms. In a potential impending crash situation, the HW index output may be set to a maximum value of 1.

Referring to FIG. 17, the time t _c until the collision can be calculated as follows.

Here, v _x is a proximity speed, A _x is a relative acceleration, and X is a distance between vehicles. This distance and proximity velocity information may be obtained from any suitable / known radar system, vision system, rider system, vehicle-to-vehicle communication system, etc.

  Considering the calculation of the HW index in an exemplary vehicle for the following scenario, FIGS. 18-20 show the host vehicle speed, the inter-vehicle proximity speed, and the range in the scenario. 21 and 22 show the average interval (calculated from Equation 22) and the HW index (calculated from Equation 23), respectively.

VII. Rule-Based Subsystem Referring back to FIG. 1, the rule-based subsystem 12 may include a knowledge base and facts for determining event binary output flags. Subsystem 12 may include specific expert engineering and vehicle / driver / environment interaction rules to supplement other elements of system 10. Knowledge may be expressed as a set of rules. A specific activation of the vehicle system may be incorporated.

  Each rule specifies an output workload recommendation and has an IF (condition) and THEN (action) structure. When the condition part of the rule is satisfied, the action part is executed. Each rule may specify a recommendation for the output workload (0 or 1). Several vehicle parameters, including longitudinal acceleration, lateral acceleration, steering angle, button usage, etc. (see, eg, Table 2a and Table 2b) can be performed by subsystem 12 in any suitable / known manner, eg, vehicle Can be monitored / acquired from the CAN bus. The facts associated with these parameters and combinations thereof can be used to set up conditional rules.

  The general rules realized by the subsystem 12 may be in the following format.

  Specific delays or limitations of infotainment or vehicle cabin systems during events are enabled from expert rules. The rule-based output may be further processed to provide relative output integration based on the use of specific features and the use of expert views of driving requirements for conditions.

  The rules may be based on the information listed in Tables 2a and 2b, for example. For example, if the handle angle is greater than 105 degrees, Event_Flag = 1. Other rules can of course be constructed.

VIII. Integration One or more of the HW Index, DCA Index, DCA Index, IP Index, and HL Index are determined by subsystem 14 using the techniques described below. A tracking index (T index) may be formed by being consolidated. However, in embodiments where only one index is used / calculated / determined, integration may not be necessary.

  In certain embodiments, short-term integration may be used to schedule / delay / suppress information / tasks to be communicated to the driver. For situations where the highest estimated driving demand is required, the T index (T Index, or Tracking_Index in Equation 29) is

Can be given by.

  In other embodiments, context dependent integration is employed for the average / maximum output combination of exponent values, as described below. For example, referring to FIG. 1, the DCA index, the IP index, the HL index, and the HW index are combined by the subsystem 14 such that

The T index given by may be generated.

Here, w _i is a context-dependent weight that depends on the driving requirement value imposed on the input. If Equation 28 is expanded,

It becomes. Here, WLE _DCA , WLE _IP , WLE _HL, and WLE _HW are DCA index, IP index, HL index, and HW index outputs, respectively. The corresponding weight is given by w _DCA , w _IP , w _HL and w _HW .

  Tables 3 and 4 list exemplary rules for integration.

  The sub-system 16 may refer to the sub-system 14 and integrate the rule-based index and the T-index into the WLE index using the above technique. As an example, the WLE index is

Can be given by.

  Exemplary rule-based indices, IP indices, and DCA indices are plotted in FIGS. 23A-23C, respectively. These indices are integrated using the techniques described herein for conditions that take into account the highest estimated driving demand situation and are plotted in FIG. 23D. Vehicle speed is plotted for reference in FIG. 23E.

IV. Long-term characterization In other embodiments, the WLE index is characterized over time to provide HMI recommendations by subsystem 16 and / or dispatcher 18 (depending on the configuration). May be. Long term WLE characterization allows the HMI to be tailored to the driver based on driving requirements over a period of time. r _k, for example, consider that a variable that reflects the WLE index values for the driver (at an arbitrary time k). Suppose that the driving requirements are categorized into three classes as {a, b, c} by fuzzy membership functions μ _a , μ _b , μ _c as defined in FIG. The driving behavior d _k can then be inferred from the following exemplary calculation.

If, for example, r _k has a value of 0.4, d _k can be expressed as [0.18, 0.62, 0] (according to FIG. 24). A filtered (long term) d _fk of driving behavior may be expressed as:

Where α is a calibratable forgetting factor (thus identifying / determining the period during which the long _dfk of driving behavior is evaluated).

The long-term probability (p _k ) _i for each class group is

Obtained from.

According to Equation 33, the filtered driving behavior (d _fk ) _{i for each} of the class groups is divided by the sum of the filtered driving behavior for all of the class groups. For example, if d _fk is represented by [0, 0.16, 0.38], (p _k ) _a is equal to 0 divided by (0 + 0.16 + 0.38) ((p _k ) _a is equal to 0), (p _k ) _b is equal to 0.16 divided by (0 + 0.16 + 0.38) ((p _k ) _b is 0.29), and (p _{k C} equals 0.38 divided by (0 + 0.16 + 0.38) ((p _k ) _c becomes 0.71).

Characterization i _k of the final long WLE index operation request,

Can be inferred from Using the above example, the maximum value of (p _k ) _i is 0.71 (that is, the value of (p _k ) _c ). Therefore, it can be inferred from Equation 34 that the driving behavior is currently in the “high demand” class.

X. Dispatcher Dispatcher 18 may apply a long term characterization of the calculated WLE index or WLE index, or any one of DCA index, IP index, HL index and HW index (only a single index). In the embodiment where is used / calculated / determined), the interaction between the infotainment and / or other interaction system and the driver is modulated. The WLE index represents the estimated workload load used to set / avoid / adjust / limit / schedule voice commands and other tasks to be presented to the driver to improve functionality and safety. provide.

  Exemplary interactions with the driver include generating text and voice information, generating avatar communications, generating notifications about incoming calls, generating proactive powertrain commands, proactive Generating an audible recommendation, for example, generating a tactile response via a tactile handle, or generating other audible, visual and / or tactile output, etc. Each of these exemplary driver interface tasks may have a priority associated with it. For example, generating a notification about an incoming call may have a high priority, whereas a proactive voice recommendation may have a low priority.

  Any suitable / known technique can be used to assign a certain priority type to a given driver interface task. By way of example, the dispatcher 18 may assign a high priority to notifications to be generated for incoming calls and a low priority to vehicle-generated recommendations to be communicated to the driver. A low priority rule may be implemented. However, other priority schemes may be used. As an example, a number between 0 and 1.0 may represent the priority of the task. That is, certain tasks are assigned a priority of 0.3, while other tasks are assigned a priority of 0.8, and so on. In other embodiments, the priority type associated with the driver interface task may be assigned by the controller / processor / subsystem (not shown) that created the task as is known in the art.

  Certain embodiments may allow driver interface tasks to be adjusted and presented based on workload and priority. If, for example, the WLE index (or possibly any one of the above indices) has a value between 0.4 and 0.6, the dispatcher 18 will only execute the high priority driver interface tasks. You may be made to do. The dispatcher 18 may schedule a low priority task so that it is later conditioned to run if the WLE index is less than 0.4. For example, if the WLE index has a value between 0.7 and 1.0, the dispatcher 18 may prevent all driver interface tasks from being performed. During these periods of high workload, dispatcher 18 schedules for high priority tasks to run after the WLE index has a value less than 0.7, and for low priority tasks. Schedules to run after the WLE index has a value less than 0.4.

  Similarly, if long-term driving behavior is characterized as “high demand”, certain / all tasks may have a long-term driving behavior of “medium demand” or “low demand” regardless of their priority. It may be interrupted / delayed / scheduled until characterized. Alternatively, if there is any chance that long-term driving behavior is in the “high demand” class, for example, certain / all tasks will be suspended until the possibility of entering “high demand” is zero / Delay / scheduled. Of course, other scenarios are possible. For example, in embodiments where priority types are not used to categorize tasks, all tasks may be suspended / delayed / scheduled depending on the inferred workload.

  For calls that arrive during periods of high workload, dispatcher 18 may forward the call to a voice mail system. After the WLE index reaches an appropriate value, the dispatcher 18 may generate a notification indicating that a call has arrived.

  The algorithm disclosed herein may be sent to any processing device / all processing devices of the system 12, 13, 14, 16, 18. The systems 12, 13, 14, 16, 18 include, but are not limited to, information permanently stored on non-writable storage media such as ROM devices, and floppy disks, magnetic tapes, CDs, RAMs It may include any existing or dedicated electronic control unit that takes many forms, including writable storage media such as devices, and information stored modifiable on other magnetic and optical media. This algorithm may be implemented in a software executable object. Alternatively, the algorithm may be any suitable hardware element, such as an application specific integrated circuit (ASIC), field programmable gate array (FPGA), state machine, controller, or other hardware element or device, or hardware, A combination of software and firmware elements may be implemented in whole or in part.

  While embodiments of the invention have been illustrated and described, these embodiments are not intended to illustrate and describe all possible forms of the invention. It will be understood that the terminology used herein is for the purpose of description, not limitation, and that various modifications can be made without departing from the spirit and scope of the invention.

Claims (17)

A vehicle,
(i) monitoring driver control action input over a period of time; and
(ii) obtaining a variation of the driver control action input with respect to an average value of the driver control action input for a specific driver; and
(iii) receive a plurality of driver interface tasks to be performed; and
(iv) scheduling execution of the plurality of driver interface tasks based on the variation; and
(v) execute the scheduled driver interface task;
A vehicle comprising: at least one processor configured as described above.   The vehicle according to claim 1, wherein the driver control action input includes an accelerator pedal position, a brake pedal position, or a steering wheel angle. Each of the plurality of driver interface tasks includes a priority,
The vehicle of claim 1, wherein the at least one processor is further configured to schedule execution of the plurality of driver interface tasks based on the priority.   The at least one processor is configured to determine the variation of the driver control action input by iteratively calculating a covariance determinant of the driver control action input. The vehicle according to claim 1.   The vehicle of claim 4, wherein the at least one processor is configured to determine an index representative of a driver workload by scaling the determinant.   The plurality of driver interface tasks includes at least one of generating an audio output, generating a visual output, and generating a haptic output. The vehicle described. A driver interface system for a vehicle,
(i) monitoring driver control action input over a period of time; and
(ii) obtaining a variation of the driver control action input with respect to an average value of the driver control action input for a specific driver; and
(iii) obtaining a driver workload based on said variation; and
(iv) receive a plurality of driver interface tasks to be performed; and
(v) selectively delaying or preventing at least some of the plurality of driver interface tasks from being performed based on the driver workload;
A driver interface system comprising: at least one processor configured as described above.   The at least one processor is configured to determine the variation of the driver control action input by iteratively calculating a covariance determinant of the driver control action input. The driver interface system according to claim 7.   The driver interface system according to claim 7, wherein the driver control action input includes an accelerator pedal position, a brake pedal position, or a steering wheel angle. Each of the plurality of driver interface tasks includes a priority,
The at least one processor is further configured to selectively delay or prevent at least some of the plurality of driver interface tasks from being performed based on the priority. The driver interface system according to claim 7.   The plurality of driver interface tasks includes at least one of generating an audio output, generating a visual output, and generating a haptic output. Driver interface system as described. A method for managing driver interface tasks, comprising:
Monitoring driver control action inputs over a period of time;
Obtaining a variation of the driver control action input relative to an average value of the driver control action input for a specific driver;
Receiving a plurality of driver interface tasks to be performed;
Selectively delaying or preventing at least some of the plurality of driver interface tasks from being performed based on the variation;
A method comprising the steps of:   13. The method of claim 12, wherein the step of determining the variation of the driver control action input comprises iteratively calculating a covariance determinant of the driver control action input.   13. The method of claim 12, wherein the driver control action input includes an accelerator pedal position, a brake pedal position, or a steering wheel angle. Each of the plurality of driver interface tasks includes a priority,
The method of claim 12, wherein at least some of the plurality of driver interface tasks are further selectively delayed or prevented from being performed based on the priority. The plurality of driver interface tasks includes generating a notification about an incoming phone call;
Selectively delaying or preventing at least some of the plurality of driver interface tasks from being performed includes forwarding the incoming call to a voice mail system. The method of claim 12.   13. The plurality of driver interface tasks includes at least one of generating an audio output, generating a visual output, and generating a haptic output. The method described.

Images