SYSTEMS AND METHODS FOR USING A MOBILE DEVICE TO MANAGE AN OVER-THE-AIR VEHICLE SOFTWARE UPDATE

In some embodiments, techniques for initiating over-the-air software updates for a vehicle using a mobile computing device are provided. In some embodiments, the vehicle and the mobile computing device each communicate with a server computing system, but do not communicate directly with each other for software update functionality. The vehicle transmits messages indicating one or more vehicle state conditions to the server computing system. The mobile computing device receives messages indicating one or more vehicle state conditions from the server computing system, and presents an interface for initiating the software update in response to determining that the vehicle state conditions indicate that the vehicle is ready for a software update. The mobile computing device transmits a command to the server computing system to cause the software update to be initiated on the vehicle, and the server computing system transmits the command to the vehicle.

BACKGROUND

Modern-day vehicles include increasing amounts of software. Software is often essential to the proper functioning of the vehicle. In many cases, software is updated from time to time in order to ensure that the vehicle is operating correctly, and/or to reconfigure vehicle functionality that is only changeable by updating the software. This is true in many types of vehicles, including but not limited to Class 8 trucks, other classes of trucks, farm equipment, buses, and passenger cars.

Electronic control units (ECUs) and other devices associated with the vehicles may store or access updatable software, which may include computer-executable instructions, settings data, torque maps, or other software. ECUs are embedded devices that control electronic systems or subsystems in vehicles. ECUs provide many types of functionality for vehicle operation, including but not limited to engine control, auxiliary equipment control, presentation of information via an instrument panel, and infotainment services. ECUs can be implemented in a variety of hardware configurations. A typical ECU includes a processor (e.g., a microcontroller), memory, input/output lines, and one or more communication links. The memory may include an electronically erasable, programmable, read-only memory (“EEPROM”) or other non-volatile memory (e.g., flash memory) and/or random access memory (“RAM”) for storing program instructions that are accessible by the processor.

Typically, vehicle software stored on the ECU is updated by coupling a specialized device (sometimes referred to as a flash tool or service tool) to a physical communication port of the vehicle, such as an OBD-II port. Once coupled to the physical communication port, the specialized device transmits the software update to the device to be updated via a vehicle network such as a CAN BUS or another type of network, and the device is updated. In order to apply the software update using this approach, the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device. Dealerships and service centers where such updates can be installed may not always be closely available to the vehicle, and application of the updates may take an inconvenient amount of time. For example, during a trip, a vehicle requiring such a software update may need to change its route, resulting in a change in itinerary and a possible delay in the installation of critical updates.

To address these limitations, over-the-air updates have been introduced in which vehicle software on the ECU can be updated wirelessly, without physically connecting the vehicle to a specialized device. In some embodiments, over-the-air updates can be delivered to the vehicle from an update server via a wireless network. The wireless network may be a private wireless network such as a protected Wi-Fi network, or could be a public network such as a 3G network, a 4G network, an LTE network, or any other wireless network, including the Internet. Such embodiments address many of the drawbacks of using a specialized device to update the vehicle software, because the vehicle can be updated at any location in which the vehicle can wirelessly access a network through which it can reach the update server.

Though over-the-air updates do address some of the problems with using a specialized device to provide vehicle software updates, technical problems exist in implementing such systems. For example, using a public network to deliver and/or otherwise manage software updates to a vehicle opens a vector of attack through which an unauthorized actor could attempt to install unapproved, malicious, or otherwise unwanted software updates. As such, ensuring the security of the software update process is a significant technical problem. As another example, allowing software updates to occur outside of a dealership or service center means that the person initiating the software update may not be fully trained or experienced in applying software updates the way a technician in a dealership or service center is. This introduces an additional technical problem, in that the safety and reliability of applying an over-the-air software update is reduced compared to previous techniques that were only performed by skilled technicians.

SUMMARY

In some embodiments, an over-the-air updater device for installation in a vehicle is provided. The over-the-air updater device comprises one or more processors, one or more remote network interfaces, one or more vehicle network interfaces, and a non-transitory computer-readable medium having computer-executable instructions stored thereon. The instructions, in response to execution by the one or more processors, cause the over-the-air updater device to perform actions comprising transmitting messages via the one or more remote network interfaces to a mobile computing device via a server computing system indicating one or more vehicle state conditions; and, in response to receiving a command from the mobile computing device via the server computing system to install an update to software stored on at least one non-transitory computer-readable medium accessible via the one or more vehicle network interfaces, transmitting a signal via the one or more vehicle network interfaces to initiate the update.

In some embodiments, a non-transitory computer-readable medium is provided. The computer-readable medium has computer-executable instructions stored thereon that, in response to execution by one or more processors of a mobile computing device, cause the mobile computing device to perform actions comprising: receiving, from an update server, a message indicating one or more vehicle state conditions; and, in response to determining that the one or more vehicle state conditions indicate that the vehicle is ready for a software update: presenting an interface element for initiating the software update; and in response to detecting actuation of the interface element, transmitting an instruction to the update server to initiate the software update on the vehicle.

In some embodiments, a method of causing an over-the-air updater device of a vehicle to initiate a software update is provided. An update server receives a notification from the over-the-air updater device that a software update has been downloaded. The update server receives a first message indicating one or more vehicle state conditions from the over-the-air updater device. The update server transmits a second message indicating the one or more vehicle state conditions to the mobile computing device. The update server receives an instruction from the mobile computing device to initiate the software update. The update server transmits the instruction to the over-the-air updater device to initiate the software update.

DETAILED DESCRIPTION

