Smart caching of over-the-air software updates for vehicles

Abstract

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

Description

[0001] Related Applications

[0002] This patent application claims the benefit and priority of U.S. Provisional Patent Application No. 63 / 429,480, filed on December 1, 2022, the content of which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to distributing over-the-air software updates to various vehicles. More specifically, the present disclosure relates to intelligently caching over-the-air software updates at specific locations to more efficiently distribute such updates to various vehicles while conserving computing resources. Background Art

[0004] Over-the-air (OTA) 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 the user having to connect their device or manually install the updates. OTA updates are commonly used to fix software bugs, improve device performance, add new features, and address security vulnerabilities. In recent years, as more and more devices have become connected to the Internet, OTA updates have become increasingly common, making it easier for manufacturers to deliver updates quickly and efficiently. Summary of the Invention

[0005] Specific aspects and advantages of the present disclosure will be set forth in part in the following description, or may be learned from the description, or may be learned through practice of the specific aspects.

[0006] One example aspect of the present disclosure relates to a computing system. The computing system includes a control circuit configured to: obtain data indicating a vehicle identifier associated with a vehicle and a time when the vehicle is expected to be at a location. The control circuit is configured to: determine, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle. The control circuit is configured to: obtain, based on the vehicle identifier, the OTA software package for the vehicle from a remote computing system via a network. The control circuit is configured to: provide the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

[0007] In some specific implementations, the control circuit is further configured to: determine that the vehicle has arrived at the location and that the vehicle is available for the OTA software package; and output the OTA software package from the local cache storage device.

[0008] In some specific implementations, to determine that the vehicle has reached the location and that the vehicle is available for the OTA software package, the control circuit is configured to: obtain a request for the OTA software package generated by the vehicle.

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

[0010] In some specific implementations, the location is a vehicle maintenance location, and in order to obtain data indicating the time at which the vehicle is expected to reach the location, the control circuit is configured to: obtain data indicating the scheduled maintenance for the vehicle; and determine, based on the scheduled maintenance for the vehicle, the time at which the vehicle is expected to reach the maintenance location.

[0011] In some specific implementations, the location is a vehicle maintenance location, and in order to obtain data indicating the time at which the vehicle is expected to reach the location, the control circuit is configured to: obtain historical maintenance data associated with the vehicle; and predict, based on the historical maintenance data associated with the vehicle, the time at which the vehicle is expected to reach the maintenance location.

[0012] In some specific implementations, the control circuit is further configured to: adjust the maintenance schedule of the vehicle based on the OTA software update.

[0013] In some specific implementations, the location is a charging station, and in order to obtain data indicating the time at which the vehicle is expected to be at the location, the control circuit is configured to: obtain historical charging data associated with the vehicle; and predict, based on the historical charging data associated with the vehicle, the time at which the vehicle is expected to reach the charging station.

[0014] In some specific implementations, the location is a vehicle production facility, and in order to obtain data indicating the time at which the vehicle is expected to be at the location, the control circuit is configured to: obtain data indicating the status of the vehicle at the vehicle production facility; and predict, based on the status of the vehicle, the time at which the vehicle is expected to be ready for the OTA software update at the vehicle production facility.

[0015] In some specific implementations, the control circuit is further configured to: determine whether the OTA software package for the vehicle has been stored in the local cache storage device located at the location.

[0016] In some specific implementations, the control circuit is 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 the shadow record of the vehicle.

[0017] In some specific implementations, the control circuit is further configured to: determine a confidence level for the time when the vehicle is expected to be at the location; and queue the OTA software package based on the confidence level for the time when the vehicle is expected to be at the location.

[0018] In some specific implementations, the control circuit is further configured to: obtain network traffic data associated with the network; and determine a time period for obtaining the OTA software package through the network based on the network traffic data.

[0019] Another example aspect of the present disclosure relates 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 expected to be at a certain location. The method includes: determining that an over-the-air (OTA) software package is available for the vehicle based on the vehicle identifier. The method includes: obtaining the OTA software package for the vehicle from a remote computing system through a network based on the vehicle identifier. The method includes: providing the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

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

[0021] In some specific implementations, the method includes: determining whether the OTA software package for the vehicle has been stored in the local cache storage device located at the location.

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

[0023] In some specific implementations, the method includes: providing data indicating that the OTA software package has been provided to the vehicle at the location to the remote computing system for updating the shadow record of the vehicle.

[0024] In some specific implementations, the method includes: determining a confidence level for the time when the vehicle is expected to be at the location; and queueing the OTA software package based on the confidence level for the time when the vehicle is expected to be at the location.

[0025] In some specific 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 via the network.

[0026] Another example aspect of the present disclosure relates to one or more non-transitory computer-readable media storing instructions executable by a control circuit to: obtain data indicating a vehicle identifier associated with a vehicle and a time at which the vehicle is expected to be at a location; determine, based on the vehicle identifier, that an over-the-air (OTA) software package is available for the vehicle; obtain, based on the vehicle identifier, the OTA software package for the vehicle from a remote computing system via a network; and provide the OTA software package to a local cache storage device located at the location before the time at which the vehicle is expected to be at the location.

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

[0028] These and other features, aspects, and advantages of the various specific implementations will become better understood with reference to the following description and the appended claims. The accompanying drawings, which are incorporated into and constitute a part of this specification, illustrate specific implementations of the present disclosure and, together with the description, serve to explain the relevant principles. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] A detailed discussion of specific implementations involving those of ordinary skill in the art is set forth in the specification, which refers to the accompanying drawings, in which:

[0030] Figure 1 An example computing ecosystem according to one implementation of the present disclosure is illustrated.

[0031] Figures 2A to 2D A diagram illustrating an example computing architecture of an in-vehicle computing system for a vehicle according to one implementation of the present disclosure.

[0032] Figure 3 A diagram illustrating an example computing platform remote from a vehicle according to one implementation of the present disclosure.

[0033] Figure 4 A diagram illustrating a computing ecosystem for providing an OTA software update for a vehicle according to one implementation of the present disclosure.

[0034] Figure 5 A diagram illustrating an example update controller according to one implementation of the present disclosure.

[0035] Figure 6 A diagram illustrating an example computing ecosystem and data flow for caching OTA software packages according to an embodiment of the present disclosure.

[0036] Figure 7 A diagram illustrating an example process for distributing and caching OTA software packages according to an embodiment of the present disclosure.

[0037] Figure 8 A diagram illustrating an example computing ecosystem and data flow for caching OTA software packages according to an embodiment of the present disclosure.

[0038] Figure 9 A diagram illustrating an example computing ecosystem and data flow for caching OTA software packages according to an embodiment of the present disclosure.

[0039] Figure 10 A diagram illustrating an example computing ecosystem and data flow for caching OTA software packages according to an embodiment of the present disclosure.

[0040] Figures 11A to 11C A flowchart diagram illustrating an example method according to an embodiment of the present disclosure.

[0041] Figure 12 A diagram illustrating an example computing ecosystem with computing components according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0042] One aspect of the present disclosure relates to intelligently caching OTA software updates for a vehicle. For example, a vehicle (e.g., a personal car) may be scheduled for maintenance at a maintenance location. A computing system associated with the maintenance site may store a data structure indicating a maintenance schedule for the maintenance location. The computing system may obtain data from the data structure indicating a vehicle identifier of the vehicle and an appointment time of the vehicle at the maintenance 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. In the presence of an OTA software update applicable to a particular vehicle, the particular vehicle may be considered available for the OTA software package. For example, this may occur when an update to the software version running on the vehicle is available for a particular make and model of the vehicle (e.g., an infotainment software update for the 2021 model). To determine whether an OTA software package is available for the vehicle, the computing system may provide an identifier of the vehicle (e.g., VIN) to the cloud-based computing platform.

[0043] A cloud-based computing platform can respond to a request by providing an OTA software package for a vehicle. For example, an update controller of the cloud-based computing platform can be configured to allocate an OTA software package for the vehicle. Based on the vehicle identifier, the update controller can invoke one or more services to compile the OTA software package for transmission over a network to a computing system associated with a maintenance site.

[0044] The computing system can obtain the OTA software package for the vehicle and cache the packaged OTA software in its local cache. For example, the computing system can provide the OTA software package to a local cache storage device located at the maintenance site before the time when the vehicle is expected to be at the location. The local cache storage device can maintain the OTA software package such that when the vehicle is at the maintenance site, the OTA software package is queued at an appropriate time for allocation to the vehicle. For example, when the vehicle arrives at the maintenance site, the vehicle can provide a request for the OTA software package (or any available OTA update). In response, the computing system can output the OTA software package from the local cache to the vehicle. When the vehicle is at the maintenance site, the vehicle can implement the OTA software package and update the software (e.g., infotainment software) running on the vehicle's computing system.

[0045] To help maintain an accurate record of the in-vehicle software capabilities of the vehicle, the computing system associated with the maintenance site can issue a notification to the cloud-based computing system that the OTA software package has been delivered to the vehicle. The cloud-based computing system can update the stored shadow record of the vehicle, which reflects the current state of the software, hardware, vehicle configuration, etc. implemented on the vehicle. This can allow the cloud-based computing system to determine in future scenarios whether the vehicle is eligible or ineligible for future OTA software updates.

[0046] In some embodiments, the computing system can cache OTA software updates based on a prediction of the vehicle's future location. For example, the computing system can obtain historical maintenance data (e.g., past maintenance records, purchase date) and predict the time when the vehicle is expected to arrive at the maintenance site based on that data. This allows the computing system to intelligently cache OTA software updates within the server associated with the location using the data available to the computing system, without the vehicle owner / operator explicitly scheduling an appointment.

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

[0048] The charge data can be processed to determine patterns or routines of the vehicle / user indicating that the vehicle is likely to be charged at a particular charging station, on a particular day of the week, during a particular part of the day, etc. For example, a computing system can process the charge data to determine the dates on which the user most frequently charges the vehicle and / or the battery level at which the user tends to recharge the vehicle (e.g., below X% battery level). Additionally or alternatively, the computing system can determine the charging stations at which the vehicle is charged more frequently. This information can be used to predict the times at which the vehicle is likely to be located at a particular charging station such that applicable OTA software updates can be cached at the charging station in the manner described herein.

[0049] In another example, the future location of a vehicle can be predicted based on the vehicle's route. For example, a user of the vehicle can request a route from a starting point to a destination. Given the vehicle's route and current charge state, a computing system can determine the locations and times at which the vehicle is likely to need to be charged. The computing system can determine candidate charging stations along the route based on the times and locations at which the vehicle is likely to need to be charged. The candidate charging stations can be presented to the user via a user interface of the vehicle's infotainment system. In some embodiments, certain candidates can be recommended to the user (e.g., visually emphasized on the UI). The user can select a candidate by providing user input (e.g., touch input) to the infotainment system. The techniques of the present disclosure can be used to cache OTA software updates for the vehicle at the candidate (or selected) charging station before the vehicle arrives. In this way, the future location of the vehicle predicted based on the vehicle's route can be used to intelligently pre-cache OTA software updates such that the vehicle can receive them while charging.

[0050] In some specific implementations, a computing system associated with a maintenance site may calibrate the time for the computing system to extract an OTA software package over a network based on predicted network traffic. For example, the computing system may obtain network traffic data associated with the network through which the OTA software package will be sent. The network traffic data may indicate the network traffic during various time intervals of a day. During off-peak hours (e.g., at night), the network traffic may be particularly low. Therefore, the computing system may determine that this would be an appropriate time range for requesting / extracting the OTA software package, thereby improving the downlink transmission efficiency.

[0051] Although the above examples are described regarding providing OTA software updates at a maintenance site, the techniques of the present disclosure are not limited to such locations. As will be further described herein, systems and methods for intelligently caching OTA software updates may be implemented using production facilities, factories, charging stations, etc.

