System, method, and apparatus to implement multi-modal OTA updates for a vehicle

Abstract

A device may include an update manager configured to implement a vehicle update interface, and to prepare an update package in response to user interactions with the vehicle update interface. A device may include a deployment manager configured to determine at least one target vehicle, and to determine a deployment approval in response to user interactions with the vehicle update interface. A device may include a package manager configured to communicate the update package to the at least one target vehicle in response to the deployment approval; and wherein the deployment manager is further configured to confirm a deployment of the update package in response to a confirmation communication from the at least one target vehicle.

Description

SYSTEM, METHOD, AND APPARATUS TO IMPLEMENT MULTI-MODAL OTA UPDATES FOR A VEHICLECROSS REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims the benefit of U.S. Provisional Application Serial No. 63 / 619,269, filed 9 JAN 2024, entitled “SYSTEM, METHOD, AND APPARATUS TO IMPLEMENT MULTI-MODAL OTA UPDATES FOR A VEHICLE” (SONA-0019-P01).

[0002] The foregoing application is incorporated herein by reference in the entirety for all purposes. BACKGROUND

[0003] Previously known systems for updating vehicle controls, applications, features, controller firmware, and the like, suffer from a number of challenges. Among other challenges, updates to these aspects of vehicles, generally called over-the-air updates, or OTA updates, are disruptive to vehicle operations, often requiring a shutdown of the vehicle, significant enforced downtime, and validation operations for the update. Further, different types of updates utilize different solutions, with management for compatibility, testing, and certification of updates to the vehicle controls managed indirectly off- vehicle, with previously known systems reliant on the proper updates to the vehicle being managed by manually ensuring the correct updates to the correct vehicles. SUMMARY

[0004] In some aspects, the techniques described herein relate to a cloud system, including: an update manager configured to implement a vehicle update interface, and to prepare an update package in response to user interactions with the vehicle update interface; a deployment manager configured to determine at least one target vehicle, and to determine a deployment approval in response to user interactions with the vehicle update interface; a package manager configured to communicate the update package to the at least one target vehicle in response to the deployment approval; and wherein the deployment manager is further configured to confirm a deployment of the update package in response to a confirmation communication from the at least one target vehicle.

[0005] In some aspects, the techniques described herein relate to a cloud system, further including: a campaign manager configured to determine a group of vehicles in response to user interactions with the vehicle update interface; wherein the deployment manager is further configured to determine a plurality of target vehicles in response to the determined group of vehicles; and wherein the package manager is further configured to communicate the update package to the plurality of target vehicles in response to the deployment approval.

[0006] In some aspects, the techniques described herein relate to a cloud system, further including: a configuration validator configured to confirm a validity of a configuration of the plurality of target vehicles in response to the update package and a configuration description for each of the plurality oftarget vehicles: and wherein the deployment manager is further configured to determine the deployment approval in response to the confirmed validity of the configuration of the plurality of target vehicles.

[0007] In some aspects, the techniques described herein relate to a cloud system, wherein the configuration validator is further configured to determine an incompatibility value in response to determining that at least one of the plurality of target vehicles does not have a valid configuration for the update package, and to provide an invalidity communication in response to the determining that at least one of the plurality of target vehicles does not have the valid configuration.

[0008] In some aspects, the techniques described herein relate to a cloud system, wherein the configuration validator is further configured to provide the invalidity communication to the campaign manager in response to the incompatibility value.

[0009] In some aspects, the techniques described herein relate to a cloud system, wherein the invalidity communication includes at least one of: a list of vehicles that do not have a valid configuration; a description of incompatible aspects of the configuration for at least one vehicle of a list of vehicles that do not have a valid configuration; or a description of incompatible aspects of the update package for at least one vehicle of a list of vehicles that do not have a valid configuration.

[0010] In some aspects, the techniques described herein relate to a cloud system, wherein the invalidity communication includes at least one of: a description of incompatible aspects of the configuration for at least one vehicle of a list of vehicles that do not have a valid configuration; or a description of incompatible aspects of the update package for at least one vehicle of a list of vehicles that do not have a valid configuration.

[0011] In some aspects, the techniques described herein relate to a cloud system, wherein the deployment manager is further configured to provide a modified update package recommendation and at least one alternative target vehicle in response to the invalidity communication.

[0012] In some aspects, the techniques described herein relate to a cloud system, further including: wherein the campaign manager is further configured to receive update status information from the plurality of target vehicles; and provide a campaign status display to the vehicle update interface in response to the update status information.

[0013] In some aspects, the techniques described herein relate to a cloud system, wherein the campaign status display includes at least one of: a list of at least a portion of the group of vehicles; a status indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles; or an issue indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles.

[0014] In some aspects, the techniques described herein relate to a cloud system, wherein the campaign status display includes a rollout dashboard corresponding to the deployment of the update package to the plurality of target vehicles.

[0015] In some aspects, the techniques described herein relate to a cloud system, wherein the rollout dashboard includes at least one of: a pending progress indicating offline vehicles of the plurality of target vehicles: a sending progress indicating ongoing ones of the communicating the update package to the plurality of target vehicles; a deploying progress indicating a status of installation of the update package on the plurality of target vehicles; or a completion progress indicating a status of application of the update package on the plurality of target vehicles.

[0016] In some aspects, the techniques described herein relate to a cloud system, further including: wherein the campaign status display includes a list of at least a portion of the group of vehicles, and a status indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles.

[0017] In some aspects, the techniques described herein relate to a cloud system, further including: wherein the campaign manager updates the campaign status display with a granular deployment view in response to a selection by the user of a vehicle from the list of at least a portion of the group of vehicles.

[0018] In some aspects, the techniques described herein relate to a cloud system, wherein the granular deployment view depicts installation operations and updated devices on the selected vehicle.

[0019] In some aspects, the techniques described herein relate to a cloud system, wherein the update package includes at least one of: a firmware value for an electronic controller; a data value for an electronic controller; a configuration value for an electronic controller; a native application update for an electronic controller; a containerized application update for the vehicle; a software configuration for an electronic controller; a policy value for the vehicle; or an automation description for the vehicle.

[0020] In some aspects, the techniques described herein relate to a cloud system, wherein the update package includes at least two of: a native application update for an electronic controller; a containerized application update for the vehicle; a policy value for the vehicle; and an automation description for the vehicle.

[0021] In some aspects, the techniques described herein relate to a cloud system, wherein the update package includes all of the following: a firmware value for a first electronic controller; a data value for one of the first electronic controller or a second electronic controller; and a policy value for the vehicle.

[0022] In some aspects, the techniques described herein relate to a cloud system, wherein the update package further includes a native application update for an electronic controller.

[0023] In some aspects, the techniques described herein relate to a system, including: a vehicle having a plurality of hierarchically arranged update controllers, the update controllers including: a primary controller configured to receive an update package including an update payload for at least one controller of the vehicle, and to communicate at least a portion of the update payload to a secondary controller; the secondary controller configured to receive the at least a portion of the update payload, and to parse the at least a portion of the update payload into a child update payload, and to communicate the child update payload to a tertiary' controller; wherein the tertiary' controller is configured to apply the child update payload, and to provide a tertiary confirmation of the applied child update payload to the secondary controller; wherein the secondary controller is further configured to compile a secondary confirmation including the tertiary confirmation, and to communicate the secondary confirmation to the primary controller; wherein the primary controller is further configured to compile a vehicle confirmation including the secondary confirmation, and to communicate the vehicle confirmation to a cloud update platform.

[0024] In some aspects, the techniques described herein relate to a system, further including: wherein each of the primary controller, secondary controller, and tertiary controller are further configured to control updates to direct responsibility' devices; wherein the tertiary controller is configured to compile direct responsibility device updates into the tertiary confirmation; wherein the secondary controller is configured to compile direct responsibility device updates into the secondary confirmation; and wherein the primary controller is configured to compile direct responsibility device updates into the vehicle confirmation.

[0025] In some aspects, the techniques described herein relate to a system, further including an update client communicatively interposed between the primary controller and the cloud update platform.

[0026] In some aspects, the techniques described herein relate to a system, wherein the update client is further configured to validate the update package, and to communicate the update package to the primary controller in response to validating the update package.

[0027] In some aspects, the techniques described herein relate to a system, wherein the update client is further configured to provide the vehicle confirmation as an issue indicator in response to the update package failing to validate.

[0028] In some aspects, the techniques described herein relate to a system, wherein the update client is further configured to provide a validated portion of the update package to the primary controller.

[0029] In some aspects, the techniques described herein relate to a system, wherein the validated portion includes an independent portion of the update package.