As will be described in more detail below, embodiments of the present disclosure generally relate to systems, devices, and methods wherein a mobile computing device is used to manage an over-the-air update of software within a vehicle. The vehicle and the mobile computing device each communicate wirelessly with a server computing system, which acts as an intermediary between the mobile computing device and the vehicle. One or more prerequisites, including but not limited to whether an initiation device has been actuated, whether an engine of the vehicle is off, whether an ignition key of the vehicle is on, whether a battery of the mobile computing device and/or the vehicle has a sufficient level of charge, and whether a parking brake is set, are checked by the server computing system, the vehicle, and/or the mobile computing device before allowing the update to be initiated.

Embodiments of the present disclosure address the technical problems discussed above in multiple ways. In some embodiments, the mobile computing device does not communicate directly with the vehicle, but instead the vehicle and the mobile computing device communicate via the server computing system. Using this communication topology allows the server computing system to authenticate the mobile computing device and/or a user thereof before allowing interaction with the vehicle, thus providing a way of securing the system from access by unauthorized actors. In some embodiments, security of the over-the-air updates is further improved by initiating the software update using both the mobile computing device and an HMI device within the vehicle. This ensures both that the user and/or the mobile computing device are authorized to initiate the software update, and that the user is physically present within the vehicle for initiation (instead of attempting to update the vehicle from a remote location, from which the user cannot know whether the vehicle is in a safe condition to perform the update). Further, the various prerequisite checks performed by the mobile computing device and/or the vehicle improve safety, in that users with low levels of experience and/or training in applying software updates are prevented from initiating updates when the vehicle is in an unsafe state. Embodiments of the present disclosure also reduce the service down-time and eliminate the added fuel usage caused by diverting a vehicle to a dealership or service center for updates Eliminating this diversion also reduces cost, because a user with less training and experience can safely and securely initiate the software updates.

FIG. 1is a schematic diagram of an example embodiment of an environment in which over-the-air software updates for components of a vehicle are performed according to one or more aspects of the present disclosure. The term “over-the-air” refers in general to communication with the vehicle106via one or more wireless networks instead of via a physical connection between the vehicle106and an update device. Accordingly, over-the-air updates of a vehicle can be performed at any location where the vehicle has a communication link to the one or more wireless networks, without requiring the vehicle to be located at a dealership or service center. As shown, the environment100includes a vehicle106, a server computing system104, and a mobile computing device102.

The vehicle106includes an over-the-air updater device108and one or more updatable components110. The over-the-air updater device108communicates with the server computing system104via a first wireless network114. The first wireless network114may include one or more types of wireless communication technology, including but not limited to a 2G wireless network, a 3G wireless network, a 4G wireless network, an LTE wireless network, a Wi-MAX wireless network, a Wi-Fi wireless network, a satellite-based wireless network, or any suitable network capable of wirelessly transmitting software updates. In some embodiments, some portions of the first wireless network114, such as a portion of the first wireless network114that is coupled to the server computing system104, may include wired communication technology including but not limited to an Ethernet local-area network or the Internet. Even in such embodiments, the connection between the vehicle106and the first wireless network114will be via a portion of the first wireless network114that includes a wireless communication technology.

The mobile computing device102communicates with the server computing system104via a second wireless network112. In some embodiments, the second wireless network112may include one or more wireless communication technologies similar to the first wireless network114, including but not limited to a 2G wireless network, a 3G wireless network, a 4G wireless network, an LTE wireless network, a Wi-MAX wireless network, a Wi-Fi wireless network, a satellite-based wireless network, or any suitable network capable of wirelessly transmitting software updates. In some embodiments, some portions of the second wireless network112, such as a portion of the second wireless network112that is coupled to the server computing system104, may include wired communication technology including but not limited to an Ethernet local-area network or the Internet. Even in such embodiments, the connection between the mobile computing device102and the second wireless network112may be via a portion of the second wireless network112that includes a wireless communication technology. In some embodiments, the mobile computing device102may be connected to the server computing system104via a wired communication technology without departing from the scope of the present disclosure.

In some embodiments, the first wireless network114and the second wireless network112may be separate from each other. In some embodiments, at least some portions of the first wireless network114and the second wireless network112may overlap. For example, both the mobile computing device102and the vehicle106may connect to the same Wi-Fi access point or cell phone tower, or separate Wi-Fi access points on a shared local area network, to access their respective wireless networks. However, in all embodiments, the mobile computing device102communicates directly with the server computing system104, and the vehicle106communicates directly with the server computing system104, but the mobile computing device102and the vehicle106do not communicate directly with each other for the management of software updates. Instead, all interaction between the mobile computing device102and the vehicle106is relayed by the server computing device104, even if the mobile computing device102and the vehicle106are connected to overlapping wireless networks. In some embodiments, the mobile computing device102and the vehicle106may communicate with each other for some purposes unrelated to software updates, such as for hands-free operation of the mobile computing device102for communication, for navigation, or for streaming media from the mobile computing device102to an infotainment system of the vehicle106for playback (e.g., using voice commands or HMI devices of the vehicle106to instruct the mobile computing device102to make calls, stream music, access maps, etc.). However, any interaction between the mobile computing device102and the vehicle106related to managing software updates on the vehicle106is mediated by the server computing system104, even if the mobile computing device102and the vehicle106are capable of communicating directly for other purposes.

FIGS. 2A and 2Bare block diagrams that illustrate details of various components of the environment illustrated inFIG. 1according to one or more aspects of the present disclosure. As shown inFIG. 2A(and as previously shown inFIG. 1), the environment includes a mobile computing device102, a server computing system104, and a vehicle106.

The mobile computing device102is any computing device capable of communicating with the server computing system104. In some embodiments, the mobile computing device102is a smartphone, such as an Apple iPhone, a Google Android device, a Samsung Galaxy S device, a Samsung Galaxy Note device, or the like. In some embodiments, the mobile computing device102is a tablet computing device, such as an Apple iPad. Though the mobile computing device102will typically be a highly portable device such as the devices described above, these examples should not be seen as limiting. In other embodiments, the mobile computing device102may be a laptop computing device or other suitable device.

