Vehicle software deployment service

Abstract

A system including one or more computing devices implements a vehicle software deployment management system. The vehicle software deployment management system enables a client to send a signed serialized data chunk of a vehicle software application and a deployment plan of the software application to a vehicle using a protocol agnostic transport format. The vehicle software deployment management system may generate a deployment plan that may be processed by an on-board application deployment planner / orchestrator of the vehicle to deploy a particular vehicle software application. The vehicle software deployment management system may send the vehicle software application using a container to be used by ECU agents of various ECUs of the vehicle. In addition, the vehicle software deployment management system may utilize the received vehicle information to dynamically generate one or more updated vehicle deployment plans for transmission to respective vehicles.

Description

BACKGROUND OF THE INVENTION

[0001] Modern vehicles, such as cars, trucks, motorcycles, etc., are typically manufactured with electronic sensors and include computer systems programmed with control algorithms that obtain inputs from such electronic sensors to determine various control actions to be taken with respect to the vehicle or systems implemented in the vehicle. Some vehicles may include multiple electronic control units (ECUs) and various sensor modalities. Additionally, the deployment of vehicle software applications may require that the vehicle software applications be compatible with the execution environment of a particular ECU in which the vehicle software application will be deployed. Furthermore, the communication formats used by the vehicle to receive vehicle software applications may limit or slow down the delivery of the software applications to the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 Shows a vehicle software deployment management system according to some embodiments that sends signed serialized data chunks of vehicle software applications and a deployment plan for the software applications to a vehicle using a protocol-agnostic transport format, and / or dynamically generates and sends a deployment plan for deploying a vehicle software application based on received vehicle data flows.

[0003] Figure 2 Shows a more detailed view of a vehicle software deployment management system according to some embodiments, its various parts and interactions, which are used to generate signed serialized data chunks of vehicle applications and / or a deployment plan and send the signed serialized data chunks to the vehicle using a protocol-agnostic transport format.

[0004] Figure 3 Shows a graphical view of an example in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, which receives signed serialized data chunks of deployments and / or vehicle applications to be deployed at the vehicle from a vehicle software deployment management system, wherein the in-vehicle application deployment planner / orchestrator enables the deployment of in-vehicle applications in the execution environment of the vehicle.

[0005] Figure 4 Shows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments and the use of conditional rules of a deployment plan to deploy vehicle software applications.

[0006] Figure 5 Shows a more detailed view of a vehicle software deployment management system according to some embodiments, its various parts and interactions, which are used to dynamically generate and send a deployment plan for deploying a vehicle software application based on vehicle data flows.

[0007] Figure 6AShows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, the in-vehicle application deployment planner / orchestrator using a deployment plan received from a vehicle software deployment management system to deploy vehicle applications, wherein the in-vehicle application deployment planner / orchestrator also sends ECU configurations and vehicle diagnostic data streams from the vehicle's ECUs back to the vehicle software deployment management system for dynamically updating the deployment plan for deploying in-vehicle applications on the vehicle.

[0008] Figure 6B Shows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, the in-vehicle application deployment planner / orchestrator redeploying vehicle applications implemented using various ECUs based on an updated deployment plan from a vehicle software deployment management system.

[0009] Figure 7 Shows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, the in-vehicle application deployment planner / orchestrator using an alternative local execution plan that prioritizes the availability of safety-critical applications over non-safety-critical applications.

[0010] Figure 8 Shows a vehicle software deployment management system according to some embodiments, configured to dynamically generate a deployment plan for vehicle applications based on various vehicle / vehicle fleet data streams and machine learning (ML) models.

[0011] Figure 9 Shows a flowchart of an operation performed by a vehicle software deployment management system according to some embodiments to send signed serialized data chunks of vehicle software applications and / or a deployment plan for the software applications to a vehicle using a protocol-agnostic transport format.

[0012] Figure 10 Shows a flowchart of an operation performed by an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments to implement an execution plan to implement vehicle software applications, wherein the execution plan is generated by the in-vehicle application deployment planner / orchestrator based on a received deployment plan for the in-vehicle applications.

[0013] Figure 11 Shows a flowchart of an operation performed by a vehicle software deployment management system according to some embodiments to dynamically generate and send a deployment plan for deploying vehicle software applications based on vehicle data flow.

[0014] Figure 12 Shows a flowchart of an operation performed by an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments to implement an execution plan to implement vehicle software applications according to a dynamically generated deployment plan received by the in-vehicle application deployment planner / orchestrator.

[0015] Figure 13 A block diagram is shown in accordance with some embodiments, which shows an example computer system that implements some or all of the techniques described herein.

[0016] Although embodiments are described herein by way of example with respect to several embodiments and illustrative diagrams, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or diagrams. It should be understood that the diagrams and the detailed description thereof are not intended to limit the embodiments to the particular forms disclosed, but on the contrary, are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of the specification or the claims. As used throughout this application, the word "may" is used in an allowable sense (i.e., meaning "has the possibility of") rather than a mandatory sense (i.e., meaning "must"). Similarly, the words "include", "including", and "includes" mean including (but not limited to). Detailed Description

[0017] The systems and methods described herein include techniques for implementing a vehicle software deployment management system that sends signed serialized data chunks of vehicle software applications and a deployment plan for the vehicle software applications to a vehicle and / or an in-vehicle application deployment planner / orchestrator of the vehicle. The in-vehicle application deployment planner / orchestrator is configured to receive the signed serialized chunks of the vehicle software applications and the associated deployment plan and generate a local deployment plan for deploying components of the in-vehicle software applications.

[0018] For example, modern vehicles are equipped with various electronic control units (ECUs), various types of buses, which can use multiple in-vehicle communication protocols and can be arranged in the vehicle in various configurations. Additionally, along with a large amount of variability regarding the vehicle environment configuration, vehicle software applications requested to be deployed in the vehicle can be large and complex, having multiple components that need to be deployed in a specific manner across various ECUs in the vehicle's ECUs, and these ECUs can be arranged in different configurations that vary between vehicles. Furthermore, the deployment of vehicle software can be further complicated because the software components involved in the deployment of vehicle software have multiple dependencies. For example, the vehicle software application requested to be deployed can be a distributed application, and due to the dependencies of various components, the distributed application needs to deploy its components in a specific sequence. It should be noted that the dependencies can include dependencies between software components. For example, as an example, component A must be deployed before component B. Moreover, the dependencies can also include software / hardware dependencies or network / software dependencies. For example, as an example, software component A can have a dependency that requires it to be deployed on an ECU that has a direct bus connection to another ECU for deploying software component B. And, the dependencies can include pure hardware dependencies. For example, as an example, software component A needs to be installed on an ECU that has a processor with X capacity, while software component B needs to be installed on an ECU that has a processor with Y capacity.

[0019] It can be seen that the deployment of vehicle software applications containing distributed applications poses a significant challenge in a vehicle environment that encompasses a wide variety of combinations of vehicle hardware and software.

[0020] Moreover, the vehicle software deployment planner of the vehicle software deployment management system (e.g., residing in the cloud as an example) can use the deployment plan to coordinate the deployment of vehicle software applications. For example, the deployment plan can indicate to deploy a specific software application component in a specific ECU based on the relationship of dependencies of each component. In addition to determining the sequence of deployment, the vehicle software deployment planner can also determine the optimal vehicle application deployment configuration based on vehicle data (e.g., available computing resources of the ECU, number of CPU cores, memory, cache, storage device of the ECU, etc.). By way of example, the deployment plan can indicate to deploy the vehicle software application to an ECU with greater available processing power compared to another ECU, where the other ECU is feasible but not optimal due to lower available processing power. The vehicle software deployment planner may be able to use the deployment plan to coordinate the deployment of vehicle software applications in an optimal configuration. In some embodiments, the level of detail included in the deployment plan can vary. For example, some deployment plans may include a high level of specificity determined by the vehicle software deployment management system (e.g., residing in the cloud), while other deployment plans may include generalized deployment instructions, where, for example, more refined determinations are made at the vehicle level by the in-vehicle application deployment planner / orchestrator. As an example, a more detailed deployment plan can specify the specific ECU of the vehicle to be used for deployment, while a more generalized (e.g., less refined) deployment plan can specify the characteristics of the ECU to be used for a specific software component, and the selection of a specific ECU based on these characteristics can be left to the in-vehicle application deployment planner / orchestrator to determine.

[0021] In addition, in some embodiments, the vehicle software application may be large such that its size hinders the transmission of the vehicle software application and the deployment plan in a single network transmission unit (e.g., the payload of a data packet). In some embodiments, the vehicle software deployment management system can generate a set of signed serialized data chunks of the vehicle software application and / or the deployment plan to be sent to the in-vehicle application deployment planner / orchestrator for incremental reconstruction. The use of serialization and signing can provide the in-vehicle application deployment planner / orchestrator with a mechanism to confirm that all relevant chunks have been received (even when sent using various different packets that can be delivered out of order, etc.). In addition, the use of serialization can enable the in-vehicle application deployment planner / orchestrator to confirm that packets are not lost during transmission. The chunks can be received and queued at the vehicle and assembled by the in-vehicle application deployment planner / orchestrator. The use of data chunks reduces the size of the individual data packets that must be transmitted and allows for greater flexibility regarding the types of transmission protocols and communication networks available for sending the vehicle software application.

[0022] In some embodiments, the deployment plan can be determined by a vehicle software deployment planner in a server (e.g., a cloud server) such that the server-based vehicle software deployment planner dynamically receives vehicle information and generates a deployment plan based on the received relevant vehicle information. In embodiments using a server-based deployment planner, the deployment plan can contain more refined deployment details, such as relevant instructions / execution plans for an in-vehicle deployment planner / orchestrator to orchestrate and relay for deploying vehicle software applications according to the deployment plan. In other embodiments, the in-vehicle deployment planner / orchestrator can receive a more generalized deployment plan and can generate a more detailed deployment plan locally in the vehicle based on the vehicle information available in the vehicle. In some embodiments, a partial deployment plan for a part of a vehicle software application can be generated by the in-vehicle deployment planner / orchestrator.

[0023] Figure 1 A vehicle software deployment management system is shown according to some embodiments that uses a protocol-agnostic transport format to send signed serialized data chunks of a vehicle software application and a deployment plan of the vehicle software application to one or more vehicles, and / or dynamically generates and sends a deployment plan for deploying the vehicle software application based on received vehicle data flows.

