Intelligent caching of OTA software updates for vehicles

Abstract

An exemplary computing system may include control circuitry configured to obtain data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location. The control circuitry may be configured to determine that an over-the-air (OTA) software package is available for the vehicle based on the vehicle identifier. The control circuitry may be configured to obtain the OTA software package for the vehicle based on the vehicle identifier over a network from a remote computing system. The control circuitry may be configured to provide the OTA software package to local cache storage located at the location prior to the time when the vehicle is estimated to be at the location.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 429,480, filed December 1, 2022, the contents of which are incorporated herein by reference in their entirety.

[0002] This disclosure relates generally to distributing over-the-air software updates to vehicles and, more specifically, to intelligently caching over-the-air software updates at specific locations to more efficiently distribute such updates to vehicles while conserving computational resources. [Background technology]

[0003] OTA (over-the-air) updates involve the process of wirelessly updating the software of devices such as smartphones, Internet of Things (IoT) devices, or vehicles. OTA updates allow manufacturers to remotely push updates and patches to devices without requiring users to connect the device or manually install the update. OTA updates are commonly used to fix software bugs, improve device performance, add new features, and address security vulnerabilities. OTA updates have become increasingly common in recent years as more devices become connected to the internet, making it easier for manufacturers to distribute updates quickly and efficiently. Summary of the Invention

[0004] Aspects and advantages of implementations 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 implementations.

[0005] One exemplary aspect of the present disclosure is directed to a computing system. The computing system includes control circuitry configured to obtain data indicating a vehicle identifier associated with a vehicle and a time (time, timing) when the vehicle is estimated to be at a (predetermined) location. The control circuitry is configured to determine, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle. The control circuitry is configured to obtain, via a network from a remote computing system, an OTA software package for the vehicle based on the vehicle identifier. The control circuitry is configured to provide the OTA software package to local cache storage located at the location prior to the time when the vehicle is estimated to be at the location.

[0006] In some implementations, the control circuitry is further configured to determine that the vehicle has arrived at the location and that the OTA software package is available for the vehicle, and to output the OTA software package from the local cache storage.

[0007] In some implementations, to determine that the vehicle has arrived at the location and that the vehicle is available for the OTA software package, the control circuitry is configured to obtain a request for the OTA software package generated by the vehicle.

[0008] In some implementations, the OTA software package includes a software update package that updates the version of software currently downloaded to the vehicle.

[0009] In some implementations, the location is a vehicle service location, and to obtain data indicative of a time when the vehicle is estimated to arrive at the location, the control circuitry is configured to obtain data indicative of a scheduled service for the vehicle, and determine, based on the scheduled service for the vehicle, a time when the vehicle is estimated to arrive at the service location.

[0010] In some implementations, the location is a vehicle service location, and to obtain data indicative of an estimated time that the vehicle will arrive at the location, the control circuitry is configured to obtain historical service data associated with the vehicle and predict, based on the historical service data associated with the vehicle, an estimated time that the vehicle will arrive at the service location.

[0011] In some implementations, the control circuitry is further configured to adjust a service schedule for the vehicle based on the OTA software update.

[0012] In some implementations, the location is a charging station, and to obtain data indicative of a time that the vehicle will be estimated to be at the location, the control circuitry is configured to obtain historical charging data associated with the vehicle and predict a time that the vehicle will be estimated to arrive at the charging station based on the historical charging data associated with the vehicle.

[0013] In some implementations, the location is a vehicle production facility, and to obtain data indicative of a time when the vehicle will be estimated to be at the location, the control circuitry is configured to obtain data indicative of a status of the vehicle at the vehicle production facility and, based on the status of the vehicle, predict a time when the vehicle will be estimated to be ready for an OTA software update at the vehicle production facility.

[0014] In some implementations, the control circuitry is further configured to determine whether an OTA software package for the vehicle is already stored in a local cache storage located at the location.

[0015] In some implementations, the control circuitry is further configured to provide data indicating that the OTA software package has been provided to the vehicle at the location to a remote computing system for updating the vehicle's shadow record.

[0016] In some implementations, the control circuitry is further configured to determine a confidence level of the time the vehicle is estimated to be at the location and queue the OTA software package based on the confidence level of the time the vehicle is estimated to be at the location.

[0017] In some implementations, the control circuitry is further configured to obtain network traffic data associated with the network and determine, based on the network traffic data, a time period for obtaining the OTA software package over the network.

[0018] Another exemplary aspect of the present disclosure is directed to a computer-implemented method system. The method includes obtaining data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a (predetermined) location. The method includes determining, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle. The method includes obtaining, from a remote computing system over a network, an OTA software package for the vehicle based on the vehicle identifier. The method includes providing the OTA software package to local cache storage located at the location before the time when the vehicle is estimated to be at the location.

[0019] In some implementations, the method includes determining that the vehicle has arrived at the location and that the vehicle is available for the OTA software package, and outputting the OTA software package from the local cache storage.

[0020] In some implementations, the method includes determining whether an OTA software package for the vehicle is already stored in a local cache storage located at the location.

[0021] In some implementations, the method includes providing data indicating that the OTA software package has been provided to the vehicle at the location to a remote computing system for updating the vehicle's shadow record.

[0022] In some implementations, the method includes providing data indicating that the OTA software package has been provided to the vehicle at the location to a remote computing system for updating the vehicle's shadow record.

[0023] In some implementations, the method includes determining a confidence level of the time the vehicle is estimated to be at the location and queuing the OTA software package based on the confidence level of the time the vehicle is estimated to be at the location.

[0024] In some implementations, the method includes obtaining network traffic data associated with the network and determining, based on the network traffic data, a time period for obtaining the OTA software package over the network.

[0025] Yet another exemplary aspect of the present disclosure is directed to one or more non-transitory computer-readable media storing instructions executable by a control circuit to: acquire data indicative of a vehicle identifier associated with a vehicle and a time (hour) when the vehicle is estimated to be at a (predetermined) location; determine, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle; acquire, from a remote computing system over a network, an OTA software package for the vehicle based on the vehicle identifier; and provide the OTA software package to local cache storage located at the location before the time when the vehicle is estimated to be at the location.

[0026] Other example aspects of the present disclosure are directed to other systems, methods, vehicles, apparatus, tangible non-transitory computer-readable media, and devices for the techniques described herein.

[0027] These and other features, aspects, and advantages of various implementations 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 implementations of the present disclosure and, together with the description, serve to explain associated principles. Detailed descriptions of implementations directed to those skilled in the art are set forth herein with reference to the accompanying drawings. [Brief explanation of the drawings]

[0028] [Figure 1] 1 illustrates an example of a computing ecosystem according to an embodiment of the present disclosure. [Figure 2A] FIG. 1 illustrates a diagram of an exemplary computing architecture for a vehicle's on-board computing system, according to one embodiment of the present disclosure. [Figure 2B] FIG. 1 illustrates a diagram of an exemplary computing architecture for a vehicle's on-board computing system, according to one embodiment of the present disclosure. [Figure 2C] FIG. 1 illustrates a diagram of an exemplary computing architecture for a vehicle's on-board computing system, according to one embodiment of the present disclosure. [Figure 2D] FIG. 1 illustrates a diagram of an exemplary computing architecture for a vehicle's on-board computing system, according to one embodiment of the present disclosure. [Figure 3] 1 illustrates a diagram of an exemplary computing platform remote from a vehicle according to one embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a diagram of a computing ecosystem for providing OTA software updates for vehicles, according to one embodiment of the present disclosure. [Figure 5] 1 illustrates a diagram of an exemplary update controller according to an embodiment of the present disclosure. [Figure 6] FIG. 1 illustrates an exemplary computing ecosystem and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. [Figure 7] FIG. 1 illustrates a diagram of an example process for distributing and caching OTA software packages according to one embodiment of the present disclosure. [Figure 8] 1 illustrates an exemplary computing ecosystem and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. [Figure 9] 1 illustrates an exemplary computing ecosystem and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. [Figure 10] FIG. 1 illustrates an exemplary computing ecosystem and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. [Figure 11A] 1 shows a flowchart diagram of an exemplary method according to an embodiment of the present disclosure. [Figure 11B] 1 shows a flowchart diagram of an exemplary method according to an embodiment of the present disclosure. [Figure 11C]1 shows a flowchart diagram of an exemplary method according to an embodiment of the present disclosure. [Figure 12] 1 illustrates a diagram of an exemplary computing ecosystem having computing components according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0029] One aspect of the present disclosure relates to intelligent caching of OTA software updates for a vehicle. For example, a vehicle (e.g., a personal automobile) may be scheduled for maintenance at a service location. A computing system associated with a service depot (service station, service base) may store a data structure indicating the maintenance schedule for the service location. The computing system may retrieve data from the data structure indicating the vehicle's vehicle identifier and the time of the vehicle's appointment at the service location. The computing system may send a message to a cloud-based computing platform to request whether an OTA software package is available for the vehicle. If an OTA software update applicable to a particular vehicle exists, the vehicle may be determined to be available for the OTA software package. This situation may arise, for example, when an update to the software version running on the vehicle is made available for a particular make and model of vehicle (e.g., an infotainment software update for a 2021 model year vehicle). To determine whether an OTA software package is available for the vehicle, the computing system may provide the vehicle's identifier (e.g., VIN) to the cloud-based computing platform.

[0030] The cloud-based computing platform may respond to the request by providing an OTA software package for the vehicle. For example, an update controller of the cloud-based computing platform may be configured to deliver the OTA software package for the vehicle. Based on the vehicle identifier, the update controller may invoke one or more services that compile the OTA software package for transmission over a network to a computing system associated with a service depot.

[0031] The computing system can obtain an OTA software package for the vehicle and cache the packed OTA software in its local cache. For example, before the time the vehicle is estimated to be at its location, the computing system can provide the OTA software package to local cache storage located at a service depot. The local cache storage can maintain the OTA software package queued for delivery to the vehicle at the appropriate time when the vehicle is at the service depot. For example, the vehicle can provide a request for the OTA software package (or any available OTA update) when the vehicle arrives at the service depot. In response, the computing system can output the OTA software package from the local cache to the vehicle. The vehicle can implement the OTA software package and update software (e.g., infotainment software) running on the vehicle's computing system while at the service depot.

[0032] To maintain an accurate record of the vehicle's on-board software capabilities, a computing system associated with the service depot may alert a cloud-based computing system that an OTA software package has been delivered to the vehicle. The cloud-based computing system may update a stored shadow record of the vehicle that reflects the current state of the vehicle's implemented software, hardware, vehicle configuration, etc. This allows the cloud-based computing system to determine in future instances whether the vehicle is eligible or ineligible for a future OTA software update.

[0033] In some implementations, the computing system can cache OTA software updates based on predictions of the vehicle's future location. For example, the computing system can retrieve historical service data (e.g., past maintenance records, purchase date) and, based on this data, predict the estimated time the vehicle will arrive at a service depot. This allows the computing system to leverage available data to intelligently cache OTA software updates within a server associated with the facility without the vehicle owner / operator having to explicitly schedule an appointment.

[0034] In another example, a vehicle may be predicted to be at a future location based on the vehicle's usage pattern. For example, charging data associated with a particular vehicle may be obtained over time. The charging data may be collected while the vehicle is at a charging station, or immediately before or after charging. The charging data may indicate when and where the vehicle's battery was charged. The charging data may indicate the vehicle's charge level at the start of a charging session and at the end of a charging session. The charging data may indicate the duration of charging, the charging rate, the charging time, the charging frequency, etc. The charging data may be communicated to a remote computing platform via the vehicle or via a computing system at the charging station.

[0035] The charging data may be processed to determine vehicle / user patterns or routines that indicate a vehicle is likely to be charged at a particular charging station, on a particular day of the week, at a particular time of day, etc. For example, the computing system may process the charging data to determine the days (days) on which the user most frequently charges the vehicle and / or the charge level at which the user prefers to recharge the vehicle (e.g., a charge level below X%). Additionally or alternatively, the computing system may determine which charging stations are more frequently utilized by the vehicle for charging. This information can be used to predict when the vehicle will be at a particular charging station so that applicable OTA software updates can be cached at the charging station in the manner described herein.

[0036] In another example, the vehicle's future location may be predicted based on the vehicle's route. For example, a vehicle user may request a route from a start location to a destination. Given the route and the vehicle's current charge state (if given), the computing system may determine where and when the vehicle may need to be charged. The computing system may determine candidate charging stations along the route based on where and when the vehicle may need to be charged. The user may be presented with candidate charging stations via a user interface of the vehicle's infotainment system. In some implementations, specific candidates may be suggested to the user (e.g., visually highlighted on the UI). The user may select a candidate by providing user input (e.g., touch input) to the infotainment system. The techniques of the present disclosure may be used to cache OTA software updates for the vehicle at candidate (or selected) charging stations before the vehicle arrives. In this manner, the vehicle's future location predicted based on the vehicle's route can be used to intelligently pre-cache OTA software updates so that the vehicle can receive them while charging.

[0037] In some implementations, a computing system associated with a service depot can calibrate (adjust) the time of day to retrieve (fetch) the OTA software package over a network based on predicted network traffic. For example, the computing system can acquire network traffic data associated with the network over which the OTA software package is transmitted. The network traffic data may indicate network traffic during various time intervals throughout the day. During off-peak periods (e.g., at night), network traffic may be particularly low. Thus, the computing system can determine an appropriate time frame (time slot) to request / retrieve the OTA software package to improve downlink efficiency.

