Computing system for generating user-specific automated vehicle actions using artificial intelligence
A machine learning-based computing system in vehicles analyzes user interactions to generate automated actions, enhancing efficiency and personalization by reducing manual inputs and optimizing resource use.
Patent Information
- Application Number
- JP2025534754
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-12-14
- Filing Date
- 2023-11-21
- Publication Date
- 2026-01-06
AI Technical Summary
Existing vehicle systems lack the ability to automatically and efficiently tailor vehicle functions to individual user preferences, leading to inefficiencies in resource usage and user interaction.
A computing system utilizing machine learning clustering models to analyze user interactions with vehicle functions, generating automated actions based on user preferences and conditions, and implementing these actions when trigger conditions are met.
Improves computational efficiency and responsiveness by reducing manual user interactions, optimizing resource usage, and providing a personalized user experience that can be transferred across vehicles.
Smart Images

Figure 2026500299000001_ABST
Abstract
Description
[Technical Field]
[0001] The present disclosure generally relates to using artificial intelligence, including machine learning models, to generate vehicle actions to be automatically performed by a vehicle and that are specifically tailored to a user of the vehicle. [Background technology]
[0002] Vehicles, such as automobiles, have on-board control systems that operate certain functions of the vehicle in response to inputs from a vehicle operator. This includes control functions such as braking, acceleration, and steering, as well as comfort-related functions such as air conditioning and seat position. The operator may physically manipulate devices or touchscreen elements to control these functions as the operator deems appropriate. Summary of the Invention
[0003] Aspects and advantages of embodiments of the present disclosure will be set forth in part in the description that follows, or may be learned from the description, or may be learned through practice of the embodiments.
[0004] One exemplary aspect of the present disclosure is directed to a computing system including a control circuit. The control circuit may be configured to receive context data associated with multiple user interactions with a vehicle function of a vehicle across multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with the respective user-selected settings. The control circuit may be configured to generate user activity clusters for the vehicle function based on the context data using a machine learning clustering model. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings. The control circuit may be configured to determine an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The control circuit may output command instructions for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0005] In one embodiment, the machine learning clustering model may be an unsupervised learning model configured to process the context data using probabilistic clustering to generate user activity clusters.
[0006] In one embodiment, the machine learning clustering model may be configured to determine boundaries of user activity clusters for vehicle functions based on one or more observed conditions.
[0007] In one embodiment, to determine an automated vehicle action, the control circuitry may process the user activity clusters using a vehicle action model, the vehicle action model being a rule-based model configured to apply a respective weight to each respective user-selected setting in the user activity cluster. The control circuitry may be configured to determine an automated setting of the vehicle function based on the weight of each user-selected setting in the user activity cluster.
[0008] In one embodiment, to receive the context data, the control circuitry may be further configured to receive, via a plurality of sensors or systems in the vehicle, data indicative of one or more observed conditions. The observed conditions may include at least one of: (i) the date and / or time at which each user interaction with the vehicle feature occurred, (ii) the location at which each user interaction with the vehicle feature occurred, (iii) the route taken during which each user interaction with the vehicle feature occurred, or (iv) the temperature at which each user interaction with the vehicle feature occurred.
[0009] In one embodiment, the control circuitry is further configured to generate content for presentation to a user via a user interface of a display device based on the automated vehicle action using the action description model, the content indicating the vehicle function, the automatic setting, and one or more trigger conditions.
[0010] In one embodiment, the content may include a request for the user to approve an automated vehicle action.
[0011] In one embodiment, the control circuitry may be further configured to store the command instructions in an accessible memory on the vehicle for execution at a later time.
[0012] In one embodiment, the control circuit may be further configured to detect the occurrence of one or more trigger conditions and, based on the one or more trigger conditions, send a signal to perform automatic configuration of the vehicle function.
[0013] In one embodiment, the control circuitry may be further configured to determine whether a conflict exists between the automated vehicle action and an existing automated vehicle action.
[0014] In one embodiment, the control circuitry may be further configured to send a communication over the network to a server system indicating command instructions for storing in association with the user's user profile.
[0015] In one embodiment, the plurality of user interactions may be associated with a first user. The command instructions for the automated vehicle action may be associated with a first user profile of the first user. The control circuitry may be further configured to receive data indicative of a second user profile of a second user of the vehicle and store, in accessible memory of the vehicle, command instructions for a second automated vehicle action associated with the second user profile. The command instructions for the second automated vehicle action may be based on at least one user interaction of the second user with a vehicle function of another vehicle.
[0016] In one embodiment, the vehicle may include a plurality of vehicle features and a plurality of machine learning clustering models, and the control circuitry may be further configured to select a machine learning clustering model from among the plurality of machine learning clustering models based on the vehicle features.
[0017] In one embodiment, the vehicle function may include (i) a window function, (ii) a seat function, or (iii) a temperature function.
[0018] In one embodiment, the seat function may include a seat temperature function, a seat ventilation function, or a seat massage function.
[0019] In one embodiment, the plurality of user-selected settings of the vehicle function may each include at least one of: (i) an on / off selection, (ii) an open / close selection, (iii) a temperature selection, or (iv) a massage level selection.
[0020] Another exemplary aspect of the present disclosure relates to a computer-implemented method. The computer-implemented method may include receiving context data associated with multiple user interactions with a vehicle function of a vehicle across multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with each user-selected setting. The computer-implemented method may include generating user activity clusters for the vehicle function based on the context data using a machine learning clustering model. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with each user-selected setting. The computer-implemented method may include determining an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The computer-implemented method may include outputting command instructions to the vehicle for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0021] In one embodiment, the machine learning clustering model may include an unsupervised learning model configured to process the context data using probabilistic clustering to generate user activity clusters, and boundaries of the user activity clusters for vehicle functions may be based on one or more observed conditions.
[0022] In one embodiment, the computer-implemented method may further include generating content for presentation to a user via a user interface of a display device based on the automated vehicle actions using the action description model. The content may indicate vehicle functions, automatic settings, and one or more trigger conditions.
[0023] Yet another exemplary aspect of the present disclosure relates to one or more non-transitory computer-readable media storing instructions executable by a control circuit to perform operations. The control circuit may receive context data associated with multiple user interactions with a vehicle function of a vehicle across multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with the respective user-selected settings. The control circuit may use a machine learning clustering model to generate user activity clusters for the vehicle function based on the context data. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings. The control circuit may determine an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The control circuit may output command instructions for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0024] Other example aspects of the present disclosure are directed to other systems, methods, vehicles, apparatus, tangible non-transitory computer-readable media, and devices for improving vehicle operation and vehicle-related computational efficiency.
[0025] These and other features, aspects, and advantages of various embodiments will become better understood with reference to the following description and appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain associated principles. [Brief explanation of the drawings]
[0026] A detailed description of embodiments directed to those skilled in the art is set forth herein with reference to the accompanying drawings. [Figure 1] 1 illustrates an exemplary computing ecosystem, according to one embodiment of the present disclosure. [Figure 2] 1 illustrates a diagram of an exemplary computing architecture according to an embodiment of the present specification. [Figure 3] 1 illustrates a diagram of an exemplary data processing pipeline according to an embodiment of the present disclosure; [Figure 4] 1 illustrates a diagram of an exemplary data structure containing data associated with a user interaction, according to an embodiment of the present disclosure. [Figure 5A] 1 illustrates an exemplary user activity cluster, according to one embodiment of the present disclosure. [Figure 5B] 1 illustrates an exemplary user activity cluster, according to one embodiment of the present disclosure. [Figure 5C] 1 illustrates an exemplary user activity cluster, according to one embodiment of the present disclosure. [Figure 5D] 1 illustrates an exemplary user activity cluster, according to one embodiment of the present disclosure. [Figure 6] 1 shows a diagram of an exemplary user interface on an exemplary display, according to an embodiment of the present disclosure. [Figure 7] 1 shows a diagram of an exemplary user interface on an exemplary display, according to an embodiment of the present disclosure. [Figure 8] 10A-10C illustrate diagrams of exemplary user interfaces on exemplary displays, in accordance with exemplary embodiments of the present disclosure. [Figure 9A] 1 illustrates an exemplary data structure containing data associated with an automated vehicle action, according to an embodiment of the present disclosure. [Figure 9B] 1 illustrates an exemplary data structure containing data associated with an automated vehicle action, according to an embodiment of the present disclosure. [Figure 10A] FIG. 1 is a flowchart diagram of an exemplary method for generating automated vehicle actions for a user, according to an embodiment of the present disclosure. [Figure 10B] FIG. 1 is a flowchart diagram of an exemplary method for generating automated vehicle actions for a user, according to an embodiment of the present disclosure. [Figure 11] FIG. 1 illustrates a flowchart diagram of an exemplary method for implementing automated vehicle actions for a second user, according to an embodiment of the present disclosure. [Figure 12] 1 illustrates a block diagram of an exemplary computing system, according to one embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION
[0027] One aspect of the present disclosure relates to using personalized artificial intelligence to analyze user interactions with a vehicle and generate actions to be automatically executed by the vehicle for a particular user. The personalized artificial intelligence that enables the vehicle to emulate a user's behavior can be based on machine learning models that learn the user's preferences over time. For example, a vehicle (e.g., an automobile) may include multiple vehicle functions. A vehicle function may refer to a function or action that the vehicle is configured to perform based on an input. For example, a user may interact with a vehicle function (e.g., activate or adjust the vehicle function). The user may be the driver of the vehicle. The vehicle may observe the user interactions and build a set of context data that reflects the user's preferences with vehicle functions over time. Based on the context data, the vehicle may predict the user's preferences and create automated vehicle actions that automatically perform vehicle functions as the user prefers.
[0028] For example, a user may interact with a seat massage feature. The user may activate a massage device on the seat and / or select a massage setting. The vehicle's onboard computing system may observe the user's interactions with the seat massage feature and record certain information about each interaction as context data. For example, the computing system may record the particular massage setting selected by the user (e.g., "Typical Massage"). In addition, the computing system may record the time, temperature, and location conditions observed by the vehicle when the user selected the particular setting. As an example, for a given user interaction, the vehicle may observe that the user selects a massage setting on Monday at 5:05 p.m. PT, with an external temperature of 65 degrees Fahrenheit, while at a particular latitude / longitude pair corresponding to the user's workplace. The user may interact with the seat massage feature on a day-by-day basis. The computing system may observe the user's selected massage setting to build setting context data that reflects the user's preferences for the seat massage feature. The vehicle can use the context data to learn the user's preferences for the seat massage feature and implement the seat massage function accordingly.
[0029] To help better identify user routines and automate user preferences, the techniques of this disclosure may leverage a multi-stage, multi-model computing framework for processing contextual data.
[0030] For example, a computing system may store or have access to multiple machine learning clustering models. Each machine learning clustering model may be associated with a particular vehicle feature. This may enable the model to better learn and calibrate its hyperparameters to the type of user interaction a user has with the particular vehicle feature. For example, to learn from a user's operation of a seat massage feature, the computing system may use a machine learning clustering model associated with the seat massage feature.
[0031] The machine learning clustering model may be configured to apply cluster modeling techniques to generate data clusters (“user activity clusters”) based on patterns identified in a user's activity. The boundaries of the user activity clusters may be defined by the machine learning clustering model based on observed conditions. For example, as described further herein, the machine learning clustering model may identify the existence of a cluster when a certain number of data points are collected that have a common time range (e.g., 5:03-5:53 p.m. PT), temperature range (e.g., 60-68 degrees Fahrenheit), and location range (e.g., within 1,000 feet of the user's workplace). For example, in the case of seat massage function interactions, a user activity cluster may include multiple data points, each associated with a specific user interaction with the seat massage function. The data points may include metadata indicating the massage setting selected by the user, as well as the observed time, temperature, and location conditions observed when the setting was selected. The machine learning clustering model may group the data points into user activity clusters based on similarities or other patterns in the metadata to establish bounding regions for parameters associated with the user's preferences for the seat massage function.
[0032] The computing system may process the user activity clusters and determine skills (also referred to as routines) for the vehicle that automate the user's preferred settings for vehicle-specific (or non-vehicle-specific) functions. To do so, the computing system may utilize a vehicle action model. In some implementations, the vehicle action model may be a rule-based model that weights various user-selected settings to determine, for example, the setting most frequently selected by the user (e.g., typical massage). The rule-based model may include a set of predetermined rules or heuristics that can be processed to achieve a goal (e.g., to apply weights for setting analysis and selection). In some implementations, the vehicle action model may include one or more machine learning models. The vehicle may implement this setting as an automatic setting.
[0033] Additionally, the vehicle action model may determine which conditions trigger the automatic settings ("trigger conditions"). In one embodiment, the trigger conditions may be based on, for example, the time, temperature, or location range associated with the user activity cluster. Thus, the computing system may generate "automated vehicle actions" that define the relationship between the automatic settings of the vehicle functions and the trigger conditions. For example, this relationship may be expressed as an if / then logic statement: if the time is between 5:00 pm PT and 5:35 pm PT, the temperature is between 60 and 65 degrees Fahrenheit, and the vehicle is located within 1000 feet of the user's workplace, activate the typical massage setting for the seat massage function.
[0034] To verify that an automated vehicle action is appropriate, the computing system may determine whether the new automated vehicle action conflicts with another automated vehicle action. For example, the computing system may compare the automation settings and trigger conditions of the new automated vehicle action with existing automated vehicle actions. Based on this comparison, the computing system may verify that the vehicle can perform both automated vehicle actions without modifying either of the automated vehicle actions.
[0035] In one embodiment, the computing system may request that the user approve the automated vehicle action before storing it in the vehicle's memory for execution. To do so, the computing system may generate content for presentation to the user via the vehicle's in-vehicle head unit display device. The content may be a prompt requesting the user's approval by selecting an element on a touchscreen, providing verbal confirmation, etc. Once approved, the computing system may output command instructions for the vehicle to implement the automated vehicle action to automatically control a vehicle function (e.g., a seat massage function) according to an automatic setting (e.g., typical massage) based on whether the vehicle detects a trigger condition. A library may store command instructions for maintaining automated vehicle actions in association with a particular user or user profile. As described in further detail, a remote cloud server may store the library so that the user's automated vehicle actions can be automatically downloaded to another vehicle that may be operated by the user. In this manner, the systems and methods of the present disclosure can automate actions for a user in a manner that is personalized to the user and transferable across multiple vehicles.
[0036] The techniques of the present disclosure provide several technical effects and improvements to vehicle and computing technology. For example, a computing system may utilize machine learning clustering models dedicated to various vehicle functions. These models may be trained and retrained based on data specific to the vehicle function and user interactions with the vehicle function. As a result, the machine learning clustering models may better learn user routines and patterns with respect to specific vehicle functions. By improving automatic learning of user preferences, for example, the techniques of the present disclosure may reduce or replace manual commands or configuration inputs from the user that may cause delays in implementing the user preferences. In this manner, for example, the techniques of the present disclosure may improve the responsiveness of the vehicle in performing vehicle functions (e.g., reducing latency). Furthermore, by improving automatic learning of user preferences, for example, the techniques of the present disclosure may reduce or replace manual commands or configuration inputs from the user that consume processing power and rendering capabilities (e.g., the capabilities for rendering audio communications, graphical communications), thereby helping to allocate such resources for other vehicle operations.
[0037] Furthermore, improved machine learning clustering models can generate more accurate clusters, which leads to automated vehicle actions that are more likely to be accepted by users. By reducing the likelihood that an action will be rejected by a user, the techniques of this disclosure can help allocate limited processing, memory, power, and bandwidth resources on the vehicle for more core vehicle operations.
[0038] The techniques of the present disclosure can improve the computational configurability of a vehicle. More specifically, by utilizing clustering models that are personalized to specific vehicle functions, a cloud-based platform can more easily and accurately update the vehicle's on-board software (e.g., via software update pushes over a network) to add models or remove obsolete models as vehicle functions change. This can help avoid system restarts or lengthy reconfigurations, which can be time- and resource-intensive.
[0039] Automated vehicle actions generated by the systems and methods of the present disclosure may also improve the efficiency of a vehicle's on-board computing resources. For example, automating vehicle actions based on a user's preferred routines can reduce the number of user interactions a user has with a particular vehicle function. By reducing the frequency of user interactions, a vehicle can reduce the amount of processing and memory resources expended each time a user manually adjusts a vehicle function. Furthermore, this can reduce wear on the physical interface associated with the vehicle function.
[0040] The techniques of the present disclosure may also help reduce unnecessary use of computational resources across multiple vehicles. For example, as described further herein, automated vehicle actions created by a first vehicle may be transferred to a second vehicle (e.g., by a cloud platform that maintains user profiles). In this way, the second vehicle can avoid using its computational resources to reproduce automated vehicle actions already performed by the first vehicle. This may include, for example, avoiding computational tasks such as clustering, algorithm weighting, user interface generation, etc.
[0041] Ultimately, the systems and methods of the present disclosure improve the computational efficiency and configurability of vehicles while also providing a personalized user experience that can be wirelessly transferred to another vehicle.
[0042] Reference will now be made in detail to the embodiments, one or more examples of which are illustrated in the drawings. Each example is provided by way of explanation of an embodiment, not as a limitation of the disclosure. Indeed, it will be apparent to those skilled in the art that various modifications and variations can be made to the embodiments without departing from the scope or spirit of the disclosure. For example, features illustrated or described as part of one embodiment may be used with another embodiment to yield a still further embodiment. Accordingly, it is intended that aspects of the present disclosure cover such modifications and variations.
[0043] The techniques of this disclosure may include collection of data associated with a user if the user explicitly authorizes such collection. Such authorization may be provided by the user via explicit user input to a user interface in response to a prompt explicitly requesting such authorization. Collected data may be anonymized, pseudonymized, encrypted, noisy, securely stored, or otherwise protected. The user may opt out of such data collection at any time.
[0044] 1 illustrates an exemplary computing ecosystem 100 according to one embodiment of the present disclosure. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (also referred to herein as computing platform 110), and a user device 115 associated with a user 120. The user 120 may be a driver of the vehicle. In some examples, the user 120 may be a passenger in the vehicle. The vehicle 105, the computing platform 110, and the user device 115 may be configured to communicate with each other via one or more networks 125.
[0045] The systems / devices of ecosystem 100 may communicate using one or more application programming interfaces (APIs), which may include an externally facing API for communicating data from one system / device to another. The externally facing API may enable the systems / devices to establish a secure communication channel through any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), remote procedure calls (RPC), scripting access, etc., via a secure access channel on network 125.
[0046] The computing platform 110 may include a computing system that is remote from the vehicle 105. In one embodiment, the computing platform 110 may include a cloud-based server system. The computing platform 110 may include one or more backend services to support the vehicle 105. The services may include, for example, teleassist services, navigation / routing services, performance monitoring services, etc. The computing platform 110 may host or otherwise include one or more APIs for communicating data to or from the computing system 130 of the vehicle 105 or the user device 115.
[0047] Computing platform 110 may include one or more computing devices. For example, computing platform 110 may include control circuitry 185 and non-transitory computer-readable medium 190 (e.g., memory). Control circuitry 185 of computing platform 110 may be configured to perform various operations and functions described herein.
[0048] In one embodiment, control circuitry 185 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or any other control circuitry.
[0049] In one embodiment, control circuitry 185 may be programmed by one or more computer-readable or computer-executable instructions stored on non-transitory computer-readable medium 190 .
[0050] In one embodiment, non-transitory computer-readable medium 190 may be a memory device, also referred to as a data storage device, and may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. Non-transitory computer-readable medium 190 may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick. In some cases, non-transitory computer-readable medium 190 may store computer-executable or computer-readable instructions, such as instructions for performing the operations and methods described herein.
[0051] In various embodiments, the terms "computer-readable instructions" and "computer-executable instructions" are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, where the computer-readable or computer-executable instructions form a module, the term "module" refers broadly to a collection of software instructions or code configured to cause control circuitry 185 to perform one or more functional tasks. The modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuitry or other hardware components execute the modules or computer-readable instructions.
[0052] User device 115 may include a computing device owned or otherwise accessible by user 120. For example, user device 115 may include a phone, laptop, tablet, wearable device (e.g., smartwatch, smart glasses, headphones), personal digital assistant, gaming system, personal desktop device, other handheld device, or other type of mobile or non-mobile user device. As described further herein, user device 115 may include one or more input components, such as buttons, a touchscreen, a joystick or other cursor control, a stylus, a microphone, a camera or other imaging device, a motion sensor, etc. User device 115 may include one or more output components, such as a display device (e.g., a display screen), a speaker, etc. In one embodiment, user device 115 may include components, such as a touchscreen, configured to perform input and output functions to receive user input and present information for user 120. User device 115 may run an instance of a software application and execute one or more instructions to present a user interface associated therewith. The launch of a software application for each transport platform may initiate a user network session with computing platform 110 .
[0053] Network 125 may be any type of network or combination of networks that enables communication between devices. In some embodiments, network 125 may include one or more of a local area network, a wide area network, the Internet, a secure network, a cellular network, a mesh network, a peer-to-peer communication link, or some combination thereof, and may include any number of wired or wireless links. Communication over network 125 may be achieved, for example, through a network interface using any type of protocol, protection scheme, encoding, formatting, packaging, etc. Communication between computing system 130 and user device 115 may be facilitated by near- or short-range communication technology (e.g., Bluetooth low energy protocol, radio frequency communication, NFC protocol).
[0054] Vehicle 105 may be a vehicle operable by user 120. In one embodiment, vehicle 105 may be an automobile or another type of ground vehicle manually driven by user 120. For example, vehicle 105 may be a Mercedes-Benz® car or van. In some embodiments, vehicle 105 may be an aircraft (e.g., a personal airplane) or a water vehicle (e.g., a boat). Vehicle 105 may include operator assistance features such as cruise control, advanced driver assistance systems, etc. In some embodiments, vehicle 105 may be a fully or semi-autonomous vehicle.
[0055] The vehicle 105 may include a powertrain and one or more power sources. The powertrain may include a motor, an e-motor, a transmission, a driveshaft, an axle, a differential, electronics, gears, etc. The power source may include one or more types of power sources. For example, the vehicle 105 may be a fully electric vehicle (EV) that can use an electric battery to operate the vehicle's 105 powertrain (e.g., for propulsion) and the vehicle's onboard functions. In one embodiment, the vehicle 105 may use combustible fuel. In one embodiment, the vehicle 105 may include a hybrid power source, such as, for example, a combination of combustible fuel and electricity.
[0056] The vehicle 105 may include a vehicle interior. The vehicle interior may include areas inside the body of the vehicle 105, including, for example, a cabin for a user of the vehicle 105. The interior of the vehicle 105 may include a seat for the user, a steering mechanism, an accelerator interface, a braking interface, etc. The interior of the vehicle 105 may include a display device, such as a display screen, associated with an infotainment system. Such components may be referred to as display devices of the infotainment system or may be considered devices for implementing an embodiment that includes use of the infotainment system. For purposes of explanation and illustration, such components may be referred to herein as head unit display devices (e.g., located in the front / dashboard area of the vehicle interior), rear unit display devices (e.g., located in the rear passenger area of the vehicle interior), infotainment head units, rear units, etc.
[0057] The display device may display a variety of content to the user 120, including information about the vehicle 105, prompts for user input, etc. The display device may include a touchscreen through which the user 120 may provide user input to a user interface. The display device may be associated with an audio input device (e.g., a microphone) for receiving audio input from the user 120. In some embodiments, the display device may function as a dashboard for the vehicle 105. Exemplary display devices are shown in FIGS. 6, 7, and 8.
[0058] The interior of vehicle 105 may include one or more lighting elements, which may be configured to emit light in various colors, brightness levels, and the like.
[0059] The vehicle 105 may include a vehicle exterior. The vehicle exterior may include the exterior surface of the vehicle 105. The vehicle exterior may include one or more lighting elements (e.g., headlights, brake lights, accent lights). The vehicle 105 may include one or more doors for accessing the vehicle interior, for example, by operating a door handle on the vehicle exterior. The vehicle 105 may include one or more windows, including a windshield, door windows, passenger windows, rear windows, a sunroof, etc.
[0060] Certain typical and conventional components of vehicle 105 (e.g., an engine) are not shown and / or described herein for the sake of brevity. Those skilled in the art will understand the operation of conventional vehicle components within vehicle 105.
[0061] The vehicle 105 may include a computing system 130 onboard the vehicle 105. The computing system 130 may be located onboard the vehicle 105, in that it is contained on or within the vehicle 105. The computing system 130 may include one or more computing devices, which may include various computing hardware components. For example, the computing system 130 may include control circuitry 135 and non-transitory computer-readable medium 140 (e.g., memory). The control circuitry 135 may be configured to perform various operations and functions to implement the techniques described herein.
[0062] In one embodiment, control circuitry 135 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or any other control circuitry. In some embodiments, control circuitry 135 and / or computing system 130 may be part of or form a vehicle control unit (also referred to as a vehicle controller) integrated into or otherwise located in vehicle 105 (e.g., a Mercedes-Benz® car or van). For example, the vehicle controller may be or include an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charge controller, a central exterior and interior controller (CEIC), a zone controller, or any other controller (the terms “or” and “and / or” may be used interchangeably herein).
[0063] In one embodiment, control circuitry 135 may be programmed by one or more computer-readable or computer-executable instructions stored on non-transitory computer-readable medium 140 .
[0064] In one embodiment, non-transitory computer-readable medium 140 may be a memory device, also referred to as a data storage device, and may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. Non-transitory computer-readable medium 140 may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick. In some cases, non-transitory computer-readable medium 140 may store computer-executable or computer-readable instructions, such as instructions for performing the methods of FIGS. 10A-10B and 11 . Additionally or alternatively, similar such instructions may be stored on computing platform 110 (eg, non-transitory computer-readable medium 190 ) and provided over network 125 .
[0065] Computing system 130 (e.g., control circuitry 135) may be configured to communicate with other components of vehicle 105 via communication channels. The communication channels may include one or more data buses (e.g., a Controller Area Network (CAN)), an on-board diagnostic connector (e.g., OBD-II), or a combination of wired or wireless communication links. On-board systems may send or receive data, messages, signals, etc. between each other via the communication channels.
[0066] In one embodiment, the communication channel may include a direct connection, such as a connection provided through a dedicated wired communication interface, such as an RS-232 interface, a Universal Serial Bus (USB) interface, or through a local computer bus, such as a Peripheral Component Interconnect (PCI) bus. In one embodiment, the communication channel may be provided over a network. The network may be any type or form of network, such as a personal area network (PAN), a local area network (LAN), e.g., an intranet, a metropolitan area network (MAN), a wide area network (WAN), or the Internet. The network may utilize different technologies and protocol layers or stacks, including, for example, the Ethernet protocol, the Internet Protocol Suite (TCP / IP), ATM (Asynchronous Transfer Mode) technology, SONET (Synchronous Optical Networking) protocol, or SDH (Synchronous Digital Hierarchy) protocol.
[0067] In one embodiment, systems / devices of vehicle 105 may communicate via an intermediate storage device, or more generally, an intermediate non-transitory computer-readable medium. For example, non-transitory computer-readable medium 140, which may be external to computing system 130, may act as an external buffer or repository for storing information. In such an example, computing system 130 may retrieve or otherwise receive information from non-transitory computer-readable medium 140.
[0068] Vehicle 105 may include one or more human-machine interfaces (HMIs) 145. Human-machine interfaces 145 may include display devices, as described herein. The display devices (e.g., touchscreens) may be viewable by a user of vehicle 105 (e.g., user 120, second user 175) located at the front of vehicle 105 (e.g., driver's seat, passenger seat). Additionally or alternatively, the display devices (e.g., rear units) may be viewable by a user located at the rear of vehicle 105 (e.g., rear passenger seats).
[0069] The vehicle 105 may include one or more sensors 150. The sensors 150 may be configured to acquire sensor data. This may include sensor data associated with the vehicle's 105 surroundings, the vehicle's interior, or a particular vehicle function. The sensor data may indicate conditions observed inside the vehicle, outside the vehicle, or the surrounding environment. For example, the sensor data may acquire image data, interior / exterior temperature data, weather data, data indicating the location of a user / object within the vehicle 105, weight data, motion / gesture data, audio data, or other types of data. The sensors 150 may include one or more of a camera (e.g., a visible spectrum camera, an infrared camera), a motion sensor, an audio sensor (e.g., a microphone), a weight sensor (e.g., a vehicle seat), a temperature sensor, a humidity sensor, a light detection and ranging (LIDAR) system, a radio detection and ranging (RADAR) system, or other types of sensors. The vehicle 105 may also include other sensors configured to acquire data associated with the vehicle 105. For example, the vehicle 105 may include an inertial measurement unit, a wheel rotation measurement device, or other sensors.
[0070] Vehicle 105 may include a positioning system 155. Positioning system 155 may be configured to generate position data (also referred to as location data) indicative of the position (also referred to as location) of vehicle 105. For example, positioning system 155 may determine the position by using one or more of an inertial sensor (e.g., an inertial measurement unit, etc.), a satellite positioning system, based on an IP address, by using triangulation and / or proximity to network access points or other network components (e.g., cellular towers, WiFi access points, etc.), or by other suitable techniques. Positioning system 155 may determine the current location of vehicle 105. The location may be expressed as a set of coordinates (e.g., latitude, longitude), an address, a semantic location (e.g., "work"), etc.
[0071] In one embodiment, positioning system 155 may be configured to locate vehicle 105 within its environment. For example, vehicle 105 may access map data that provides detailed information about the vehicle's 105 surroundings. The map data may provide information about the identity and location of different roads, road segments, buildings, or other items, the location and direction of lanes (e.g., the location and direction of parking lanes, turning lanes, bicycle lanes, or other lanes within a particular road), traffic control data (e.g., the location, timing, or commands of signs (e.g., stop signs, yield signs), traffic lights (e.g., stop lights), or other traffic signals or control devices / markings (e.g., crosswalks)), or any other data. Positioning system 155 may locate vehicle 105 within the environment (e.g., across multiple axes) based on the map data. For example, positioning system 155 may process sensor data (e.g., LIDAR data, camera data, etc.) and match it with a map of the surrounding environment to gain an understanding of the vehicle's location within the environment. The determined location of the vehicle 105 may be used by various systems of the computing system 130 or may be provided to the computing platform 110 .
[0072] Vehicle 105 may include communication system 160 configured to enable vehicle 105 (and its computing system 130) to communicate with other computing devices. Computing system 130 may use communication system 160 to communicate with computing platform 110 or one or more other remote computing devices over network 125 (e.g., via one or more wireless signal connections). In some embodiments, communication system 160 may enable communication between one or more of the systems onboard vehicle 105.
[0073] In one embodiment, communication system 160 may be configured to enable vehicle 105 to communicate with or otherwise receive data from user device 115. Communication system 160 may utilize various communication technologies, such as, for example, Bluetooth® low energy protocol, radio frequency signaling, or other short-range or near-field communication technologies. Communication system 160 may include any suitable components for interfacing with one or more networks, including, for example, transmitters, receivers, ports, controllers, antennas, or other suitable components that may help to facilitate communication.
[0074] The vehicle 105 may include multiple vehicle functions 165A-165C. The vehicle functions 165A-165C may be functions that the vehicle 105 is configured to perform based on detected inputs. The vehicle functions 165A-165C may include one or more of the following: (i) a vehicle comfort function, (ii) a vehicle staging function, (iii) a vehicle environment function, (iv) a vehicle navigation function, (v) a driving style function, (v) a vehicle parking function, or (vi) a vehicle entertainment function.
[0075] Vehicle comfort features may include window features (e.g., for door windows, sunroofs), seat features, wall features, steering wheel features, pedal features, or other comfort features. In one embodiment, a seat feature may include, for example, a seat temperature feature to control the temperature of a seat. This may include a specific temperature (e.g., degrees C / F) or a temperature level (e.g., low, medium, high). In one embodiment, a seat feature may include a seat ventilation function to control a seat ventilation system. In one embodiment, a seat feature may include a seat massage function to control a massager device within the seat. The seat massage function may have one or more levels, each reflecting the intensity of the massage. In one embodiment, the seat massage function may have one or more programs / settings, each reflecting a different type or combination of massage. In one embodiment, a seat feature may include a seat position function to control the position of the seat in one or more directions, for example, forward / backward or up / down. A pedal function may control the position of one or more pedal controls (e.g., brake pedal, accelerator pedal) relative to the user's feet. A wall function may control the temperature of the interior walls or doors of the vehicle. The handle function may control the temperature, position, or vibration of the handle.
[0076] The vehicle staging function may control the interior lighting of the vehicle 105. In one embodiment, the vehicle staging function may include an interior lighting function. For example, the interior lighting function may control the color, brightness, intensity, etc. of the interior lighting (e.g., ambient lighting) of the vehicle 105. In one embodiment, the vehicle staging function may include one or more predetermined lighting programs or combinations. The programs may be set by a user or may be pre-programmed into the vehicle 105's default settings. In some embodiments, the vehicle staging function may include an exterior lighting function. For example, the exterior lighting function may control accent lighting located underneath or along the exterior of the vehicle 105.
[0077] Vehicle environment functions may control the interior environment of vehicle 105. In one embodiment, vehicle environment functions may include an air conditioning / heating function for controlling an air conditioning / heating system or other system related to setting the temperature within the cabin of vehicle 105. In one embodiment, vehicle environment functions may include a defrost or fan function for controlling the level, type, and / or location of air flow within the cabin of vehicle 105. In one embodiment, vehicle environment functions may include an air fragrance function for controlling the fragrance within the interior of vehicle 105.
[0078] Vehicle navigation functions can control the vehicle's systems to provide a route to a particular destination. For example, the vehicle 105 can include an in-vehicle navigation system that provides the user 120 with a route for traveling to the destination. The navigation system can utilize map data and Global Positioning System (GPS)-based signals to provide directions to the user 120 via a display device inside the vehicle 105.
[0079] The vehicle parking function may control parking-related features of the vehicle. In one embodiment, the vehicle parking function may include a parking camera function that controls a side camera, a rear camera, or a 360-degree camera to assist the user 120 in parking the vehicle 105. Additionally or alternatively, the vehicle parking function may include a parking assist function that helps maneuver the vehicle 105 into a parking area.
[0080] Vehicle entertainment functions may control one or more entertainment-related features of the vehicle 105. For example, the vehicle entertainment functions may include a radio function for controlling a radio or a media function for controlling another source of audio or visual media. The vehicle entertainment functions may control sound quality parameters (e.g., volume, bass, treble, speaker distribution) or may select a radio station or media content type / source.
[0081] Each vehicle function may include a controller 170A-170C associated with that particular vehicle function 165A-165C. The controller 170A-170C for a particular vehicle function may include control circuitry configured to operate its associated vehicle function 165A-165C. For example, a controller may include circuitry configured to turn on a heated seat function, turn off a heated seat function, set a particular temperature or temperature level, etc.
[0082] In one embodiment, controller 170A-170C for a particular vehicle function may include or otherwise be associated with a sensor that captures data indicating that vehicle function is turned on or off, the setting of that vehicle function, etc. For example, the sensor may be an audio sensor or a motion sensor. An audio sensor may be a microphone configured to capture audio input from user 120. For example, user 120 may provide a voice command to activate a radio function of vehicle 105 and request a particular station. A motion sensor may be a visual sensor (e.g., camera), infrared, radar, etc. configured to capture gesture input from user 120. For example, user 120 may provide a hand gesture motion to adjust a temperature function of vehicle 105 to lower the temperature inside the vehicle.
[0083] Controllers 170A-170C may be configured to send signals to control circuitry 135 or another in-vehicle system. The signals may encode data associated with the respective vehicle functions. The encoded data may indicate, for example, function settings, timing, etc.
[0084] User 120 may interact with vehicle features 165A-165C through user input. The user input may specify a setting for vehicle feature 165A-165C selected by the user (a "user-selected setting"). In one embodiment, vehicle features 165A-165C may be associated with a physical interface, such as a button, knob, switch, lever, touchscreen interface element, or other physical mechanism. The physical interface may be physically manipulated to control vehicle feature 165A-165C in accordance with the user-selected setting. As an example, user 120 may physically manipulate a button associated with a seat massage function to set the seat massage function to a massage intensity of level 5. In one embodiment, user 120 may interact with vehicle features 165A-165C via user interface elements presented on a user interface of a display device (e.g., of a head unit infotainment system).
[0085] The techniques of this disclosure may utilize artificial intelligence, including machine learning models, to learn the routines or patterns of a user 120 interacting with vehicle functions and generate a database of actions for that vehicle function that can be automatically performed by the vehicle 105 for a particular user 120. These automatically executable actions may be referred to as “automated vehicle actions.” The user 120 may authorize and activate the computing system 130 to capture data and generate these automated vehicle actions. Such authorization / activation may be provided via user input to a user interface of a display device (e.g., an infotainment system of the vehicle 105). Techniques for generating automated vehicle actions are now described in more detail.
[0086] 2 illustrates a diagram of an exemplary computing architecture 200 for generating automated vehicle actions, according to one embodiment of the present disclosure. Architecture 200 may include (i) various databases for stored information, (ii) services that perform automated tasks, respond to hardware events, provide data, listen for data requests from other software, etc., and (iii) software clients. In one embodiment, the services and clients may be implemented as modules within their respective computing systems. For example, the services and clients may be implemented as modules on vehicle 105 (e.g., within computing system 130) or remote from vehicle 105 (e.g., within computing platform 110).
[0087] Computing system 130 may include various services and databases that may be implemented on vehicle 105 to generate automated vehicle actions based on the learned routines of user 120. In one embodiment, computing system 130 may include vehicle function services 205A-205C, embedded learning service 210, model database 215, vehicle action manager 220, vehicle embedded services 225, and automated vehicle action database 230.
[0088] Vehicle function services 205A-205C may be configured to listen for data associated with vehicle functions 165A-165C. In one embodiment, computing system 130 may include one vehicle function service 205A-205C for each vehicle function 165A-165C. Vehicle function services 205A-205C may listen for context data associated with the respective vehicle function (e.g., via controllers 170A-170C, associated sensors, etc.). The context data may indicate the setting of vehicle function 165A-165C selected by user 120 (the "user-selected setting") and the condition observed at the time of the user-selected setting (the "observed condition"). The user-selected setting may include (i) an on / off selection, (ii) an open / close selection, (iii) a temperature selection, (iv) a function-specific program / setting selection (e.g., a seat massage level selection, a seat heating temperature level selection), or another type of selection. The vehicle function services 205A-205C may be configured to communicate the context data to the embedded learning service 210 or the vehicle embedded service 225.
[0089] The embedded learning service 210 may be configured to learn routines or patterns of user interactions with particular vehicle features 165A-165C and generate automated vehicle actions using one or more models. The embedded learning service 210 may access models from a model database 215. The model database 215 may store models that may be specific to each of the various vehicle features 165A-165C of the vehicle 105. In one embodiment, the model database 215 may store a data structure that indexes or catalogs models based on their associated vehicle features 165A-165C. The embedded learning service 210 may access a particular model based on the vehicle features 165A-165C indicated in the received context data.
[0090] The embedded learning service 210 may include a learning kernel that is continuously training and predicting user routines. These learnings may be formulated into automated vehicle actions and suggested to the user 120. The process / data pipeline by which the embedded learning service 210 analyzes contextual data to generate automated vehicle actions is described in more detail below with reference to FIG. 3.
[0091] 2 , vehicle action manager 220 may be configured to manage automated vehicle actions. In one embodiment, vehicle action manager 220 may include services for performing its management responsibilities. Managing automated vehicle actions may include, for example, creating and modifying automated vehicle actions, conflict analysis, persisting automated vehicle actions, context observation, and coordinating the distribution of automated vehicle actions. Vehicle action manager 220 may be programmed to implement a collection of components and libraries for managing the generation of automated vehicle actions. In some implementations, vehicle action manager 220 may include a framework that utilizes one or more software factories to return one or more objects for use by vehicle action manager 220.
[0092] In one embodiment, vehicle action manager 220 may provide one or more software development kits (SDKs) that assist in enabling a vehicle (e.g., its clients and services) to create and execute automated vehicle actions. For example, an SDK may include a standardized object library based on interface definitions, client objects for establishing communication to another client or device (e.g., IPC communication to a cloud platform), client authentication mechanisms, standardized logging and metrics (analytics) hooks and tooling, and / or other factors.
[0093] In one embodiment, the vehicle action manager 220 may include a client interface to the vehicle action manager 220 services. For example, the vehicle action manager 220 may include a client interface configured to establish a client connection to the vehicle action manager 220 in-vehicle services. This may include establishing a connection to the service using inter-process communication (IPC), such as Unix domain sockets (UDS) or message queuing (mqueue). In one embodiment, the manager client may not utilize client authentication onboard the vehicle 105. For example, the client-service relationship may be established at software build time such that a client process that links to the SDK may be provided with the ability to interact with the vehicle action manager 220 services.
[0094] Vehicle embedded services 225 may be services for synchronizing, maintaining, and managing the execution of automated vehicle actions. In one embodiment, vehicle embedded services 225 may provide an API and a bridge to vehicle 105 for various clients to extract contextual data (e.g., as data points) and perform automated vehicle actions. For example, vehicle embedded services 225 may maintain automated vehicle action database 230. As described further herein, automated vehicle action database 230 may store data structures including command instructions for automated vehicle actions associated with a particular user 120 or user profile. In one embodiment, automated vehicle action database 230 may simultaneously store automated vehicle actions for more than one user (or user profile). Vehicle embedded services 225 may be configured to receive data from vehicle function services 205A-205C and determine whether a trigger condition exists for the stored automated vehicle action. Vehicle embedded services 225 may be configured to send a signal to control vehicle functions 165A-165C according to the automated vehicle action if a trigger condition exists, as described further herein.
[0095] Vehicle embedded services 225 may be configured to synchronize automated vehicle actions with a computing system remote from vehicle 105. For example, vehicle embedded services 225 may be configured to send data indicative of automated vehicle actions generated onboard vehicle 105 to computing platform 110 (e.g., a cloud-based server system).
[0096] Computing platform 110 may include various services and databases that may be implemented on its servers to assist in the management and generation of automated vehicle actions. In one embodiment, computing platform 110 may include cloud embedded services 235 and cloud database 240.
[0097] Cloud embedded service 235 may be a service for synchronizing, maintaining, and managing automated vehicle actions in a system remote from vehicle 105. In one embodiment, cloud embedded service 235 may provide an API for various clients to manage automated vehicle actions. Possible clients may include, for example, a service running onboard vehicle 105, a mobile software application (e.g., iOS, Android), or a web application.
[0098] In one embodiment, cloud embedded services 235 may include or be otherwise associated with a cloud manager (off-vehicle) configured to perform operations and functions similar to vehicle action manager 220. For example, the cloud manager may include a client configured to establish a client connection to the cloud manager service (e.g., connecting to the service using a TCP-based protocol such as HTTP). In some embodiments, client authentication may be required to establish the connection. This may include, for example, using a token-based authentication scheme.
[0099] The cloud embedded service 235 may be configured to maintain a data structure that identifies automated vehicle actions for a particular user 120. This may include, for example, receiving data indicative of an automated vehicle action generated in the vehicle 105, identifying a particular user profile 245 of the user 120 of the vehicle 105 for which the automated vehicle action was generated, and providing the data indicative of the automated vehicle action for storage in association with the user profile 245 in the cloud database 240. The cloud embedded service 235 may identify a user profile 245 from among multiple user profiles based on the data provided from the vehicle 105. This may include encrypted pseudonymized data associated with the user 120 (e.g., an encrypted user ID), which may be decrypted and used with a lookup function to access the appropriate user profile 245. The cloud embedded service 235 may be configured to update the cloud database to include new automated vehicle actions or to remove automated vehicle actions (e.g., when an action is disabled or deleted by a user).
[0100] Cloud database 240 may store information for multiple users. For example, cloud database 240 may store multiple data structures containing automated vehicle actions. Each data structure may include a table or list of automated vehicle actions associated with a particular user profile. The table / list may index the automated vehicle actions according to vehicle function 165A-165C. Each data structure may be adjusted to reflect an updated representation of the automated vehicle actions associated with a particular user profile (e.g., when new actions are created, previous actions are removed, etc.).
[0101] In one embodiment, cloud embedded service 235 may be configured to provide data indicative of a user profile and its associated vehicle actions to vehicle 105. For example, user 120 may be identified by vehicle embedded service 225 when user 120 enters the vehicle (e.g., based on a handshake between the user's key or user device and vehicle 105, a user profile selection on a head unit display). User 120 may be different from the last user to operate vehicle 105. Vehicle embedded service 225 may send pseudonymized data indicative of the user and request data indicative of user profile 245 (and its associated automated vehicle actions) for user 120. Cloud embedded service 235 may receive this request, access cloud database 240 to retrieve the requested data, and send data indicative of the requested user profile 245 (and its associated automated vehicle actions) to vehicle embedded service 225. Vehicle embedded service 225 may store data indicative of automated vehicle actions associated with user 120 (e.g., as an active user of vehicle 105) in automated vehicle action database 230.
[0102] In one embodiment, vehicle embedded service 225 may request two or more user profiles from cloud embedded service 235. For example, two users, a first user 120 as a driver and a second user 175 as a passenger (shown in FIG. 1 ), may enter vehicle 105. Computing system 130 may detect the presence of the first user based on a handshake between the first user's key (or mobile device) and vehicle 105, or first user 120 may provide user input to a display device of vehicle 105 to select the first user's user profile. Computing system 130 may detect the presence of the second user 175 based on a handshake between the second user's key (or mobile device) and vehicle 105, or second user 175 may provide user input to a display device of vehicle 105 to select the second user's profile. In response, computing system 130 may send a request for the first user profile of first user 120 and the second user profile of second user 175 to cloud embedded service 235. Cloud embedded service 235 may retrieve data indicative of the first and second user profiles from cloud database 240 and send the profile data to computing system 130. As described herein, the simultaneous use of multiple user profiles on vehicle 105 may enable embedded learning service 210 to learn user routines for two different users during the same (or overlapping) time period.
[0103] Cloud embedded service 235 may be configured to track the performance of the models utilized to generate automated vehicle actions. For example, cloud embedded service 235 may be configured to track the frequency with which automated vehicle actions generated by embedded learning service 210 are rejected by users 120.
[0104] 3 illustrates a diagram of an example data pipeline 300 for generating automated vehicle actions using multiple models, according to one embodiment of the present disclosure. The following description of the data flow in the data pipeline 300 is described using an example implementation in which the computing system 130 utilizes multiple models to generate automated vehicle actions on the vehicle 105. Additionally or alternatively, one or more portions of the data flow in the data pipeline 300 may be implemented within the computing platform 110.
[0105] The computing system 130 may receive context data 305 associated with multiple user interactions with vehicle features 165A-165C of the vehicle 105 across multiple time instances. The vehicle function services 205A-205C associated with each vehicle feature 165A-165C may provide the context data 305. The user interactions may include the user 120 interacting with an interface (e.g., physical buttons, soft buttons) of the vehicle feature 165A-165C to adjust the vehicle feature 165A-165C according to user-preferred settings 310. This may include turning the vehicle feature 165A-165C to an “on” state, an “open” state, setting an intensity level, etc.
[0106] The context data 305 can indicate multiple user preferences 310 across multiple time instances. Each time instance can be a point in time, a time range, a time of day, a stage of a day (e.g., morning, midday, afternoon, evening, night), a day of the week, a week, a month, a specific date, etc. Each time instance can indicate when a user interaction occurred (e.g., when a vehicle function service 205A-205C detected a user interaction) or when the context data was sent or received by the embedded learning service 210.
[0107] The context data 305 may indicate one or more observed conditions 315 associated with the user-selected settings 310. The observed conditions 315 may be captured at a time instance associated with a user interaction. The computing system 130 may receive data indicative of the observed conditions 315 via multiple sensors 150 or systems (e.g., positioning system 155) of the vehicle 105. In one embodiment, the data indicative of the observed conditions 315 may be provided via associated vehicle function services 205A-205C.
[0108] Observed conditions 315 may indicate particular conditions occurring when user 120 interacts with each vehicle feature 165A-165C. For example, observed conditions 315 may include at least one of: (i) the date and / or time at which each user interaction with vehicle feature 165A-165C occurred; (ii) the location at which each user interaction with vehicle feature 165A-165C occurred; (iii) the route taken during each user interaction with vehicle feature 165A-165C; or (iv) the temperature at which each user interaction with vehicle feature 165A-165C occurred. The route may be a route requested by the user via the vehicle's navigation function and followed by the user to the destination. In one embodiment, observed conditions 315 may include other information, such as weather conditions, traffic conditions, etc.
[0109] FIG. 4 illustrates exemplary context data 305 associated with multiple user interactions with vehicle features 165A-165C of vehicle 105 across multiple time instances. Each row illustrated in FIG. 4 may represent a respective user interaction. As illustrated, each user interaction is associated with a time (e.g., date and time) and may include user-selected settings 310 for vehicle features 165A-165C. As an example, on Monday, user 120 manually sets seat ventilation to level 3, turns on the seat massage function and sets it to "typical massage," and opens the driver's side window. Each of these user-selected settings 310 is recorded along with the observed conditions 315. As illustrated in the example, each user-selected setting 310 is associated with the day, time, location (e.g., latitude / longitude coordinates), and temperature at which it was observed.
[0110] 3, computing system 130 may utilize a machine learning model to determine whether a routine or pattern exists within context data 305. For example, computing system 130 may utilize a model such as machine learning clustering model 320. Additionally or alternatively, computing system 140 may utilize a rule-based clustering model.
[0111] In one embodiment, the machine learning clustering model 320 may be an unsupervised learning model configured to group input data into clusters such that similar data points are grouped together and dissimilar data points are distinguished. The machine learning clustering model 320 may process the context data 305 using cluster analysis (e.g., probabilistic clustering) to generate user activity clusters 500A-500C based on user interactions with particular vehicle features 165A-165C. Using the machine learning clustering model 320 may include processing the context data 305 with one or more cluster modeling techniques. This may include applying one or more of the following to the context data 305: K-means clustering, KNN (k-nearest neighbors), K-medians clustering, expectation maximization model, hierarchical clustering, density-based spatial clustering for applications with noise (DBSCAN), ordering to identify cluster structure (OPTICS), anomaly detection, principal component analysis, independent component analysis, prior algorithms, or other techniques. The machine learning clustering model 320 may include or be otherwise influenced by several hyperparameters, such as, for example, the number of clusters.
[0112] The unsupervised learning model may be trained based on training data that does not contain labels (or that contains only a few labels). Training may include methods such as Hopfield learning rule, Boltzmann learning rule, contrastive divergence, wake-sleep, variational inference, maximum likelihood estimation, posterior probability maximization, Gibbs sampling, or backpropagation for reconstruction error or hidden state reparameterization. Training of the machine learning clustering model 320 is further described below with reference to FIG. 12.
[0113] As described herein, the model database 215 may include multiple machine learning clustering models. Each machine learning clustering model may be associated with a particular vehicle feature 165A-165C. By assigning individual machine learning clustering models to specific vehicle features, each machine learning clustering model can focus its learning on data associated with a single vehicle feature, as opposed to attempting to learn patterns and identify clusters across multiple vehicle features. This can improve the reliability of the model as well as the accuracy of the clusters generated by the dedicated model.
[0114] The computing system 130 may select, invoke, or otherwise implement the machine learning clustering model 320 from among multiple machine learning clustering models (e.g., stored in the model database 215) based on one or more vehicle features 165A-165C indicated in the context data 305. For example, given the example context data 305 shown in FIG. 4, the computing system 130 may select at least one of (i) a machine learning clustering model for a seat ventilation function, (ii) a machine learning clustering model for a seat massage function, or (iii) a machine learning model for a window function. The computing system 130 may select the various models by analyzing the context data 305 to determine data types and determining models for each of those data types. The computing system 130 may select the various models by invoking (e.g., using a function call) a specific model for processing a particular portion of the context data 305 (e.g., invoking a respective model for each column of tabular data, etc.).
[0115] The computing system 130 may use a machine learning clustering model 320 to generate user activity clusters 500A-500C of vehicle features 165A-165C based on the context data 305. The machine learning clustering model 320 may be configured to identify the user activity clusters 500A-500C based at least in part on the user-selected settings 310 and at least in part on one or more observed conditions 315 associated with each user-selected setting. More specifically, the machine learning clustering model 320 may be configured to perform cluster analysis to group (or partition) data points with shared attributes in order to infer algorithmic relationships between the user-selected settings 310 and the observed conditions 315 for particular vehicle features 165A-165C.
[0116] 5A-5D, the computing system 130 may record multiple data points over the course of a week's work. Each data point may be associated with a specific user interaction with a vehicle feature 165A-165C and may represent user-specific variables for a given user interaction. For example, each data point may indicate observed conditions (e.g., time, location, temperature) and may include metadata indicating user-selected settings 310 with the respective vehicle feature. For example, FIG. 5A shows exemplary data points 505 recorded for a user interaction with the ventilation function (e.g., setting it to level 3). FIG. 5B shows exemplary data points recorded for a user interaction with the seat massage function (e.g., setting it to "typical massage"). FIG. 5C shows exemplary data points recorded for a user interaction with the window function (e.g., opening a window). FIG. 5D shows exemplary data points recorded for a user interaction with the staging function (e.g., selecting an ambient light setting).
[0117] The machine learning clustering model 320 may be configured to process the context data 305 (e.g., the context data resulting in the data points 505) using probabilistic clustering to generate user activity clusters 500A-500C. The user activity clusters 500A-500C may be specific sets of values of context features based on time, location, and other observed conditions 315. The user activity clusters 500A-500C are groupings of data points 505 of the context data 305 that exhibit sufficient commonality between each other to represent the personalized routine of the user 120. In one embodiment, the machine learning clustering model 320 may apply a probability distribution to the data points that may describe the probability (e.g., confidence) that the data points belong within the user activity clusters 500A-500C. As an example, the machine learning clustering model 320 may be configured to generate a first user activity cluster 500A that represents the routine of the user 120 when interacting with a seat ventilation feature. The first user activity cluster 500A may be considered complete (or closed) when the model has analyzed enough data points to reach a threshold level of confidence that the data points are grouped into the first user activity cluster 500A. A similar process may be used to generate a second user activity cluster 500B for the seat massage function and a third user activity cluster 500C for the window function.
[0118] The machine learning clustering model 320 may be configured to determine boundaries of user activity clusters 500A-500C for vehicle functions based on one or more observed conditions 315. For example, the boundaries of the user activity clusters 500A-500C may be defined by the outermost time, location, and temperature of the data points included in each user activity cluster 500A-500C. The boundaries of the user activity clusters 500A-500C may be defined by cutoff probabilities of probability distributions along the dimensions of the user activity clusters 500A-500C. The boundaries of the user activity clusters 500A-500C may be defined by distances from anchor points (e.g., centroids) of a given cluster. The boundaries of the user activity clusters 500A-500C may be implicitly encoded in parameters of a machine learning classification model configured to receive a set of input context data and output a classification (e.g., cluster classification).
[0119] In one embodiment, the machine learning clustering model 320 may not generate a user activity cluster if the user activity cluster does not reach a threshold confidence level. As an example, as shown in FIG. 5D , the context data 305 includes only two user interaction data points for the staging function over the represented time frame. Therefore, the machine learning clustering model 320 may not yet have enough data / confidence to generate a user activity cluster that potentially represents a routine for the staging function.
[0120] Returning to FIG. 3 , the computing system 130 may determine an automated vehicle action 330 for each vehicle function 165A-165C based on the user activity clusters 500A-500C for that vehicle function 165A-165C. The automated vehicle action 330 may be considered a skill / routine of the vehicle 105 that describes the automated execution of the vehicle function 165A-165C based on the context. For example, the automated vehicle action 330 may indicate an automatic setting 335 for the vehicle function 165A-165C and one or more trigger conditions 340 for automatically implementing the automatic setting 335. More specifically, the automated vehicle action 330 may define a relationship between the one or more trigger conditions 340 and one or more settings 335 of the vehicle function 165A-165C. By way of example, as described further herein, the automated vehicle action 330 may include a logic statement (e.g., an if / then statement) or learned model output indicating that if the trigger condition 340 is detected, the vehicle 105 will automatically control the vehicle functions 165A-C in accordance with the automatic setting 335 (e.g., to activate the setting).
[0121] In one embodiment, to assist in determining automated vehicle actions 330, computing system 130 may use or otherwise utilize vehicle action model 325. Vehicle action model 325 may be responsible for learning user 120's preferences among different settings / programs associated with vehicle functions 165A-165C.
[0122] The vehicle action model 325 may include a weighting algorithm that may be applied to the learned user activity clusters 500A-C. For example, the vehicle action model 325 may be a rule-based model configured to apply a respective weight 345 to each of the respective user-preference settings 310 in the user activity clusters 500A-C. The weight 345 may be, for example, a number assigned to each of the user-preference settings 310 indicating its importance with respect to the user's preferences.
[0123] Every user activity cluster 500A-500C may have an independent set of weights 345 associated with it, corresponding to a vehicle function 165A-165C. For example, the set of weights 345 applied to a first user activity cluster 500A associated with a seat ventilation function may be different from the set of weights 345 applied to a second user activity cluster 500B associated with a window function. The seat ventilation function may have several ventilation levels (e.g., 1, 2, 3, 4, 5, etc.), and the window function may include two states (e.g., open, closed). As a result, in one embodiment, additional weighting may be applied to the first user activity cluster 500A associated with the seat ventilation function than to the second user activity cluster 500B associated with the window function.
[0124] The computing system 130 may process the user activity clusters 500A-500C using the vehicle action model 325 to determine the automatic settings 335 of the vehicle features 165A-165C based on the weights 345 of the respective user-selected settings 310 in the user activity clusters 500A-500C. In one embodiment, the weights 345 of each possible setting of the vehicle features 165A-165C may be set to the same value at cluster creation. The vehicle action model 325 may use a set of rules to adjust / update the weights 345 of the user-selected settings 310 as the user interacts with the vehicle features 165A-165C to set the user-selected settings 310.
[0125] The rules may be based on the type of interaction the user 120 has with the vehicle features 165A-165C. For example, the set of rules for adjusting the weights 345 may include positive interaction rules, negative interaction rules, and neutral interaction rules. In one embodiment, a positive interaction rule may indicate that when the user 120 activates (e.g., turns on, opens) a particular user-selected setting 310, the weight of that user-selected setting 310 is increased (e.g., +1). In one embodiment, a negative interaction rule may indicate that when the user 120 deactivates (e.g., turns off) a particular user-selected setting 310 or performs an action explicitly opposite to the positive interaction (e.g., closes a window), the weight of that user-selected setting 310 is decreased (e.g., −1).
[0126] In one embodiment, a neutral interaction rule may indicate that the weight 345 of a particular user-selected setting 310 will not change based on a user interaction. This may occur when a condition in a user activity cluster 500A-500C occurs, but the user 120 does not perform an action that would have been performed previously in that context. As an example, a neutral interaction may be identified when the user 120 does not actively close or open a window, but rather does not interact with the window, leaving the state unchanged despite the occurrence of an observed condition 315 that would fall within the scope of the user activity cluster 500C. In some embodiments, a neutral interaction may be treated as negative reinforcement (e.g., for seat heating, ventilation).
[0127] In one embodiment, vehicle action model 325 may be configured to represent user interactions with vehicle features 165A-165C as a distribution. For example, user interactions may be modeled as a multinomial distribution. A multinomial distribution may include a distribution over the observed counts of each possible category in a set of categorically distributed observations. Under this approach, weights 345 may be parameterized by a Dirichlet distribution (e.g., a conjugate prior of the multinomial distribution).
[0128] In one embodiment, each user activity cluster 500A-500C may have an independent Dirichlet distribution corresponding to user interactions with the associated vehicle feature 165A-165C. The parameters of the Dirichlet distribution may contain information representing the confidence of a particular user-selected setting 310 being used by the user 120 and its probability relative to other settings for the respective vehicle feature 165A-165C. The average of the parameters of every setting / program for a vehicle feature 165A-165C may constitute the likelihood of use by the user 120 within that user activity cluster 500A-500C (e.g., given observed conditions). In one embodiment, for all vehicle features 165A-165C with "X" settings / programs, the Dirichlet distribution for each user activity cluster 500A-500C may have (X+1) parameters, one for each possible setting / program and an additional one for the "off" setting.
[0129] The parameters (e.g., weights) may be updated according to the positive and negative rules described above based on user interaction with the associated settings / programs. In one example, positive reinforcement may correspond to an incremental increase in the weight of a user-selected setting 310 within a user activity cluster 500A-C, and negative reinforcement may correspond to an incremental increase in the weight of an "off" setting.
[0130] Vehicle action model 325 may be configured to generate a similar type of distribution to identify day of week preferences within each user activity cluster. For example, the seven days of the week may be modeled as a Dirichlet distribution. Vehicle action model 325 may initialize weights 345 for each day with the same weight value and update weights 345 for each day based on the occurrence of user interactions on that day.
[0131] In one embodiment, the vehicle action model 325 may be configured to determine the automated vehicle action 330 based on a threshold value 350. The threshold value 350 may include a preset threshold value representing a minimum probability required before an automated vehicle action 330 (e.g., its automatic setting 335) is determined. For example, the threshold value 350 may be expressed as a minimum value that the weight 345 of a particular user-selected setting 310 must reach before the vehicle action model 325 determines that the particular user-selected setting 310 should be used as the basis for the automatic setting 335.
[0132] The following provides an example of how the computing system 130 may process the user activity clusters 500A-C using the vehicle action model 325. In this example, the seat massage function may include three possible settings for activating the seat massage function: “gentle,” “typical,” and “firm,” as well as an “off” setting. An initial weight for each of these settings may be assigned 1, which may be represented as a Dirichlet distribution with centered parameters [1, 1, 1, 1]. Within the same user activity cluster (e.g., given similar observed conditions 315), the user 120 may interact with the “gentle” setting once and the “typical” setting four times. The “gentle” and “typical” settings may be considered user-selected settings 310, and the computing system 130 may adjust their associated weights accordingly. For example, the computing system 130 (e.g., the vehicle action model 325) may update the corresponding Dirichlet parameters to [1 + 1, 1 + 4, 1, 1] = [3, 5, 1, 1]. These weight values may be converted to probability weights by dividing by the total weight, e.g., 3+5+1+1=10. Thus, the respective probabilities may be [0.3, 0.5, 0.1, 0.1], indicating that the vehicle action model 325 has a confidence level of 30%, 50%, 10%, and 10%, respectively, for each setting. Thus, the vehicle action model 325 may determine that the “typical” massage setting is the preferred setting for the user 120 in this particular user activity cluster 500A. Thus, the vehicle action model 325 may select the “typical” massage setting as the automatic setting 335 for a given automated vehicle action 330.
[0133] In one embodiment, the action explanation model 355 can build a decision-making framework that explains patterns of user activity revealed by the processed user activity clusters 500A-C. The action explanation model 355 may utilize rule-based or heuristic-based techniques as well as machine learning methods. The action explanation model 355 may be configured to translate the user activity clusters 500A-C and the automatic settings 335 into automated vehicle actions 330 that mimic the patterns of user activity. The action explanation model 355 may be configured to assist in generating the automated vehicle actions 330 in a format understandable to the vehicle 105 or the user 120. This may include, for example, assisting in determining trigger conditions 340 for automatically executing the automatic settings 335 of the vehicle functions 165A-C.
[0134] In one embodiment, the action explanation model 355 can operate directly on the context data 305 (e.g., access the user-selected settings 310). Additionally or alternatively, the action explanation model 355 may probabilistically sample simulated user activities in clusters based on the relative probabilities determined for various settings, optionally without accessing the user-selected settings 310. Such simulated user activities provide training data for training / testing the decision-making framework generated by the action explanation model 355.
[0135] In one embodiment, the action explanation model 355 may construct a decision boundary in the context feature space. The decision boundary may provide an interpretable range of parameter values for the context data, and collectively may approximate the area of the context feature space output by the machine learning clustering model.
[0136] In one embodiment, the action explanation model 355 can process data using a rule-based approach to find deterministic feature boundaries for the context features used in clustering. Context features may include observed conditions 315 (e.g., latitude, longitude, temperature, time of day). For all user activity clusters 500A-500C, the individual dimensions of the multivariate Gaussian distribution may be assumed to be independent Gaussians. The feature boundaries may be defined by the following range [min, max] = [m l · s, m + l · s], where m is the feature mean, s is the standard deviation of the individual distributions, and l is a hyperparameter that can take values from 1 to 3 depending on the desired level of granularity for the automated vehicle actions 330. The minimum and maximum values of the feature boundaries may be used to determine trigger conditions 340 for the automatic configuration 335 of vehicle functions 165A-165C.
[0137] In one embodiment, the action explanation model 355 may obtain decision boundaries in the context feature space that form a hyperrectangle or hypercube. For example, the edges of the hyperrectangle may be ranges of values for a given feature (e.g., the endpoints of the segments that form the edges are the minimum and maximum values of the range).
[0138] In one embodiment, the action explanation model 355 may evaluate the relative influence of one or more context features (e.g., one or more dimensions in the context feature space). For example, some context feature dimensions may not have a meaningful impact on feature settings and therefore may be deprioritized or ignored even if present in the determined cluster. For example, some characteristics may be random, a proxy for other features, or imperfectly observed. For example, the action explanation model 355 may determine that time of day is less influential with respect to interior heating settings than external temperature. This may cause the action explanation model 355 to decide to omit or relax a decision boundary on the time axis in the context feature space for heating settings. For example, even if a user has never turned on the heater at a time outside of a set of previously observed behaviors (e.g., 3:00 AM), the action explanation model 355 may determine a decision boundary that does not exclude that data point based on its outlier time value when a more influential criterion is met (e.g., external temperature below 32°F).
[0139] In one embodiment, the action explanation model 355 may include one or more hypercubes 360, which may be thought of as "approximators" for each of the user activity clusters 500A-C, and a multicube 365, which may be defined as a collection of hypercubes 360. The multicube may be a three-way bridge between the vehicle action model 325, the collection of hypercubes 360, and the automated vehicle actions 330 presented to the user 120.
[0140] In one example, the multicube 365 can train all the hypercubes 360, perform learning of the hypercubes 360, and present them to the user 120. This can be accomplished via a three-stage approach.
[0141] In a first stage, the multicube 365 can simulate usage data for each user activity cluster 500A-C. The multicube 365 can simulate data emulating different context regions that intelligently cover the topological space learned by the machine learning clustering model 320 using a custom Metropolis-Hastings-inspired sampling algorithm. Each simulated data point can be a numeric vector corresponding to each context feature being learned (e.g., observed condition 315) and a "target" value indicating whether the user 120 engaged in a user interaction in that context space.
[0142] In a second stage, for each user activity cluster 500A-C, the data may be passed to a hypercube object that identifies a subset of context features that were most important in the user's interaction with the respective vehicle feature 166A-C (e.g., the observed conditions that had the highest impact in the user activity cluster 500A-C). For example, for a heated seat feature, interior temperature and exterior temperature may be the two main factors that influence a particular user's 120 use of heated seats. The most important features may be determined by a custom scoring function that uses: (i) features with the highest variance, (ii) features with higher mutual information scores relative to the "target" value in the first stage, and (iii) features with higher chi-square scores relative to the "target" value in the first stage.
[0143] In a third stage, for each of these key features, the action explanation model 355 may calculate minimum and maximum bounds. For example, as described herein, a hypercube 360 may be trained for each user activity cluster 500A-500C across multiple context features (e.g., observed conditions 315). The hypercube 360 may approximate the context region learned by the machine learning clustering model 320 by partitioning the region into a collection of hyperrectangles (e.g., higher-dimensional cubes). The hypercube 360 may take as input the information generated by the machine learning clustering model 320 and the vehicle action model 325 and approximate this into a higher-dimensional cube that may be presented as automated vehicle actions 330 for the user 120. In this way, over the second and third stages, the action explanation model 355 can determine preferred features to use as the first edges of the hyperrectangle based on a custom scoring function, appropriately characterize the model output, determine decision boundary rules that maximize information gain in each context space using the preferred features and target variables, and translate the discovered rules / constraints into boundaries for the edges of the hyperrectangle.
[0144] In one embodiment, computing system 130 may utilize additional or alternative statistical techniques to determine trigger condition 340. For example, as described herein, trigger condition 340 may be based on observed conditions 315 in user activity clusters 500A-C. In one example, trigger condition 340 may be defined by minimum and maximum values of observed conditions 315 in a user activity cluster. As shown in FIG. 4 , observed conditions 315 recorded in user activity cluster 500A for a seat ventilation function may indicate that user 120 activated a level 3 ventilation setting every day when the temperature was between 21 and 24 degrees Celsius. Thus, trigger condition 340 for activating level 3 ventilation as an automatic setting may include detecting a temperature above 21 degrees Celsius and below 24 degrees Celsius. In some embodiments, computing system 130 may adjust the minimum and maximum values (e.g., + / - 5 degrees Celsius) based on the appropriateness for widening (or narrowing) trigger condition 340. In some embodiments, the trigger condition 340 may include a threshold (based on a minimum value) above which the automatic setting 335 may be activated.
[0145] In one embodiment, the trigger condition 340 may be based on being within a particular range of observed conditions 315. For example, as shown in FIG. 4, the observed conditions 315 recorded in the user activity cluster 500C for the seat massage function may indicate that the user 120 activated the "typical" massage setting for each day the temperature was between 24 and 25 degrees Celsius. Thus, the trigger condition 340 for activating the "typical" massage setting as the automatic setting may include detecting that the temperature is within a particular range (e.g., +1 / -5 degrees Celsius) of 24 to 25 degrees Celsius.
[0146] In one embodiment, the trigger condition 340 may be based on the average, mode, or centroid of the observed conditions 315 in the user activity clusters 500A-500C. For example, the observed conditions 315 recorded in the user activity cluster 500B may indicate that the user 120 opened the driver's side window when the vehicle 105 was within "X" meters of a central location (e.g., corresponding to the user's workplace). The central location may be determined based on the average or mode of the latitude and longitude coordinates in the observed conditions 315 of the user activity cluster 500B. In one example, the distance "X" may be defined by the maximum distance from the central location at which the user 120 opened the driver's side window. The trigger condition 340 for automatically opening the driver's side window may include detecting that the vehicle 105 is within "X" distance from the central location.
[0147] The computing system 130 may output an automated vehicle action 330. As described herein, the automated vehicle action 330 may include an automatic setting 335 (e.g., the highest weighted user-selected setting 310) and one or more trigger conditions 340 that indicate circumstances under which the vehicle 105 should automatically activate the automatic setting 335. This may be expressed as a logical relationship, for example, "when (trigger condition occurs), perform (automatic setting) for the associated vehicle function." In one embodiment, the computing system 130 may assign a name to the automated vehicle action 330 that reflects the associated vehicle function (e.g., ventilation), automatic setting (e.g., level 3), trigger condition (e.g., nearby location, time of day, temperature), or other characteristic.
[0148] The computing system 130 may notify the user 120 of the automated vehicle action 330. To do so, the computing system 130 may utilize an action explanation model 355, which may be configured to generate content for presentation to the user 120 via a user interface of a display device. The content may be based on described techniques for generating user-understandable automated vehicle actions 330 (e.g., by developing the content using a hypercube 360). The content may suggest the automated vehicle action 330 to the user and may request the user 120 to approve the automated vehicle action 330 (e.g., via user input to a display device). The content may indicate vehicle functions 165A-165C, automatic settings 335, and one or more trigger conditions 340 associated with the automated vehicle action 330. The display device may include, for example, a touchscreen of an infotainment system installed in the vehicle 105 or a touchscreen of the user device 115 of the user 120.
[0149] 6 , user activity cluster 500A may result in an automated vehicle action 600 for a seat ventilation function. Automated vehicle action 600 may indicate that an automatic setting 605 (e.g., ventilation level 3) for the seat ventilation function is activated if a trigger condition 610 (e.g., location, time, and temperature condition) is detected. Automated vehicle action 600 may be presented as content on a user interface 615 of a display device 620 (e.g., onboard vehicle 105). In one embodiment, the content may be generated as a prompt to user 120. User 120 may interact with user interface 615 (e.g., by providing touch input to a user interface soft button element) to accept automated vehicle action 600, manually adjust trigger condition 610, ignore, disable, or delete automated vehicle action 600, or user 120 may later decide whether to implement automated vehicle action 600.
[0150] In another example, FIG. 7 shows content for presentation to user 120 regarding an automated vehicle action 700. User activity cluster 500B may result in automated vehicle action 700 for a seat massage function. Automated vehicle action 700 may indicate that an automatic setting 705 (e.g., a “typical” massage setting) for the seat massage function is activated if trigger condition 710 (e.g., location, time, and temperature conditions) is detected. Automated vehicle action 700 may be presented as content on a user interface 715 of a display device 720 (e.g., onboard vehicle 105). User 120 may interact with user interface 715 (e.g., via user interface elements) to choose to accept automated vehicle action 700, manually adjust trigger condition 710, ignore, disable, or delete automated vehicle action 700, or user 120 may later determine whether to implement automated vehicle action 700.
[0151] In another example, FIG. 8 shows content for presentation to user 120 regarding automated vehicle action 800. User activity cluster 500C may result in automated vehicle action 800 for a window function. Automated vehicle action 800 may indicate that an automatic setting 805 of the window function (e.g., opening the driver's window) is activated if trigger condition 810 (e.g., location, time, and temperature conditions) is detected. Automated vehicle action 800 may be presented as content on a user interface 815 of a display device 820 (e.g., onboard vehicle 105). User 120 may interact with user interface 815 (e.g., via user interface elements) to choose to accept automated vehicle action 800, manually adjust trigger condition 810, ignore, disable, or delete automated vehicle action 800, or user 120 may later determine whether to implement automated vehicle action 800.
[0152] 3 , in one embodiment, computing system 130 may determine whether a conflict exists between the newly generated automated vehicle action 330 and an existing automated vehicle action. Such conflict resolution may occur before presenting the automated vehicle action 330 to user 120 or before storing the automated vehicle action 330 in database 230 for execution by vehicle 105.
[0153] To perform the conflict avoidance analysis, computing system 130 may utilize conflict analyzer 370. Conflict analyzer 370 may be implemented as a module of computing system 130. Conflict analyzer 370 may be configured to determine whether automated vehicle action 330 conflicts with another existing automated vehicle action (e.g., stored in database 230). A conflict may be determined to exist if vehicle 105 is not capable of performing both automated vehicle actions without modifying one of them.
[0154] Conflict analyzer 370 may determine whether a conflict exists between automated vehicle actions in various ways. In one embodiment, conflict analyzer 370 may determine that a conflict exists when two automated vehicle actions are assigned the same name. Conflict analyzer 370 may be configured to detect name conflicts using string comparison or substring check analysis.
[0155] In one embodiment, the conflict analyzer 370 may determine that a conflict exists between automated vehicle actions based on a domain associated with the automated vehicle action 330 or the context of the controlled vehicle function 165A-165C. The domain of the conflict may be identified by which controller 170A-170C (or ECU) is associated with performing the automated vehicle action 330. The computing system may determine that a conflict exists unless the vehicle action involves the same controller 170A-170C (or ECU) and the controller 170A-170C is capable of implementing both automated settings simultaneously. For example, an environmentally based automated vehicle action cannot simultaneously set the environmental control temperature to maximum heating and maximum cooling.
[0156] In one embodiment, conflict analyzer 370 may determine whether a conflict exists between an automated vehicle action 330 and an action being performed by vehicle 105 due to an explicit user command. For example, user 120 may provide audio input (e.g., a spoken voice command) to vehicle 105 to perform navigation guidance to a place of interest (e.g., a restaurant). A trigger condition 340 of the automated vehicle action 330 may indicate that an automated navigation setting for guidance to the user's workplace is to be executed simultaneously. Thus, conflict analyzer 370 may determine that a conflict exists between the voice-activated navigation and the automated vehicle action 330.
[0157] The computing system 130 may address conflicts based on one or more conflict resolution policies 375. The policies 375 may be programmed to automatically resolve which automated vehicle actions to enable and which to disable. One example policy may include enabling more recently determined automated vehicle actions and disabling other actions. Another example policy may include enabling automated vehicle actions that are more likely to occur frequently (e.g., during the morning commute) and disabling other actions (e.g., activated only during certain seasons). Additionally or alternatively, another example policy may include enabling or disabling automated vehicle actions based on a hierarchy of automated vehicle actions. Additionally or alternatively, another example policy may include prioritizing the setting of vehicle functions according to explicit user commands over automated vehicle actions. Additionally or alternatively, another example policy may include prioritizing automated vehicle actions created on vehicle 105 (e.g., via computing system 130) over automated vehicle actions created outside vehicle 105 (e.g., via computing platform 110).
[0158] Additionally or alternatively, example policies may be configured to help resolve conflicts based on the context of the vehicle 105. For example, policies may be configured to prevent activation of certain features taking into account weather, traffic conditions, noise levels, or other current or future conditions of the vehicle 105. By way of example, an automated vehicle action associated with opening a window (e.g., a sunroof) may not be activated if it is (or is predicted to be) raining, noisy, etc. The prediction of rain, high noise levels, etc. may be determined based on data indicative of future operating conditions of the vehicle 105 (e.g., weather data predicting rain, route data indicating a route through a noisy area). This may help resolve conflicts between automated vehicle actions by prioritizing automated vehicle actions that are more appropriate in light of the vehicle's context.
[0159] In one embodiment, if none of policies 375 automatically resolves the conflict, user 120 may be presented with content on a user interface to manually resolve the conflict. The content may include prompts asking the user which automated vehicle actions should be enabled and which automated vehicle actions should be disabled. Disabled automated vehicle actions may remain disabled until manually adjusted, for example, by user 120.
[0160] The computing system 130 may output command instructions 380 based on the automated vehicle actions 330. The command instructions 380 may be computer-executable instructions for the vehicle 105 to perform the automated vehicle actions 330 to automatically control the vehicle functions 165A-165C according to the automatic settings 335 based on whether the vehicle 105 detects one or more trigger conditions 340.
[0161] In one embodiment, computing system 130 may store command instructions 380 in accessible memory on vehicle 105 for execution at a subsequent time. For example, command instructions 380 may be stored in automated vehicle action database 230 along with command instructions associated with other automated vehicle actions. Database 230 may be updated when new automated vehicle actions are created, when existing automated vehicle actions are modified, disabled, enabled, etc.
[0162] The computing system 130 may execute the command instructions 380 at a subsequent time. For example, at a later time, the computing system 130 may detect the occurrence of one or more trigger conditions 340. The detection may be based on a signal generated by the vehicle function services 205A-205C. The signal may encode data indicative of the trigger condition 340 (e.g., time, temperature, location, weather, traffic, etc.). Based on the trigger condition 340, the computing system 130 (e.g., the vehicle embedded services 225) may send a signal to implement an automatic setting 335 by the vehicle 105. The signal may be sent to a controller 170A-170C configured to activate / adjust the vehicle functions 170A-170C to the automatic setting 335 (e.g., initiate a typical massage program).
[0163] In one embodiment, computing system 130 may generate content (e.g., a notification) indicating that vehicle 105 is performing or has performed automatic configuration 335. The content may be presented to user 120 via a user interface of a display device (e.g., of the vehicle's infotainment system). In one embodiment, user 120 may provide user input to stop, snooze, or delay (e.g., to perform at another time), or cancel or override automated vehicle action 330.
[0164] In one embodiment, the command instructions 380 may be stored in one or more collections for indexing automated vehicle actions, each of which may include a collection of automatic settings 335, trigger conditions 340, etc.
[0165] For example, FIGS. 9A-9B illustrate data structures 900A-900B that include multiple automated vehicle actions. Data structure 900A may be, for example, a table, list, or the like that indexes each automated vehicle action. The automated vehicle actions may be represented as objects that store automatic setting objects and trigger condition objects. The objects may also maintain a set of metadata useful in uniquely identifying the automated vehicle action, such as a serial number, a unique identifier, an assigned name, or the like. In one embodiment, the automated vehicle actions may be stored or indexed according to the type of action (e.g., ClimateControlAction, NavigationRouteAction, etc.). In one embodiment, the automated vehicle actions may be associated with an action affinity that defines the responsibility of a computing system 130 (e.g., vehicle embedded services 225) or computing platform 110 (e.g., cloud embedded services 235) for a particular automated vehicle action.
[0166] Command instructions 380 may be stored in association with user profiles of users 120. For example, data structure 900A may be associated with a first user profile associated with first user 120, and data structure 900B may be associated with a second user profile associated with second user 175 (shown in FIG. 1 ). In this manner, database 230 may indicate which automated vehicle actions are associated with which users.
[0167] In one embodiment, computing system 130 may send a communication over network 125 to computing platform 110 (e.g., a server system) indicating command instructions 380 for storage in association with a user profile of user 120 away from vehicle 105. For example, computing platform 110 may receive the communication and store the command instructions in cloud database 240 associated with the user profile of user 120. When user 120 enters second vehicle 180 (shown in FIG. 1 ), computing platform 110 may provide data to second vehicle 180 indicating command instructions 380 for automated vehicle actions associated with the user profile of user 120. Thus, user 120 can experience the automated vehicle actions determined by first vehicle 105 while in second vehicle 180.
[0168] In one embodiment, computing platform 110 may be configured to aggregate automated vehicle actions across multiple users. For example, computing platform 110 (e.g., cloud embedded service 235) may obtain data indicating multiple automated vehicle actions generated by multiple different vehicles for multiple different users. Such data may be stored, for example, in cloud database 240. Computing platform 110 may analyze the data to generate aggregated clusters including multiple automated vehicle actions from multiple different users. In one example, computing platform 110 may determine the aggregated clusters using similar clustering analysis and machine learning models as described previously herein. The automated vehicle actions within an aggregated cluster may be related in that they are associated with similar vehicle functions, have similar trigger conditions, etc. Additionally or alternatively, users associated with a cluster may have common attributes, such as, for example, being located in the same or similar geographic area, similar weather conditions, etc.
[0169] Computing platform 110 may be configured to suggest automated vehicle actions to the user based on analysis of the aggregate cluster. For example, computing platform 110 may apply a vehicle action model to weight multiple automatic settings in the aggregate cluster based on their respective frequencies in the aggregate cluster. Computing platform 110 may identify the automatic setting with the highest weight and select it as the suggested automatic setting. Using techniques similar to those described herein, computing platform 110 may determine a suggested trigger condition for the suggested automatic setting based on the aggregate cluster (e.g., based on the trigger condition action included therein). Computing platform 110 may generate a suggested vehicle action for user 120 based on the suggested automatic setting and the suggested trigger condition.
[0170] Computing platform 110 may send a communication indicating the proposed vehicle action to vehicle 105 associated with user 120 or user device 115 associated with user 120. Computing system 130 of vehicle 105 may receive the communication and process it for presentation to user 120. In one example, computing system 130 may generate content for presentation to user 120 via a display device onboard vehicle 105. The content may include the proposed vehicle action and prompt user 120 to accept, discard, or ignore the suggestion. If user 120 accepts, computing system 130 may store the proposed vehicle action as an automated vehicle action in action database 230 (e.g., in association with the user profile of user 120).
[0171] In one embodiment, computing system 130 may send a communication to computing platform 110 to indicate the user's approval of the proposed vehicle action. Computing platform 110 may store the proposed vehicle action as an automated vehicle action in cloud database 240 (e.g., in association with the user profile of user 120). Additionally or alternatively, computing platform 110 may use the feedback to help retrain models used to generate aggregate clusters, suggested vehicle actions, etc.
[0172] In one embodiment, user device 115 may additionally or alternatively perform the operations and functions of computing system 130 with respect to the proposed vehicle action.
[0173] 10A-10B show a flow diagram illustrating an example method 1000 for generating an automated vehicle action, according to one embodiment of the present disclosure. Method 1000 may be performed by a computing system described with reference to other figures. In one embodiment, method 1000 may be performed by control circuitry 135 of computing system 130 of FIG. 1. One or more portions of method 1000 may be implemented as an algorithm on hardware components of a device described herein (e.g., as in FIGS. 1-3, 6-8, and 12), for example, to generate an automated vehicle action as described herein. For example, the steps of method 1000 may be implemented as operations / instructions executable by computing hardware.
[0174] 10A-10B depict elements performed in a particular order for purposes of illustration and explanation. Using the disclosure provided herein, those skilled in the art will understand that elements of any of the methods discussed herein may be adapted, rearranged, extended, omitted, combined, or modified in various ways without departing from the scope of the present disclosure. FIGS. 10A-10B are described with reference to elements / terminology described with respect to other systems and figures, for example, for illustrative purposes and are not intended to be limiting. One or more portions of method 1000 may additionally or alternatively be performed by other systems. For example, method 1000 may be performed by control circuitry 185 of computing platform 110.
[0175] In one embodiment, method 1000 may begin with or otherwise include step 1005, in which computing system 130 receives context data 305 associated with multiple user interactions with vehicle function 165B of vehicle 105 over multiple time instances. Context data 305 may include data indicative of multiple user-selected settings 310 for vehicle function 165B and data indicative of one or more observed conditions 315 associated with each user-selected setting 310. For example, user 120 may activate a massage setting for a seat massage function by interacting with a knob, button, etc., every day for a week. Context data 305 may indicate the particular massage setting, as well as the time, temperature, and location conditions when the setting was selected.
[0176] In one embodiment, the method 1000 may include step 1010, in which the computing system 130 selects a machine learning clustering model 320 from among the plurality of machine learning clustering models based on the vehicle feature 165B. As described herein, each machine learning clustering model 320 may be dedicated to a particular vehicle feature 165A-165C of the vehicle 105. The computing system 130 may process the context data 305 to identify the vehicle feature 165A-165C to which it pertains (e.g., identify the vehicle feature service that provided the data by identifying an indicator encoded within the data) and access the machine learning clustering model 320 associated with that vehicle feature. In one example, if the context data 305 indicates user interaction with a seat massage feature, the computing system 130 may access the machine learning clustering model 320 for the seat massage feature.
[0177] In one embodiment, the method 1000 may include step 1015, in which the computing system 130 uses the machine learning clustering model 320 to generate user activity clusters 500B for the vehicle features 165B based on the context data 305. As described herein, the machine learning clustering model 320 may be trained to identify user activity clusters 500B based at least in part on the user-selected settings 310 and at least in part on one or more observed conditions 315 associated with each user-selected setting 310. For example, the machine learning clustering model 320 may generate a user activity cluster 500B that includes particular data points 505 associated with user interactions with a seat massage feature. The machine learning clustering model 320 may group the data points 505 based on similarities or patterns among them. This may include, for example, activation of the seat massage feature within a similar time range, temperature range, location range, etc. As described herein, the machine learning clustering model 320 may apply a probability distribution to the data points 505, which may help determine the probability (e.g., confidence) that the data points 505 belong within the user activity cluster 500B (e.g., for the seat massage function).
[0178] In one embodiment, the method 1000 may include step 1020 in which the computing system 130 determines an automated vehicle action 330 based on the user activity cluster 500B. The automated vehicle action 330 may indicate an automatic setting 335 for a vehicle function 165B (e.g., a vehicle comfort function) and one or more trigger conditions 340 for automatically implementing the automatic setting 335. More specifically, as described herein, the automated vehicle action 330 may be expressed as a dependency (e.g., an if / then statement) between the implementation of the automatic setting 335 and the trigger condition 340.
[0179] In one embodiment, the computing system 130 may determine the automated vehicle action 330 in step 1020 using the vehicle action model 325. The vehicle action model 325 may include, for example, a weighting algorithm that may be applied to the user activity cluster 500B. A particular weighting scheme may be specific to the vehicle function 165B. In one example, the vehicle action model 325 may provide a weighting scheme specific to the seat massage function (e.g., taking into account the number of massage settings). The vehicle action model 325 may assign a weight to each user-selected setting 310 when the user interacts with the seat massage function. In one embodiment, the vehicle action model 325 may identify the user-selected setting 310 with the highest weight (e.g., a typical massage setting) in the user activity cluster 500B as preferred by the user 120. Thus, the computing system 130 may set the highest-weighted user-selected setting 310 as the automatic setting 335 to be implemented in the execution of the automated vehicle action 330.
[0180] Computing system 130 may determine trigger conditions 340 for automatic settings 335 based on user activity clusters 500B in step 1020. As described herein, trigger conditions 340 may be based on observed conditions 315 appearing in user activity clusters 500B. In one example, time, location, and / or temperature conditions for automatically activating a typical massage setting may be based on observed times, locations, and temperatures at which user 120 selected this setting over time.
[0181] In one embodiment, method 1000 may include step 1025, in which computing system 130 determines whether a conflict exists between the automated vehicle action 330 and an existing automated vehicle action. In one embodiment, computing system 130 may compare the trigger conditions 340 of the new automated vehicle action 330 and the existing automated vehicle action to determine whether the actions can be triggered simultaneously. If so, computing system 130 may compare the automatic settings 335 of the newer automated vehicle action 330 with the automatic settings of the existing automated vehicle action to determine whether the settings can be implemented simultaneously. For example, if the associated controller 170B (or ECU) cannot activate the settings during an overlapping period, the settings may not be implemented simultaneously. As an example, controller 170B for a driver's seat massage function may be programmed to activate only one massage setting at a time. Thus, controller 170B may not be able to activate a typical massage setting of a new automated vehicle action and a gentle massage setting of an existing automated vehicle action if these actions can be triggered by the same condition. In this example, computing system 130 may determine that a conflict exists, and method 1000 may return to step 1005. If a conflict does not exist, method 1000 may continue.
[0182] In one embodiment, method 1000 may include step 1030, in which computing system 130 generates content for presentation to user 120 via a user interface of a display device based on automated vehicle actions 330 using action description model 355. The content may indicate vehicle functions 165B, automatic settings 335, and one or more trigger conditions 340. Exemplary content is shown in FIG. 7, in which user interface 715 presents a prompt to user 120 indicating that a typical massage setting for a seat massage function will be activated when certain location, time, and temperature conditions are detected. In one embodiment, user 120 can interact with user interface 715 to edit trigger conditions 710.
[0183] 10B , the method 1000 in one embodiment may include step 1035 in which the computing system 130 receives user input indicating approval of the automated vehicle action 330 by the user 120. As described herein, the user input may include touch input to a user interface element, a voice command, etc.
[0184] In one embodiment, the user 120 may reject the automated vehicle action 330. In the event of a rejection, the method 1000 may return to step 1005.
[0185] In one embodiment, the method 1000 may include step 1040, in which the computing system 130 retrains the machine learning clustering model 320. For example, the computing system 130 may include a feedback training loop in which the machine learning clustering model 320 that generated the associated user activity cluster 500B is trained / retrained based on the user 120 feedback received in step 1035. For example, the machine learning clustering model 320 may be retrained based on whether the user 120 accepted or rejected the automated vehicle action 330. This may include, for example, modifying the hyperparameters of the machine learning clustering model 320 (e.g., based on the feedback).
[0186] Method 1000 in one embodiment may include step 1045, in which computing system 130 outputs command instructions 380 to vehicle 105 to implement automated vehicle actions 330 for automatically controlling vehicle function 165B according to automatic settings 335 based on whether vehicle 105 detects one or more trigger conditions 340. Command instructions 380 may include computer-executable instructions that cause computing system 130 to monitor trigger conditions 340 (e.g., time, location, temperature, etc.) and, if detected, implement automatic settings 335 (e.g., activate a typical massage setting).
[0187] In one embodiment, the method 1000 may include step 1050, in which the computing system 130 stores the command instructions 380 in accessible memory on the vehicle for execution at a subsequent time. For example, the command instructions 380 may be stored in memory (e.g., automated vehicle action database 230) onboard the vehicle 105. The command instructions 380 may be executed later (e.g., to activate the automatic settings 335), for example, when the user 120 approves / enables the automated vehicle action 330, when a trigger condition 340 is detected, etc.
[0188] In one embodiment, method 1000 may include step 1055, in which computing system 130 sends a communication indicating command instructions 380 over a network to a server system for storage in association with a user profile of user 120. As described herein, command instructions 380 may be provided to computing platform 110 (e.g., a cloud-based server system). Computing platform 110 may store command instructions 380 in memory remote from vehicle 105 (e.g., cloud database 240). Command instructions 380 may be stored in association with user profile 245 of user 120 such that the user's automated vehicle actions may be transferred from computing platform 110 to one or more other vehicles, if desired. For example, computing platform 110 may send data indicating automated vehicle actions 330 to another vehicle (different from vehicle 105), such that the other vehicle may perform automated vehicle actions 330, even though the automated vehicle actions 330 were created by another vehicle (e.g., vehicle 105).
[0189] In one embodiment, the method 1000 may include a step 1060 in which the computing system 130 detects the occurrence of one or more trigger conditions 340. For example, the computing system 130 may capture data from sensors 150 (e.g., a thermometer) of the vehicle 105 or other systems / devices (e.g., a clock, a positioning system 155) on the vehicle 105 to determine whether a trigger condition 340 for an automated vehicle action 330 occurs.
[0190] In one embodiment, method 1000 may include step 1065 in which computing system 130 sends a signal to implement automatic configuration 335 for vehicle function 165B based on one or more trigger conditions 340. In one example, if computing system 130 detects the occurrence of a defined set of time, temperature, and location conditions, computing system 130 may automatically send a signal to controller 170B to indicate that the seat massage function is to be set to a typical massage.
[0191] FIG. 11 illustrates a flowchart diagram of an example method 1100 for implementing an automated vehicle action for a second user, according to one embodiment of the present disclosure. Method 1100 may be performed by a computing system described with reference to other figures. In one embodiment, method 1100 may be performed by control circuitry 135 of computing system 130 of FIG. 1. One or more portions of method 1100 may be implemented as an algorithm on hardware components of a device described herein (e.g., as in FIGS. 1-3, 6-8, and 12). For example, steps of method 1100 may be implemented as operations / instructions executable by computing hardware.
[0192] FIG. 11 shows elements performed in a particular order for purposes of illustration and explanation. Using the disclosure provided herein, those skilled in the art will understand that elements of any of the methods discussed herein may be adapted, rearranged, extended, omitted, combined, or modified in various ways without departing from the scope of the present disclosure. FIG. 11 is described with reference to elements / terminology described with respect to other systems and figures, for example, for illustrative purposes and is not intended to be limiting. One or more portions of method 1100 may additionally or alternatively be performed by other systems. For example, method 1100 may be performed by control circuitry 185 of computing platform 110.
[0193] In one embodiment, method 1100 may begin with or otherwise include step 1105, in which computing system 130 receives data indicative of a second user profile for second user 175 of vehicle 105. In one example, second user 175 may enter vehicle 105 to be the driver of vehicle 105, and another user (e.g., first user 120) may not be in vehicle 105 with second user 175. In another example, second user 175 may be in vehicle 105 with another user (e.g., first user 120). In such an example, second user 175 may be the driver or a passenger.
[0194] In one embodiment, computing system 130 may receive data indicative of a second user profile as a result of detecting the presence of second user 175 within vehicle 105. For example, as described herein, computing system 130 may identify the user's key or user device (e.g., through a handshake process), or second user 175 may provide user input (e.g., voice input, touch input) to indicate that second user 175 has entered vehicle 105. In one embodiment, computing platform 110 may receive data indicative of the user's presence within vehicle 105 and respond by transmitting data indicative of automated vehicle actions associated with the second user profile to computing system 130 onboard vehicle 105. The automated vehicle actions associated with the second user profile / second user 175 may have been determined by a different vehicle than vehicle 105 (e.g., one currently being used by second user 175).
[0195] In one embodiment, method 1100 may include step 1110, in which computing system 130 stores command instructions for a second automated vehicle action associated with the second user profile in accessible memory of vehicle 105. For example, computing system 130 may store the command instructions for the second automated vehicle action in automated vehicle action database 230 onboard vehicle 105.
[0196] The command instructions for the second automated vehicle action may be based on at least one user interaction of the second user with a vehicle function of another vehicle (e.g., vehicle 180). For example, second user 175 may interact with a seat massage function of second vehicle 180 over multiple time instances. A computing system (e.g., its control circuitry) of second vehicle 175 may be configured to determine a second automated vehicle action based on second user 175's user interaction with the seat massage function of second vehicle 180 using the techniques and processes described herein. The computing system may output command instructions for the second automated vehicle action and transmit data indicative of the second automated vehicle action (e.g., associated command instructions) to computing platform 110. As described herein, computing platform 110 may store such information in association with a second user profile and transmit it to another vehicle (e.g., vehicle 105).
[0197] In one embodiment, computing system 130 may not store command instructions for automated vehicle actions other than those associated with second user 175. This may occur, for example, if second user 175 is the only user in vehicle 105. Additionally or alternatively, this may occur if second user 175 is the only user detected in vehicle 105. Additionally or alternatively, this may occur if second user 175 is the driver of vehicle 105. Computing system 130 may later execute command instructions to activate automatic configuration of vehicle features 165A-165C for second user 175 when a trigger condition is detected.
[0198] In one embodiment, computing system 130 may be configured to simultaneously store command instructions for automated vehicle actions associated with first user 120 and second user 175. This may occur, for example, when first user 120 and second user 175 are riding in vehicle 105 at the same time. Additionally or alternatively, this may occur when first user 120 and second user 175 are frequent users of vehicle 105.
[0199] In one embodiment, computing system 130 may execute an automated vehicle action for first user 120 and an automated vehicle action for second user 175 during simultaneous / overlapping time periods, such that vehicle 105 executes two automated settings (for two different users) simultaneously. As an example, a first automated vehicle action for first user 120 may indicate that vehicle 105 should set the heated seat function to "low" when the external temperature is below 16 degrees Celsius. A second automated vehicle action for second user 175 may indicate that vehicle 105 should set the heated seat function to "high" when the external temperature is below 15 degrees Celsius.
[0200] In a manner similar to that described herein, computing system 130 may compare the vehicle features, trigger conditions, and automatic settings of the first and second automated vehicle actions to determine whether they conflict with each other. The first automated vehicle action and the second automated vehicle action may be considered to conflict if the vehicle 105 (e.g., the associated vehicle features) cannot simultaneously implement the automatic settings of the two actions. In the above example, the first automated vehicle action and the second automated vehicle action may be implemented simultaneously because the seat of the first user 120 (e.g., sitting in the driver's seat) has a different seat heating feature than the seat of the second user 175 (e.g., sitting in the passenger seat). Thus, if computing system 130 detects an outside temperature of 14 degrees Celsius, computing system 130 may send a first signal to set the seat heating feature of the first user to “low” and a second signal to set the seat heating feature of the second user to “high.” In one embodiment, computing system 130 may generate content to inform first and second users of the activation of the automatic settings (e.g., via a user interface on a display device of the infotainment system).
[0201] If a conflict exists, computing system 130 may attempt to resolve the conflict according to one or more policies 375. In one embodiment, policies 375 may include one or more policies for resolving conflicts between automated vehicle actions of different users who are both within vehicle 105. For example, policy 375 may include a hierarchical structure indicating that automated vehicle actions are given higher priority than other automated vehicle actions, regardless of which user is the driver. In another example, the hierarchical structure may indicate that automated vehicle actions for whichever user first entered vehicle 105 are given higher priority than other automated vehicle actions. In one embodiment, computing system 130 may generate content to inform first user 120 or second user 175 that a particular automated vehicle action has not been performed in light of the conflict.
[0202] In one embodiment, the method 1100 may include step 1115, in which the computing system 130 generates another automated vehicle action for the second user 175 based on context data associated with the second user 175. For example, the computing system 130 may utilize the data pipeline 300 described with reference to FIG. 3 to generate an automated vehicle action for the second user 175 of the vehicle 105. Such a vehicle action may be stored in association with a second user profile of the second user 175. In this manner, a user / user profile may be associated with multiple automated vehicle actions, with at least one automated vehicle action (e.g., a command instruction associated therewith) determined by the first vehicle 105 and at least one automated vehicle action (e.g., a command instruction associated therewith) determined by the second vehicle 175.
[0203] In some embodiments, computing system 130 can utilize data pipeline 300 to simultaneously learn the routines and patterns of first user 120 and second user 175. This can include collecting contextual data, generating user activity clusters, determining automated vehicle actions, issuing command instructions, performing conflict resolution analysis, etc., for first user 120 and second user 175 simultaneously.
[0204] 12 illustrates a block diagram of an exemplary computing system 1200 according to one embodiment of the present disclosure. The system 1200 includes a computing system 1205 (e.g., a computing system onboard a vehicle), a server computing system 1305 (e.g., a remote computing system, a cloud computing platform), and a training computing system 1405 communicatively connected via one or more networks 1255.
[0205] Computing system 1205 may include one or more computing devices 1210 or circuitry. For example, computing system 1205 may include control circuitry 1215 and non-transitory computer-readable medium 1220, also referred to herein as memory. In one embodiment, control circuitry 1215 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or any other control circuitry. In some embodiments, control circuitry 1215 may be part of or form a vehicle control unit (also referred to as a vehicle controller) integrated into or otherwise located in a vehicle (e.g., a Mercedes-Benz® car or van). For example, the vehicle controller may be or may include an infotainment system controller (e.g., an infotainment head unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charge controller, a central external and internal controller (CEIC), a zone controller, or any other controller. In one embodiment, the control circuitry 1215 may be programmed by one or more computer-readable or computer-executable instructions stored on a non-transitory computer-readable medium 1220.
[0206] In one embodiment, the non-transitory computer-readable medium 1220 may be a memory device, also referred to as a data storage device, and may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-transitory computer-readable medium 1220 may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick.
[0207] Non-transitory computer-readable medium 1220 may store information that can be accessed by control circuitry 1215. For example, non-transitory computer-readable medium 1220 (e.g., a memory device) may store data 1225 that can be obtained, received, accessed, written, manipulated, created, and / or stored. Data 1225 may include, for example, any of the data or information described herein. In some embodiments, computing system 1205 may retrieve data from one or more memories that are remote from computing system 1205.
[0208] The non-transitory computer-readable medium 1220 may also store computer-readable instructions 1230 that can be executed by the control circuitry 1215. The instructions 1230 may be software written in any suitable programming language or may be implemented in hardware. The instructions may include computer-readable instructions, computer-executable instructions, etc. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, when the computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a collection of software instructions or code configured to cause the control circuitry 1215 to perform one or more functional tasks. The modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuitry 1215 or other hardware components execute the modules or computer-readable instructions.
[0209] The instructions 1230 may execute in logically and / or virtually separate threads on the control circuitry 1215. For example, the non-transitory computer-readable medium 1220 may store instructions 1230 that, when executed by the control circuitry 1215, cause the control circuitry 1215 to perform any of the operations, methods, and / or processes described herein. In some cases, the non-transitory computer-readable medium 1220 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the method of FIGS. 10A-10B or 11.
[0210] In one embodiment, computing system 1205 may store or include one or more machine learning models 1235. For example, machine learning model 1235 may be or otherwise include various machine learning models, including machine learning clustering model 320. In one embodiment, machine learning model 1235 may include an unsupervised learning model (e.g., for generating data clusters). In one embodiment, machine learning model 1235 may include a neural network (e.g., a deep neural network) or other type of machine learning model, including a nonlinear model and / or a linear model. The neural network may include a feedforward neural network, a recurrent neural network (e.g., a long short-term memory recurrent neural network), a convolutional neural network, or other forms of neural network. Some exemplary machine learning models may utilize attention mechanisms, such as self-attention. For example, some exemplary machine learning models may include a multi-headed self-attention model (e.g., a Transformer model).
[0211] In one aspect of the present disclosure, model 1235 may be used to group various types of input data. For example, machine learning clustering model 320 may be used to classify, recognize, or extract features from input data such as data describing user-selected settings 310 and associated observed conditions 315, data encoding user interactions with vehicle features 165A-165C, or any other suitable type of structured data.
[0212] As described herein, the machine learning clustering model 320 may receive inputs and process each input to generate a respective cluster assignment for each input. The respective cluster assignment for each input may include a respective probability distribution for each embedding for multiple clusters. The respective probability distribution for each input element may describe a respective probability (e.g., confidence) for each element belonging to each of the clusters. In other words, the respective cluster assignment may probabilistically map (e.g., soft-code) each input to multiple clusters. Thus, the cluster assignment may identify similarities between various inputs or input elements, such as similar objects or features in images, similar sounds in audio, and / or correlations between statistical data points.
[0213] In some embodiments, the cluster assignments describing the mapping of embeddings to multiple clusters may describe the centroids of each of the multiple clusters. For example, the clusters may be mathematically defined based on their respective centroids in a multidimensional space. In other implementations, the cluster assignments describing the mapping of embeddings to multiple clusters do not refer to or require the calculation of cluster centroids.
[0214] In one embodiment, one or more machine learning models 1235 may be received from server computing system 1305 over network 1255, stored on computing system 1205 (e.g., non-transitory computer-readable medium 1220), and then used or otherwise implemented by control circuitry 1215. In one embodiment, computing system 1205 may implement multiple parallel instances of a single model.
[0215] Additionally or alternatively, one or more machine learning models 1235 may be included in or otherwise stored and implemented by a server computing system 1305 that communicates with computing system 1205 according to a client-server relationship. For example, machine learning models 1235 may be implemented by server computing system 1305 as part of a web service. Thus, one or more models 1235 may be stored and implemented in computing system 1205 and / or one or more models 1235 may be stored and implemented in server computing system 1305.
[0216] Computing system 1205 may include one or more communications interfaces 1240. Communications interface 1240 may be used to communicate with one or more other systems. Communications interface 1240 may include any circuits, components, software, etc. for communicating over one or more networks (e.g., network 1255). In some embodiments, communications interface 1240 may include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.
[0217] The computing system 1205 may also include one or more user input components 1245 that receive user input. For example, the user input component 1245 may be a touch-sensitive component (e.g., a touch-sensitive display screen or touchpad) that responds to the touch of a user input object (e.g., a finger or stylus). The touch-sensitive component may function to implement a virtual keyboard. Other exemplary user input components include a microphone, a traditional keyboard, a cursor device, a joystick, or other device through which a user may provide user input.
[0218] Computing system 1205 may include one or more output components 1250. Output component 1250 may include hardware and / or software for generating content audibly or visually. For example, output component 1250 may include one or more speakers, earphones, a headset, a handset, etc. Output component 1250 may include a display device, which may include hardware for displaying a user interface and / or messages for a user. By way of example, output component 1250 may include a display screen, CRT, LCD, plasma screen, touch screen, TV, projector, tablet, and / or other suitable display component.
[0219] Server computing system 1305 may include one or more computing devices 1310. In one embodiment, server computing system 1305 may include or be otherwise implemented by one or more server computing devices. When server computing system 1305 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or some combination thereof.
[0220] The server computing system 1305 may include control circuitry 1315 and non-transitory computer-readable media 1320, also referred to herein as memory 1320. In one embodiment, the control circuitry 1315 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or any other control circuitry. In one embodiment, the control circuitry 1315 may be programmed by one or more computer-readable or computer-executable instructions stored on the non-transitory computer-readable media 1320.
[0221] In one embodiment, the non-transitory computer-readable medium 1320 may be a memory device, also referred to as a data storage device, and may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-transitory computer-readable medium may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick.
[0222] The non-transitory computer-readable medium 1320 may store information that can be accessed by the control circuitry 1315. For example, the non-transitory computer-readable medium 1320 (e.g., a memory device) may store data 1325 that can be obtained, received, accessed, written, manipulated, created, and / or stored. The data 1325 may include, for example, any of the data or information described herein. In some embodiments, the server system 1305 may retrieve data from one or more memories that are remote from the server system 1305.
[0223] The non-transitory computer-readable medium 1320 may also store computer-readable instructions 1330 that can be executed by the control circuitry 1315. The instructions 1330 may be software written in any suitable programming language or may be implemented in hardware. The instructions may include computer-readable instructions, computer-executable instructions, etc. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, when the computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a collection of software instructions or code configured to cause the control circuitry 1315 to perform one or more functional tasks. The modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuitry 1315 or other hardware components execute the modules or computer-readable instructions.
[0224] The instructions 1330 may execute in logically and / or virtually separate threads on the control circuitry 1315. For example, the non-transitory computer-readable medium 1320 may store instructions 1330 that, when executed by the control circuitry 1315, cause the control circuitry 1315 to perform any of the operations, methods, and / or processes described herein. In some cases, the non-transitory computer-readable medium 1320 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the method of Figures 10A-10B or 11.
[0225] The server computing system 1305 may store or otherwise include one or more machine learning models 1335, including multiple machine learning clustering models 320. The machine learning models 1335 may include or be the same as the models 1235 stored in the computing system 1205. In one embodiment, the machine learning models 1335 may include unsupervised learning models (e.g., for generating data clusters). In one embodiment, the machine learning models 1335 may include neural networks (e.g., deep neural networks) or other types of machine learning models, including nonlinear and / or linear models. The neural networks may include feedforward neural networks, recurrent neural networks (e.g., long short-term memory recurrent neural networks), convolutional neural networks, or other forms of neural networks. Some exemplary machine learning models may utilize attention mechanisms, such as self-attention. For example, some exemplary machine learning models may include multi-headed self-attention models (e.g., Transformer models).
[0226] The machine learning models described herein may have various types and / or combinations of input data representing data available to sensors and / or other systems onboard the vehicle. The input data may include, for example, latent coding data (e.g., latent space representations of inputs), statistical data (e.g., data calculated and / or derived from some other data source), sensor data (e.g., raw and / or processed data captured by sensors on the vehicle), or other types of data.
[0227] Server computing system 1305 may include one or more communications interfaces 1340. Communications interface 1340 may be used to communicate with one or more other systems. Communications interface 1340 may include any circuitry, components, software, etc. for communicating over one or more networks (e.g., network 1255). In some embodiments, communications interface 1340 may include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.
[0228] The computing system 1205 and / or the server computing system 1305 may train the models 1235, 1335 through interaction with a training computing system 1405 that is communicatively coupled via a network 1255. The training computing system 1405 may be separate from the server computing system 1305 or may be part of the server computing system 1305.
[0229] The training computing system 1405 may include one or more computing devices 1410. In one embodiment, the training computing system 1405 may include or be otherwise implemented by one or more server computing devices. When the training computing system 1405 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or some combination thereof.
[0230] The training computing system 1405 may include control circuitry 1415 and non-transitory computer-readable media 1420, also referred to herein as memory 1420. In one embodiment, the control circuitry 1415 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuits (PLCs) or programmable logic / gate arrays (PLAs / PGAs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or any other control circuitry. In one embodiment, the control circuitry 1415 may be programmed by one or more computer-readable or computer-executable instructions stored on the non-transitory computer-readable media 1420.
[0231] In one embodiment, the non-transitory computer-readable medium 1420 may be a memory device, also referred to as a data storage device, and may include an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. The non-transitory computer-readable medium may form, for example, a hard disk drive (HDD), a solid-state drive (SDD) or solid-state integrated memory, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a dynamic random access memory (DRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick.
[0232] The non-transitory computer-readable medium 1420 may store information that can be accessed by the control circuitry 1415. For example, the non-transitory computer-readable medium 1420 (e.g., a memory device) may store data 1425 that can be obtained, received, accessed, written, manipulated, created, and / or stored. The data 1425 may include, for example, any of the data or information described herein. In some embodiments, the training computing system 1405 may obtain data from one or more memories that are remote from the training computing system 1405.
[0233] The non-transitory computer-readable medium 1420 may also store computer-readable instructions 1430 that can be executed by the control circuitry 1415. The instructions 1430 may be software written in any suitable programming language or may be implemented in hardware. The instructions may include computer-readable instructions, computer-executable instructions, etc. As described herein, in various embodiments, the terms “computer-readable instructions” and “computer-executable instructions” are used to describe software instructions or computer code configured to perform various tasks and operations. In various embodiments, when the computer-readable or computer-executable instructions form a module, the term “module” broadly refers to a collection of software instructions or code configured to cause the control circuitry 1415 to perform one or more functional tasks. The modules and computer-readable / executable instructions may be described as performing various operations or tasks when the control circuitry 1415 or other hardware components execute the modules or computer-readable instructions.
[0234] The instructions 1430 may execute in logically or virtually separate threads on the control circuitry 1415. For example, the non-transitory computer-readable medium 1420 may store instructions 1430 that, when executed by the control circuitry 1415, cause the control circuitry 1415 to perform any of the operations, methods, and / or processes described herein. In some cases, the non-transitory computer-readable medium 1420 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the method of FIGS. 10A-10B or 11.
[0235] The training computing system 1405 may include a model trainer 1435 that trains the machine learning models 1235, 1335 stored on the computing system 1205 and / or the server computing system 1305 using various training or learning techniques. For example, the models 1235, 1335 (e.g., machine learning clustering models) may be trained using a clustering loss function. The clustering loss function may be configured to balance two competing objectives. First, the clustering loss function may be configured to attempt to generate reliable assignments of input data elements to clusters. The clustering loss function may balance this first objective with a second objective of preventing a trivial solution in which all elements of the input data map to a single cluster. Thus, the clustering loss function may promote confident assignment of each input to one of the clusters, but may also promote mapping of input data points across multiple clusters.
[0236] The model trainer may train the model 1235, 1335 (e.g., a machine learning clustering model) in an unsupervised manner. Thus, the model may be effectively trained using unlabeled data for a particular application or problem domain (e.g., generating user activity clusters), which improves the model's performance and adaptability. Furthermore, the model 1235, 1335 may facilitate the discovery of natural partitions or clusters within the data without requiring pre-existing embeddings to seed the clustering objective. As a result, such models may be more effectively trained to cluster complex data with less manual human intervention (e.g., labeling, selecting pre-existing embeddings, etc.).
[0237] More specifically, the clustering loss function may evaluate the achievement of a first objective (promoting reliable mapping) by evaluating a first average of a respective first entropy of each respective probability distribution across multiple inputs (e.g., "average entropy per example"). The clustering loss function may evaluate the achievement of a second objective (promoting diversity in cluster assignments) by evaluating a second entropy of a second average of the probability distributions for the multiple inputs (e.g., "batch average distribution entropy"). Thus, the clustering loss function may be used to train the model 1235, 1335 to generate non-trivial and reliable clustering assignments in an unsupervised manner.
[0238] The training computing system 1405 may modify parameters of the model 1235, 1335 (e.g., the machine learning clustering model 320) based on a loss function (e.g., a clustering loss function) so that the model 1235, 1335 can be effectively trained for a particular application in an unsupervised manner without labeled data. This may be particularly useful for effectively training a model for clustering complex unlabeled data sets.
[0239] In one example, the model trainer 1435 may backpropagate the clustering loss function through the machine learning clustering model 320 to modify the parameters (e.g., weights) of the clustering model. The model trainer 1435 may continue to backpropagate the clustering loss function through the machine learning clustering model 320 with or without modifying the parameters (e.g., weights) of the model. For example, the model trainer 1435 may perform a gradient descent method in which the parameters of the machine learning clustering model 320 may be modified in the direction of the negative gradient of the clustering loss function. Thus, in one embodiment, the model trainer 1435 may modify the parameters of the machine learning clustering model 320 based on the clustering loss function without modifying the parameters of the embedding model.
[0240] In one embodiment, one or more components of the clustering loss function may be scaled by a respective hyperparameter. For example, the second entropy may be scaled by a diversity hyperparameter. The diversity hyperparameter may be used to adjust the relative influence of the terms in the clustering loss function that respectively promote two objectives. Thus, the diversity hyperparameter may be used to adjust or tune the loss provided by the clustering loss function and the resulting behavior of the machine learning clustering model 320 trained based on the clustering loss function. The diversity hyperparameter may be selected to produce a desired balance between the first objective of minimizing the average entropy of the input data points and the second objective of preventing the mappings produced by the machine learning clustering model 320 from collapsing into a trivial solution in which all inputs are mapped to a single cluster.
[0241] In other implementations, one or more components of the clustering loss function may be scaled by learned diversity weights or parameters. For example, an iterative training and evaluation step may be used to optimize a diversity hyperparameter that controls the balance between the first and second objectives described above. Thus, diversity weights may be learned to further improve the training of the machine learning clustering model 320.
[0242] The model trainer 1435 may utilize training techniques such as backpropagation of errors. For example, a loss function may be backpropagated through the model (e.g., based on the gradient of the loss function) to update one or more parameters of the model. Various loss functions may be used, such as mean squared error, likelihood loss, cross-entropy loss, hinge loss, and / or various other loss functions. Gradient descent may be used to iteratively update the parameters over several training iterations.
[0243] In one embodiment, performing backpropagation of errors may include performing truncated backpropagation in time. The model trainer 1435 may implement several generalization techniques (e.g., weight decay, dropout, etc.) to improve the generalization ability of the model being trained. In particular, the model trainer 1435 may train the machine learning models 1235, 1335 based on the set of training data 1440.
[0244] The training data 1440 may include unlabeled training data for training in an unsupervised manner. In one example, the training data 1440 may include unlabeled sets of data representing training user-selected settings and training observed conditions for a particular vehicle function. The training data 1440 may be specific to a particular vehicle function to help focus the models 1235, 1335 on the particular vehicle function.
[0245] In one embodiment, if the user provides consent / permission, the training examples may be provided by a computing system 1205 (e.g., in the user's vehicle). Thus, in such an embodiment, the model 1235 provided to the computing system 1205 may be trained by the training computing system 1405 to personalize the model 1235.
[0246] Model trainer 1435 may include computer logic utilized to provide desired functionality. Model trainer 1435 may be implemented in hardware, firmware, and / or software controlling a general-purpose processor. For example, in one embodiment, model trainer 1435 may include a program file stored on a storage device, loaded into memory, and executed by one or more processors. In other embodiments, model trainer 1435 may include one or more sets of computer-executable instructions stored on a tangible computer-readable storage medium, such as RAM, a hard disk, or optical or magnetic media.
[0247] Training computing system 1405 may include one or more communications interfaces 1445. Communications interface 1445 may be used to communicate with one or more other systems. Communications interface 1445 may include any circuitry, components, software, etc. for communicating over one or more networks (e.g., network 1255). In some embodiments, communications interface 1445 may include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.
[0248] The one or more networks 1255 may be any type of communications network, such as a local area network (e.g., an intranet), a wide area network (e.g., the Internet), or some combination thereof, and may include any number of wired or wireless links. In general, communications over the network(s) 1255 may be carried over any type of wired and / or wireless connection using a wide variety of communications protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encodings or formats (e.g., HTML, XML), and / or security schemes (e.g., VPN, Secure HTTP, SSL).
[0249] 15 illustrates one exemplary computing system that may be used to implement the present disclosure. Other computing systems may be used as well. For example, in one embodiment, the computing system 1205 may include a model trainer 1435 and a training dataset 1440. In such an embodiment, the models 1235, 1335 may be trained and used locally on the computing system 1205. In some such embodiments, the computing system 1205 may implement the model trainer 1435 to personalize the models 1235, 1335.
[0250] Additional Considerations of Various Embodiments Embodiment 1 relates to a computing system. The computing system may include a control circuit. The control circuit may be configured to receive context data associated with multiple user interactions with a vehicle function of a vehicle over multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with the respective user-selected settings. The control circuit may be configured to generate user activity clusters for the vehicle function based on the context data using a machine learning clustering model. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings. The control circuit may be configured to determine an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The control circuit may output command instructions for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0251] Example 2 includes the computing system of Example 1. In this embodiment, the machine learning clustering model can be an unsupervised learning model configured to process the context data using probabilistic clustering to generate user activity clusters.
[0252] Example 3 includes the computing system of either example 1 or example 2. In this example, the machine learning clustering model can be configured to determine boundaries of user activity clusters for vehicle functions based on one or more observed conditions.
[0253] Example 4 includes the computing system of any of Examples 1 to 3. In this example, to determine an automated vehicle action, the control circuitry may process the user activity clusters using a vehicle action model, the vehicle action model being a rule-based model configured to apply a respective weight to each respective user-selected setting in the user activity cluster. The control circuitry may be configured to determine an automated setting of the vehicle function based on the weight of each user-selected setting in the user activity cluster.
[0254]
[0023] Example 5 includes the computing system of any of Examples 1 to 4. In this example, to receive the context data, the control circuitry may be further configured to receive, via a plurality of sensors or systems of the vehicle, data indicative of one or more observed conditions. The observed conditions may include at least one of: (i) a date and / or time at which each user interaction with the vehicle feature occurred; (ii) a location at which each user interaction with the vehicle feature occurred; (iii) a route along which each user interaction with the vehicle feature occurred; or (iv) a temperature at which each user interaction with the vehicle feature occurred.
[0255] Example 6 includes the computing system of any of Examples 1 to 5. In this embodiment, the control circuitry is further configured to generate content for presentation to a user via a user interface of a display device based on the automated vehicle action using the action description model, wherein the content indicates vehicle functions, automatic settings, and one or more trigger conditions.
[0256] Example 7 includes the computing system of any of Examples 1 to 6. In this example, the content may include a request for a user to approve the automated vehicle action.
[0257] Example 8 includes the computing system of any of Examples 1 to 7. In this example, the control circuitry may be further configured to store the command instructions in an accessible memory on the vehicle for execution at a subsequent time.
[0258] Example 9 includes the computing system of any of Examples 1 to 8. In this embodiment, the control circuitry may be further configured to detect occurrence of one or more trigger conditions and, based on the one or more trigger conditions, send a signal to perform automatic configuration of the vehicle function.
[0259] Example 10 includes the computing system of any of Examples 1 to 9. In this example, the control circuitry may be further configured to determine whether a conflict exists between the automated vehicle action and an existing automated vehicle action.
[0260] Example 11 includes the computing system of any of Examples 1 to 10. In this embodiment, the control circuitry can be further configured to send a communication over a network to a server system indicating command instructions for storing in association with a user profile of the user.
[0261] Embodiment 12 includes the computing system of any of embodiments 1 to 11. In this embodiment, the plurality of user interactions may be associated with a first user. The command instructions for the automated vehicle action may be associated with a first user profile of the first user. The control circuitry may be further configured to receive data indicating a second user profile of a second user of the vehicle and store, in an accessible memory of the vehicle, command instructions for a second automated vehicle action associated with the second user profile. The command instructions for the second automated vehicle action may be based on at least one user interaction of the second user with a vehicle function of another vehicle.
[0262] Example 13 includes the computing system of any of Examples 1 to 12. In this embodiment, the vehicle may include a plurality of vehicle functions and a plurality of machine learning clustering models. The control circuitry may be further configured to select a machine learning clustering model from the plurality of machine learning clustering models based on the vehicle function.
[0263] Example 14 includes the computing system of any of Examples 1 to 13. In this example, the vehicle function may include (i) a window function, (ii) a seat function, or (iii) a temperature function.
[0264] Embodiment 15 includes the computing system of any of embodiments 1 to 14. In this embodiment, the seat function may include a seat temperature function, a seat ventilation function, or a seat massage function.
[0265] Example 16 includes the computing system of any of Examples 1 to 15. In this example, the plurality of user-selected settings of the vehicle function may each include at least one of: (i) an on / off selection, (ii) an open / close selection, (iii) a temperature selection, or (iv) a massage level selection.
[0266] Embodiment 17 includes a computer-implemented method. The computer-implemented method may include receiving context data associated with multiple user interactions with a vehicle function of a vehicle across multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with the respective user-selected settings. The computer-implemented method may include generating user activity clusters for the vehicle function based on the context data using a machine learning clustering model. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings. The computer-implemented method may include determining an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The computer-implemented method may include outputting command instructions for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0267] Example 18 includes the computer-implemented method of Example 17. In this example, the machine learning clustering model may include an unsupervised learning model configured to process the context data using probabilistic clustering to generate user activity clusters, and boundaries of the user activity clusters for the vehicle functions may be based on one or more observed conditions.
[0268] Example 19 includes the computer-implemented method of either Example 17 or Example 18. In this embodiment, the computer-implemented method may further include generating content for presentation to a user via a user interface of a display device based on the automated vehicle action using the action explanation model. The content may indicate vehicle functions, automatic settings, and one or more trigger conditions.
[0269] Embodiment 20 relates to one or more non-transitory computer-readable media storing instructions executable by a control circuit to perform an operation. The control circuit may receive context data associated with multiple user interactions with a vehicle function of a vehicle across multiple time instances. The context data may include data indicating multiple user-selected settings for the vehicle function and data indicating one or more observed conditions associated with the respective user-selected settings. The control circuit may use a machine learning clustering model to generate user activity clusters for the vehicle function based on the context data. The machine learning clustering model may be configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings. The control circuit may determine an automated vehicle action based on the user activity clusters. The automated vehicle action may indicate an automatic setting of the vehicle function and one or more trigger conditions for automatically implementing the automatic setting. The control circuit may output command instructions for the vehicle to implement the automated vehicle action to automatically control the vehicle function according to the automatic setting based on whether the vehicle detects the one or more trigger conditions.
[0270] Additional Disclosures As used herein, adjectives and their possessive forms are intended to be used interchangeably unless otherwise clear from the context and / or explicitly stated. For example, "vehicle component" may be used interchangeably with "vehicle component" where appropriate. Similarly, words, phrases, and other disclosures herein are intended to encompass obvious variations and synonyms, even if such variations and synonyms are not explicitly recited.
[0271] The technology described herein refers to servers, databases, software applications, and other computer-based systems, as well as actions taken on and information transmitted to and from such systems. The inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions among components. For example, the processes described herein may be performed using a single device or component, or multiple devices or components operating in combination. Databases and applications may be implemented on a single system or distributed across multiple systems. Distributed components may operate sequentially or in parallel.
[0272] While the present subject matter has been described in detail with reference to various specific exemplary embodiments thereof, each example is provided by way of explanation, not limitation, of the present disclosure. Those skilled in the art, once they achieve the foregoing understanding, will be able to readily produce modifications, variations, and equivalents of such embodiments. Accordingly, the present disclosure does not exclude the inclusion of such modifications, variations, and / or additions to the present subject matter as would be readily apparent to one skilled in the art. For example, features illustrated or described as part of one embodiment may be used with another embodiment to yield yet a further embodiment. Accordingly, the present disclosure is intended to encompass such modifications, variations, and equivalents.
[0273] Aspects of the present disclosure have been described with respect to exemplary embodiments thereof. Numerous other implementations, modifications, or variations within the scope and spirit of the appended claims will occur to those skilled in the art from a consideration of this disclosure. Any and all features in the following claims may be combined or rearranged in any possible manner. Accordingly, the scope of the present disclosure is exemplary rather than limiting, and the present disclosure does not exclude the inclusion of such modifications, variations, or additions to the subject matter as would be readily apparent to one of ordinary skill in the art. Furthermore, terms are described herein using lists of exemplary elements joined by conjunctions such as "and," "or," and "but." It should be understood that such conjunctions are provided for descriptive purposes only. The terms "or" and "and / or" may be used interchangeably herein. For example, a list joined by a particular conjunction such as "or" can refer to "at least one" or "any combination" of the exemplary elements listed therein, and "or" should be understood as "and / or" unless otherwise indicated. Additionally, terms such as "based on" should be understood as "based at least in part on."
[0274] Those skilled in the art will understand, using the disclosure provided herein, that elements of any of the claims, operations, or processes discussed herein may be adapted, rearranged, extended, omitted, combined, or modified in various ways without departing from the scope of the present disclosure. At times, elements may be listed in the specification or claims using letter references for illustrative purposes and are not meant to be limiting. Letter references, when used, do not imply a particular order of operations or a particular importance of the listed elements. For example, letter identifiers such as (a), (b), (c), ..., (i), (ii), (iii), ... may be used to indicate operations or different elements within a list. Such identifiers are provided for the convenience of the reader and do not imply a particular order, importance, or priority of steps, operations, or elements. For example, an operation indicated by a list identifier such as (a), (i), etc. may be performed before, after, or in parallel with another operation indicated by a list identifier such as (b), (ii), etc.
Claims
1. 1. A computing system comprising: a control circuit, the control circuit comprising: receiving context data associated with a plurality of user interactions with a vehicle function of a vehicle across a plurality of time instances, the context data including data indicative of a plurality of user-selected settings for the vehicle function and data indicative of one or more observed conditions associated with the respective user-selected settings; generating user activity clusters for the vehicle functions based on the context data using a machine learning clustering model, the machine learning clustering model configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings; determining an automated vehicle action based on the user activity cluster, the automated vehicle action indicating an automatic configuration of the vehicle function and one or more trigger conditions for automatically performing the automatic configuration; and outputting command instructions for the vehicle to perform the automated vehicle action to automatically control the vehicle function in accordance with the automatic setting based on whether the vehicle detects the one or more trigger conditions.
2. 10. The computing system of claim 1, wherein the machine learning clustering model is an unsupervised learning model configured to process the contextual data using probabilistic clustering to generate the user activity clusters.
3. 2. The computing system of claim 1, wherein the machine learning clustering model is configured to determine the boundaries of the user activity clusters for the vehicle functions based on the one or more observed conditions.
4. To determine the automated vehicle action, the control circuitry: processing the user activity clusters using a vehicle action model, the vehicle action model being a rule-based model configured to apply a respective weight to each of the respective user-selected settings in the user activity clusters; The computing system of claim 1 , configured to determine the automatic setting of the vehicle feature based on the weight of the respective user-selected setting in the user activity cluster.
5. To receive the context data, the control circuitry:
10. The computing system of claim 1, further configured to receive, via a plurality of sensors or systems of the vehicle, data indicative of the one or more observed conditions, the observed conditions including at least one of: (i) the date and / or time when the respective user interaction with the vehicle function occurred; (ii) the location when the respective user interaction with the vehicle function occurred; (iii) the route along which the respective user interaction with the vehicle function occurred; or (iv) the temperature when the respective user interaction with the vehicle function occurred.
6. The control circuit and further configured to generate content for presentation to a user via a user interface of a display device using an action description model based on the automated vehicle actions; The computing system of claim 1 , wherein the content indicates the vehicle functions, the automatic settings, and the one or more trigger conditions.
7. The computing system of claim 6 , wherein the content includes a request for the user to approve the automated vehicle action.
8. The computing system of claim 1 , wherein the control circuitry is further configured to store the command instructions in accessible memory on the vehicle for execution at a subsequent time.
9. The control circuit detecting an occurrence of the one or more trigger conditions; The computing system of claim 1 , further configured to: send a signal to implement the automatic configuration of the vehicle feature based on the one or more trigger conditions.
10. The control circuit The computing system of claim 1 , further configured to determine whether a conflict exists between the automated vehicle action and an existing automated vehicle action.
11. The control circuit 10. The computing system of claim 1, further configured to send a communication over a network to a server system indicating the command instructions for storing in association with a user profile of a user.
12. The plurality of user interactions are associated with a first user, and the command instructions for the automated vehicle actions are associated with a first user profile of the first user, and the control circuitry is configured to: receiving data indicative of a second user profile for a second user of the vehicle; and further configured to store in the vehicle accessible memory command instructions for a second automated vehicle action associated with the second user profile; 10. The computing system of claim 1, wherein the command instructions for the second automated vehicle action are based on at least one user interaction of the second user with a vehicle function of another vehicle.
13. The vehicle includes a plurality of vehicle functions and a plurality of machine learning clustering models, and the control circuitry The computing system of claim 1 , further configured to select the machine learning clustering model from among the plurality of machine learning clustering models based on the vehicle function.
14. The computing system of claim 1 , wherein the vehicle features include (i) a window feature, (ii) a seat feature, or (iii) a temperature feature.
15. The computing system of claim 14 , wherein the seat function includes a seat temperature function, a seat ventilation function, or a seat massage function.
16. 2. The computing system of claim 1, wherein the plurality of user-selected settings of the vehicle function each include at least one of: (i) an on / off selection; (ii) an open / close selection; (iii) a temperature selection; or (iv) a massage level selection.
17. 1. A computer-implemented method comprising: receiving context data associated with a plurality of user interactions with a vehicle function of a vehicle across a plurality of time instances, the context data including data indicative of a plurality of user-selected settings for the vehicle function and data indicative of one or more observed conditions associated with the respective user-selected settings; generating user activity clusters for the vehicle functions based on the context data using a machine learning clustering model, the machine learning clustering model configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings; determining an automated vehicle action based on the user activity cluster, the automated vehicle action indicating an automatic configuration of the vehicle function and one or more trigger conditions for automatically performing the automatic configuration; outputting command instructions for the vehicle to perform the automated vehicle action to automatically control the vehicle function in accordance with the automatic configuration based on whether the vehicle detects the one or more trigger conditions. Computer-implemented method.
18. 20. The computer-implemented method of claim 17, wherein the machine learning clustering model is an unsupervised learning model configured to process the context data using probabilistic clustering to generate the user activity clusters, and the boundaries of the user activity clusters for the vehicle functions are based on the one or more observed conditions.
19. generating content for presentation to a user via a user interface of a display device using an action description model based on the automated vehicle actions; The computer-implemented method of claim 17 , wherein the content indicates the vehicle functions, the automatic settings, and the one or more trigger conditions.
20. One or more non-transitory computer-readable media storing instructions, the instructions being configured by control circuitry to: receiving context data associated with a plurality of user interactions with a vehicle function of a vehicle across a plurality of time instances, the context data including data indicative of a plurality of user-selected settings for the vehicle function and data indicative of one or more observed conditions associated with the respective user-selected settings; generating user activity clusters for the vehicle functions based on the context data using a machine learning clustering model, the machine learning clustering model configured to identify the user activity clusters based at least in part on the user-selected settings and at least in part on the one or more observed conditions associated with the respective user-selected settings; determining an automated vehicle action based on the user activity cluster, the automated vehicle action indicating an automatic configuration of the vehicle function and one or more trigger conditions for automatically performing the automatic configuration; and outputting command instructions for the vehicle to perform the automated vehicle action to automatically control the vehicle function according to an automatic setting based on whether the vehicle detects the one or more trigger conditions.
Citation Information
Patent Citations
Device and method for controlling in-vehicle apparatus
JP2010070171A
Vehicle setting inheritance system
JP2020158003A
Vehicle seat and seat control device
JP2022020529A
Crowd-sourced vehicle setting recommendations
US20170305437A1