[0024] The vehicle system can include a vehicle software deployment management system 100 and a network 120 connected to vehicles 140, 142, 143, and 144. Although Figure 1 Four vehicles 140, 142, 143, and 144 are shown connected to the vehicle software deployment management system 100 via the network 120, but this illustration is only intended as an example and it should be understood that any number of vehicles can form a fleet of vehicles connected to the network 120. In some embodiments, the network 120 can be connected to vehicles containing various components configured to send and receive signals using different vehicle signal formats and / or containing various ECU environments. In some embodiments, the vehicles can use a homogeneous vehicle signal format and / or a homogeneous set of ECUs. Additionally, customers 122a through 122n can be connected to the vehicle software deployment management system via the network 120. Customers 122a through 122n can be vehicle suppliers or vehicle component suppliers (e.g., vehicle original equipment manufacturers (OEMs) and / or parts suppliers). The network 120 can be a private or public network, such as a direct connection to a service provider network hosting the vehicle software deployment management system 100, or an Internet connection. Additionally, the network 120 can be a wireless network, such as a cellular network, a WiFi network, or other wireless network. In some embodiments, vehicles 140, 142, 143, and 144 can be connected to multiple types of networks 120, not just one type of network 120.

[0025] In some embodiments, the vehicle software deployment management system 100 may include a deployment plan generator 104, a fleet management system 102, a vehicle application storage 106, a vehicle application market 108, a vehicle data ML inference module 110, and a vehicle application transmission module 112. The deployment plan generator 104 may generate a deployment plan 130 for a single vehicle (e.g., vehicle 142) or a fleet of vehicles 140, 142, 144, and 146 based on vehicle application deployment requests 124a - 124n. Regarding the vehicle software applications to be deployed, the deployment plan generator 104 may obtain the vehicle software applications to be deployed from the vehicle application storage 106, an external application storage 206( Figure 2 as shown) and / or directly from the customer 122. In some embodiments, the vehicle software applications to be deployed may be provided using an Open Container Initiative (OCI) image that is compatible with the ECUs in the vehicles in which the vehicle software applications are to be deployed. In some embodiments, the vehicle application market 108 may present various vehicle applications to the customers 122a - 122n that are allowed to be deployed to a given vehicle. The customers 122a - 122n may indicate specific applications to be deployed to the vehicle in the vehicle application deployment requests. Although not shown, in some embodiments, the control plane of the vehicle software deployment management system 100 allows the customers 122a, 122n to perform various actions required to deploy one or more vehicle software applications and update the deployment plan. The control plane of the vehicle software deployment management system 100 may register vehicles, model the vehicles (e.g., manage vehicle shadows), and manage data across a single vehicle or a fleet of vehicles. The deployment plan generator 104, the vehicle application storage 106, and the vehicle application market 108 will be further discussed in Figure 2 and Figure 5 .

[0026] In some embodiments, the deployment plan generator 104 may use software contained within a container having an Open Container Initiative (OCI) image format to generate a deployment plan for vehicle software applications to be implemented. The deployment plan generator 104 may generate a deployment plan 130 that may be processed by the in-vehicle application deployment planner / orchestrator 150 of the vehicle 142 to deploy a specific vehicle software application. In some embodiments, the in-vehicle application deployment planner / orchestrator 150 may include one or more subsystems that process the deployment plan sent from the vehicle software deployment management system 100 and may create a local ECU execution plan based on metadata obtained from ECUs in the vehicle via one or more ECU agents deployed at the ECUs. In some embodiments, the deployment plan 130 sent to the vehicle may create one or more local ECU execution plans, and then the one or more local ECU execution plans may be transmitted by the in-vehicle application deployment planner / orchestrator 150 to the corresponding ECUs. In some embodiments, the execution plans may be transmitted to the corresponding ECUs according to a specific sequence. The in-vehicle application deployment planner / orchestrator 150 and the local execution plan will be discussed further in Figure 3 connection with the in-vehicle application deployment planner / orchestrator 150 and the local execution plan.

[0027] In some embodiments, the vehicle application transfer module 112 may ingest one or more vehicle data streams 132 from vehicles 140, 142, 144, and 146; decode the ingested one or more vehicle data streams; and transfer a deployment plan and / or vehicle application to the respective vehicle. As further discussed herein, in some embodiments, the deployment plan may be adjusted based on information provided in the one or more vehicle data streams 132. Additionally, the vehicle application transfer module 112 may provide a vehicle-side software development kit (SDK) or other collection of software development kits to interpret the deployment plan (or other messages) and interpret vehicle software applications (including OCI images and dependencies of the applications) to the vehicle. Additionally, the vehicle application transfer module 112 may include a first-in-first-out (FIFO)-type queue that stores signed serialized data chunks that have been generated based on an aggregated deployment plan. The signed serialized data chunks may be formatted in a certain way, and the vehicle application transfer module may be configured to transfer the signed serialized data chunks such that the signed serialized data chunks can be relayed using any communication protocol / mechanism preferred by the customer. The vehicle application transfer module 112 may generate a collection of signed serialized data chunks of only vehicle applications, only deployment plans, or both deployment plans and vehicle applications. In some embodiments, customers 122a - 122n may indicate the desired size of the data chunks to be transferred to vehicles 140, 142, 144, and 146. For example, the grouped chunk transfer 170 of vehicle applications and deployment plans may be determined according to the respective vehicle application deployment requests 124a - 124n of the respective customers 122a - 122n. In some embodiments, the chunks may be signed to enable the in-vehicle application deployer / orchestrator 150 to verify that the received data chunks were sent by the correct entity. In some embodiments, third-party applications may utilize the cloud-side SDK to interact with the vehicle software deployment management system 100 and transfer signed serialized data chunks to any of the connected vehicles. Additionally, in some embodiments, the vehicle software deployment management system 100 may communicate with the vehicle using one or more protocols, including the Message Queuing Telemetry Transport (MQTT) protocol, Constrained Application Protocol (CoAP), Extensible Messaging and Presence Protocol (XMPP), Advanced Message Queuing Protocol (AMQP), and / or Data Distribution Service (DDS).

[0028] In some embodiments, the in-vehicle application deployer / orchestrator 150 may implement a gateway for the vehicle 142 to receive the grouped chunk transfer 170 of vehicle applications and deployment plans. Although not shown in detail, the in-vehicle application deployer / orchestrator 150 may be implemented in the ECU or other computing unit of the vehicle 142. The in-vehicle application deployer / orchestrator 150 may provide an in-vehicle receiving module (e.g., Figure 3as discussed in the on-vehicle receiving module 314). Further, the on-vehicle deployment planner 150 may allow a vehicle to process signed serialized data chunks transmitted via a communication protocol / mechanism for transmitting signed serialized data chunks in a protocol-agnostic manner. The on-vehicle application deployment planner / orchestrator 150 may incrementally reconstruct a deployment plan and an application package / container image to be used for implementing an on-vehicle application based on the chunked data sent to the vehicle. Once the chunked transmission of the deployment plan and the vehicle application is received, the on-vehicle application deployment planner / orchestrator 150 may use the received chunks to incrementally reconstruct the deployment plan and the application package / container image. In some embodiments, the data chunks may be verified and routed to a package manager for application reconstruction (including OCI image reconstruction) and / or an ECU task delegator for plan execution (as Figure 3-4 discussed). In some embodiments, the deployment plan may not be processed for execution until the prerequisite OCI image is fully reconstructed in the local repository. In some embodiments, the on-vehicle application deployment planner / orchestrator 150 may use a multi-protocol communication mediator to interact with ECU agents in one or more ECUs of the vehicle.

