DE102015206263A1 - APPLICATION FORECASTS FOR CONTEXTIC INTERFACES - Google Patents

Abstract

A vehicle interface system may include an interface configured to display icons representing selectable vehicle functions; and a controller programmed to generate a score for each of the functions based on a context variable, including a vehicle location and / or a vehicle speed and / or a previous feature application information and / or a predicted one End location for the vehicle, and based on the scores generated to display certain of the icons and hide other of the icons.

Description

The present disclosure relates to application prediction for a contextual interface.

A conventional vehicle includes many systems that allow a user to interact with the vehicle. In particular, conventional vehicles provide a variety of devices and techniques to control and monitor the various subsystems and functions of the vehicle. As technology advances, more and more functions are introduced to control various subsystems within the vehicle. Some of these functions can be demonstrated to the driver via a user interface. However, these functions can only be demonstrated to the user in a defined manner. Therefore, an improved and flexible system is needed to show the user vehicle functions.

A vehicle interface system may include an interface configured to show icons representing selectable vehicle functions; and a control unit programmed to generate a score for each of the functions based on a context variable, including one or all of a vehicle location, a vehicle speed, and a predicted end location for the vehicle, and determined based on the generated scores Display glyphs and hide other glyphs.

A vehicle controller may include at least one contextual module configured to generate at least one context variable representing a driving context including vehicle location or vehicle speed, and a processor programmed to generate a functional score based on a vehicle location and / or or a vehicle speed as defined by the at least one context variable, wherein the function score represents the likelihood that the vehicle function will be selected based on the driving context, and based on the scores generated, display certain of the icons and other of the icons to hide.

A method may include receiving at least one context variable from a context module, generating a function score based on at least one context variable, and displaying an icon associated with a vehicle function that corresponds to a score on the score Interface device is based, wherein the icon is configured to interact with a system that is associated with the corresponding vehicle function.

1A illustrates exemplary components of the user interface system;

1B FIG. 12 is a block diagram of exemplary components in the user interface system of FIG 1A ;

2 FIG. 3 illustrates a flowchart of an example method that may be implemented by the user interface system; FIG.

3 provides a block diagram of a possible implementation of the user interface system of 1A group;

4 FIG. 3 illustrates a flow chart of a possible implementation that may be performed by the user interface system of FIG 3 can be executed;

5 FIG. 4 illustrates a flowchart of an alternative implementation implemented by the user interface system of FIG 3 can be executed;

6 FIG. 10 illustrates an exemplary location database generated by the user interface system of FIG 1A can be used;

7A FIG. 12 illustrates a diagram of an example score as an indication of the likelihood of the output by the example components of the user interface system of FIG 1A to stop;

7B FIG. 12 illustrates a diagram of an example score as an indication of the likelihood of the output by the example components of the user interface system of FIG 1A to stop;

8th illustrates an exemplary block diagram for generating a function score;

9A -C are exemplary data diagrams as an indication of context variables for generating a function score; and

10 represents an exemplary flowchart for generating a function score.

As required, detailed embodiments of the present invention are disclosed herein; It should be understood, however, that the disclosed embodiments are merely exemplary of the invention, which is described in different and alternative forms can be expressed. The figures are not necessarily a true to scale representation; some features may be enlarged or reduced to show details of specific components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art the various uses of the present invention.

Vehicle interface systems may provide the user with various options for accessing and interacting with vehicle systems. These systems may include air conditioners, navigation systems, parking systems, etc. Each system may provide various vehicle functions, such as cruise control, driving directions, parking aids, etc. At certain times, when the vehicle is in use, certain of these functions are more likely to be relevant to the current driving conditions than others. For example, when the vehicle is traveling at high speed, it is more likely that the driver will use the cruise control function and less likely that the driver would use the park assist function. As another example, if the vehicle is under 20 miles per hour, it may not be possible to use the cruise control function. In that case, the inability to use this feature may result in it being hidden from the driver. Based on the driving context, a vehicle interface system may use this probable probability to assist in displaying certain functions on the user interface within the vehicle. That Certain icons associated with the vehicle functions may be displayed or hidden based on the likelihood that they will be selected by the user for an application. Thus, the user can easily perceive and select relevant functions. Functions that are unlikely or impossible in their application may not be displayed so as not to overload the driver with unnecessary options during driving. In the example of the parking function (for example, parking aid, reversing cameras), certain variables can be used to develop a function score. For example, the distance between the current location and the destination may be used to determine the likelihood that the driver will apply a parking function. Moreover, the frequency with which the driver previously selected the function at the destination, as well as the vehicle's current vehicle speed, can also be used to determine a functional score and to support the user interface parking function accordingly. In addition, the current status of the function can be observed. If the feature is already in use, there is no need to support this feature.

A vehicle system may include a controller configured to receive a sensor input. The controller may generate a functional score based at least in part on the sensor input and location data within a database. The control unit can assign the functional evaluation to a selectable option. The controller may instruct a user interface device to display the selectable option in response to the feature score, thereby allowing the user to view options that may be of interest based on multiple attributes, such as sensor input and location data , In one example, the selectable options may be a parking assistance option and / or a valet parking option. The Park Assist option, when selected, can automatically assist drivers in parking their vehicles. That The vehicle can steer itself into a parking space, park one behind the other or next to each other, with little or no input from the user. In another example, a parking service option may be available. Valet parking can be activated next to specific locations with valet parking, such as hotels, restaurants, bars, etc. Thus, the exemplary system may detect when a vehicle is approaching a location where a user may be using both the parking assistance option and the parking service option. These options may be preferred over other vehicle functions, such as cruise control, and presented to the user via the user interface device. Parking service mode may disable or dim the display screens within the vehicle, so that personal information and priorities may be inaccessible to the driver performing the parking service. The park service mode feature is generally implemented within a system that includes navigation systems and infotainment systems. Such information, such as the home address of the vehicle owner, would be unavailable to unauthorized drivers.

1A illustrates an exemplary user interface system. The system may take various forms and include multiple and / or alternative components and devices. While an exemplary system is shown in the figures, the exemplary components shown in the figures are not intended to be limiting understood. And indeed, additional or alternative components and / or implementations may be applied.

1A represents a diagram of the user interface system 100 While the present embodiment may be practiced in a motor vehicle, the user interface system 100 can also be used in any vehicle, including but not limited to motorcycles, boats, airplanes, helicopters, off-road vehicles, trucks, etc.

With reference to the 1A and 1B includes the system 100 a user interface device 105 , The user interface device 105 may include a single interface, such as a one-touch screen, or multiple interfaces. The user interface system 100 may additionally include a single interface or multiple interface types (eg, audio and video) configured for human-machine interaction. The interface device 105 may include a display, such as a touch screen. It can also include a display controlled by various hardware controls. The interface device 105 may also include a head-up display (HUD) unit in which images are projected onto the windshield of the vehicle. The user interface device 105 may be configured to receive user input from the vehicle occupants. The user interface device may include, for example, control buttons and / or control buttons displayed on a touch screen display (eg, physical buttons and / or function buttons) that allow the user to provide commands and information for use by the user interface system 100 enter. The user interface device 105 provided inputs can be sent to the control unit 110 for controlling various aspects of the vehicle. For example, those of the user interface device 105 provided inputs by the control unit 110 be used to monitor the climate in the vehicle to interact with a navigation system, to control the media playback, to take parking assistance and the like. The user interface device 105 may also include a microphone that allows the user to enter commands and other information about the voice.