As shown, the mobile computing device102includes a display device202, a camera204, one or more processors207, one or more network interfaces211, and a computer-readable medium209. In some embodiments, the display device202is a screen such as an OLED device, an AMOLED device, or other suitable display device. In some embodiments, the display device202is also touch sensitive, such that a user can interact with information presented on the display device202using touches such as tapping, holding, swiping, and dragging. In some embodiments, the camera204(which may or may not be present) is a device configured to capture video and/or images, and to provide the video and/or images to other components of the mobile computing device102for further processing. In some embodiments, the one or more network interfaces211may include at least one wireless network interface, including but not limited to a cellular network interface, a Wi-Fi interface, and a Bluetooth interface. The one or more network interfaces211allow the mobile computing device102to communicate with at least the second wireless network112. In some embodiments, the at least one processor207may include one or more general-purpose CPUs, one or more special-purpose processors (including but not limited to graphics processors), or other types of processors. The at least one processor207executes computer-executable instructions stored on the computer-readable medium209. The computer-readable medium209may be any suitable computer-readable medium, including but not limited to a flash memory, and may store an update processing module206. In some embodiments, the update processing module206is configured to communicate with the server computing system104and to present various interfaces via the display device202as illustrated and described further below.

In general, the word “module,” as used herein, refers to logic embodied in hardware or software instructions, which can be written in a programming language, such as C, C++, COBOL, JAVATM, PHP, Perl, HTML, CSS, JavaScript, VBScript, ASPX, Microsoft .NETTM, Swift, Go, and/or the like. A module may be compiled into executable programs or written in interpreted programming languages. Software modules may be callable from other modules or from themselves. Generally, the modules described herein refer to logical modules that can be merged with other modules, or can be divided into modules. As a non-limiting example, in some embodiments, the user processing module208and the communication relay module210may be combined into a single module. The modules can be stored in any type of computer-readable medium or computer storage device and be stored on and executed by one or more processors of an ECU or other computing device, thus creating a special purpose computer configured to provide the module. Thus, the term “module” as used herein may be shorthand for one or more processors and a computer-readable medium having computer-executable instructions stored thereon that, in response to execution by the one or more processors, cause the one or more processors to perform the actions described as being performed by the module.

In some embodiments, the server computing system104includes one or more computing devices capable of communicating with the first wireless network114and the second wireless network112and performing the actions below. Any suitable computing devices may be used. Typically, the computing devices of the server computing system104include desktop computing devices, rack-mounted computing devices, and/or cloud computing systems. In some embodiments, the computing devices of the server computing system104are hosted in a single data center. In some embodiments, the computing devices of the server computing system104are located in more than one data center, and communicate with each other via one or more networks. As shown, the server computing system104includes a computer-readable medium213that stores a user processing module208and a communication relay module210, one or more processors203, one or more network interfaces205, and a vehicle data store212. In some embodiments, the user processing module208authenticates users connecting to the server computing system104via mobile computing devices102in order to permit them to interact with the server computing system104. In some embodiments, the user processing module208provides functionality for associating users with vehicles106, and may also verify that an authenticated user of a mobile computing device102is associated with a vehicle106they are attempting to update. In some embodiments, instead of or in addition to associating users with vehicles106, the user processing module208may provide functionality for associating mobile computing device102with vehicles106, and may also verify that a given mobile computing device102is associated with a vehicle106it is being used to update. In some embodiments, the user processing module208queries a vehicle data store212—which stores the associations between vehicles106and users, between vehicles106and mobile computing devices102, or both—for vehicles associated with an authenticated user or a given mobile computing device102. A list of the associated vehicles is then provided by the user processing module208to the appropriate mobile computing device102.

A “data store” as described herein may be any suitable device configured to store data for access by a computing device. One example of a data store is a highly reliable, high-speed relational database management system (DBMS) executing on one or more computing devices and accessible over a high-speed network. Another example of a data store is a key-value store. However, any other suitable storage technique and/or device capable of quickly and reliably providing the stored data in response to queries may be used, and the computing device may be accessible locally instead of over a network, or may be provided as a cloud-based service. A data store may also include data stored in an organized manner, such as files in a file system, on a computer-readable storage medium, as described further below.

In some embodiments, the communication relay module210receives transmissions from the vehicle106, determines an appropriate mobile computing device102to receive the transmission, and sends a transmission based on the transmission from the vehicle106to the mobile computing device102. The communication relay module210may also receive transmissions from the mobile computing device102intended for the vehicle106, and may send transmissions based on the transmissions from the mobile computing device102to the vehicle106.

In some embodiments, the one or more processors203may include any suitable processor, including but not limited to a general purpose CPU, a graphics processor, and other types of processors. The one or more processors203execute computer-executable instructions stored on the computer readable medium213. In some embodiments, the one or more network interfaces205may include a wired interface including but not limited to an Ethernet interface, a USB interface, a FireWire interface, or other type of wired interface. In some embodiments, the one or more network interfaces205may include a wireless interface including but not limited to a Wi-Fi interface, a 3G interface, a 4G interface, an LTE interface, a Bluetooth interface, or another type of wireless interface.

The server computing system104is illustrated in a single box, and in some embodiments, may be implemented using a single computing device. In some embodiments, multiple computing devices may be used to provide the server computing system104. In such embodiments, the components of the server computing system104illustrated inFIG. 2Amay be duplicated amongst the computing devices and load may be balanced between the computing devices, or some components may be present on some computing devices and some components may be present on other computing devices. For example, a first computing device (or set of computing devices) may provide the user processing module208, while a second computing device (or set of computing devices) provides the communication relay module210, and a third computing device (or set of computing devices) provides the vehicle data store212. In some embodiments, at least some components of the server computing system104may be provided in a cloud service or using a virtual server instead of being provided by a dedicated computing device.