[0030] In some aspects, the techniques described herein relate to a system, wherein the primary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

[0031] In some aspects, the techniques described herein relate to a system, wherein the secondary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

[0032] In some aspects, the techniques described herein relate to a system, wherein the tertiary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

[0033] In some aspects, the techniques described herein relate to a system, including: a vehicle including an update manager, a container manager, and a vehicle data collector; wherein the update manager is configured to receive an update package including an update to a containerized application on the vehicle; wherein the container manager is configured to validate and apply the update to the containerized application on the vehicle, and to provide a vehicle confirmation to the vehicle data collector; and wherein the vehicle data collector is configured to provide the vehicle confirmation to a cloud update platform.

[0034] In some aspects, the techniques described herein relate to a system, wherein the container manager is configured to provide an issue indicator to the vehicle data collector in response to the update to the containerized application on the vehicle failing to validate.BRIEF DESCRIPTION OF THE RELATED FIGURES

[0035] Fig. 1 depicts an example system for multi-modal OTA updates for a vehicle.

[0036] Fig. 2 depicts an example system for multi-modal OTA updates for a vehicle.

[0037] Fig. 3 depicts an example secondary controller for use in a multi-modal OTA update system.

[0038] Fig. 4 depicts an example system for multi-modal OTA updates for a vehicle.

[0039] Fig. 5 depicts an example system for multi-modal OTA updates for containerized applications for a vehicle.

[0040] Fig. 6 depicts an example system for multi-modal OTA updates for a vehicle.

[0041] Fig. 7 depicts an example vehicle update interface, with an interface for adding new assets for vehicle configuration.

[0042] Fig. 8 depicts an example vehicle update interface, with an interface for adding new assets for vehicle configuration.

[0043] Fig. 9 depicts an example vehicle update interface, with an interface for confirming a vehicle configuration.

[0044] Fig. 10 depicts an example vehicle update interface, with an interface for preparing an update package.

[0045] Fig. 11 depicts an example vehicle update interface, with an interface for preparing a deployment.

[0046] Fig. 12 schematically depicts an example vehicle update interface, with an interface for preparing a deployment.

[0047] Fig. 13 depicts an example vehicle update interface, with an interface for preparing a deployment.

[0048] Fig. 14 schematically depicts an example vehicle update interface, with an interface for preparing a deployment.

[0049] Fig. 15 depicts an example vehicle update interface, with a campaign status display.

[0050] Fig. 16 schematically depicts an example vehicle update interface, with a campaign status display.

[0051] Fig. 17 depicts an example vehicle update interface.

[0052] Fig. 18 schematically depicts an example vehicle update interface.

[0053] Fig. 19 depicts an example vehicle update interface, with a rollout dashboard.

[0054] Fig. 20 schematically depicts an example vehicle update interface, with a rollout dashboard.

[0055] Fig. 21 depicts an example vehicle update interface, with a campaign status display.

[0056] Fig. 22 schematically depicts an example vehicle update interface, with a campaign status display.

[0057] Fig. 23 depicts an example vehicle update interface, with a granular deployment view.

[0058] Fig. 24 schematically depicts an example vehicle update interface, with a granular deployment view.DETAILED DESCRIPTION

[0059] Embodiments herein provide one or more of a number of improvements to address these and other challenges with previously known systems. Embodiments herein provide for a reduced cost and rollout learning curve to install updates on a vehicle, by utilizing a single solution capable of performing any type of update. For example, a system may have updates related to firmware (e.g., baseline executable instructions operating on controller(s) of the vehicle), useful data parameters (e.g., generally calibrations or trims, including values that the baseline executable instructions utilize to perform features, but that changing these values does not represent a fundamental change to theexecuting operations, firmware, or software of the vehicle), or configurations of the vehicle (e.g., parameters or data that are used to control certain operations of the vehicle, such as how data is collected, data utilized to implement certain automated features, or the like, which are generally not available in previously known systems). In certain embodiments herein, adjustments to the configuration are capable to perform significant adjustments in the operations of the vehicle, for example in managing network communications and security, providing appropriate communications for new, updated, or moved hardware devices, adjustment of operational, communicative, and / or available storage for applications or flows on the vehicle, or the like. An example embodiment utilizes configurable aspects of the vehicle to provide for the ability to update and configure capabilities of the vehicle without requiring an update to the main executing instructions (or firmware) of controllers, providing for the capability to adjust network management functions, data collection functions, automated vehicle functions, diagnostic functions, and / or shared storage functions of the vehicle. In certain embodiments, a framework is applied that allows for fully configured features to be implemented through configuration changes that can be implemented with a configuration change, for example by communicating a configuration file to the vehicle. In a further embodiment, the ability of any end point on any network of the vehicle to communicate seamlessly with any other end point on any network of the vehicle allows for the creation of high capability features utilizing a configuration file. Another example embodiment utilizes containerized applications that allow for high capability features to be implemented on the vehicle, which may be installed on any controller of the vehicle with the ability to gather any data and / or implement any actuator on the vehicle, subject to permissions applied - which may be applied as a part of the configuration file. In certain embodiments, updating of the configuration file may be implemented by providing a policy to the vehicle, which is validated and implemented by a policy manager positioned on a controller of the vehicle, and / or distributed between controllers of the vehicle. Another example embodiment includes a local controller on the vehicle configured to enforce dependencies among configurations, applications, calibrations or trims, and / or firmware. Another example embodiment provides the framework for feature additions to the vehicle, for example allowing features on the vehicle to be added, upgraded, or configured, by communicating a simple and non-disruptive configuration file to the vehicle, opening up a number of possibilities for vehicle manufacturers or dealers to provide features for the vehicle that can be added without the vehicle being brought to a service location, and could even be added by the vehicle operator using an in- vehicle selection, mobile application, or web portal application set up by the dealer or manufacturer. Additionally or alternatively, embodiments herein provide for non-disruptive remote installation of updates for campaigns or recalls, to correct issues with the vehicle, that can be fully tracked andreadily confirmed. In a further embodiment, the campaign or recall can be implemented through a single action for a large number of vehicles, with vehicle-specific adjustments automatically managed by an on-vehicle controller such as a policy manager, data collection manager, vehicle automation manager, or the like.

[0060] Certain aspects of the present disclosure include adjusting the routing of communications on a network, whether between separate devices on the network, or between a device on the network and an external device. Certain aspects of the present disclosure include applying configurations and / or policies to controllers of the vehicle, facilitating communication between end points of the vehicle, including between end points on different networks or different network zones, and between end points that utilize distinct data formatting, data rates, communication protocols, or the like. Without limitation to any aspect of the present disclosure, some tools that can be utilized to tactically implement certain operations herein, in combination with the present disclosure, and descriptions that can enhance understanding of some of the terminology used herein (e.g., policy, end point, external device, network protocol, network type, etc.) can be found in one or more of the following U.S. Patents or Patent Applications: US application 17 / 027,167, filed 21 SEP 2020, and entitled SYSTEM, METHOD, AND APPARATUS TO SUPPORT MIXED NETWORKCOMMUNICATIONS ON A VEHICLE (SGNA-0006-U01); US application 17 / 027,187, filed 21 SEP 2020, and entitled SYSTEM, METHOD, AND APPARATUS TO EXTRA VEHICLE COMMUNICATIONS CONTROL (SONA-0007-U01); US application 17 / 195,589, filed 8 MAR 2021, and entitled SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION (SONA-0010-U01); US application 17 / 833,614, filed 6 JUN 2022, and entitled SYSTEM, METHOD, AND APPARATUS FOR MANAGING VEHICLE DATA COLLECTION (SONA-0012-U01); and / or US application 18 / 244,147, filed 8 SEP 2023, and entitled SYSTEM, METHOD, AND APPARATUS TO EXECUTE VEHICLE COMMUNICATIONS USING A ZONAL ARCHITECTURE (SONA-0015-U01), each of which is incorporated herein by reference in the entirety for all purposes.