With the user interface device 105 communicates a control unit 110 , The control unit 110 may include any computing device configured to execute computer readable instructions that, as discussed herein, the user interface device 105 controls. For example, the control unit 110 a processor 115 include, a contextual module 120 and an external data store 130 , The external data store 130 may be a flash memory, RAM, EPROM, EEPROM, hard disk drive or other type of memory or a combination thereof. Alternatively, the contextual module 120 and the external data store 130 be included in the processor. Yet another embodiment may include multiple controllers that communicate with each other, each one processor 115 , a context module 120 and an external data store 130 contains. The control unit 110 can in the user interface device 105 be integrated or appear separately.

In general, computing systems and / or devices, such as the control unit, may be used 110 and the user interface device 105 , Employ any number of computer operating systems including, but not limited to versions and / or different types of Microsoft Windows ^® operating system, the Unix operating system (for example, by Oracle Corporation of Redwood Shores, California, Solaris widespread ^® operating system), the by International Business Machines of Armonk, New York, has been distributing AIX UNIX operating system, the Mac OS X and iOS operating system distributed by Apple, Inc. of Cupertino, California, the Blackberry OS distributed by Research in Motion of Waterloo, Canada Android operating system developed by the Open Handset Alliance. It will be apparent to those skilled in the art from the disclosure that the precise hardware and software for the user interface device 105 and the control unit 110 may be any combination sufficient to carry out the functions of the embodiments discussed herein.

The control unit 110 may be configured, the availability of a function on the user interface device 105 over the processor 115 to control. The processor 115 may be configured to detect a user input indicating the user's desire to control a vehicle system or subsystem by detecting the selection of a selectable option on the user interface device 105 to activate. There is a selectable option for each function available in the vehicle (eg temperature control, seat heating, parking aids, cruise control, etc.). Each selectable option can control a vehicle system or subsystem. For example, the selectable option for vehicle speed control becomes Control vehicle system that monitors the constant speed of the vehicle (or vehicle speed control). Further, each selectable option may control more than one vehicle system. For example, a user may select a selectable option that is associated with driving assistance technology. This selection can control a park assist function as well as enable the activation of certain rear view cameras. The selectable option may include a glyph for display on the interface. It may also include a textual description of the vehicle function that controls the corresponding option among other pictorial representations.

The control unit 110 , about the processor 115 , may be configured to determine, in a particular driving context, the functions that are most likely to be beneficial to the driver or passenger, and to remove the functions that are of minimal or no benefit to the driver / occupant. To determine the function that can be of paramount importance at the moment, the control unit can 110 receive an input from a variety of contextual variables through the context module 120 and the base sensor 135 be communicated via an interface (not shown). The interfaces may include an input / output system configured to transmit and receive data from the respective components. The interface can be unidirectional, so data can only be transmitted in one direction. In addition, the interface can be bidirectional for receiving and transferring data between components.

The control unit can have many context modules 120 each configured to output a specific context or context variable. For example, a context module 120 be configured to determine the distance to a known location. Another context module 120 may be configured to determine the vehicle speed in relation to the current speed limit. Yet another context module may be configured to determine if the vehicle enters a new jurisdiction requiring different driving regulations (eg, a "hands-free" driving zone). In another example, a context module may be configured to a data store 130 to determine how often a particular vehicle function is applied to a particular location. In another example representation, each output may be received by any of the many selectable options, and may be used and reused by the selectable options for creating a function score. That means each of the many context modules 120 always performs the same operation. For example, the context module becomes 120 for the vehicle speed relative to the current speed limit always output this context, although the context of different selectable options can be received. A context variable may also use vehicle and vehicle module specific information to output a context score. For example, the park assist feature may not be functional / selectable unless the vehicle speed is less than 10 miles per hour. In this context, the output context score also encodes the configuration of a vehicle subsystem and or physical limitations that are operable and available to the driver / passenger.

A context variable may represent a particular driving condition, such as the vehicle speed or a previous location where the driver has activated a function. The context variables can be from the context module 120 or the basic sensor 135 be issued. The control unit 110 may be configured to select a function that has a high probability of vehicle-user interaction being that of the context module 120 and the base sensors 135 received input based. For example, the control unit 110 indicate that the vehicle speed control function may be of particular importance due to the driving context or circumstance. In an exemplary approach, each will be on the user interface device 105 available function represented by a specific selectable option. For example, the function for a garage door opener may always be associated with a selectable option for the garage door opener.

The context variables may be a driving context dependent numeric value. In one possible implementation, the context variables extend from a value of 0 to 1, where 1 represents the strongest value. In addition, or alternatively, the contextual variables may represent a particular context, such as outside temperature, precipitation, or distance to a particular location or destination. For example, the context variable output may indicate that the vehicle is approaching a locality that offers valet parking.

The output may indicate that the vehicle is approaching a parking garage, a parking lot, or a parking area on the street. There can be two types of context variables: simple context variables and intelligent context variables. Simple context variables can be from the base sensor 135 be derived. A basic sensor 135 can be any available in the vehicle Sensor or sensor systems include. For example, the base sensor could 135 Audio sensors, light sensors, accelerometers, speedometers, temperature sensors, navigation sensors (eg, a satellite navigation system sensor), etc. Intelligent context variables can be accessed through the context module 120 and may represent other contextual variables that are aggregated into values that are not readily available in the vehicle. That is, no other system or subsystem within the vehicle can generate an intelligent contextual variable alone. For example, the context module 120 To create the intelligent context variables, inputs from both the output of simple context variables by the base sensors 135 as well as the output of other intelligent context variables by the context modules 120 and aggregate these outputs into complex values (for example, multivalued aggregations). The context module can create their values in various ways. For example, methods may involve simple or advanced algebraic calculations, fuzzy logic, neural networks, statistics, frequentist interference, etc.

The control unit 110 can store the location data stored in a database, for example an external data store 130 , include. The external data store 130 can be inside the control unit 110 or attached as a separate component. The location data may include stop location data, such as previous stopping locations of the vehicle, or include selectable option data, such as the number of times a selectable option at an earlier stop location (eg, a site-based feature usage ) has been activated. For a park location, publicly available information, such as toll-free and / or applicable parking charges, may be available. The location data may also include interest point data, such as parking service points of interest indicating parking service providing locations (eg, restaurants, hotels, conference halls, etc.). Interest point data may additionally include the user preference for a given situation, such as a crowded location versus a remote location. For example, the user sets his or her preference for valet parking restaurants, which may affect the functional rating associated with each selectable option. While the data store 130 in the control unit 110 can be included, he may also be far away from the control unit 110 be attached and can with the control unit 110 communicate over a network, for example via cloud computing resources or APIs (Application Programming Interface) (APIs) over the Internet.

The processor 115 can be configured with the external data storage 130 whenever stored information is required to assist in the creation of a selectable option. The external data store 130 can with the context module 125 communicate to create an intelligent context variable. Similarly, the external data store 130 directly with the processor 115 communicate. The external data store 130 may be composed of general information, for example, from a navigation database storing, for example, road and legal regulations, or user-specific information, such as the vehicle's preferred interior temperature. In addition, or alternatively, the external data memory 130 Track vehicle function activations at specific locations or under certain driving conditions. For example, the external data memory may store the number of cruise control activations on a particular highway. This, in turn, may affect the functional rating for vehicle speed control when the vehicle is traveling on this highway. Furthermore, the external data memory 130 for example, by the application of telematics or by another suitable method. An in-vehicle telematics system may be configured to receive updates from a server or other appropriate source (eg, a vehicle dealer operation). Similarly, the external data store 130 manually updated with the input from the vehicle user, that of the user interface device 105 provided. Moreover, the control unit 110 be configured to the user interface system 100 allow communication with a mobile device over a wireless network. Such a network may include a wireless telephone, etc., Bluetooth ^®, a personal digital assistant, 3G and 4G broadband devices.