As stated above, the vehicle106may be any type of vehicle that includes updatable software. In some embodiments, the vehicle106is a Class 8 truck. In some embodiments, the vehicle106is another type of vehicle, such as another class of truck, a bus, a passenger car, a motorcycle, etc. As shown, the vehicle106includes an over-the-air (OTA) updater device108, an updatable component110, and a human-machine interface (HMI) device214. Though not illustrated, the components of the vehicle106communicate with each other in some embodiments using a vehicle communication bus. Any suitable vehicle communication bus, such as a controller area network (CAN) bus, may be used.

In some embodiments, the OTA updater device108performs actions for updating software within the vehicle106. In some embodiments, the OTA updater device108obtains software updates. In some embodiments, the OTA updater device108communicates vehicle status information to the server computing system104. In some embodiments, the OTA updater device108receives commands from the server computing system104regarding the application of software updates, and applies the software updates in response to the commands. Further description of the OTA updater device108is provided below in association withFIG. 2B.

In some embodiments, the updatable component110is any non-transitory computer-readable medium within the vehicle106that has computer-executable instructions, data, or other software stored thereon that can be updated by the OTA updater device108. In some embodiments, this computer-readable medium may be a part of another vehicle component, such as a firmware or other memory of an ECU. In some embodiments, this computer-readable medium may be a separate component, such as a flash memory. Though only a single updatable component110is illustrated inFIG. 2for ease of discussion, in some embodiments, the vehicle106may have more than one updatable component110.

In some embodiments, the HMI device114is a device that accepts input from the operator of the vehicle106. Any suitable device may be used as the HMI device114, including but not limited to a push button, a toggle switch, a lever, and a touch-sensitive display. In some embodiments, a dedicated HMI device114(such as a push button, toggle switch, lever, or touch-sensitive display interface that is only associated with the software update initiation functionality) is provided in the vehicle106for initiating the software update functionality as described below. In some embodiments, the status of an existing HMI device114within the vehicle106(such as a push button, toggle switch, lever, or touch-sensitive display interface that is associated with functionality of the vehicle106whether or not the software update initiation functionality is present in the vehicle106) may be used to initiate the software update functionality. For example, in some embodiments, a cruise control set button may be an existing HMI device114that can be used to initiate software update functionality. In such embodiments, the cruise control set button may be depressed for a threshold amount of time, such as three seconds, in order to activate the functionality as described below.

FIG. 2Billustrates further details regarding components within the over-the-air (OTA) updater device108. As shown, the OTA updater device108includes at least one processor220, one or more remote network interfaces222, one or more vehicle network interfaces224, and a computer-readable medium216that stores an over-the-air update module218thereon. In some embodiments, the at least one processor220may include one or more general-purpose CPUs, one or more special-purpose processors (including but not limited to graphics processors), or other types of processors. The at least one processor220executes computer-executable instructions stored on the computer-readable medium216. In some embodiments, the one or more remote network interfaces222may include at least one wireless network interface, including but not limited to a cellular network interface, a Wi-Fi interface, and a Bluetooth interface. The one or more remote network interfaces222allow the OTA updater device108to communicate with at least the first wireless network114. In some embodiments, the one or more vehicle network interfaces224may include at least one network interface that connects the OTA updater device108to other components of the vehicle106, including but not limited to the vehicle communication bus (CAN bus) described above, an Ethernet network, a USB network, a FireWire network, a wireless network local to the vehicle106, or another network that connects components of the vehicle106. The over-the-air update module218causes the OTA updater device108to perform actions for controlling a software update of a vehicle106as described below.

FIGS. 3A-3Cdescribe an example method for controlling a software update of a vehicle component according to one or more aspects of the present disclosure. At block302, an over-the-air (OTA) updater device108of a vehicle106receives a software update for an updatable component110. In some embodiments, the software update includes computer-executable instructions, settings, data or other software that will replace or update software stored in an updatable component110. In some embodiments, the software update may also include other information, including but not limited to version information, prerequisite information, and instructions for the OTA updater device108regarding how to install the software on the updatable component110. Though the discussion herein primarily refers to obtaining a single software update for a single updatable component110for ease of discussion, in some embodiments, the OTA updater device108may obtain more than one software update for a single updatable component110. Also, in some embodiments, the OTA updater device108may obtain separate software updates for multiple updatable components110.

The OTA updater device108may receive the software update in a variety of manners. For example, the OTA updater device108may transmit a request for available updates to the server computing system104(or another computing system), and may receive the software update in response. As another example, the server computing system104(or another computing system) may push the software update to the OTA updater device108, or may otherwise cause the OTA updater device108to initiate a download of the software update. As yet another example, the software update may be copied to the OTA updater device108from a computer-readable storage medium coupled to the vehicle106. After obtaining the software update, the OTA updater device108stores the software update until application of the software update is initiated.

At block304, the OTA updater device108optionally transmits a notification to a server computing system104that the software update has been obtained. This may be the same server computing system104from which the software update was obtained, or the software update may have been obtained from a different source. In some embodiments, the notification informs the server computing system104that the software update has been completely downloaded to allow a list of registered vehicles that includes indications of vehicles that have received a software update to be generated. If the optional notification is not transmitted, the list of registered vehicles may not include the indications of vehicles that have received software updates. At block306, the server computing system104stores the software update status that indicates that the software update has been obtained by the vehicle106in a vehicle data store212of the server computing system104.

At block308, a user activates an update processing module206of a mobile computing device102. In some embodiments, the update processing module206may be activated at the user's discretion, such as by manually launching an application that provides the functionality of the update processing module206. In some embodiments, the update processing module206may be activated in response to a message transmitted from the server computing system104to the mobile computing device102in response to receiving and storing the notification from the OTA updater device108. The message transmitted to the mobile computing device102may be a push notification including but not limited to an application-directed SMS, an iMessage, or a text SMS with a link usable to launch the update processing module206. Alternatively, the message transmitted to the mobile computing device102may be another kind of message, such as an email. In some embodiments, receipt of the message causes the mobile computing device102to present a notification that prompts the user to launch an application that provides the functionality of the update processing module206. In some embodiments, receipt of the message causes the mobile computing device102to automatically launch an application that provides the functionality of the update processing module206.