[0038] Although the above examples are described with respect to providing OTA software updates at service depots, the techniques of this disclosure are not limited to such locations. As described further herein, systems and methods for intelligently caching OTA software updates can also be implemented in production facilities, factories, charging stations, etc.

[0039] The techniques of the present disclosure may provide many technical effects and computing improvements. For example, by intelligently caching vehicle OTA software updates in accordance with the techniques described herein, a computing ecosystem (e.g., including on-board computers, cloud platforms, etc.) can avoid other software distribution techniques that involve high computational costs. For example, the systems and methods of the present disclosure avoid incurring large amounts of data transfer caused by fully synchronizing all available update packages and instead utilize a proactive process of on-demand package synchronization. This allows for selectively retrieving only software packages applicable to a specific vehicle that are available at a local facility, thereby saving time, bandwidth, processing power, and memory resources. Additionally, this reduces the need to distribute physical media (e.g., DVDs) to local facilities. Thus, a computing ecosystem can avoid the costly processing and inefficient read / write capabilities typically required to create and utilize such media.

[0040] The techniques of the present disclosure can improve the performance of a computing system configured to distribute software packages. For example, the computing system may obtain data indicating a vehicle identifier (e.g., VIN) associated with a vehicle and a time when the vehicle is estimated to be at a location (e.g., an appointment time at a service depot). The computing system may determine that an over-the-air (OTA) software package is available for the vehicle based on the vehicle identifier. The computing system may obtain the OTA software package for the vehicle based on the vehicle identifier over a network from a remote computing system. Prior to the time when the vehicle is estimated to be at the location, the computing system may provide the OTA software package to local cache storage located at the location. During the scheduled appointment period, the OTA software package may be provided to the vehicle for download while at the service depot.

[0041] In this way, the computing system can identify which vehicles are idle and when, allowing the computing system to select applicable OTA software packages and cache them locally for retrieval by the vehicles. By leveraging the local cache, the computing system can more efficiently distribute software packages to vehicles when they are not being driven by their owners. This ensures that OTA software packages are downloaded to the vehicle in a single session, rather than multiple sessions resulting from fluctuations in network connectivity as the vehicle is driven to various locations. The techniques of the present disclosure therefore help avoid stopping and restarting OTA software packages, leading to more computationally efficient vehicle software updates. Ultimately, keeping a vehicle's onboard software up to date can improve the vehicle's own performance, thereby increasing the reliability of the vehicle's onboard computing functions.

[0042] Additionally, as described further herein, the techniques of the present disclosure can intelligently queue OTA software packages for retrieval and / or downlink from a remote computing system. The queue can be structured in an order that avoids wasting storage resources of the local computing system. For example, in the case of a local computing system at a service depot, OTA software packages (or requests therefor) can be queued in the order in which reservations occur. As a result, (i) the local computing system is more likely to download the OTA software package for the first reservation of the day to its local cache; (ii) packages later in the download list are for later reservations; and (iii) time and bandwidth are not wasted downloading unnecessary packages.

[0043] 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 and is not intended to limit 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 can be used in combination with another embodiment to yield a still further embodiment. Accordingly, it is intended that aspects of the present disclosure cover such modifications and variations.

[0044] 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, noised, securely stored, or otherwise protected. Users may opt out of such data collection at any time.

[0045] The following description describes over-the-air (OTA) software update related techniques in the context of a vehicle for illustrative purposes. The techniques described herein may be utilized in other Internet of Things (IoT) contexts and environments. For example, a computing device may be used in place of a vehicle and vehicle computing system.

[0046] 1 illustrates an example computing ecosystem 100 according to an embodiment of the present invention. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (hereinafter also referred to 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 implementations, the user 120 may be a passenger in the vehicle. In some implementations, the computing ecosystem 100 may include a third-party (3P) computing platform 125, as described further herein. The vehicle 105 may include a vehicle computing system 200 onboard the vehicle 105. The computing platform 110, the user device 115, the third-party computing platform 125, and / or the vehicle computing system 200 may be configured to communicate with each other via one or more networks 130.

[0047] 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 allows the systems / devices to establish a secure communication channel over a secure access channel on network 130 through any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), remote procedure calls (RPC), scripted access, etc.

[0048] Computing platform 110 may include a computing system that is remote from vehicle 105. In one embodiment, computing platform 110 may include a cloud-based server system. Computing platform 110 may be associated with (e.g., operated by) an entity. For example, remote computing platform 110 may be associated with an OEM responsible for the make and model of vehicle 105. In another example, remote computing platform 110 may be associated with a service entity contracted by the OEM to operate a cloud-based server system that provides computing services to vehicle 105.

[0049] The computing platform 110 may include one or more backend services to support the vehicle 105. These services may include, for example, teleassist services, navigation / routing services, performance monitoring services, etc. The computing platform 110 may host or include one or more APIs for communicating data to or from the computing system 130 of the vehicle 105 or the user device 115.

[0050] Computing platform 110 may include one or more computing devices. For example, computing platform 110 may include control circuitry and non-transitory computer-readable media (e.g., memory). The control circuitry may be one or more processors. The control circuitry of computing platform 110 may be configured to perform various operations and functions described herein. Further description of computing hardware and components of computing platform 110 is provided herein with reference to other figures.

[0051] User device 115 may include a computing device owned by or accessible to 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 a component, such as a touchscreen, configured to perform input / output functions to receive user input and present information to user 120. User device 115 may execute one or more instructions to run an instance of a software application and present a user interface associated therewith, as described further herein. In one embodiment, the launch of a software application may initiate a user network session with computing platform 110 .

[0052] The third-party computing platform 125 may include a computing system that is remote from the vehicle 105, the remote computing platform 110, and the user device 115. In one embodiment, the third-party computing platform 125 may include a cloud-based server system. The term “third-party entity” may be used to refer to an entity different from the entity associated with the remote computing platform 110. For example, as described herein, the remote computing platform 110 may be associated with the OEM responsible for the make and model of the vehicle 105. The third-party computing platform 125 may be associated with a supplier to the OEM, a maintenance provider, a mapping service provider, an emergency provider, or other type of entity. In another example, the third-party computing platform 125 may be associated with an entity that owns, operates, manages, etc., a software application that is available on or downloaded to the vehicle computing system 200.

[0053] The third-party computing platform 125 may include one or more backend services provided by a third-party entity. The third-party computing platform 125 may provide services accessible by other systems and devices in the ecosystem 100. These services may include, for example, map services, routing services, search engine functionality, maintenance services, entertainment services (e.g., music, video, images, games, graphics), emergency services (e.g., roadside assistance, 911 support), or other types of services. The third-party computing platform 125 may host or include one or more APIs for communicating data between the third-party computing platform 125 and other systems / devices in the ecosystem 100.

[0054] Network 130 may be any type of network or combination of networks that enables communication between devices. In some implementations, network 130 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 a combination thereof, and may include any number of wired or wireless links. Communication over network 130 may be achieved, for example, via a network interface using any type of protocol, protection scheme, encoding, formatting, packaging, etc. In one embodiment, communication between vehicle computing system 200 and user device 115 may be facilitated by near field or short range communication technology (e.g., Bluetooth® Low Energy protocol, radio frequency signaling, NFC protocol).

[0055] 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 implementations, 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 implementations, vehicle 105 may be a fully autonomous vehicle or a semi-autonomous vehicle.

[0056] The vehicle 105 may include a powertrain and one or more power sources. The powertrain may include a motor (e.g., an internal combustion engine, an electric motor, or a hybrid thereof), an e-motor (e.g., an electric motor), a transmission (e.g., an automatic transmission, a manual transmission, a continuously variable transmission), a driveshaft, an axle, a differential, e-components, gears, etc. The power source may include one or more types of power source. 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 a combination of combustible fuel and electricity.

[0057] The vehicle 105 may include a cabin (interior of the vehicle). The cabin may include, for example, an area inside the vehicle 105, including a cabin for a user of the vehicle 105. The cabin of the vehicle 105 may include a seat for the user, a steering mechanism, an accelerator interface, a brake interface, etc. The cabin of the vehicle 105 may include a display device, such as a display screen associated with an infotainment system, as further described with respect to FIG. 3 .

[0058] Vehicle 105 may include a vehicle exterior. The vehicle exterior may include the exterior surface of vehicle 105. The vehicle exterior may include one or more lighting elements (e.g., headlights, brake lights, accent lights). Vehicle 105 may include one or more doors for accessing the passenger compartment, for example, by operating a door handle on the vehicle exterior. Vehicle 105 may include one or more windows, including a windshield, a driver's side window (door window), a passenger's side window, a rear window, a sunroof, etc.

[0059] Systems and components of vehicle 105 may be configured to communicate over communication channels. The communication channels may include one or more data buses (e.g., Controller Area Network (CAN)), on-board diagnostic connectors (e.g., OBD-II), or a combination of wired or wireless communication links. On-board systems may send or receive data, messages, signals, etc. to and from each other over the communication channels. The vehicle may also be configured to reference one or more protocols used to transmit data (e.g., software updates) over a charging cable, wirelessly, via short-range communication (e.g., NFC, Bluetooth), etc.

[0060] 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), an intranet, a metropolitan area network (MAN), a wide area network (WAN), or the Internet. The network may utilize layers or stacks of different technologies and protocols, 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.

[0061] 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 receive information from non-transitory computer-readable medium 140.

[0062] Certain routines and conventional components (e.g., engine) of vehicle 105 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.

[0063] Vehicle 105 may include vehicle computing system 200. As described herein, vehicle computing system 200 is onboard vehicle 105. For example, computing devices and components of vehicle computing system 200 may be housed, located, or included on or within vehicle 105. Vehicle computing system 200 may be configured to perform computing functions and operations of vehicle 105.

[0064] FIG. 2A illustrates an overview of the operating system of vehicle computing system 200. The operating system may be a layered operating system. Vehicle computing system 200 may include a hardware layer 205 and a software layer 210. Hardware layer 205 and software layer 210 may include sub-layers. In some implementations, the operating system of vehicle computing system 200 may include other layers (e.g., above, below, or between the layers shown in FIG. 2A). In one example, hardware layer 205 and software layer 210 may be standardized base layers of a vehicle's operating system.

[0065] 2B illustrates a diagram of the hardware layer 205 of the vehicle computing system 200. In the layered operating system of the vehicle computing system 200, the hardware layer 205 may reside between the physical computing hardware 215 installed in the vehicle 105 and the software (e.g., software layer 210) that operates on and within the vehicle 105.

[0066] The hardware layer 205 may be an abstraction layer that includes computing code that enables communication between software in the vehicle computing system 200 and the computing hardware 215. For example, the hardware layer 205 may include interfaces and calls that enable the vehicle computing system 200 to generate hardware-dependent instructions to the computing hardware 215 (e.g., processor, memory, etc.) of the vehicle 105.

[0067] The hardware layer 205 may be configured to support the coordination of hardware resources. The architecture of the hardware layer 205 may be service-oriented. These services may help provide the computing power of the vehicle computing system 105. For example, the hardware layer 205 may include domain computers 220 of the vehicle 105, which may host various functions of the vehicle 105, such as the vehicle's intelligent functions. The specifications of each domain computer may be tailored to the functionality and performance requirements of the services abstracted to the domain computer. For example, this may allow a particular processing resource (e.g., a graphical processing unit) to support the functionality of a central in-vehicle infotainment computer for rendering graphics to one or more display devices for navigation, gaming, etc., or to support an intelligent self-driving computer to achieve certain industry guarantees.

[0068] The hardware layer 205 may be configured to include a connectivity module 225 for the vehicle computing system 200. The connectivity module may include code / instructions for interfacing with communication hardware in the vehicle 105. This may include interfacing with, for example, a communication controller, a receiver, a transceiver, a transmitter, a port, a conductor, or other hardware for communicating data / information. The connectivity module 225 may enable the vehicle computing system 200 to communicate with other computing systems remote from the vehicle 105, including, for example, the remote computing platform 110 (e.g., an OEM cloud platform).

[0069] The architectural design of the hardware layer 205 may be configured to interface with computing hardware 215 for one or more vehicle control units 225. The vehicle control units 225 may be configured to control various functions of the vehicle 105, which may include, for example, a central exterior and interior controller (CEIC), a charge controller, or other controllers as further described herein.

[0070] Software layer 205 may be configured to provide software operations for executing various types of functions and applications for vehicle 105. FIG. 2C shows a diagram of software layer 210 of vehicle computing system 200. The architecture of software layer 210 may be service-oriented and configured to provide software for various functions of vehicle computing system 200. To that end, software layer 210 may include multiple sublayers 235A-235E. For example, software layer 210 may include a first sublayer 235A including firmware (e.g., audio firmware) and a hypervisor, a second sublayer 235B including operating system components (e.g., open source components), and a third sublayer 235C including middleware (e.g., for flexible integration with applications developed by related entities or third-party entities).

[0071] The vehicle computing system 200 may include an application layer 240. The application layer 240 may enable integration with one or more software applications 245 that are downloadable or accessible by the vehicle 105. The application layer 240 may be configured to integrate with applications developed by a variety of different entities, for example, using a container interface.

[0072] The layered operating system and on-board computing resources of the vehicle may enable the vehicle computing system 200 to collect and communicate data and operate systems implemented onboard the vehicle 105. Figure 2D shows a block diagram of example systems and data of the vehicle 105.