In an exemplary illustration, the user interface device 105 allow a user to specify certain preferences regarding a location. A user may set a preference for locations providing valet parking or offering a remote dining spot. These preferences can be stored in external data storage 130 (for example, as a point of interest) and can be saved through the context module 120 . 125 applied to affect the context variable output. For example, the function score for the Park service mode at a particular location (for example, producing a higher functional score) when the user sets his / her preference for inclusion of the park service mode, regardless of whether the user has previously stopped at that location. Thus, a previous stop at a locality is not necessarily required to create a high functional score if the user preferences are somewhat customized in some way.

The processor 115 can be configured by the context module 120 detected inputs, such as the context variables. The processor 115 can store any selectable option associated with a specific function for the application through the user interface device 105 is available. Each selectable option takes the input from a range of contextual variables, from a base sensor 135 and the context module 120 be generated. The processor 115 aggregates the received variables to generate a function score associated with the selectable options, indicating the likelihood of interaction of the particular function with the user. Thus, each selectable option is assigned to a function score. However, the function scores associated with the selectable options may vary depending on the driving conditions and context. Many implementations may be used to aggregate the context variables, such as, but not limited to, the formation of the product, summation, mean, or nonlinear algorithms, such as fuzzy logic. In one embodiment, the processor 115 assign a decimal function score from 0 to 1 to the selectable option, where 0 represents a low probability of the function being selected at the moment, and 1 represents the high probability that the user wants to apply the function. Thus, a function already in use (for example, the vehicle system or subsystem is currently being applied) would be scored low on the decimal system because there is no chance of future interaction with the function. However, this selection may be changed by the driver or manufacturer, so that 1 means that the user is actively interacting with the function. Furthermore, the decimal range is illustrative only and a different range of numbers could be applied if desired.

The processor 115 generates a functional score and subsequently the processor can 115 the functional rating to the user interface device 105 transport. Based on the preference of the driver or the manufacturer, the processor 115 the selectable option with the highest score for display on the user interface device 105 choose. The highest function score may be representative of the preferred selectable option or function being selected. That is, the selectable option associated with the highest score may be the preferred feature. In an alternative embodiment, the processor 115 Rank the selectable options based on their function scores and select multiple functions with the highest scores on the user interface device 105 to be displayed. Selectable options associated with lower scores may be hidden or from the user interface device 105 be removed. The via the user interface device 105 Displayed glyphs may change continuously as the function scores associated with each change.

In a specific example, a parking function, such as an active parking aid for in-line parking, or a general parking function using rear view camera views may be available to the vehicle for side-by-side parking. Parking functions are likely to be applied at certain locations, certain geographic areas (for example, in the city, in the city center, near popular venues, etc.), at certain times of the day, etc. Moreover, parking functions are more likely to be applied when the vehicle is moving at a lower speed. In this exemplary illustration, a base sensor (eg, a base sensor 135 ) output the current location of the vehicle (via GPS, for example). Another basic sensor (for example, the basic sensor 140 ) can output the speed of the vehicle. Both of these outputs can be simple contextual variables. The simple context variable speed and location can be determined by the context module 120 be received. The context module 120 can use the current location to get additional intelligent context variables. In one example, the current location may be used to determine possible end locations (eg, the desired destination). These end locations can be entered by the user using the navigation system. They can also be experienced or predicted locations. The predicted end locations can be compared to the current location. The end location that is closest to the current location can be selected and evaluated. The context module 120 . 125 can apply the end site to see what kind of features the user has previously selected at the end site. Ie at the end location has the User previously applied a parking function. In addition, the context module 120 . 125 receive these context variables as well as other variables. In one example, the context module 120 . 125 receive public parking data indicating a parking facility near the current location. These variables can be assigned to the processor 115 which can transmit a functional score for each option selectable in relation to a particular driving context. In one example, if the vehicle is near a location for which the vehicle is typically applying a parking function but is traveling at high speed, the driving context may be given a low score (eg, 0.3). In another example, the driving context may be given a higher score (eg, 0.8) when the vehicle is traveling at a lower speed. The processor 115 can select the highest scoring option (s) to display on the user interface device 105 display. The selectable option can replace current options if the function score assigned to the selectable option exceeds the function score of the currently displayed options.

With reference to the above example, the system 100 apply a current vehicle location, and an end location, and a vehicle speed to determine a functional score for a parking function. The end location may be a user-desired destination. The end location may be through the context module 120 . 125 be determined. It may also be determined by another component (for example, the GPS system) in response to the user input. As discussed, the final location may also be a predicted destination or location. The predicted destination may be determined based on a dynamic learning and prediction module. The module may be able to learn and re-code various stop and start habits, and often visited locations may be recognized without user input. The prediction module may take into account various factors, such as time of day, day of the week, etc. Thus, when the vehicle is moving on a recognized route, the module may predict that the final location is one of a handful of probable destinations, based on the history of the user and / or the vehicle. Further, the predicted location may be a location where the user has previously used a parking function. These important pre-parking locations may be identified by a user, within the data memory described herein 130 is displayed.

The end location can also be used to determine a possible external parking location. The external parking location may differ from the end location in that the parking location may be a parking garage or a parking lot near the end location. The external parking locations can be from the data store 130 or other locations, such as from a mobile device via wireless communication or a dedicated channel. For example, a map application within a mobile device may be the processor 115 and / or the context module 120 . 125 Provide nearby parking facilities. A local city map, which provides various parking facilities, can also be used. The data store 130 may also include a database of available parking facilities. Thus, the external parking facilities through the data memory 130 or any other component in or out of the interface system 100 to be provided. In some situations, external parking may come from a public source as well as a private database.

1B illustrates a general system interaction of one embodiment of the user interface system 100 Initially, the control unit receives an input from the base sensors 135 and 140 collecting information from sensors or sensor systems available on the vehicle and outputting simple context variables. For example, the base sensor could represent the current outside temperature, a vehicle speed sensor, or a vehicle GPS location. The context modules 120 and 125 can be simple context variables, other intelligent context variables, and / or location data from the external data store 130 received to create intelligent context variables. Location data from the external data store 130 may include the parking facilities received from a public source as well as those received from a private database. The processor 115 can receive both the smart context variables and the simple context variables to attribute their values to multiple selectable options. The selectable options are each assigned to a function score, which is generated from the values of the received context variables. Each selectable option continuously receives input from the base sensors and the context modules. However, depending on the driving context, the functional scores associated with the selectable options vary. For example, if the context variables communicate that the vehicle is traveling at near top speed on a highway, the selectable option for the cruise control feature will provide a high score during the seat heater or garage door opener feature will create a low functional rating.