At block310, the user provides login credentials to the update processing module206, and the update processing module206transmits the login credentials to the server computing system104. Any suitable type of login credential may be used, including but not limited to a username and password, a value provided from a smart card, biometric information, a code generated by a key generator, and an identifier of the mobile computing device102. In some embodiments, combinations of more than one type of login credential may be used. In some embodiments, the login credentials may include information previously entered by the user and stored by the mobile computing device102, such as a saved username and password, or stored biometric information.

At block312, a user processing module208of the server computing system104verifies the login credentials and retrieves a list of registered vehicles associated with the user from the vehicle data store212. An example embodiment of a method for creating of the list of registered vehicles associated with the user is illustrated inFIG. 5and discussed in further detail below. In some embodiments, the list of registered vehicles may include status information about each vehicle, including but not limited to whether each vehicle has received a software update that is awaiting installation. In some embodiments, the list of registered vehicles may include vehicle identification numbers (VINs) associated with each vehicle (or portions thereof), other unique identifiers of the vehicles (such as license plate numbers or other unique identifiers generated for the vehicles to associate the vehicles with records in the vehicle data store104), and/or information to make it easier to identify a given vehicle (such as a nickname, a color, or a photograph) At block314, the user processing module208transmits the list of registered vehicles to the mobile computing device102, and the update processing module206presents the list of registered vehicles. Presenting may occur by displaying the list on a display device, outputting the list via a loudspeaker, or by any other presentation technique. The list of registered vehicles transmitted to the mobile computing device102may include identifiers corresponding to each vehicle.

At block316(FIG. 3B), in response to a user selection of the particular vehicle106from the displayed list of registered vehicles, the update processing module206transmits an identifier corresponding to the selected vehicle to the server computing system104. In some embodiments, the identifier of the selected vehicle is a vehicle identification number (VIN) associated with the vehicle or a portion thereof. In some embodiments, the identifier is some other unique identifier, such as a license plate number, or a unique identifier other than the VIN that is generated for the vehicle106to associate the vehicle106with a record in the vehicle data store104.

FIG. 4Aillustrates an example embodiment of a mobile computing device102user interface displaying a list of registered vehicles according to various aspects of the present disclosure. As shown in this example, the mobile computing device102displays a list of vehicles402, including each corresponding unique identifier404. In some embodiments, more information may be provided in order to make it easier to identify a given vehicle, such as a license plate number, a nickname, a color, or a photograph. The stars406in the list of vehicles may indicate whether a given vehicle has received a software update, and selecting a vehicle within the list via a tap, a swipe, a press and hold, a hard press, or other gesture may cause the selection described in block316. In some embodiments, the illustrated interface may be used to perform a search for a specific vehicle. Alternatively or additionally, the user interface may receive an input from a camera of the mobile computing device102to scan an identifier such as a QR code, VIN, or license plate from the vehicle in order to detect or identify a particular vehicle within the list, or to cause the selection described in block316.

In some embodiments, the user processing module208(or the communication relay module210) keeps track of whether a mobile computing device102is currently interacting with the vehicle106. A mobile computing device102is interacting with the vehicle106when it is receiving notifications from the server computing system104about the vehicle106and transmitting commands to the server computing system104intended for the vehicle106. In some embodiments, the mobile computing device102may be considered to be interacting with the vehicle106between receipt of notifications and transmission of commands if the method300is still underway for the mobile computing device102and the vehicle106. Typically, only one mobile computing device102will be allowed to receive the notifications and transmit commands at a time in order to avoid conflicts between the two devices. In some embodiments, multiple mobile computing devices102may be allowed to receive the notifications, but only a single mobile computing device102may be allowed to transmit commands at a time. Accordingly, at block318(FIG. 3B), the user processing module208verifies that no other device is receiving notifications and transmitting commands for the vehicle106, and stores a record indicating that the mobile computing device102is interacting with the vehicle106. The method300as illustrated assumes that no other device is receiving notifications and transmitting commands for the vehicle106. However, if the user processing module208detected that a different device is receiving notifications and transmitting commands for the vehicle, the user processing module208may transmit an error notification to be presented by the mobile computing device102, and the method300may terminate.

At block319, the user processing module208transmits instructions for performing a triggering action to the mobile computing device102, and the update processing module206presents the instructions. Presenting the instructions helps guide the user through successfully initiating the software update without requiring other training. In some embodiments, the triggering action is an action performed within the vehicle106to indicate that the user is present and intends to initiate the software update. In some embodiments, the triggering action may be designed to avoid inadvertent triggering. For example, the triggering action may include actuating an HMI device214of the vehicle106(such as the cruise control set button, a button dedicated to the update initiation functionality, or another HMI device214) for at least a threshold amount of time, such as depressing a button for at least three seconds. The threshold amount of time may help ensure that an inadvertent or unrelated actuation of the HMI device214does not trigger the update functionality. In some embodiments, another technique could be used to avoid inadvertent triggering, such as using an input interface on an infotainment system or other touch-sensitive display that is hidden behind multiple layers of menus or that requires some other detailed input or confirmation from the user to be actuated. Using a threshold amount of time for actuating an existing HMI device214such as a cruise control set button has benefits in that the functionality cannot be accidentally discovered, because existing vehicle hardware can be used without changes, and because the technique is relatively simple. Another example of a technique for avoiding inadvertent triggering is determining whether an HMI device214that is protected from actuation by a cover, a key, or by another technique has been actuated for any amount of time. Yet another example of a technique for avoiding inadvertent triggering is determining whether a combination of HMI devices214were actuated at the same time, or in a predetermined sequence.