[0073] The vehicle 105 may include one or more sensor systems 305. A sensor system may include or be in communication with sensors in the vehicle 105 and modules for processing sensor data 310 associated with the sensors configured to acquire the sensor data 305. This may include sensor data 310 associated with the vehicle's 105 surroundings, sensor data associated with the vehicle's 105 interior, or sensor data associated with a particular vehicle function. The sensor data 310 may indicate conditions observed inside the vehicle, outside the vehicle, or in the surrounding environment. For example, the sensor data 305 may include image data, interior / exterior temperature data, weather data, data indicating the location of a user / object within the vehicle 105, weight data, movement / gesture data, voice data, or other types of data. The sensors 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 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 odometer device, or other sensors.

[0074] The vehicle 105 may include a positioning system 315. The positioning system 315 may be configured to generate location data 320 (also referred to as position data) that indicates the location (also referred to as position) of the vehicle 105. For example, the positioning system 315 may determine the location by using one or more of an inertial sensor (e.g., an inertial measurement unit, etc.), a satellite positioning system, IP address-based triangulation and / or proximity to network access points or other network components (e.g., cellular towers, Wi-Fi access points, etc.), or other suitable techniques. The positioning system 315 may determine the current location of the 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.

[0075] In one embodiment, the positioning system 315 may be configured to locate the vehicle 105 within its environment. For example, the vehicle 105 may access map data that provides detailed information about the vehicle's 105 surroundings. The map data may provide information regarding the identification and location of various roads, road segments, buildings, or other objects, lane locations and directions (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 signals (e.g., stop lights), or other traffic signal or control devices / markings (e.g., crosswalks)), or other data. The positioning system 315 may locate the vehicle 105 within the environment (e.g., across multiple axes) based on the map data. For example, the positioning system 155 may process certain sensor data 310 (e.g., LIDAR data, camera data, etc.) and match it with a map of the surrounding environment to determine the vehicle's location within that environment. The determined location of the vehicle 105 may be used by various systems in the vehicle computing system 200 or another computing system (e.g., remote computing platform 110, third-party computing platform 125, user device 115).

[0076] Vehicle 105 may include a communication system 325 configured to enable vehicle 105 (and its vehicle computing system 200) to communicate with other computing devices. Vehicle computing system 200 may use communication system 325 to communicate with remote computing platform 110 or one or more other remote computing devices over network 130 (e.g., via one or more wireless signal connections). For example, vehicle computing system 200 may utilize communication system 325 to receive platform data 330 from computing platform 110. This may include, for example, over-the-air (OTA) software updates for the operating system of vehicle computing system 200. Additionally or alternatively, vehicle computing system 200 may utilize communication unit 325 to transmit vehicle data 335 to computing platform 110. Vehicle data 335 may include any data captured in the vehicle, including, for example, sensor data 310, location data 320, diagnostic data, user input data, data indicative of the current software version or currently running applications, occupancy data, data associated with a user 120 of the vehicle 105, or any other type of data captured (e.g., acquired, accessed, generated, downloaded, etc.) by the vehicle computing system 200.

[0077] In some implementations, the communication system 325 may enable communication between one or more systems onboard the vehicle 105.

[0078] In one embodiment, the communications unit 325 may be configured to enable the vehicle 105 to communicate with and receive data from the user device 115 (shown in FIG. 1 ). The communications unit 325 may utilize various communications technologies, such as, for example, the Bluetooth® Low Energy protocol, radio frequency signaling, or other short-range or near-field communications technologies. The communications unit 325 may include any suitable components for interfacing with one or more networks, including, for example, a transmitter, a receiver, a port, a controller, an antenna, or other suitable components that may help facilitate communications.

[0079] The vehicle 105 may include one or more human-machine interfaces (HMIs) 340. The human-machine interfaces 340 may include display devices (display devices), as described herein. The display devices (e.g., touchscreens) may be viewable by a user of the vehicle 105 (e.g., user 120) located at the front of the 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 the vehicle 105 (e.g., back seat). The human-machine interfaces 340 may present content 335 via a user interface for display to the user 120.

[0080] The vehicle 105 may include multiple vehicle functions 350A-C. The vehicle functions 350A-C may be functions that the vehicle 105 is configured to perform based on detected inputs. The vehicle functions 350A-C may include one or more of: (i) vehicle comfort functions, (ii) vehicle staging functions, (iii) vehicle environment functions, (vi) vehicle navigation functions, (v) driving style functions, (v) vehicle parking functions, and (vi) vehicle entertainment functions. The user 120 may interact with the vehicle functions 250A-C through user input (e.g., adjustable input device, input to UI elements) that specifies settings for the vehicle functions 250A-C selected by the user.

[0081] Each vehicle function may include a controller 355A-C associated with that particular vehicle function 355A-C. The controller 355A-C for a particular vehicle function may include control circuitry configured to operate its associated vehicle function 355A-C. 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, the controllers 355A-C for a particular vehicle function may include or be otherwise associated with sensors that capture data indicating whether the vehicle function is turned on or off, the setting of the vehicle function, etc. For example, the sensors may be voice (audio) sensors or motion sensors. An audio sensor may be a microphone configured to capture voice input from the user 120. For example, the user 120 may provide voice commands to activate the vehicle's 105 radio function 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 the user 120. For example, the user 120 may provide a hand gesture to adjust the vehicle's 105 temperature function to lower the temperature inside the vehicle.

[0083] Controllers 355A-C may be configured to send signals to other in-vehicle systems. The signals may encode data associated with the respective vehicle functions. The encoded data may indicate, for example, function settings, timing, etc. In one example, such data may be used to generate content for presentation via display device 345 (e.g., indicating current settings). Additionally or alternatively, such data may be included in vehicle data 335 and transmitted to computing platform 110.

[0084] 3 illustrates a diagram of a computing platform 110 remote from a vehicle, according to one embodiment of the present disclosure. As described herein, computing platform 110 may include a cloud-based computing platform. Computing platform 110 may be implemented on one or more servers and may include or have access to one or more databases. In one example, computing platform 110 may be implemented using different servers based on geographic region.

[0085] In some implementations, computing platform 110 may include a layered infrastructure including multiple layers. For example, computing platform 110 may include a cloud-based layer associated with functionality such as security, automation, monitoring, and resource management. Computing platform 110 may include a cloud application platform layer associated with functionality such as charging station functionality, live traffic, vehicle functionality, and vehicle sharing functionality. Computing platform 110 may include applications and services built on these layers.

[0086] Computing platform 110 may be a modular, connected services platform that includes multiple services available to vehicle 105. In one example, computing platform 110 may include a container-based microservices mesh platform. These services may be represented or implemented as systems within computing platform 110. Computing platform 110 may also include functionality related to simulating its components, services, and subsystems. As described further herein, this may be achieved through the use of a test computing system that is part of (or at least in communication with) computing platform 110.

[0087] The computing platform 110 may include a user system 405. The user system 405 may create, store, manage, or access user profile data 410. The user profile data 410 may include multiple user profiles, each associated with a respective user 120. The user profile may indicate various information about each user 120, including the user's preferences (e.g., music, comfort settings), frequently visited / previously visited destinations, past routes, etc. The user profile may be stored in a secure database. In some implementations, when the user 120 enters the vehicle 105, the user's key (or user device) may provide a signal including a user or key identifier to the vehicle 105. The vehicle 105 may transmit data indicative of the identifier to the computing platform 110 (e.g., via its communication system 325). The computing platform 110 may look up the user profile of the user 120 based on the identifier and transmit the user profile data 410 to the vehicle computing system 200 of the vehicle 105. The vehicle computing system 200 may utilize the user profile data 410 to implement the user's 120 preferences, current and past destination locations, etc. The user profile data 410 may be updated based on information provided periodically by the vehicle 105. In some implementations, the user profile data 410 may be provided to the user device 120.

[0088] The computing platform 110 may include a remote assistance system 415. The remote assistance system 415 may provide assistance to the vehicle 105. This may include providing the vehicle 105 with information to assist with charging (e.g., charging location recommendations), remotely controlling the vehicle (e.g., AV assistance), roadside assistance (e.g., collision, flat tire), etc. The remote assistance system 415 may obtain assistance data 420 to provide its core functionality. The assistance data 420 may include information that may be useful for the remote assistance system 415 to assist the vehicle 105. This may include information related to the current state of the vehicle, the current state of the occupants, the location of the vehicle, the route of the vehicle, charge / fuel levels, incident data, etc. In some implementations, the assistance data 420 may include vehicle data 335.

[0089] The remote assistance system 415 may transmit data or command signals to provide assistance to the vehicle 105. This may include providing data indicating relevant charging locations, providing remote control commands to move the vehicle or connect to an emergency provider, etc.

[0090] Computing platform 110 may include security system 425. Security system 425 may be associated with one or more security-related functions for accessing computing platform 1110 or vehicle 105. For example, security system 425 may process security data 430 for digital key identification, data encryption, data decryption, etc. for accessing services / systems of computing platform 110. Additionally or alternatively, security system 425 may store security data 430 associated with vehicle 105. User 120 may request access to vehicle 105 (e.g., via user device 115). If the request includes a digital key for vehicle 105 as indicated in security data 430, security system 425 may provide a signal to lock (or unlock) vehicle 105.