[0052] The techniques of the present disclosure may provide many technical effects and computing improvements. For example, by intelligently caching OTA software updates for a vehicle according to the techniques described herein, a computing ecosystem (e.g., including an in-vehicle vehicle computer, a cloud platform, etc.) may avoid other software distribution techniques that include high computing costs. For example, the systems and methods of the present disclosure avoid the large amount of data transfer caused by fully synchronizing all available update packages, but instead utilize an advanced process of on-demand package synchronization. This saves time, bandwidth, processing, and memory resources by selectively extracting only those software packages applicable to a particular vehicle that will be available at a local site. Additionally, this reduces the need to distribute physical media (e.g., DVDs) to the local site. Therefore, the computing ecosystem may avoid the high-cost processing and inefficient read / write functions typically required to create and utilize such media.

[0053] The techniques of the present disclosure may 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 the time the vehicle is expected to be at a certain location (e.g., the appointment time at a maintenance site). The computing system may determine an over-the-air (OTA) software package available for the vehicle based on the vehicle identifier. The computing system may obtain, over a network, the OTA software package applicable to the vehicle based on the vehicle identifier from a remote computing system. Before the time the vehicle is expected to be at the location, the computing system may provide the OTA software package to a local cache storage device located at the location. During a scheduled appointment, the OTA software package may be provided to the vehicle for download at the maintenance site.

[0054] In this manner, the computing system can identify the situations and times when the vehicle will be idle, such that the computing system can select applicable OTA software packages and locally cache them for the vehicle to retrieve. By leveraging the local cache, the computing system can more efficiently deliver the software packages to the vehicle when the vehicle is not being driven by its owner. This can help ensure that the OTA software packages are downloaded to the vehicle in a single session, rather than in multiple sessions caused by changes in network connectivity as the vehicle is driven to various locations. Thus, the techniques of the present disclosure help avoid stops and restarts of the OTA software packages, thereby achieving vehicle software updates in a more computationally efficient manner. Ultimately, this can improve the reliability of the in-vehicle computing functions by helping to keep the in-vehicle software up-to-date, thereby improving the performance of the vehicle itself.

[0055] Additionally, as further described herein, the techniques of the present disclosure can intelligently queue OTA software packages for retrieval and / or download from a remote computing system. The queue can be constructed in an order that avoids wasting storage resources of the local computing system. For example, for the local computing system at a maintenance site, the OTA software packages (or requests for the OTA software packages) can be queued in the order in which the appointments occur, such that: (i) the local computing system is more likely to download the OTA software packages to the local cache at the beginning of the day for the first appointment; (ii) any software packages located later in the download list correspond to later appointments; and (iii) time and bandwidth waste caused by downloading unnecessary software packages is avoided.

[0056] Reference will now be made in detail to the embodiments, one or more examples of which are illustrated in the accompanying drawings. Each example is provided by way of explanation of the embodiments and not limitation of the disclosure. In fact, 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, the functions illustrated or described as part of one embodiment can be used with another embodiment to yield yet another embodiment. Accordingly, aspects of the disclosure are intended to cover such modifications and variations.

[0057] The techniques of the present disclosure can include such collection of data in cases where the user explicitly authorizes the collection of data associated with the user. Such authorization can be provided by the user via explicit user input to a user interface in response to a prompt that explicitly requests such authorization. The data collected can be anonymized, pseudonymized, encrypted, noise-added, securely stored, or otherwise protected. The user can opt out of such data collection at any time.

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

[0059] Figure 1 An example computing ecosystem 100 is illustrated in accordance with an embodiment of the present disclosure. The ecosystem 100 may include a vehicle 105, a remote computing platform 110 (also referred to herein as the 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 embodiments, the user 120 may be a passenger of the vehicle. In some embodiments, the computing ecosystem 100 may include a third-party (3P) computing platform 125, as further described herein. The vehicle 105 may include a vehicle computing system 200 located on 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.

[0060] The systems / devices of the ecosystem 100 may communicate using one or more application programming interfaces (APIs). This may include external-facing APIs to communicate data from one system / device to another. The external-facing APIs may allow the systems / devices to establish secure communication channels via a secure access channel over the network 130 by any number of methods, such as web-based forms, programmatic access via RESTful APIs, Simple Object Access Protocol (SOAP), Remote Procedure Call (RPC), script access, etc.

[0061] The computing platform 110 may include a computing system remote from the vehicle 105. In an embodiment, the computing platform 110 may include a cloud-based server system. The computing platform 110 may be associated with an entity (e.g., operated by the entity). For example, the remote computing platform 110 may be associated with an OEM responsible for the make and model of the vehicle 105. In another example, the 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 the vehicle 105.

[0062] The computing platform 110 may include one or more backend services for supporting the vehicle 105. Each service may include, for example, a remote assistance service, a navigation / routing service, a performance monitoring service, etc. The computing platform 110 may host or otherwise include one or more APIs for communicating data to / from the computing system 130 of the vehicle 105 or the user device 115.

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

[0064] The user device 115 may include a computing device owned or otherwise accessible by the user 120. For example, the user device 115 may include a telephone, a laptop computer, a tablet computer, a wearable device (e.g., a smartwatch, smart glasses, headphones), a personal digital assistant, a gaming system, a personal desktop device, other handheld devices, or other types of mobile or non-mobile user devices. As further described herein, the user device 115 may include one or more input components, such as buttons, a touchscreen, a joystick or other cursor controls, a stylus, a microphone, a camera or other imaging device, a motion sensor, etc. The 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, the user device 115 may include a component such as a touchscreen that is configured to perform input and output functionality to receive user input and present information to the user 120. The user device 115 may execute one or more instructions to run an instance of a software application and present a user interface associated with the instance, as further described herein. In an embodiment, launching a software application may initiate a user network session with the computing platform 110.

[0065] The third-party computing platform 125 may include a computing system remote from the vehicle 105, the remote computing platform 110, and the user device 115. In an 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 an OEM responsible for the make and model of the vehicle 105. The third-party computing platform 125 may be associated with a supplier of the OEM, a maintenance provider, a map service provider, an emergency provider, or other types of entities. In another example, the third-party computing platform 125 may be associated with an entity that owns, operates, manages, etc., a software application that may be used or downloaded to the vehicle computing system 200.

[0066] 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 that can be accessed by other systems and devices of the ecosystem 100. Each service 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 otherwise include one or more APIs to communicate data to / from the third-party computing system 125 and other systems / devices of the ecosystem 100.

[0067] The network 130 can be any type of network or combination of networks that enables communication between the various devices. In some specific implementations, the 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 some combination thereof, and may include any number of wired or wireless links. Communication over the network 130 can be accomplished, for example, via a network interface using any type of protocol, protection scheme, encoding, format, encapsulation, etc. In an implementation, communication between the vehicle computing system 200 and the user device 115 can be facilitated by near field communication technology or short-range communication technology (e.g., Bluetooth Low Energy protocol, radio frequency signaling, NFC protocol).

[0068] The vehicle 105 can be a vehicle operable by the user 120. In an implementation, the vehicle 105 can be an automobile or another type of land-based vehicle manually driven by the user 120. For example, the vehicle 105 can be a sedan or a van. In some specific implementations, the vehicle 105 can be an aircraft (e.g., a personal aircraft) or a water-based vehicle (e.g., a boat). The vehicle 105 may include operator assistance functionality such as cruise control, advanced driver assistance systems, etc. In some specific implementations, the vehicle 105 can be a fully autonomous vehicle or a semi-autonomous vehicle.

[0069] 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 electric motor (e.g., an electric motor), a transmission (e.g., an automatic transmission, a manual transmission, a continuously variable transmission), a drive shaft, an axle, a differential, electronic components, gears, etc. The power source may include one or more types of power sources. For example, the vehicle 105 may be a fully electric vehicle (EV) that is capable of using a battery to operate the powertrain of the vehicle 105 (e.g., for propulsion) and the on-vehicle functions of the vehicle. In an embodiment, the vehicle 105 may use a combustible fuel. In an embodiment, the vehicle 105 may include a hybrid power source, such as, for example, a combination of a combustible fuel and electricity.

[0070] The vehicle 105 may include an interior of the vehicle. The interior of the vehicle may include the area located inside the body of the vehicle 105, including, for example, the passenger compartment of the vehicle 105. The interior of the vehicle 105 may include seats for the users, a steering mechanism, an accelerator interface, a brake interface, etc. The interior of the vehicle 105 may include a display device, such as a display screen associated with an infotainment system, as further described Figure 3 below.

[0071] The vehicle 105 may include an exterior of the vehicle. The exterior of the vehicle may include the outer surface of the vehicle 105. The exterior of the vehicle may include one or more lighting elements (e.g., headlights, brake lights, spotlights). The vehicle 105 may include one or more doors for entering the interior of the vehicle by, for example, manipulating a door handle on the exterior of the vehicle. The vehicle 105 may include one or more windows, including a windshield, a door window, a passenger window, a rear window, a sunroof, etc.

[0072] The systems and components of the vehicle 105 may be configured to communicate via a communication channel. The communication channel may include one or more data buses (e.g., Controller Area Network (CAN)), an on-vehicle diagnostic connector (e.g., OBD-II), or a combination of wired or wireless communication links. The on-vehicle systems may transmit or receive data, messages, signals, etc. to and from each other via the communication channel. The vehicle may also be configured to refer to one or more protocols for sending data (e.g., software updates) via a charging cable, wirelessly, via short-range communication (e.g., NFC, ) etc.

[0073] In an embodiment, the communication channel may include a direct connection, such as a connection provided via a dedicated wired communication interface (such as an RS-232 interface, a Universal Serial Bus (USB) interface) or via a local computer bus (such as a Peripheral Component Interconnect (PCI) bus). In an embodiment, the communication channel may be provided via a network. The network can 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 different technology and protocol layers or protocol stacks, including, for example, Ethernet protocol, Internet protocol suite (TCP / IP), ATM (Asynchronous Transfer Mode) technology, SONET (Synchronous Optical Network) protocol, or SDH (Synchronous Digital Hierarchy) protocol.

[0074] In an embodiment, the systems / devices of vehicle 105 may communicate via an intermediate storage device or more generally via an intermediate non-transitory computer-readable medium. For example, a non-transitory computer-readable medium 140 that may be located external to computing system 130 may act as an external buffer or repository for storing information. In such examples, computing system 130 may extract information from or otherwise receive information from non-transitory computer-readable medium 140.

[0075] For the sake of brevity, certain routines and conventional components of vehicle 105 (e.g., the engine) are not illustrated and / or discussed herein. Those of ordinary skill in the art will understand the operation of conventional vehicle components in vehicle 105.

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

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

[0078] Figure 2BFIG. illustrates 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 on the vehicle 105 and the software running on the vehicle 105 (e.g., of the software layer 210).

[0079] The hardware layer 205 may be an abstraction layer that includes computing code that implements communication between the software and the computing hardware 215 in the vehicle computing system 200. For example, the hardware layer 205 may include interfaces and calls that allow the vehicle computing system 200 to generate hardware-related instructions to the computing hardware 215 of the vehicle 105 (e.g., processors, memories, etc.).

[0080] The hardware layer 205 may be configured to help coordinate hardware resources. The architecture of the hardware layer 205 may be a service-oriented architecture. The services may help provide the computing capabilities of the vehicle computing system 105. For example, the hardware layer 205 may include the domain computers 220 of the vehicle 105, which may host various functions of the vehicle 105 (such as the intelligent functions of the vehicle). The specifications of each domain computer may be customized for functional and performance requirements, where the services are abstracted to the domain computers. As an example, this allows certain processing resources (e.g., graphics processing units) to support the functionality of the central in-vehicle infotainment computer for rendering graphics on one or more display devices for navigation, gaming, etc., or to support the intelligent autonomous driving computer to achieve certain industry assurances.

[0081] 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 docking with the communication hardware of the vehicle 105. This may include, for example, docking with communication controllers, receivers, transceivers, transmitters, ports, conductors, or other hardware for transmitting data / information. The connectivity module 225 may allow 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., the OEM cloud platform)).