[0061] Referencing Fig. 1 , an example architecture for an update system is schematically depicted. The example architecture includes a number of controllers on a vehicle, configured to at least intermittently communicate with an external device 102 (e.g., a service tool; WiFi connected tool; a mobile device; a tool communicatively coupled to a port such as a public or private data port, OBD port, or the like; a tool interfacing with I / O of a controller, for example a bench wherein a controller of the system is plugged into the bench and the bench is configured to emulate one or more aspects of the vehicle and / or controllers on the vehicle, and to support network communications with the controller, for example in embodiments where OTA operations are performed on one or morecontrollers of the vehicle, and / or a portion of the vehicle, such as during manufacturing, body building, uplifting, and / or service operations; a cloud device or server; a web portal; and / or a network connected device of any type, including over a LAN, WAN, VPN, or any other network based connection to the vehicle). The example includes a first high performance computing (HPC) controller 101 having an (HPC Primary 104) that performs direct communications with the external device 102 to receive and send OTA communications, updated policies, updated configurations, update packages, or the like. The example includes a number of secondary HPC devices (HPC Secondary 106, 108, 112), with three such devices in the example of Fig. 1 , that receive relevant portions of update operations as provided by an OTA controller on the HPC Primary 104. In the example architecture, each HPC device is responsible for execution of update operations on controllers within the scope of responsibility for that device, including executing update operations for lower capability devices such as CAN controllers 110, 116, vehicle control units 118 (VCUs - for example controllers operating on lower capability networks such as a LIN or other simplified communication protocol), and can be configured to perform any special update procedures for lower capability devices (e.g., voltage or communication sequences that may be utilized to put such devices into an update mode, bootloader mode, etc., which might be used in lieu of sophisticated update procedures that might be available for higher capability controllers; communication schemes to perform the actual update; and / or communication schemes to return the device to an operating mode; any one or more of these aspects, or any other aspects, may be present depending upon the control devices present on the vehicle). In the example of Fig. 1 , a tertiary HPC (HPC Tertiary 114) is present that is not directly connected to the HPC Primary 104. The HPC Tertiary 114 of Fig. 1 is a non-limiting example. In the example of Fig. 1, the HPC Tertiary 114 receives update communications from the next device up in the hierarchy, HPC Secondary 1 106, although in certain embodiments the HPC Tertiary 114 may receive update communications from any device, such as the HPC Primary 104 tunneling update communications directly to the HPC Tertiary 114 device. The various HPC devices may be on any network or network zone of the vehicle, with any network arrangement (e.g., bus, star, ring, etc.). The example of Fig. 1 depicts the logical communication arrangement for implementing OTA operations, but may not correspond to the physical communication arrangement present on the vehicle, and the physical communication arrangement is not limiting to the present disclosure.