[0091] The computing platform 110 may include a navigation system 435 that provides back-end routing and navigation services to the vehicle 105. The navigation system 435 may provide map data 440 to the vehicle 105. The map data 440 may be utilized by the positioning system 315 of the vehicle 105 to determine the location of the vehicle 105, points of interest, etc. The navigation system 435 may also provide routes to destinations requested by the vehicle 105 (e.g., via user input to the vehicle's head unit). The routes may be provided as part of the map data 440 or as separate routing data. The data provided by the navigation system 435 may be presented as content on the display device 345 of the vehicle 105.

[0092] The computing platform 110 may include an entertainment system 445. The entertainment system 445 may access one or more databases for entertainment data 450 for the user 120 of the vehicle 105. In some implementations, the entertainment system 445 may access the entertainment data 450 from another computing system associated with a third-party service provider of entertainment content (e.g., via an API). The entertainment data 450 may include media content such as music, video, game data, etc. The vehicle 105 may output the entertainment data 450 via one or more output devices (e.g., a display device, speakers, etc.) of the vehicle 105.

[0093] The computing platform 110 may include a vehicle software system 455 configured to provide one or more software updates 460 to the vehicle 105. The vehicle software system 455 may include or communicate with one or more backend services for providing the software updates 460 to the vehicle. For example, the vehicle software system 455 (or its services) may maintain or have access to a data structure (e.g., a list, a table) that indicates the current software or versions thereof that have been downloaded to a particular vehicle. The vehicle software system 455 (or its services) may also maintain a data structure that indicates software packages or versions to be downloaded by a particular vehicle. In some implementations, the vehicle computing system 200 may maintain data structures that indicate the computing hardware, charging hardware, or other hardware resources installed in a particular vehicle. These data structures may be organized by vehicle identifier (e.g., VIN) so that the computing platform 110 can perform a lookup function based on the vehicle identifier to determine the relevant software (and updates) for a particular vehicle.

[0094] When vehicle 105 is connected to computing platform 110 and available to update its software, vehicle 105 can request a software package, such as a software update, from the computing platform. Computing platform 110 can provide one or more software updates 460 to vehicle 105 as an over-the-air (OTA) software package (also referred to as an "OTA software update" or "OTA update") over network 130. An OTA software package (OTA update) may include a new version of software currently downloaded to the vehicle or a new software application to be downloaded to the vehicle.

[0095] 4 illustrates a diagram of a computing ecosystem for providing an OTA software package for a vehicle 105, according to one embodiment of the present disclosure. FIG. 4 illustrates a portion of a computing platform 110, such as, for example, a vehicle software system 455. To coordinate the delivery of software updates 460 (e.g., OTA updates) to the vehicle, the computing platform 110 (e.g., vehicle software system 455) may include a remote update controller system 500. The remote update controller system 500 is also referred to herein as an update controller 500. The update controller 500 may be configured to act as an orchestrator of the OTA software package as well as a point of contact for the vehicle 105 when obtaining the OTA software package.

[0096] Update controller 500 may include and communicate with various systems / components to coordinate the delivery of OTA software packages. Figure 5 shows a diagram of update controller 500 and other systems with which update controller 500 may communicate to coordinate the delivery of OTA software packages. Figure 5 may represent update controller 500 and its ecosystem in an actual, live (real-world) environment for delivering OTA software packages to actual vehicles.

[0097] The update controller 500 may be implemented on a cloud computing infrastructure 505, which may include the infrastructure of the computing platform 100. The cloud computing infrastructure 505 may include underlying frameworks and components that enable the delivery of cloud computing services over a network (e.g., the Internet). The cloud computing infrastructure 505 may be provided by a cloud computing service provider. The cloud computing service provider may enable entities to access computing resources on-demand, adjust / consume resources as needed, and the like. The cloud computing infrastructure 505 may provide a foundation for deploying and running various cloud-based services, including Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

[0098] Cloud computing infrastructure 505 may include hardware, software, networking, and storage resources to support cloud-based applications, data storage, and processing. For example, cloud computing infrastructure 505 may include one or more servers. The servers may include physical or virtual machines that host and run applications, store data, and perform computational tasks in the cloud. The servers may be distributed across multiple data centers. Cloud computing infrastructure 505 may be managed and controlled through a software platform that provides functionality such as resource provisioning, monitoring, security, and automation.

[0099] The cloud computing infrastructure 505 may include storage and network resources. For example, the cloud computing infrastructure 505 may offer various types of storage options, such as object storage, file storage, and block storage. These storage resources are accessible over a network, allowing entities to store and retrieve data. The cloud computing infrastructure 505 may include networking components, such as routers, switches, and load balancers, that enable communication between different components of the cloud system. The network connections can ensure data transmission and access across distributed servers and data centers.

[0100] The cloud computing infrastructure 505 may incorporate various security measures to protect data, applications, and infrastructure from unauthorized access, data breaches, and other threats, including encryption, firewalls, access control, and security monitoring systems.

[0101] Cloud computing infrastructure 505 may utilize virtualization technology, which can enable the creation of virtual instances of servers, operating systems, and other resources, which can help provide efficient resource allocation, scalability, and isolation of different cloud tenants (users or entities) on a shared physical infrastructure.

[0102] The update controller 500 can communicate with numerous services and systems to manage the distribution of OTA updates. For example, the update controller 500 can be configured to communicate with the vehicle computing system 200 (not shown in FIG. 5 ) of the vehicle 105. The update controller 500 can receive a request (or other type of communication) generated by the vehicle computing system 500 indicating that the vehicle 105 is available for the OTA software package 515. In one example, the vehicle 105 can be considered available for the OTA software package 515 if the vehicle 105 has network connectivity to receive the package / payload associated with the OTA software package 515 and / or sufficient computing resources (e.g., processing power, memory, power, etc.) necessary to download and configure the OTA software package 515 on the vehicle 105.

[0103] The update controller 500 may communicate with one or more consumer systems 520. The consumer systems 520 may be computing systems configured to create rules 522 for distributing the OTA software packages 515.

[0104] The rules 522 may be associated, for example, with a campaign to update a specific software version on a group of vehicles (e.g., a specific vehicle model in year X) or a campaign to provide a new software package to a group of vehicles (e.g., a new in-car chatbot for finding music content). The rules 522 may define which vehicles are eligible / applicable for a software update and which OTA updates 515 should be provided to the eligible vehicles. For example, the rules 522 may be a combination of characters, text strings, etc. that explicitly describe the intent to distribute a given OTA update 515 to a specific set of vehicles.

[0105] A "task" may represent an instance of a rule 522 that is applied to an individual vehicle 105. For example, when the vehicle 105 communicates with the update controller 500, the update controller 500 notifies the vehicle 105 of a task, which the vehicle computing system 200 executes. A task may include actions that the vehicle 105 should perform to implement the OTA software package 515. This may include, for example, downloading a software update package over a network, updating / changing the configuration of components of the vehicle 105, etc.

[0106] The consumer system 520 can automatically create the rules 522 or allow for manual creation of the rules 522. For example, the consumer system 520 can be configured to automatically create the rules 522 when the OTA software package 515 is validated, deployed, posted, or made available for distribution. Additionally or alternatively, the consumer system 520 can include a display device configured to present a user interface to a user of the consumer system 520. The user interface can allow the user to provide user input for creating the rules 522.

[0107] The update controller 500 can communicate with one or more external software services 525 to facilitate delivery of the OTA software package 515 in accordance with the rules 522. The external software services 525 are sometimes referred to herein as “dependencies” 525. The external software services 525 may include platform-based systems such as back-end software services (e.g., microservices). The external software services 525 may include services that process or maintain information that may be useful in determining whether a rule 522 applies to a particular vehicle 105 and what actions the vehicle 105 should take to implement the OTA software package 515 associated with the rule 522. In one example, the dependencies 525 may include a vehicle call service that maintains / accesses one or more data structures including the vehicle identification numbers (VINs) of all vehicles. The dependencies 525 may include a vehicle configuration service configured to access the vehicle configuration of each vehicle as well as external data associated therewith. In another example, the dependencies 525 may include a vehicle documentation (VDOC) service. The VDOC service may include an external vehicle metadata service that maintains a record of each current and / or past configuration for each respective vehicle, as well as any documentation (e.g., required by regulation).

[0108] The update controller 500 may include one or more services, components, systems, etc. configured to assist in orchestrating the OTA software package. For example, the update controller may include a vehicle service 530 that responds to traffic from the vehicle 105. For example, the vehicle service 530 may be configured to receive a request 510 for an OTA software package 515 from the vehicle 105. The request 510 may include data indicating that the OTA software package is available to the vehicle 105, if an OTA software package is available for the vehicle 105. In some implementations, the request 515 may be an explicit request for a particular (or any) OTA software package 515. The vehicle service 530 may be configured to respond to the request 510 with a payload indicating the OTA software package 515 and an action to be taken by the vehicle 105 to implement the OTA software package 515.

[0109] The update controller 500 may include one or more controller components 535. The controller component 535 may be a software service configured to map rules and actions to vehicle-specific tasks and perform some other related responsibilities. For example, the controller component 536 may be configured to communicate with external software services 525 or to determine which external software services 525 to communicate with to gather information for a particular OTA software package 515. This can help the update controller 500 determine the action that the vehicle 105 should take with respect to a particular OTA software package 515. The controller components 535 may include, for example, a rule service (e.g., a microservice for evaluating rules), a response service for evaluating vehicle inventory, a device service, a data synchronization service, etc.

[0110] Update controller 500 may include management service 540 configured to expose an interface through which consumer systems 520 interact with update controller 500. Management service 540 may be configured to access data indicative of rules 522 and interact with controller component 535 to advance rules 522 within the ecosystem. For example, management service 530 may be configured to coordinate with the rest of the update controller ecosystem such that when vehicle service 530 receives request 510 from vehicle 105 that meets (qualifies for) the requirements of OTA software package 515, vehicle service 530 can notify vehicle 105 of actions it needs to take to implement OTA software package 515.

[0111] As an example, the management service 540 may obtain rules 522 for distributing the OTA software package 515, such as "all 2021 models will be upgraded to navigation version 6.1.6." The update controller 500 (e.g., via the controller component 535) may communicate with an external software service 525, from which the update controller 525 may obtain information about the vehicle 105 for properly implementing the OTA software package 515 according to the rules 522. The update controller 500 may package the collected information about the target vehicle 105 and output such information to the vehicle 105 via the vehicle service 530, so that the vehicle computing system 200 (onboard the vehicle 105) can take appropriate action to implement the OTA software package 515.

[0112] 5 illustrates services and systems that may be utilized to communicate an OTA software package 515 to a vehicle 105 based on a request from the vehicle 105, the techniques of this disclosure enhance these services / systems to intelligently determine that an OTA software package may be available to the vehicle 105 (without an explicit request from the vehicle) and communicate the OTA software package 515 to a computing system at a physical facility where the vehicle 105 is expected to be available. This may enable the vehicle 105 to download the OTA software package 515 via local cache storage located at the facility when the vehicle may be idle (e.g., not being utilized by its owner). As described further herein, this may improve the reliability and efficiency of delivering OTA software packages to vehicles.

[0113] 6 illustrates an exemplary computing ecosystem 600 and data flow diagram for caching OTA software packages, according to one embodiment of the present disclosure. As described further herein, the computing ecosystem 600 of FIG. 6 may be used in association with a service station / depot for vehicles. Such locations are not limiting, and other types of locations and facilities may utilize the present technology, even if described.

[0114] The computing ecosystem 600 may include a local computing system 605 and a remote computing system 610. The components, systems, and subsystems of Figure 6 may be implemented as modules on computing hardware.

[0115] The local computing system 605 may be associated with a particular location. For example, at least a portion of the local computing system 605 may be located within / on the entity's physical premises. This may include a service location (e.g., a service depot), a dealership, a vehicle distribution facility, a vehicle manufacturing center, a manufacturing facility (e.g., a factory), a charging station, or other place / entity for providing maintenance and other services to vehicles. The local computing system 605 may include a reservation scheduling system 615 and a local package repository 620. In one example, one or both of the reservation scheduling system 615 or the local package repository 620 may be part of the local computing system 605 located within the entity's physical premises (e.g., hosted on a server, database, etc. located at a service depot).

[0116] The remote computing system 610 may be remote from a particular location associated with the local computing system 605. For example, the remote computing system 610 may be, be included within, or include the computing platform 110. In some implementations, the remote computing system 610 may include the update controller 500. One or more of the components / subsystems of the remote computing system 610 described and shown in FIG. 6 may be implemented within the update controller 500.

[0117] The computing ecosystem 600 may be configured to implement a data flow process for intelligently caching OTA software packages using the local computing system 605. For example, the appointment scheduling system 615 may generate an appointment for the vehicle 105 to undergo maintenance at a service depot. The appointment may be generated in response to a reservation request (e.g., by an owner / user of the vehicle 105) or automatically based on historical service data for the vehicle 105.

[0118] Historical service data may indicate a history of maintenance and service performed on the vehicle 105. The appointment scheduling system 615 may analyze this data to predict / determine when it is preferable for the vehicle 105 to be serviced next. This may be determined based on the vehicle's 105's expected mileage since its last service, its purchase, etc. Additionally or alternatively, this may be determined based on previous service provided (or not provided) to the vehicle 105 during its last service.

[0119] In some implementations, the reservation scheduling system 615 may trigger a notification indicating the scheduled reservation. The notification may be sent to the user device 115 of the user 120 of the vehicle 105. In some implementations, the notification may be sent to the vehicle computing system 200 for the vehicle 105. The notification may be displayed to the user 120 (e.g., on a display device). In some implementations, the reservation may be confirmed, rejected, or modified by the user 120 providing user input in response to the notification. Data indicating the confirmation, rejection, and / or modification may be provided to the reservation scheduling system 615.

[0120] The appointment scheduling system 615 may provide a pre-notification 625 to the local package repository 620. The pre-notification 625 may indicate the date and location of the appointment (or predicted appointment). The pre-notification 625 may indicate the estimated time the vehicle 105 will be at the location (e.g., a service location). The pre-notification 625 may indicate a vehicle identifier associated with the vehicle 105. The vehicle identifier may include, for example, a vehicle identification number.

[0121] A download coordinator 635 of the local package repository 620 may obtain the advance notification 625. The download coordinator 635 may be configured to determine whether there are any over-the-air (OTA) software packages available for the vehicle 105. For example, the download coordinator 635 may process the advance notification 625 to parse or otherwise identify a vehicle identifier for the vehicle 105. The download coordinator may determine that an OTA software package is available for the vehicle based on the vehicle identifier.

[0122] To do so, the download coordinator 635 may communicate with the remote computing system 610. For example, the download controller 635 may send vehicle metadata 640 to a package resolver 645 of the remote computing system 610. The vehicle metadata 640 may indicate a vehicle identifier for the vehicle 105. In some implementations, the vehicle metadata 640 may include an estimated time that the vehicle 105 is expected to be at the location.

[0123] The package resolver 645 may be configured to process the vehicle metadata 640 and determine whether any OTA software packages are applicable to the vehicle 105. For example, the package resolver 645 may include or be in communication with the update controller 500, which may utilize the vehicle identifier to determine whether any OTA software packages are available or will be available for the vehicle 105. This may include, for example, invoking one or more external services 525 as described herein. In some implementations, the package resolver 645 may utilize the estimated time that the vehicle 105 will be at a service location to determine whether any OTA software packages that are not currently available may become available before the estimated arrival time of the vehicle 105 at the service location. This may include, for example, any OTA updates that are pending or in beta testing but are scheduled for production deployment before the estimated time that the vehicle 105 will be at the location.

[0124] The package resolver 645 can communicate associated package metadata 650 to the local package repository 620. The associated package metadata 650 can include information about one or more OTA software packages available for the vehicle 105. The metadata can include identifiers, such as names, links, reference numbers, serial numbers, filenames, strings, and the like, associated with the OTA software packages. This can include, for example, an identifier associated with an OTA software package for updating the software version of an infotainment system installed in the vehicle 105. The associated package metadata 650 can include a vehicle identifier associated with the vehicle 105.

[0125] The download coordinator 635 may receive the associated package metadata 650. The download coordinator 635 may be a module configured to generate instructions for queuing data payloads for the vehicle 105. In one example, the download coordinator 635 may generate prioritized download work items 655 based on the associated package metadata 650. The prioritized download work items 655 may be units passed through a workflow instance (e.g., an execution of a workflow model) associated with the download coordinator 635. The prioritized download work items 655 may include the data on which the instance operates, references associated with underlying workflow steps, etc. The download coordinator 635 may process the associated package metadata 650 to identify the vehicle 105 and applicable OTA software updates (e.g., via a vehicle identifier), and then generate the prioritized download work items 655 to reflect this information in a manner processable by downstream actors in the workflow. Additionally, the prioritized download work items 655 may include a time associated with the vehicle 105. This may indicate when (time of day) the vehicle 105 is scheduled or predicted (estimated) to be at (present) a particular location associated with the local computing system 605 .

[0126] The download coordinator 635 may communicate the prioritized download work items 655 to the download queue 660. The download queue 660 may be configured to process the prioritized download work items 655 to determine where to place them in the queue. Each prioritized download work item 655 may be stored in association with a respective vehicle identifier.

[0127] The queue may indicate an order, priority, etc. for each of the prioritized download work items 655 stored in the queue to be downloaded from the remote computing system 610. For example, the prioritized download work items 655 may be queued in the order in which their associated vehicles arrive at a particular location (e.g., a service depot). Additionally or alternatively, the prioritized download work items 655 may be queued based on their associated OTA software updates. For example, the more vehicles that have a particular OTA software update applied, the higher the associated prioritized download work item 655 may be placed in the queue. The number of vehicles that have the OTA software update applied can be determined based on the associated package metadata 650 (e.g., by the download coordinator 655) or the prioritized download work items 655 (e.g., by the download queue).

[0128] In some implementations, OTA software packages can be queued based on a confidence that the vehicle 105 will arrive at its location at the scheduled / estimated time. The local computing system 605 (e.g., download coordinator 635) can determine a confidence level for the estimated time that the vehicle 105 will be at its location and queue the OTA software packages (e.g., work items, requests therefor) based on that confidence level.

[0129] For example, in the case of scheduled appointments, the confidence may be determined based on historical data indicating arrival times, delays, cancellations, etc. of appointments associated with the vehicle 105. If appointments associated with the vehicle 105 are frequently canceled, there may be less confidence that the vehicle 105 will arrive at the estimated time, and the prioritized download work item 655 may be placed or moved lower in the queue. If the vehicle 105 has a history of arriving at the service depot on time (and rarely cancels appointments), there may be more confidence in the estimated time, and the prioritized download work item 655 may be moved higher in the download queue 660.

[0130] If the appointment is scheduled based on a predicted need for service, the confidence can be based on the confidence level in the prediction. For example, the local computing system 605 may determine its service prediction based on various signals. Particular signals may provide a stronger indication that the vehicle 105 should be serviced and therefore will arrive at a particular location. This may include, for example, the time since the last service and the predicted distance traveled based on the distance traveled in the previous service. If the predicted time is based on these stronger signals, the confidence may be higher.

[0131] The download coordinator 635 and / or the download queue 660 may communicate with a download manager 665. The download manager 655 may include control circuitry configured to request associated OTA software packages and to receive the OTA software packages in response to the request. The download manager 655 may access (e.g., receive, pull, look up, invoke, retrieve, read, or communicate from) the download queue 660 to determine the vehicle 105 and available OTA software packages for the vehicle 105 (e.g., based on a vehicle identifier).

[0132] Based on the information (e.g., priority, order, etc.) in the download queue 660, the download manager 655 can access the relevant OTA software packages. By way of example, the download manager 665 can access the download queue 660 to obtain data indicating a vehicle identifier associated with the vehicle 105 and information associated with the OTA software packages (e.g., their identifiers) available for the vehicle 105. As described herein, this information can be stored in prioritized download work items 655 in the download queue 660.

[0133] In some implementations, the download manager 665 can determine whether an OTA software package for the vehicle 105 is already stored in a local cache storage 670 located at a location associated with the local computing system 605. For example, the download manager 665 can utilize information associated with the OTA software package (e.g., its identifier) ​​to query the local cache storage 670 to determine whether the OTA software package is already stored in the local cache storage 670. In some implementations, this can include accessing a lookup table that indicates the OTA software packages stored in the local cache storage 670. If the local cache storage 670 contains the relevant OTA software package for the vehicle 105, the download manager 665 can forgo communicating with the remote computing system 610 to request the OTA software package.

[0134] In some implementations, the download manager 665 can communicate a request 675 for an associated OTA software package to the remote computing system 610. This may occur, for example, if the OTA software package has not yet been downloaded to the local cache storage 670. The download manager 665 can generate the request 675 based on information associated with the OTA software package included in the download queue. This may include associated package metadata 650 and / or an identifier associated with the OTA software package that can be used by the remote computing system 610 to access the OTA software package.

[0135] In one example, the remote computing system 610 may include a central package repository 680. The central package repository 680 may be configured to return an associated OTA software package 685 based on the request 675. For example, the remote computing system 610 may be configured to access (e.g., query) the central package repository 680 using the associated package metadata 650 (and / or other information associated with the associated OTA software package) to obtain the OTA software package 685. The remote computing system 610 may be configured to communicate the OTA software package 685 over a network to a download manager 665. The download manager 665 may be configured to obtain the OTA software package 685 for the vehicle 105 from the remote computing system 610 over the network.

[0136] In some implementations, the local computing system 605 may be configured to shape downlink bandwidth for retrieving the OTA software package 685 from the remote computing system 610. In one example, the download manager 665 may be configured as a downlink bandwidth shaper. The download manager 665 may obtain network traffic data associated with the network utilized for communication between the local computing system 605 and the remote computing system 610. The network traffic data may indicate historical, current, or future estimates of the network's available bandwidth, speed, outages, maintenance, and the like for each of one or more time periods (time slots) of a day. The download manager 665 may determine a time period for retrieving the OTA software package 685 over the network based on the network traffic data. As an example, the download manager 665 may determine based on the network traffic data that network bandwidth and download speeds are higher between 1:00 AM and 3:00 AM EST and / or that it is less expensive (e.g., monetarily, computationally) to retrieve the OTA software package 685 from the remote computing system 610 during this time period. Thus, the download manager 665 may send the request 675 between 1:00 AM and 3:00 AM EST to have the OTA software package 685 provided by the remote computing system 610 during this time period.

[0137] In some implementations, the download manager 665 can send the request 675 during a time period other than 1:00-3:00 AM EST, and the request 675 can indicate a preferred time period (e.g., 1:00-3:00 AM EST) during which the download manager 665 desires to obtain the OTA software package 685. In this way, the download manager 665 can send lighter (e.g., smaller data size) requests 675 during times of higher network traffic, while heavier (e.g., larger data size) OTA software packages 685 can be received during times of lower network traffic.

[0138] Prior to a time when the vehicle 105 is estimated to be at a particular location associated with the local computing system 605, the download manager 665 may provide and store the OTA software package 685 in the local cache storage 670. The OTA software package 685 may be stored in association with a vehicle identifier associated with the vehicle 105.

[0139] This can ensure that the associated OTA software package 685 is available to the vehicle 105 when the vehicle 105 is in a location associated with the local computing system 605.

[0140] The OTA software package 685 may be accessed by the software update system 690 when the vehicle 105 is at a particular location. For example, the software update system 690 may determine that the vehicle 105 has arrived at the location and that the OTA software package 690 is available for the vehicle 105. The vehicle 105 (and / or another system) may provide a communication indicating that the vehicle 105 is ready for any available OTA software package, that the vehicle 105 will be available for downloading the OTA software package for a particular period of time, that the vehicle 105 is connected to a local network (e.g., wired or wireless) so that it can receive the OTA software package, a vehicle identifier associated with the vehicle 105, or other information. In some implementations, the software update system 690 may determine that the period of time that the vehicle 105 is available for download is long enough to download the OTA software package 685 from the local cache storage 670 at that location (e.g., taking into account available bandwidth, network speed, etc.).

[0141] The software update system 690 can output at least a portion of the OTA software package 685 from the local cache storage 670. For example, this can include a software update that updates a version of software currently downloaded to the vehicle 105, or a new application that is added to the vehicle computing system 200.

[0142] In some implementations, the remote computing system 610 may maintain a data shadow record 695 of the vehicle 105. The data shadow record 695 may include a data structure (e.g., a list, a table, a vehicle model) indicating the current software version installed on the vehicle 105, a software update history, locations where OTA software packages were provided to / downloaded by the vehicle 105, etc. The remote computing system 610 may store the data shadow record 695 in a memory configured to allow the shadow record 695 to be read, written, updated, etc. The remote computing system 610 may include multiple shadow records, each associated with a different vehicle. The local computing system 605 (e.g., a download manager) can provide data to the remote computing system 610 indicating that an OTA software package 685 was provided to the vehicle 105 at a particular location for updating the data shadow record 695 of the vehicle 105.

[0143] In some implementations, the local computing system 605 can adjust the service schedule for the vehicle 105 based on the OTA software update 685. By way of example, the local computing system 605 (e.g., download coordinator 635, download manager 665) can determine that the OTA software package 685 is too large to be downloaded to the vehicle 105 within the currently scheduled time frame (e.g., 30 minutes) for the vehicle 105 to be at the location. In response, the local computing system 605 (e.g., appointment scheduling system 615) can adjust the service schedule to extend the appointment or reschedule the appointment to another time slot and / or day that provides sufficient time (e.g., 60 minutes) for the vehicle 105 to download the OTA software package 685.

[0144] In some implementations, the local computing system 605 may take into account schedule changes. This may include, for example, reservation cancellations, last-minute changes, etc. The local computing system 605 may model a compensation mechanism that may unschedule the download of the OTA software package 685, assuming that the download of the OTA software package 685 has not yet started / completed. In some implementations, the OTA software package 685 may be removed (deleted) from the local cache storage 670. This may occur, for example, when a reservation has been canceled and not yet rescheduled, resulting in uncertainty as to when the vehicle 105 will be at (arrive at) a particular location (e.g., a service deport), and the OTA software package 685 is not associated with another vehicle scheduled or predicted to be at that location.

[0145] In some implementations, the local cache may be managed based on cache expiration using a time to live (TTL). For example, the TTL may identify the length of time an OTA software package is available from the local cache 670. The TTL may be reset and / or increased each time an additional vehicle is identified as being applicable for the OTA software package. For example, the TTL associated with a particular OTA software package may be "bumped" when a vehicle for which the OTA software package is applicable is determined / predicted to be at the location of the local computing system 605. Additionally or alternatively, the TTL associated with a particular OTA software package may be "bumped" when a vehicle begins downloading the OTA software package via the local cache 670.

[0146] The local cache 670 may be purged to allow a newer OTA software package to be included in the local cache 670. For example, a newer version of an OTA software package may be identified / requested for download within the local cache 670. Purging the local cache 670 signals the local cache 670 to stop serving cached objects associated with an older OTA software package in response to a request from the vehicle and instead retrieve new objects, such as a new OTA software package. This may help to better manage the limited resources of the local cache 670.

[0147] 7 illustrates a diagram of an example process 700 for distributing and caching an OTA software package according to one embodiment of the present disclosure. For example, at 705, the local computing 605 may receive a vehicle reservation notification. The vehicle reservation notification may be generated based on a reservation being scheduled (and / or predicted) for the vehicle 105 at a service location. In some implementations, the vehicle reservation notification may be generated in response to a user (e.g., owner) associated with the vehicle 105 confirming or scheduling a reservation (e.g., via a user device).

[0148] The local computing system 605 may obtain data indicating a vehicle identifier associated with the vehicle 105 and the estimated time the vehicle 105 will be at its location (e.g., a service location). This information may be retrieved from an accessible database of VINs and included in the notification.

[0149] At (710), the local computing system 605 may identify any required update packages for the vehicle 105. For example, the local computing system 605 may determine that an OTA software package 685 is available for the vehicle 105 based on a vehicle identifier. To do so, the local computing system 605 may communicate the vehicle identifier to the remote computing system 610. The remote computing system 610 may determine (e.g., using the package resolver 645) whether there is an OTA software package available for the vehicle 105. As described herein, this may include OTA software packages that are targeted to the make and model of the vehicle 105 (e.g., infotainment software version updates) and that have not yet been downloaded to the vehicle 105. The local computing system 605 may obtain a communication from the remote computing system 610 indicating the available OTA software package(s) (e.g., via metadata associated therewith), or lack thereof.

[0150] If there is at least one OTA software package 685 available for the vehicle 105, the local computing system 605 may determine (715) whether the associated OTA software package 685 is already cached locally. If so, the local computing system 605 may update the download manager 665 to associate (720) the vehicle identifier of the vehicle 105 with the associated OTA software package 685 in the local cache storage 670. When the vehicle 105 is at a service depot (e.g., the local computing system 605) location, the local computing system may (730) update the software on the vehicle 105 using the cached OTA software package 685. This may cause the algorithmic process 700 to terminate (735).

[0151] If the associated OTA software package 685 is not already cached locally, the local computing system 605 may fetch the associated OTA software package 685 and cache it in the local cache storage 670. The local computing system 605 may obtain the OTA software package 685 for the vehicle 105 based on the vehicle identifier over the network from the remote computing system 610. For example, as described herein, the local computing system 605 may use the vehicle identifier of the vehicle 105 (e.g., at 710) to determine that there is at least one OTA software package 685 available for the vehicle 105. This may include the local computing system 605 receiving metadata indicating the OTA software package 685. In some implementations, the local computing system 605 may then provide a request 675 for the OTA software package 685 to the remote computing system 610. The request 675 may include metadata indicating the OTA software package 685 and / or the vehicle identifier. In response to the request, the local computing system 605 may receive the OTA software package 685. Prior to the time that the vehicle 105 is estimated to be at the location (e.g., a service depot), the local computing system 605 can provide the OTA software package 685 to local cache storage 670 stored on computing hardware physically located at the location.

[0152] At 730, the local computing system 605 may update software on the vehicle 105 using the OTA software package 685 received from the remote computing system 610. The local computing system 610 may determine that the vehicle 105 has arrived at its location and that the OTA software package 685 is available to the vehicle 105. In some implementations, to make such a determination, the local computing system 605 (e.g., the software update system 690) may obtain a request generated by the vehicle 105 for the OTA software package 685. The request may indicate a specific OTA software package 685 and / or more generally request any OTA software package associated with / available to the vehicle 105. Additionally or alternatively, the local computing system 605 may determine that the vehicle 105 has connected to the local network. The local computing system 605 may output the OTA software package 685 from the local cache storage 670. This may terminate the algorithmic process 700 at 735.

[0153] 8 illustrates an example computing ecosystem 800 and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. In this example, a local computing system 805 may be located at a vehicle manufacturing center / facility (VPC).

[0154] The local computing system 805 may include a VPC inventory management system 810. The VPC inventory management system 810 may be configured to maintain a database indicating the vehicles in the VPC as well as the status of each vehicle. In one example, the vehicles 850 may be indicated by a vehicle identifier associated with the vehicle 850, such as a VIN. The status of each vehicle may indicate the stage, state, etc. of each vehicle within the VPC. This may include, for example, a status indicating whether each vehicle is ready for delivery from a vehicle manufacturing center, whether it is ready for any software updates, the time, etc. The VPC inventory management system 810 in the VPC may store the vehicle identifier of the vehicle 850 in a data structure associated with the status of the vehicle 850. The VPC inventory management system 810 may provide notifications 815 indicating the status of the vehicle 105 and the vehicle 850 within the VPC (e.g., using the vehicle identifier).

[0155] The local computing system 805 may predict the time when the vehicle 850 is estimated to be ready for the OTA software package in the VPC based on the status of the vehicle 850. For example, the local computing system 805 may determine that the vehicle 850 is in the final stages of the VPC and therefore is ready to download the associated OTA software package immediately.

[0156] The local computing system 805 may include a local package repository 820. The local package repository 820 may include or be associated with a download manager configured to request relevant OTA software packages for the vehicle 850 in the VPC. To that end, the download manager may communicate a request 825 to the remote computing system 610. The request 825 may include a vehicle identifier and / or data indicative of the relevant OTA software package (e.g., associated package metadata, a reference number, or other identifier). The central package repository 680 may return OTA software packages 830 that are available and applicable to the vehicle 850. The OTA software packages 830 may include one or more software updates for one or more software applications installed on the vehicle 830. Additionally or alternatively, the OTA software packages 830 may include new software applications for the vehicle 830 that are not currently downloaded to the vehicle 830. In some implementations, the OTA software packages 830 may include software updates / packages requested, authorized, purchased, etc. by a user of the vehicle 850.

[0157] The local computing system 805 can provide the OTA software package 830 to local cache storage associated with the local package repository 830. This can occur before the vehicle 850 is ready to download the OTA software package 830, or at least a portion thereof.

[0158] The local computing system 805 can include a vehicle software update system 835 that can manage the delivery of the OTA software update 830 to the vehicle 850. For example, the local computing system 805 can generate instructions for the vehicle software update system 835 to provide the OTA software package 830 (or a portion thereof) to the vehicle 850 for download. In some implementations, the vehicle software update system 835 can detect that the vehicle 850 is available for an update (e.g., because the vehicle 850 is connected to a network, a notification from another system, a request / notification from the vehicle 850) and can instruct the provision of the OTA software package 830 (or a portion thereof) to the vehicle 850.

[0159] The shadow record of the vehicle 850 at the remote computing system 610 may be updated after the vehicle 850 downloads the OTA software package 830. The shadow record may, at least at some point in time, indicate the state of the software suite on board the vehicle 850 when the vehicle 850 exits the VPC.

[0160] 9 illustrates an example computing ecosystem 900 and data flow diagram for caching OTA software packages according to one embodiment of the present disclosure. In this example, a local computing system 905 may be located at a facility such as a manufacturing facility.

[0161] The local computing system 905 may include a production logistics system 910. The production logistics system 910 may be configured to maintain a database indicating the vehicles at the facility as well as the status of each vehicle. In one example, the vehicle 950 may be indicated by a vehicle identifier associated with the vehicle 950, such as its VIN. The status of the vehicle 950 may indicate the stage of production, condition, etc. of the vehicle 950 within the facility. This may include, for example, a status indicating whether the vehicle 950 is ready or will be ready for any software updates, a time (hour) associated therewith, etc. The production logistics system 910 may store the vehicle identifier of the vehicle 950 in a data structure associated with the status of the vehicle 950. The production logistics system 910 may provide notifications 915 indicating the vehicle 950 and the status of the vehicle 950 within the facility (e.g., using the vehicle identifier).

[0162] The local computing system 905 can predict the time when the vehicle 950 is likely to be ready for an OTA software update at the facility based on the status of the vehicle 950. For example, the local computing system 905 can determine that the vehicle 950 is in the final stages of the facility and therefore is ready to download the associated OTA software package immediately.

[0163] The local computing system 905 may include a local package repository 920. The local package repository 920 may include or be associated with a download manager configured to request relevant OTA software packages for the vehicles 950 at the facility.

[0164] To that end, the download manager may communicate a request 925 to the remote computing system 610. As described herein, the request 925 may include data indicative of a vehicle identifier and / or an associated OTA software package (e.g., associated package metadata, a reference number, other identifiers). The central package repository 680 may return OTA software packages 930 that are available and applicable to the vehicle 950. The OTA software packages 930 may include one or more software updates for one or more software applications installed on the vehicle 930. Additionally or alternatively, the OTA software packages 930 may include new software applications for the vehicle 950 that are not currently downloaded to the vehicle 950. In some implementations, the OTA software packages 930 may include software updates / packages requested, authorized, purchased, etc. by a user of the vehicle 950.

[0165] The local computing system 905 can provide the OTA software package 930 to local cache storage associated with the local package repository 930. In some implementations, this can occur before the vehicle 950 is ready to download the OTA software package 930, or at least a portion thereof.

[0166] The local computing system 905 can include a vehicle software update system 940 that can manage the delivery of the OTA software update 930 to the vehicle 950. For example, the local computing system 905 can generate instructions for the vehicle software update system 940 to provide the OTA software package 930 (or a portion thereof) to the vehicle 950 for download. In some implementations, the vehicle software update system 940 can detect that the vehicle 950 is available for an update (e.g., because the vehicle 950 is connected to a network, a notification from another system, or a request from the vehicle 950) and can instruct the provision of the OTA software package 930 (or a portion thereof) to the vehicle 950.

[0167] The shadow record of the vehicle 950 at the remote computing system 610 may be updated after the vehicle 950 downloads the OTA software package 930. The shadow record may, at least at some point in time, indicate the state of the software suite on board the vehicle 950 when the vehicle 950 leaves the facility.

[0168] 10 illustrates an example computing ecosystem 1000 and data flow diagram for caching an OTA software package according to one embodiment of the present disclosure. In this example, a local computing system 1005 may be located at a charging station.

[0169] The local computing system 1005 may include a charger reservation system 1010. The charger reservation system 1010 may be configured to maintain a database indicating vehicle reservations / assignments to chargers at charging stations. In one example, the vehicle 1050 may be indicated by a vehicle identifier associated with the vehicle 1050, such as its VIN. The charger reservation may be reflected as a data entry in a data structure (e.g., a table) indicating the VIN of the vehicle 1050 in association with the charger's identifier. The reservation may also indicate the time (hour) that the vehicle is utilizing the charger.

[0170] In some implementations, the charger reservation system 1010 can maintain a data structure that indicates that a vehicle 1050 is present / expected to arrive at a charging station even if it has not been assigned a specific charger.

[0171] In some implementations, the reservation is made automatically by a computing system (e.g., computing platform 110) based on a user's selection of a charging station or another type of request for a reservation.

[0172] In some implementations, a reservation can be made based on a prediction that a vehicle can be charged at a charging station at a future time. As described herein, this prediction can be based on a vehicle usage pattern that indicates that a vehicle user typically charges the vehicle when the vehicle reaches a particular charge level. Additionally or alternatively, the charging station can be an identified candidate for charging the vehicle as the vehicle travels along a particular route.

[0173] The local computing system 1005 can predict the time at which the vehicle 1050 is estimated to be ready for an OTA software update at the charging station. For example, the local computing system 1005 can determine that the vehicle 1050 is ready to download the associated OTA software package as soon as the vehicle 1050 is connected to a charger (e.g., via a communications link for data transfer included in the charging connector).

[0174] The local computing system 1005 may include a local package repository 1020. The local package repository 1020 may include or be associated with a download manager configured to request relevant OTA software packages for the vehicles 1050 at the facility.

[0175] To that end, the download manager may communicate a request 1025 to the remote computing system 610. As described herein, the request 1025 may include data indicative of a vehicle identifier and / or an associated OTA software package (e.g., associated package metadata, a reference number, other identifiers). The central package repository 680 may return OTA software packages 1030 that are available and applicable to the vehicle 1050. The OTA software packages 1030 may include one or more software updates for one or more software applications installed on the vehicle 1030. Additionally or alternatively, the OTA software packages 1030 may include new software applications for the vehicle 1050 that are not currently downloaded to the vehicle 1050. In some implementations, the OTA software packages 1030 may include software updates / packages requested, authorized, purchased, etc. by a user of the vehicle 1050.

[0176] The OTA software package 1030 may be sized to allow the vehicle 1050 to download the OTA software package 1030 while the vehicle 1050 is charging, taking into account the download speed of the vehicle's 1050 data connection to the local computing system 1005. The charging time may be determined based on the vehicle's 1050 projected charge level when the vehicle 1050 arrives at the charging station and the speed of the assigned charger. The download manager may provide data indicative of the charging time to the remote computing system 610, which may be configured to select the OTA software package 1030 based on the charging time. This may help ensure that the OTA software package 1030 provided to the vehicle 1050 is available for download within the time the vehicle 1050 is charging.

[0177] The local computing system 1005 can provide the OTA software package 1030 to local cache storage associated with the local package repository 1030. In some implementations, this can occur before the vehicle 1050 is ready to download the OTA software package 1030, or at least a portion thereof.

[0178] The local computing system 1005 can include a vehicle software update system 1040 that can manage the delivery of the OTA software update 1030 to the vehicle 1050. For example, the local computing system 1005 can generate instructions for the vehicle software update system 1040 to provide the OTA software package 1030 (or a portion thereof) to the vehicle 1050 for download. In some implementations, the vehicle software update system 1040 can detect that the vehicle 1050 is available for an update (e.g., the vehicle 1050 begins charging, connects to a network via a charger / wirelessly, a notification from another system, a request from the vehicle 1050, etc.) and instruct the vehicle 1050 to provide the OTA software package 1030 (or a portion thereof).

[0179] The shadow record of the vehicle 1050 at the remote computing system 610 may be updated after the vehicle 1050 downloads the OTA software package 1030. The shadow record may indicate, at least at some point in time, the state of the software suite on board the vehicle 1050 after the OTA software package 1030 is downloaded, when the vehicle 1050 finishes charging, when the vehicle 1050 leaves a charging station, etc.

[0180] 11A-11C illustrate flowchart diagrams of an exemplary method for delivering an OTA software package to a local cache according to one embodiment of the present disclosure. The method may be performed by a computing system described with reference to other figures (e.g., FIGS. 1-10, 12). In one embodiment, the method may be performed by control circuitry of the computing system. One or more portions of the method may be implemented as an algorithm on hardware components of a device described herein. For example, the steps of the method may be implemented as operations / instructions executable by computing hardware. This may include one or more non-transitory computer-readable media storing instructions executable by control circuitry to perform the operations of FIGS. 11A-11C.

[0181] 11A-11C show elements performed in a particular order for purposes of illustration and explanation. Those skilled in the art will understand, using the disclosure provided herein, 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.

[0182] 11A-11C are described with reference to elements / terminology described with respect to other systems and figures, for example, for illustrative purposes and not meant to be limiting. One or more portions of the method may additionally or alternatively be performed by other systems.

[0183] In one embodiment, method 1100 may begin or otherwise include operation 1105, in which a computing system may obtain data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location (and / or ready for package download). For example, local computing system 605 may obtain a vehicle identifier (e.g., a VIN) associated with vehicle 105 and data indicating a time when vehicle 105 is estimated to be at a location associated with local computing system 605 (and / or ready for package download).

[0184] In one example, the location associated with the local computing system may be a service location. The local computing system 605 may obtain data indicative of a scheduled service for the vehicle 105. The local computing system 605 may determine, based on the scheduled service for the vehicle 105, an estimated time that the vehicle 105 will arrive at the service location. The data indicative of the scheduled service may be a reservation notice that includes a vehicle identifier for the vehicle 105.

[0185] Additionally or alternatively, the local computing system 605 may obtain historical service data associated with the vehicle 105. The historical service data may indicate past maintenance or service records for the vehicle 105, services that have not yet been completed, dates of service, type of service, etc. The local computing system 605 may predict an estimated time that the vehicle 105 will arrive at a service location based on the historical service data associated with the vehicle 105. For example, the historical service data may indicate that the vehicle 105 had an oil change 14 months ago and that, at that time, the vehicle had driven 24,000 miles. The historical service data may indicate that, on average, the vehicle 105 receives an oil change every 3,000 miles and that the vehicle 105 drives approximately 200 miles per month. Thus, the local computing system 605 may determine that the vehicle 105 is estimated to arrive at a service location within the next month.

[0186] In one example, the location associated with local computing system 605 may be a charging station. For example, vehicle 105 may be an electric vehicle (EV). Local computing system 605 may be configured to obtain historical charging data associated with vehicle 105 and predict an estimated time when vehicle 105 will arrive at a charging station based on the historical charging data associated with vehicle 105. For example, the historical charging data may indicate when, where, and how often vehicle 105 charges its battery. Local computing system 605 may utilize this information to predict that vehicle 105 may arrive at a charging station within a particular time frame per week.

[0187] In one embodiment, the method 1100 may include operation 1110, in which a computing system may determine that an OTA (over-the-air) software package is available for the vehicle based on the vehicle identifier. For example, the local computing system 605 may determine that an OTA software package is available for the vehicle 105 based on a vehicle identifier associated with the vehicle 105. As described herein, this may include providing a communication to the remote computing system 610 indicating the vehicle identifier. The remote computing system 610 may access its database or the like to determine whether there is an OTA software package associated with the vehicle 105 (e.g., based on its make / model / year). The remote computing system 610 may respond to the local computing system 605 to indicate which OTA software packages, if any, are available for the vehicle 105. This may include transmitting data indicating a reference number, link, and / or another type of identifier associated with one or more OTA software packages.

[0188] In one embodiment, the method 1100 may include operation 1115, in which the computing system may determine whether an OTA software package for the vehicle is already stored in the local cache storage 670 located at that location. For example, the local computing system 605 may access its local cache storage 670 to determine whether an available OTA software package associated with the vehicle 105 is already cached locally. To do so, the local computing system 605 may generate a search query and / or perform a lookup function within the local cache using an identifier (e.g., a reference number, a serial number, a name) associated with the OTA software package. If the local cache storage 670 already contains the OTA software package, the local computing system 605 may provide instructions to associate a vehicle identifier for the vehicle 105 with the OTA software package. This may include creating a data entry, completing a data field, etc., to indicate that the OTA software package should be delivered to the vehicle 105 associated with the particular vehicle identifier.

[0189] If the OTA software package is already cached locally, the local computing system 605 may not need to request the OTA software package from the remote computing system 610.

[0190] In some instances, the OTA software package may not already be stored in the local cache storage.

[0191] In one embodiment, method 1100 may include operation 1120, in which the computing system may obtain, over a network from a remote computing system, an OTA software package for the vehicle based on the vehicle identifier. For example, local computing system 605 may provide a first communication to remote computing system 610 inquiring whether there is an OTA software package associated with vehicle 105. The first communication may include a vehicle identifier associated with vehicle 105. Remote computing system 610 may process the request and perform a lookup function using the vehicle identifier to determine the make, model, and year of vehicle 105. Remote computing system 610 may determine whether there are any outstanding OTA software packages available for vehicle 105 (e.g., for that given make, model, and year) and that have not yet been downloaded to vehicle 105.

[0192] In some implementations, the remote computing system 610 can use an identifier associated with the vehicle 105 to query a database that stores a shadow record for the vehicle 105. The remote computing system 610 can utilize the shadow record to determine whether the on-board software of the vehicle 105 is up to date and / or whether any OTA software packages are available for it. For example, the shadow record may indicate the current version of the infotainment software running on the vehicle 105. The remote computing system 610 may determine that a newer version of the infotainment software is available for the make / model / year of the vehicle 105.

[0193] In some implementations, in response to the first communication inquiring whether there are any relevant OTA software packages for the vehicle 105, the remote computing system 610 can identify the relevant OTA software packages and send them to the vehicle 105.

[0194] In some implementations, the remote computing system 610 can send data indicating an associated OTA software package to the local computing system 605. This data may be sent instead of the OTA software package itself. For example, the remote computing system 610 can send metadata indicating an OTA software package (e.g., an infotainment software update) to the local computing system 605. The metadata can include an identifier associated with the OTA software package.

[0195] The local computing system 610 can generate a second communication requesting the OTA software package. In one example, the local computing system 610 can call an API and construct the second communication according to the API to request the OTA software package from a database (e.g., a central package repository 680). The remote computing system 610 can process the structured request and return the OTA software package to the local computing system 605.

[0196] By generating separate first and second communications for identifying and then retrieving the OTA software package, respectively, technical effects and improvements may be realized by the present disclosure. For example, in response to a first communication requesting whether any relevant OTA software packages exist for the vehicle 105, the local computing system 605 may retrieve a smaller data packet that includes an identifier associated with the relevant OTA software package, rather than the package itself. This allows the local computing system 605 to store less information in a structured queue and control the timing of retrieving the actual OTA software package. By utilizing this approach, the local computing system 605 may conserve its memory resources (e.g., by storing less weighted metadata) while still ensuring that the OTA software package is cached locally for the vehicle 105.

[0197] In some implementations, the computing system can obtain the OTA software package based on network traffic associated with the network from which the OTA software package is obtained. This may include the operations of method 1180 shown in FIG. 11C . For example, at 1185, the local computing system 605 may obtain network traffic data associated with the network. This network traffic data may be obtained by calling an API of a third-party network monitoring service and sending a request for such data structured based on the API. In response, the local computing system 605 may obtain network traffic data (e.g., from the third-party computing system) indicating the network's current bandwidth, download speed, etc.

[0198] At 1190, the local computing system 605 can determine a time period for obtaining the OTA software package over the network based on the network traffic data. This time period can be a time period in which there is sufficient bandwidth, download speed, etc. to efficiently transmit the OTA software package over the network. This may also be a time period in which transmission is most cost-effective (e.g., price per MB). This configuration for evaluating the network in this manner can be reflected in the local computing system 605, which can have a model having components responsible for shaping downlink traffic.

[0199] 11A , in one embodiment, method 1000 may include operation 1125, in which the computing system may provide the OTA software package to local cache storage located at the location prior to the time the vehicle is estimated to be at the location. For example, in some implementations, local computing system 605 may provide the OTA software package to local cache storage prior to the time the vehicle 105 may request / have the OTA software package available.

[0200] In some implementations, the local computing system 605 can send a request to the remote computing system 610 at a time so that the local computing system 605 can provide the OTA software package for local cache storage before the vehicle 105 arrives at its location or is otherwise ready / able to download the OTA software package.

[0201] In some implementations, the OTA software package may be queued based on a confidence that the vehicle 105 will be at its location (e.g., a service depot, a VPC, a charging station, a factory) at the scheduled / estimated time. This may include the operations of method 1150 shown in FIG. 11B . For example, at 1155, the local computing system 605 may determine a confidence in the estimated time that the vehicle will be at / ready at its location, as described herein. The local computing system 605 may queue the OTA software package at 1160 based on the confidence in the estimated time that the vehicle will be at its location. For example, the higher the confidence that the vehicle 105 will arrive sooner, the higher in the queue the work item for downloading the OTA software package to the local cache may be.

[0202] 11A , in one embodiment, method 1100 may include operation 1130, in which a computing system may determine that a vehicle has arrived at the location and that the vehicle is available for an OTA software package. For example, local computing system 605 may obtain a request generated by vehicle 105 for an OTA software package. The request may indicate a specific package for vehicle 105 or any related packages. Additionally or alternatively, local computing system 605 may determine that vehicle 105 has arrived at the location (e.g., a charging station, a service location) based on vehicle 105 connecting to a network associated with the location. Additionally or alternatively, a computing device of vehicle 105 may broadcast its presence (e.g., via near field communication, other network communication) to local computing system 605 and / or other computing devices.

[0203] In one embodiment, method 1100 may include operation 1135, in which the computing system may output the OTA software package from the local cache storage. By way of example, local computing system 605 may provide instructions to release an OTA software update for the vehicle's infotainment software from the local cache storage. This may enable vehicle 105 to download the infotainment software update from the local cache storage rather than from a remote cloud platform.

[0204] In one embodiment, method 1100 may include operation 1140, in which the computing system may provide data to a remote computing system indicating that an OTA software package has been provided to the vehicle at the location for updating the vehicle's shadow record. By way of example, data indicating that the vehicle 105 has downloaded a software update for its infotainment system and its associated version number may be provided (e.g., stored by the remote computing system 610) to update the vehicle's shadow record. In some implementations, the shadow record may be maintained on the vehicle 105 and / or within the local computing system 605 and periodically uploaded to the remote computing system 610.

[0205] 12 illustrates a block diagram of an exemplary computing system 7000 according to one embodiment of the present disclosure. The system 7000 includes a computing system 6005 (e.g., a computing system onboard a vehicle), a remote computing system 7005 (e.g., a server computing system, a cloud computing platform, a test computing system, etc., remote from the vehicle), and a user device 8005 (e.g., a user device of a vehicle user) communicatively coupled via one or more networks 9050. The computing system 6005, the remote computing system 7005, the user device 8005, and the network 9050 may represent systems (and components of those systems) and networks described herein with reference to other figures.

[0206] The computing system 6005 may include one or more computing devices 6010 or circuitry. For example, the computing system 6005 may include control circuitry 6015 and a non-transitory computer-readable medium 6020, also referred to herein as memory. In one embodiment, the control circuitry 6015 may include one or more processors (e.g., microprocessors), one or more processing cores, a programmable logic circuit (PLC) or programmable logic / gate array (PLA / PGA), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or any other control circuitry. In some implementations, the control circuitry 6015 may be part of or form a vehicle control unit (also referred to as a vehicle controller) embedded 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 circuit 6015 may be programmed by one or more computer-readable or computer-executable instructions stored on a non-transitory computer-readable medium (non-transitory CRM) 6020.

[0207] In one embodiment, the non-transitory computer-readable medium 6020 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 6020 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.

[0208] The non-transitory computer-readable medium 6020 may store information that can be accessed by the control circuitry 6015. For example, the non-transitory computer-readable medium 6020 (e.g., a memory device) may store data 6025 that can be obtained, received, accessed, written, manipulated, created, and / or stored. The data 6025 may include, for example, any of the data or information described herein. In some implementations, the computing system 6005 may retrieve data from one or more memories that are remote from the computing system 6005.

[0209] The non-transitory computer-readable medium 6020 may also store computer-readable instructions 6030 that can be executed by the control circuitry 6015. The instructions 6030 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, where 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 6015 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 6015 or other hardware components execute the modules or computer-readable instructions.

[0210] The instructions 6030 may execute in logically and / or virtually separate threads on the control circuitry 6015. For example, the non-transitory computer-readable medium 6020 may store instructions 6030 that, when executed by the control circuitry 6015, cause the control circuitry 6015 to perform any of the operations, methods, and / or processes described herein. In some cases, the non-transitory computer-readable medium 620 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the methods of Figures 11A-11C.

[0211] The computing system 6005 may include one or more communications interfaces 6035. The communications interfaces 6035 may be used to communicate with one or more other systems. The communications interfaces 6035 may include any circuits, components, software, etc. for communicating over one or more networks (e.g., network 750). In some implementations, the communications interfaces 6035 may include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.

[0212] The computing system 6005 may also include one or more user input components 6040 that receive user input. For example, the user input component 6040 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.

[0213] The computing system 6005 may include one or more output components 6045. The output components 6045 may include hardware and / or software for generating content audibly or visually. For example, the output components 6045 may include one or more speakers, earphones, a headset, a handset, etc. The output components 6045 may include a display device, which may include hardware for displaying a user interface and / or messages for a user. By way of example, the output components 6045 may include a display screen, a CRT, an LCD, a plasma screen, a touch screen, a TV, a projector, a tablet, and / or other suitable display component.

[0214] The remote computing system 7005 may include one or more computing devices 710. In one embodiment, the remote computing system 7005 may include or be otherwise implemented by one or more server computing devices. When the remote computing system 7005 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.

[0215] The remote computing system 7005 may include control circuitry 7015 and non-transitory computer-readable media (non-transitory CRM) 7020, also referred to herein as memory 7020. In one embodiment, the control circuitry 7015 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 7015 may be programmed by one or more computer-readable or computer-executable instructions stored on the non-transitory computer-readable media 7020.

[0216] In one embodiment, the non-transitory computer-readable medium 7020 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) or a digital versatile disc (DVD), and / or a memory stick.