[0082] The architecture design of the hardware layer 205 may be configured to dock / interface with the computing hardware 215 of one or more vehicle control units 225. The vehicle control units 225 may be configured to control various functions of the vehicle 105. This may include, for example, the central external and internal controller (CEIC), the charging controller, or other controllers as further described herein.

[0083] The software layer 205 may be configured to provide software operations for performing various types of functions and applications of the vehicle 105. Figure 2CA diagram illustrating the software layer 210 of the vehicle computing system 200 is shown. The architecture of the software layer 210 can be a service-oriented architecture and can be configured to provide software for various functions of the vehicle computing system 200. To this end, the software layer 210 can include multiple sub-layers 235A - 235E. For example, the software layer 210 can include a first sub-layer 235A, a second sub-layer 235B, and a third sub-layer 235C. The first sub-layer includes firmware (e.g., audio firmware) and a hypervisor. The second sub-layer includes operating system components (e.g., open-source components). The third sub-layer includes middleware (e.g., for flexible integration with applications developed by associated entities or third-party entities).

[0084] The vehicle computing system 200 can include an application layer 240. The application layer 240 can allow integration with one or more software applications 245 that can be downloaded or otherwise accessed by the vehicle 105. The application layer 240 can be configured, for example, using a container interface, to integrate with applications developed by various different entities.

[0085] The layered operating system and the vehicle's on-vehicle computing resources can allow the vehicle computing system 200 to collect and communicate data and operate the systems implemented on the vehicle 105. Figure 2D A block diagram illustrating an example system and data of the vehicle 105 is shown.

[0086] Vehicle 105 may include one or more sensor systems 305. The sensor system may include sensors of vehicle 105 and modules for processing sensor data 310 or otherwise communicating with the sensors and the modules, the modules being associated with sensors configured to obtain sensor data 305. This may include sensor data 310 associated with the surrounding environment of vehicle 105, sensor data associated with the interior of vehicle 105, or sensor data associated with a particular vehicle function. Sensor data 310 may indicate conditions observed within the vehicle, outside the vehicle, or in the surrounding environment. For example, sensor data 305 may include image data, interior / exterior temperature data, weather data, data indicating the location of a user / object within vehicle 105, weight data, motion / gesture data, audio data, or other types of data. The sensors may include one or more of the following: cameras (e.g., visible spectrum cameras, infrared cameras), motion sensors, audio sensors (e.g., microphones), weight sensors (e.g., for vehicle seats), temperature sensors, humidity sensors, light detection and ranging (LIDAR) systems, radio detection and ranging (RADAR) systems, or other types of sensors. Vehicle 105 may include other sensors configured to obtain data associated with vehicle 105. For example, vehicle 105 may include an inertial measurement unit, a tire odometer device, or other sensors.

[0087] 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) indicating the location (also referred to as the position) of vehicle 105. For example, the positioning system 315 may determine the location by one or more of the following means: using inertial sensors (e.g., inertial measurement units, etc.), satellite positioning systems; based on an IP address; using triangulation and / or proximity to network access points or other network components (e.g., cell towers, Wi-Fi access points, etc.); or other suitable techniques. The positioning system 315 may determine the current location of vehicle 105. The location may be represented as a set of coordinates (e.g., latitude, longitude), an address, a semantic location (e.g., "at work"), etc.

[0088] In an embodiment, the positioning system 315 can be configured to position the vehicle 105 within the environment of the positioning system. For example, the vehicle 105 can access map data that provides detailed information about the surrounding environment of the vehicle 105. The map data can provide information about: the identification and location of different roads, road segments, buildings, or other objects; the location and direction of traffic lanes (e.g., the location and direction of parking lanes, turning lanes, bicycle lanes, or other lanes within a particular road); traffic control data (e.g., the location, timing, or instructions of signs (e.g., stop signs, yield signs), traffic lights (e.g., stop lights), or other traffic signals or control devices / markers (e.g., crosswalks)); or any other data. The positioning system 315 can position the vehicle 105 within the environment (e.g., across multiple axes) based on the map data. For example, the positioning system 155 can process certain sensor data 310 (e.g., LIDAR data, camera data, etc.) to match the sensor data with a map of the surrounding environment to determine the position of the vehicle within the environment. The determined position of the vehicle 105 can be used by various systems of the vehicle computing system 200 or another computing system (e.g., the remote computing platform 110, the third-party computing platform 125, the user device 115).

[0089] The vehicle 105 can include a communication system 325 that is configured to allow the vehicle 105 (and its vehicle computing system 200) to communicate with other computing devices. The vehicle computing system 200 can use the communication system 325 to communicate with the remote computing platform 110 or one or more other remote computing devices via a network 130 (e.g., via one or more wireless signal connections). For example, the vehicle computing system 200 can utilize the communication system 325 to receive platform data 330 from the computing platform 110. This can include, for example, an over-the-air (OTA) software update for the operating system of the vehicle computing system 200. Additionally or alternatively, the vehicle computing system 200 can utilize the communication unit 325 to transmit vehicle data 335 to the computing platform 110. The vehicle data 335 can include any data obtained on the vehicle, including, for example, sensor data 310, location data 320, diagnostic data, user input data, data indicating the current software version or currently running applications, occupancy data, data associated with the user 120 of the vehicle 105, or other types of data obtained (e.g., acquired, accessed, generated, downloaded, etc.) by the vehicle computing system 200.

[0090] In some embodiments, the communication system 325 can allow communication between one or more of the systems on the vehicle 105.

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

[0092] The vehicle 105 may include one or more human-machine interfaces (HMIs) 340. The human-machine interface 340 may include a display device, as described herein. The display device (e.g., touchscreen) may be viewable by a user (e.g., user 120) of the vehicle 105 located in the front portion of the vehicle 105 (e.g., driver seat, front passenger seat). Additionally or alternatively, the display device (e.g., rear unit) may be viewable by a user in the rear portion of the vehicle 105 (e.g., rear passenger seat). The human-machine interface 340 may present content 335 via the user interface for display to the user 120.

[0093] The vehicle 105 may include a plurality of vehicle functions 350A - 350C. The vehicle functions 350A - 350C may be functionality that the vehicle 105 is configured to perform based on a detected input. The vehicle functions 350A - 350C may include one or more of the following: (i) vehicle comfort functions; (ii) vehicle preparation functions; (iii) vehicle climate functions; (iv) vehicle navigation functions; (v) drive mode functions; (vi) vehicle parking functions; or (vii) vehicle entertainment functions. The user 120 may interact with the vehicle functions 250A - 250C via a user input (e.g., going to an adjustable input device, UI element) that specifies settings for the vehicle functions 250A - 250C selected by the user.

[0094] Each vehicle function may include a controller 355A - 355C associated with that particular vehicle function 355A - 355C. The controller 355A - 355C for a particular vehicle function may include control circuitry configured to operate the vehicle function 355A - 355C associated with the controller. For example, the controller may include circuitry configured to turn on a seat heating function, turn off a seat heating function, set a particular temperature or temperature level, etc.

[0095] In one embodiment, the controllers 355A - 355C for a particular vehicle function may include or otherwise be associated with a sensor that collects data indicating whether a vehicle function is turned on or off, the settings of the vehicle function, etc. For example, the sensor can be an audio sensor or a motion sensor. The audio sensor can be a microphone configured to collect audio input from the user 120. For example, the user 120 can provide a voice command to activate the radio function of the vehicle 105 and request a specific station. The motion sensor can be a vision sensor (e.g., a camera), an infrared sensor, a RADAR sensor, etc. configured to collect gesture input from the user 120. For example, the user 120 can provide a gesture motion to adjust the temperature function of the vehicle 105, thereby reducing the temperature inside the vehicle.

[0096] The controllers 355A - 355C can be configured to transmit a signal to another in - vehicle system. The signal can encode data associated with the corresponding vehicle function. For example, the encoded data can indicate, for example, function settings, timing, etc. In an example, such data can be used to generate content for presentation via the display device 345 (e.g., showing the current settings). Additionally or alternatively, such data can be included in the vehicle data 335 and sent to the computing platform 110.

[0097] Figure 3 A diagram of the computing platform 110 remote from the vehicle according to an embodiment of the present disclosure is illustrated. As described herein, the computing platform 110 can include a cloud - based computing platform. The computing platform 110 can be implemented on one or more servers and includes or otherwise accesses one or more databases. In an example, the computing platform 110 can be implemented using different servers based on the geographical region.

[0098] In some embodiments, the computing platform 110 can include a layered infrastructure that includes multiple layers. For example, the computing platform 110 can include a cloud - based layer associated with functions such as security, automation, monitoring, and resource management. The computing platform 110 can include a cloud application platform layer associated with functions such as charging station functions, real - time traffic, vehicle functions, vehicle sharing functions, etc. The computing platform 110 can include applications and services built on these layers.

[0099] The computing platform 110 can be a modularly connected service platform that includes multiple services available for the vehicle 105. In an example, the computing platform 110 can include a container-based microservices mesh platform. Each service can be represented or implemented as a system within the computing platform 110. The computing platform 110 can also include functions related to the simulation of the components, services, and subsystems of the computing platform. As further described herein, this can be achieved by using a test computing system that is part of (or at least communicates with) the computing platform 110.

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

[0101] The computing platform 110 can include a remote assistance system 415. The remote assistance system 415 can provide assistance to the vehicle 105. This can include providing information to the vehicle 105 to assist with charging (e.g., charging location recommendations), remotely controlling the vehicle (e.g., for AV assistance), roadside assistance (e.g., for collisions, flat tires), etc. The remote assistance system 415 can obtain assistance data 420 to provide its core functions. The assistance data 420 can include information that may help the remote assistance system 415 assist the vehicle 105. This can 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, the battery level / fuel level, event data, etc. In some embodiments, the assistance data 420 can include vehicle data 335.

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

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

[0104] The computing platform 110 may include a navigation system 435 that provides backend routing and navigation services for the vehicle 105. The navigation system 435 may provide map data 440 to the vehicle 105. The map data 440 may be used 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 a route to a destination requested by the vehicle 105 (e.g., via user input to the vehicle's host unit). The route 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.

[0105] The computing platform 110 may include an entertainment system 445. The entertainment system 445 may access one or more databases of entertainment data 450 for the user 120 of the vehicle 105. In some embodiments, the entertainment system 445 may access 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 of the vehicle 105 (e.g., a display device, speakers, etc.).

[0106] 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 otherwise communicate with one or more backend services for providing software updates 460 to the vehicle. For example, the vehicle software system 455 (or its services) may maintain or otherwise access a data structure (e.g., a list, a table) that indicates the current software or its version downloaded to a particular vehicle. The vehicle software system 455 (or its services) may also maintain a data structure indicating software packages or versions to be downloaded by a particular vehicle. In some embodiments, the vehicle computing system 200 may maintain a data structure indicating computing hardware, charging hardware, or other hardware resources on a particular vehicle. These data structures may be organized by vehicle identifier (e.g., VIN) such that the computing platform 110 may perform a lookup function based on the vehicle identifier to determine the associated software (and updates) for a particular vehicle.

[0107] When the vehicle 105 is connected to the computing platform 110 and available for software updates to the vehicle, the vehicle 105 may request software packages (such as software updates) from the computing platform. The computing platform 110 may provide one or more software updates 460 to the vehicle 105 via the network 130 as over-the-air (OTA) software packages (also referred to as "OTA software updates" or "OTA updates"). The OTA software packages (OTA updates) may include a new version of the software currently downloaded to the vehicle or a new software application to be downloaded to the vehicle.

[0108] Figure 4 Illustrates a diagram of a computing ecosystem for providing OTA software packages for a vehicle 105 according to one embodiment of the present disclosure. Figure 4 Shows a portion of the computing platform 110, such as, for example, the vehicle software system 455. To help orchestrate / coordinate the distribution of software updates 460 (e.g., OTA updates) to the vehicle, the computing platform 110 (e.g., the vehicle software system 455) may include a remote update controller system 500. The remote update controller system 500 is also referred to herein as the update controller 500. The update controller 500 may be configured to act as an orchestrator for OTA software packages and as a liaison node for the vehicle when the vehicle 105 obtains an OTA software package.

[0109] The update controller 500 may include and communicate with various systems / components to coordinate OTA software packages. Figure 5 Illustrates a diagram of the update controller 500 and other systems with which the update controller 500 may communicate to orchestrate the distribution of OTA software packages.Figure 5 An update controller 500 and its ecosystem for distributing OTA software packages to actual vehicles in an actual real-time (real world) environment can be represented.

[0110] The update controller 500 can be implemented on a cloud computing infrastructure 505. This can include the infrastructure of the computing platform 100. The cloud computing infrastructure 505 can include an underlying framework and components capable of delivering cloud computing services over a network (e.g., the Internet). The cloud computing infrastructure 505 can be provided by a cloud computing service provider. The cloud computing service provider can allow entities to access computing resources on demand, adjust / consume resources as needed, etc. The cloud computing infrastructure 505 can 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).

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