The processor 115 can rank the selectable options according to their functional rating. The processor 115 can select the highest value selection option. Depending on how the user interface system 100 is configured, the processor can 115 either the highest-scoring option that can be selected or multiple user-interface device selectable options 105 transport. At the same time, the processor 115 (a) function (s) from the user interface device 105 eliminate where a user interaction is no longer likely. The basic sensors 135 . 140 and context modules 120 . 125 are always active to facilitate making a running feature score for each selectable option. The processor 115 uses these scores to the user interface device 105 to provide the most current driving contexts so that the selectable option with the highest functional score is always on the user interface device 105 is shown.

2 FIG. 3 illustrates a flowchart of an example method. FIG 200 This is done by the user interface system 100 can be implemented. The operation of the user interface system 100 can (data block 205 ) at the latest at the time when the ignition of the vehicle is switched on, automatically activate. At this point, the vehicle may undergo an internal system check in which the operating state of one or more vehicle systems and / or subsystems will be determined to ensure that the vehicle is operational. While the internal system check is verified, the system can 100 additionally the categorization of the data block in the vehicle 210 determine available selectable options. The system 100 Additionally, the available functions (and their corresponding selectable options) of the user interface system 100 into a departure group and an arrival group. The departure category may include functions that are frequently used when leaving a location, such as a garage door opener or climate control. The arrival group may include functions that are frequently used on the way to or on arrival at a destination, such as a cruise control or a parking aid. The categorization procedure may be performed by the control unit 110 be executed. The functional division may be dictated by either the manufacturer or dealer, or the vehicle owner may customize the departure and arrival group based on the preference. Splitting the functions into two or more groups can help reduce processing time in the more advanced stages by limiting the number of functions available for selection.

At data block 215 can the system 100 start by the base sensors 135 and the context modules 120 Monitor generated context variables. As previously mentioned, the context variables may be either simple context variables derived directly from sensors available in the vehicle, or intelligent contextual variables derived from aggregations of other (simpler or more intelligent) contextual variables that are not without Further values available in the vehicle can be derived. The system 100 can also check for additional external information at data block 220 from the external data store 130 required are. This can occur where the context variables require stored information, such as road speed limits, location data, or vehicle user room temperature preference of the vehicle user. If additional external information is required, the information about the context modules can be found 120 be routed to create an intelligent context variable. If no additional external information is required, or has already been provided, and no information is required, the procedure may 200 at data block 225 to be continued.

At data block 225 The context variables can be used by the processor 115 be communicated to create a functional score. The processor 115 can aggregate the received inputs (for example, the context variables) and map the values of each selectable option to create the function score. The function scores may be created by aggregating the context variables, by forming the product, the average, the maximum, the minimum, etc., or any combination or variation, or any nonlinear algorithm, such as fuzzy logic. The functional score can be directly proportional to the relevance of the aggregation of the processor 115 be transmitted context variables. For example, if the context variables indicate that a vehicle is traveling on a highway at a relative speed that is close to the speed limit, but notice that the vehicle speed varies above and below the speed limit (for example, as in the case of heavy traffic), For example, the function score for the vehicle speed control selectable option will have a lower value compared to when the vehicle is traveling at a steady speed near the speed limit for some time. Moreover, the parking assistance For example, the same variables associated with the selection option have a very low functional rating, for example, since the probability of using a parking function during a high-speed drive is very low.

At data block 230 can the processor 115 prioritize the selectable options based on their associated performance scores. In general, the highest-scoring options that can be selected will have the highest priority, and the remaining available selectable options will be ranked accordingly. Depending on the user preference, either the function with the highest function rating or multiple functions (for example, the three functions with the highest function rating) may be the user interface device 105 at data block 235 ascend for display and execution. Similarly, those on the user interface device 105 functions already displayed are removed (or demoted) at the same time, if their meaning has decreased within the particular driving context. Additionally or alternatively, the processor may 115 or the control unit 110 Arrange the selectable options according to the function score assigned to each selectable option. The control unit 110 can then determine the arrangement of selectable options with function scores over a predetermined threshold. For example, the control unit 110 select only the selectable options with a function score of or greater than 0.7. The control unit 110 can then place the available selectable options with the highest score in a first place in order, and another selectable option with a slightly lower score in second order in order, and so on.

As shown, the data blocks run 215 to 225 a continuous cycle while the vehicle is in operation. The basic sensors 135 and context modules 120 are active at all times, and continually enter information into the processor that continuously generates new function scores. Accordingly, the processor updates 115 the priority rankings in data block 230 So that the most important functions at all times on the user interface device 105 at data block 235 to be shown.

In at least one embodiment of the disclosure, the user interface system 100 determine a selectable option based on received sensor inputs and location data. The location data may include past stop sites and site-based feature usage. The selectable option may generally be activated based on the location of the vehicle with respect to other known or previously defined locations. For example, the present disclosure provides the system and method for creating the selectable option for the park assist and park service modes, both of which are activated upon approaching specific locations (eg, car parks, office buildings, or restaurants). The parking aid is an available vehicle function that activates the vehicle system to automatically assist drivers in parking their vehicle. That is, the vehicle can control itself in a parking lot, park one behind the other or next to each other, with little or no input from the user. The parking service mode or option is a similar feature that is activated near specific locations, such as hotels, restaurants, bars, etc. that include valet parking. Activation of the parking service mode option vehicle system may disable components of the vehicle (eg, the user interface device, the glove box, the vehicle trunk) such that the valet parking operator does not have access to private information stored within the vehicle can. The parking service option can be realized by the part of the control unit 110 in that the vehicle is approaching a locality with a valet parking service. This may be due to stored data that relates to a locality within the external data store 335 be known.

The location-based options may be associated with a normalized usage frequency to indicate the number of times a selectable option has been activated at a particular location. The normalized usage frequency can be determined by the control unit 110 be determined. The value of the normalized frequency of use (F _AF (i, j)) can be achieved by a two-stage implementation. At the beginning, when the number of assessments and observations is limited, a true value of the normalized frequency is created using the first implementation. That is, before a predefined minimum number of assessments of a site is met (N _min ), the total number of functional activations of a specific function at a specific site is divided by the total number of assessments of that site to reflect the true value of the frequency with which a function is pending a location has been activated. The minimum threshold can be used to include a larger sample of functional activation observations at a specific location to provide a more accurate percentage. A minimum number of reviews may be in the external data store 335 include defined value and can by the Vehicle manufacturer, dealer or possibly vehicle driver.

The mode of actual application, or a percentage of how often a function is applied to a specific location, may indicate the actual frequency with which a function has been applied to a specific location. N (i, j) _a represents the number of function activations at a specific location, for example the frequency with which a function, such as the parking aid at a location, for example the supermarket, has been applied. For example, i is the location and j can be the function. N (i) _all represents the total number of assessments at location i. The actual value can be calculated using the following formula: F _AF (i, j) = N (i, j) _a / N (i) _all .

If the total number of assessments of a specific site has met or exceeded the predefined minimum, the method follows the second implementation. The second implementation includes a recursive formula that can be applied online to estimate the normalized application frequency (F _AF (i, j)) without requiring specific data points, such as the number of feature activations at a specific location. The second implementation involves a learning rate that is the memory depth of the external data store 335 and a gain signal that can become increasingly stronger the more often a function is activated at a location. The normalized application frequency for the on-line mode may be calculated using the following formula: F _AF (i, j) = (1-α) * F _AF (i, j-1) + (α) * sig- _positive (i, j), where α = the learning rate (for example, on a scale of 0 to 1, where 1 represents a significant learning rate) F _AF (i, j) = the normalized application frequency of the function j at location i, as explained above, and _Sigifyce (i, j) = the amplification signal representing the function j activated at the location i (for example, on a scale of 0 to 1, where 1 represents a strong amplification signal).