[0217] The non-transitory computer-readable medium 7020 may store information that can be accessed by the control circuitry 7015. For example, the non-transitory computer-readable medium 7020 (e.g., a memory device) may store data 7025 that can be obtained, received, accessed, written, manipulated, created, and / or stored. The data 7025 may include, for example, any of the data or information described herein. In some implementations, the remote computing system 7005 may retrieve data from one or more memories that are remote from the remote computing system 7005.

[0218] The non-transitory computer-readable medium 7020 may also store computer-readable instructions 7030 that can be executed by the control circuitry 7015. The instructions 7030 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 7015 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 7015 or other hardware components execute the modules or computer-readable instructions.

[0219] The instructions 7030 may execute in logically and / or virtually separate threads on the control circuitry 7015. For example, the non-transitory computer-readable medium 7020 may store instructions 7030 that, when executed by the control circuitry 7015, cause the control circuitry 7015 to perform any of the operations, methods, and / or processes described herein, which may include operations described as being performed by the test computing system 610. In some cases, the non-transitory computer-readable medium 7020 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the data flows and methods / processes of FIGS. 5-11C.

[0220] The server computing system 7005 may include one or more communications interfaces 7035. The communications interfaces 7035 may be used to communicate with one or more other systems. The communications interfaces 7035 may include any circuits, components, software, etc. for communicating over one or more networks (e.g., network 9050). In some implementations, the communications interface 7035 may include, for example, one or more of a communications controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.