FIG. 4Billustrates an example embodiment of a mobile computing device102user interface displaying a set of instructions for performing a triggering action so initiate installation of the software update. As shown in this example, the interface displays text408instructing the user to press and hold the cruise control set button for three seconds to initiate the installation. Additionally or alternatively, a photo or illustration410of the cruise control set button is provided to assist the user in locating the proper button. In this example, the interface also includes a back interface control412to allow the user to return to the list of vehicles, in case the user no longer wishes to proceed with the software update for the selected vehicle. AlthoughFIG. 4Billustrates a particular example instructing the user to depress the cruise control button, this example is not meant to limit the scope of the disclosure, and it is understood that any one or more combinations of buttons may be used to confirm installation of the software update.

Returning toFIG. 3B, at block320, the user processing module208transmits a request to the OTA updater device108of the vehicle106for notifications of vehicle state conditions. The request sent to the OTA updater device108by the user processing module208may not identify the mobile computing device102, because the vehicle106is only transmitting the notifications to the server computing system104, and the server computing system104is storing a record regarding which mobile computing device102should receive updates generated by a given vehicle106. In some embodiments, the requests generated by the user processing module208may be sent to the OTA updater device108by the communication relay module210.

At block321, the OTA updater device108collects one or more vehicle state conditions and transmits notifications of the one or more vehicle state conditions to the server computing system104. Each vehicle state condition indicates a condition of the vehicle106that may impact whether the vehicle106is ready for an update. Some vehicle state conditions may indicate whether the update is likely to succeed or fail (including but not limited to whether wireless signal strength or battery levels are adequate). Some vehicle state conditions may indicate whether the vehicle106is in a condition in which it is safe to install the update (including but not limited to whether the vehicle106is parked, whether the engine of the vehicle106is running, or whether the user is present within the vehicle106).

In some embodiments, the OTA updater device108collects the one or more vehicle state conditions by receiving information that can be used to determine the vehicle state conditions from other components of the vehicle106via the vehicle communication bus. The vehicle state conditions may include instantaneous values (such as a value at a time when the OTA update device108queries a component for the value) and may also include values that are determined over time (such as how long a particular value has been in a particular state). A non-limiting example of a vehicle state condition that may be determined over time is whether a HMI device214has been actuated for a threshold amount of time. Some non-limiting examples of vehicle state conditions that may be determined based on an instantaneous value include whether an engine of the vehicle106is running, whether an ignition of the vehicle106is on, whether a battery voltage of the vehicle106meets a battery voltage threshold, whether a wireless signal strength detected by the OTA updater device108meets a signal strength threshold, whether a parking brake of the vehicle106is set, whether the OTA updater device108can communicate with one or more updatable components110to be updated by the software update and/or the computer-readable media associated therewith, and any combination thereof.

At block322, a communication relay module210of the server computing system104transmits a notification including the one or more vehicle state conditions to the mobile computing device102. At block324, the update processing module206checks the one or more vehicle state conditions provided in the notification to determine if the triggering action was performed at the vehicle106. Ensuring purposeful triggering by analyzing the actuation of an HMI device214or other triggering signal by analyzing the vehicle state conditions from the vehicle106helps provide an additional layer of security, in that the software update process cannot be initiated without both being authenticated by the server computing system104through the mobile computing device102, and also by having physical access to the vehicle106such that the HMI device214can be actuated. This can help prevent remote attacks on the software update process from unauthorized or malicious actors.

The method300then proceeds to decision block326, where a determination is made based on whether the triggering action was performed at the vehicle106. If the update processing module206determines that the triggering action was not performed at the vehicle106, then the result of decision block326is NO, and the method300proceeds to block328, where the update processing module206again presents an instruction to perform the triggering action. In some embodiments, the presentation of the instruction may be skipped, but displaying the instruction again can help guide the operator through the software update process without requiring significant training. The method300then returns to block320.

Returning to decision block326, if the HMI device has been actuated for at least the threshold amount of time, then the result of decision block326is YES, and the method300proceeds to a continuation terminal (“terminal C”). At block330(FIG. 3C), the update processing module206presents readiness values of a remainder of the vehicle state conditions. In some embodiments, the update processing module206may present success indicators associated with vehicle state conditions that are met, and failure indicators associated with vehicle state conditions that are not met, in order to guide the operator through preparing the vehicle106for the software update. In some embodiments, for vehicle state conditions that are not met, the update processing module206may present further information regarding how the operator can cause the conditions to be met. In some embodiments, the update processing module206may also check state conditions of the mobile computing device102itself, in addition to the vehicle state conditions. These mobile device state conditions may include but are not limited to, whether a battery level of the mobile computing device102meets a battery level threshold, or a wireless signal strength detected by the mobile computing device102meets a signal strength threshold. The success or failure states of these mobile device state conditions may also be presented, at block330, on a display of the mobile device102, along with information regarding how to remedy failed conditions (such as, for example, instructing the user to connect the mobile computing device102to a power source). These conditions may affect the determination at decision block332, in that if one or more of the mobile device states are failed, the result of decision block332may be NO (as described further below).

FIG. 4Cillustrates an example embodiment of a mobile computing device102user interface displaying a success state for each of the vehicle state conditions and mobile device state conditions. As shown in this example, a checkmark416is presented next to indicators for an engine off vehicle state condition418, an ignition on vehicle state condition420, a mobile battery charge state condition422, a vehicle battery voltage state condition424, and a parking brake state condition426. Alternatively, more, fewer, or different vehicle state conditions may be presented, and the interface may allow scrolling or swiping to show more vehicle state conditions than provided on the present display. The interface also includes an interface element for initiating the software update428, which will be described in further detail, below.