Switching to the recursive second formula helps to address two topics. First, the formula reduces the storage volume used because the second formula does not require N (i) _all or N (i, j) _a to estimate the normalized application frequency. This can not only create storage space, but also ensure a faster processing time. Similarly, the online mode may produce a more reliable output since a minimum threshold of activations at a particular location has been met as an indication of the driver's preference to often apply a particular function to a specific location. Further, the second formula reflects the most recent driving application in case the driver's preference shifts. The value of the learning rate (α) may be altered to reflect the driver's recent interactions and a specific function at different locations.

With reference to 6 For example, options based on the location (eg, park assist, valet parking, garage door control, etc.) may be activated as the vehicle approaches or leaves a specific location. In general, each specific location may have a data record associated with the location within the external data store 335 exhibit. The external data store 335 may include the latitude and longitude positions for a specific location (eg, home, office, corporate restaurant, etc.). Each record associated with the site may further include a field representing a normalized application frequency relevant to specific functions at the applicable site. Additionally or alternatively, each record may be stored in one or both of an arrival group and a departure group, thereby creating two records associated with a location. In this way, the functions associated with the start of a drive cycle and the functions associated with the end of a drive cycle may be delimited from one another, thus providing more accurate and timely predictions as to the usefulness of each function to the driver.

Each element within the field represents the normalized application frequency of a specific function (eg, cruise control, garage door control, home alarm activation, parking assistance, park service mode, vehicle interior temperature, etc.). For example, in the home arrival set record, the field may reflect the normalized application frequency for, among other things Vehicle speed control, parking assistance and vehicle interior temperature included. If the feature (or selectable option) has never been activated in a specific location, the normalized application frequency may be low or may not register in the field. For example, the selectable option for cruise control may enter a normalized application frequency of 0.00 at home location. On the other hand, the selectable garage door control option within this field may enter a higher normalized application frequency depending on the number of selectable option activations or the selectable option learn rate. The normalized application frequency for each function may be continually adjusted or updated to reflect the preferences of the driver or passenger.

3 represents an embodiment of the system 300 for creating a function score for a selectable option. The system may be a user interface device 305 , a control unit 310 with a processor 315 , Context modules 320 . 325 and 330 and a variety of sensors 340 . 345 include that of the control unit 310 submit the input. The through the base sensors 340 . 345 and the context modules 320 . 325 and 330 Variables are all made to the processor 315 to create a function score assigned to a selectable option. The function score can be used to determine the most relevant selectable option in relation to the driving context. The system 300 can also be stored in an external data store 335 stored location data, which may include, for example, previous driving stop locations, the number of parking aids and parking service mode function activations for previous stop locations and user interest points (POIs). The location data can be updated in the external data store after a certain time. For example, the external data store 335 store only the previous vehicle stopping locations from the previous 30, 60 or 90 days. This may aid in viewing the driver's most recent driving preferences, and may also decrease the storage volume used by the location data.

In one embodiment, the system 300 generate the selectable option for the parking aid. As stated, a position sensor 340 and a speed sensor 345 communicate with the control unit via an interface. The vehicle speed sensor 345 may include a speedometer, a transmission gear sensor or a wheel or axle sensor that monitors the wheel or axle rotation. The vehicle position sensor 340 may comprise a satellite navigation system (GPS) capable of identifying the location of the vehicle, as well as Radio Frequency Identification (RFID), Radio Frequency Electromagnetic Fields or Mobile Phones or a personal digital assistant (PDA) -GPS applies transmitted for example via a mobile phone or a PDA by Bluetooth ^®.

Each of the context modules 320 . 325 . 330 can be a specific function within the control unit 310 To run. While each of their corresponding functions are described herein, these are merely exemplary and a single module may perform all or some of the functions. The third context module 330 may be configured from the vehicle position sensor 340 to get the vehicle position, and from the external data memory 335 the previous stopping locations of the vehicle. Based on these sensor inputs, the third module 330 determine a stopping location (for example, a locality) that is near the current location of the vehicle.

The first context module 320 can be configured to use this stopping location from the third context module 330 to obtain. It can also determine how many times a specific function has been applied to that location. For example, the first module 320 Determine how often the parking aid has been applied at the location. This information may be in a location record within the external data store 335 and may be used to determine the normalized application frequency for the specific location (using either the actual application mode or the online application mode formula) as described above. For example, the parking assistance application per location may be entered as N (i, j) _a , and the number of assessments of the nearest previous stopping locations may be entered as N (i) _all for the formula of the actual application. On the other hand, everything that is the context module 320 for the online application mode must be the previous stop location and for the available selectable options a normalized application frequency will be generated. The first context module 320 can be configured to return the normalized application frequency to the processor 315 and can be configured to apply the normalized application frequency to the external data store as an input for creating a function score for a selectable option 335 to update the record at specific locations, or both.

The second context module 325 may be configured to detect the position of the vehicle from the vehicle position sensor 340 and the closest vehicle stop location transmitted by the third context module 330 is transmitted to determine the distance to the nearest location. In an example method, the vehicle speed sensor may 345 directly to the processor 315 be transmitted. The through the first and second context modules 320 and 325 editions produced by the vehicle speed sensor 345 transmitted vehicle speed can then the processor 315 be transmitted to attribute the values of the selectable option for the parking aid. The processor 315 can then create a function score associated with the parking assist selection option based on the received variables, and the parking assist selection option the user interface device 305 to spend on driver interaction.

Additionally or alternatively, the system may 300 create a selectable option for a driver service options mode. Much of the system 300 is similar to the selectable option for parking assistance, except for the addition of parking service interest points (POIs). The parking service interest points POIs provide information as to whether the parking service is offered at a specific location or location. The parking service interest points POIs may be available either through an in-vehicle map database serving as location data in the external data store 335 or in the form of a network service (for example, cloud-based communication). The parking service POIs can be accessed directly from the external data store 335 (for example, the external data store 335 programmed with specific locations that provide valet parking) or by inference by interpreting the location name in the external data store 335 be won. For example, trigger words, such as a conference center, hotel, or restaurant, may indicate that valet parking is typically provided at such locations. Are the parking service interest points POIs of a location in the external data store 335 not yet saved, or the name of the site does not give reason for a conclusion by interpretation, then the activation of the parking service mode selection option may be in relation to the external data memory 335 be updated to associate this location with the provision of a parking service. The parking service interest points POIs may affect the functional rating for the parking service mode selection option, because if a location does not offer valet parking, the particular function may become less significant (and subsequently create a low functional score).

4 represents a procedure 400 to create a function score associated with a selectable option. For purposes of example only, the foregoing discussion will refer to a parking assist option. At the beginning, the current vehicle location at data block 405 be determined. This can be done by the vehicle position sensor 340 be achieved. The through the vehicle position sensor 340 information received can be the context module 330 at data block 410 be transmitted directly. The third context module 330 compares the current position to the previous stop locations within the data store 335 to determine a nearest previous stop site. For example, by the vehicle position sensor 340 output current vehicle position and by the external data memory 335 transmitted previous stop sites in the third context module 330 aggregated to establish the nearest previous stopping location (e.g., the current position of the vehicle with respect to previous stopping locations within the external data memory 335 are stored).