[0221] The computing system 6005 and / or the server computing system 7005 may also communicate with a user device 8005 communicatively coupled via a network 9050 .

[0222] The user device 8005 may include one or more computing devices 8010. The user device 8005 may include control circuitry 8015 and non-transitory computer-readable media (non-transitory CRM) 8020, also referred to herein as memory 8020. In one embodiment, the control circuitry 8015 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 8015 may be programmed by one or more computer-readable or computer-executable instructions stored on the non-transitory computer-readable media 8020.

[0223] In one embodiment, the non-transitory computer-readable medium 8020 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.

[0224] The non-transitory computer-readable medium 8020 may store information that can be accessed by the control circuitry 8015. For example, the non-transitory computer-readable medium 820 (e.g., a memory device) may store data 8025 that can be obtained, received, accessed, written, manipulated, created, and / or stored. The data 8025 may include, for example, any of the data or information described herein. In some implementations, the user device 8005 may retrieve data from one or more memories that are remote from the user device 8005.

[0225] The non-transitory computer-readable medium 8020 may also store computer-readable instructions 8030 that can be executed by the control circuitry 8015. The instructions 8030 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, where 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 8015 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 8015 or other hardware components execute the modules or computer-readable instructions.

[0226] The instructions 8030 may execute in logically or virtually separate threads on the control circuitry 8015. For example, the non-transitory computer-readable medium 8020 may store instructions 8030 that, when executed by the control circuitry 8015, cause the control circuitry 8015 to perform any of the operations, methods, and / or processes described herein. In some cases, the non-transitory computer-readable medium 8020 may store computer-executable or computer-readable instructions, such as instructions for performing at least a portion of the methods of Figures 11A-11C.