[0112] The cloud computing infrastructure 505 can include storage resources and networking resources. For example, the cloud computing infrastructure 505 can provide various types of storage options, such as object storage, file storage, block storage, etc. These storage resources can be accessed over a network and allow entities to store and retrieve data. The cloud computing infrastructure 505 can include networking components (such as routers, switches, and load balancers) that enable communication between different components of the cloud system. Network connectivity can ensure data transfer and accessibility across distributed servers and data centers.

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

[0114] The cloud computing infrastructure 505 can utilize virtualization technology. Virtualization technology can enable the creation of virtual instances of servers, operating systems, and other resources. This helps to provide efficient resource allocation, scalability, and isolation for different cloud tenants (users or entities) on a shared physical infrastructure.

[0115] The update controller 500 can communicate with multiple 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 of the vehicle 105 ( Figure 5 not shown in). The update controller 500 can receive a request (or other type of communication) generated by the vehicle computing system 500, which indicates that the vehicle 105 is available for the OTA software package 515. In an example, the vehicle 105 can be considered available for the OTA software package 515 if the vehicle 105 has network connectivity to receive data packets / payloads associated with the OTA software package 515 and / or sufficient computing resources (e.g., processing resources, memory resources, power resources, etc.) to download and configure the OTA software package 515 on the vehicle 105.

[0116] The update controller 500 can communicate with one or more consumer systems 520. The consumer system 520 can be a computing system configured to create rules 522 for distributing the OTA software package 515.

[0117] The rule 522 can be associated, for example, with an activity for updating certain software versions on a group of vehicles (e.g., certain vehicle models of a specific year X) or an activity for providing a new software package to a group of vehicles (e.g., a new in-vehicle chatbot for finding music content). The rule 522 can define which vehicles are to receive / apply the software update and which OTA updates 515 will be provided to the target vehicles. For example, the rule 522 can be a combination of characters, text strings, etc., for explicitly describing the intention to distribute / give a given OTA update 515 to a specific group of vehicles.

[0118] A "task" can represent an instance of the rule 522: The rule is applied to a single vehicle 105 such that when the vehicle 105 communicates with the update controller 500, the update controller 500 notifies the vehicle 105 of the task and the vehicle computing system 200 executes the task. The task can include actions that the vehicle 105 will take to implement the OTA software package 515. This can include, for example, downloading a software update package over a network, updating / changing the configuration of a certain component of the vehicle 105, etc.

[0119] Consumer system 520 can automatically create rules 522 or allow manual creation of rules 522. For example, consumer system 520 can be configured to automatically create rules 522 once OTA software package 515 has been verified, deployed, released, or otherwise made available for distribution. Additionally or alternatively, consumer system 520 can include a display device configured to present a user interface to a user of consumer system 520. The user interface can allow the user to provide user input to create rules 522.

[0120] Update controller 500 can communicate with one or more external software services 525 to facilitate distribution of OTA software package 515 according to rules 522. External software services 525 may also be referred to herein as “dependencies” 525. External software services 525 can include platform-based systems such as backend software services (e.g., microservices). External software services 525 can include services that process or maintain information that can help determine whether rules 522 apply to a particular vehicle 105 and the actions that vehicle 105 should take to implement OTA software package 515 associated with rules 522. In an example, dependency 525 can include a vehicle call service that maintains / accesses one or more data structures including vehicle identification numbers (VINs) of all vehicles. Dependency 525 can include a vehicle configuration service configured to access the vehicle configuration of a corresponding vehicle and external data associated with the vehicle configuration service. In another example, dependency 525 can include a vehicle document (VDOC) service. The VDOC service can include an external vehicle metadata service that maintains records of the current and / or past configurations of each corresponding vehicle in each respective vehicle and any documents (e.g., required by regulations).

[0121] Update controller 500 can include one or more services, components, systems, etc. configured to help orchestrate / coordinate OTA software packages. For example, update controller can include a vehicle service 530 responsive to traffic from vehicle 105. For example, vehicle service 530 can be configured to receive a request 510 for OTA software package 515 from vehicle 105. If there is an OTA software package applicable to vehicle 105, request 510 can include data indicating that vehicle 105 is available for the OTA software package. In some embodiments, request 515 can be an explicit request for a particular (or any) OTA software package 515. Vehicle service 530 can be configured to respond to request 510 with a payload indicating OTA software package 515 and the actions that vehicle 105 should take to implement OTA software package 515.

[0122] 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 multiple other related responsibilities. For example, the controller component 536 may be configured to communicate with an external software service 525 or determine which external software services 525 to communicate with to gather information about a specific OTA software package 515. This may help the update controller 500 determine the actions that the vehicle 105 will take for a specific OTA software package 515. The controller component 535 may include, for example, a rules service (e.g., a microservice for evaluating rules), a service as a response for evaluating vehicle inventory, a device service, a data synchronization service, etc.

[0123] The update controller 500 may include a management service 540 that is configured to expose an interface for a consumer system 520 to interact with the update controller 500. The management service 540 may be configured to access data indicating rules 522 and interact with the controller component 535 to advance the rules 522 within the ecosystem. For example, the management service 530 may be configured to coordinate with the rest of the update controller ecosystem such that if the vehicle service 530 receives a request 510 from a vehicle 105 eligible to receive an OTA software package 515, the vehicle service 530 will be able to inform the vehicle 105 of the actions needed to implement the OTA software package 515.

[0124] As an example, the management service 540 may obtain a rule 522 for allocating an 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, and the update controller 525 may obtain information about the vehicle 105 from the external software service according to the rule 522 to correctly implement the OTA software package 515. The update controller 500 may package the collected information of the target vehicle 105 and output such information to the vehicle 105 via the vehicle service 530. This may allow the vehicle computing system 200 (on the vehicle 105) to take appropriate actions to implement the OTA software package 515.

[0125] While Figure 5The examples described herein illustrate services and systems that can be used to communicate an OTA software package 515 to a vehicle based on a request from vehicle 105. However, the techniques of the present disclosure improve upon these services / systems to intelligently determine that vehicle 105 is available / eligible to receive an OTA software package (without an explicit request from the vehicle), and communicate the OTA software package 515 to a computing system at a physical location where vehicle 105 is expected to be available. This can be achieved such that when the vehicle may be idle (e.g., not being used by its owner), vehicle 105 downloads the OTA software package 515 via a local cache storage device located within the location. As further described herein, this can improve the reliability and efficiency of delivering OTA software packages to vehicles.

[0126] Figure 6 Illustrates a diagram of an example computing ecosystem 600 and data flows for caching OTA software packages according to an embodiment of the present disclosure. As further described herein, Figure 6 the computing ecosystem 600 can be used in association with a vehicle maintenance station / site. Such locations are not meant to be limiting, as other types of locations and facilities can utilize the described techniques.

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

[0128] The local computing system 605 can be associated with a specific location. For example, at least a portion of the local computing system 605 can be located at or on a physical premises of an entity. This can include maintenance / service locations (e.g., maintenance sites) for providing maintenance and other servicing to vehicles, dealerships, vehicle distribution facilities, vehicle production centers, manufacturing facilities (e.g., factories), charging stations, or other locations / entities. The local computing system 605 can include a reservation scheduling system 615 and a local package repository 620. In an example, one or both of the reservation scheduling system 615 or the local package repository 620 can be part of the local computing system 605 located at the physical premises of an entity (e.g., hosted on a server, database, etc. located at a maintenance site).

[0129] The remote computing system 610 can be remote from the specific location associated with the local computing system 605. For example, the remote computing system 610 can be a computing platform 110, included within or otherwise including the computing platform. In some embodiments, the remote computing system 610 can include an update controller 500. Figure 6 One or more of the components / subsystems of the remote computing system 610 described and illustrated herein can be implemented within the update controller 500.

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

[0131] The historical maintenance data can indicate the history of maintenance and servicing performed on the vehicle 105. The reservation planning system 615 can analyze this data to predict / determine the appropriate time for the vehicle 105 to receive the next maintenance. This can be determined based on the predicted mileage of the vehicle 105 since its last maintenance, purchase, etc. Additionally or alternatively, this can be determined based on the previous services provided (or not provided) to the vehicle during its last maintenance.

[0132] In some embodiments, the reservation planning system 615 can trigger a notification indicating the scheduled reservation. The notification can be transmitted to the user device 115 of the user 120 of the vehicle 105. In some embodiments, the notification can be transmitted to the vehicle computing system 200 of the vehicle 105. The notification can be displayed to the user 120 (e.g., via a display device). In some embodiments, the user 120 can confirm, reject, or modify the reservation by providing user input in response to the notification. Data indicating the confirmation, rejection, and / or modification can be provided to the reservation planning system 615.

[0133] The reservation planning system 615 can provide an advance notice 625 to a local (software) package repository 620. The advance notice 625 can indicate the date and location of the reservation (or predicted reservation). The advance notice 625 can indicate the time when the vehicle 105 is expected to be at the location (e.g., the maintenance site). The advance notice 625 can indicate the vehicle identifier associated with the vehicle 105. The vehicle identifier can include, for example, a vehicle identification number.

[0134] The download coordinator 635 of the local package repository 620 can obtain the advance notice 625. The download coordinator 635 can 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 can process the advance notice 625 to parse or otherwise identify the vehicle identifier of the vehicle 105. The download coordinator can determine the OTA software packages available for the vehicle based on the vehicle identifier.

[0135] To this end, the download coordinator 635 can communicate with the remote computing system 610. For example, the download controller 635 can send vehicle metadata 640 to the (software) package parser 645 of the remote computing system 610. The vehicle metadata 640 can indicate the vehicle identifier of the vehicle 105. In some embodiments, the vehicle metadata 640 can include an estimated time that the vehicle 105 is expected to be at the location.

[0136] The package parser 645 can be configured to process the vehicle metadata 640 and determine whether any OTA packages are applicable to the vehicle 105. For example, the package parser 645 can include or communicate with an update controller 500 that can use the vehicle identifier to determine whether any OTA packages are available or will be available in the future for the vehicle 105. This can include, for example, invoking one or more external services 525 as described herein. In some embodiments, the package parser 645 can use the time that the vehicle 105 is expected to arrive at the maintenance location to determine whether any OTA packages that are not currently available but may become available before the vehicle 105 is expected to arrive at the maintenance location. This can include, for example, any pending or beta-test OTA updates that are scheduled for production before the estimated time that the vehicle 105 is expected to arrive at the location.

[0137] (Software) The package parser 645 can communicate relevant package metadata 650 to the local package repository 620. The relevant package metadata 650 can include information about one or more OTA packages that are available for the vehicle 105. The metadata can include identifiers associated with the OTA packages, such as names, links, reference numbers, serial numbers, file names, strings, etc. This can include, for example, identifiers associated with an OTA package for updating the software version of the infotainment system on the vehicle 105. The relevant package metadata 650 can include the vehicle identifier associated with the vehicle 105.

