Vehicle software deployment services

Abstract

The vehicle software deployment management system generates a modifiable deployment plan and one or more associated vehicle software modules that are sent to an edge device at the vehicle activity site. The edge device stores the modifiable deployment plan and one or more vehicle software modules to update a given vehicle at a future time. In some embodiments, the vehicle may have insufficient network connectivity to perform updates remotely from the vehicle activity site. In some embodiments, the modifiable deployment plan may be modified by the edge device at a future time when the vehicle is at the vehicle activity site, based on vehicle information acquired by the edge device and vehicle user / technician input acquired by the edge device.

Description

Background Art

[0001] Modern vehicles such as cars, trucks, and motorcycles are often manufactured with electronic sensors and include a computer system programmed with a control algorithm that obtains inputs from such electronic sensors and determines various control operations performed on the vehicle or a system implemented in the vehicle. Some vehicles may include multiple electronic control units (ECUs) and various sensor modalities. In addition, the deployment of vehicle software modules may require that the vehicle software module be compatible with the execution environment of the particular ECU in which the vehicle software module is deployed. Further, the limited network connections available in vehicles may limit or slow down the transfer of software modules to the vehicle.

Brief Description of the Drawings

[0002] [Figure 1] Illustrates a cloud-based vehicle software deployment management system that generates a modifiable deployment plan for deploying a software module, illustrates sending the modifiable deployment plan / software module to an edge device at a vehicle activity site, where the vehicle's electronic control unit (ECU) is updated at the activity site at a future time and the vehicle has insufficient network connectivity to perform the update remotely from the vehicle activity site. [Figure 2A] Illustrates a more detailed diagram of a cloud-based vehicle software deployment management system and an edge device located at a vehicle activity site that stores vehicle software modules and modifiable deployment plans generated by the cloud-based vehicle software deployment management system for future use when servicing the vehicle, where the vehicle has insufficient network connectivity to perform an update of the vehicle's ECU remotely from the vehicle activity site. [Figure 2B]The following are more detailed diagrams illustrating an edge device that modifies a stored modifiable deployment plan to update the vehicle's ECU at a vehicle activity site, according to several embodiments, where the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from the vehicle activity site. [Figure 2C] The present invention illustrates, in some embodiments, a more detailed diagram of an edge device that prepares and deploys a vehicle software module based on a revised deployment plan to update the vehicle's electronic control unit (ECU) at a vehicle activity site, where the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from the vehicle activity site. [Figure 3] This provides a more detailed illustration of a cloud-based vehicle software deployment management system that provides missing vehicle software modules and updates modifiable deployment plan vehicles based on interactions between vehicles and edge devices located at vehicle activity sites, according to several embodiments. [Figure 4] This illustrates, in several embodiments, a more detailed diagram of a cloud-based vehicle software deployment management system for updating available software modules in a software module catalog, where the software module catalog is presented to the vehicle technician / user at the vehicle activity site where the vehicle is located, and the vehicle has insufficient network connectivity to perform remote ECU updates from the vehicle activity site. [Figure 5A] This provides a more detailed illustration of edge devices at a vehicle activity site that establish connectivity to the vehicle's ECU and deploy updates to the ECU according to a modifiable deployment plan, using several embodiments. [Figure 5B] This provides a more detailed illustration of an edge device at a vehicle activity site that prevents the deployment of one or more software modules in an order that deviates from the certified order for installing software modules according to a modifiable deployment plan, as illustrated by several embodiments. [Figure 6]This paper illustrates a cloud-based vehicle software deployment management system configured to generate modifiable deployment plans for deploying vehicle software modules based on various vehicle / vehicle fleet deployment operation data and machine learning (ML) models, in several embodiments. [Figure 7] The flowchart illustrates, in several embodiments, the actions performed by an edge device that receives and modifies a vehicle software module and / or modifies a modifiable deployment plan for updating the vehicle's ECU at a future time, wherein the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from the vehicle activity site. [Figure 8] This document illustrates flowcharts of operations performed by an edge device in several embodiments, which acquire vehicle information and vehicle user input, modify a modifiable deployment plan, and orchestrate the deployment of software modules based on the modified deployment plan. [Figure 9] Block diagrams illustrating exemplary computer systems that implement some or all of the technologies described herein, according to several embodiments, are provided.