[0227] The user device 8005 may include one or more communication interfaces 8035. The communication interface 8035 may be used to communicate with one or more other systems. The communication interface 8035 may include any circuitry, components, software, etc. for communicating over one or more networks (e.g., network 9050). In some implementations, the communication interface 8035 may include, for example, one or more of a communication controller, receiver, transceiver, transmitter, port, conductors, software, and / or hardware for communicating data / information.

[0228] The user device 8005 may also include one or more user input components 840 that receive user input. For example, the user input component 8040 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.

[0229] The user device 8005 may include one or more output components 8045. The output component 8045 may include hardware and / or software for generating content audibly or visually. For example, the output component 8045 may include one or more speakers, earphones, a headset, a handset, etc. The output component 8045 may include a display device, which may include hardware for displaying a user interface and / or messages for the user. By way of example, the output component 8045 may include a display screen, CRT, LCD, plasma screen, touch screen, TV, projector, tablet, and / or other suitable display component.

[0230] The one or more networks 9050 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) 9050 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 protection schemes (e.g., VPN, Secure HTTP, SSL).

[0231] Further Description of Various Embodiments Embodiment 1 relates to a computing system. In this embodiment, the computing system may include control circuitry configured to obtain data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location. The control circuitry may be configured to determine that an OTA (over-the-air) software package is available for the vehicle based on the vehicle identifier. The control circuitry may be configured to obtain the OTA software package for the vehicle based on the vehicle identifier from a remote computing system over a network. The control circuitry may be configured to provide the OTA software package to local cache storage located at the location prior to the time when the vehicle is estimated to be at the location.