[0062] Referencing Fig. 2, an example HPC Primary 104 controller includes an OTA controller 208, where the example OTA controller 208 receives and validates OTA requests from an external device 202, 204 (e.g., an upstream OTA controller on the cloud, a connected tool, etc.), that forwards the validated OTA request (or relevant portions thereof) to downstream OTA controllers (e.g., positionedon HPC Secondary controllers), drives updates to local components within the scope of responsibility of the HPC Primary 104 controller (e.g., local policy(ies) 212, A / B updater 214 (e.g., backup and active partitions), UDS components 216 (e.g., diagnostic components), and / or container(s) 218 (e.g., containerized local applications to the HPC Primary 104 controller), execute updates to other components within the scope of responsibility of the HPC Primary 104 controller (e.g., CAN controllers, VCUs, etc.), orchestrates the sequence of updating the local components, and reporting update status data to the external device or upstream OTA controller. In certain embodiments, the reporting is aggregated with reporting from the downstream controllers (e.g., OTA controllers on HPC Secondary controllers). The example of Fig. 2 depicts an OTA cloud controller 204 as the external device. The example of Fig. 2 further depicts a proximity tool 202, for example to determine communicative coupling options to the HPC Primary 104 controller, for example implementing updates based on required or desired connectivity options, for example to implement a large update when the vehicle is connected to a relevant WiFi connection, coupled to a tool, or the like. In the example of Fig. 2, the OTA client 206 operates as a bridge between the OTA controller 208 and the external device 202, 204, performing one or more operations such as: registering the vehicle (or controllers) and / or provisioning resources with the cloud; authenticating with the cloud (and / or authenticating cloud messages as legitimate); retrieving existing software versions (or configurations, etc.) from the OTA controller; sending messages and reports to the cloud; downloading new assets from the cloud (e.g., images, policies, configuration files, etc.); validating OTA update requests from the cloud; initiating update operations (e.g., with a call to the OTA controller); reporting OTA progress and / or status to the cloud; and / or retaining OTA update information (e.g., retaining persistent data for update operations that may extend across one or more shutdown / startup sequences). In certain embodiments, the OTA client 206 is communicatively interposed between the OTA controller 208 and a cloud server. In certain embodiments, the OTA controller 208 may be referenced as the HPC Primary 104 (e.g., where the OTA client 206 is positioned on the physical HPC Primary 104, and the OTA controller 208 is performing the control functions for update operations).

[0063] In certain embodiments, an OTA configuration (e.g., as OTA updateable component) is stored on each OTA controller 208, including information such as: the role of the OTA controller (e.g., Primary or Secondary, and / or identifying the upstream and / or downstream OTA controllers); access information of the OTA Client for the primary' HPC; access information for dow nstream HPCs; access information for the immediate upstream HPC; access information for CAN ECUs within the responsibility of the OTA controller; access information for CAN ECUs connected over IP; and / oraccess information for updating local components (e.g., local policy(ies), A / B updater (e.g., backup and active partitions), UDS components (e.g., diagnostic components), and / or container(s)).

[0064] Referencing Fig. 3, an example HPC Secondary 106 controller includes an OTA controller 308 that operates similarly to the OTA controller 208 on the HPC Primary 104 controller, but receives communications from, and provides communications to, the HPC Primary 104 controller as the upstream controller. In certain embodiments, an example system includes multiple layers of hierarchy within the OTA controller space, for example where an HPC Tertiary 114 controller includes an OTA controller. In certain embodiments, a lowest layer of the HPC controllers can perform without an OTA controller, where the second lowest layer of the HPC controllers is configured to execute update functions for the lowest layer of the system (e.g., as depicted in Fig. 1). In the example of Fig. 3, the HPC Secondary 106 controller drives updates to local components within the scope of responsibility of the HPC Secondary 106 controller (e.g., local policy(ies) 312, A / B updater 314 (e.g., backup and active partitions), UDS components 316 (e.g., diagnostic components), and / or container(s) 318 (e.g., containerized local applications to the HPC Secondary 106 controller).

[0065] Embodiments herein allow for vehicle updates using a single interface for the user directing the updates, and any or all of the features depicted can be updated in a single operation, or divided into separate operations according to the goals of the user directing the update. Example and nonlimiting features of the vehicle that can be updated by embodiments herein include: ECU firmware (e.g., firmware, or base software, for any controller within the vehicle): ECU data (e.g., collecting data, directing the collection or capture of data, and / or adjusting data collection parameters such as sampling frequency, data resolution, data formatting, units, etc.); ECU configuration (e.g., adjusting control operations within the scope of the ECU, for example data routing paths for the ECU, permissions for the ECU, network address and / or responses to an adjustment of the physical (e.g., movement to a different network zone) or logical (e.g., movement from one virtual network zone to another) location of the ECU; updates to a native application (e.g., an application stored and executed on a particular ECU); updates to a containerized application (e.g., an application that is stored and operated as a container on an ECU, typically but not limited to a dedicated ECU to support containerized applications, but it can be any containerized application on any ECU of the vehicle); a software configuration (e.g., the configuration of any ECU, a policy file, a data collection configuration, a network management configuration, a service oriented architecture configuration, etc.); and / or a policy and / or recipe (e.g., updating a policy, removing a policy, adding a new policy, and / or utilizing a recipe to create a new policy or policy update).

[0066] Embodiments herein allow for simultaneous updates to be performed, including a combination of updates to multiple features such as firmware values for electronic controllers, data values for electronic controllers (e.g., calibrations, trims, accumulation tracking values, identifiers, and / or any other non-volatile data values associated with an electronic controller), a configuration value for an electronic controller (e.g., versions for hardware or software, I / O identifiers, compatibility values, etc.), a native application update (e.g., updates for applications run as software directly on an ECU of the vehicle, where the update can be a modification, addition of a new application, removal of an application, moving an application from one ECU to another ECU, etc.), a containerized application update (e.g., updates, modification, addition, and / or removal of a containerized application, which will typically be in a common location with other containerized applications), a software configuration for an electronic controller (e.g., OS software, bootloaders, software versions, etc.), a policy value for the vehicle (e.g., changes, additions, removal, and / or modifications for policies (and / or similar objects) such as may implement data collection, automated operations, and / or remote control operations), and / or an automation description for a vehicle (e.g., a data structure that can be utilized for performing automated operations, which may be a policy, part of a policy, and / or implemented as a standalone data structure and / or automation implementation system).

[0067] Embodiments herein utilize the simplest update mechanism that is sufficient to perform the updates requested, minimizing potential disruption to vehicle operations, and seamlessly adjusting the update scheme according to the updates being performed, without management of the updating scheme required by the user directing the update. For example, updates may be performed at runtime, on a next startup, or implemented over a period of time or startup cycles, depending upon the update being performed, and the affected features of the vehicle. An example update may be performed in parts, with non-disruptive portions performed at runtime, minimally disruptive and / or low risk updates being performed on a next startup, and higher risk operations (e.g., changes to firmware for a vehicle control ECU that may change operator perception of performance, formatting of physical disk space, etc.) performed over time according to the vehicle operating state to ensure that the vehicle operator does not experience a sudden change in control and that ECUs or data on the vehicle are not corrupted, and accounting for dependencies between aspects of the update operations. The adjustments to divide updates and ensure update implementation are performed automatically by the update system herein, and do not require specific management of the pieces by the user directing the update. Additionally, embodiments herein provide for granular tracking of updates for each vehicle, allowing the user directing the update to track and / or get a report depicting which vehicles have received which updates, any update attempts that have failed or stalled, andinformation about the vehicle on when updates occurred, which updates are in progress, and why any failure or stalled behavior has occurred.

[0068] In certain embodiments, the update system herein provides a predictive component that provides a cost estimate for an update campaign (e.g., the cost to apply selected updates to a selected group of vehicles, where the cost can include predicted downtime for vehicles, time to complete the campaign, resources that will be utilized to complete the campaign (e.g., computing, networking, power, and / or mobile communication bandwidth), and / or expected number of update failures that will require intervention to complete); dependency validation for the update (e.g., confirming among the vehicle set which portions of the update require specific versions of hardware, firmware, or the like, to successfully receive and implement the planned update, and / or feature dependencies - for example installed applications on the vehicle, or applications that should be updated together - that are required to successfully receive and implement the planned update); and / or target vehicle estimation (e.g., which group of vehicles should receive the update, and / or are compatible with the update). An example embodiment includes a dependency management system (DMS) that determines dependencies related to the update, allowing the user to ensure that vehicles targeted for update will not have dependency issues based on the targeted update parameters, provides an interface to address any dependency issues, and / or makes recommendations to resolve any dependency issues.

[0069] In certain embodiments, the update system includes transparency operations to allow the user to track and confirm the progress of an update for a vehicle, group of vehicles, or campaign. The transparency operations facilitate operations such as: a failure root cause analysis (e.g., providing information about why updates to one or more vehicles were not successful); provide for gathering and correlation from multiple data sources (e.g., logs, detected events, status values from ECUs on the vehicle, operational parameters such as startup and shutdown timing on the vehicle, etc.) that are presented to the user in a campaign tracker or other interface, and / or that are made available to the user in dashboards, messages, or the like; and / or context stitching based on the campaign (e.g., a timeline of events of the campaign, including causal relationships between events, correlation of timing between events, etc.).

[0070] In certain embodiments, the update system is scalable (e.g., the update system allows the user to define vehicle groups and associate aspects for update readily with related vehicles) and expandable, allowing for any type of update to ECUs, switches, shared storage parameters, container based applications, service oriented architecture changes (e.g., subscription or publication paradigms, permissions, addition of available services, removal of services, etc.), and / or variant coding (e.g., adaptation of updates for specific vehicles based on rules, features or hardware installed on thevehicle, subscriptions or preferences by the vehicle owner or operator, etc.). In certain embodiments, any or all of these aspects may be implemented in a manner that is readily configurable by the user directing the update, and / or that is transparent to the user directing the update.

[0071] In certain embodiments, the update system provides an interface for campaign creation, download (e.g., to the specific vehicles), orchestration (e.g., implementing elements of the campaign in sequence according to the updates being performed and / or the vehicles being updated), verification, rollback (e.g., reverting one or more update elements of the campaign, including generally and / or for specific vehicles), and / or status reporting for the campaign. Example embodiments provide comprehensive tracking and / or auditing for the campaign, support for A / B updates (e.g., using an active and backup configuration file, firmware, etc., to allow for low risk updates for certain types of updates), support for delta updates (e.g., updating by modifying an existing firmware, configuration file, etc., that does not require overwriting the entire previous file), support for new and legacy vehicles and network configurations from a single interface (including, e.g., vehicles utilizing a CAN, LIN, etc.), and / or enforcement of security features to ensure that only authorized users are able to perform updates, including scheduling of different aspects of the update for different users within their permission scope.

[0072] Example embodiments to support firmware updates for ECUs, end points, and / or controllers on the vehicle provide cost savings by avoiding manual updates, provide for enhanced security both through enforcement of operational security during update procedures and also by providing the tools for rapid deployment of security updates to ensure that computing devices on the vehicle are operating with the latest security enhancements, and improve the quality of life for vehicle operators by providing a mechanism for new features, rapid bug fixes, and reduce risks by avoiding a requirement to travel to a service center for updates. Additionally, embodiments to support firmware updates reduce downtime and disruptive impact on vehicle operations, further increasing satisfaction for vehicle operators.

[0073] Previously known systems have a limited number of ECUs on the vehicle that are available for firmware updates at all, where embodiments herein may provide full update capability to any ECU on any network or network zone of the vehicle. Previously known systems require a lengthy development and testing process before an update can be rolled out to vehicles, involving formal engineering testing, verification, and certification (e.g., if a software update is being implemented). Previously known systems involve a complicated and manual deployment process, and an expensive download process involving service events and / or significant downtime for the vehicle. Previously known systems involve a high risk installation, with limited ability to detect off-nominal installations and / or determine root causes of issues with an installation.

[0074] In certain embodiments herein, multiple layers of OTA implementation are available to the update system, for example a configuration OTA capable to update hardware or software configurations, a feature OTA capable to update policies and / or recipes, and an application OTA capable to update native or containerized applications for the vehicle. In certain embodiments, the update system schedules a given update to utilize the least disruptive OTA layer that is sufficient to deploy a given update, including dividing the update into portions to limit disruptive OTA operations to those aspects that require such capability. Embodiments herein allow the update system to support DBC (CAN database) updates, allow for feature enablement (e.g., toggle features on / off, and / or support subscriptions for features), provide for data collection operations (e.g., updates to collected data), provide for diagnostics updates and / or diagnostics of update operations, and / or provide for calibration updates on the vehicle.

[0075] Referencing Fig. 4, an example feature OTA embodiment is schematically depicted. In certain embodiments, the feature OTA of Fig. 4 may be utilized to update native applications on ECUs of the vehicle. The example system includes an update manager 204 having cloud layer components allowing a user to configure and deploy campaigns for updates to a group of vehicles, for example a group of vehicles having a certain feature, related by model and / or model year, owned by a particular fleet, etc. Any group of vehicles is contemplated herein. The cloud layer allows a non-technical person to define the update and / or campaign target, allows a technical person to determine the specific updates, for example configurations, calibrations, feature updates, etc., and to deploy the update to the group of vehicles. The cloud layer additionally allows a technical person to monitor the deployment, including determining which vehicles have been updated, which vehicles have not been updated, and why the vehicles have not been updated. In certain embodiments, the cloud layer provides a dashboard with update statistics, relevant issues (e.g., fault codes, versions of hardware and / or software, etc., indicating why updates are delayed or not completed), verified completion of the campaign or vehicle updates, etc. The vehicle side layer includes an update master that receives and verifies the update, and that distributes relevant portions of the update to ECUs on the vehicle, as well as coordinates update operations to ensure that the least disruptive update operations are performed, that all updates are completed, and provides update information to the cloud layer to inform the dashboard or user interface utilized to track the updates and / or campaign. In the example of Fig. 4, the OTA master operates as the HPC Primary 104, and an OTA client 206 is communicatively interposed between the HPC Primary 104 and the update manager 204. In the example of Fig. 4, intermediate controllers in the hierarchy operate as HPC Secondary 106 controllers, for example a Container Updater, Switch FW Updater, and / or CAN ECU Updater.

[0076] Referencing Fig. 5, an example application OTA embodiment, capable to update containerized applications, is schematically depicted. The example of Fig. 5 may be included, in whole or part, as a part of the example of Fig. 4. In certain embodiments, aspects of the example of Fig. 4 may be included, in whole or part, with the example of Fig. 5. The example of Fig. 5 depicts a container manager 504 that executes operations to implement and validate updates to containerized applications on any ECU of the vehicle. The example of Fig. 5 includes an update manager, positioned on the container manager 504 in the example embodiment, that receives an update package (e.g., from the OTA Manager 506), where the container manager 504 validates the update package and applies the update to containerized applications on the vehicle. The example of Fig. 5 includes a vehicle data collector 508 that provides a confirmation of the update (and / or an issue communication where the update did not work, and / or an invalidity communication if the update package is not validated), which is received by a vehicle data platform 510 external device. In the example of Fig. 5, the Container OTA Platform 502 implements a vehicle update interface to allow a user to create, deploy, and / or monitor updates for the vehicle, and receives vehicle communications from the vehicle data platform 510.

[0077] Referencing Fig. 6, an example configuration OTA embodiment is schematically depicted, capable to update vehicle configuration values. The example of Fig. 6 may be utilized with, or included as a part of, the example of Fig. 4. The example of Fig. 5 depicts a vehicle configuration manager that executes operations to implement configuration updates for any end points, entities, applications, etc. on the vehicle. In the example of Fig. 6, the Vehicle Configuration Platform 602 operates as an update manager, the Vehicle Configuration Manager 604 operates as an HPC Primary, and other controllers depicted 606, 608, 610 operate as HPC Secondary controllers.

[0078] Referencing Fig. 7, an example vehicle update interface 700 is depicted, with an interface depicted that allows for a user to add ECUs to the system and associate them with specific vehicles. The interface of Fig. 7 allows the update manager to ensure that updates will be valid for the specific vehicle, including for example utilizing the proper versions for software, firmware, calibrations, trims, controller data, or the like, as well as determine compatibility with other devices on the vehicle and updates for those devices. In certain embodiments, vehicle information such as specific ECUs and / or versions of information on the ECU can be determined automatically by operations of the update manager, and / or as a data collection operation - for example with the user applying a policy to a selected group of vehicles to gather the information and merge it into an update operation, such as a campaign.

[0079] Referencing Fig. 8, an example user interface, which may be a part of a vehicle update interface 800, for example implemented at the cloud layer, allows users to define which ECUs onvehicles of a group support asset types such as firmware, containers, policies, configurations, variant coding, application software, or the like. Referencing Fig. 9, an example user interface, for example implemented at the cloud layer and which may be a part of a vehicle update interface 900, allows users to upload artifacts for the asset types supported by ECUs on the group of vehicles, and / or further allows the user to assign dependencies of the artifacts on any of the asset types. Referencing Fig. 9, an example user interface, for example implemented at the cloud layer, allows users to package multiple artifacts together into a single package as a part of an update (e.g., as a part of a campaign). Referencing Fig. 10, an example user interface, for example implemented at the cloud layer and which may be a part of a vehicle update interface 1000, allows users to select target package(s) to be deployed as an update, including allowing the user to configure the update communication parameters (e.g., cellular, WiFi, direct tool connection, etc.), any vehicle conditions to be enforced for the update (e.g., windows closed, minimum battery level, doors shut, HVAC turned off, etc.). In certain embodiments, the controller on vehicle may apply additional criteria to ensure that update operations are completed successfully, such as applying certain updates on a start operation, utilizing partitions to implement certain types of updates, etc., but the example of Fig. 10 allows for the user to apply additional criteria if desired. Referencing Fig. 11, an example user interface for a selection of the “Rollouts” tab from the example of Fig. 10 is schematically depicted, which may be a part of a vehicle update interface 1100. As used herein, a rollout is a deployment action, which may be a part of updating vehicles or a campaign to update a number of vehicles, and which may be approved and / or initiated by a user interacting with the vehicle update interface. Referencing Fig. 12, an example user interface 1100 is schematically depicted, which is consistent with the example of Fig. 11. The example interface 1100 includes displays for a rollout name, a vehicle selection window allowing a user to find and select vehicles according to shared properties of the vehicles, a rollout strategy window allowing the user to define deployment and / or rollout operational parameters, and an issue response window allowing the user to define responses to issues that occur during the rollout (e.g., defining failure threshold and response to the deployment failure).

[0080] Referencing Fig. 13, an example for a selection of the “Installation and approval” tab from the example of Fig. 10 is schematically depicted, and which may be a part of a vehicle update interface 1300. Referencing Fig. 14, a vehicle update interface 1300 that is consistent with the example of Fig. 13 is schematically depicted. The example of Fig. 14 includes a rollout completion timeline display allowing a user to track progress for deployment and installation of the rollout on various vehicles, a rollout installation details window that allows the user to see and / or modify properties of the rollout implementation, and an approval interface that allows the user to approve and / or initiate deployment of the updates represented in the rollout to selected vehicles.

[0081] Referencing Fig. 15, an example of a predicted deployment operation is schematically depicted, which may be provided on a dashboard or other display for the user for example as part of a vehicle update interface 1500. The example of Fig. 15 allows a user to diagnose issues likely to be incurred if the update is deployed as planned, estimated cost of the campaign, bandwidth utilization, potential conflicts, and / or suggested actions to reduce or resolve the issues. Referencing Fig. 16, a vehicle update interface 1500 that is consistent with the example of Fig. 15 is schematically depicted. The example of Fig. 16 includes a vehicle update interface 1600 having a rollout header allowing the user to readily track which rollout is being displayed, a vehicle summary display that shows the shared properties of the selected vehicles (e.g., make, model year, significant features, etc.), a performance description that allows the user to see the predicted cost or other performance parameters for the rollout, a vehicle listing that allows the user to select vehicles in scope for the rollout, an issue indicators section listing issues that are predicted to occur for vehicles in the list (e.g., incompatible version issues, lack of available memory, lack of sufficient connectivity, etc.), a statistics display showing relevant aspects of the rollout such as bandwidth utilization, update package sizes, predicted times, etc., a heat map displaying where the vehicles related to the rollout are located, and an approval interface allowing the user to save and / or implement the rollout. In certain embodiments, a similar interface to that depicted in Figs. 15-16 may be used in real time after the rollout is commenced, for example allowing the user to track the actual performance of the rollout / deployment.

[0082] Referencing Fig. 17, an example rollout status interface is schematically depicted, which may be a part of a vehicle update interface 1700, and which provides information about the status of various rollouts that are in deployment or that have been deployed, with options for more detailed reporting. Referencing Fig. 18, an example vehicle update interface 1700 is schematically depicted and consistent with the example of Fig. 17. The example of Fig. 18 includes a rollout header, a campaign details display allowing the user to identify the associated campaign, a rollout list displaying various rollout / deployment operations related to the campaign, a rollout installation details window that shows operational parameters for the rollout / display operations, and an approval interface allowing the user to approve and / or initiate particular rollouts, and / or to pause or abort ongoing rollouts.

[0083] Referencing Fig. 19, an example interface is schematically depicted, which may be a part of a vehicle update interface 1900, and which provides more detailed reporting on a particular campaign, including options to pause or abort the campaign. Referencing Fig. 20, an example vehicle update interface 1900 is schematically depicted and consistent with the example of Fig. 19. The example of Fig. 20 includes a rollout header, a rollout statistic display allowing the user to track progress of therollout, a deployment dashboard showing progress of the rollout including numbers of vehicles at each stage of the rollout, along with a vehicle list and issue indicators that show live data and that can be navigated by the user to diagnose issues and / or select vehicles for further details and / or to plan corrections.

[0084] Referencing Fig. 21, an example interface is schematically depicted, which may be a part of a vehicle update interface 2100, and which provides reporting on performance for an update for a particular vehicle, for example accessed by a query about the vehicle, or selecting the vehicle from a list for example from the interface of Fig. 19. Referencing Fig. 22, an example vehicle update interface 2100 is schematically depicted and consistent with the example of Fig. 21. The example of Fig. 22 includes a rollout header, a rollout timeline and statistics display (e.g., allowing the user to monitor progress of the rollout), an asset identification and status display, for example showing details of various components being updated on a specific vehicle (and / or a more generalized view of the components that are common to all vehicles and / or selected vehicles), and installation details so the user can see which components of a vehicle have been updated, relevant progress, and / or relevant issues.

[0085] Referencing Fig. 23, an example detailed information about an update process on a particular vehicle is schematically depicted, which may be a part of a vehicle update interface 2300, and which may be accessed, for example, by selecting a process for the vehicle from the example of Fig. 21. The example of Fig. 23 provides a granular deployment view that may be utilized to optimize future campaigns (e.g., using a machine learning algorithm or the like), perform accurate predictions for the outcome of campaigns, and / or to diagnose specific issues for the vehicle or campaign. Each process within the example of Fig. 23 may additionally be selected to show additional information such as Tags or Events for the process. Referencing Fig. 24, an example vehicle update interface 2300 is schematically depicted and consistent with the example of Fig. 23. The example of Fig. 24 includes a rollout header, an asset identification and status (e.g., which specific component that is being updated has the details being displayed), an installation sequence (e.g., update steps for the particular asset / component being displayed), and installation details such as time of event completion, progress, issues, or the like.

[0086] Example and non-limiting embodiments are described following. The example embodiments described following may be embodied, in whole or part, in the systems and / or controllers in Figs. 1-6 preceding, and / or using vehicle update interfaces such as depicted in Figs. 7-24 preceding.

[0087] An example cloud system designed to facilitate over-the-air (OTA) updates for vehicles includes an update manager, a deployment manager, a package manager, and a campaign manager, each configured to perform specific functions to ensure seamless and efficient updates to vehiclesoftware and configurations. The example update manager implements a vehicle update interface and prepares an update package based on user interactions with the interface. The deployment manager determines at least one target vehicle and approves the deployment based on user interactions. The package manager communicates the update package to the target vehicle upon deployment approval. The deployment manager also confirms the deployment upon receiving a confirmation communication from the target vehicle.

[0088] The example system includes a campaign manager that determines a group of vehicles based on user interactions. The deployment manager determines the target vehicles from this group (which may be all of the vehicles in the group), and the package manager communicates the update package to these vehicles upon deployment approval.

[0089] A configuration validator confirms the validity of the target vehicles' configurations in response to the update package and configuration descriptions for each vehicle. The deployment manager uses this validation to approve the deployment. The configuration validator can determine an incompatibility value if at least one target vehicle does not have a valid configuration for the update package, and provides an invalidity communication in such cases. The configuration validator sends the invalidity communication to the campaign manager based on the incompatibility value.

[0090] Example and non-limiting invalidity communications includes one or more of: a list of vehicles without valid configurations, a description of incompatible aspects of the configuration for at least one vehicle, and / or a description of incompatible aspects of the update package for at least one vehicle. An example invalidity communication includes a description of incompatible aspects of the configuration for at least one vehicle and / or a description of incompatible aspects of the update package for at least one vehicle. An example deployment manager provides a modified update package recommendation (e.g., a change to the update package that corrects the incompatible aspect) and at least one alternative target vehicle in response to the invalidity communication.

[0091] The example campaign manager receives update status information from the target vehicles and provides a campaign status display to the vehicle update interface based on this information. Example and non-limiting aspects of a campaign status display include: a list of at least a portion of the group of vehicles, a status indicator for each vehicle, and / or an issue indicator for each vehicle (e.g., which may be a number representing the number of issues, an issue descriptor, and / or a null indicator or blank space if no issues are indicated). The campaign status display includes a rollout dashboard corresponding to the deployment of the update package to the target vehicles. An example rollout dashboard includes aspects such as: a pending progress indicator for offline vehicles, a sending progress indicator for ongoing communications to vehicles, a deploying progressindicator for installation status, and / or a completion progress indicator for the application status of the update package (e.g., to a vehicle, to all vehicles of the rollout / deployment, and / or for a selected group of vehicles, for example including averaged information and / or other statistical measures). An example campaign status display includes a list of at least a portion of the group of vehicles and a status indicator for each vehicle.

[0092] The campaign manager updates the campaign status display with a granular deployment view when a user selects a vehicle from the list, and / or selects a group of vehicles. An example granular deployment view depicts installation operations and updated devices on the selected vehicle(s). An example granular deployment view depicts installation operations and updated devices on the selected vehicle.

[0093] An example update package includes one or more of: a firmware value, a data value, a configuration value, a native application update, a containerized application update, a software configuration, a policy value, and / or an automation description for the vehicle. Another example update package includes at least two of: a native application update, a containerized application update, a policy value, and an automation description for the vehicle. Another example update package includes a firmware value for a first electronic controller, a data value for either the first or a second electronic controller, and a policy value for the vehicle. In a further example the update package includes a native application update for an electronic controller. The described update packages are non-limiting, but are some examples of high value update packages that are difficult or not possible to implement in previously known OTA update systems.

[0094] The example cloud system provides a comprehensive solution for managing OTA updates for vehicles, ensuring that updates are efficiently prepared, validated, communicated, and confirmed, while also providing detailed status information and handling potential configuration incompatibilities.

[0095] An example system designed to facilitate over-the-air (OTA) updates for vehicles, utilizes a hierarchical arrangement of update controllers within the vehicle. The example system includes a vehicle with a number of hierarchically arranged update controllers. These controllers comprise a primary controller, a secondary controller, and a tertiary controller. The primary controller is configured to receive an update package that includes an update payload for at least one controller of the vehicle. It then communicates at least a portion of the update payload to the secondary controller. The secondary controller receives the portion of the update payload from the primary controller, parses it into a child update payload, and communicates the child update payload to the tertiary controller. The tertiary controller applies the child update payload and provides a tertiary confirmation of the applied child update payload to the secondary controller. The secondarycontroller compiles a secondary confirmation, which includes the tertiary confirmation, and communicates this secondary confirmation to the primary controller. The primary controller then compiles a vehicle confirmation, which includes the secondary confirmation, and communicates the vehicle confirmation to a cloud update platform.

[0096] In certain embodiments, each of the primary, secondary, and tertiary controllers is further configured to control updates to direct responsibility devices. The tertiary controller compiles direct responsibility device updates into the tertiary confirmation, the secondary controller compiles these updates into the secondary confirmation, and the primary controller compiles them into the vehicle confirmation.

[0097] An update client (e.g., an OTA client) is communicatively interposed between the primary controller and the cloud update platform. In certain embodiments, the update client is configured to validate the update package and communicate it to the primary controller upon validation. If the update package fails to validate, the update client provides the vehicle confirmation as an issue indicator. The update client can also provide a validated portion of the update package to the primary controller, where the validated portion includes an independent portion of the update package. The primary controller is configured to implement A / B installation management for itself and for direct responsibility devices (e.g., protecting for the ability to roll back changes for the primary controller and devices that are updated directly from the primary controller). Similarly, the secondary and tertiary controllers are also configured to implement A / B installation management for themselves and for their respective direct responsibility devices.

[0098] This system provides a structured and efficient method for managing OTA updates within a vehicle, ensuring that updates are validated, communicated, and confirmed through a hierarchical arrangement of controllers, while also handling potential issues and providing detailed status information.

[0099] An example system is designed to facilitate over-the-air (OTA) updates for vehicles, specifically focusing on containerized applications within the vehicle. The example system includes a vehicle comprising an update manager, a container manager, and a vehicle data collector. The update manager is configured to receive an update package that includes an update to a containerized application on the vehicle. The container manager is responsible for validating and applying the update to the containerized application on the vehicle. Once the update is applied, the container manager provides a vehicle confirmation to the vehicle data collector. The vehicle data collector then communicates the vehicle confirmation to a cloud update platform.

[0100] If the update to the containerized application on the vehicle fails to validate, the container manager provides an issue indicator to the vehicle data collector. This ensures that any issues with the update are promptly identified and communicated.

[0101] This system provides an efficient method for managing OTA updates for containerized applications within a vehicle, ensuring that updates are validated, applied, and confirmed, while also handling potential issues and providing detailed status information.

[0102] Example embodiments herein provide a single unified tool to implement update operations for the vehicle throughout the vehicle life cycle, providing a consistent user interface and functional capability. Example embodiments allow for convenient and rapid change to vehicle configurations, for example during development for new features, for bug fixes, and / or in developing diagnostics or executing fault tree analysis. Example embodiments allow for grouping and updating of vehicles according to installed features, vehicle behavior, model, trim, etc., at any point of the vehicle life cycle including during manufacture, body building, dealer trimming, service events, ongoing operation, vehicle upfitting, and / or vehicle application changes. Example embodiments allow users to easily and quickly create, update, deploy, and / or inspect vehicle configurations.

[0103] The methods and systems described herein may be deployed in part or in whole through a machine having a computer, computing device, processor, circuit, and / or server that executes computer readable instructions, program codes, instructions, and / or includes hardware configured to functionally execute one or more operations of the methods and systems herein. The terms computer, computing device, processor, circuit, and / or server, (“computing device”) as utilized herein, should be understood broadly.

[0104] An example computing device includes a computer of any type, capable to access instructions stored in communication thereto such as upon a non-transient computer readable medium, whereupon the computer performs operations of the computing device upon executing the instructions. In certain embodiments, such instructions themselves comprise a computing device. Additionally or alternatively, a computing device may be a separate hardware device, one or more computing resources distributed across hardware devices, and / or may include such aspects as logical circuits, embedded circuits, sensors, actuators, input and / or output devices, network and / or communication resources, memory resources of any type, processing resources of any type, and / or hardware devices configured to be responsive to determined conditions to functionally execute one or more operations of systems and methods herein.

[0105] Network and / or communication resources include, without limitation, local area network, wide area network, wireless, internet, or any other known communication resources and protocols. Example and non- limiting hardware and / or computing devices include, without limitation, a general-purpose computer, a server, an embedded computer, a mobile device, a virtual machine, and / or an emulated computing device. A computing device may be a distributed resource included as an aspect of several devices, included as an interoperable set of resources to perform described functions of the computing device, such that the distributed resources function together to perform the operations of the computing device. In certain embodiments, each computing device may be on separate hardware, and / or one or more hardware devices may include aspects of more than one computing device, for example as separately executable instructions stored on the device, and / or as logically partitioned aspects of a set of executable instructions, with some aspects comprising a part of one of a first computing device, and some aspects comprising a part of another of the computing devices.

[0106] A computing device may be part of a server, client, network infrastructure, mobile computing platform, stationary computing platform, or other computing platform. A processor may be any kind of computational or processing device capable of executing program instructions, codes, binary instructions and the like. The processor may be or include a signal processor, digital processor, embedded processor, microprocessor or any variant such as a co-processor (math co-processor, graphic co-processor, communication co-processor and the like) and the like that may directly or indirectly facilitate execution of program code or program instructions stored thereon. In addition, the processor may enable execution of multiple programs, threads, and codes. The threads may be executed simultaneously to enhance the performance of the processor and to facilitate simultaneous operations of the application. By way of implementation, methods, program codes, program instructions and the like described herein may be implemented in one or more threads. The thread may spawn other threads that may have assigned priorities associated with them; the processor may execute these threads based on priority or any other order based on instructions provided in the program code. The processor may include memory that stores methods, codes, instructions and programs as described herein and elsewhere. The processor may access a storage medium through an interface that may store methods, codes, and instructions as described herein and elsewhere. The storage medium associated with the processor for storing methods, programs, codes, program instructions or other type of instructions capable of being executed by the computing or processing device may include but may not be limited to one or more of a CD-ROM, DVD, memory, hard disk, flash drive, RAM, ROM, cache and the like.

[0107] A processor may include one or more cores that may enhance speed and performance of a multiprocessor. In embodiments, the process may be a dual core processor, quad core processors, other chip-level multiprocessor and the like that combine two or more independent cores (called a die).

[0108] The methods and systems described herein may be deployed in part or in whole through a machine that executes computer readable instructions on a server, client, firewall, gateway, hub, router, or other such computer and / or networking hardware. The computer readable instructions may be associated with a server that may include a file server, print server, domain server, internet server, intranet server and other variants such as secondary server, host server, distributed server and the like. The server may include one or more of memories, processors, computer readable transitory and / or non-transitory media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other servers, clients, machines, and devices through a wired or a wireless medium, and the like. The methods, programs, or codes as described herein and elsewhere may be executed by the server. In addition, other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the server.

[0109] The server may provide an interface to other devices including, without limitation, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, and the like. Additionally, this coupling and / or connection may facilitate remote execution of instructions across the network. The networking of some or all of these devices may facilitate parallel processing of program code, instructions, and / or programs at one or more locations without deviating from the scope of the disclosure. In addition, all the devices attached to the server through an interface may include at least one storage medium capable of storing methods, program code, instructions, and / or programs. A central repository may provide program instructions to be executed on different devices. In this implementation, the remote repository may act as a storage medium for methods, program code, instructions, and / or programs.

[0110] The methods, program code, instructions, and / or programs may be associated with a client that may include a file client, print client, domain client, internet client, intranet client and other variants such as secondary client, host client, distributed client and the like. The client may include one or more of memories, processors, computer readable transitory and / or non-transitory media, storage media, ports (physical and virtual), communication devices, and interfaces capable of accessing other clients, servers, machines, and devices through a wired or a wireless medium, and the like. The methods, program code, instructions, and / or programs as described herein and elsewhere may be executed by the client. In addition, other devices required for execution of methods as described in this application may be considered as a part of the infrastructure associated with the client.

[0111] The client may provide an interface to other devices including, without limitation, servers, other clients, printers, database servers, print servers, file servers, communication servers, distributedservers, and the like. Additionally, this coupling and / or connection may facilitate remote execution of methods, program code, instructions, and / or programs across the network. The networking of some or all of these devices may facilitate parallel processing of methods, program code, instructions, and / or programs at one or more locations without deviating from the scope of the disclosure. In addition, all the devices attached to the client through an interface may include at least one storage medium capable of storing methods, program code, instructions, and / or programs. A central repository may provide program instructions to be executed on different devices. In this implementation, the remote repository may act as a storage medium for methods, program code, instructions, and / or programs.

[0112] The methods and systems described herein may be deployed in part or in whole through network infrastructures. The network infrastructure may include elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices and other active and passive devices, modules, and / or components as known in the art. The computing and / or non-computing device(s) associated with the network infrastructure may include, apart from other components, a storage medium such as flash memory, buffer, stack, RAM, ROM and the like. The methods, program code, instructions, and / or programs described herein and elsewhere may be executed by one or more of the network infrastructural elements.

[0113] The methods, program code, instructions, and / or programs described herein and elsewhere may be implemented on a cellular network having multiple cells. The cellular network may either be frequency division multiple access (FDMA) network or code division multiple access (CDMA) network. The cellular network may include mobile devices, cell sites, base stations, repeaters, antennas, towers, and the like.

[0114] The methods, program code, instructions, and / or programs described herein and elsewhere may be implemented on or through mobile devices. The mobile devices may include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, electronic books readers, music players and the like. These devices may include, apart from other components, a storage medium such as a flash memory, buffer, RAM, ROM and one or more computing devices. The computing devices associated with mobile devices may be enabled to execute methods, program code, instructions, and / or programs stored thereon. Alternatively, the mobile devices may be configured to execute instructions in collaboration with other devices. The mobile devices may communicate with base stations interfaced with servers and configured to execute methods, program code, instructions, and / or programs. The mobile devices may communicate on a peer-to-peer network, mesh network, or other communications network. The methods, program code, instructions, and / or programs may be stored on the storage mediumassociated with the server and executed by a computing device embedded within the server. The base station may include a computing device and a storage medium. The storage device may store methods, program code, instructions, and / or programs executed by the computing devices associated with the base station.

[0115] The methods, program code, instructions, and / or programs may be stored and / or accessed on machine readable transitory and / or non-transitory media that may include: computer components, devices, and recording media that retain digital data used for computing for some interval of time; semiconductor storage known as random access memory (RAM); mass storage typically for more permanent storage, such as optical discs, forms of magnetic storage like hard disks, tapes, drums, cards and other ty pes; processor registers, cache memory, volatile memory, non-volatile memory'; optical storage such as CD, DVD; removable media such as flash memory (e.g. USB sticks or keys), floppy disks, magnetic tape, paper tape, punch cards, standalone RAM disks, Zip drives, removable mass storage, off-line, and the like; other computer memory' such as dynamic memory, static memory, read / write storage, mutable storage, read only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage area network, bar codes, magnetic ink, and the like.

[0116] Certain operations described herein include interpreting, receiving, and / or determining one or more values, parameters, inputs, data, or other information (“receiving data”). Operations to receive data include, without limitation: receiving data via a user input; receiving data over a network of any type; reading a data value from a memory location in communication with the receiving device; utilizing a default value as a received data value; estimating, calculating, or deriving a data value based on other information available to the receiving device; and / or updating any of these in response to a later received data value. In certain embodiments, a data value may be received by a first operation, and later updated by a second operation, as part of the receiving a data value. For example, when communications are down, intermittent, or interrupted, a first receiving operation may be performed, and when communications are restored an updated receiving operation may be performed.

[0117] Certain logical groupings of operations herein, for example methods or procedures of the current disclosure, are provided to illustrate aspects of the present disclosure. Operations described herein are schematically described and / or depicted, and operations may be combined, divided, reordered, added, or removed in a manner consistent with the disclosure herein. It is understood that the context of an operational description may require an ordering for one or more operations, and / or an order for one or more operations may be explicitly disclosed, but the order of operations should be understood broadly, where any equivalent grouping of operations to provide an equivalent outcomeof operations is specifically contemplated herein. For example, if a value is used in one operational step, the determining of the value may be required before that operational step in certain contexts (e.g., where the time delay of data for an operation to achieve a certain effect is important), but may not be required before that operation step in other contexts (e.g. where usage of the value from a previous execution cycle of the operations would be sufficient for those purposes). Accordingly, in certain embodiments an order of operations and grouping of operations as described is explicitly contemplated herein, and in certain embodiments re-ordering, subdivision, and / or different grouping of operations is explicitly contemplated herein.

[0118] The methods and systems described herein may transform physical and / or or intangible items from one state to another. The methods and systems described herein may also transform data representing physical and / or intangible items from one state to another.

[0119] The methods and / or processes described above, and steps thereof, may be realized in hardware, program code, instructions, and / or programs or any combination of hardware and methods, program code, instructions, and / or programs suitable for a particular application. The hardware may include a dedicated computing device or specific computing device, a particular aspect or component of a specific computing device, and / or an arrangement of hardware components and / or logical circuits to perform one or more of the operations of a method and / or system. The processes may be realized in one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors or other programmable device, along with internal and / or external memory. The processes may also, or instead, be embodied in an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that may be configured to process electronic signals. It will further be appreciated that one or more of the processes may be realized as a computer executable code capable of being executed on a machine readable medium.

[0120] The computer executable code may be created using a structured programming language such as C, an object oriented programming language such as C++, or any other high-level or low-level programming language (including assembly languages, hardware description languages, and database programming languages and technologies) that may be stored, compiled or interpreted to run on one of the above devices, as well as heterogeneous combinations of processors, processor architectures, or combinations of different hardware and computer readable instructions, or any other machine capable of executing program instructions.

[0121] Thus, in one aspect, each method described above, and combinations thereof, may be embodied in computer executable code that, when executing on one or more computing devices, performs the steps thereof. In another aspect, the methods may be embodied in systems that performthe steps thereof, and may be distributed across devices in a number of ways, or all of the functionality may be integrated into a dedicated, standalone device or other hardware. In another aspect, the means for performing the steps associated with the processes described above may include any of the hardware and / or computer readable instructions described above. All such permutations and combinations are intended to fall within the scope of the present disclosure.

Claims

What is claimed is:

1. A cloud system, comprising: an update manager configured to implement a vehicle update interface, and to prepare an update package in response to user interactions with the vehicle update interface; a deployment manager configured to determine at least one target vehicle, and to determine a deployment approval in response to user interactions with the vehicle update interface; a package manager configured to communicate the update package to the at least one target vehicle in response to the deployment approval; and wherein the deployment manager is further configured to confirm a deployment of the update package in response to a confirmation communication from the at least one target vehicle.

2. The cloud system of claim 1, further comprising: a campaign manager configured to determine a group of vehicles in response to user interactions with the vehicle update interface; wherein the deployment manager is further configured to determine a plurality of target vehicles in response to the determined group of vehicles; and wherein the package manager is further configured to communicate the update package to the plurality of target vehicles in response to the deployment approval.

3. The cloud system of claim 2, further comprising: a configuration validator configured to confirm a validity of a configuration of the plurality of target vehicles in response to the update package and a configuration description for each of the plurality of target vehicles; and wherein the deployment manager is further configured to determine the deployment approval in response to the confirmed validity of the configuration of the plurality of target vehicles.

4. The cloud system of claim 3, wherein the configuration validator is further configured to determine an incompatibility value in response to determining that at least one of the plurality of target vehicles does not have a valid configuration for the update package, and to provide an invalidity communication in response to the determining that at least one of the plurality of target vehicles does not have the valid configuration.

5. The cloud system of claim 4, wherein the configuration validator is further configured to provide the invalidity communication to the campaign manager in response to the incompatibility value.

6. The cloud system of claim 5, wherein the invalidity communication includes at least one of: a list of vehicles that do not have a valid configuration;a description of incompatible aspects of the configuration for at least one vehicle of a list of vehicles that do not have a valid configuration; or a description of incompatible aspects of the update package for at least one vehicle of a list of vehicles that do not have a valid configuration.

7. The cloud system of claim 5, wherein the invalidity communication includes at least one of: a description of incompatible aspects of the configuration for at least one vehicle of a list of vehicles that do not have a valid configuration; or a description of incompatible aspects of the update package for at least one vehicle of a list of vehicles that do not have a valid configuration.

8. The cloud system of claim 7, wherein the deployment manager is further configured to provide a modified update package recommendation and at least one alternative target vehicle in response to the invalidity communication.

9. The cloud system of claim 2, further comprising: wherein the campaign manager is further configured to receive update status information from the plurality of target vehicles; and provide a campaign status display to the vehicle update interface in response to the update status information.

10. The cloud system of claim 9, wherein the campaign status display comprises at least one of: a list of at least a portion of the group of vehicles; a status indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles; or an issue indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles.

11. The cloud system of claim 10, wherein the campaign status display comprises a rollout dashboard corresponding to the deployment of the update package to the plurality of target vehicles.

12. The cloud system of claim 11, wherein the rollout dashboard comprises at least one of: a pending progress indicating offline vehicles of the plurality7of target vehicles; a sending progress indicating ongoing ones of the communicating the update package to the plurality of target vehicles; a deploying progress indicating a status of installation of the update package on the plurality of target vehicles; or a completion progress indicating a status of application of the update package on the plurality of target vehicles.

13. The cloud system of claim 9, further comprising:wherein the campaign status display comprises a list of at least a portion of the group of vehicles, and a status indicator corresponding to each vehicle of the list of at least a portion of the group of vehicles.

14. The cloud system of claim 13, further comprising: wherein the campaign manager updates the campaign status display with a granular deployment view in response to a selection by the user of a vehicle from the list of at least a portion of the group of vehicles.

15. The cloud system of claim 14, wherein the granular deployment view depicts installation operations and updated devices on the selected vehicle.

16. The cloud system of claim 1, wherein the update package comprises at least one of: a firmware value for an electronic controller; a data value for an electronic controller; a configuration value for an electronic controller; a native application update for an electronic controller; a containerized application update for the vehicle; a software configuration for an electronic controller; a policy value for the vehicle; or an automation description for the vehicle.

17. The cloud system of claim 1, wherein the update package comprises at least two of: a native application update for an electronic controller; a containerized application update for the vehicle; a policy value for the vehicle; and an automation description for the vehicle.

18. The cloud system of claim 1, wherein the update package comprises all of the following: a firmware value for a first electronic controller; a data value for one of the first electronic controller or a second electronic controller; and a policy value for the vehicle.

19. The cloud system of claim 18, wherein the update package further comprises a native application update for an electronic controller.

20. A system, comprising: a vehicle having a plurality of hierarchically arranged update controllers, the update controllers comprising:a primary controller configured to receive an update package comprising an update payload for at least one controller of the vehicle, and to communicate at least a portion of the update payload to a secondary controller; the secondary controller configured to receive the at least a portion of the update payload, and to parse the at least a portion of the update payload into a child update payload, and to communicate the child update payload to a tertiary controller; wherein the tertiary controller is configured to apply the child update payload, and to provide a tertiary confirmation of the applied child update pay load to the secondary controller; wherein the secondary controller is further configured to compile a secondary confirmation including the tertiary confirmation, and to communicate the secondary confirmation to the primary controller; wherein the primary controller is further configured to compile a vehicle confirmation including the secondary confirmation, and to communicate the vehicle confirmation to a cloud update platform.

21. The system of claim 20, further comprising: wherein each of the primary controller, secondary controller, and tertiary controller are further configured to control updates to direct responsibility devices; wherein the tertiary controller is configured to compile direct responsibility device updates into the tertiary confirmation; wherein the secondary controller is configured to compile direct responsibility device updates into the secondary confirmation; and wherein the primary controller is configured to compile direct responsibility device updates into the vehicle confirmation.

22. The system of claim 20, further comprising an update client communicatively interposed between the primary controller and the cloud update platform.

23. The system of claim 22, wherein the update client is further configured to validate the update package, and to communicate the update package to the primary controller in response to validating the update package.

24. The system of claim 23, wherein the update client is further configured to provide the vehicle confirmation as an issue indicator in response to the update package failing to validate.

25. The system of claim 24, wherein the update client is further configured to provide a validated portion of the update package to the primary controller.

26. The system of claim 25, wherein the validated portion comprises an independent portion of the update package.

27. The system of claim 21, wherein the primary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

28. The system of claim 27, wherein the secondary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

29. The system of claim 28, wherein the tertiary controller is further configured to implement A / B installation management for itself and for direct responsibility devices.

30. A system, comprising: a vehicle comprising an update manager, a container manager, and a vehicle data collector; wherein the update manager is configured to receive an update package comprising an update to a containerized application on the vehicle; wherein the container manager is configured to validate and apply the update to the containerized application on the vehicle, and to provide a vehicle confirmation to the vehicle data collector; and wherein the vehicle data collector is configured to provide the vehicle confirmation to a cloud update platform.

31. The system of claim 30, wherein the container manager is configured to provide an issue indicator to the vehicle data collector in response to the update to the containerized application on the vehicle failing to validate.

Images