[0029] In some embodiments, the vehicle communication bus 158 of the vehicle 142 may transmit vehicle information sent from various components of the vehicle, such as the electronic control unit 152 (ECU #1), the electronic control unit 154 (ECU #2), and the electronic control unit 156 (ECU #3). Additionally, other components, such as physical sensor #1 160, physical sensor #2 162, and physical sensor #3 163, may be connected to the vehicle communication bus 158 and / or one or more of the vehicle's ECUs. In some embodiments, the various physical sensors may include audio / visual sensors that obtain audio / visual information and may transmit such information via the vehicle communication bus 138. In some embodiments, the various physical sensors 160, 162, and 164 may include position sensors capable of obtaining the position of the vehicle. In some embodiments, the position sensor may be a GPS using cellular, wireless passive, satellite, and other types of global positioning system (GPS) systems. The position sensor may obtain position information that is further processed by the on-vehicle application deployment planner / orchestrator 150 before being transmitted to the vehicle software deployment management system 100 via the network. In some embodiments, the various physical sensors may be connected to multiple vehicle communication buses and / or physical sensors. For example, in the vehicle 142, the physical sensor 162 (physical sensor #2) may be connected to the ECU 154 (ECU #2) and the ECU 156 (ECU #3) via the vehicle communication bus 158. The various vehicle communication bus 158 connections may provide alternative sensor signal paths. As will be described in Figure 3As further discussed, the various portions of the vehicle communication bus 158 can be different types of buses and / or buses using different types of in-vehicle communication protocols. The in-vehicle communication protocols used in the vehicle 142 can 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 Diagnostic (OBD) protocol.

[0030] The various vehicles 140, 142, 144, and 146 can generate vehicle data streams 132 containing various or various types of vehicle information that is sent to the vehicle software deployment management system 100. The in-vehicle application deployment planner / orchestrator 150 can send various diagnostic data for the vehicle 142, including information generated by physical sensor #1 (160), physical sensor #2 (162), and physical sensor #3 (164); and / or ECU configurations of the vehicle 142, including ECU #1 (154), ECU #2 (156), and / or ECU #3 (158) configurations. The vehicle application transmission module 112 can directly ingest the vehicle data stream 132 and decode the information. For example, in some embodiments, the extracted vehicle data can include compressed data, such as video frames, images, radar amplitudes, temperature data, engine speed, driver performance, and / or other information about the vehicle, which can be decoded into available vehicle data that can be used by the vehicle software deployment management system 100. In some embodiments, the vehicle data can be enriched with other vehicle information. The vehicle software deployment management system 100 can utilize the received vehicle information to dynamically generate one or more updated vehicle deployment plans 130 for sending to the corresponding vehicles.

[0031] The deployment plan generator 104 of the vehicle software deployment management system 100 can dynamically generate a deployment plan that allows for continuous optimization of the deployment configuration of software applications within the corresponding vehicle. For example, the vehicle 142 can utilize the in-vehicle application deployment planner / orchestrator 150 to implement the newly optimized deployment plan to manage the application lifecycle and deployment destinations of containers for implementing one or more in-vehicle applications, including the various ECUs of the vehicle 142 for executing the code contained in the containers, such as Figure 5-6. This will be further discussed in [0000089]. In some embodiments, the vehicle application deployment planner 150 may continuously obtain the optimal deployment configuration from the vehicle software deployment management system 100 and redeploy and / or reassign applications based on the dynamically updated deployment plan. One or more customers may determine and / or specify the applications to be deployed and the vehicle configurations to be used for optimizing the deployment of the applications to utilize fleet management 102 or the vehicle application market 108. The deployment plan generator 104 may use the vehicle ECU configuration and diagnostic data and ML inferences generated from vehicle data and other sources to determine the optimized configuration for deploying applications on the vehicle, as further discussed in [0000089]. Figure 8 This will be further discussed in [0000089]. In some embodiments, when the vehicle software deployment management system 100 cannot connect to the vehicle (e.g., in a situation where there is no Internet connection available for the vehicle), a local execution plan may be utilized, which prioritizes the availability of safety-critical applications over non-safety-critical applications.

[0032] In some embodiments, fleet management 102 may utilize vehicle data 132 to reconstruct a representation or state of the vehicle in a vehicle simulator (e.g., a virtual copy of the vehicle). The reconstructed representation can be used to test various vehicle software applications, including testing the deployment of vehicle software applications, as further discussed in [0000092]. Figure 5 In addition, the in-vehicle application deployment planner / orchestrator 150 may use a deployment adapter interface to communicate with different runtime environments that can be deployed in vehicle ECU partitions, such as Autosar Classic, Autosar Adaptive, Android, OCI container framework, and / or WASM runtime, as further discussed in [0000093]. Figure 6A-6B This will be further discussed in [0000093].

[0033] Note that the previous descriptions of the vehicle software deployment management system and the in-vehicle application deployment planner / orchestrator are logical descriptions and should not be construed as limitations on a particular implementation or parts thereof. This specification continues with various examples of the vehicle software deployment management system and the in-vehicle application deployment planner / orchestrator, including different components / modules or different arrangements of components / modules that can be adopted as part of the implementation system / planner. Several different methods and techniques for implementing protocol-agnostic transmission of signed serialized transport application packages / images and deployment plans are discussed, some of which are shown in the accompanying flowcharts. Several different methods and techniques for implementing the dynamic generation of deployment plans are also discussed, some of which are similarly shown in the accompanying flowcharts. Finally, a description of an example computing system on which various components, modules, systems, devices, and / or nodes can be implemented is provided. Various examples are provided throughout this specification.

[0034] Figure 2Shows a more detailed view of a vehicle software deployment management system, its various parts, and interactions for generating signed serialized data chunks of a vehicle application and / or deployment plan and sending the signed serialized data chunks to a vehicle using a protocol-agnostic transport format.

[0035] In Figure 2 it, the vehicle software deployment management system 100 can receive a request 200 to deploy a vehicle application. In some embodiments, the request 200 to deploy a vehicle application can be a vehicle application deployment request 124a from a customer 122a as shown in Figure 1 or can be a deployment request from another client. The request to deploy a vehicle application can indicate to the vehicle software deployment management system 100 the vehicle software application to be deployed to the vehicle 142. In some embodiments, instead of the request 200 to deploy a vehicle application, the vehicle software deployment management system 100 can receive the vehicle application 202 itself from the client / customer as a supplement or alternative to the indication of the vehicle software application to be deployed. In some embodiments, the vehicle application 202 can contain code included in one or more containers formatted in the OCI image format for deployment using a containerized computing environment. For example, the in-vehicle application deployer / orchestrator 150 can implement operating system (OS)-level virtualization or an OS paradigm where the kernel allows for the existence of multiple isolated software instances, called containers. The containerized environment can support various interpreted or compiled programming languages such as Ruby, Perl, Python, C, C++, etc.

[0036] In some embodiments, the vehicle application 204 can be a custom vehicle application sent to the vehicle software deployment management system 100 along with the request 200 to deploy a vehicle application. The vehicle application 204 can be added to the vehicle application storage 106 and / or the external vehicle application storage 106. The vehicle application storage 106 can be various object or file data storage devices for placing, updating, and retrieving data objects or files (including application packages such as container images). For example, the vehicle application storage 106 can be an object-based data repository that allows different data objects of different data formats or types, such as vehicle software application files with the OCI format. In some embodiments, the received application can be a collection of one or more custom application packages / container images not found in the vehicle application storage 206. The data objects in the vehicle application storage 206 can further include associated dependency software packages (dependencies) that include dependency OCI images. In some embodiments, the control plane of the vehicle software deployment management system 100 can be accessed via a programming interface (e.g., an API) or a graphical user interface to manage the applications stored in the vehicle application storage 106.

[0037] Once the vehicle software deployment management system 100 receives a request 200 to deploy a vehicle application, where the application is identified (or included) in the request 200, the deployment plan generator 104 can generate a deployment plan 208 for deploying the application on the vehicle, and the deployment plan can be used by the on-vehicle application deployment planner / orchestrator 150 to deploy the identified vehicle application, as Figure 1 discussed. In some embodiments, the vehicle application transfer module 112 can retrieve the vehicle application package / container image 210 based on the indications included in the deployment plan. In some embodiments, the vehicle application transfer module 112 can retrieve a directory of vehicle applications stored in the vehicle application storage 106 and retrieve the vehicle applications based on the applications described in the directory and the various dependencies further identified in the directory. In some embodiments, the vehicle application transfer module 112 can retrieve one or more portions 214 of the vehicle application from an external vehicle application storage. Similar to retrieving the applications stored in the vehicle application storage 106, the vehicle application transfer module 112 can retrieve the vehicle applications based on how the application components are described in the external vehicle application storage 206 directory and the various dependencies further identified in the external directory (e.g., stored in the external storage 206). In some embodiments, the vehicle application 204 can be provided directly from the deployment plan generator 104 to the vehicle application transfer module 112.

[0038] Once the vehicle application transfer module 112 obtains all the vehicle application components / images, the vehicle application transfer module 112 can generate data chunks of the vehicle application and / or the deployment plan. The data chunks reduce the size of the individual data packets that must be transmitted and allow for greater flexibility in terms of the types of transport protocols and communication networks that can be used. As Figure 1 discussed, the data chunks can be signed and / or serialized and can be received by the on-vehicle application deployment planner / orchestrator 150 to deploy the application in the vehicle 142. In some embodiments, a specific signature associated with the signed chunk can be recognized by the on-vehicle application deployment planner / orchestrator 150 to verify that the signed chunk is from the correct entity and / or that the signed chunk has been received by the correct vehicle. In some embodiments, the data chunks can be encrypted such that the data chunks can be used at a vehicle that can access the correct encryption key and otherwise cannot be used by unauthorized entities. For example, the on-vehicle application deployment planner / orchestrator 150 can be able to access a private key in a secure repository such that the vehicle 142 can decrypt the encrypted data chunks, while other vehicles that are not the specific target may not be able to decrypt the data chunks. In some embodiments, the vehicle application transfer module can store the data chunks in the packet chunk vehicle package transfer queue 212 and use Figure 1One or more of the various transport protocols described in to send the packetized vehicle applications and deployment plans. In some embodiments, the vehicle application transport module 112 can send the packetized vehicle applications and deployment plans to the vehicle via an external data transport service (e.g., a third-party over-the-air (OTA) service). In some embodiments, the external service used to transport data chunks can use additional signing / encryption. In some embodiments, the vehicle application transport module can use a separate MQTT service 220 to transport the packetized data. One or more of the data chunks can be sent using a protocol-agnostic transport format that is compatible with multiple different transport protocols used for communication between the vehicle software deployment management system 100 and the vehicle 142. In some embodiments, the protocol-agnostic transport format can be a format that is compatible with various external data transport services / OTA services that utilize multiple different transport protocols.

[0039] Figure 3 A graphical view showing an example in-vehicle application deployer / orchestrator for a vehicle according to some embodiments, the in-vehicle application deployer / orchestrator receiving signed serialized data chunks of vehicle applications to be deployed and / or received at the vehicle from a vehicle software deployment management system, wherein the in-vehicle application deployer / orchestrator enables the deployment of in-vehicle applications in the execution environment of the vehicle.

[0040] In some embodiments, the in-vehicle application deployer / orchestrator 150 can include an in-vehicle receiving module 312, an in-vehicle transport module 314, a package manager 322, an ECU task delegator 324, and a multi-protocol communication module 326. As Figure 1 discussed, the vehicle communication bus 158 can include different types of buses and / or buses that use different types of in-vehicle communication protocols. For example, a first portion of the vehicle communication bus 158a can be a FlexRay bus, a second portion of the vehicle communication bus 158b can be an Ethernet / IP bus, and a third portion of the vehicle communication bus 158a of the vehicle 142 can be a CAN bus. In some embodiments, there can be multiple CAN buses (e.g., CAN bus #1 and CAN bus #2, etc.) and / or local interconnect (LIN) buses. The vehicle communication bus can utilize Figure 1 the various in-vehicle communication protocols discussed. For example, the CAN bus 158c can utilize the high-speed CAN protocol.

[0041] As Figure 3As shown, the in-vehicle receiving module 312 can receive protocol-agnostic packet block transmissions 216 of vehicle software applications and corresponding deployment plans generated by the vehicle software deployment management system 100. The in-vehicle receiving module 312 can interface with various networks having a network connection to the vehicle and receive packet block transmissions from any one or more of the various networks according to various communication protocols. The in-vehicle receiving module 312 can send the received deployment plan 330 to the ECU task delegator 324 and send the application data 332 to the packager manager. The application data 332 can be organized into chunks of the application and / or chunks of one or more received application packages / container images. The package manager 322 uses the received application data 332 to reconstruct application components (such as container images) for deploying the application in the vehicle 142. In some embodiments, the ECU task delegator 324 can monitor the package manager 340 to verify that prerequisite application components such as OCI images are fully reconstructed before processing the deployment plan and sending one or more deployment instructions 344 to the multi-protocol communication module 326. The one or more deployment instructions 344 can be one or more execution plans for implementing the vehicle software application at the vehicle based on the received deployment plan.

[0042] In some embodiments, the execution plan can include specific instructions regarding the relevant ECU that will be used to deploy the application on the relevant ECU (or, in the case of a distributed vehicle software application not using a container configuration, a specific component of the application). The ECU task delegator can generate individual local execution plans to deploy the application (or a specific component of the application) for each of the ECUs. For example, the ECU task delegator can instruct the multi-protocol communication module 326 to obtain the relevant package / image 342 from the package manager 322 according to the deployment plan for deployment on ECU #1 (152) and send the package / image along with the ECU deployment instruction 350 to ECU #1 (152). The local ECU execution plan can be transmitted to the appropriate ECU, rather than being transmitted to all ECUs of the vehicle.

[0043] In some embodiments, the multi-protocol communication module 326 can implement the translation of various vehicle communication bus 158 protocols to facilitate the transfer of information within the vehicle. For example, the multi-protocol communication module 326 can use the high-speed CAN protocol to send the ECU deployment instruction 350 along with a given image to be deployed to ECU #1 via the CAN bus 158c. Once sent, the multi-protocol communication module 374 of the ECU agent 370 can receive the local ECU deployment instruction 350 using the high-speed CAN protocol and allow the deployment plan executor of the ECU agent 370 to deploy the local ECU deployment instruction.

[0044] In some embodiments, the ECU agent 370 may interact with the underlying components of ECU #1 provided by a real-time operating system (RTOS) vendor or other third-party ECU vendor to manage the lifecycle of vehicle applications. Additionally, in some embodiments, the ECU agent 370 may provide various container network interface (CNI) plugins 372 that extend the capabilities of ECU #1, such as enabling GPU sharing extensions, shared memory extensions, zero-copy inter-process communication (IPC) extensions, etc. for ECU #1. The multi-protocol communication module 326 may notify the ECU task delegator of the status 346 regarding the ECU (including the deployment status of the application) sent from the ECU agent 370. The ECU task delegator 324 may send status messages 338 to be sent from the vehicle 142 to one or more recipients. The protocol-agnostic transport 360 containing the vehicle status may be sent by the in-vehicle transport module 314 to the vehicle software deployment management system 100 or other recipients. The in-vehicle transport module 314 may be similar to the in-vehicle receiving module 312 in terms of supporting Figure 1 the various transport protocols described therein. In some embodiments, a separate MQTT service 220 may be used by the vehicle application transport module to transport packet block data, as Figure 2 discussed. In some embodiments, the transport 360 may be divided into data chunks by the in-vehicle transport module 314 and sent using a protocol-agnostic transport format compatible with multiple different transport protocols used for communication between the vehicle 142 and the vehicle software deployment management system 100. Although Figure 3 it is shown that the in-vehicle application deployment planner / orchestrator 150 only interacts with ECU #1 152, this is by way of example, and the in-vehicle application deployment planner / orchestrator 150 may be connected to various other ECUs, sensors, and other vehicle components and may send corresponding ECU deployment instructions.

[0045] Figure 4 Shows a more detailed view of the in-vehicle application deployment planner / orchestrator of a vehicle according to some embodiments and the deployment of vehicle software applications using conditional rules of the deployment plan.

[0046] In some embodiments, the local ECU execution plan discussed in Figure 3 may be generated based on ECU environment metadata obtained from ECU agents deployed on various ECUs. For example, the in-vehicle application deployment planner / orchestrator 150 may receive a deployment plan 400 from the vehicle software deployment management system 100. In as Figure 3After generating the local execution plan for deploying the application to ECU #1 (152) as discussed, the application may fail to deploy. In some embodiments, metadata indicating a deployment failure 404 generated by ECU #1 (152) can be transmitted to the in-vehicle application deployment planner / orchestrator 150. Based on the received metadata, the ECU task delegator 324 can generate another local execution plan to deploy the application at the opportunistic deployment location A (410a) in ECU #2 154. In some embodiments, in addition to the indication of the failed application deployment, the ECU task delegator 324 can also include various other metadata, such as metadata indicating the ECU processing environment, including the capacity of the ECU's computing resources, the types of containers supported by the ECU, the configurations of other applications deployed to the ECU (such as other containers implemented on the ECU), the number of the ECU's CPU cores, memory, cache, storage devices, etc., and any other performance characteristics of the ECU. For example, the ECU task delegator 324 can determine that the application will be deployed at the opportunistic deployment location B (410b) in ECU #3 156 rather than the opportunistic deployment location A 410a after determining that ECU #2 (154) will not provide a suitable processing environment compared to ECU #3 (156). In some embodiments, other vehicle metadata can be used to determine the local execution plan including sensor data and vehicle communication bus 158 metadata. For example, the ECU task delegator 324 can attempt to redeploy the application to ECU #1 (152) after receiving metadata regarding the disconnected communication bus 412 connecting ECU #3 156 to the ECU task delegator 324.

[0047] In some embodiments, the ECU task delegator 324 can determine the local execution plan based on the conditional rules 402 provided in the deployment plan 400. For example, the conditional rule can state a predetermined ECU to be used as the opportunistic deployment location for a given container image in response to the deployment failure of the given container image in the container image (in the example of using OCI container images). In some embodiments, the conditional rule can indicate the opportunistic deployment location of a given container image in response to the successful deployment of another in the ECU among the multiple ECUs. For example, after successfully deploying an application to ECU #1, another application can then be configured to be deployed to ECU #2. In some embodiments, the conditional rule can indicate the selection of the deployment location of a given container image based on the respective states, characteristics, and / or configurations of the vehicle's ECUs. Various other conditional rules can determine how one or more applications can be deployed.

[0048] Figure 5Shows a more detailed view of a vehicle software deployment management system, its various parts, and interactions that are used to dynamically generate and send a deployment plan for deploying vehicle software applications based on vehicle data flow.

[0049] In some embodiments, the vehicle software deployment management system 100 may receive a request 200 to deploy one or more vehicle applications. In some embodiments, the request 200 may be received by a fleet management 102 that tracks and manages one or more vehicles in a vehicle fleet to which a given application may be deployed. The request may indicate the vehicles to which the one or more applications are to be deployed, including virtual vehicles generated by a vehicle simulator 510 of the vehicle software deployment management system 100 or vehicles to be used as a test environment. For example, the fleet management 102 of the vehicle software deployment management system 100 may test the deployment of an application on a vehicle fleet specifically marked as a test environment by sending a deployment plan and vehicle application to the test fleet 521. For example, based on the request 200, the fleet management may request the deployment plan generator 104 to generate one or more deployment plans for the selected vehicles. Thus, as Figure 5 shown, the deployment plan generator 104 may transmit the deployment plan and vehicle application 506 to the vehicle 142. In some embodiments, the deployment plan and / or vehicle application may be transmitted as signed serialized data chunks, as Figure 2 discussed.

[0050] In some embodiments, the vehicle 142 may generate ECU configurations and vehicle diagnostic data streams and send them to the deployment plan generator 104. According to some embodiments, the deployment plan generator 104 may determine that a more optimized vehicle application configuration is available and may dynamically generate a deployment plan for deploying vehicle software applications based on the vehicle data flow. The data stream 508 may include vehicle data as Figure 4 discussed and Figure 3The ECU state discussed in. The deployment plan generator 104 can determine that a threshold improvement level of the application reliability, processing efficiency, processing speed, and / or another optimization criterion of the vehicle 142 is available. After determining that the threshold improvement level of the vehicle 142 is met, the deployment plan generator 104 can generate and send an updated deployment plan and vehicle application 514 based on the vehicle data stream. For example, the deployment plan generator 104 can determine that a part of the vehicle communication bus is unavailable based on the vehicle diagnostic data, and send the updated deployment plan for redeploying the vehicle application to another ECU. In some embodiments, before sending the updated deployment plan and vehicle application, the deployment plan generator 104 can request authentication 513 of the deployment plan. For example, the deployment plan generator 104 can send a request including the deployment plan, vehicle application, application dependencies, vehicle metadata, and / or application test results to an authentication destination, and the authentication destination can initiate its own separate internal authentication workflow to determine whether the deployment plan should be authenticated and allowed to be deployed. In some embodiments, the authentication destination can reject the deployment plan and request the deployment plan generator 104 to generate another deployment plan with a different application deployment sequence or configuration so that the authentication can be satisfied.

[0051] In some embodiments, the deployment plan generator 104 can perform dependency tracking / verification to determine whether the deployment plan is certified for deployment to the vehicle. For example, vehicle applications can be deployed as groups, where there are certain dependencies between the applications (and / or components of the applications) in the group. The deployment plan generator 104 can generate one or more dependency graphs that track changes made to the applications deployed in the vehicle. When an application is replaced, upgraded, or removed over time, the dependency graph can track the impact of the various changes on the dependencies. The deployment plan generator 104 can also track and / or ensure that such changes do not violate the conditions on which the authentication of the already installed vehicle software applications depends. And, before deploying a new vehicle software application, the deployment plan generator 104 can use the dependency graph to verify that the deployment based on the deployment plan will not have a negative impact on the listed dependencies or otherwise violate the conditions on which the authentication depends. In this way, the authentication of the deployment of the application can be cleared based on determining that the deployment will not break any of the listed dependencies from the dependency graph. The authentication process involving dependency tracking / verification can prevent potential breakage of individual dependencies and prevent the application deployment from failing before it occurs in the vehicle.

[0052] In some embodiments, it can be from such as Figure 2The vehicle application storage device 106 and / or the external vehicle application storage device 206 discussed herein obtain applications. In some embodiments, a request 200 to deploy a vehicle application may be indicated to the vehicle application marketplace 108. The deployment request 200 may be based on a catalog of applications marked as available for a particular vehicle model or a particular vehicle configuration. For example, the vehicle application marketplace 108 may indicate to a client or customer of the vehicle software deployment management system 100 a list of applications available for deployment. In some embodiments, after an application is selected from the application list, the vehicle application marketplace may obtain a viable deployment option 520 from the deployment plan generator. For example, the deployment plan generator 104 may obtain various deployment options that satisfy various optimization criteria (e.g., application reliability, processing efficiency, and processing speed). The vehicle application marketplace 108 may request a selection 522 of a viable deployment option from the client and / or customer. In some embodiments, the request 522 to select a viable deployment option may be sent to the client that sends the request 200 to deploy a vehicle application to the vehicle software deployment management system 100. In some embodiments, the deployment plan generator 104 may determine that no viable vehicle software application can be deployed in the vehicle. In some embodiments, the viable deployment plan options may include the one or more viable deployment options that include options to change one or more of the following: the arrangement of the vehicle software deployed in the vehicle, the set of vehicle software deployed in the vehicle, and / or the specifications of the vehicle hardware components.

[0053] In some embodiments, the vehicle simulator 510 may create a vehicle replica 512 based on the vehicle 142 information obtained by the deployment plan generator 104. The vehicle simulator 510 and the generated vehicle replica may be used to test the deployment 520 of the vehicle application. In some embodiments, the testing of the deployment of the application using the deployment plan may be based on the initial request 200 to deploy the vehicle application. Although Figure 5 one updated deployment plan sent to the vehicle 142 is shown, any number of dynamic updates to the deployment plan sent to the vehicle 142 may exist based on the obtained ECU configuration and vehicle diagnostic data stream.

[0054] Figure 6AShows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, where the in-vehicle application deployment planner / orchestrator deploys vehicle applications using a deployment plan received from a vehicle software deployment management system, and where the in-vehicle application deployment planner / orchestrator also sends ECU configurations and vehicle diagnostic data streams from the vehicle's ECUs back to the vehicle software deployment management system for dynamically updating the deployment plan for the vehicle. In some embodiments, a deployment plan 602 for an application (e.g., Application D) may be received by a vehicle data receiving module 604, which receives the deployment plan and the required application package. In some embodiments, the received application may be an application image in OCI image format, and the vehicle data receiving module 604 may be an over-the-air (OTA) agent that receives the deployment plan for Application D wirelessly. In some embodiments, the vehicle data receiving module 604 may be similar to the in-vehicle receiving module 312 as Figure 3 discussed in

[0055] After receiving the deployment plan for Application D, the ECU task delegator may obtain the deployment plan to generate and / or relay a local execution plan 605. In some embodiments, the deployment plan may contain all relevant local instructions and / or execution plans for the in-vehicle deployment planner / orchestrator 150 to relay to relevant vehicle components (e.g., ECUs) for deploying vehicle software applications. In some embodiments, the relay of the local execution plan may not be limited to an unmodified transmission of the local execution plan generated by the deployment plan generator 104, but may also include modifying the local execution plan, including reassembling, decompressing, reformatting, etc. of the local execution plan. In some embodiments, the in-vehicle deployment planner / orchestrator 150 may receive a partial deployment plan containing a portion of the local execution plan for a vehicle software application, and the local execution plan for the remaining portion of the vehicle software application may be generated by the in-vehicle deployment planner / orchestrator 150, as Figure 3-5 discussed in Figure 3 The multi-protocol communication module 326 may deploy Application D 608 to ECU #1 (152) such that ECU #1 (152) deploys Vehicle Application A 620a and Vehicle Application D 620d. The deployment may occur via one or more vehicle communication buses using one or more communication protocols as Figure 3 discussed in In addition, various ECUs may contain various currently deployed vehicle applications, such as Vehicle Application B 620b in ECU #2 (154) and Vehicle Application C 620c in ECU #3 (156). After successfully deploying Vehicle Application D 620d, ECU #1 may then send the ECU configuration 610 from the deployment of Application D to the vehicle data transmission module 612. In some embodiments, the vehicle data transmission module 612 may be similar to the in-vehicle transmission module 314 as Figure 3 discussed inFigure 2 a transmission module for communicating multiple communication protocols discussed in [document] with the vehicle software deployment management system 100.

[0056] In addition to the ECU configuration 610 from the deployment of Application D, in some embodiments, the vehicle data transmission module 612 may also receive ECU configuration and vehicle diagnostic data from ECU#2 and ECU#3 612, and may send the data as a data stream 508 to the vehicle software deployment management system 100. As Figure 5 discussed in [document], based on the data stream 508 and after determining that the threshold optimization of the vehicle 142 is met, an updated deployment plan may be generated and sent to the vehicle, which may further enable the redeployment of Application D.

[0057] Figure 6B A more detailed view of an in-vehicle application deployment planner / orchestrator of a vehicle according to some embodiments is shown. The in-vehicle application deployment planner / orchestrator redeploys vehicle applications in various ECUs based on an updated deployment plan from the vehicle software deployment management system. In some embodiments, the vehicle data receiving module 604 may receive the updated deployment plan 630. The vehicle software deployment management system 100 may receive the data stream 508 and dynamically generate the updated deployment plan 630. The ECU task delegator 324 may obtain the updated deployment plan to generate and / or relay a local execution plan 631.

[0058] In some embodiments, the local execution plan may include one or more operations for removing Application D 632 from ECU#1. Additionally, the local execution plan may include not only a plan to redeploy Application D 620 to ECU#2 (as shown in the figure), but may also include multiple corresponding local execution plans for the corresponding ECUs to redistribute vehicle applications A, B, C, and D 634. For example, the updated deployment plan may redeploy the previously deployed vehicle application B from ECU#2 154 to ECU#1 152. In some embodiments, the various vehicle applications A 620a, B 620b, C 620c, and D 620d may be sub-components of a distributed vehicle software application and may be redistributed according to the updated deployment plan.

[0059] Figure 7Shows a more detailed view of an in-vehicle application deployment planner / orchestrator for a vehicle according to some embodiments, the in-vehicle application deployment planner / orchestrator using an alternative local execution plan that prioritizes the availability of safety-critical applications over non-safety-critical applications. In some embodiments, the vehicle data receiving module 604 may detect that the connection to the network is unavailable 702. For example, the vehicle data receiving module 604 may determine that one or more of the wireless networks used by the vehicle to receive data (such as a cellular network, a Wi-Fi network, or other wireless networks) are unavailable. After the detection 702, the ECU task delegator 324 may enable the use of the local execution plan 706 when the network connection is unavailable. In some embodiments, instead of detecting that the connection to the network is unavailable, the vehicle data receiving module 604 may detect that the connection to the vehicle software deployment management system 100 is unavailable or that the communication quality or speed has degraded beyond a threshold level.

[0060] In some embodiments, the ECU task delegator 324 may contain an emergency local execution plan 704 and may generate an additional local execution plan that prioritizes the deployment of safety-critical applications 710 over non-safety-critical applications. The emergency local execution plan 704 may be part of the ECU task delegator 324 or may be received from the vehicle software deployment management system 100. For example, in the illustrated vehicle 142, safety-critical applications A 720a, B 720b, and C 720c may be deployed in ECU #1 152, ECU #2 154, and ECU #3 156, respectively, prior to the original vehicle applications A 620a, B 620d, and C 620c. In some embodiments, safety-critical applications may include features that affect passenger safety (such as an airbag deployment application) and / or key vehicle performance features (such as a braking control application). In some embodiments, non-safety-critical applications may include various infotainment applications and / or fuel efficiency applications. The emergency local execution plan may include a prior determination of which applications are considered safety-critical and / or non-safety-critical.

[0061] Figure 8 Shows a vehicle software deployment management system according to some embodiments, which dynamically generates a deployment plan for vehicle applications based on various vehicle / vehicle fleet data streams and machine learning (ML) models. In some embodiments, ECU configurations and vehicle diagnostic data streams 802 from a vehicle fleet may be sent via the network 120 to the vehicle application transfer module 112. After receiving the data stream 802 from the fleet, the vehicle application transfer module 112 may send the vehicle data 806 to the vehicle data ML inference module 110 that generates an ML inference 808. The generated ML inference 808 may be used by the deployment plan generator 104 to determine the optimal application deployment configuration and generate a deployment plan.

[0062] In some embodiments, using vehicle data 806 from a vehicle fleet, a vehicle data ML inference module may train one or more ML models to generate one or more ML inferences. For example, based on vehicle data 806, a trained ML model may make an inference indicating a negative impact of the deployment of a particular application on a particular ECU environment. A deployment plan generator 104 may use the ML inference to generate and send a deployment plan 810 that is at least partially based on the generated ML inference. A vehicle application transmission module 112 may send a deployment plan 812 for the vehicle / fleet based on the ML inference, as discussed in Figure 5 -6. In some embodiments, a vehicle data ML inference module 110 may train the one or more ML models based on current and historical updates 804 of the ECU configuration and diagnostic data of the vehicle sent from vehicle 142. A vehicle application transmission module 112 may use the current and historical updates 804 of the ECU configuration and diagnostic data of the vehicle to send an updated deployment plan 814 for the vehicle based on the ML inference obtained from the ML model.

[0063] Figure 9 A flowchart showing operations performed by a vehicle software deployment management system according to some embodiments for sending a signed serialized data chunk of a vehicle software application image and / or a deployment plan of a software application to a vehicle using a protocol-agnostic transport format.

[0064] At block 910, a vehicle application deployment planner generates a deployment plan for a set of application packages to be used when implementing a vehicle software application. In some embodiments, the application packages may be container images obtained from an external image repository, as discussed in Figure 2 . In some embodiments, the application packages may be container images according to the Open Container Image (OCI) format.

[0065] At block 920, the vehicle application deployment planner generates data chunks of the set of application packages configured to be reconstructed by the vehicle application deployment planner of the vehicle. In some embodiments, the data chunks may be stored in a first-in-first-out (FIFO)-type queue in the vehicle application deployment planner, as discussed in Figure 1 and 2 . However, in some embodiments, other queue orderings may be used.

[0066] At block 930, the vehicle application deployment planner sends the deployment plan and the data chunks to the vehicle. The deployment plan causes the vehicle application deployment planner to generate an execution plan for implementing the vehicle software application based on the deployment plan, and causes the vehicle application deployment planner to execute the execution plan immediately after determining that the data chunks of the set of application packages are fully reconstructed to implement the vehicle software application at the vehicle according to the deployment plan.

[0067] Figure 10 A flowchart showing operations performed by an in-vehicle application deployment planner / orchestrator according to some embodiments to implement the execution of a plan to implement a vehicle software application, where the execution plan is generated by the in-vehicle application deployment planner / orchestrator based on a received deployment plan for the in-vehicle application.

[0068] At block 1010, the in-vehicle application deployment planner / orchestrator receives a deployment plan for a set of application packages to be used when implementing a vehicle software application, and also receives a data chunk of the set of application packages configured to be reconstructed by the vehicle application deployment planner of the vehicle. In some embodiments, the data chunk can be received in a protocol-agnostic transport format compatible with different transport protocols as Figure 1 and 2 discussed in.

[0069] At block 1020, the in-vehicle application deployment planner / orchestrator generates an execution plan for implementing the vehicle software application at the vehicle based on the deployment plan received via the vehicle application deployment planner.

[0070] At block 1030, the in-vehicle application deployment planner / orchestrator reconstructs the data chunk. In some embodiments, the data chunk can be queued in a package manager 322 as Figure 3 discussed in.

[0071] At block 1040, the in-vehicle application deployment planner / orchestrator determines that the set of application packages has been fully reconstructed from the received data chunk.

[0072] At block 1050, the in-vehicle application deployment planner / orchestrator executes the execution plan to implement the vehicle software application at the vehicle according to the deployment plan.

[0073] Figure 11 A flowchart showing operations performed by a vehicle software deployment management system according to some embodiments to dynamically generate and send a deployment plan for deploying a vehicle software application based on vehicle data flow.

[0074] At block 1110, the vehicle application deployment planner receives a vehicle data flow that includes updates indicating the configuration of the electronic control units (ECUs) of the vehicle and / or the diagnostic data of the vehicle. In some embodiments, the received vehicle data can include one or more of the capacity of the computing resources of the ECU, the type of containers supported by the ECU, and the configuration of other applications deployed to the ECU, as Figure 4 discussed in.

[0075] At block 1120, the vehicle application deployment planner dynamically generates a deployment plan for the vehicle software application based on the ECU configuration and / or diagnostic data indicated in the flow.

[0076] At block 1130, a vehicle application deployment planner sends a deployment plan based on a request to deploy a vehicle software application to a vehicle, generates and / or relays a local execution plan for deploying the vehicle software application, and implements the local execution plan. In some embodiments, the deployment plan may be sent based on authentication received from an authentication destination that performs the authentication workflow as discussed in Figure 5 The authentication destination sends the deployment plan.

[0077] Figure 12 FIG. shows a flowchart of operations performed by an in-vehicle application deployment planner / orchestrator of a vehicle to implement an execution plan to implement a vehicle software application according to a dynamically generated deployment plan received by the in-vehicle application deployment planner / orchestrator, according to some embodiments.

[0078] At block 1210, the in-vehicle application deployment planner / orchestrator sends vehicle data streams from vehicles in a vehicle fleet to a dynamic vehicle software deployment planner, where the vehicle data streams indicate electronic control unit (ECU) configurations of the vehicles in the fleet and / or indicate diagnostic data of the vehicles in the fleet.

[0079] At block 1220, the in-vehicle application deployment planner / orchestrator receives a deployment plan for a distributed vehicle software application that has been dynamically generated by a cloud-based dynamic vehicle software deployment planner based on the flow-based indications. In some embodiments, the deployment plan received by the in-vehicle application deployment planner / orchestrator may be a deployment plan optimized for the vehicle based on historical data of the vehicle and / or the vehicle fleet, as discussed in Figure 5 And Figure 8 As discussed in.

[0080] At block 1230, the in-vehicle application deployment planner / orchestrator generates and / or relays a local execution plan for deploying the distributed vehicle software application based on the deployment plan. In some embodiments, the local execution plan may only be relayed to the appropriate ECUs, rather than being transmitted to all ECUs of the vehicle as discussed in Figure 3 As discussed in.

[0081] At block 1240, the in-vehicle application deployment planner / orchestrator implements the execution plan at the vehicle to install the distributed vehicle software application on the vehicle.

[0082] Example computer system

[0083] Any of a variety of computer systems may be configured to implement processes associated with a vehicle software deployment management system, an in-vehicle application deployment planner / orchestrator, an operating system in a vehicle or a device, or any other component of the above figures. For example, Figure 13A block diagram is shown that illustrates an example computer system that implements some or all of the techniques described herein according to some 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 of the foregoing Figure 1-12 may each include, for example Figure 13 one or more computer systems 1300 as shown.

[0084] In the illustrated embodiment, computer system 1300 includes one or more processors 1310 coupled to system memory 1320 via an input / output (I / O) interface 1330. Computer system 1300 further includes a network interface 1340 coupled to the I / O interface 1330. In some embodiments, computer system 1300 may illustrate a server that implements enterprise logic or provides downloadable applications, while in other embodiments, the server may include more, fewer, or different elements than computer system 1300.

[0085] In various embodiments, computing device 1300 may be a single-processor system that includes one processor, or a multi-processor system that includes several processors 1310a - 1310n (e.g., two, four, eight, or another suitable number). Processors 1310a - 1310n may include any suitable processors capable of executing instructions. For example, in various embodiments, processors 1310a - 1310n may be processors that implement any one of a variety of instruction set architectures (ISAs) such as, for example, x86, PowerPC, SPARC, or MIPS ISA or any other suitable ISA. In some embodiments, processors 1310a - 1310n may include specialized processors such as a graphics processing unit (GPU), an application specific integrated circuit (ASIC), etc. In a multi-processor system, each of processors 1310a - 1310n typically may but need not implement the same ISA.

[0086] System memory 1320 may be configured to store program instructions and data accessible by processors 1310a - 1310n. In various embodiments, system memory 1320 may be implemented using any suitable memory technology such as, for example, static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data that implement one or more desired functions (e.g., those methods, techniques, and data described above) are shown as being stored in system memory 1320 as code (e.g., program instructions) 1325 and data store 1335.

[0087] In one embodiment, I / O interface 1330 may be configured to coordinate I / O traffic between processors 1310a - 1310n, system memory 1320, and any peripheral devices in the apparatus, including network interface 1340 or other peripheral interfaces. In some embodiments, I / O interface 1330 may perform any necessary protocol, timing, or other data transformation to convert data signals from one component (such as system memory 1320) into a format suitable for use by another component (such as processor 1310). In some embodiments, I / O interface 1330 may include support for devices attached via various types of peripheral buses, such as variants of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard. In some embodiments, I / O interface 1330 may include support for devices attached via, for example, the automotive CAN bus. In some embodiments, the functionality of I / O interface 1330 may be split into two or more separate components, such as a northbridge and a southbridge. Also, in some embodiments, some or all of the functionality of I / O interface 1330, such as the interface to system memory 1320, may be incorporated directly into processors 1310a - 1310n.

[0088] In some embodiments, network interface 1340 may be coupled to I / O interface 1330 and one or more input / output devices 1350, such as cursor control device 1360, keyboard 1370, and display 1380. In some cases, embodiments may be implemented using a single instance of computer system 1300, while in other embodiments, multiple such computer systems or multiple nodes that make up computer system 1300 may be configured to host different parts or instances of program instructions as described above for the various embodiments. For example, in one embodiment, some elements of the program instructions may be implemented via one or more nodes of computer system 1300 that are different from those implementing other elements.

[0089] Network interface 1340 may be configured to allow data to be exchanged between computing device 1300 and other devices associated with one or more networks. In various embodiments, network interface 1340 may support communication via any suitable wired or wireless general data network, such as types of Ethernet networks, cellular networks, Bluetooth networks, WiFi networks, Ultra - Wideband networks, etc. Additionally, network interface 1340 may support communication via a telecommunications / telephone network (such as an analog voice network or a digital fiber optic communication network), via a storage area network (such as a Fibre Channel SAN), or via any other suitable type of network and / or protocol.

[0090] In some embodiments, system memory 1320 can be an example of a computer-readable (e.g., computer-accessible) medium configured to store program instructions and data for implementing embodiments of the corresponding methods, systems, and devices as described above. However, in other embodiments, the program instructions and / or data may be received, sent, or stored on different types of computer-readable media. Generally, computer-readable media may include non-transitory storage media or memory media, such as magnetic or optical media, e.g., a disk or a DVD / CD coupled to computing device 1300 via I / O interface 1330. One or more non-transitory 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 as system memory 1320 or another type of memory in some embodiments of computing device 1300. Additionally, computer-readable media may include transmission media or signals (e.g., electrical, electromagnetic, or digital signals) communicated via a communication media (e.g., a network and / or a wireless link) implemented, for example, via network interface 1340. For example Figure 13 Some or all of the illustrated plurality of computing devices may be used to implement the functionality described in various embodiments; for example, software components running on a variety of different devices and servers may cooperate to provide the functionality. In some embodiments, portions 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 at least all of these types of devices and are not limited to these types of devices.

[0091] Embodiments of the present disclosure may be described in view of the following clauses:

[0092] Clause 1. A system, comprising:

[0093] One or more computing devices configured to implement a vehicle software deployment management system, the vehicle software deployment management system being configured to:

[0094] Generate a deployment plan for a set of application packages to be used in implementing a distributed vehicle software application;

[0095] Generate a signed serialized data chunk of the set of application packages, wherein the signed serialized data chunk is configured to be used by a vehicle application deployment planner of the vehicle to reconstruct the set of application packages; and

[0096] Send the deployment plan and the signed serialized data chunk to the vehicle, wherein the deployment plan includes instructions that, when executed, cause the vehicle application deployment planner to:

[0097] Generate an execution plan for implementing the distributed vehicle software application at the vehicle based on the deployment plan; and

[0098] After determining that the application package is fully rebuilt, immediately implement the execution plan to implement the distributed vehicle software application at the vehicle according to the deployment plan.

[0099] Clause 2. The system according to clause 1, wherein the vehicle software deployment management system is further configured to:

[0100] Before generating the deployment plan for the set of application packages, receive a deployment instruction from a client, the deployment instruction including one or more indications of application packages to be included in the set of application packages; and

[0101] Retrieve the set of application packages indicated by the client to the vehicle deployment software management system from one or more application package registries accessible by the vehicle software deployment management system.

[0102] Clause 3. The system according to clause 1 or clause 2, wherein the deployment plan for the distributed vehicle software application includes the following for implementing the distributed vehicle software application at the vehicle:

[0103] One or more indications of deployment dependencies between corresponding application packages in the set of application packages; or

[0104] Conditional rules for deploying the corresponding application packages in the set of application packages.

[0105] Clause 4. The system according to any one of clauses 1 to 3, wherein the corresponding application packages in the set of application packages are formatted according to the Open Container Initiative (OCI) format.

[0106] Clause 5. A method, comprising:

[0107] Generate a deployment plan for a set of application packages to be used when implementing a vehicle software application via a vehicle software management system;

[0108] Generate data chunks of the set of application packages, wherein the data chunks are configured to be used by a vehicle application deployment planner of a vehicle to rebuild the set of application packages; and

[0109] Send the deployment plan and the data chunks to the vehicle, wherein the deployment plan includes instructions that, when executed, cause the vehicle application deployment planner to:

[0110] Generate an execution plan for implementing the vehicle software application at the vehicle based on the deployment plan; and

[0111] After determining that the application package set has been completely rebuilt, the execution plan is immediately implemented to implement the vehicle software application at the vehicle according to the deployment plan.

[0112] Clause 6. The method according to clause 5, further comprising:

[0113] Before generating the deployment plan for the application package set, receive a deployment instruction from a client, the deployment instruction including one or more indications of application packages to be included in the application package set.

[0114] Clause 7. The method according to clause 6, further comprising:

[0115] Retrieve the application package set indicated by the client from one or more application package storage locations accessible by the vehicle software management system.

[0116] Clause 8. The method according to clause 7, further comprising:

[0117] Receive one or more client-provided custom application packages from a client of the vehicle software management system; and

[0118] Store the one or more client-provided custom application packages in the one or more container storage locations,

[0119] where at least a portion of the application package set retrieved for deployment includes the one or more client-provided custom application packages.

[0120] Clause 9. The method according to any one of clauses 5 to 8, wherein the deployment plan for the vehicle software application includes the following for implementing the vehicle software application at the vehicle:

[0121] One or more indications of deployment dependencies between corresponding application packages in the application package set; or

[0122] Condition rules for deploying the corresponding application packages in the application package set.

[0123] Clause 10. The method according to any one of clauses 5 to 9, wherein the application packages in the application package set are formatted according to the Open Container Initiative (OCI) format.

[0124] Clause 11. The method according to any one of clauses 5 to 10, wherein the deployment plan and the data chunks sent to the vehicle are sent using a protocol-agnostic transport format that is compatible with multiple different transport protocols for communication between a given remote server and a given vehicle.

[0125] Clause 12. The method according to Clause 11, wherein the plurality of different transport protocols compatible with the protocol-agnostic format at least includes:

[0126] Message Queuing Telemetry Transport (MQTT) protocol.

[0127] Clause 13. One or more non-transitory computer-readable storage media storing program instructions that, when executed on one or more processors or across one or more processors, cause the one or more processors to perform the following operations:

[0128] Receive from a vehicle software deployment management system:

[0129] A deployment plan for implementing a vehicle software application at a vehicle; and

[0130] A data chunk representing a set of application packages to be used to implement the vehicle software application at the vehicle, wherein the data chunk is configured to be used at the vehicle to reconstruct the set of application packages;

[0131] Generate, via a vehicle application deployer, an execution plan for implementing the vehicle software application at the vehicle based on the received deployment plan;

[0132] Reconstruct the application packages of the vehicle software application at the vehicle using the data chunk; and

[0133] After determining that the application packages of the vehicle software application are fully reconstructed, implement the execution plan to implement the vehicle software application at the vehicle according to the deployment plan.

[0134] Clause 14. The one or more non-transitory computer-readable storage media according to Clause 13, wherein implementing the execution plan includes:

[0135] Based on the deployment plan, determine a corresponding electronic control unit (ECU) among a plurality of ECUs of the vehicle, the corresponding ECU to be used to execute code included in a corresponding application package of the set of application packages; and transmit the corresponding application package to the corresponding ECU.

[0136] Clause 15. The one or more non-transitory computer-readable storage media according to Clause 14, wherein the corresponding application package is transmitted to the corresponding ECU via a plurality of different in-vehicle communication protocols, the plurality of different in-vehicle communication protocols including two or more of the following:

[0137] Controller Area Network (CAN) protocol;

[0138] Remote Procedure Call (RPC) protocol;

[0139] Controller Area Network Flexible Data Rate (CAN FD) protocol;

[0140] Low-speed CAN protocol;

[0141] High-speed CAN protocol;

[0142] Society of Automotive Engineers (SAE) J1939 protocol;

[0143] CANopen protocol; or

[0144] On-board diagnostics (OBD) protocol.

[0145] Clause 16. One or more non-transitory computer-readable storage media according to clause 14 or clause 15, wherein transmitting the corresponding application package to the corresponding ECU includes sequentially transmitting the corresponding application package to the corresponding ECU according to a deployment sequence defined in the deployment plan.

[0146] Clause 17. One or more non-transitory computer-readable storage media according to any one of clauses 13 to 16, wherein the program instructions, when executed, cause the one or more processors to further perform the following operations:

[0147] Generating, by the vehicle application deployment planner, a corresponding local ECU execution plan for deploying the corresponding application package in the corresponding ECU of the ECUs at the corresponding ECU of the ECUs, wherein the local ECU execution plan is generated at least in part based on metadata describing the corresponding execution environment of the corresponding ECU of the ECUs; and

[0148] Sending the corresponding local ECU execution plan to the corresponding ECU of the ECUs.

[0149] Clause 18. One or more non-transitory computer-readable storage media according to any one of clauses 13 to 17, wherein the deployment plan includes conditional rules for the deployment of the set of application packages, and the conditional rules include one or more of the following:

[0150] A conditional rule including an opportunistic deployment location for a given application package to be used in response to a deployment failure of the given application package or another application package in an ECU of a plurality of electronic control units (ECUs) of the vehicle;

[0151] A conditional rule including an opportunistic deployment location for a given application package to be used in response to a successful deployment of another application package in the ECU of the plurality of ECUs; or

[0152] A conditional rule for selecting a deployment location of a given application package based on corresponding states, characteristics, and / or configurations of corresponding ECUs in the ECU of the vehicle.

[0153] Clause 19. One or more non-transitory computer-readable storage media according to any one of Clauses 13 to 18, wherein the received deployment plan and the received data chunks are transmitted to the vehicle application deployment planner using protocol-agnostic packet chunk transmission, and wherein the protocol-agnostic packet chunk transmission is compatible with multiple different server-to-vehicle transmission protocols.

[0154] Clause 20. One or more non-transitory computer-readable storage media according to Clause 19, wherein the multiple different transmission protocols compatible with the protocol-agnostic format at least include:

[0155] Message Queuing Telemetry Transport (MQTT) protocol.

[0156] Clause 21. A system comprising:

[0157] One or more computing devices configured to implement a dynamic vehicle software deployment planner, the dynamic vehicle software deployment planner being configured to:

[0158] Receive a vehicle data stream from a vehicle in a vehicle fleet, the vehicle data stream including updates indicating an electronic control unit (ECU) configuration of the vehicle and diagnostic data of the vehicle or a system of the vehicle;

[0159] Generate a deployment plan for deploying a distributed vehicle software application on the vehicle, wherein the deployment plan is generated at least in part based on the ECU configuration of the vehicle and the diagnostic data indicated in the stream; and

[0160] Send the deployment plan based on a request received by the dynamic vehicle software deployment planner,

[0161] wherein the generated deployment plan includes instructions that, when executed, cause an in-vehicle application deployment planner of the vehicle to:

[0162] Relay a local execution plan for deploying components of the distributed vehicle software application based on the deployment plan; and

[0163] Implement the local execution plan to deploy the components of the distributed vehicle software application on the vehicle.

[0164] Clause 22. The system according to Clause 21, wherein the generated deployment plan includes instructions that, when executed, further cause the in-vehicle application deployment planner to:

[0165] Redeploying another deployed component of another distributed vehicle software application from an initial ECU among the plurality of ECUs of the vehicle to another ECU among the plurality of ECUs of the vehicle based on the generated deployment plan.

[0166] Clause 23. The system according to clause 21 or clause 22, wherein the dynamic vehicle software deployment planner is further configured to:

[0167] Dynamically generate an updated deployment plan for the distributed vehicle software application based on the vehicle data flow; and

[0168] Send the dynamically generated updated deployment plan to the vehicle, wherein the dynamically generated deployment plan includes instructions that, when executed, cause the in-vehicle application deployment planner of the vehicle to:

[0169] Deploy components of the distributed vehicle software application to one or more ECUs of the vehicle in the configuration indicated in the deployment plan, the deployment plan being generated in consideration of the current ECU configuration and current diagnostic data of the vehicle indicated in the flow.

[0170] Clause 24. The system according to clause 23, wherein the dynamic vehicle software deployment planner is further configured to:

[0171] Determine whether one or more conditions of the vehicle related to the deployment of the distributed vehicle software have changed by more than a threshold amount based on the ECU configuration of the vehicle and the diagnostic data of the vehicle indicated in the flow;

[0172] In response to the one or more conditions having changed by more than the threshold amount:

[0173] Execute the dynamic generation of the updated deployment plan and the sending of the updated deployment plan; and

[0174] In response to the one or more conditions not having changed by more than the threshold amount:

[0175] Prevent the dynamic generation of the updated deployment plan and the sending of the updated deployment plan from being executed.

[0176] Clause 25. The system according to any one of clauses 21 to 24, wherein the deployment plan is configured to interface with an in-vehicle orchestrator of the vehicle, and wherein the in-vehicle orchestrator employs a deployment adapter framework that is configured to interface with multiple different runtime architectures of the plurality of ECUs of the vehicle.

[0177] Clause 26. A method, comprising:

[0178] Receiving a vehicle data stream via a vehicle software deployment planner, the vehicle data stream including updates indicating an electronic control unit (ECU) configuration of the vehicle and diagnostic data of the vehicle; and

[0179] Sending a deployment plan for the vehicle software application based on a request to deploy the vehicle software application to the vehicle, wherein the deployment plan is generated based on the ECU configuration and the diagnostic data indicated in the stream,

[0180] wherein the deployment plan includes instructions which, when executed, cause an in-vehicle application deployment planner of the vehicle to:

[0181] Implement a local execution plan for deploying the vehicle software application at the vehicle based on the deployment plan.

[0182] Clause 27. The method according to clause 26, wherein the deployment plan includes instructions which, when executed, further cause the in-vehicle application deployment planner to:

[0183] Redeploy another deployed component of another vehicle software application from an initial ECU among a plurality of ECUs of the vehicle to another ECU among the plurality of ECUs of the vehicle based on the deployment plan.

[0184] Clause 28. The method according to clause 26 or clause 27, further comprising:

[0185] Dynamically generating the deployment plan for the vehicle software application based on the ECU configuration and / or the diagnostic data indicated in the stream; and

[0186] Sending the dynamically generated deployment plan to the vehicle, wherein the dynamically generated deployment plan includes instructions which, when executed, cause the in-vehicle application deployment planner of the vehicle to:

[0187] Remove another vehicle software application previously deployed to the vehicle; and

[0188] Deploy the vehicle software application to one or more ECUs of the vehicle according to the dynamically generated deployment plan.

[0189] Clause 29. The method according to any one of clauses 26 to 28, wherein the vehicle further includes a plurality of ECUs, and wherein generating the deployment plan includes:

[0190] Determining different runtime architectures of the plurality of ECUs,

[0191] Wherein the deployment plan is configured such that an in-vehicle orchestrator of the vehicle can interface with different runtime architectures of the plurality of ECUs by adopting a deployment adapter framework.

[0192] Clause 30. The method according to Clause 29, wherein at least one of the different runtime architectures of the plurality of ECUs is an Open Container Initiative (OCI) framework architecture, and wherein the vehicle software application includes one or more container images formatted according to the OCI format.

[0193] Clause 31. The method according to Clause 26, wherein the dynamically generating the deployment plan is performed by a cloud-based dynamic vehicle software deployment planner, and the method further includes:

[0194] Training one or more machine learning (ML) models used by the dynamic vehicle software deployment planner based on the received stream, wherein the deployment plan of the vehicle software application is dynamically generated at least in part based on ML inferences generated from the one or more ML models.

[0195] Clause 32. The method according to Clause 31, wherein the training the one or more ML models includes:

[0196] Training the one or more ML models based on current and historical updates to the ECU configuration of the vehicle and current and historical diagnostic data of the vehicle, wherein the deployment plan of the vehicle software application is generated at least in part based on ML inferences generated from the current and historical updates and the current and historical diagnostic data.

[0197] Clause 33. The method according to Clause 31, wherein the training the one or more ML models includes:

[0198] Training the one or more ML models based on ECU configurations of a plurality of vehicles in a fleet and diagnostic data of the plurality of vehicles indicated in the stream, wherein the deployment plan of the vehicle software application is generated at least in part based on ML inferences generated considering the ECU configurations and the diagnostic data of the plurality of vehicles from the fleet.

[0199] Clause 34. The method according to any one of Clauses 26 to 33, further including:

[0200] Generating a virtual copy of the vehicle based on the ECU configuration and diagnostic data of the stream; and

[0201] Using the virtual copy to test the deployment of the vehicle software application based on the deployment plan.

[0202] Clause 35. The method according to any one of Clauses 26 to 34 further comprises:

[0203] Based on the ECU configuration and diagnostic data of the stream, for a plurality of vehicle software applications in a vehicle application store, determining one or more feasible vehicle software applications that can be deployed in the vehicle, wherein the vehicle software application to be deployed is selected from the one or more feasible vehicle software applications for deployment.

[0204] Clause 36. The method according to Clause 26 further comprises:

[0205] Based on the ECU configuration and diagnostic data of the stream, determining one or more feasible deployment options for the vehicle software application, wherein the one or more feasible deployment options include options for changing one or more of the following:

[0206] The arrangement of vehicle software deployed in the vehicle,

[0207] The set of vehicle software deployed in the vehicle, or

[0208] The specifications of vehicle hardware components.

[0209] Clause 37. One or more non-transitory computer-readable storage media storing program instructions that, when executed on one or more processors or across one or more processors, cause the one or more processors to implement a dynamic vehicle software deployment planner that implements the following operations:

[0210] Sending a vehicle data stream from vehicles in a vehicle fleet to the dynamic vehicle software deployment planner, the vehicle data stream indicating the electronic control unit (ECU) configuration of the vehicles in the fleet and indicating the diagnostic data of the vehicles in the fleet;

[0211] Receiving a deployment plan for a distributed vehicle software application that has been dynamically generated by a cloud-based dynamic vehicle software deployment planner based on the indications of the stream;

[0212] Via the in-vehicle application deployment planner of the vehicle, implementing a local execution plan based on the deployment plan to install the distributed vehicle software application on the vehicle.

[0213] Clause 38. The one or more non-transitory computer-readable storage media according to Clause 37, wherein the program instructions, when executed, cause the one or more processors to further implement the following operations:

[0214] After determining that the connection to the cloud-based dynamic vehicle software deployment planner is unavailable, an alternative local execution plan is generated that prioritizes the availability of safety-critical applications over non-safety-critical applications.

[0215] Clause 39. One or more non-transitory computer-readable storage media according to Clause 37 or Clause 38, wherein the vehicle further includes a plurality of ECUs, and an in-vehicle orchestrator of the vehicle employs a deployment adapter framework to interface with different runtime architectures of the plurality of ECUs.

[0216] Clause 40. One or more non-transitory computer-readable storage media according to any one of Clauses 37 to 39, wherein the program instructions, when executed, cause the one or more processors to further perform the following operations:

[0217] Receive different deployment plans, wherein the different deployment plans include instructions to deploy another distributed vehicle software application in different deployment configurations;

[0218] Remove the previously deployed vehicle software application; and

[0219] Deploy the another vehicle software application to one or more ECUs of the vehicle based on the different deployment plans.

[0220] The various methods shown and described herein represent illustrative embodiments of the methods. The methods may be implemented manually, in software, in hardware, or in combination thereof. The order of any method may be changed, and various elements may be added, reordered, combined, omitted, modified, etc. For example, in one embodiment, the method may be implemented by a computer system that includes 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 functionality described herein (e.g., the functionality of data transfer tools, various services, databases, devices, and / or other communication devices, etc.).

[0221] Various modifications and changes can be made, which will be obvious to those skilled in the art who benefit from the present disclosure. It is intended to cover all such modifications and changes, so the above description should be regarded as illustrative rather than restrictive.

[0222] Each embodiment may further include receiving, sending, or storing instructions and / or data implemented in accordance with the foregoing description on a computer-accessible medium. Generally, a computer-accessible medium may include a storage medium or a memory medium, such as a magnetic medium or an optical medium, such as a disk or a DVD / CD-ROM; a volatile or non-volatile medium, such as RAM (e.g., SDRAM, DDR, RDRAM, SRAM, etc.), ROM, etc.; and a transmission medium or signal, such as an electrical, electromagnetic, or digital signal, transmitted via a communication medium, such as a network and / or a wireless link.

Claims

1. A system, comprising: one or more computing devices configured to implement a vehicle software deployment management system, the vehicle software deployment management system being configured to: generate a deployment plan for a set of application packages to be used when implementing a vehicle software application; generate data chunks of the set of application packages, wherein the data chunks are configured to be used by a vehicle application deployment planner of the vehicle to reconstruct the set of application packages; and send the deployment plan and the data chunks to the vehicle, wherein the deployment plan includes instructions that, when executed, cause the vehicle application deployment planner to: generate an execution plan for implementing the vehicle software application at the vehicle based on the deployment plan; and upon determining that the application packages are fully reconstructed, implement the execution plan to implement the vehicle software application at the vehicle according to the deployment plan.

2. The system according to claim 1, wherein the vehicle software deployment management system is further configured to: receive, prior to generating the deployment plan for the set of application packages, a deployment instruction from a client, the deployment instruction including one or more indications of application packages to be included in the set of application packages; and retrieve the set of application packages indicated by the client to the vehicle deployment software management system from one or more application package registries accessible by the vehicle software deployment management system.

3. The system according to claim 1 or claim 2, wherein the deployment plan for the vehicle software application includes one or more of the following for implementing the vehicle software application at the vehicle: one or more indications of deployment dependencies between corresponding application packages in the set of application packages; or conditional rules for deploying the corresponding application packages in the set of application packages.

4. A method, comprising: generating, via a vehicle software management system, a deployment plan for a set of application packages to be used when implementing a vehicle software application; generating data chunks of the set of application packages, wherein the data chunks are configured to be used by a vehicle application deployment planner of the vehicle to reconstruct the set of application packages; and sending the deployment plan and the data chunks to the vehicle, wherein the deployment plan includes instructions that, when executed, cause the vehicle application deployment planner to: generate an execution plan for implementing the vehicle software application at the vehicle based on the deployment plan; and upon determining that the set of application packages is fully reconstructed, implement the execution plan to implement the vehicle software application at the vehicle according to the deployment plan.

5. The method according to claim 4, further comprising: receiving, prior to generating the deployment plan for the set of application packages, a deployment instruction from a client, the deployment instruction including one or more indications of application packages to be included in the set of application packages.

6. The method according to claim 5, further comprising: retrieving the set of application packages indicated by the client from one or more application package storage locations accessible by the vehicle software management system.

7. The method according to claim 6, further comprising: Receiving, from a client of the vehicle software management system, one or more client-provided customized application packages; And Storing the one or more client-provided customized application packages in the one or more container storage locations, Where at least a portion of the set of application packages retrieved for deployment includes the one or more client-provided customized application packages.

8. The method according to any one of claims 4 to 7, wherein the deployment plan and the data chunks sent to the vehicle are sent using a protocol-agnostic transport format that is compatible with multiple different transport protocols for communication between a given remote server and a given vehicle.

9. The method according to claim 8, wherein the multiple different transport protocols compatible with the protocol-agnostic format at least include: Message Queuing Telemetry Transport (MQTT) protocol.

10. The method according to claim 4, further comprising: Receiving, at the vehicle: The deployment plan for implementing the vehicle software application at the vehicle; And The data chunks representing the set of application packages to be used for implementing the vehicle software application at the vehicle, wherein the data chunks are configured to be used at the vehicle to reconstruct the set of application packages; Generating, at the vehicle via a vehicle application deployment planner, an execution plan for implementing the vehicle software application at the vehicle based on the received deployment plan; Reconstructing, at the vehicle, the application packages of the vehicle software application using the data chunks; And After determining that the application packages of the vehicle software application are completely reconstructed, immediately implementing the execution plan to implement the vehicle software application at the vehicle according to the deployment plan.

11. The method according to claim 10, further comprising: Based on the deployment plan, determining a corresponding electronic control unit (ECU) among a plurality of ECUs of the vehicle, the corresponding ECU to be used to execute code included in a corresponding application package in the set of application packages; And Transmitting the corresponding application package to the corresponding corresponding ECU.

12. The method according to claim 11, wherein the corresponding application package is transmitted to the corresponding corresponding ECU via multiple different in-vehicle communication protocols, the multiple different in-vehicle communication protocols including two or more of the following: 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; or On-Board Diagnostic (OBD) protocol.

13. The method according to claim 11, wherein the transmitting the corresponding application package to the corresponding corresponding ECU includes sequentially transmitting the corresponding application package to the corresponding ECU according to a deployment sequence defined in the deployment plan.

14. The method according to any one of claims 10 to 13, further comprising: The vehicle application deployment planner generates a corresponding local ECU execution plan for a corresponding ECU in the ECU for deploying a corresponding application package in the application packages at the corresponding ECU in the ECU, wherein the local ECU execution plan is generated at least in part based on metadata describing the corresponding execution environment of the corresponding ECU in the ECU; and sending the corresponding local ECU execution plan to the corresponding ECU in the ECU.

15. The method according to claim 10, wherein the deployment plan includes conditional rules for the deployment of the set of application packages, wherein the conditional rules include one or more of the following: A conditional rule including an opportunistic deployment location for a given application package to be used in response to a deployment failure of the given application package or another application package in an ECU among a plurality of electronic control units (ECUs) of the vehicle; A conditional rule including an opportunistic deployment location for a given application package to be used in response to a successful deployment of another application package in the ECU among the plurality of ECUs; or A conditional rule for selecting a deployment location for a given application package based on the corresponding status, characteristics, and / or configuration of the corresponding ECU in the ECU of the vehicle.

Images