[0232] Example 2 includes the computing system of Example 1. In this embodiment, the control circuitry may be further configured to determine that the vehicle has arrived at the location and that the OTA software package is available for the vehicle, and output the OTA software package from the local cache storage.

[0233] Example 3 includes the computing system of any of Examples 1 and 2. In this embodiment, the control circuitry can be configured to obtain a request for the OTA software package generated by the vehicle to determine that the vehicle has arrived at the location and that the vehicle is available for the OTA software package.

[0234] Example 4 includes the computing system of any of Examples 1 to 3. In this embodiment, the OTA software package can include a software update package that updates a version of software currently downloaded to the vehicle.

[0235] Example 5 includes the computing system of any of Examples 1 to 4. In this example, the location may be a vehicle service location, and to obtain data indicative of an estimated time that the vehicle will arrive at the location, the control circuitry may be configured to obtain data indicative of scheduled services for the vehicle and determine, based on the scheduled services for the vehicle, an estimated time that the vehicle will arrive at the service location.

[0236] Example 6 includes the computing system of any of Examples 1 to 5. In this embodiment, the location may be a vehicle service location, and to obtain data indicative of an estimated time that the vehicle will arrive at the location, the control circuitry may be configured to obtain historical service data associated with the vehicle and predict, based on the historical service data associated with the vehicle, the estimated time that the vehicle will arrive at the service location.

[0237] Example 7 includes the computing system of any of Examples 1 to 6. In this example, the control circuitry may be further configured to adjust a service schedule for the vehicle based on the OTA software update.

[0238] Example 8 includes the computing system of any of Examples 1 to 7. In this embodiment, the location may be a charging station, and to obtain data indicative of a time when the vehicle will be estimated to be at the location, the control circuitry may be configured to obtain historical charging data associated with the vehicle, and predict, based on the historical charging data associated with the vehicle, a time when the vehicle will be estimated to arrive at the charging station.

[0239] Example 9 includes the computing system of any of Examples 1 to 8. In this embodiment, the location may be a vehicle production facility, and to obtain the data indicative of a time when the vehicle will be estimated to be at the location, the control circuitry may be configured to obtain data indicative of a status of the vehicle at the vehicle production facility, and predict, based on the status of the vehicle, a time when the vehicle will be estimated to be ready for an OTA software update at the vehicle production facility.

[0240] Example 10 includes the computing system of any of Examples 1 to 9. In this embodiment, the control circuitry can be further configured to determine whether an OTA software package for the vehicle is already stored in a local cache storage located at the location.

[0241] Example 11 includes the computing system of any of Examples 1 to 10. In this embodiment, the control circuitry can be further configured to provide data to the remote computing system indicating that an OTA software package has been provided to the vehicle at the location for updating the vehicle's shadow record.

[0242] Example 12 includes the computing system of any of Examples 1 to 11. In this example, the control circuitry can be further configured to determine a confidence level of the estimated time that the vehicle will be at the location, and queue the OTA software package based on the confidence level of the estimated time that the vehicle will be at the location.

[0243] Example 13 includes the computing system of any of Examples 1 to 12. In this embodiment, the control circuitry may be further configured to acquire network traffic data associated with the network and determine, based on the network traffic data, a time period for acquiring the OTA software package over the network.

[0244] Embodiment 14 relates to a computer-implemented method system. In this embodiment, the method may include obtaining data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location. The method may include determining that an OTA (over-the-air) software package is available for the vehicle based on the vehicle identifier. The method may include obtaining the OTA software package for the vehicle based on the vehicle identifier from a remote computing system over a network. The method may include providing the OTA software package to local cache storage located at the location before the time when the vehicle is estimated to be at the location.

[0245] Example 14 includes the computer-implemented method of Example 13. In this embodiment, the method can include determining that the vehicle has arrived at the location and that the OTA software package is available for the vehicle, and outputting the OTA software package from the local cache storage.

[0246] Example 15 includes the computer-implemented method of any of Examples 13 or 14. In this embodiment, the method may include determining whether the OTA software package for the vehicle is already stored in a local cache storage located at the location.

[0247] Example 16 includes the computer-implemented method of any of Examples 13 to 15. In this embodiment, the method may include providing data to the remote computing system indicating that an OTA software package has been provided to the vehicle at the location for updating the vehicle's shadow record.

[0248] Example 17 includes the computer-implemented method of any of Examples 13 to 16. In this embodiment, the method may include providing data to the remote computing system indicating that an OTA software package has been provided to the vehicle at the location for updating the vehicle's shadow record.

[0249] Example 18 includes the computer-implemented method of any of Examples 13 to 17. In this embodiment, the method can include determining a confidence level of the time the vehicle is estimated to be at the location, and queuing the OTA software package based on the confidence level of the time the vehicle is estimated to be at the location.

[0250] Example 19 includes the computer-implemented method of any of Examples 13 to 18. In this embodiment, the method includes acquiring network traffic data associated with a network, and determining, based on the network traffic data, a time period for acquiring the OTA software package over the network.

[0251] Embodiment 20 relates to one or more non-transitory computer-readable media storing instructions that may be executable by a control circuit to: acquire data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location; determine, based on the vehicle identifier, that an OTA (over-the-air) software package is available for the vehicle; acquire, via a network from a remote computing system, the OTA software package for the vehicle based on the vehicle identifier; and provide the OTA software package to local cache storage located at the location prior to the time when the vehicle is estimated to be at the location.

[0252] 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.

[0253] Computing tasks and operations discussed herein as being performed in or by a computing device remote from the vehicle may instead be performed in the vehicle (e.g., via a vehicle computing system), or vice versa.

[0254] 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 functionality among components. For example, the processes described herein may be implemented 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.

[0255] 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.

[0256] Aspects of the present disclosure have been described with respect to exemplary implementations 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 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 present subject matter as would be readily apparent to one of ordinary skill in the art. Furthermore, terminology is 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."

[0257] 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 (a), (b), (c), ...(i), (ii), (iii), ..., etc. 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 the 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: obtaining data indicative of a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location; determining, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle; obtaining the OTA software package for the vehicle based on the vehicle identifier from a remote computing system over a network; providing the OTA software package to a local cache storage located at the location prior to the time that the vehicle is estimated to be at the location; 11. A computing system comprising: a control circuit configured to:

2. The control circuit determining that the vehicle has arrived at the location and that the vehicle is available to the OTA software package; outputting the OTA software package from the local cache storage; The computing system of claim 1 further configured to:

3. To determine that the vehicle has arrived at the location and is available to the OTA software package, the control circuitry: The computing system of claim 2 , configured to obtain a request for the OTA software package generated by the vehicle.

4. 10. The computing system of claim 1, wherein the OTA software package comprises a software update package that updates a version of software currently downloaded to the vehicle.

5. the location is a vehicle service location, and the control circuitry is configured to obtain data indicative of the time the vehicle is estimated to arrive at the location; obtaining data indicative of scheduled services for the vehicle; determining an estimated time that the vehicle will arrive at the service location based on the scheduled service for the vehicle; 10. The computing system of claim 1, configured to:

6. the location is a vehicle service location, and the control circuitry is configured to obtain data indicative of the time the vehicle is estimated to arrive at the location; obtaining historical service data associated with the vehicle; predicting an estimated time that the vehicle will arrive at the service location based on the historical service data associated with the vehicle; 10. The computing system of claim 1, configured to:

7. The control circuit The computing system of claim 1 , further configured to adjust a service schedule for the vehicle based on the OTA software update.

8. The control circuitry is configured to: obtain data indicating the time when the location is a charging station and the vehicle is estimated to be present at the location; obtaining historical charging data associated with the vehicle; predicting an estimated time that the vehicle will arrive at the charging station based on the historical charging data associated with the vehicle; 10. The computing system of claim 1, configured to:

9. the location is a vehicle production facility, and to obtain the data indicative of the time that the vehicle is estimated to be present at the location, the control circuitry obtaining data indicative of the status of the vehicle at the vehicle production facility; predicting a time when the vehicle will be ready for the OTA software update at the vehicle production facility based on the status of the vehicle; 10. The computing system of claim 1, configured to:

10. The control circuit 2. The computing system of claim 1, further configured to determine whether the OTA software package for the vehicle is already stored in the local cache storage located at the location.

11. The control circuit 10. The computing system of claim 1, further configured to provide data indicating that the OTA software package has been provided to the vehicle at the location to the remote computing system for updating a shadow record of the vehicle.

12. The control circuit determining a confidence level for the time that the vehicle is estimated to be at the location; queuing the OTA software package based on the confidence in the time that the vehicle is estimated to be at the location; The computing system of claim 1 further configured to:

13. The control circuit obtaining network traffic data associated with said network; determining a time period for acquiring the OTA software package over the network based on the network traffic data; The computing system of claim 1 further configured to:

14. 1. A computer-implemented method comprising: obtaining data indicative of a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location; determining, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle; obtaining the OTA software package for the vehicle based on the vehicle identifier from a remote computing system over a network; providing the OTA software package to a local cache storage located at the location prior to the time the vehicle is estimated to be at the location.

15. determining that the vehicle has arrived at the location and that the vehicle is available to the OTA software package; outputting the OTA software package from the local cache storage; The computer-implemented method of claim 13 further comprising:

16. The computer-implemented method of claim 13 , further comprising determining whether the OTA software package for the vehicle is already stored in the local cache storage located at the location.

17. 14. The computer-implemented method of claim 13, further comprising providing data indicating that the OTA software package has been provided to the vehicle at the location to the remote computing system for updating a shadow record of the vehicle.

18. determining a confidence level for the time that the vehicle is estimated to be at the location; queuing the OTA software package based on the confidence in the time that the vehicle is estimated to be at the location; The computer-implemented method of claim 13 further comprising:

19. obtaining network traffic data associated with said network; determining a time period for acquiring the OTA software package over the network based on the network traffic data; The computer-implemented method of claim 13 further comprising:

20. obtaining data indicative of a vehicle identifier associated with a vehicle and a time when the vehicle is estimated to be at a location; determining, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle; obtaining the OTA software package for the vehicle based on the vehicle identifier from a remote computing system over a network; One or more non-transitory computer-readable media storing instructions executable by control circuitry to provide the OTA software package to local cache storage located at the location prior to the time that the vehicle is estimated to be at the location.

Images