[0138] The download coordinator 635 may receive relevant (software) package metadata 650. The download coordinator 635 may be a module configured to generate instructions for queuing data payloads for the vehicle 105. In an example, the download coordinator 635 may generate prioritized download work items 655 based on the relevant package metadata 650. The prioritized download work items 655 may be units passed through a workflow instance (e.g., running a workflow model) associated with the download coordinator 635. The prioritized download work items 655 may include data for the instance to act on, references associated with underlying workflow steps, etc. The download coordinator 635 may process the relevant package metadata 650 to identify the vehicle 105 and applicable OTA software updates (e.g., via the vehicle identifier), and then generate prioritized download work items 655 such that the prioritized download work items reflect this information in a manner that can be processed by downstream participants in the workflow. Additionally, the prioritized download work items 655 may include a time associated with the vehicle 105. This may indicate the time when the vehicle 105 is scheduled or predicted to be at a specific location associated with the local computing system 605.

[0139] 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 in the queue to place the prioritized download work items. The corresponding prioritized download work items 655 may be stored in a manner associated with the corresponding vehicle identifier.

[0140] The queue may indicate the order, priority, etc. of each prioritized download work item 655 stored in the queue for download 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 specific location (e.g., a maintenance site). Additionally or alternatively, the prioritized download work items 655 may be queued based on their associated OTA software updates. For example, the more vehicles to which a particular OTA software update applies, the higher the priority of the associated prioritized download work item 655 in the queue. The number of vehicles to which an OTA software update applies may be determined based on the relevant package metadata 650 (e.g., provided by the download coordinator 655) or the prioritized download work items 655 (e.g., provided by the download queue).

[0141] In some embodiments, the OTA software packages may be queued based on the confidence that the vehicle 105 will arrive at the location at the planned / estimated time. The local computing system 605 (e.g., the download coordinator 635) may determine the confidence in the time when the vehicle 105 is expected to be at the location, and queue the OTA software packages (e.g., work items, and thus requests) based on that confidence.

[0142] For example, in the case of a scheduled appointment, the confidence level can be determined based on historical data indicating the arrival time, delay, cancellation, etc. of the appointment associated with vehicle 105. In the case where appointments associated with vehicle 105 are frequently cancelled, the confidence level that vehicle 105 will arrive at the estimated time may be lower, and the prioritized download work item 655 may be deprioritized or adjusted to a lower priority in the queue. In the case where vehicle 105 has historically arrived at the maintenance site on time (with few cancelled appointments), the confidence level of the estimated time may be higher, and the prioritized download work item 655 can be moved up in the download queue 660.

[0143] In the case of scheduling an appointment based on predicted maintenance requirements, the confidence level can be based on the confidence level in the prediction. For example, the local computing system 605 can determine its maintenance prediction based on various signals. Some signals can provide a stronger indication that vehicle 105 should receive maintenance and thus vehicle 105 will arrive at a particular location. This can include, for example, the time since the last maintenance and the predicted mileage based on the mileage at the previous maintenance. In the case where the predicted time is more based on these stronger signals, the confidence level may be higher.

[0144] The download coordinator 635 and / or the download queue 660 can communicate with the download manager 665. The download manager 655 can include control circuitry configured to request relevant OTA packages and receive the OTA packages in response to the request. The download manager 655 can access the download queue 660 (e.g., receive from the download queue, pull from the download queue, look up the download queue, call the download queue, obtain via the download queue, read the download queue, otherwise communicate with the download queue) to determine the available OTA packages for vehicle 105 and vehicle 105 (e.g., based on the vehicle identifier).

[0145] Based on the information in the download queue 660 (e.g., priority, order, etc.), the download manager 655 can access the relevant OTA packages. As an example, the download manager 665 can access the download queue 660 and obtain data indicating the vehicle identifier associated with vehicle 105 and information associated with the OTA packages available for vehicle 105 (e.g., the identifier of the OTA package). As described herein, this information can be stored within the prioritized download work item 655 within the download queue 660.

[0146] In some specific implementations, the download manager 665 may determine whether an OTA software package for the vehicle 105 has been stored in the local cache storage device 670, which is located at a location associated with the local computing system 605. For example, the download manager 665 may use information associated with the OTA software package (e.g., the identifier of the OTA software package) to query the local cache storage device 670 to determine whether the OTA software package has been stored in the local cache storage device 670. In some specific implementations, this may include accessing a lookup table that indicates the OTA software packages stored in the local cache storage device 670. In the case where the local cache storage device 670 includes the relevant OTA software package for the vehicle 105, the download manager 665 may forego communicating with the remote computing system 610 to request the OTA software package.

[0147] In some specific implementations, the download manager 665 may convey a request 675 for the relevant OTA software package to the remote computing system 610. For example, this may occur when the OTA software package has not been downloaded to the local cache storage device 670. The download manager 665 may generate the request 675 based on information associated with the OTA software packages included in the download queue. This may include the relevant package metadata 650 and / or the identifier associated with the OTA software package, which may be used by the remote computing system 610 to access the OTA software package.

[0148] In one example, the remote computing system 610 may include a central (software) package repository 680. The central package repository 680 may be configured to return the relevant 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 relevant package metadata 650 (and / or other information associated with the relevant OTA software package) to obtain the OTA software package 685. The remote computing system 610 may be configured to convey the OTA software package 685 to the download manager 665 via a network. The download manager 665 may be configured to obtain the OTA software package 685 for the vehicle 105 from the remote computing system 610 via the network.

[0149] In some specific implementations, the local computing system 605 may be configured to shape the downlink bandwidth for extracting the OTA 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 used for communication between the local computing system 605 and the remote computing system 610. The network traffic data may indicate the historical, current, or estimated future available bandwidth, speed, interruptions, maintenance, etc. of the network during one or more corresponding time periods of the day. The download manager 665 may determine a time period for obtaining the OTA package 685 over the network based on the network traffic data. As an example, the download manager 665 may determine that the network bandwidth and download speed are higher during the period from 1:00 am to 3:00 am ET, and / or it is less costly (e.g., in terms of cost or computing) to extract the OTA package 685 from the remote computing system 610 during this time period. Therefore, the download manager 665 may send a request 675 during the period from 1:00 am to 3:00 am ET, such that the OTA package 685 is provided from the remote computing system 610 during this time period.

[0150] In some specific implementations, the download manager 665 may send a request 675 during a time period other than from 1:00 am to 3:00 am ET, and the request 675 may indicate a preferred time period (e.g., during the period from 1:00 am to 3:00 am ET) when the download manager 665 wants to obtain the OTA package 685. In this way, the download manager 665 may send a lighter-weight (e.g., smaller amount of data) request 675 during a time period of higher network traffic, but receive a heavier (e.g., larger amount of data) OTA package 685 during a time period of lower network traffic.

[0151] Before the time when the vehicle 105 is expected to arrive at a specific location associated with the local computing system 605, the download manager 665 may provide the OTA package 685 to the local cache storage device 670 for storage. The OTA package 685 may be stored in a manner associated with the vehicle identifier associated with the vehicle 105.

[0152] This may ensure that when the vehicle 105 is at the location associated with the local computing system 605, the relevant OTA package 685 will be available for the vehicle 105.

[0153] When the vehicle 105 is at a particular location, the OTA software package 685 can be accessed by the software update system 690. For example, the software update system 690 can determine that the vehicle 105 has reached the location and that the vehicle 105 is available for the OTA software package 690. The vehicle 105 (and / or another system) can provide communications indicating that the vehicle 105 is ready to receive any available OTA software package, that the vehicle 105 will be available to download the OTA software package within a particular time period, that the vehicle 105 is connected to a local (e.g., wired or wireless) network such that the vehicle can receive the OTA software package, the vehicle identifier associated with the vehicle 105, or other information. In some embodiments, the software update system 690 can determine that the time period during which the vehicle 105 is available for download is sufficient time (e.g., given available bandwidth, network speed, etc.) to download the OTA software package 685 from the local cache storage device 670 at the location.

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

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

[0156] In some specific implementations, the local computing system 605 may adjust the maintenance schedule of the vehicle 105 based on the OTA software update 685. As an example, the local computing system 605 (e.g., the download coordinator 635, the download manager 665) may determine that the OTA software package 685 is too large to be downloaded to the vehicle 105 within the current scheduled time frame (e.g., 30 minutes) that the vehicle 105 is at the location. In response, the local computing system 605 (e.g., the reservation scheduling system 615) may adjust the maintenance schedule to extend the reservation or change the reservation to another time slot and / or date, so as to provide sufficient time (e.g., 60 minutes) to download the OTA software package 685 for the vehicle 105.

[0157] In some specific implementations, the local computing system 605 may consider changes to the schedule. This may include changes such as reservation cancellations, ad-hoc changes, etc. The local computing system 605 may model a compensation mechanism for canceling the scheduled download of the OTA software package 685, assuming that it has not started / been completed yet. In some specific implementations, the OTA software package 685 may be removed from the local cache storage 670. For example, this may occur in a situation where the reservation is canceled and not rescheduled, and it is not known when the vehicle 105 will be at a specific location (e.g., a maintenance site), and the OTA software package 685 is not relevant to another vehicle that is scheduled or predicted to be at that location.

[0158] In some specific implementations, a time-to-live (TTL) may be used to manage the local cache based on the cache expiration time. For example, the TTL may identify the amount of time that the OTA software package can be retrieved from the local cache 670. The TTL may be reset and / or incremented whenever an additional vehicle is identified as applicable to the OTA software package. For example, when it is determined / predicted that a vehicle to which a specific OTA software package is applicable will be at the location of the local computing system 605, the TTL associated with that OTA software package may be "extended". Additionally or alternatively, when a vehicle initiates a download of a specific OTA software package via the local cache 670, the TTL associated with that OTA software package may be "extended".

[0159] The local cache 670 may be cleared to allow an updated OTA software package to be included in the local cache 670. For example, a newer version of the OTA software package may be identified / requested for download in the local cache 670. Clearing the local cache 670 notifies the local cache 670 to stop serving cached objects associated with the older OTA software package in response to vehicle requests, and instead extract the newer object (such as the newer OTA software package). This may help better manage the limited resources of the local cache 670.

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

[0161] The local computing system 605 may obtain data indicating a vehicle identifier associated with the vehicle 105 and the time the vehicle 105 is expected to be at the location (e.g., maintenance location). This information may be retrieved from an accessible database of the VIN and included in the notification.

[0162] At (710), the local computing system 605 may resolve any required update packages for the vehicle 105. For example, the local computing system 605 may determine an OTA software package 685 available for the vehicle 105 based on the 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 (e.g., using the package resolver 645) may determine if there are any OTA software packages available for the vehicle 105. As described herein, this may include OTA software packages intended for the make and model of the vehicle 105 that have not been downloaded to the vehicle 105 (e.g., for an update to an infotainment software version). The local computing system 605 may obtain a communication from the remote computing system 610 indicating the available OTA software package or lack thereof (e.g., via associated metadata).

[0163] In the case where there is at least one OTA software package 685 available for the vehicle 105, the local computing system 605 may determine at (715) whether the relevant OTA software package 685 has been locally cached. If so, the local computing system 605 may update the download manager 665 to associate the vehicle identifier of the vehicle 105 with the relevant OTA software package 685 in the local cache storage 670. At (720), when the vehicle 105 is at the location of the maintenance site (e.g., the local computing system 605), the local computing system may use the cached OTA software package 685 to update the software on the vehicle 105 at (730). This may end the algorithmic process 700 at (735).

[0164] In the case where the relevant OTA software package 685 has not been locally cached, the local computing system 605 may obtain and cache the relevant OTA software package 685 at the local cache storage device 670. The local computing system 605 may obtain the OTA software package 685 applicable to the vehicle 105 from the remote computing system 610 via a network based on the vehicle identifier. For example, as described herein, the local computing system 605 may (e.g., at 710) use the vehicle identifier of the vehicle 105 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 embodiments, 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. Before the time when the vehicle 105 is expected to arrive at the location (e.g., maintenance site), the local computing system 605 may provide the OTA software package 685 to the local cache storage device 670, which is stored on computing hardware physically located at the location.

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

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

