METHOD AND DEVICE FOR PREDICTIVE DRIVING MODE LEARNING AND RELEASE

Abstract

System comprising: a processor configured to: receive a vehicle location; retrieve driver-specific driving mode change data for the vehicle location; determine, based on the retrieved data, whether a vehicle driving mode change has occurred sufficiently at the vehicle location to exceed a predefined threshold;and automatic switching of a vehicle driving mode to a driving mode associated with the driving mode change that has occurred previously sufficiently to exceed the predefined threshold, wherein the processor is further configured to receive a vehicle context, and wherein the processor is configured to determine whether the vehicle driving mode change has previously occurred previously sufficiently at the vehicle location under at least one aspect of the received context to exceed the predefined threshold, wherein the at least one aspect of the received context includes the current occupant composition.

Description

TECHNICAL AREA The illustrative embodiments generally relate to a method and a device for predictive driving mode learning and release. BACKGROUND Adaptive driving control systems provide an enhanced driving experience under a wide range of driving conditions. Recent developments allow for the automatic selection of modes such as Sport, Normal, and Comfort to adapt to changing road conditions, cornering, and undulating curves. As additional modes become available, such as Snow, Gravel, Sand, Eco, etc., automatically selecting a mode desired by a driver for current vehicle operating conditions becomes increasingly challenging. The publication DE 10 2014 218 905 A1 discloses a method for controlling a vehicle, which includes automatically activating a first operating mode of a vehicle; determining whether a driver prefers the automatically activated first operating mode; and automatically switching to a second operating mode based on the determination, as well as a mode switching system for a vehicle for carrying out the method. Document DE 10 2010 053 037 A1 discloses a function mapping method and a function mapping device for a motor vehicle in which processes and / or functions are mapped to be carried out at specific locations, and the necessary location data that needs to be processed is supplied by an on-board integrated navigation system of the motor vehicle. Further state of the art is disclosed in publications DE 10 2013 215 012 A1 and DE 10 2010 015 742 A1. SUMMARY Based on this prior art, a system with the features of independent claims 1, 4 and 13 and a method with the features of independent claims 7 and 10 are created. Advantageous embodiments can be found in the description and the dependent claims. In a first illustrative embodiment, a system includes a processor configured to receive a vehicle location. The processor is further configured to retrieve driver-specific driving mode change data for the vehicle location. The processor is also configured, based on the retrieved data, to determine whether a vehicle driving mode change has occurred previously at the vehicle location sufficiently to exceed a predefined threshold and to automatically switch the vehicle driving mode to a driving mode resulting from the driving mode change that occurred previously enough times to exceed the threshold. In a second illustrative embodiment, a computer-implemented method includes receiving a vehicle location. The method further includes retrieving driver-specific driving mode change data for the vehicle location. Based on the retrieved data, the method further includes determining whether a vehicle driving mode change has occurred sufficiently at the vehicle location to exceed a predetermined threshold and automatically switching the vehicle to a driving mode resulting from the driving mode change that occurred with sufficient frequency to exceed the threshold. In a third illustrative embodiment, a system includes a processor configured to receive driver input indicating a vehicle driving mode change. The processor is also configured to receive a vehicle location and store an instance of the correspondence between the vehicle driving mode change and the vehicle location. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 shows an illustrative vehicle computer system; Fig. 2 shows an illustrative driver behavior learning and prediction system; Fig. 3 shows an illustrative learning process; and Fig. 4 shows an illustrative predictive driving mode activation process. DETAILED DESCRIPTION Detailed embodiments of the present invention are disclosed herein as required; however, it is understood that the disclosed embodiments are merely exemplary of the invention, which can be implemented in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of certain components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching a person skilled in the art to apply the present invention in various ways. Fig. 1 shows an exemplary block topology for a vehicle-based computer system 1 (VCS) for a vehicle 31. An example of such a vehicle-based computer system 1 is the SYNC system, manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computer system may include a visual upstream interface 4 located in the vehicle. The user may also be able to interact with the interface, for example, if it is equipped with a touch-sensitive screen. In another illustrative embodiment, interaction is achieved by pressing buttons, a speech dialogue system with automatic speech recognition and speech synthesis. In the illustrative embodiment 1 shown in Fig. 1, a processor 3 controls at least part of the operation of the vehicle-based computer system. The processor, which is provided in the vehicle, allows the processing of instructions and routines on board. Furthermore, the processor is connected to both the non-volatile memory 5 and the persistent memory 7. In this illustrative embodiment, the volatile memory is random-access memory (RAM), and the persistent memory is a hard disk drive (HDD) or flash memory. In general, persistent (non-volatile) memory can include any form of storage that retains data when a computer or other device is switched off. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent storage. The processor is also provided with a number of different inputs that allow the user to connect to the processor. In this illustrative embodiment, a microphone 29, an auxiliary input 25 (for input 33), a USB input 23, a GPS input 24, a screen 4, which can be a touchscreen, and a BLUETOOTH input 15 are all provided. An input selector switch 51 is also provided to allow a user to switch between different inputs. Input into both the microphone and auxiliary inputs is converted from analog to digital by a converter 27 before being passed to the processor. Although not shown, numerous vehicle components and auxiliary components can communicate with the VCS using a vehicle network (such as, but not limited to, a CAN bus) to transmit data to and from the VCS (or components thereof). Outputs from the system can include, but are not limited to, a visual display 4 and a speaker 13 or stereo system output. The speaker is connected to an amplifier 11 and receives its signal from the processor 3 through a digital-to-analog converter 9. Output can also be to a remote BLUETOOTH device such as a PND 54 or a USB device such as a vehicle navigation system 60 along the bidirectional data streams shown at 19 and 21, respectively. In an illustrative embodiment, the system 1 uses a BLUETOOTH transceiver 15 to communicate 17 with a user's mobile device 53 (e.g., cordless phone, smartphone, PDA, or any other device that has wireless connectivity to a remote network). The mobile device can then be used to communicate 59 with a network 61 outside the vehicle 31, for example, by communicating 55 with a radio mast 57. In some embodiments, the mast 57 can be a WLAN access point. Example communication between the mobile device and the BLUETOOTH transceiver is represented by signal 14. Pairing a mobile device 53 and the BLUETOOTH transceiver 15 can be initiated by pressing a key 52 or similar input. Accordingly, the CPU is instructed to pair the onboard BLUETOOTH transceiver with a BLUETOOTH transceiver in a mobile device. Data can be communicated between the CPU 3 and the network 61 using, for example, a data plan, data-over-speech, or DTMF tones associated with the mobile device 53. Alternatively, it may be desirable to provide an onboard modem 63 equipped with an antenna 18 to communicate data between the CPU 3 and the network 61 over the voice band 16. The mobile device 53 can then be used to communicate 59 with a network 61 outside the vehicle 31, for example, by communicating 55 with a radio mast 57. In some embodiments, the modem 63 can establish communication 20 with the mast 57 to communicate with the network 61. As a non-limiting example, the modem 63 can be a USB radio modem, and the communication 20 can be radio communication. In an illustrative embodiment, the processor is equipped with an operating system that includes an API for communicating with modem application software. The modem application software can access an embedded module or embedded firmware in the Bluetooth transceiver to establish wireless communication with a remote Bluetooth transceiver (such as one in a mobile device). Bluetooth is a subset of the IEEE 802 PAN (Personal Area Network) protocols. The IEEE 802 LAN (Local Area Network) protocols include WLAN and exhibit considerable cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other communication methods that can be used in this area include free-space optical communication (such as IrDA) and non-standard customer IR protocols. In another embodiment, the mobile device 53 includes a modem for voice-band or broadband data communication. In the data-over-speech embodiment, a technique known as frequency-division multiplexing (FDM) can be implemented, allowing the owner of the mobile device to speak through the device while data is being transmitted. At other times, when the user is not using the device, data transmission can utilize the entire bandwidth (300 Hz to 3.4 kHz in one example). While FDM may be common and still used for analog cellular communication between the vehicle and the internet, it has been largely superseded by hybrids such as code-division multiplexing (CDMA), time-division multiplexing (TDMA), and space-division multiplexing (SDMA) for digital cellular communication.These are all standards compatible with ITU IMT-2000 (3G) and offer data rates of up to 2 Mbps for stationary or walking users and 385 kbps for users in a moving vehicle. 3G standards are now being superseded by IMT-Advanced (4G), which offers 100 Mbps for users in a vehicle and 1 Gbps for stationary users. If the user has a data plan associated with the mobile device, it is possible that the data plan offers broadband transmission, and the system could use a much greater bandwidth (thereby speeding up data transmission). In yet another embodiment, the mobile device 53 is replaced by a radio communication device (not shown) installed in the vehicle 31. In a further embodiment, the ND 53 can be a wireless local area network (LAN) device capable of communicating over, for example (and without limitation), an 802.11g network (i.e.,to communicate via Wi-Fi or a WiMax network. In one embodiment, incoming data from the mobile device can be routed via a data-over-voice or data plan through the onboard BLUETOOTH transceiver and into the vehicle's internal processor 3. In the case of, for example, certain temporary data, the data can be stored in the HDD or another storage medium 7 until the data is no longer needed. Other sources that can connect to the vehicle include a personal navigation device 54, which, for example, has a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB 62 or other connection, an onboard GPS device 24, or a remote navigation system (not shown) that has connectivity to the network 61. USB is one of a class of protocols for serial network connectivity. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the backbone of device-to-device serial standards. Most of the protocols can be implemented for either electrical or optical communication. Furthermore, the CPU could communicate with a variety of other auxiliary devices 65. These devices could be connected via a wireless 67 or wired 69 connection. The auxiliary device 65 could include, but is not limited to, personal media players, wireless health devices, portable computers, and the like. Alternatively, or in addition, the CPU could be connected to a vehicle-based wireless router 73 using, for example, a WLAN transceiver (IEEE 803.11) 71. This could allow the CPU to connect to remote networks within range of the local router 73. In addition to exemplary processes executed by a vehicle computer system located in a vehicle, in certain embodiments the exemplary processes can be executed by a computer system in communication with a vehicle computer system. Such a system may include, but is not limited to, a wireless device (e.g., and without limitation, a mobile phone) or a remote computer system (e.g., and without limitation, a server) connected by the wireless device. Together, such systems may be referred to as vehicle-associated computer systems (VACS). In certain embodiments, specific components of the VACS may execute specific portions of a process, depending on the particular implementation of the system.By way of example only, and not as a limitation, it is likely that if a process involves a step of sending or receiving information with a coupled wireless device, the wireless device will not perform this part of the process, since the wireless device would not "send and receive" information with itself. An average person skilled in the field will understand when it is appropriate to use a special computing system for a given solution. In each of the illustrative embodiments discussed herein, an exemplary, non-limiting example of a process executable by a computer system is presented. With respect to each process, it is possible for the computer system executing the process to be configured, for the limited purpose of executing the process, as a special-purpose processor for executing that process. None of the processes need be executed in their entirety, and it is understood that they are examples of process types that can be executed to achieve elements of the invention. Additional steps can be added to or removed from the exemplary processes as desired. The illustrative embodiments provide exemplary systems and procedures for learning driver selection to choose the vehicle mode. This provides prediction and selection of the driving mode (e.g., without limitation, Sport mode, Comfort mode, Snow mode, Gravel mode, Sand mode, Fuel Economy mode, etc.) based on previously observed driver behavior. In one embodiment, the prior selection of a particular mode at specific locations a sufficient number of times can be considered indicative of a driver's intention to activate that particular mode each time that location is reached. In other embodiments, the context (e.g., without limitation, passengers, weather, etc.) can be used to further refine the decision / prediction process. Based on predicted driver-based mode selection, the vehicle can automatically activate a driving mode that the driver is likely to manually select at a given location. This can improve both the convenience of mode selection and the overall driver experience. If the driver is highly engaged (utilizing a high level of driver attention), the predictive system can automatically activate the mode, relieving the driver of the need to add yet another consideration to an already overloaded mental workload. The illustrative embodiments utilize the detection, selection, and recording of frequent driver mode selections to assist in predicting upcoming mode selections and automatically releasing predicted modes. Regions and contextual conditions for specific mode selections can be learned over time by merging coordination information, contextual information, and real-time driver mode selection data. This learned data can then be used to automatically release modes at similar coordinates under similar conditions in the future. Fig. 2 shows an illustrative driver behavior learning and prediction system. The illustrative system shown in Fig. 2 has several inputs. These include the driver 201, the GPS coordinates from the telematics unit 203, and any relevant vehicle data used for context 205. In this example, the driver has the ability to change the driving modes at any time. This could include switching to a mode with enhanced traction on slippery roads, a sport driving mode for aggressive driving, an off-road mode for off-road driving or gravel / dirt roads, and so on. The driver can select which driving behavior / mode is desired or appropriate for changing road and weather conditions. Different mode selections may be made for the same locations / conditions based on different drivers and their individual preferences. Accordingly, it is not always possible to predict, using a universal mode, which mode a specific driver will want in a specific situation.While mass-collected data or a "best guess" analysis can be used to make a mode selection decision when limited driver-specific data is available for a particular driver, recognizing the individual driver's specific preferences over time can lead to more accurate mode release predictions. Entering a GPS location allows the recording of driving mode selections in relation to specific road / map coordinates. Certain road or driving conditions tend to persist in specific locations over time. If the driver activates a specific vehicle mode to deal with these conditions, assuming the conditions persist, there is a probability that the mode will be desired again at a later time. If the conditions have resolved or change, a decay factor associated with predictive learning can allow the mode selection to gradually decay to a point where it is no longer automatically released when the road segment is encountered. For example, if a driver activates off-road mode to deal with a section of road riddled with potholes, they will likely want to keep the mode active as long as the potholes persist. Repeated manual activation of the mode at the same GPS coordinates can be used as a basis for predicting that this mode will be desired at those coordinates. When the potholes are repaired, the driver can either stop manually selecting the mode or, if the automatic mode selection thresholds are met, decline automatic mode switching. Over time, the mode's availability at those coordinates will decrease relative to the threshold until the automatic activation threshold is no longer met.If the potholes reappear, accepting automatic activation and / or manual activation will increase the observed instances of mode release until the threshold is reached again or the observed level is maintained above the threshold. Vehicle data can also be used to assist in the decision to automatically activate a driving mode. This data, commonly known as "context," can provide a snapshot of the surrounding driving conditions, occupant composition, and so on. For example, if children are present in a vehicle, a driver may more frequently activate "conservative" driving modes, which may reduce power in the interest of more conservative driving. Similarly, if certain weather conditions are present, the vehicle may automatically activate an appropriate mode or prevent the activation of certain power-enhancing modes. Using the available inputs, the system can compile a data repository of vehicle driving mode context categories. This can include, for example, driving modes that have been activated at specific locations and / or driving modes that have been activated in specific contexts. The data can also represent a combination of location and context, such that at location X, driving mode N is only activated if context Y exists. Typically, this data will represent decisions to manually activate modes made by one or more drivers. Driver identification can also be used to differentiate between different driver preferences at specific locations for the same vehicle. In this way, a more cautious driver is not subjected to automatic switching based on the preferences of a more aggressive driver when driving the same vehicle at the same location. Based on observed driver behavior recorded over time,209 the system can engage in driver learning.211 This will use predictive algorithms to “guess” when a driver would typically activate a particular driving mode. Driver selections of driving modes based on road conditions and geometry generally have a high probability of occurrence (since these factors typically persist). Mode selections based on, for example, road geometry are likely to be repeated each time the driver is in the same location and in the same vehicle.Based on the frequency of manual mode selection, the locations of mode change / mode selection by a given driver or by all drivers of a vehicle can be identified (known driver identification techniques can be used to differentiate between different vehicle drivers, if desired). Once the probability of a mode selection, determined at least partially based on observed behavior, exceeds a tunable threshold at a given location, that location can be characterized as a site for driver-personalized mode switching. Environmental information can be used to further refine the prediction or, in some cases, can serve as the basis for automatic mode enabling or preventing mode selection (e.g., without limitation, enabling Snow mode under snowy conditions at a given location, preventing Sport mode in wet or icy conditions, etc.). The table below provides some exemplary mode selection data that can be used as a basis for understanding the illustrative implementations. KiesGPSlat 1, GPSlong1--L1 SnowGPSlat 2, GPSlong2SnowBelowFreezingPointL2 SportGPSlat 3, GPSlong3Rain~ Freezing point0 A driver selection learning algorithm can run on the vehicle's journeys in real time and can update the driver mode selection status. If a driver mode selection is made at a specific location (i), the GPS coordinates of that location can be stored, and an initial probability is given: Here, n is the number of detected locations and p0 is the initial probability of the selected driving mode. On future journeys, if the vehicle is driven through a similar area of ​​GPS coordinates as Li and the driver selects the same driving mode, the probability will be increased as in: If the driving mode is not selected (or in at least one case automatic selection of the driving mode is reversed or rejected), what is the probability of: In this context, α is a decaying factor. In another illustrative embodiment, the probability constants for p0in can be selected in the following form: Here, γ is the value during initialization and α is the corresponding update value. Whenever the probability of Lieinen reaches a predefined, tunable sensitivity threshold, based, for example, on the frequency of driver selection, the corresponding location is considered a high-probability location for mode changes. Conversely, if Lida falls below the threshold level, the location may no longer be considered a point where a mode change should occur. Information from the driver selection learning system module can be sent to a module for predicted personalized mode selection 213. The predictive personalized mode selection module can provide early information about upcoming high-demand situations. Whenever the probability of a situation reaching a predefined, tunable sensitivity threshold is reached, the corresponding location for the selected driving mode can be recorded. Then, when the vehicle approaches a GPS location identified by the driver selection learning module in future driving situations, the predictive personalized mode module can automatically select the appropriate mode, thereby amplifying the vehicle settings accordingly. In practice, the activation of a specific mode can be defined based on an aggregated number of mode occurrences or, for example, on a percentage of mode occurrences.For example, if a sample size with limited data is available for a given location, a minimum number of aggregated occurrences may be required to automatically activate a mode. Naturally, the choice of activation criteria is at the discretion of the implementer, and these examples are provided for illustrative purposes only. Fig. 3 shows an illustrative learning process. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor temporarily becomes active as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. During the execution of code that provides instructions for performing some or all of the steps of the procedure, the processor may be temporarily repurposed as a special-purpose processor until the procedure is completed. In another example, firmware acting in accordance with a pre-configured processor may, to a reasonable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a reasonable modification thereof. In the illustrative example shown in Fig. 3, the process waits until a driver mode selection is made 301. The vehicle will generally start in a basic mode or in the mode to which the vehicle was last put. If a manual mode change occurs 301, the process receives vehicle GPS coordinates 303 and any relevant context data 305. Depending on whether the mode was previously observed at this location and / or under the context (if any) received from the vehicle, the process can then either record a new instance of the mode setting or update an existing instance of the mode setting for this set of coordinates 307. As long as the new mode persists, coordinate and context data of the vehicle can be received and recorded, thus recording the use of the mode over a range of GPS coordinates. Once the mode reverts, the process can stop recording data (or recording data for the new mode) until another mode change is detected. In at least one example, a vehicle has a "base mode" for driving, to which the vehicle is generally set. Whenever the current mode is the base mode, the system can skip recording data, since the absence of data indicates the use of this mode. Whenever a non-base mode is detected, the system can record the relevant data for the duration of the non-base mode's use.Accordingly, if mode A is the basic mode and modes B and C are alternative modes, the GPS and context data could be recorded over the course of mode A, mode B, mode C, mode A, mode B, mode A for mode B, mode C and then again for mode B, and the data for the instances of mode A could be ignored. Data recorded for observed instances of mode switching can be stored in mode:location pairs or, for example, in a mode:location:context pair. In the mode:location pair model, mode usage is observed as a binary variable that is either on or off at a given location. To achieve a higher degree of specificity regarding mode prediction and release, the context can be included. This can help refine the contexts in which a particular mode is activated. Assuming that Mode A corresponds to the "basic" driving mode, Mode B to a sport driving mode, and Mode C to a driving mode with increased traction, it can be observed that Mode B is only activated in certain locations when the weather is not adverse. Furthermore, it can be observed that Mode B is never activated when children (identifiable by the vehicle's sensors) are present in the vehicle. Mode C may only be activated in certain locations in snow or rain and may never be activated in good weather. Using context can improve the prediction of conditional behavior. For example, if a driver passes through location i fifty times and activates mode C in one hundred percent of the seven instances where the road is icy, the driver will likely always have mode C activated at that location when the road is icy. However, because there were forty-three instances where mode C was not activated, a Mode:Location value might not be above a mode activation threshold because decay would tend to reduce overall usage to a point where it is less than likely that mode C will be activated at any given time for location i. In contrast, if the context (e.g., icy road in this case) is used, it can be observed that mode C is used in the context of icy road conditions one hundred percent of the time.Accordingly, if the road is currently smooth, mode C can be enabled the next time the vehicle reaches location i. Different types of context can be included in the mode ratings, as appropriate for a given model. Increasing the number of available context variables will improve accuracy with a sufficient sample size, but will also tend to provide a wider range of results from which inferences can be drawn. With insufficient sample sizes, this wide range of results can make meaningful predictive decisions difficult. Accordingly, in one example, it is possible to store the Mode:Location:Context data, but only examine the Mode:Location portion of the stored data until at least a meaningful set (determined by the implementer) of samples has been observed. Once a clear correlation between context and mode is observed, or a separation between context and mode is observed (i.e., it appears that the context has no influence on mode activation), the system can make more informed decisions by utilizing the context. For example, if context S (icy roads) is always present during mode activation and never present when the mode is not selected, it can be assumed that context M is usable for forming the mode prediction. Conversely, if context K (children present / occupant composition) is equally present during both mode selection and non-selection (within a tolerance), it can be assumed that context K has no influence on the mode prediction.If desired, contextual data from a variety of mode activation instances (for all modes or for a specific mode, across multiple different GPS coordinate locations) can be used to determine correlations between specific contexts and modes. Consequently, if only limited samples are available for a given coordinate location, but several locations have associated data, the system can more quickly infer the relevance of a particular context based on observed behavior at multiple locations in conjunction with a common context (e.g., road slipperiness). Fig. 4 shows an illustrative predictive driving mode activation process. Regarding the illustrative embodiments described in this figure, it should be noted that a general-purpose processor temporarily becomes active as a special-purpose processor for the purpose of executing some or all of the exemplary procedures shown herein. During the execution of code providing instructions for performing some or all of the steps of the procedure, the processor may be temporarily repurposed as a special-purpose processor until the completion of the procedure. In another example, firmware acting in accordance with a pre-configured processor may, to a reasonable extent, cause the processor to function as a special-purpose processor, provided for the purpose of executing the procedure or a reasonable modification thereof. In the illustrative example shown in Fig. 4, the process will attempt to predictively activate a driving mode (when appropriate). Accordingly, in this example, the process receives the GPS location data 401 and the current context data 403. The process then accesses the prediction module 405 to determine whether the current location data corresponds to the likely activation of a new driving mode 407. If the data do not indicate that a new mode should be selected (e.g., without restriction, insufficient data, no data above a threshold, or the data indicate that maintaining the current mode is desired), the process is repeated with later GPS and context data until a time at which a mode change is predicted. If the data indicate that past behavior under similar circumstances, or at least in a similar location, tends to indicate a desired mode change (e.g., observed behavior above a threshold), the process then determines whether the current context data is relevant for the potential new mode 409. For example, at a given location i1, a single mode can be selected ninety percent of the time, regardless of the context. Consequently, in this example, the context data does not appear to influence mode selection. But at another location i2, it can be observed that two new modes are selected a certain number of times, each with a different, and therefore highly correlated, context. Consequently, in this example, the context data may be relevant for mode selection. In another example of contextual relevance, certain driving modes can typically be enabled or disabled based on specific contexts (at least with regard to automatic activation). Therefore, if the data indicates that Mode B (Sport) or Mode C (Enhanced Traction) has been observed at a location i3, and Mode B is never automatically activated on slippery roads and / or Mode C is always automatically activated on slippery roads, a context indicating slippery roads can also be considered relevant for a final decision, regardless of whether the context was actually observed in the past regarding the activation of Mode B or Mode C for that particular location i3. If it is determined that the context has no meaningful influence on the mode prediction 409, the process will determine whether the instances of the previously observed mode release rise above the automatic activation threshold 411. If not, the process will be repeated for the next GPS location. If the observed behavior indicates a probability that the mode will be manually enabled 411, the process can automatically activate the predicted mode 413 for the current GPS location. Because there may be a decay factor associated with a mode not being manually enabled, or because automatic activation can contribute to the persistence of the mode, but the driver may no longer want the mode, this example process will notify the driver that the mode has been enabled 415. In another example, the process can provide the driver with an easily selectable option (e.g., selectable by touch or voice) to enable the mode. In this example, the driver has the option to return to a previous driving mode after the new mode has been enabled. If the driver returns to the previous mode (417), the process will treat the return as an instance of mode non-selection and may update the data with the return (421). In one model, this update is the same as passing the data point without enabling the mode, which is the application of decay. In another example, because the driver affirmatively undid the mode selection, accelerated decay may be applied due to the fact that the driver, for whatever reason, has explicitly determined that the prediction was incorrect. In addition to allowing for a suitable decay, the process can also temporarily disable the automatic mode-switching option. This prevents the system from attempting to switch back to the unwanted mode at the next coordinate instance. That is, if the driver no longer wanted Mode B over a one-mile stretch of road, and the mode prediction occurs every 0.1 miles, the process would avoid attempting to switch to Mode B every 0.1 miles, which might be annoying for the driver. Once the predetermined distance of continuous persistence of Mode B (based on previously observed behavior) has passed, the process could resume predicting the automatic mode switch. Returning to step 409, in this example, if the context is relevant for any reason, the process could attempt to determine which of the context data are useful for the current analysis (425). That is, since different contexts might be significant in different scenarios, a variety of context data could be collected and made available to the prediction process at any given time, even if only some of the context data are relevant to a given situation. After the relevant context data has been extracted, the process determines whether the context data specifies a scenario of continuous activation. For example, if a driver first purchases a vehicle, the vehicle may be configured such that certain contexts always result in the activation of specific driving modes. Accordingly, either for a specific location or generally for all locations, the occurrence of, for example, the context "slippery road surface" may initially always result in the activation of enhanced traction control, or, for example, always result in the activation of enhanced traction control at road points with known characteristics (e.g., sharp curves, high-speed limits, demanding geometry).Accordingly, in this example, when a present location corresponding to a known characteristic is encountered for the first time (or has been encountered a limited number of times, such that the data on observed behavior is insufficient to make an informed, driver-personalized decision), a preset mode change may exist for that location. In other words, even if there is insufficient personal driver data to dictate a mode change at that location, the known characteristics initially predetermine a mode change, in this example in conjunction with the context of road slipperiness. Although the mode can be changed automatically, the driver might not actually want the mode changed at that location, regardless of the context. Accordingly, in this example, if the mode is changed automatically based on the specific context (and, in this example, the specific location), the process can activate the previously discussed driver notification / return / update process. That is, if the driver consents to the mode change (i.e., does not revert to the previous mode), the process updates the mode change affirmatively as specific observed driver behavior. If the driver reverts to the previous mode, the process can either decay or, otherwise, negatively update the mode change as specific observed driver behavior.In this way, automatic mode switching based on specific contexts, as set by an original equipment manufacturer (OEM), can still be adapted to the wishes of a particular driver. Similarly, there may be certain contexts that are preset to automatically block a mode change, such as icy roads when a Sport mode is predicted. The previously observed context may not provide any indication as to whether a mode was enabled based on a previously observed context. For example, the weather was good on all previously observed instances of reaching the current coordinates. While a Sport mode was always selected, there is therefore nothing to indicate whether such a mode would be selected if the weather caused icy roads. Accordingly, the OEM can specify initial blocking contexts for the activation of certain modes (429). As with the contexts for automatic activation, the contexts for automatic blocking can be tailored over time based on driver preferences. In the example above, if the automatic activation of a Sport mode is blocked based on the occurrence of the context "Icy Roads" 431, the driver can be notified that the predicted context swap did not occur 433. If the driver manually changes the driving mode to Sport mode anyway 435, the process can update the "Icy Roads Location:Mode:Context" data for that location 437 so that, with sufficient observations at that location, Sport mode will no longer be blocked, even if icy roads are present. If, however, the driver does not manually change the mode to Sport mode, this is considered consent to the locking, which is understood as an indication that the locking is accepted and that the driver prefers either the basic mode or another contextually appropriate mode (if another mode is manually selected by the driver). In this case, the location:mode:context data for road slipperiness and Sport mode at that location may decay, so that the correspondence between context, mode, and location in future instances is or remains below the threshold. Acceptance of automatic locking in the given context could additionally or alternatively be positively updated 439 to confirm / reinforce the locking of Sport modes (at that location or at any number of locations) based on the "road slipperiness" context. Of course, it is also possible to always block or always activate certain modes under specific conditions, regardless of driver preferences. In these cases, the driver would simply need to manually activate a different mode if desired. However, by using context, location information, and observed driver behavior at the relevant contexts and locations, it is generally possible to predict driver mode changes with a high degree of accuracy once sufficient data has been obtained. The level of data considered "sufficient" can be set based on the specific requirements of the implementer and can range from a single instance to just a few instances from which further predictions can be derived. While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the patent specification are descriptive and not limitative, and it is understood that various modifications can be made without altering the essence and scope of protection of the invention. Furthermore, the features of the different implementing embodiments can be combined to form further embodiments of the invention.