At data block 415 can be the third context module 330 the first context module 320 submit the nearest, previous stop site. The context module can then retrieve data from the data store 335 that are assigned to the nearest previous hold site. This information may include an application indicator that indicates the frequency with which a specific function, such as the parking aid, has been applied at that location. This, in turn, can be achieved through the second context module 320 to calculate the normalized frequency of use as described above. For example, the first context module 320 also the number of selections (or functions) activations at the specific location from the external data store 335 receive. The external data store 335 may indicate that the parking assistant selection option has been activated seven times at the supermarket near the driver's home. If the total number of assessments of the nearest previous stopping location, the predefined minimum number (e.g. N (i) _all ≤ N _min) is not reached to assessments, the actual-application mode (when the data block 425 ) generate a context variable indicating the actual application frequency using a parking aid at the location. On the other hand, the online mode (data block 430 After the minimum number of assessments has been satisfied (for example, N (i) _all > N _min ), generate an intelligent context variable that estimates the normalized application frequency of a function at a particular location. Depending on the value provided by the signal amplification ( _Sigqueque (i, j)) and the learning tempo (α), the value provided by the first context module 320 Context variable generated is either strong (for example, close to 1) or weak.

At data block 435 can be the second context module 325 an input from the vehicle position sensor 340 and the nearest stop site from the third context module 330 to calculate the distance between the current vehicle position and the previous stop location. The closer the vehicle is to the closest previous stop location, the higher the value of the intelligent context variable. Further determined at data block 440 the vehicle speed sensor 345 the current vehicle speed. The through the vehicle speed sensor 345 output, simple context variable is inversely proportional to the vehicle speed. For example, if the vehicle is traveling at a speed of 40 miles per hour, the likelihood that the vehicle will stop (and thus the likelihood of having a parking aid applied) is low.

At data block 445 can through the first context module 320 , the second context module 325 and the vehicle speed sensor 345 output context variables to the processor 315 be transmitted. The processor 315 writes the values received to the selectable options on data block 450 to. As mentioned above, if the selectable options are categorized into an arrival group and a departure group, then the contextual variables need only be entered into the arrival group selection options. This can be determined if the vehicle has been driven for some time and for a certain distance with the ignition key inserted. The variables can be aggregated to a function score (data block 455 ) to create. The heuristic used in the aggregation of the values can be achieved in a variety of ways, including but not limited to the formation of product, average, maximum and minimum values. At data block 455 can the processor 315 the product of the first context module 320 , the second context module 325 and the vehicle speed sensor 345 form output variables to generate the function score for the selectable options.

At data block 460 can the processor 315 Select the parking assist selection option if the function score is the highest in relation to the other available selectable options. The processor 315 may be an indication of the function on the user interface device 305 at data block 465 favor. At the same time, the processor can use one on the user interface device 305 remove an existing function that may not be relevant in the current context.

5 FIG. 3 illustrates a flowchart using an example method. FIG 500 for generating the parking service mode selection option and for transporting the selectable option to the user interface device 305 The current vehicle location may be at data block 505 by means of a vehicle position sensor 340 be determined. At data block 510 can the external data store 335 display the previous stopping locations and the parking service POIs to determine the relative location data based on the current location of the vehicle. The external data store 335 The location data may be the third context module 330 to transfer. At data block 515 can be the third context module 330 through the external data store 335 obtained location data with that by the vehicle position sensor 340 combined vehicle position to determine the nearest previous stop location offering a valet parking service. The parking service POIs can, as previously mentioned, directly to the external data storage 335 or the POIs may be accessed by reference to the location designation (e.g. restaurant, cinema, conference hall).

At data block 520 then the nearest, previous stop location may be the first context module 320 to determine the normalized use frequency of the parking service mode at a particular location. For example, if the nearest previous stop location is the restaurant at the driver's place of work, this will be entered as (i), and the park service mode as (j) in the normalized application frequency formula as described above. Has the minimum number of evaluations (for example, N (i) _all ≤ N _min) is not exceeded assessments before switching to the online mode, the total number, then the actual application rate in data block is 530 be calculated. If, on the other hand, the extent of site assessments has (i) met the predefined minimum, then the online application frequency can be determined using the recursive formula at data block 535 be calculated. Regardless of the formula used, a smart context variable for a normalized park service mode function application is provided by the first context module 320 be issued. When the normalized application of the parking service mode selection option is high, the probability of activating the function is high, and thus the value assigned to the generated intelligent context variable is high.

At data block 545 can be the second context module 325 the vehicle position from the vehicle position sensor 340 learn and the nearest previous stop site from the third context module 330 to determine the distance to the nearest previous stop location. If the distance to the nearest previous stop site offering valet parking is low, the probability of a park service mode function being selected is high (and again, the value of the intelligent context variable output is high). In addition, the vehicle speed becomes through the vehicle speed sensor 345 at data block 545 certainly. If the vehicle speed is low, the likelihood that the vehicle will stop in the near future is high.

At data block 550 will be the vehicle speed, the normalized application frequency and the distance to the nearest location in the processor 315 entered. The processor 315 The values can be set to the available selectable options on data block 555 attribute. The processor 315 can then by aggregating the at data block 555 values obtained create a function score for each selectable option. The processor 315 can also prioritize the selectable options that have exceeded a minimum threshold. The selectable option with the highest function score may be assigned the highest priority, the selectable option with the second highest score may be assigned the second highest priority, and so on and so forth. If the functional rating for the park service mode selection option were attributed to the highest functional score, and thus provided with the highest functional priority, the processor could 315 the parking service mode at data block 565 and display it on the user interface device 305 at data block 570 transport. Alternatively, the processor 315 select multiple selectable options that include the first, second, etc. priority for transport to the user interface device 305 exhibit. The processor 315 may, therefore, downgrade a selectable option that has a lower functional score with respect to the driving context, so that the selectable option with the highest score is always on the user interface device 305 is shown.

With reference to the 7A and 7B For example, the functional score assigned to the various stop-site-based selection options (eg, park assist or park service mode) may be based on at least three if-then rules. Is that through the first context module 320 If the Park Assist or Park Service normalized application frequency is high, the probability (and thus the value of the Context Variable output) of the associated selectable option may also be high. 7A shows relative performance scores based on the distance of a vehicle from a known location. Is the distance as in 7A shown to one (through the second context module 325 manufactured) known location low (for example, less than 500 Meter), then the likelihood that the vehicle will stop at the location is high. 7B shows relative performance scores based on the speed of a vehicle. Is the (through the vehicle speed sensor 345 certain) vehicle speed, as in 7B low, the likelihood that the vehicle will stop at the location is high. The processor 315 aggregates these values to determine a function score. Thus, synergy may be required between the three values to create a high functional score.

For example, if the distance to the nearest previous stop location is low and the normalized application frequency is high, but the vehicle is traveling at 45 miles per hour, then the vehicle is unlikely to stop at the location. Thus, for example, the park rating or park service mode rating may be low, and thus the user interface may not display such options. Likewise, if the vehicle is near a previous stop location and the vehicle is traveling at low speed, but the specific function has never been activated at the location, then a relatively low application frequency can be determined and the likelihood of interaction therewith Function (for example, the function score) will also be low.

8th is an exemplary block diagram for the creation of a function rating for a parking function. The block diagram is exemplary and is intended to show how an end location 810 , a sub-site 815 and an external park location 820 can be applied to a parking function in the interface system 100 evaluate. The entered location 810 can be entered by a user via the navigation system.