[0167] 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 at the VPC and the status of each vehicle. In an example, the vehicle 850 may be indicated by a vehicle identifier associated with the vehicle 850 (such as a VIN). The status of the corresponding vehicle may indicate the stage, status, etc. of the corresponding vehicle within the VPC. This may include, for example, a status indicating that the corresponding vehicle is ready for distribution from the vehicle production center, ready for any software updates, time, etc. The VPC inventory management system 810 at the VPC may store the vehicle identifier of the vehicle 850 in a data structure in a manner associated with the status of the vehicle 850. The VPC inventory management system 810 may provide a notification 815 that indicates the status of the vehicle 850 and the vehicle 105 within the VPC (e.g., using the vehicle identifier).

[0168] The local computing system 805 may predict the time when the vehicle 850 is expected to be ready to receive an OTA software package at 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 stage of the VPC and will therefore soon be ready to download the relevant OTA software package.

[0169] The local computing system 805 may include a local package repository 820. The local package repository 820 may include or otherwise be associated with a download manager that is configured to request a relevant OTA software package for the vehicle 850 at the VPC. To this end, the download manager may send a request 825 to the remote computing system 610. The request 825 may include a vehicle identifier and / or data indicating the relevant OTA software package (e.g., relevant package metadata, reference number, or other identifier). The central package repository 680 may return an OTA software package 830 that is available for and applicable to the vehicle 850. The OTA software package 830 may include one or more software updates to one or more software applications on the vehicle 830. Additionally or alternatively, the OTA software package 830 may include a new software application for the vehicle 830 that is not currently downloaded to the vehicle 830. In some embodiments, the OTA software package 830 may include software updates / packages that have been requested, permitted, purchased, etc. by the user of the vehicle 850.

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

[0171] The local computing system 805 may include a vehicle software update system 835 that manages the distribution of OTA software updates 830 to a vehicle 850. For example, the local computing system 805 may generate instructions for the vehicle software update system 835 to provide an OTA software package 830 (or a portion thereof) to the vehicle 850 for download. In some embodiments, the vehicle software update system 835 may detect that the vehicle 850 is available for an update (e.g., due to the vehicle 850 connecting to a network, a notification from another system, a request / notification from the vehicle 850) and instruct the provision of the OTA software package 830 (or a portion thereof) to the vehicle 850.

[0172] After the vehicle 850 downloads the OTA software package 830, a shadow record of the vehicle 850 at the remote computing system 610 may be updated. The shadow record may indicate, at least at some point, the state of the software suite on the vehicle 850 when the vehicle 850 leaves the VPC.

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

[0174] 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 and the status of each vehicle. In the 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 manufacturing stage, status, etc. of the vehicle 950 within the facility. This may include, for example, a status indicating that the vehicle 950 is ready or will be ready for any software updates, the time associated with the vehicle, etc. The production logistics system 910 may store the vehicle identifier of the vehicle 950 in a data structure in a manner associated with the status of the vehicle 950. The production logistics system 910 may provide a notification 915 that indicates the vehicle 950 (e.g., using the vehicle identifier) and the status of the vehicle 950 within the facility.

[0175] The local computing system 905 may predict the time when the vehicle 950 is predicted 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 may determine that the vehicle 950 is in the final stage of the facility and will therefore soon be ready to download the relevant OTA software package.

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

[0177] To this end, the download manager may transmit a request 925 to the remote computing system 610. As described herein, the request 925 may include a vehicle identifier and / or data indicating the relevant OTA software package (e.g., relevant package metadata, reference number, other identifier). The central package repository 680 may return an OTA software package 930 that is available for and applicable to the vehicle 950. The OTA software package 930 may include one or more software updates to one or more software applications on the vehicle 930. Additionally or alternatively, the OTA software package 930 may include a new software application for the vehicle 950 that is not currently downloaded to the vehicle 950. In some embodiments, the OTA software package 930 may include software updates / software packages that have been requested, permitted, purchased, etc. by the user of the vehicle 950.

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

[0179] The local computing system 905 may include a vehicle software update system 940, which may manage the distribution of the OTA software update 930 to the vehicle 950. For example, the local computing system 905 may 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 embodiments, the vehicle software update system 940 may detect that the vehicle 950 is available for an update (e.g., due to the vehicle 950 being connected to the network, a notification from another system, a request from the vehicle 950), and instruct to provide the OTA software package 930 (or a portion thereof) to the vehicle 950.

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

[0181] Figure 10Illustrated is a diagram of an example computing ecosystem 1000 and data flow for caching OTA software packages according to embodiments of the present disclosure. In this example, the local computing system 1005 may be located at a charging station.

[0182] The local computing system 1005 may include a charging reservation system 1010. The charging reservation system 1010 may be configured to maintain a database indicating reservations / allocations of vehicles to chargers at the charging station. In the example, the vehicle 1050 may be indicated by a vehicle identifier associated with the vehicle 1050, such as the VIN of the vehicle. The charger reservation may be reflected as a data entry in a data structure (e.g., a table) that indicates the VIN of the vehicle 1050 associated with the identifier of the charger. The reservation may also indicate the time when the vehicle may be using the charger.

[0183] In some embodiments, the charging reservation system 1010 may maintain a data structure indicating that the vehicle 1050 will be / is predicted to be at the charging station but no specific charger has been allocated to the vehicle.

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

[0185] In some embodiments, the reservation may be created based on a prediction that the vehicle may be charged at the charging station at a future time. As described herein, the prediction may be based on a vehicle usage pattern that indicates that the user of the vehicle typically charges the vehicle when the vehicle reaches a certain battery level. Additionally or alternatively, the charging station may be an identified candidate for charging the vehicle when the vehicle travels along a specific route.

[0186] The local computing system 1005 may predict the time when the vehicle 1050 is expected to be ready for an OTA software update at the charging station. For example, the local computing system 1005 may determine that the vehicle 1050 will be ready to download the relevant OTA software package as long as the vehicle 1050 is connected to the charger (e.g., via a communication link for data transfer included in the charging connector).

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

[0188] Accordingly, the download manager may transmit a request 1025 to the remote computing system 610. As described herein, the request 1025 may include a vehicle identifier and / or data indicating a relevant OTA software package (e.g., relevant package metadata, reference number, or other identifier). The central package repository 680 may return an OTA software package 1030 that is available for and applicable to the vehicle 1050. The OTA software package 1030 may include one or more software updates to one or more software applications installed on the vehicle 1030. Additionally or alternatively, the OTA software package 1030 may include a new software application for the vehicle 1050 that has not yet been downloaded to the vehicle 1050. In some embodiments, the OTA software package 1030 may include software updates / software packages that have been requested, permitted, purchased, etc. by the user of the vehicle 1050.

[0189] The size of the OTA software package 1030 may be designed such that: given the download speed of the data connection of the vehicle 1050 to the local computing system 1005, the vehicle 1030 is capable of downloading the OTA software package 1030 while the vehicle 1030 is charging. The charging time may be determined based on the predicted battery level of the vehicle 1050 when it arrives at the charging station and the speed of the assigned charger. The download manager may provide data indicating 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 capable of being downloaded during the time the vehicle 1050 is charging.

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

[0191] The local computing system 1005 may include a vehicle software update system 1040 that may manage the distribution of the OTA software update 1030 to the vehicle 1050. For example, the local computing system 1005 may 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 embodiments, the vehicle software update system 1040 may detect that the vehicle 1050 is available for update (e.g., due to the vehicle 1050 starting to charge, connecting to the network via the charger / wirelessly, a notification from another system, a request from the vehicle 1050) and instruct the OTA software package 1030 (or a portion thereof) to be provided to the vehicle 1050.

[0192] After the vehicle 1050 downloads the OTA software package 1030, the shadow record of the vehicle 1050 at the remote computing system 610 can be updated. The shadow record can indicate, at least at some point, the state of the software suite on the vehicle 1050 in the following situations: after downloading the OTA software package 1030, when the vehicle 1050 finishes charging, when the vehicle 1050 leaves the charging station, etc.

[0193] Figures 11A to 11C A flowchart diagram illustrating an example method for allocating an OTA software package to a local cache according to an embodiment of the present disclosure. The method can be executed by a computing system described with reference to other figures (e.g., Figures 1 to 10 , Figure 12 ). In one embodiment, the method can be executed by the control circuit of the computing system. One or more parts of the method can be implemented as algorithms on the hardware components of the devices described herein. For example, the steps of the method can be implemented as operations / instructions capable of being executed by computing hardware. This can include one or more non-transitory computer-readable media that store instructions capable of being executed by the control circuit to perform Figures 11A to 11C the operations.

[0194] Figures 11A to 11C Elements are illustrated and discussed in a particular order for purposes of illustration. In using the disclosure provided herein, one of ordinary skill in the art will understand that the elements of any of the methods discussed herein can be adapted, rearranged, extended, omitted, combined, or modified in various ways without departing from the scope of the present disclosure.

[0195] Figures 11A to 11C is described with reference to elements / terms described with respect to other systems and figures for purposes of example illustration and is not meant to be limiting. One or more parts of the method can additionally or alternatively be executed by other systems.

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

[0197] In an example, the location associated with the local computing system can be a maintenance location. The local computing system 605 can obtain data indicating a scheduled maintenance for the vehicle 105. The local computing system 605 can determine the time when the vehicle 105 is expected to arrive at the maintenance location based on the scheduled maintenance for the vehicle 105. The data indicating the scheduled maintenance can be a reservation notice including the vehicle identifier of the vehicle 105.

[0198] Additionally or alternatively, the local computing system 605 can obtain historical maintenance data associated with the vehicle 105. The historical maintenance data can indicate past maintenance or servicing records of the vehicle 105, outstanding maintenance, service dates, service types, etc. The local computing system 605 can predict the time when the vehicle 105 is expected to arrive at the maintenance location based on the historical maintenance data associated with the vehicle 105. For example, the historical maintenance data can indicate that the vehicle 105 had an oil change 14 months ago, and the mileage of the vehicle at that time was 24,000 miles. The historical maintenance data can indicate that on average, the vehicle 105 has an oil change every 3,000 miles, and the vehicle 105 travels approximately 200 miles per month. Therefore, the local computing system 605 can determine that the vehicle 105 is expected to arrive at the maintenance location within the next month.

[0199] In an example, the location associated with the local computing system 605 can be a charging station. For example, the vehicle 105 can be an electric vehicle (EV). The local computing system 605 can be configured to obtain historical charging data associated with the vehicle 105, and predict the time when the vehicle 105 is expected to arrive at the charging station based on the historical charging data associated with the vehicle 105. For example, the historical charging data can indicate the time, location, and frequency at which the vehicle 105 charges its battery. The local computing system 605 can use this information to predict that the vehicle 105 may arrive at the charging station within a certain time range this week.

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

[0201] In one embodiment, method 1100 may include operation 1115, in which a computing system may determine whether an OTA software package for a vehicle has been stored in local cache storage 670 located at the site. For example, local computing system 605 may access its local cache storage 670 to determine whether an OTA software package associated with vehicle 105 and available for the vehicle has been locally cached. To this end, local computing system 605 may generate a search query in the local cache and / or perform a lookup function using an identifier associated with the OTA software package (e.g., reference number, serial number, name). In the case where local cache storage 670 already includes the OTA software package, local computing system 605 may provide instructions associating the vehicle identifier of vehicle 105 with the OTA software package. This may include making data entries, completing data fields, etc., to indicate that the OTA software package should be assigned to vehicle 105 associated with a specific vehicle identifier.

[0202] If the OTA software package has been locally cached, local computing system 605 may not request the OTA software package from remote computing system 610.

[0203] In some cases, the OTA software package may not have been stored in local cache storage.