Claims

System comprising: a processor configured to: receive a vehicle location; retrieve driver-specific driving mode change data for the vehicle location; determine, based on the retrieved data, whether a vehicle driving mode change has occurred sufficiently at the vehicle location to exceed a predefined threshold;and automatic switching of a vehicle driving mode to a driving mode associated with the driving mode change that has occurred previously sufficiently to exceed the predefined threshold, wherein the processor is further configured to receive a vehicle context, and wherein the processor is configured to determine whether the vehicle driving mode change has previously occurred sufficiently at the vehicle location under at least one aspect of the received context to exceed the predefined threshold, wherein the at least one aspect of the received context includes the current occupant composition. System according to claim 1, wherein the at least one aspect of the received context includes current weather conditions. System according to claim 1, wherein the threshold is based on an aggregated number of occurrences. System comprising: a processor configured to: receive a vehicle location; retrieve driver-specific driving mode change data for the vehicle location; determine, based on the retrieved data, whether a vehicle driving mode change has occurred previously at the vehicle location sufficiently to exceed a predefined threshold; and automatically switch a vehicle driving mode to a driving mode associated with the driving mode change that has occurred previously sufficiently to exceed the predefined threshold, the threshold being based on a percentage of occurrences in relation to a number of times the vehicle has been located at the vehicle location. System according to claim 1, wherein the processor is further configured to receive a vehicle context, and wherein the processor is further configured to block a driving mode change which would otherwise be automatically activated as a result of the driving mode change having occurred previously sufficiently to exceed the threshold, wherein the blocking is based on at least one aspect of the received context. System according to claim 5, wherein the at least one aspect includes a weather condition. A computer-implemented method comprising: receiving a vehicle location; retrieving driver-specific driving mode change data for the vehicle location; determining, based on the retrieved data, whether a vehicle driving mode change has occurred previously at the vehicle location sufficiently to exceed a predefined threshold; and automatically switching a vehicle driving mode to a driving mode resulting from the driving mode change that has occurred previously sufficiently to exceed the predefined threshold; the method further comprising receiving a vehicle context, and wherein the determining includes determining whether the vehicle driving mode change has occurred previously sufficiently at the vehicle location under at least one aspect of the received context to exceed the predefined threshold, wherein the at least one aspect of the received context includes the current occupant composition. Method according to claim 7, wherein the at least one aspect of the received context includes current weather conditions. Method according to claim 7, wherein the threshold is based on an aggregated number of occurrences. A computer-implemented method comprising: receiving a vehicle location; retrieving driver-specific driving mode change data for the vehicle location; determining, based on the retrieved data, whether a vehicle driving mode change has occurred previously at the vehicle location sufficiently to exceed a predefined threshold; and automatically switching a vehicle driving mode to a driving mode resulting from the driving mode change that has occurred previously sufficiently to exceed the predefined threshold, the threshold being based on a percentage of occurrences with respect to a number of times the vehicle has been located at the received vehicle location. The method of claim 7, further comprising receiving a vehicle context and blocking a driving mode change which would otherwise be automatically activated as a result of the driving mode change having occurred previously sufficiently to exceed the threshold, wherein the blocking is based on at least one aspect of the received context. Method according to claim 11, wherein the at least one aspect includes a weather condition. System comprising: a processor configured to: receive a driver input indicating a vehicle driving mode change; receive a vehicle location; and store an instance of the correspondence between the vehicle driving mode change and the vehicle location, the processor further being configured to update a value of an occurrence probability variable representing a present and past reception of the driver input indicating a vehicle driving mode change at the received vehicle location as part of the storage of the instance of the correspondence. System according to claim 13, wherein the processor is further configured to receive a vehicle context and to store at least one aspect of the vehicle context in relation to the instance of correspondence, such that the instance of correspondence is between the at least one aspect of the vehicle context, the vehicle driving mode change and the vehicle location. System according to claim 13, wherein the processor is further configured to allow the value of the variable indicating an instance of no correspondence between vehicle driving mode change and vehicle location to decay when the processor receives a vehicle location for which a value of an occurrence probability variable was previously updated, without receiving driver input indicating a vehicle driving mode change.

Images