FIG. 4Dillustrates an example embodiment of a mobile computing device102user interface displaying a failure state for one of the vehicle state conditions according to various aspects of the present disclosure. As shown, a positive indicator such as a checkmark416is presented next to each listed vehicle state condition or mobile device state condition that is in a success state. Furthermore, in this example, a negative indicator such as an “X”430is presented next to each vehicle state condition or mobile device state condition that is in a failure state. Some vehicle state conditions, such as the illustrated engine off vehicle state condition418, may be self-explanatory with regard to how to remedy the failed state condition. For other vehicle state conditions, further information may be provided to explain how to remedy the failure state, either automatically next to the failed indicator, or upon tapping on the negative indicator. In this example, the interface element for initiating the software update426(e.g., the “INSTALL” user interface element) is not displayed because of the presence of at least one failure state. Alternatively, in some embodiments, the interface element for initiating the software update426may be present in the interface illustrated inFIG. 4D, but disabled.

Although this example displays checkmarks and “X” indicators as illustrating the success state and the failure state, respectively, it is understood that in some embodiments other techniques may be used to indicate success and failure, including but not limited to different colors, different shapes, or organization of indicators into different areas or groups.

Returning toFIG. 3C, the method300then proceeds to decision block332, where a determination is made regarding whether the vehicle state conditions indicate that the vehicle106is ready for an update. In some embodiments, the determination at decision block332is made by the update processing module206, because the result is a change in the interface presented by the mobile computing device102. Alternatively, in some embodiments, the determination at decision block332is made by the user processing module208or the communication relay module210, and a result of the determination is transmitted to the update processing module206. If the vehicle state conditions do not indicate that the vehicle106is ready for an update, then the result of decision block332is NO, and the method300returns to terminal B to recheck the vehicle state conditions. Otherwise, if all of the vehicle state conditions indicate that the vehicle106is ready for an update, then the result of decision block332is YES, and the method300proceeds to block334. In some embodiments, all of the vehicle state conditions presented by the mobile computing device102must be met in order to indicate that the vehicle106is ready for an update. In some embodiments, there may be only a single vehicle state condition. In some embodiments, some of the vehicle state conditions may not be critical for proceeding to perform an update, and in such embodiments, less than all of the vehicle state conditions may need to be met for the result of decision block332to be YES. In some embodiments, a patterned sequence of vehicle state conditions may indicate that the vehicle106is ready for an update.

At block334, the update processing module206presents an interface element for initiating the software update.FIG. 4Calso illustrates such an interface element, which includes the text “Install” and allows the user to tap to actuate the element. Though a button interface element is illustrated inFIG. 4C, any suitable interface element, including but not limited to a slide bar, a toggle switch, and a toggle switch/button combination may be used. Returning toFIG. 3C, at block336, the update processing module206detects actuation of the interface element and transmits a command to the server computing system104to initiate the software update.

At block338, the communication relay module210transmits the command to the OTA updater device108, which receives the command, conducts the software update process, and transmits a signal indicating a result to the server computing system104. In some embodiments, the OTA updater device108may separately confirm the vehicle state conditions allow the software update process to be conducted, in order to add an additional level of safety assurance. The OTA updater device108may use any suitable technique for applying the update to the updatable component110. For example, the OTA updater device108may transmit the software update or a portion thereof to the updatable component110via the vehicle communication bus, and the updatable component110may use it to update software stored on a computer-readable medium of the updatable component110. As another example, the OTA updater device108may directly access the computer-readable medium via the vehicle communication bus, and may itself update the stored information on the computer-readable medium.

At block340, the communication relay module210transmits the result to the mobile computing device102. In some embodiments, the result may indicate a success of the software update or a failure of the software update, and may include separate results for separate software updates and/or updatable components110. In some embodiments, intermediate results, such as a predicted amount of time before the software update is completed, or a percentage of the software update that has currently been completed, may be transmitted by the OTA updater device108and relayed to the mobile computing device102by the communication relay module210in order to present a progress indication to the operator during application of the software update.

The method300then proceeds to a decision block341, where a determination is made by the update processing module206regarding whether the software update was successful based on the result received from the vehicle106via the communication relay module210. In some embodiments, the determination may be made by the communication relay module210or the user processing module208and transmitted to the update processing module206. If the result indicates that the software update was successful, then the result of decision block341is YES, and the method300proceeds to block342, where the update processing module206presents a success notification. In addition, the server computing system104may update the appropriate vehicle record in the vehicle data store212to indicate that the software update was successfully installed. Accordingly, a future vehicle status list such as the list presented in block314will include accurate information regarding the software updates that have been applied to the vehicle106. After presentation of the success notification, the method300proceeds to an end block and terminates.FIG. 4Eillustrates an example embodiment of an interface presented by a mobile computing device102that shows such a success notification according to one or more aspects of the present disclosure.

Returning to decision block341ofFIG. 3C, if the result indicated that the software update was not successful, then the result of decision block341is NO, and the method300proceeds to block344, where the update processing module206presents a failure notification. In some embodiments, the failure notification may include a status message that indicates what portion of the software update failed and why. In some embodiments, the failure notification may indicate to the operator that a retry of the software update will be automatically attempted one or more times. In some embodiments, the failure notification may provide an interface element that gives the operator the option to choose to manually retry the software update.

FIG. 4Fillustrates an example embodiment of an interface presented by a mobile computing device102that shows a failure notification according to one or more aspects of the present disclosure. As shown, the interface displays an indication432that the update was unsuccessful and that the vehicle106will automatically retry the software update after a predetermined time period. An interface element434is also provided to allow the user to request an immediate retry. In some embodiments, the automatic retry may be performed for a predetermined number of attempts before requiring confirmation for further retries from the user.

Returning toFIG. 3C, the method300then proceeds to decision block346, where a determination is made based on an option chosen by the operator in the failure notification interface. If the operator chooses to retry the software update then the result of decision block346is YES, and the method300returns to block334to attempt to retry the update. Otherwise, if the operator chooses not to retry the software update, then the result of decision block346is NO. In some embodiments, not receiving a command to retry within a given time period may cause the OTA updater device108to automatically retry the software update. The method300then proceeds to an end block and terminates. In some embodiments, upon reaching the end block, the record indicating that the mobile computing device102is interacting with the vehicle106may be deleted.