[0204] In one embodiment, method 1100 may include operation 1120, in which a computing system may obtain, via a network, an OTA software package applicable to a vehicle based on a vehicle identifier. For example, local computing system 605 may provide a first communication to remote computing system 610 to inquire whether there are any relevant OTA software packages applicable to vehicle 105. The first communication may include the 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 pending OTA software packages available for vehicle 105 (e.g., a given make, model, year of the vehicle) that have not yet been downloaded to vehicle 105.

[0205] In some specific implementations, remote computing system 610 may use the identifier associated with vehicle 105 to query a database storing the shadow record of vehicle 105. Remote computing system 610 may utilize the shadow record to determine whether the in-vehicle software of 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 vehicle 105. Remote computing system 610 may determine that a newer version of the infotainment software applicable to the make / model / year of vehicle 105 exists.

[0206] In some specific implementations, in response to the first communication inquiring whether there are any relevant OTA software packages applicable to vehicle 105, remote computing system 610 may identify the relevant OTA software package and send the relevant OTA software package to vehicle 105.

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

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

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

[0210] In some embodiments, a computing system can obtain an OTA software package based on network traffic associated with the network via which the OTA software package is obtained. This can include Figure 11C the operations of method 1180 shown. For example, at 1185, local computing system 605 can obtain network traffic data associated with the network. The network traffic data can be obtained by invoking an API of a third-party network monitoring service and transmitting a request for such data constructed based on the API. In response, local computing system 605 can obtain (e.g., from a third-party computing system) network traffic data indicating the current bandwidth, download speed, etc. of the network.

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

[0212] Return Figure 11A , in one embodiment, method 1000 can include operation 1125, in which the computing system can provide the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location. For example, in some embodiments, local computing system 605 can provide the OTA software package to the local cache storage device before the time when vehicle 105 can request / use the OTA software package.

[0213] In some specific implementations, the local computing system 605 may transmit a request to the remote computing system 610 at a certain time, such that the local computing system 605 can provide the OTA software package to the local cache storage device before the vehicle 105 arrives at the location or is otherwise ready to download / available for downloading the OTA software package.

[0214] In some specific implementations, the OTA software package may be queued based on the confidence that the vehicle 105 will be at the location (e.g., maintenance site, VPC, charging station, factory) at the planned / expected time. This may include Figure 11B the operations of the method 1150 shown. For example, at 1155, the local computing system 605 may determine the confidence of the time when the vehicle is expected to be at the location / ready to be at the location, as described herein. At 1160, the local computing system 605 may queue the OTA software package based on the confidence of the time when the vehicle is expected to be at the location. For example, the higher the confidence that the vehicle 105 will arrive faster, the higher the priority of the work item for downloading the OTA software package to the local cache in the queue may be.

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

[0216] In an embodiment, the method 1100 may include operation 1135, in which the computing system may output the OTA software package from the local cache storage device. As an example, the local computing system 605 may provide instructions to release an OTA software update for the infotainment software of the vehicle from the local cache storage device. This may allow the vehicle 105 to download the infotainment software update from the local cache storage device (instead of from the remote cloud platform).

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

[0218] Figure 12 FIG. illustrates a block diagram of an example computing system 7000 according to an embodiment of the present disclosure. System 7000 includes a computing system 6005 (e.g., a computing system on a vehicle), a remote computing system 7005 (e.g., a server computing system, a cloud computing platform, a test computing system, etc. away 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. Computing system 6005, remote computing system 7005, user device 8005, and network 9050 may represent the systems (and components of those systems) and networks described herein with reference to other figures.

[0219] Computing system 6005 may include one or more computing devices 6010 or circuits. For example, computing system 6005 may include control circuit 6015 and a non-transitory computer-readable medium 6020 (also referred to herein as a memory). In an embodiment, control circuit 6015 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuitry (PLC) or programmable logic devices / gate arrays (PLA / PGA), field programmable gate arrays (FPGA), application specific integrated circuits (ASIC), or any other control circuit. In some embodiments, control circuit 6015 may be part of or may form a vehicle control unit, which is embedded or otherwise disposed in a vehicle (e.g., in a car or truck). For example, the vehicle controller can be or can include an infotainment system controller (e.g., an infotainment host unit), a telematics control unit (TCU), an electronic control unit (ECU), a central powertrain controller (CPC), a charging controller, a central external and internal controller (CEIC), a zone controller, or any other controller. In an embodiment, the control circuit 6015 can be programmed by one or more computer-readable instructions or computer-executable instructions stored on a non-transitory computer-readable medium 6020.

[0220] In one embodiment, the non-transitory computer-readable medium 6020 can be a memory device (also referred to as a data storage device), which can 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 can form, for example, a hard disk drive (HDD), a solid-state drive (SDD), or a 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.

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

[0222] The non-transitory computer-readable medium 6020 may also store computer-readable instructions 6030 executable by the control circuit 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, if the computer-readable instructions 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 circuit 6015 to perform one or more functional tasks. When the control circuit 6015 or other hardware components are executing a module or computer-readable instructions, these modules and computer-readable instructions / computer-executable instructions may be described as performing various operations or tasks.

[0223] The instructions 6030 may be executed on the control circuit 6015 in logically and / or virtually separated threads. For example, the non-transitory computer-readable medium 6020 may store instructions 6030 that, when executed by the control circuit 6015, cause the control circuit 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 instructions or computer-readable instructions, such as instructions for performing Figures 11A to 11C at least a portion of the method of.

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

[0225] 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 a touchpad) that is sensitive to a user input object (e.g., a finger or a stylus). The touch-sensitive component may be used to implement a virtual keyboard. Other example user input components include a microphone, a traditional keyboard, a cursor device, a joystick, or other devices through which a user may provide user input.

[0226] 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 in an auditory or visual manner. For example, the output components 6045 may include one or more speakers, earpieces, headphones, mobile phones, 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. As an 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 computer, and / or other suitable display components.

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

[0228] The remote computing system 7005 may include control circuitry 7015 and a non-transitory computer-readable medium 7020 (also referred to herein as memory 7020). In an embodiment, the control circuitry 7015 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuitry (PLC) or programmable logic element / gate array (PLA / PGA), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or any other control circuitry. In an embodiment, the control circuitry 7015 may be programmed by one or more computer-readable instructions or computer-executable instructions stored on the non-transitory computer-readable medium 7020.

[0229] In one embodiment, the non-transitory computer-readable medium 7020 may be a memory device (also referred to as a data storage device), which 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 a solid state integrated memory, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), portable compact disc read only memory (CD-ROM), or digital versatile disc (DVD) and / or a memory stick.

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

[0231] The non-transitory computer-readable medium 7020 can also store computer-readable instructions 7030 executable by the control circuit 7015. The instructions 7030 can be software written in any suitable programming language or can be implemented in hardware. The instructions can 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, if the computer-readable instructions 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 circuit 7015 to perform one or more functional tasks. When the control circuit 7015 or other hardware components are executing a module or computer-readable instructions, these modules and computer-readable instructions / computer-executable instructions can be described as performing various operations or tasks.

[0232] The instructions 7030 can be executed on the control circuit 7015 in logically and / or virtually separated threads. For example, the non-transitory computer-readable medium 7020 can store instructions 7030 that, when executed by the control circuit 7015, cause the control circuit 7015 to perform any of the operations, methods, and / or processes described herein. This can include the operations described as being performed by the test computing system 610. In some cases, the non-transitory computer-readable medium 7020 can store computer-executable instructions or computer-readable instructions, such as instructions for performing Figures 5 to 11C at least a portion of the data stream and method / process.

[0233] The server computing system 7005 can include one or more communication interfaces 7035. The communication interfaces 7035 can be used to communicate with one or more other systems. The communication interfaces 7035 can include any circuitry, components, software, etc. for communicating via one or more networks (e.g., network 9050). In some specific implementations, the communication interfaces 7035 can include, for example, one or more of a communication controller, receiver, transceiver, transmitter, port, conductor, software, and / or hardware for conveying data / information.

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

[0235] The user device 8005 may include one or more computing devices 8010. The user device 8005 may include control circuitry 8015 and a non-transitory computer-readable medium 8020 (also referred to herein as a memory 8020). In an embodiment, the control circuitry 8015 may include one or more processors (e.g., microprocessors), one or more processing cores, programmable logic circuitry (PLC) or programmable logic element / gate array (PLA / PGA), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or any other control circuitry. In an embodiment, the control circuitry 8015 may be programmed by one or more computer-readable instructions or computer-executable instructions stored on the non-transitory computer-readable medium 8020.

[0236] In an embodiment, the non-transitory computer-readable medium 8020 may be a memory device (also referred to as a data storage device), which 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 a solid state integrated memory, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), dynamic random access memory (DRAM), a portable compact disc read only memory (CD-ROM), a digital versatile disc (DVD), and / or a memory stick.

[0237] The non-transitory computer-readable medium 8020 may store information accessible 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 specific implementations, the user device 8005 may obtain data from one or more memories remote from the user device 8005.

[0238] The non-transitory computer-readable medium 8020 may also store computer-readable instructions 8030 executable by the control circuit 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, if the computer-readable instructions 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 circuit 8015 to perform one or more functional tasks. When the control circuit 8015 or other hardware components are executing a module or computer-readable instructions, these modules and computer-readable instructions / computer-executable instructions may be described as performing various operations or tasks.

[0239] The instructions 8030 may be executed in a logical or virtual separate thread on the control circuit 8015. For example, the non-transitory computer-readable medium 8020 may store instructions 8030 that, when executed by the control circuit 8015, cause the control circuit 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 instructions or computer-readable instructions, such as instructions for performing Figures 11A to 11C at least a portion of the method of.

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

[0241] 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 a touchpad) that is sensitive to a user input object (e.g., a finger or a stylus). The touch-sensitive component may be used to implement a virtual keyboard. Other example user input components include a microphone, a traditional keyboard, a cursor device, a joystick, or other devices through which a user may provide user input.

[0242] The user device 8005 may include one or more output components 8045. The output components 8045 may include hardware and / or software for generating content in an auditory or visual manner. For example, the output components 8045 may include one or more speakers, handsets, headphones, mobile phones, etc. The output components 8045 may include a display device, which may include hardware for displaying a user interface and / or messages for the user. As an example, the output components 8045 may include a display screen, CRT, LCD, plasma screen, touch screen, TV, projector, tablet computer, and / or other suitable display components.

[0243] One or more networks 9050 may be any type of communication 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. Generally, communication over the network 9050 may be carried via any type of wired and / or wireless connection using various communication protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encodings or formats (e.g., HTML, XML), and / or security schemes (e.g., VPN, secure HTTP, SSL).

[0244] Additional discussion of various embodiments

[0245] 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 at which the vehicle is expected to be at a location. The control circuitry may be configured to: determine an over-the-air (OTA) software package available for the vehicle based on the vehicle identifier. The control circuitry may be configured to: obtain, via a network, the OTA software package applicable to the vehicle based on the vehicle identifier from a remote computing system. The control circuitry may be configured to: provide the OTA software package to a local cache storage device located at the location before the time at which the vehicle is expected to be at the location.

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

[0247] Embodiment 3 includes the computing system according to any one of Embodiments 1 and 2. In this embodiment, in order to determine that the vehicle has arrived at the location and that the vehicle is available for the OTA software package, the control circuitry may be configured to: obtain a request for the OTA software package generated by the vehicle.

[0248] Embodiment 4 includes the computing system according to any one of Embodiments 1 to 3. In this embodiment, the OTA software package may include a software update package that updates the version of the software currently downloaded to the vehicle.

[0249] Embodiment 5 includes the computing system according to any one of Embodiments 1 to 4. In this embodiment, the location may be a vehicle maintenance location, and in order to obtain data indicating the time when the vehicle is expected to reach the location, the control circuit may be configured to: obtain data indicating the scheduled maintenance for the vehicle; and determine the time when the vehicle is expected to reach the maintenance location based on the scheduled maintenance for the vehicle.