[0003] Embodiments are described herein as examples of several embodiments and illustrative drawings, but those skilled in the art will recognize that embodiments are not limited to those described or drawn. It should be understood that the drawings and their detailed description are not intended to limit embodiments to any particular form disclosed, but rather to encompass all modifications, equivalents, and substitutes included in the spirit and scope defined by the appended claims. Headings used herein are for structural purposes only and are not intended to limit the scope of the description or claims. As used throughout this application, the word “may” is used in a permissive sense (e.g., meaning it has the possibility of) rather than an obligatory sense (e.g., meaning it must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to. [Modes for carrying out the invention]

[0004] The systems and methods described herein include techniques for implementing a cloud-based vehicle software deployment management system that uses edge devices located at a vehicle activity center to generate a modifiable deployment plan for deploying one or more software modules to a vehicle. The cloud-based vehicle software deployment management system is communicatively coupled via a network connection to edge devices located at vehicle activity sites, such as vehicle service centers, vehicle charging stations, vehicle sales centers, and vehicle storage locations. The edge devices located at the vehicle activity center receive a modifiable deployment plan from the cloud-based vehicle software deployment management system for deployment to the vehicle at a future time, and the vehicle has insufficient network connectivity to remotely update the vehicle's electronic control units (ECUs) from the vehicle activity site. The cloud-based vehicle software deployment management system may be configured to generate a modifiable deployment plan for deploying one or more software modules on the vehicle's ECUs before a future time when the vehicle is scheduled to be at an activity site (or before a future time when the vehicle is scheduled to be connected to an edge device). The one or more software modules may be deployed to one or more ECUs of the vehicle using a connection established between the edge devices located at the vehicle activity site and the vehicle. The edge device deployment orchestrator may be configured to modify the deployment plan based on one or more inputs determined at a future time when the vehicle connects to the edge device at the vehicle activity site.

[0005] For example, some vehicles may lack sufficient network connectivity to perform updates remotely from a vehicle activity site (as is the case with many older vehicles). Unlike vehicles with sufficient network connectivity to receive updates for their respective ECUs remotely from a vehicle activity site via wireless communication such as Wi-Fi or cellular networks, these vehicles with limited connectivity may require a technician (or vehicle user) to physically connect a connector to a port on the vehicle to deploy the software. For example, a connector connected to an edge device (either via cable or wirelessly) may connect to one or more vehicle ports to manually establish a connection to the vehicle ECU in order to deploy one or more software modules. For example, older vehicles may lack the necessary hardware or software to support over-the-air (OTA) updates, which are commonly used to update vehicles wirelessly over the internet or using cellular networks. As a result, updating a vehicle with limited network connectivity may require physical access to the vehicle's computer system to establish sufficient network connectivity to perform the update. In another example, even if a vehicle is equipped with wireless communication capabilities, it may turn out to have insufficient connectivity to download software updates remotely from a vehicle activity site due to other reasons, such as the cost of transferring data over a cellular network. In some embodiments, a vehicle may have insufficient connectivity to download software updates due to a vehicle user's decision to opt out of software updates by moving away from the vehicle activity site. Once sufficient network connectivity is established at the vehicle activity site, the deployment plan and necessary software modules can be deployed to the vehicle. The deployed deployment plan and software modules can then be used to update the vehicle's ECU.However, downloading files on demand when the vehicle is at the activity site after establishing a connection to the vehicle (e.g., just-in-time (JIT) download) may have some drawbacks compared to precaching software modules (e.g., "prefetching" or "pre-pushing" software modules to the edge and remembering the prefetched or pre-pushed software modules). For example, JIT downloads of deployment plans and software modules may lead to increased service time for vehicle users because the software modules / deployment plans must first be downloaded to the vehicle activity site before they can be deployed to the vehicle's ECU located at the vehicle activity site. For example, retrieving all relevant files for a given update may take several hours, potentially extending vehicle service time. Further extensions to vehicle service time can negatively impact the customer experience. Furthermore, the time it takes to download deployment plans and associated software modules may be even worse at activity sites with slow or unreliable network / internet speeds. In addition, such deployment plans and on-demand downloads of software modules could contribute to network congestion at activity sites (as multiple vehicles may be updated simultaneously at the same activity site), potentially increasing service hours and disrupting the operation of the activity sites.

[0006] Using edge devices that prefetch and / or cache necessary deployment plans and associated software modules can reduce service times and avoid contributing to network congestion. However, there can be challenges in prefetching or pre-pushing deployment plans / associated software modules to and storing them on edge devices at vehicle activity sites. For example, because there are numerous software modules for different types of ECUs, edge devices may not be able to store all possible software modules that may be used. Even if the available software modules are limited to those occurring for a single vehicle model, there may still not be enough storage space available to cache all available software modules because there may be numerous customizations of hardware and / or vehicle configuration options for a given vehicle that significantly increase the types of software modules that can be deployed to that vehicle. The numerous variations of vehicles, both within a given type and model, and between different types and models, can make determining a deployment plan for a particular vehicle difficult. For example, two vehicles of the same type and model may nevertheless have different features, such as different infotainment systems, different driver assistance systems, and different automatic braking systems, which are customized to suit the individual needs of the drivers (or buyers) of those two vehicles of the same type and model. Therefore, various combinations of ECUs supporting different features require different deployment plans and software modules associated with those different deployment plans. Also, different versions of the vehicle software may exist, and one vehicle may have received the latest update for its ECU, while the same ECU in the second vehicle may not have received the previous update. Furthermore, the deployment plan may differ depending on the various combinations of vehicle hardware / software present in a given vehicle.While edge devices may be configured to store a large number of different software modules, they may never be able to prefetch or prepush and store all the software modules for all deployment plans for all possible permutations of a deployment plan, and all the necessary software modules required to update a vehicle fleet. Furthermore, in some limited cases, for a given vehicle, the exact ECU configuration and / or user input for determining a user-selected update may not be available until the vehicle is physically located at the activity site at a future time, and therefore, the edge device may not be able to anticipate and store all the software modules corresponding to all potential ECU configurations or all possible user-selected decisions.

[0007] As described above, updating software on vehicles with insufficient network connectivity and performing remote software deployment from a vehicle activity site presents significant challenges, including the need to accommodate a wide range of vehicle hardware and software combinations.

[0008] In some embodiments, a cloud-based vehicle software deployment management system may generate a modifiable deployment plan, and edge devices at vehicle activity sites may store the modifiable deployment plan (and associated software modules) for later use when vehicles with insufficient network connectivity connect to edge devices at vehicle activity centers. In contrast to generating a completely new deployment plan and downloading associated software modules after the vehicle arrives at the vehicle activity site, the cloud-based vehicle software deployment management system may generate a modifiable deployment plan and provide the modifiable deployment plan (and associated software modules) to edge devices located at the vehicle activity site before the vehicle arrives at the vehicle activity site, and the edge devices may store the modifiable deployment plan along with the associated software modules before the vehicle arrives at the vehicle activity site. This can reduce download times and provide a faster service experience. By pre-downloading or otherwise transferring the required modifiable deployment plan and software modules in advance and at intervals, the files are obtained beforehand, which can reduce network congestion during vehicle service. For example, if a given vehicle activity site serves a large number of vehicles during the day and only a small number of vehicles at night, network bandwidth can be used more efficiently by spreading network usage across both day and night by cooperatively prefetching the deployment plan and associated software modules, rather than attempting to simultaneously download a substantial portion of the deployment plan and associated software modules required for the day during peak activity hours at the vehicle activity site during the day. Furthermore, modifiable deployment plans allow the deployment plan to be modified as it is being serviced at the vehicle activity site, tailoring vehicle ECU updates based on specific vehicle types and incorporating vehicle user / technician input and other vehicle information (which may not have been available in the cloud-based vehicle software deployment management system before service at the activity site).For example, certain vehicle configurations may require the establishment of a physical connection to the vehicle's ports, which prevents cloud-based vehicle software deployment management systems from taking these specific configurations into account. Therefore, a modifiable deployment plan can define various aspects of deployment, but it can also accommodate field modifications based on information that was not available in the cloud due to the need for physical connection or user / owner input.

[0009] In some embodiments, the modifiable deployment plan may be generated based on vehicle information, such as the vehicle type, model, and custom features, obtained before the vehicle is serviced at a vehicle activity site. In some embodiments, the modifiable deployment plan may be a modifiable deployment plan for multiple vehicles. In some embodiments, a cloud-based vehicle software deployment management system may generate a modifiable deployment plan based on receiving / obtaining instructions that a vehicle activity site reservation is scheduled for a vehicle at a particular vehicle activity site. For example, a vehicle user may schedule a service reservation with a vehicle service center or schedule the vehicle to be charged at a charging station, both of which may be types of vehicle activity sites including edge computing devices as described herein. The cloud-based vehicle software deployment management system may generate a modifiable deployment plan before the date and / or time of the scheduled vehicle activity site reservation. The cloud-based vehicle software deployment management system may transmit the generated modifiable deployment plan to an edge device, which is connected to the cloud-based vehicle software deployment management system. The generated modifiable deployment plan transmitted to the edge device may be stored for future use at the vehicle activity site indicated in the scheduled reservation. In some embodiments, the modifiable deployment plan may be modified based on input from the vehicle user / technician received at the vehicle activity site. For example, the vehicle user may decide which of several available updates to apply to the vehicle. In some embodiments, the updates may be associated with higher-tier product sales options and / or bundled sales options.

[0010] In some embodiments, an edge device located at an activity site may be configured to connect to the vehicle using various connectivity interfaces. For example, the edge device may interface with vehicle software update / diagnostic mechanisms such as a flash port, an onboard diagnostic system (ODB) port, and / or IEEE 802.11b direct sequence "Wi-Fi". In some embodiments, the edge device may be a hardware device having a secure connection to a cloud-based vehicle software deployment management system. The edge device may acquire vehicle information such as the number and type of ECUs in the vehicle, the latest software module version installed in the ECUs, and modify a stored modifiable deployment plan, taking these configuration details into consideration. In some embodiments, modifications to a stored deployment plan may include updating one or more parts of the vehicle software modules, and / or updating the modifiable deployment plan, and the modifications may be based on the received vehicle information and / or vehicle user / technician input. For example, the edge device may acquire information about the vehicle configuration of a customized ECU of an infotainment system and, based on the customization, determine that the software module of the infotainment system may not be installed. In another example, based on a decision that the ECU for the automatic braking system includes additional computing power, the edge device may acquire a new, more processing-intensive version of the software module deployed to the ECU. Based on the vehicle configuration and engineer / user input, one or more inputs that trigger one or more modifications to the deployment plan may be provided to the edge device for use when modifying the modifiable deployment plan.

[0011] Figure 1 illustrates a cloud-based vehicle software deployment management system that generates a modifiable deployment plan for deploying software modules in several embodiments, illustrating the transmission of the modifiable deployment plan / software module to an edge device at an activity site, where the vehicle's electronic control unit (ECU) is updated at the activity site at a future time, and the vehicle has insufficient network connectivity to perform the update remotely from the vehicle activity site.

[0012] In some embodiments, the vehicle software deployment management system may be a cloud-based system contained within a provider network, such as provider network 102. Provider network 102 may include data centers, networking infrastructure, etc., configured to provide cloud-based services. In some embodiments, provider network 102 may be set up by an entity, such as a corporation or public sector organization, to provide one or more services (such as various types of cloud-based services) accessible over the Internet and / or other networks. In some embodiments, the cloud-based system may be contained within a private provider network established within the service provider's data center for private use. The private provider network may be isolated from other users and may provide dedicated connectivity and resources for the service provider's private use, such as a virtual private cloud. In some embodiments, the cloud-based system may be contained within a public provider network shared among multiple tenants or organizations within the cloud service provider's data center. A “cloud-based” vehicle software deployment management system may be implemented in a public provider network or a private provider network, as well as in a virtual private network contained within a public provider network. In some embodiments, the vehicle software deployment management system may be partially implemented in both the private and public provider networks. The provider network 102 may be implemented in a single location, or it may be implemented in multiple data centers hosting various resource pools, such as a collection of physical and / or virtualized computer servers, storage devices, network equipment, etc., necessary to implement and distribute the infrastructure and services provided by the provider network 102, including the vehicle software deployment management system 100 (for example, the provider network 102 may include multiple computing systems 900, which will be discussed later with respect to Figure 9).

[0013] Provider network 102 may deliver content from points of presence located outside the data center of provider network 100, but connected to it via edge locations. Such points of presence at edge locations may be referred to herein as edge devices 190, and the point of presence locations may include vehicle activity sites such as vehicle service centers, vehicle charging stations, vehicle storage facilities, vehicle parking facilities, and vehicle sales centers. In some embodiments, a given one of the edge devices 190 may be a set of one or more servers provided to customer facilities (such as vehicle activity sites) that can be at least partially controlled by the control plane of provider network 102. For example, edge device 190a may be located at activity site A 184b, and edge device 190b may be located at activity site B 184b, and may be controlled by the control plane of provider network 102, such as the control plane of the virtualized computing services of provider network 102. Also in some embodiments, edge devices 190a and 190b may be connected to the provider network, for example, via physical network cables such as dedicated direct connections, or via public network connections such as the Internet. In some embodiments, edge devices 190a and 190b may be connected to the provider network 102 without being included in the provider network's control plane. In any configuration, edge devices 190a and 190b may cache modifiable deployment plans 170 and 180 (including their associated software modules) before vehicles such as vehicles 140, 142, 144, and 146 arrive at one of the given vehicle activity sites A (184a) and B (184b).

[0014] In some embodiments, vehicle activity sites such as vehicle activity site A(184a) and vehicle activity site B(184b) may be vehicle service centers. Vehicle service centers may provide maintenance, repair, and other services for vehicles, including various software updates for vehicle ECUs. In some embodiments, vehicle service centers may be staffed with trained technicians and equipped with specialized tools and equipment for diagnosing, repairing, and servicing vehicles of various types and models. In some embodiments, activity sites may be charging stations for electric vehicles (EVs), for example, to recharge batteries. For example, activity site A 184b may include charging infrastructure such as an electric vehicle supply system (EVSE) or a charging station with charging connectors compatible with various types of EVs, which may provide the power necessary to recharge the batteries of EVs.

[0015] In some embodiments, the edge devices 190a and 190b of activity sites A / B 184a and 184b may be connected to vehicles 140, 142, 144, and 146. Figure 1 illustrates three vehicles 142, 144, and 146 connected to edge device 190b via a vehicle-edge device connection 192, but various other numbers of vehicles may be connected to edge device 190b simultaneously. For example, this example is intended for illustrative purposes only, and it should be understood that any number of vehicles can be connected to edge device 190b. Furthermore, in some embodiments, there may be any number of vehicle activity sites, such as vehicle activity site A 184a and vehicle activity site B 184b, where edge devices 190a and 190b may be located, respectively. Also, in some embodiments, two or more edge devices may be located at a given vehicle activity site. For example, multiple edge devices may be located at activity sites A / B 184a and 184b, respectively. In some embodiments, the network 120 may be accessible to the edge device 190. The edge device 190 may also include various components configured to send and receive signals using different vehicle signal formats, such as vehicle connection adapters (further described in Figures 2A-2C). In some embodiments, the edge devices 190a and 190b may provide connectivity to the vehicle at vehicle activity sites 184a and 184b using dual power and data connections. The edge device 190 may provide both network power and network connectivity. In some embodiments, a single adapter may connect not only the power and data connections used to connect the edge device 190 to a given vehicle, but also the power lines used for charging. Customers 122a-122n may further communicate with the vehicle software deployment management system 100 via the network 120. Customers 122a-122n may be vehicle suppliers or vehicle component suppliers (e.g., original equipment manufacturers (OEMs) and / or parts suppliers).Network 120 may be a direct connection to a service provider network hosting the vehicle software deployment management system 100, or a private or public network such as an internet connection. Network 120 may also be a wireless network such as a cellular network, a Wi-Fi network, or another wireless network. In some embodiments, vehicles 140, 142, 144, and 146 may be connected to more than one type of network 120.

[0016] In some embodiments, the vehicle software deployment management system 100 may include a modifiable deployment plan generator 104, a vehicle application storage 106 configured to store software modules available in the deployment plan generated by the modifiable deployment plan generator 104, a vehicle application marketplace 108, a vehicle data ML inference module 110, and a vehicle application transmission module 112. The modifiable deployment plan generator 104 may generate modifiable deployment plans 180 for a single vehicle, such as vehicle 142, or for a fleet of vehicles 140, 142, 144, and 146, based on vehicle application deployment requests 124a to 124n sent by customers 122a to 122n, respectively. For example, customer 122a may send a vehicle application deployment request 124a requesting that an updated automatic braking software module be deployed to vehicle 140. In some embodiments, a vehicle software module deployment request 124a may request the deployment of a software module with varying levels of generality, such as requesting updates for all ECUs determined by the vehicle software deployment management system, or requesting updates for vehicle safety functions without specifying a particular ECU to which the software module should be deployed.

[0017] With respect to the vehicle software modules to be deployed, the modifiable deployment plan generator 104 may retrieve or reference one or more vehicle software modules stored in the vehicle application storage 106, external application storage, and / or directly from the customer 122. The retrieved or referenced software modules may be included in the modifiable deployment plan generated by the modifiable deployment plan generator 104. In some embodiments, the modifiable deployment plan may instruct specific components of the software modules to be deployed to a specific ECU. The deployment plan or software modules may also be modified at an edge device (or another receiving agent). The modifiable deployment plan may include software packages necessary for the vehicle to deploy the software modules, including information indicating various software dependencies. In some embodiments, the modifiable deployment plan may further include operational procedures for a technician to deploy the software modules in the correct order, as well as test and verification procedures. The modifiable deployment plan generator 104 and the generation of the modifiable deployment plan are further described in Figures 2A to 2C. In some embodiments, the vehicle application marketplace 108 may publish various vehicle applications that are permitted to be deployed to a given vehicle for customers 122a to 122n. Customers 122a-122n may specify in their vehicle application deployment requests the particular applications to be deployed on the vehicles. Although not illustrated, in some embodiments the control plane of the vehicle software deployment management system 100 may register vehicles, model vehicles (e.g., manage vehicle shadows), and manage data for a single vehicle or an entire vehicle fleet. In some embodiments the control plane of the vehicle software deployment management system 100 may enable customers 122a-122n to perform various actions necessary to deploy one or more vehicle software modules and update deployment plans via edge devices 190a-b.

[0018] For example, the modifiable deployment plan generator 104 may generate a modifiable deployment plan and associated vehicle software modules that can be stored by an edge device 190a at activity site A 184a. The edge device 190a may include software and / or networking connectivity to provide a technician user interface (UI) 194, a deployment orchestrator 196, and vehicle software storage 198. The edge device 190a may receive transmissions of vehicle software modules and modifiable deployment plans 170 and store them in the vehicle software storage 198 for future deployment when vehicle 140 arrives at vehicle activity site A 184a for maintenance. The edge device 190a may receive vehicle user input and / or technician input regarding updates to vehicle 140 via the technician UI 194 when vehicle 140 is present at activity site A 184a (and therefore the vehicle has sufficient network connectivity for updates via the edge device). Based on the received user / technician input, the edge device may modify the deployment plan and deploy the software module to ECU#1 150 and ECU#2 152 of the vehicle 140. In some embodiments, ECU#1 150 and ECU#2 152 may include one or more subsystems that process the deployment plan sent from the vehicle software deployment management system 100 and may create localized ECU execution plans based on metadata obtained from the ECUs in the vehicle via one or more ECU agents deployed to the ECUs. In some embodiments, the modifiable deployment plan 180 sent to the vehicle may create one or more local ECU execution plans that are transmitted by ECU#1 150 to ECU#2 152. In some embodiments, the execution plans may be transmitted to each ECU in a specific order. For example, a particular installation sequence may be used in testing to authenticate the vehicle software, and to meet the authentication requirements, the software module may need to be installed in the same sequence used in the test.The vehicle application storage 106 and the vehicle application marketplace 108 will be further explained in Figures 2A to 2C and Figure 4.

[0019] In some embodiments, the vehicle application transmission module 112 may provide a vehicle-side software development kit (SDK) or other set of software development packages to interpret the deployment plan (or other message) and the vehicle software modules for the vehicle 140 (including various file formats and dependencies of the software modules). The vehicle application transmission module 112 may further include a first-in, first-out (FIFO) type queue for storing signed serialized data chunks generated based on the modifiable deployment plan. The signed serialized data chunks may be formatted to transmit signed serialized data chunks so that they can be relayed using any communication protocol / mechanism that the customer prefers to use on the edge device 190 (and the vehicle application transmission module may be configured so). The vehicle application transmission module 112 may generate sets of signed serialized data chunks of only vehicle software modules, only modifiable deployment plans, or both deployment plans and vehicle software modules. In some embodiments, the chunks may be signed so that the edge device can verify that the received data chunks were sent by the correct entity. In some embodiments, a third-party application may use a cloud-side SDK to interact with the vehicle software deployment management system 100 and transmit signed, serialized data chunks to an edge device 190. The edge device 190 may incrementally reconstruct the deployment plan and software module package used to implement the software modules transmitted to the vehicle. In some embodiments, upon receiving the transmission of the deployment plan and associated software module chunks, the edge device 190 may incrementally reconstruct the deployment plan and software modules.

[0020] In some embodiments, the vehicle communication bus 156 of the vehicle 140 may transmit vehicle information transmitted from various components of the vehicle, such as electronic control unit 150 (ECU#1), electronic control unit 156 (ECU#4), and electronic control unit 154 (ECU#3). In addition, other components, such as physical sensor #1 160, physical sensor #2 162, and physical sensor #3 164, may be connected to the vehicle communication bus 156 and / or one or more of the vehicle's ECUs. In some embodiments, the various physical sensors may include voice / visual sensors that acquire voice / visual information and may communicate such information via the vehicle communication bus 156. In some embodiments, the various physical sensors 160, 162, and 164 may include location sensors that can acquire the location of the vehicle. In some embodiments, the location sensors may be a Global Positioning System (GPS) using cellular, radio passive, satellite, and other types of GPS systems. The location sensor may acquire location information that is further processed by ECU#1 150 before being transmitted to the vehicle software deployment management system 100 via the network. In some embodiments, various physical sensors may be connected to multiple vehicle communication buses and / or physical sensors. For example, in vehicle 140, physical sensor 162 (physical sensor #2) may be connected to ECU 156 (ECU#4) and ECU 156 (ECU#3) via vehicle communication bus 156. Connections to various vehicle communication buses 156 may provide alternative sensor signal paths. In some embodiments, various parts of vehicle communication bus 156 may be buses using different types of buses and / or different types of on-board communication protocols. On-board communication protocols used in vehicle 140 may include Controller Area Network (CAN) protocol, Remote Procedure Call (RPC) protocol, Controller Area Network Flexible Data Rate (CAN FD) protocol, Low-Speed ​​CAN protocol, High-Speed ​​CAN protocol, Society of Automotive Engineers (SAE) J1939 protocol, CANopen protocol, and / or On-Board Diagnostics (OBD) protocol.Edge device 190 may be connected to one or more components of a vehicle via one or more vehicle-edge device connections 192. For example, edge device 190a may be connected to ECU#1 150 via vehicle-edge device connection 192a and may be connected to ECU#2 152 via vehicle-edge device connection 192b. Edge device 190a may use vehicle-edge device connections 192a and 192b to deploy one or more software modules on ECU#1 and / or ECU#2. In some embodiments, a vehicle edge device connection to one component of a vehicle may enable the deployment of a software module to another component of the vehicle. For example, vehicle-edge device connection 192b formed between edge device 190a and ECU#2 152 may enable deployment orchestrator 196 to deploy a software module to ECU#3 154 connected to ECU#2. In some embodiments, ECU#2 152 may receive the required deployment plan / software module package and facilitate the deployment on ECU#3.

[0021] The modifiable deployment plan generator 104 of the vehicle software deployment management system 100 can generate a deployment plan that enables modification or optimization of the deployment configuration for deploying one or more software modules to respective vehicles. For example, the modifiable deployment plan generator 104 can use vehicle ECU configurations and diagnostic data including deployment operation data (e.g., the stage of failure of a deployment procedure), as well as ML inferences generated from vehicle data and other sources, to determine a modified or optimized configuration for the deployment of applications on the vehicle. The use of ML inferences to update modifiable deployments is further described in FIG. 6. In some embodiments, the vehicle software deployment management system 100 may utilize vehicle data 182 to reconstruct the representation or state of the vehicle in a vehicle simulator such as a virtual replica of the vehicle. The reconstructed representation can be used to test various vehicle software modules, including testing the deployment of vehicle software modules, as further described in FIGS. 5A - 5B. Additionally, ECU #1 150 may communicate with different runtime environments capable of deploying software modules to vehicle ECU partitions such as Autosar Classic, Autosar Adaptive, Android, OCI container framework, and / or WASM runtime using a deployment adapter interface.

[0022] FIG. 2A illustrates a more detailed view of a cloud - based vehicle software deployment management system, an edge device located at a vehicle activity site storing one or more vehicle software modules, and a modifiable deployment plan generated by the cloud - based vehicle software deployment management system for future use when servicing the vehicle, where the vehicle has network connectivity insufficient to perform ECU updates of the vehicle remotely from the vehicle activity site.

[0023] In some embodiments, the vehicle software deployment management system 100 may request / receive vehicle activity reservation information 210. In some embodiments, the vehicle activity reservation information may include one or more of the following: the type of activity requested for the vehicle (e.g., a specific type of update or function requested, or a specific ECU), the reservation date, the reservation time, and the reservation location for the activity reservation. For example, the vehicle software deployment management system 100 may receive information regarding a vehicle service reservation indicating that vehicle 140 is scheduled to be serviced at activity site A 184 at future time T2 to update ECU #1 150. In some embodiments, the activity reservation time may be a range of future times and / or an approximate future time. In some embodiments, the vehicle activity reservation information may include predictions of vehicle reservations that are expected to be made at vehicle activity sites without any explicit reservations already established for vehicles. For example, the vehicle software deployment management system 100 may receive or generate predictions regarding a specific vehicle (or a specific type of vehicle) that is expected to arrive at a charging station at a future time. In some embodiments, the vehicle software deployment management system 100 may predict vehicle arrival using a vehicle data ML inference module 110, as further described in Figure 6. The prediction may function as vehicle activity reservation information that can be used by the vehicle software deployment management system 100 to determine a modifiable deployment plan for precaching at edge device 190a. In some embodiments, the vehicle software deployment management system 100 may request / receive vehicle information 212 and use the received vehicle information to generate a modifiable deployment plan. In some embodiments, the vehicle activity reservation may be a reservation for vehicle charging at a vehicle charging station and / or the time and duration for which the charging station is reserved. The received vehicle information may include the type, model, year, and VIN (Vehicle Identification Number) of the vehicle 140 whose vehicle activity is performed at activity site A 184a.Vehicle information may include, and is not limited to, various other types of information, such as vehicle ECU configuration, vehicle software configuration, vehicle status information, various inferences derived from fleet-wide analysis, or other vehicle information related to the generation of a vehicle deployment plan. In some embodiments, the vehicle software deployment management system 100 may request / receive vehicle information 212 in multiple steps, and in some embodiments, the vehicle software deployment management system 100 may acquire information based on a portion of the received vehicle information. For example, based on the received vehicle VIN, the vehicle software deployment management system 100 may request ECU information from an original equipment manufacturer (OEM) that can use the VIN number to identify a specific ECU located in the vehicle. In some embodiments, the vehicle software deployment management system 100 may request / receive vehicle user input 214 that can be used to generate a modifiable deployment plan. For example, the vehicle software deployment management system 100 may request vehicle user input regarding any modifications made to the hardware in the vehicle 140 by sending a notification to the user and may receive input regarding specific vehicle configuration options. The vehicle user input may be used to narrow the range of software modules that can be deployed in the modifiable deployment plan. In some embodiments, vehicle information may be used to determine notifications to send to the vehicle user for vehicle user input. Similarly, vehicle user input received by the vehicle software deployment management system 100 may be used to request / receive additional information from among the vehicle information from various sources.

[0024] The modifiable deployment plan generator 104 may generate a modifiable deployment plan based on received reservation information, vehicle information, and / or user input. The modifiable deployment plan may include one or more variations of a deployment plan that can be used at a future time when the vehicle is present at a vehicle activity site. The modifiable deployment plan may include a set of predefined deployment strategies or approaches that can be modified or customized in the future based on vehicle user / technician input. In some embodiments, in addition to vehicle user / technician input, the modifiable deployment plan may be modified based on vehicle information acquired when the vehicle is connected to an edge device. The deployment plan may include multiple strategies or options for deploying one or more different versions of a given software module. In some embodiments, the modifiable deployment plan may further include additional software dependencies required for the deployment of different versions. In some embodiments, the modifiable deployment plan may include provisions for testing and verification activities to ensure the quality and stability of the deployment, such as unit tests that can be modified later based on user / technician input. Modifiable deployment plans can provide flexibility and adaptability during the deployment process (in the absence of specific vehicle information and / or user input) and can enable precaching of deployment plans and software modules at the vehicle activity site location without having all the information required for the actual deployment. As shown in Figure 2B, the vehicle software deployment management system 100 can provide transmission of vehicle software modules and modifiable deployment plans in T1220, and the vehicle software storage 198 can store vehicle software modules and modifiable deployment plans for future use (222) without the vehicle information and / or user input required for deployment.

[0025] Figure 2B illustrates a more detailed diagram of an edge device that modifies a stored modifiable deployment plan to update the vehicle's ECU at a vehicle activity site, according to several embodiments, where the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from the vehicle activity site.

[0026] In some embodiments, the edge device 190a may be located at the vehicle activity site A 184a and may include a technician UI 194, a deployment orchestrator 196, vehicle software storage 198, a software module catalog 240, a vehicle analyzer 250, a software module packager 255, and a vehicle connection adapter 260. At T2, the edge device 190a may receive vehicle user / technician input 232 via the technician UI 194. In some embodiments, the technician UI 194 may provide an interface for providing the vehicle user / technician with a list of target ECUs for software module deployment, including selection from a list of available ECUs or manual input of ECU identifiers. The technician UI 194 may further provide an interface for browsing a list of available vehicle software modules, searching for modules by name or function, and / or selecting from a predefined set of modules for a particular vehicle model to be deployed. In some embodiments, the technician UI 194 may allow instruction or selection of options for configuring software module / ECU parameters, such as setting thresholds or selecting ECU modes. For example, the technician UI 194 may provide a list of vehicle software modules available for updating based on the available memory of ECU#1 150. Vehicle user / technician input 232 may provide instructions for selection provided by the technician UI 194. In some embodiments, vehicle user / technician input 232 may be a selection based on higher-end product sales options and / or bundled sales options provided to the vehicle user by the technician UI 194, and the options are purchasable. For example, vehicle user / technician input 232 may be a selection of advanced infotainment features purchased by the vehicle user, and upon selection, the edge device may be configured to deploy the relevant infotainment module to ECU#1 150. Based on the received vehicle user / technician input 232, the modifiable deployment plan stored in the vehicle software storage 198 may be updated.For example, based on vehicle user input 232 selecting advanced infotainment features for deployment, the edge device 190a may update the deployment plan based on user / technician input 234 to deploy the advanced infotainment features. In some embodiments, the technician UI 194 also provides an interface for receiving appropriate security credentials, such as user authentication and role-based access control. In some embodiments, the technician UI 194 may provide authorization management to ensure that only authorized technicians can access the ECU and deploy modules. The technician UI 194 may further provide technicians with diagnostic and troubleshooting capabilities to identify problems during software module deployment, including providing deployment logs and errors.

[0027] In some embodiments, the vehicle connection adapter 260 may be used to provide a connection to one or more ECUs of the vehicle 140. For example, the vehicle connection adapter 260 may provide a connection to ECU#1 via the vehicle's OBD-II (On-Board Diagnostics II) port and provide a vehicle edge device connection to ECU#1 150 in T2292a. In some embodiments, additional vehicle edge connections may be formed, such as a vehicle edge device connection in T2292b connected to ECU#2 152. In some embodiments, the vehicle edge device connection may use different communication protocols, such as CAN (Controller Area Network) or Ethernet protocol. In some embodiments, the vehicle edge device connection may be a wireless connection using Wi-Fi protocol or other wireless communication protocols, such as Bluetooth. In some embodiments, the vehicle connection adapter 260 may be a handheld device that connects to edge device 190a and can form a vehicle-edge device connection with the vehicle 140 in T2292a / 292b via one or more protocols. In some embodiments, multiple handheld devices may be physically and / or wirelessly connected to an edge device 190a and connected to a vehicle 140.

[0028] The vehicle analyzer 250 may acquire the vehicle configuration 236 via the vehicle edge device connection at T2. In some embodiments, the vehicle analyzer 250 may send queries or commands to the ECUs to acquire information about the ECU configuration of the vehicle 140. For example, the vehicle analyzer 250 may request information about the configuration of the ECUs for the engine, transmission, fuel system, emission components, sensors, actuators, and / or other systems of the vehicle 140. The vehicle configuration may include ECU type, model, parameter settings, service date, and other information related to modifications of the deployment plan. The vehicle analyzer 250 may analyze the received vehicle configuration 236 and update the deployment plan based on the vehicle configuration 236. For example, the vehicle analyzer may determine that an older version of the software module should be deployed based on an analysis that ECU#1 does not support a newer version of the software module.

[0029] In some embodiments, based on the updated deployment plan, the edge device 190a may request / receive additional vehicle software modules and a modifiable deployment plan at T2242. For example, based on the vehicle analyzer 250 detecting the presence of an ECU requiring a critical safety patch, the edge device 190a may request additional vehicle software modules and update the modifiable deployment plan at T2. In some embodiments, the vehicle user / technician input 232 and vehicle configuration 236 may be transmitted to the vehicle software deployment management system to generate a new modifiable deployment plan, which is further described in Figure 3.

[0030] Figure 2C illustrates a more detailed diagram of an edge device, according to several embodiments, that prepares and deploys a vehicle software module based on a modified deployment plan to update the vehicle's electronic control unit (ECU) at a vehicle activity site, where the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from the vehicle activity site.

[0031] In some embodiments, in T3, after the modifiable deployment plan is updated (in T2) based on vehicle user / technician input from the technician UI 194 and vehicle configuration from the vehicle analyzer, the deployment orchestrator 196 retrieves the modified deployment plan and vehicle software modules 252 and sends them to the software module packager 255 to prepare the modified deployment plan and vehicle software modules for deployment in the vehicle in T3256.

[0032] In some embodiments, the deployment orchestrator 196 may initiate the execution of the updated deployment plan in an orderly manner. In some embodiments, the software module packager 255 may assemble the necessary software artifacts of a given software module of the deployment plan into an image / file format supported by the vehicle and associated interfaces. For example, the source code, libraries, configuration files, or other associated files of a software module for deployment using the deployment plan may be compiled or packaged into a format supported by the vehicle and its associated interfaces (e.g., the CAN bus protocol for the CAN bus). The software module packager 255 may deploy the vehicle software module of the modified deployment plan at T3 via the vehicle connection adapter 260 and vehicle edge device connections 294a and 294b at T3.

[0033] Figure 3 illustrates a more detailed diagram of a cloud-based vehicle software deployment management system that provides missing vehicle software modules and updates modifiable deployment plan vehicles based on the interaction between the vehicle and edge devices located at the activity site, according to several embodiments.

[0034] In some embodiments, as shown in Figure 2B, based on vehicle user / technician input received from a user or technician in the technician UI 194, the edge device 190a may transmit vehicle user / technician input 314 to the vehicle software deployment management system 100. Furthermore, based on the vehicle configuration acquired by the vehicle analyzer 250, the edge device 190a may transmit the vehicle configuration to the vehicle software deployment management system 100. In some embodiments, the vehicle software deployment management system 100 may generate a new modifiable deployment plan to be transmitted to the edge device 190a. The vehicle configuration and vehicle user / technician input may be used to determine the new modifiable deployment plan determined by the vehicle software deployment management system 100. For example, based on vehicle user input for deploying an automatic braking function and a vehicle configuration indicating the surplus computing power of vehicle ECU #1, the vehicle software deployment management system 100 may generate a different modifiable deployment plan to use a computationally intensive automatic braking sensor software module (which may require a different deployment sequence). In some embodiments, the modifiable deployment plan and software modules received at T1 may be missing one or more components necessary to execute the newly determined deployment plan. In such a situation, the edge device 190a may request the missing vehicle software modules and modifiable deployment plan after T1322, and the vehicle software deployment management system 100 may transmit the missing vehicle software modules and modifiable deployment plan after T1324.

[0035] Figure 4 illustrates a more detailed diagram of a cloud-based vehicle software deployment management system for updating available software modules in a software module catalog, according to several embodiments, where the software module catalog is presented to vehicle technicians and / or users of the vehicle activity site for vehicles that have insufficient network connectivity to remotely perform updates to the vehicle's ECU from the vehicle activity site.

[0036] In some embodiments, based on the vehicle configuration and / or vehicle user / technician input provided to the vehicle software deployment management system 100 by the edge device 190a, the vehicle software deployment management system 100 may further update the software module catalog 240 at T2. In some embodiments, the vehicle software deployment management system 100 may receive additional information (via the vehicle user or another vehicle information source) before T2, when the vehicle 140 has not yet arrived at activity site A 184a (or is not connected to the edge device 190a). The vehicle software module catalog 240 may be a comprehensive database or inventory of software modules available for deployment to the vehicle 140. For example, the vehicle software deployment management system 100 may determine that a software module for the infotainment system has already been deployed to the vehicle and remove that software module from the software module catalog for that particular vehicle. In some embodiments, the vehicle software deployment management system 100 may determine that additional software modules are available for deployment to the vehicle 140 and update the software module catalog 240 with the newly available software modules. In some embodiments, the software module catalog may be updated based on vehicle configurations provided by received vehicle user / technician input and / or edge device 190a, as described in Figures 2B and 3. Once the software module catalog 240 is updated, the technician UI 194 may present the vehicle technician and / or user 430 with available software module updates that reflect the updated software catalog.

[0037] Figure 5A illustrates a more detailed diagram of an edge device at an activity site that establishes a connection to the vehicle's ECU and deploys updates in the ECU according to a modifiable deployment plan, in several embodiments.

[0038] In some embodiments, the modifiable deployment plan may indicate that the software update includes deploying vehicle software modules A 520a, B 520b, C 520c, and D 520d to designated ECUs in the listed order, where vehicle software modules A 520a and B 520b are deployed to ECU #1 150, vehicle software module C 520c is deployed to ECU #2 152, and vehicle software module D 520d is deployed to ECU #3 154. In some embodiments, the edge device 190a may establish a connection to ECU #1 and deploy the software update according to the modifiable deployment plan 510. In some embodiments, the deployment sequence may be a certified deployment sequence that has been tested, reviewed, and verified as having successfully met certification requirements. In some embodiments, the deployment of software modules may be required to conform to a certified sequence, as the sequence is authorized to ensure security, and the certified deployment sequence indicates the correct order that minimizes the risk of errors, inconsistencies, or failures that may arise from deploying components out of sequence.

[0039] Figure 5B illustrates a more detailed diagram of an edge device at a vehicle activity site that prevents the deployment of software modules from deviating from the certified order for installing software modules according to a modifiable deployment plan, in several embodiments.

[0040] In some embodiments, the edge device 190a may attempt to deploy vehicle software module C 520c to ECU#2 152 before deploying vehicle software module B 520b to ECU#1 150. In some embodiments, out-of-sequence deployment may be initiated by a technician via a technician UI 194 that allows at least partial manual control over the deployment process. In some embodiments, the edge device 190a may detect an out-of-sequence deployment request and prevent a connection to and / or deployment to ECU#2 that deviates from the certified order, according to a modifiable deployment plan 512. For example, based on the determination that, according to the deployment plan, vehicle software module B 520b should be deployed to ECU#1 150 and vehicle software module C 520c should not be deployed to ECU#2 152, the edge device 190a may prevent a request by a technician to wirelessly connect to ECU#2.

[0041] In some embodiments, a physical connection to the ECU is made for the deployment of an out-of-sequence vehicle software module, but the edge device 190a may prevent the deployment of the software module. For example, the edge device 190a may establish a connection to ECU #3 514. However, based on the edge device 190a's determination that vehicle software module B 520b should be deployed to ECU #1, the edge device 190a may prevent the deployment of a software module (e.g., vehicle software module D 520d) that deviates from the certified order, according to the modifiable deployment plan 516. In some embodiments, network traffic may be shut down based on the determination that the software module to be deployed (or the ECU connection) is out-of-sequence, even though a physical connection is established between the edge device 190a and the ECU. In some embodiments, the edge device 190a may prevent the execution of instructions for out-of-sequence deployment. In some embodiments, the technician UI 194 may provide an error message 518 to indicate that an out-of-sequence deployment has been prevented. Error message 518 indicates that the deployment failed due to an incorrect order of deployment steps or components, and may indicate the correct modules and deployment sequence in the authenticated order. In some embodiments, the edge device 190a may perform an out-of-sequence deployment of a vehicle software module and send a warning message 519 indicating that the deployment deviates from the authenticated order of deployment steps. In some embodiments, the warning message 519 may include further details about the correct deployment plan that the technician has deviated from, such as the software module that is expected to be deployed next, the ECU to which it will be deployed, and whether the out-of-sequence deployment invalidates the authentication. In some embodiments, the technician UI 194 may provide an alternative deployment plan 521 to address the out-of-sequence deployment. For example, the edge device 190a may receive an instruction to deploy software module D 520d that deviates from the authenticated order.Based on that instruction, the edge device 190a may generate an alternative deployment plan in which the deployment of software module D 520d follows the correct sequence for compliance with certification. The technician UI 194 may provide the technician with the alternative deployment plan 521 for approval.

[0042] Figure 6 illustrates a cloud-based vehicle software deployment management system configured to generate modifiable deployment plans for deploying vehicle software modules based on various vehicle / vehicle fleet deployment operation data and machine learning (ML) models, in several embodiments.

[0043] In some embodiments, various edge devices 602a, 602b, and 602c at each of the vehicle activity sites #1, #2, and #3 600a, 600b, and 600c may transmit historical deployment operation data 601 to the vehicle application transmission module 112 via the network 120. In some embodiments, the historical deployment operation data 601 may be data collected by edge devices related to the deployment process, including error messages, deployment failures, deployment successes, and deployment operations that rendered the vehicle ECU inoperable. In some embodiments, the historical deployment operation data 601 may include data relating to vehicle activity at vehicle activity sites without explicit reservations at each of the vehicle activity sites #1, #2, and #3 600a, 600b, and 600c. For example, the historical deployment operation data 601 may indicate the model of the vehicle that arrived at vehicle activity sites #1, #2, and #3 600a, 600b, and 600c, the vehicle's ECU configuration, the time / duration of the activity, and / or the vehicle software modules that were requested to be deployed. This may be used to predict future vehicle arrivals at a vehicle activity site. After receiving the historical deployment operation data 601, the vehicle application transmission module 112 may send the vehicle data 606 to the vehicle data ML inference module 110, which generates ML inference 606. The generated ML inference 606 may be used by the deployment plan generator 104 to determine the optimal application deployment configuration and generate a deployment plan. In some embodiments, the ML inference 606 may also be a prediction of vehicle activity that is likely to occur at a vehicle activity site, which may be used by the deployment plan generator 104 to determine a modifiable deployment plan for pre-caching at various edge devices 602a, 602b, and 602c. For example, based on the ML inference 606 (predicting vehicles of type "A" and model "B" as likely candidates to arrive at vehicle activity site #1 600a), the deployment plan generator 104 may generate a modifiable deployment plan for pre-caching at edge device 602a.In some embodiments, a software recall may be performed using predictions of vehicle activity. For example, historical patterns or seasonality may be used to determine a specific vehicle activity site (e.g., one or more of vehicle activity sites 600a, 600b, and 600c) that is likely to be visited by a vehicle with an unresolved active software recall. In such a case, the software modules required to perform the software recall may be pre-cached on edge devices located at vehicle activity sites that are likely to be visited by a vehicle with an active software recall.

[0044] In some embodiments, using vehicle data 606 from the fleet, the vehicle data ML inference module may train one or more ML models to generate one or more ML inferences. For example, based on the vehicle data 606, the trained ML model may make inferences indicating the adverse effects of deploying a particular application to a particular ECU environment. For example, based on an ML inference that deploying a first software module to a first type of ECU would render the ECU inoperable, the modifiable deployment plan generator 104 may generate a modifiable deployment plan to deploy the first software module to a second type of ECU. The modifiable deployment plan generator 104 may use the ML inference to generate and transmit a deployment plan, at least in part, based on the generated ML inference 610. The vehicle application transmission module 112 may transmit an updated modifiable deployment plan for the vehicle / predicted vehicle based on the ML inference 614, as described in Figures 1 to 3. In some embodiments, the vehicle data ML inference module 110 may train one or more ML models based on current vehicle information 604 transmitted from the vehicle 140.

[0045] Figure 7 illustrates a flowchart of operations performed by an edge device in several embodiments to receive and modify a vehicle software module and modify a modifiable deployment plan for updating the vehicle's ECU at a future time, where the vehicle has insufficient network connectivity to perform the vehicle's ECU update remotely from a vehicle activity site. In some embodiments, the modifiable deployment plan may be generated based on vehicle information such as the vehicle type, model, and custom features, which is acquired prior to vehicle servicing at a vehicle activity site as described in Figures 1 and 2A-2C.

[0046] In block 710, the edge device receives a deployment plan generated by a cloud-based vehicle software deployment management system for deploying software modules to vehicle electronic control units (ECUs) that have insufficient network connectivity to remotely perform software module updates from vehicle activity.

[0047] In block 720, the edge device may modify the received deployment plan, which is configured to be modified based on inputs determined at a future time when the vehicle is at the vehicle activity site. For example, as illustrated in Figure 2B, the received inputs may be vehicle information such as ECU configuration acquired by the vehicle analyzer, and / or vehicle user / technician input from the technician UI.

[0048] Figure 8 illustrates flowcharts of operations performed by an edge device in several embodiments, which acquire vehicle information and vehicle user input, modify a modifiable deployment plan, and orchestrate the deployment of software modules based on the modified deployment plan.

[0049] In block 810, the edge device may acquire vehicle information or vehicle user input related to the deployment plan. In some embodiments, the acquired vehicle information may be ECU type, model, parameter settings, service date, and other information related to modifications of the deployment plan as described in Figure 2B. In some embodiments, the vehicle user input may be a selection based on higher-end product sales options and / or bundled sales options provided to the vehicle user to be purchased by the technician UI, as described in Figure 2B.

[0050] In block 820, the edge device may modify the deployment plan received from the cloud-based vehicle software management system based on acquired vehicle information or vehicle user input. In some embodiments, as illustrated in Figure 2B, the modification of the deployment plan may involve changing the deployment procedure, changing the software modules to be deployed, or receiving a new deployment plan from the cloud-based vehicle software management system.

[0051] In block 830, the edge device can orchestrate the deployment of software modules on the ECU. In some embodiments, the edge device may determine that the vehicle software modules to be deployed are out of sequence according to a certified order from a modifiable deployment plan, and may prevent the deployment of software modules that deviate from the certified order, as described in Figures 5A and 5B.

[0052] Exemplary computer system Any of the various computer systems may be configured to implement processes related to a vehicle software deployment management system, an edge device, an ECU, an operating system in a vehicle or device, or any other component in the figures above. For example, Figure 9 illustrates a block diagram illustrating an exemplary computer system that implements some or all of the technologies described herein in several embodiments. In various embodiments, a vehicle software deployment management system, a provider network that implements the vehicle software deployment management system and other cloud services, an operating system in a vehicle or device, or any other component in Figures 1 to 8 above may each include one or more computer systems 900 as illustrated in Figure 9.

[0053] In the illustrated embodiments, the computer system 900 includes one or more processors 910 coupled to system memory 920 via an input / output (I / O) interface 930. The computer system 900 further includes a network interface 940 coupled to the I / O interface 930. In some embodiments, the computer system 900 may be an example of a server that implements enterprise logic or provides downloadable applications, while in other embodiments, the server may include more, fewer, or different elements than the computer system 900.

[0054] In various embodiments, the computing device 900 may be a uniprocessor system including one processor, or a multiprocessor system including several processors 910a-910n (e.g., two, four, eight, or another appropriate number). Processors 910a-910n may include any suitable processor capable of executing instructions. For example, in various embodiments, processors 910a-910n may be processors implementing any of various instruction set formats (ISAs), such as x86, PowerPC, SPARC, or MIPS ISA, or any other suitable ISA. In some embodiments, processors 910a-910n may include dedicated processors such as graphics processing units (GPUs) or application-specific integrated circuits (ASICs). In a multiprocessor system, each of processors 910a-910n may, but generally, implement the same ISA.

[0055] The system memory 920 may be configured to store program instructions and data accessible by processors 910a to 910n. In various embodiments, the system memory 920 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiments, program instructions and data that implement one or more desired functions, such as the methods, techniques, and data described above, are stored and shown in the system memory 920 as code (e.g., program instructions) 925 and data storage device 935.

[0056] In one embodiment, the I / O interface 930 may be configured to coordinate I / O traffic between processors 910a-910n, system memory 920, and any peripheral devices within the device, including network interface 940 or other peripheral interfaces. In some embodiments, the I / O interface 930 may perform any necessary protocols, timing, or other data conversions to convert data signals from one component (e.g., system memory 920) into a format suitable for use by another component (e.g., processor 910). In some embodiments, the I / O interface 930 may include support for devices mounted via various types of peripheral buses, such as a PCI bus standard or a variation of the Universal Serial Bus (USB) standard. In some embodiments, the I / O interface 930 may include support for devices mounted via an automotive CAN bus, for example. In some embodiments, the functionality of the I / O interface 930 may be divided into two or more separate components, such as a northbridge and a southbridge. Furthermore, in some embodiments, some or all of the functionality of the I / O interface 930, such as the interface to the system memory 920, may be directly incorporated into the processors 910a to 910n.

[0057] In some embodiments, the network interface 940 may be coupled to the I / O interface 930, as well as one or more input / output devices 950, such as a cursor control device 960, a keyboard 970, and a display 980. In some cases, the embodiment may be implemented using a single instance of the computer system 900, and in other embodiments, multiple such computer systems, or multiple nodes constituting the computer system 900, may be configured to host different parts or instances of program instructions, as described above for various embodiments. For example, in one embodiment, some elements of program instructions may be implemented via one or more nodes of the computer system 900, separate from those nodes that implement other elements.

[0058] The network interface 940 may be configured to allow data exchange between the computing device 900 and other devices associated with one or more networks. In various embodiments, the network interface 940 may support communication over any suitable wired or wireless general-purpose data network, such as Ethernet networks, cellular networks, Bluetooth networks, Wi-Fi networks, or ultra-broadband networks. In addition, the network interface 940 may support communication over telecommunications / telephone networks, such as analog voice networks or digital fiber optic networks, over storage area networks, such as Fibre Channel SANs, or over any other suitable type of network and / or protocol.

[0059] In some embodiments, the system memory 920 may be an embodiment of a computer-readable (e.g., computer-accessible) medium configured to store program instructions and data as described above in order to implement the corresponding embodiments of the methods, systems, and apparatus. However, in other embodiments, the program instructions and / or data may be received, transmitted, or stored on different types of computer-readable media. Generally speaking, the computer-readable medium may include non-temporary storage or memory media such as magnetic or optical media (e.g., disks or DVDs / CDs) coupled to the computing device 900 via the I / O interface 930. One or more non-temporary computer-readable storage media may also include any volatile or non-volatile media such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., which may be included in some embodiments of the computing device 900 as system memory 920 or other types of memory. Furthermore, the computer-readable medium may include transmitting media or signals such as electrical signals, electromagnetic signals, or digital signals transmitted via communication media such as networks and / or wireless links, which may be implemented via the network interface 940. Some or all of the computing devices illustrated in Figure 9 may be used in various embodiments to implement the described functionality, for example, software components running on various different devices and servers may cooperate to provide the functionality. In some embodiments, parts of the described functionality may be implemented using storage devices, network devices, or various types of computer systems. As used herein, the terms “computing device” and “ECU” refer to, but are not limited to, at least all of these types of devices.

[0060] Embodiments of this disclosure may be described in consideration of the following provisions. Clause 1. A system, The cloud-based vehicle software deployment management system further comprises one or more computing devices configured to implement a cloud-based vehicle software deployment management system. It is determined that a vehicle activity will be performed on a vehicle at a vehicle activity site at a future time, The vehicle includes one or more electronic control units (ECUs) that will be updated. The vehicle has insufficient network connectivity to perform ECU updates remotely from the vehicle activity site, and it is determined that Before a future time, generate a deployment plan for deploying one or more software modules on one or more ECUs via a connection established between an edge device located at a vehicle activity site and the vehicle, A system configured to provide an generated deployment plan to an edge device located at a vehicle activity site before a future time, wherein the generated deployment plan is configured to be modified at least in part based on one or more inputs determined at a future time when the vehicle is at the vehicle activity site.

[0061] Article 2. The edge device is located at the vehicle activity site, and the edge device is The acquisition of one or more inputs, the acquisition of one or more inputs including vehicle information or vehicle user input related to the deployment plan, Based on acquired vehicle information or vehicle user input, modify the deployment plan received from the cloud-based vehicle software management system, The system described in Clause 1, configured to orchestrate the deployment of one or more software modules on one or more ECUs.

[0062] Clause 3. Edge devices are In an edge device, receiving a deployment plan before a future time, the deployment plan includes instructions to deploy one or more software modules on one or more ECUs of a vehicle. The system according to Clause 1 or Clause 2, configured to store one or more software modules in an edge device before a future time, wherein the one or more software modules are received with a deployment plan or have been previously cached in the edge device.

[0063] Clause 4. In order to determine that a vehicle activity will be performed at the vehicle activity site at a future time, the cloud-based vehicle software deployment management system shall The vehicle activity reservation is configured to receive instructions from the activity site that it has been scheduled for the vehicle. The cloud-based vehicle software deployment management system is A system as described in any one of Clauses 1 to 3, configured to generate a deployment plan before a future time based on the date or time of a scheduled vehicle activity reservation included in the instructions.

[0064] Clause 5. The cloud-based vehicle software deployment management system is Before the future, It is configured to receive or access vehicle information indicating the vehicle model, the year of manufacture of the vehicle model, the selected vehicle software application for deployment, the vehicle's ECU type or configuration, or the parameter settings for the vehicle's ECU. The generation of the deployment plan is performed at least in part on the received or accessed vehicle information, using the system described in any one of Clauses 1 to 4.

[0065] Clause 6. The cloud-based vehicle software deployment management system is To generate predictions of one or more vehicles that are expected to be at a vehicle activity site at a future time, A system as described in any one of Clauses 1 to 5, configured to select one or more software modules to pre-cached on an edge device based on the generated predictions.

[0066] Article 7. Method, Receiving a deployment plan generated by a cloud-based vehicle software deployment management system for deploying one or more software modules on one or more electronic control units (ECUs) of a vehicle, at an edge device located at a vehicle activity site, wherein the deployment plan is received at the edge device before the vehicle arrives at the vehicle activity site. Establishing a connection between the edge device and the vehicle while the vehicle is located at the vehicle activity site, Modifying a received deployment plan based at least in part on one or more inputs determined while the vehicle is at a vehicle activity site, wherein the received deployment plan is configured to be modified based at least in part on one or more inputs determined at the vehicle activity site. A method comprising orchestrating the deployment of one or more software modules on one or more ECUs using a modified deployment plan.

[0067] Article 8. This further includes obtaining vehicle information or vehicle user input related to the deployment plan received from a cloud-based vehicle software management system while the vehicle is located at the vehicle activity site, Modifying the received deployment plan is to be done in accordance with the method described in Clause 7, based on acquired vehicle information or vehicle user input.

[0068] Article 9. Before the vehicle arrives at the vehicle activity site, the edge device receives one or more software artifacts necessary to deploy one or more software modules to the vehicle's ECU based on the deployment plan, The method according to Clause 7 or 8, further comprising storing one or more received software artifacts in an edge device before the vehicle arrives at a vehicle activity site, and the edge device then orchestrates the deployment of one or more software on one or more ECUs using the stored software artifacts at a future time.

[0069] Clause 10. At least a portion of the modified deployment plan is generated by an edge device in addition to the deployment plan received from the cloud-based vehicle software deployment management system, as described in any one of Clauses 7-9.

[0070] Article 11. This further includes obtaining vehicle user input related to the deployment plan via the user interface of an edge device, the user interface is To indicate one or more ECUs available for update in the vehicle, To obtain permission to overcome the security restrictions of the ECU, The method of Clause 7, which is configured to show the steps for an engineer to execute the deployment plan workflow.

[0071] Clause 12. The method of Clause 7 or Clause 11, wherein the edge device is configured to wirelessly connect to one or more handheld devices, and the connection established between the edge device and the vehicle is made via one or more handheld devices.

[0072] Article 13. The method according to Clause 7, further comprising using an edge device and a connection between the edge device and the vehicle to determine the respective deployment progress of the deployment of one or more software modules on one or more ECUs of the vehicle.

[0073] Article 14. Receiving one or more deployment failures identified at each deployment progress, The method of Clause 13, further comprising modifying the deployment plan based on one or more deployment failures identified in each deployment progress.

[0074] Article 15. The method according to Clause 7, further comprising receiving one or more instances of vehicle information provided by the vehicle user in a cloud-based vehicle software deployment management system, wherein one or more instances of vehicle information include the vehicle model, the year of manufacture of the vehicle model, the vehicle software application selected for deployment, the vehicle's ECU, or parameter settings for the vehicle's ECU.

[0075] Clause 16. The activity site is a vehicle service station, and the edge device is configured to provide connectivity to the vehicle, as described in Clause 7.

[0076] Clause 17. The method described in Clause 7, wherein the activity site is a charging station and the edge device is configured to provide connectivity to the vehicle.

[0077] Clause 18. Edge devices are Based on the deployment plan, prevent out-of-sequence deployment of software module components. To present an authenticated deployment sequence for the components of a software module, or The method of Clause 7, configured to perform one or more of the following: providing an alternative deployment plan.

[0078] Clause 19. One or more non-temporary computer-readable storage media for storing program instructions, wherein when the program instructions are executed on or across one or more processors, the program instructions are stored in one or more processors. It is determined that a vehicle activity will be performed on a vehicle at a vehicle activity site at a future time, Vehicle activity includes making decisions such as updating one or more electronic control units (ECUs) of the vehicle. Before a future time, generate a deployment plan to deploy one or more software modules on one or more ECUs of a vehicle via a connection established between an edge device located at a vehicle activity site and the vehicle, One or more non-temporary computer-readable storage media provide a generated deployment plan to an edge device located at a vehicle activity site before a future time, wherein the generated deployment plan is configured to be modified at least in part based on one or more inputs determined at a future time when the vehicle is at the vehicle activity site.

[0079] Clause 20. When a program instruction is executed on or across one or more processors, it is sent to one or more processors. Using edge devices connected to the vehicle, determine the vehicle configuration, which includes one or more of the vehicle's software configuration or hardware configuration. To provide vehicle configurations that are sent to a cloud-based vehicle software deployment management system, One or more non-temporary computer-readable storage media as described in Clause 19, which are used to generate or update vehicle configuration graphs of vehicles based on vehicle configurations using a cloud-based vehicle software deployment management system.

[0080] The various methods illustrated in the figures and described herein represent illustrative embodiments of the method. The method may be carried out manually, in software, in hardware, or in combination thereof. The order of any method may be changed, and various elements may be added, rearranged, combined, omitted, modified, etc. For example, in one embodiment, the method may be carried out by a computer system including a processor that executes program instructions stored on a computer-readable storage medium coupled to the processor. The program instructions may be configured to implement the functions described herein (e.g., functions such as data transfer tools, various services, databases, devices and / or other communication devices).

[0081] As will be apparent to those skilled in the art, various modifications and changes can be made that have advantages of the present disclosure. It is intended to encompass all such modifications and changes, and therefore the above description is intended to be considered illustrative rather than restrictive.

[0082] Various embodiments may further include receiving, transmitting, or storing instructions and / or data implemented on a computer-accessible medium in accordance with the above description. Generally speaking, computer-accessible mediums may include storage or memory media such as magnetic or optical media, e.g., disks or DVD / CD-ROMs, RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), volatile or nonvolatile media such as ROM, and transmission media or signals such as electrical, electromagnetic, or digital signals transmitted over communication media such as networks and / or wireless links.

Claims

1. It is a system, The computing device comprises one or more computing devices configured to implement an edge device, and the edge device is Receiving a deployment plan generated by a cloud-based vehicle software deployment management system for deploying one or more software modules on one or more electronic control units (ECUs) of a vehicle, at the edge device when it is located at a vehicle activity site, wherein the deployment plan is received at the edge device before the vehicle arrives at the vehicle activity site. While the vehicle is located at the vehicle activity site, a connection is established between the edge device and the vehicle. Modifying the received deployment plan based at least in part on one or more inputs determined while the vehicle is at the vehicle activity site, wherein the received deployment plan is configured to be modified based at least in part on one or more inputs determined at the vehicle activity site. A system configured to orchestrate the deployment of one or more software modules on one or more ECUs using the modified deployment plan.

2. The system further comprises one or more computing devices configured to implement the cloud-based vehicle software deployment management system, and the cloud-based vehicle software deployment management system is It is determined that a vehicle activity will be performed on the vehicle at the vehicle activity site at a future time, The aforementioned vehicle is equipped with one or more updated electronic control units (ECUs), The vehicle has insufficient network connectivity to perform the update of the ECU remotely from the vehicle activity site, Before the aforementioned future time, generate the deployment plan for deploying the one or more software modules on the one or more ECUs via a connection established between the edge device located at the vehicle activity site and the vehicle, The system according to claim 1, configured to provide the generated deployment plan to the edge device located at the vehicle activity site before the aforementioned future time, wherein the generated deployment plan is modified at least in part based on one or more inputs determined at the future time when the vehicle is at the vehicle activity site.

3. The edge device is The edge device receives, before the future time, the deployment plan, which includes instructions for deploying the one or more software modules on the one or more ECUs of the vehicle. The system according to claim 2, wherein the edge device is configured to store the one or more software modules before the future time, and the one or more software modules are received together with the deployment plan or are previously cached on the edge device.

4. In order to determine that the vehicle activity will be performed at the vehicle activity site at the future time, the cloud-based vehicle software deployment management system: The system is configured to receive instructions that a vehicle activity reservation has been scheduled for the vehicle on the activity site. The aforementioned cloud-based vehicle software deployment management system is The system according to claim 2 or 3, configured to perform the generation of the deployment plan before the future time based on the date or time of the scheduled vehicle activity reservation included in the instruction.

5. The aforementioned cloud-based vehicle software deployment management system is Generate predictions of one or more vehicles that are expected to be at the vehicle activity site at the aforementioned future time, The system according to claim 2 or 3, configured to select one or more software modules to be pre-cached in the edge device based on the generated prediction.

6. It is a method, Receiving a deployment plan generated by a cloud-based vehicle software deployment management system for deploying one or more software modules on one or more electronic control units (ECUs) of a vehicle, at an edge device located at a vehicle activity site, wherein the deployment plan is received at the edge device before the vehicle arrives at the vehicle activity site. While the vehicle is located at the vehicle activity site, a connection is established between the edge device and the vehicle. Modifying the received deployment plan based at least in part on one or more inputs determined while the vehicle is at the vehicle activity site, wherein the received deployment plan is configured to be modified based at least in part on one or more inputs determined at the vehicle activity site. A method comprising orchestrating the deployment of one or more software modules on one or more ECUs using the modified deployment plan.

7. The further includes obtaining vehicle information or vehicle user input related to the deployment plan received from the cloud-based vehicle software management system while the vehicle is located at the vehicle activity site, The method according to claim 6, wherein modifying the received deployment plan is based on acquired vehicle information or vehicle user input.

8. Before the vehicle arrives at the vehicle activity site, the edge device receives one or more software artifacts necessary to deploy the one or more software modules on the vehicle's ECU based on the deployment plan. The method according to claim 6 or 7, further comprising storing one or more received software artifacts in the edge device before the vehicle arrives at the vehicle activity site, wherein the edge device uses the stored one or more software artifacts to orchestrate the deployment of one or more software on one or more ECUs at the future time.

9. The method according to claim 6 or 7, wherein at least a portion of the modified deployment plan is generated by the edge device in addition to the deployment plan received from the cloud-based vehicle software deployment management system.

10. The further includes obtaining vehicle user input related to the deployment plan via the user interface of the edge device, the user interface is The vehicle in question indicates one or more ECUs that can be used for replacement. Having received permission to overcome the security restrictions of the aforementioned ECU, The method according to claim 6, configured to show steps for an engineer to execute the workflow of the deployment plan.

11. The method according to claim 6, further comprising using the edge device and the connection between the edge device and the vehicle to determine the deployment progress of each of the one or more software modules on the one or more ECUs of the vehicle.

12. Receiving one or more deployment failures identified in each of the aforementioned deployment progresses, The method according to claim 11, further comprising modifying the deployment plan based on one or more deployment failures identified in each of the deployment progresses.

13. The method according to claim 6, further comprising receiving one or more instances of vehicle information provided by a user of the vehicle, wherein one or more instances of the vehicle information include a vehicle model, a year of manufacture of the vehicle model, a vehicle software application selected for deployment, an ECU of the vehicle, or parameter settings for the ECU of the vehicle.

14. The method according to claim 6, wherein the activity site is a vehicle service station, and the edge device is configured to provide connectivity to the vehicle.

15. The method according to claim 6, wherein the activity site is a charging station, and the edge device is configured to provide connectivity to the vehicle.

Images