FIG. 5is a flowchart that illustrates an example embodiment of a method500of registering a vehicle to be associated with a user for controlling software updates according to one or more aspects of the present disclosure. At block502, a user activates an update processing module206of a mobile computing device102. In an example, this may involve the user launching an application on the mobile computing device102that provides the functionality of the update processing module206. At block504, the user provides login credentials to the update processing module206, and the update processing module206transmits the login credentials to the server computing system104. At block506, a user processing module208of the server computing system104verifies the login credentials. The details of blocks502-506are similar to the details described above in blocks308-312ofFIG. 3A, and so are not repeated here for the sake of brevity.

At block508, the update processing module206detects actuation of an interface control for adding a vehicle and prompts the user to obtain a unique identifier of the vehicle106.

At block510, the user enters the unique identifier of the vehicle106by manual entry (such as by using a keyboard) or by scanning a QR code attached to the vehicle with a camera204of the mobile computing device102. Using the camera204to scan a QR code applied to the vehicle106to obtain the unique identifier of the vehicle is an example only. In some embodiments, a one-dimensional bar code may be used instead of a two-dimensional QR code. In some embodiments, the camera204may be used take a picture of the alphanumeric VIN or other alphanumeric identifier attached to the vehicle106, and the unique identifier value may be obtained from the picture using optical character recognition (OCR). In some embodiments, the mobile computing device102may include a microphone, which allows the user to enter the unique identifier using voice input by reading off the VIN or other unique vehicle identifier.

At block512, the update processing module206transmits the unique identifier of the vehicle106to the server computing system104. At block514, the user processing module208registers the vehicle106with the user in the vehicle data store212using the unique identifier. To register the vehicle106, the user processing module208creates a record within the vehicle data store212that associates the vehicle106with the user. The record may also store other information about the vehicle106, such as the status of software updates as described above. After registration, the vehicle106will be added to the vehicle list as described herein, enabling the user to initiate software updates for the registered vehicle106. The method500then proceeds to an end block and terminates.

FIG. 6is a block diagram that illustrates aspects of a representative computing device600appropriate for use with embodiments of the present disclosure. WhileFIG. 6is described with reference to a computing device that is implemented as a device on a network, the description below is applicable to servers, personal computers, mobile phones, smart phones, tablet computers, embedded computing devices, and other devices that may be used to implement portions of embodiments of the present disclosure. Moreover, those of ordinary skill in the art and others will recognize that the computing device600may be any one of any number of currently available or yet to be developed devices.

In its most basic configuration, the computing device600includes at least one processor602and a system memory604connected by a communication bus606. Depending on the exact configuration and type of device, the system memory604may be volatile or nonvolatile memory, such as read only memory (“ROM”), random access memory (“RAM”), EEPROM, flash memory, or similar memory technology. Those of ordinary skill in the art and others will recognize that system memory604typically stores data and/or program modules that are immediately accessible to and/or currently being operated on by the processor602. In this regard, the processor602may serve as a computational center of the computing device600by supporting the execution of instructions.

As further illustrated inFIG. 6, the computing device600may include a network interface610comprising one or more components for communicating with other devices over a network. Embodiments of the present disclosure may access basic services that utilize the network interface610to perform communications using common network protocols. The network interface610may also include a wireless network interface configured to communicate via one or more wireless communication protocols, such as Wi-Fi, 2G, 3G, LTE, WiMAX, Bluetooth, and/or the like.

In the exemplary embodiment depicted inFIG. 6, the computing device600also includes a storage medium608. However, services may be accessed using a computing device that does not include means for persisting data to a local storage medium. Therefore, the storage medium608depicted inFIG. 6is represented with a dashed line to indicate that the storage medium608is optional. In any event, the storage medium608may be volatile or nonvolatile, removable or non-removable, implemented using any technology capable of storing information such as, but not limited to, a hard drive, solid state drive, flash memory, CD ROM, DVD, or other disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, and/or the like.

As used herein, the term “computer-readable medium” includes volatile and non-volatile and removable and non-removable media implemented in any method or technology capable of storing information, such as computer readable instructions, data structures, program modules, or other data. In this regard, the system memory604and storage medium608depicted inFIG. 6are merely examples of computer-readable media. Computer-readable media can be used to store data for use by programs.

Suitable implementations of computing devices that include a processor602, system memory604, communication bus606, storage medium608, and network interface610are known and commercially available. For ease of illustration and because it is not important for an understanding of the claimed subject matter,FIG. 6does not show some of the typical components of many computing devices. In this regard, the computing device600may include input devices, such as a keyboard, keypad, mouse, microphone, touch input device, touch screen, tablet, and/or the like. Such input devices may be coupled to the computing device600by wired or wireless connections including RF, infrared, serial, parallel, Bluetooth, USB, or other suitable connections protocols using wireless or physical connections. Similarly, the computing device600may also include output devices such as a display, speakers, printer, etc. Since these devices are well known in the art, they are not illustrated or described further herein.

As will be appreciated by one skilled in the art, the specific routines described above in the flowcharts may represent one or more of any number of processing strategies such as event-driven, interrupt-driven, multi-tasking, multi-threading, and the like. As such, various acts or functions illustrated may be performed in the sequence illustrated, in parallel, or in some cases omitted. Likewise, the order of processing is not necessarily required to achieve the features and advantages, but is provided for ease of illustration and description. Although not explicitly illustrated, one or more of the illustrated acts or functions may be repeatedly performed depending on the particular strategy being used. Further, these FIGURES may graphically represent code to be programmed into a computer-readable storage medium associated with a computing device.