[0250] Embodiment 6 includes the computing system according to any one of Embodiments 1 to 5. In this embodiment, the location is a vehicle maintenance location, and in order to obtain data indicating the time when the vehicle is expected to reach the location, the control circuit may be configured to: obtain historical maintenance data associated with the vehicle; and predict the time when the vehicle is expected to reach the maintenance location based on the historical maintenance data associated with the vehicle.

[0251] Embodiment 7 includes the computing system according to any one of Embodiments 1 to 6. In this embodiment, the control circuit may be further configured to: adjust the maintenance schedule of the vehicle based on the OTA software update.

[0252] Embodiment 8 includes the computing system according to any one of Embodiments 1 to 7. In this embodiment, the location may be a charging station, and in order to obtain data indicating the time when the vehicle is expected to be at the location, the control circuit may be configured to: obtain historical charging data associated with the vehicle; and predict the time when the vehicle is expected to reach the charging station based on the historical charging data associated with the vehicle.

[0253] Embodiment 9 includes the computing system according to any one of Embodiments 1 to 8. In this embodiment, the location may be a vehicle production facility, and in order to obtain data indicating the time when the vehicle is expected to be at the location, the control circuit may be configured to: obtain data indicating the status of the vehicle at the vehicle production facility; and predict the time when the vehicle is expected to be ready for the OTA software update at the vehicle production facility based on the status of the vehicle.

[0254] Embodiment 10 includes the computing system according to any one of Embodiments 1 to 9. In this embodiment, the control circuit may be further configured to determine whether the OTA software package for the vehicle has been stored in the local cache storage device located at the location.

[0255] Embodiment 11 includes the computing system according to any one of Embodiments 1 to 10. In this embodiment, the control circuit may be 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 the shadow record of the vehicle.

[0256] Embodiment 12 includes the computing system according to any one of Embodiments 1 to 11. In this embodiment, the control circuit may be further configured to determine the confidence level of the time when the vehicle is expected to be at the location; and queue the OTA software package based on the confidence level of the time when the vehicle is expected to be at the location.

[0257] Embodiment 13 includes the computing system according to any one of Embodiments 1 to 12. In this embodiment, the control circuit may be further configured to obtain network traffic data associated with the network; and determine a time period for obtaining the OTA software package through the network based on the network traffic data.

[0258] 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 the time when the vehicle is expected to be at a certain location. The method may include: determining an over-the-air (OTA) software package available for the vehicle based on the vehicle identifier. The method may include: obtaining, through a network, the OTA software package applicable to the vehicle based on the vehicle identifier from a remote computing system. The method may include: providing the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

[0259] Embodiment 14 includes the computer-implemented method according to Embodiment 13. In this embodiment, the method may include: determining that the vehicle has arrived at the location and the vehicle is available for the OTA software package; and outputting the OTA software package from the local cache storage device.

[0260] Embodiment 15 includes the computer-implemented method according to any one of Embodiments 13 or 14. In this embodiment, the method may include: determining whether the OTA software package for the vehicle has been stored in the local cache storage device located at the location.

[0261] Embodiment 16 includes the computer-implemented method according to any one of Embodiments 13 to 15. In this embodiment, the method may include: providing data indicating that the OTA software package has been provided to the vehicle at the location to the remote computing system for updating the shadow record of the vehicle.

[0262] Embodiment 17 includes the computer-implemented method according to any one of Embodiments 13 to 16. In this embodiment, the method may include: providing data indicating that the OTA software package has been provided to the vehicle at the location to the remote computing system for updating the shadow record of the vehicle.

[0263] Embodiment 18 includes the computer-implemented method according to any one of Embodiments 13 to 17. In this embodiment, the method may include: determining the confidence level of the time when the vehicle is expected to be at the location; and queuing the OTA software package based on the confidence level of the time when the vehicle is expected to be at the location.

[0264] Embodiment 19 includes the computer-implemented method according to any one of Embodiments 13 to 18. In this embodiment, the method may include: obtaining network traffic data associated with the network; and determining a time period for obtaining the OTA software package through the network based on the network traffic data.

[0265] Embodiment 20 relates to one or more non-transitory computer-readable media that store instructions that can be executed by a control circuit to: obtain data indicating a vehicle identifier associated with a vehicle and the time when the vehicle is expected to be at a location; determine an over-the-air (OTA) software package available for the vehicle based on the vehicle identifier; obtain, through a network, the OTA software package applicable to the vehicle based on the vehicle identifier from a remote computing system; and provide the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

[0266] Additional disclosure

[0267] As used herein, adjectives and their possessive forms are intended to be used interchangeably, unless the context clearly dictates otherwise and / or indicates otherwise. For example, where appropriate, "components of a vehicle" and "vehicle components" are used interchangeably. Similarly, words, phrases, and other disclosures herein are intended to cover obvious variations and synonyms, even if such variations and synonyms are not expressly listed.

[0268] Computing tasks and operations discussed herein that are performed at or by a computing device remote from a vehicle may alternatively (e.g., via a vehicle computing system) be performed at the vehicle, and vice versa.

[0269] The technical reference servers, databases, software applications, and other computer-based systems discussed herein, as well as the actions taken and the information transmitted to and from these systems. The inherent flexibility of computer-based systems allows for a wide variety of possibilities in terms of configuration, combination, and task and functionality partitioning among components. For example, the processes discussed herein may be implemented using a single device or component, or multiple devices or components working 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.

[0270] Although the subject matter has been described in detail with respect to various specific example embodiments thereof, each example is provided by way of illustration rather than limitation of the disclosure. Those skilled in the art will readily conceive of alterations, variations, or equivalents to such embodiments upon learning the foregoing. Accordingly, the disclosure does not exclude including such modifications, variations, and / or additions to the disclosure that would be obvious to a person of ordinary skill in the art. For example, functions illustrated or described as part of one embodiment may be used with another embodiment to yield yet another embodiment. Accordingly, the disclosure is intended to cover such alterations, variations, and equivalents.

[0271] Aspects of the present disclosure have been described in accordance with illustrative embodiments of the present disclosure. Many other specific embodiments, modifications, or variations within the scope and spirit of the appended claims may occur to those of ordinary skill in the art upon viewing the present disclosure. Any and all of the functions in the following claims may be combined or rearranged in any possible manner. Accordingly, the scope of the present disclosure is intended to be covered by way of example rather than limitation, and the present disclosure does not exclude including such modifications, variations, or additions to the present disclosure that would be apparent to those of ordinary skill in the art. Additionally, lists of example elements are used herein to describe terms using conjunctions such as "and," "or," "but," etc. It should be understood that such conjunctions are provided for explanatory purposes only. The terms "or" and "and / or" are used interchangeably herein. A list connected by a specific conjunction such as "or" may refer to "at least one" or "any combination" of the example elements listed in the list, where "or" is understood as "and / or" unless otherwise indicated. Additionally, terms such as "based on" should be understood as "at least partially based on."

[0272] In using the disclosure provided herein, those of ordinary skill in the art will understand that the 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. Sometimes, for purposes of illustrative exemplification, letter designations may be used to list elements in the specification or claims, but this is not meant to be limiting. If letter designations are used, the letter designation does not imply a particular order of operations or a particular importance of the listed elements. For example, letter identifiers (such as (a), (b), (c), --, (i), (ii), (iii), --, etc.) may be used to exemplify different elements in an operation or a list. Such identifiers are provided for the convenience of the reader and do not denote a particular order, importance, or priority of steps, operations, or elements. For example, the operations exemplified by list identifiers such as (a), (i), etc. may be performed before, after, or in parallel with another operation exemplified by list identifiers such as (b), (ii), etc.

Claims

1. A computing system, the computing system comprising: control circuitry configured to: obtain data indicating a vehicle identifier associated with a vehicle and a time at which the vehicle is expected to be at a location; determine over-the-air (OTA) software applicable to the vehicle based on the vehicle identifier; obtain, via a network, an OTA software package applicable to the vehicle based on the vehicle identifier from a remote computing system; and prior to the time at which the vehicle is expected to be at the location, provide the OTA software package to a local cache storage device located at the location.

2. The computing system according to claim 1, wherein, The control circuitry is further configured to: determine that the vehicle has arrived at the location and that the vehicle is available for the OTA software package; and output the OTA software package from the local cache storage device.

3. The computing system according to claim 2, wherein, 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.

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

5. The computing system according to claim 1, wherein, The location is a vehicle maintenance location, and wherein to obtain data indicating the time at which the vehicle is expected to arrive at the location, the control circuitry is configured to: obtain data indicating scheduled maintenance for the vehicle; and determine, based on the scheduled maintenance for the vehicle, the time at which the vehicle is expected to arrive at the maintenance location.

6. The computing system according to claim 1, wherein, The location is a vehicle maintenance location, and wherein to obtain data indicating the time at which the vehicle is expected to arrive at the location, the control circuitry is configured to: obtain historical maintenance data associated with the vehicle; and predict, based on the historical maintenance data associated with the vehicle, the time at which the vehicle is expected to arrive at the maintenance location.

7. The computing system according to claim 1, wherein, The control circuitry is further configured to: adjust a maintenance schedule for the vehicle based on the OTA software update.

8. The computing system according to claim 1, wherein, The location is a charging station, and wherein to obtain data indicating the time at which the vehicle is expected to be at the location, the control circuitry is configured to: obtain historical charging data associated with the vehicle; and predict, based on the historical charging data associated with the vehicle, the time at which the vehicle is expected to arrive at the charging station.

9. The computing system according to claim 1, wherein, The location is a vehicle production facility, and wherein to obtain data indicating the time at which the vehicle is expected to be at the location, the control circuitry is configured to: obtain data indicating a state of the vehicle at the vehicle production facility; and predict, based on the state of the vehicle, the time at which the vehicle is expected to be ready for an OTA software update at the vehicle production facility.

10. The computing system according to claim 1, wherein, The control circuitry is further configured to: determine whether the OTA software package for the vehicle has been stored in a local cache storage device located at the location.

11. The computing system according to claim 1, wherein, The control circuit is further configured to: Provide data indicating that the OTA package has been provided to the vehicle at the location to the remote computing system for updating the shadow record of the vehicle.

12. The computing system according to claim 1, wherein, The control circuit is further configured to: Determine the confidence level of the time when the vehicle is expected to be at the location; and Queue the OTA package based on the confidence level of the time when the vehicle is expected to be at the location.

13. The computing system according to claim 1, wherein, The control circuit is further configured to: Obtain network traffic data associated with the network; and Determine a time period for obtaining the OTA package through the network based on the network traffic data.

14. A computer-implemented method, the method comprising: Obtain data indicating a vehicle identifier associated with a vehicle and the time when the vehicle is expected to be at a location; Determine an over-the-air (OTA) package applicable to the vehicle based on the vehicle identifier; Obtain, through a network, the OTA package applicable to the vehicle based on the vehicle identifier from a remote computing system; And Provide the OTA package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

15. The computer-implemented method according to claim 13, the method further comprising: Determine that the vehicle has arrived at the location and the vehicle is available for the OTA package; And Output the OTA package from the local cache storage device.

16. The computer-implemented method according to claim 13, the method further comprising: Determine whether the OTA package for the vehicle has been stored in the local cache storage device located at the location.

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

18. The computer-implemented method according to claim 13, the method further comprising: Determine the confidence level of the time when the vehicle is expected to be at the location; And Queue the OTA package based on the confidence level of the time when the vehicle is expected to be at the location.

19. The computer-implemented method according to claim 13, the method further comprising: Obtain network traffic data associated with the network; And Determine a time period for obtaining the OTA package through the network based on the network traffic data.

20. One or more non-transitory computer-readable media, the one or more non-transitory computer-readable media storing instructions that can be executed by a control circuit to: Obtain data indicating a vehicle identifier associated with a vehicle and the time when the vehicle is expected to be at a location; Determine an over-the-air (OTA) package applicable to the vehicle based on the vehicle identifier; Obtain, from a remote computing system via a network, the OTA software package applicable to the vehicle based on the vehicle identifier; and Provide the OTA software package to a local cache storage device located at the location before the time when the vehicle is expected to be at the location.

Images