The sub-park location 815 may be a location with a parking facility that has been routinely selected at this location. For example, a driver may routinely park using the park assist function when he or she steps on the bench. Each time a function is applied to a given location, an application indicator associated with the given location may be positively located within the end location data in the data store 130 increase. In addition, if a function is not selected at a given location, the application indicator may be negatively increased. The application indicator may be associated with a specific end location, such as an address. However, it can also be assigned to a geographic location in general (for example geographic coordinates). Ie. the park location 815 may be assigned to an end location address (e.g. bank address) and / or the park location may be the geographic location of the car park (for example, the geographic coordinates of the car park in front of the bank). A low pass filter can be used to increase / decrease the application indicator. For example, a frequency vector is associated with a list of locations that the driver frequently visits. When a driver is observed to have visited a location, the value in the frequency vector associated with that location is increased using a low-pass filter with the one gain signal value associated with it, while the remainder of the vector will match their gain signals associated with zero reduce. In this example, since the gain signals will be either one or zero and the proportion in the frequency vector between 0 and 1 will be indicative of the driver's trip goal preference. Further, the application indicator may be somewhere else besides the data store 130 to get managed. Thus, the end location may be a predicted location based on the pre-behavior of a user / vehicle.

As explained, the external park location 820 a parking location (for example, a parking garage or a parking lot) near a specific location (for example, a stadium, restaurant, etc.). This information can be the data store 130 or external sources such as a map database or a public database. In addition, multiple entered locations 810 , Sub-locations 815 and external locations 820 through the context module 120 . 125 be received and identified. Before a location is recalled, the driver may be asked to confirm the location as a remembered location. That is, before the location becomes a preferred or remembered location, the driver may need to give his consent. Similarly, the driver can remove the location and associated data. Thus, the driver can remove locations that are no longer of interest.

If a vehicle moves on a lane, the current location (for example, a context variable) may be determined by the context module 120 . 125 in one example obtained by the GPS, are compared to one or all of the predicted end locations at regular intervals or as needed. The distance between the predicted end locations and the current location may be determined by the context module 120 be determined. Once the distance is calculated, the nearest location may be from the predicted end locations (for example, the location entered 210 , the sub-park location 815 and the external park location 820 selected) as the final location. In some configurations, an input location may by default be the end location, and the context module 120 . 125 may not calculate the distance between the current location and the end location. However, in some configurations, while the end location may be entered into the navigation system by the user, a parking lot or car park may be a more suitable end location, and thus the distance may nonetheless be calculated to determine the end location , For example, although a user has entered the address for a restaurant, when approaching the restaurant, the vehicle may pass by the parking lot for the restaurant. In this situation, the end location may be the parking lot and not the address of the restaurant.

As explained, if multiple predicted end locations are possible, these locations may be aggregated and compared to determine which is closest to the current location. Once the end location has been selected, the context module can 120 . 125 a simple context variable from the base sensors 135 . 140 , For example, the vehicle speed obtained. The processor 115 may provide a score to the current driving context based on the vehicle speed, the location with respect to the selection location, and the application increase associated with the selected location. For example, if the vehicle is traveling at low speed and near a location where the vehicle is routinely parked, the parking function may receive a high functional rating, and thus as a selectable option on the interface device 105 Arrange. On the other hand, if the vehicle is traveling at low speed, but nowhere near an end location or pre-park location, then the functional score may be low.

The 9A -C are exemplary data diagrams as an indicator for context variables for creating function scores for the interface system. In 9A an exemplary location data diagram is shown. The location data diagram may indicate the driving distance of a vehicle via latitude and longitude coordinates, which is indicated by the solid line in the figure. Furthermore, various end locations can be represented by the circles in the figure. In 9B the vehicle speed can be represented graphically in time. Based on the vehicle location with respect to a known end location and at a given vehicle speed, the control unit may 110 Assign a function rating for the driving context. Exemplary function scores are in 9C shown. As shown in the figure, at about 50 seconds, the functional score is about 0.9. At approximately 450 seconds, the functional score is approximately 0.85. These high performance scores are correlated with the vehicle location, which is very close to a known end location, as well as with a very low vehicle speed. However, between 50 seconds and 450 seconds, the functional score may be low because the vehicle is not approaching or near any end locations, regardless of vehicle speed. Moreover, between about 550 seconds and 675 seconds, the functional score may increase to 0.35. In these cases, the vehicle speed may decrease, but the current vehicle location may be far from any known end locations.

10 FIG. 10 is a flowchart for implementing an example interface system method. FIG 400 , The procedure 1000 can at data block 1005 begin where the operation of the user interface system 100 automatically at the latest when the vehicle ignition is switched on. At this point, the vehicle may undergo an internal system check in which the operational status of one or more vehicle systems and / or subsystems will be determined to ensure that the vehicle is operational. While the internal system check is verified, the system can 100 additionally determine the current location of the vehicle. Once the system is activated, the procedure can be done with data block 1010 continue.

At data block 1010 can be the context module 120 . 125 Location information (for example, simple context variables) from one of the context modules 120 . 125 receive. The location information, as discussed above, may include one or more predicted end locations. These end locations may be either based on user input information (eg, entering an address into the navigation system) or predicted based on the user's / vehicle's pre-behavior. The obtained location information may include a list of predicted end locations when the end locations are predicted. For example, the end site may include multiple pre-park locations that are the context module 120 . 125 in the location information based on the route the vehicle is currently driving. Once the location information has been obtained, the procedure can 400 continue with data block 100015.

At data block 1015 can be the context module 120 . 125 determine an end location (for example, a context variable) from the predicted end locations. Depending on the configuration, the processor can 115 For example, to determine the end location based on a defined hierarchy, always selecting a user-entered location from a predicted location and aggregating the predicted end-locations and selecting the location closest to the current location of the vehicle. The latter configuration may require that the processor 115 the current location of the vehicle from the base sensor 135 . 140 is transmitted. One of the context modules 120 . 125 within the processor 115 can determine the distance between the current location and each predicted end location. Based on these distances, the location within the closest vicinity of the current location can be selected as the final location. As explained, this analysis may not be required if the user is using an end location via the navigation system on the interface device 105 has reached. Once the final location is determined, the procedure continues 1000 with data block 1020 continued.

At data block 1020 can be the context module 120 . 125 Get end-location data that includes an application indicator associated with the end-site (e.g., an intelligent context variable). This data may be the data store 130 or another external source. The application indicator can indicate how often the function is applied to the end site. The procedure 1000 sets with data block 1025 continued.

At data block 1025 can be the context module 120 . 125 from the base sensor 135 . 140 get the current vehicle speed (for example, a simple context variable). The context modules 120 . 125 can get the speed and in turn send it to the processor 115 output. The procedure 1000 can with data block 1030 Continue.

At data block 1030 The context variables can include the end location, the end location data, and the vehicle speed, the processor 115 be transmitted to generate a function rating. The processor 115 can combine the resulting context variables and assign values to the function or functions. The function scores can be generated by aggregating the context variables by using product, average, maximum, minimum, or other non-linear algorithms, such as fuzzy logic or neural networks. The functional score may be relevant to the aggregation of the processor 115 transmitted context variables are directly proportional. Is this located? For example, if the vehicle is in close proximity to its final location, where it typically applies the parking assist function, the function score for the selectable option associated with the parking assist function will be of a higher value than if the vehicle is not in close proximity to the end position. Location would be and would be traveling at high speed. The procedure 1000 sets with data block 1045 continued.

At data block 1045 can the processor 115 prioritize the selectable options based on their associated performance scores. In general, the highest-scoring options that can be selected have the highest priority, and the remaining available selectable options are ranked accordingly. Depending on the user preference, either the function with the highest function rating or multiple functions (for example, the three functions with the highest functional ratings) may be the user interface device 105 at data block 1040 for display and execution. Similarly, those on the user interface device 105 functions already displayed are removed (or demoted) at the same time if their meaning has decreased within the particular driving context. Additionally or alternatively, the processor may 115 or the control unit 110 Arrange the selectable options according to the function score assigned to each selectable option. The control unit 110 can then determine the order of selectable options with function scores above a certain threshold. For example, the control unit 110 select only those selectable options that have a function score of or greater than 0.7. The control unit 110 can then put the available selectable options with the highest score in a first place, another selectable option with a slightly lower score in second, and so on.

In one example, the parking function may be on the interface device 105 transported and displayed there when there is a high probability that the user will park the vehicle. This may be based in part on the closest proximity to the end location, the frequency that the function has been applied, and the current vehicle speed. As explained, the parking function may include a parking assistance function that can be used when parking a vehicle in a row. The parking function may also include a general parking assistance / function, in which the view from the rear view cameras on the interface device 105 is displayed or another screen visible to the user to assist the user in parking the vehicle. Each of the park assist function and the general park function can be independently evaluated and evaluated. Thus, a selectable option associated with the park functions may be on the interface device 105 be displayed, and another not. However, in some driving contexts, both selectable options may be displayed.

As shown, the data blocks 1010 - 1030 Perform a continuous cycle while the vehicle is in operation. The basic sensors 135 . 140 and the context modules 120 . 125 are active at all times by keeping information in the processor 115 which continuously generates new functional scores associated with the available selectable options (for example, the ones associated with Park functions) so that the most relevant functions can be available and via the interface device 105 can be displayed.

Accordingly, an interface system for determining the likelihood is described herein that a vehicle function will be selected by a driver and for correspondingly displaying that function on the interface. By contextually evaluating the selectable functions, the interface can be more user-friendly and increase the frequency of application of various functions due to display of the selectable functions at a time of likely application. Furthermore, the system can provide a safer, less distracting driving experience.

Data processing devices generally include computer-executable instructions, which instructions may be executable by one or more data processing devices as enumerated above. Computer-executable instructions may be compiled and interpreted from computer programs that may be generated using a variety of programming languages and / or technologies, including, without limitation, and either individually or in combination, Java ^™ , C, C ++, Visual Basic, Java Script, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, such as memory, a computer-readable medium, etc., and executes these instructions by executing one or more methods, including one or more the method described herein. Such commands and other data may be stored and transmitted using a variety of computer readable media.

A computer-readable medium (also referred to as a processor-readable medium) includes any non-transitory (eg, physical) medium involved in the provision of data (e.g., instructions) that can be read by a computer (for example, by a processor of a computer). Such a data carrier may take many different forms, including but not limited to non-volatile media and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other persistent storage. For example, volatile volumes may include Dynamic Random Access Memory (DRAM), which is typically a main memory. Such instructions may be transmitted through one or more communication media, including coaxial cable, copper wire and fiber optic, including the wires that include a system bus connected to a processor of a computer. Common forms of computer readable media include, for example, a floppy disk, a flexible disk, a magnetic disk, a magnetic tape, any other magnetic media, a CD-ROM, a DVD, any other optical media, punched cards, perforated tape, any other perforated patterned physical media , a Random Access Memory / RAM, a Programmable Read Only Memory / PROM, an Erasable Programmable Read Only Memory / EPROM, a FLASH Electrically Erasable Programmable Read Only Memory / FLASH EEPROM, any other memory chip or memory cartridge, or any other disk from which a computer can read.

Databanks, databases, or other data stores described herein may include various types of mechanisms for storing, accessing, and retrieving various types of data, including a hierarchy database, a file set in a file system, an application database in a proprietary format, a relational database management system ( RDBMS) etc. Each of these data stores is generally included within a data processing apparatus employing a computer operating system, such as one of those mentioned above, and accesses take place over a network in some or several ways. A file system may be accessible by a computer operating system and may include files stored in various formats. An RDBMS generally uses the Structured Query Language (SQL) in addition to a language for creating, storing, editing, and executing stored methods, such as the PL / SQL language mentioned above.

In some examples, system elements may be implemented as computer-readable instructions (eg, software) on one or more computing devices (eg, servers, personal computers, etc.) stored on associated computer-readable media (eg, floppy disks, memory, etc.). A computer program product may include such instructions stored on computer readable media for carrying out the functions described herein.

With reference to the methods, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such methods, etc., have been described as occurring in a particular order, such methods could be practiced with the described steps described in U.S. Patent Nos. 4,314,309; other than in the order described herein. It is further noted that certain steps could be performed concurrently, other steps could be added, or that other steps described herein could be omitted. In other words, the subject descriptions of the methods are provided for the purpose of illustrating particular embodiments, and should by no means be construed in a limiting sense.

Accordingly, it should be understood that the above description is intended to be illustrative and not restrictive. Many embodiments and applications that differ from the examples provided would be apparent upon reading the above description. The scope of protection should be determined, not with reference to the above description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and envisioned that there will be future developments in the technologies discussed herein, and that the disclosed systems and methods are incorporated into such future embodiments. In summary, it should be noted that the application can be modified and varied.

All terms used in the claims are to be construed in the broadest and most appropriate manner, also in light of their meaning, as understood by those skilled in the technologies described herein, unless expressly stated otherwise herein. In particular, the use of the words "first", "second" etc. may be interchangeable.

Claims (10)

Vehicle interface system, comprising: an interface configured to show icons representing selectable vehicle functions; and a control unit that is programmed generate a score for each of the functions based on a context variable comprising one or all of a vehicle location, a vehicle speed and a predicted end location for the vehicle, and display certain of the icons based on the generated scores and others of Hide pictogram. The system of claim 1, wherein the controller is further programmed to create the score based on a distance between the vehicle location and the predicted end location. The system of claim 2, wherein the score increases as the distance decreases. The system of claim 1, wherein the score increases as the vehicle speed decreases. The system of claim 1, wherein the predicted end location is defined by a user and identified based on the previous drivability or identified based on the park location data. Vehicle control, comprising: at least one context module configured to generate at least one context variable representing a driving context, including vehicle location or vehicle speed; and a processor that is programmed a function score based on a vehicle location and / or a vehicle speed as defined by the at least one context variable, wherein the score represents the likelihood that a vehicle function will be selected via an icon that is on the vehicle Context-based vehicle function is assigned, and based on the function scores, display certain of the icons and hide others of the icons. The control unit of claim 6, wherein the at least one context variable comprises an end location, the processor is configured to create the function score based at least in part on a distance between the vehicle location and the end location. The control unit of claim 7, wherein the end location is defined by a user identified based on previous drivability or identified based on park location data. The control unit of claim 6, wherein the at least one context variable comprises at least one end-location data comprising an application indicator indicative of vehicle function pre-application, the processor further programming to generate the function score based on the application indicator of the icon is. The controller of claim 9, wherein at least one context variable includes a vehicle speed indicator, the processor further programmed to generate the function score based on the vehicle speed indicator.

Images