Patent ID: 12190091

DETAILED DESCRIPTION OF THE DRAWINGS

While the concepts of the present disclosure are susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and will be described herein in detail. It should be understood, however, that there is no intent to limit the concepts of the present disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives consistent with the present disclosure and the appended claims.

References in the specification to “one embodiment,” “an embodiment,” “an illustrative embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may or may not necessarily include that particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. Additionally, it should be appreciated that items included in a list in the form of “at least one A, B, and C” can mean (A); (B); (C): (A and B); (B and C); or (A, B, and C). Similarly, items listed in the form of “at least one of A, B, or C” can mean (A); (B); (C): (A and B); (B and C); or (A, B, and C).

The disclosed embodiments may be implemented, in some cases, in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on a transitory or non-transitory machine-readable (e.g., computer-readable) storage medium, which may be read and executed by one or more processors. A machine-readable storage medium may be embodied as any storage device, mechanism, or other physical structure for storing or transmitting information in a form readable by a machine (e.g., a volatile or non-volatile memory, a media disc, or other media device).

In the drawings, some structural or method features may be shown in specific arrangements and/or orderings. However, it should be appreciated that such specific arrangements and/or orderings may not be required. Rather, in some embodiments, such features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of a structural or method feature in a particular figure is not meant to imply that such feature is required in all embodiments and, in some embodiments, may not be included or may be combined with other features.

Referring now toFIG.1, an illustrative system100for remote firmware updates includes multiple telematics devices102in communication with a telematics cloud server104over a network106. In use, as described further below, a telematics device102contacts the telematics cloud server104and retrieves one or more firmware components for installation, for example to install upgrades, bug fixes, security enhancements, or other features. The telematics cloud server104and/or the telematics device102may identify certain firmware components within a firmware package for download and installation, which may reduce network bandwidth usage and increase speed of updates. Additionally, the telematics device102may apply one or more device policies, security policies, or more advanced rules to identify firmware components for installation. Additionally, in some embodiments, an administrator may schedule one or more mandatory or otherwise forced installations of firmware components. Thus, the system100also provides a powerful, flexible, and efficient system for managing firmware updates for a fleet of multiple, potentially heterogeneous telematics devices102.

Each telematics device102may be embodied as any type of device capable of performing the functions described herein. For example, the telematics device102may be embodied as, without limitation, a mobile computing device, an embedded device, a computer, a laptop computer, a notebook computer, a tablet computer, a wearable computing device, a multiprocessor system, a network appliance, a distributed computing system, a processor-based system, and/or a consumer electronic device. As shown inFIG.1, the illustrative telematics device102includes a processor120, an I/O subsystem122, memory124, a data storage device126, and a communication subsystem128. Of course, the telematics device102may include other or additional components, such as those commonly found in a portable or embedded computer (e.g., various input/output devices), in other embodiments. Additionally, in some embodiments, one or more of the illustrative components may be incorporated in, or otherwise form a portion of, another component. For example, the memory124, or portions thereof, may be incorporated in the processor120in some embodiments.

The processor120may be embodied as any type of processor or compute engine capable of performing the functions described herein. For example, the processor may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit. Similarly, the memory124may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory124may store various data and software used during operation of the telematics cloud server104such as operating systems, applications, programs, libraries, and drivers. The memory124is communicatively coupled to the processor120via the I/O subsystem122, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor120, the memory124, and other components of the telematics cloud server104. For example, the I/O subsystem122may be embodied as, or otherwise include, memory controller hubs, input/output control hubs, firmware devices, communication links (i.e., point-to-point links, bus links, wires, cables, light guides, printed circuit board traces, etc.) and/or other components and subsystems to facilitate the input/output operations. In some embodiments, the I/O subsystem122may form a portion of a system-on-a-chip (SoC) and be incorporated, along with the processor120, the memory124, and other components of the telematics device102, on a single integrated circuit chip.

The data storage device126may be embodied as any type of device or devices configured for short-term or long-term storage of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, or other data storage devices. The communication subsystem128of the telematics device102may be embodied as any communication circuit, device, or collection thereof, capable of enabling communications between the telematics device102, the telematics cloud server104, and/or other remote devices. The communication subsystem128may be configured to use any one or more communication technology (e.g., wireless or wired communications) and associated protocols (e.g., Ethernet, Bluetooth®, Bluetooth Low Energy (BLE), WiMAX, 3G LTE, 5G, etc.) to effect such communication.

As shown, each telematics device102is coupled to or otherwise included in a vehicle130. Each vehicle130may be embodied as, without limitation, a heavy truck, a fleet vehicle, a garbage truck, a snow plow, a dump truck, a bus, a light truck, a passenger car, an airplane, a water craft, or other vehicle. Additionally or alternatively, in some embodiments, the telematics device102may be coupled to another asset such as a shipping pallet, a tool cage, a restricted access room, a section of the warehouse, or any other device or location that may be monitored or tracked using a telematics device102. Illustratively, the vehicle130is a vehicle, and the telematics device102is configured to monitor operating conditions of the vehicle130and to communicate telematics data indicative of the operating conditions of the vehicle130to the telematics cloud server104.

As shown, the illustrative vehicle130further includes a vehicle bus132that may be coupled to multiple connected devices such as controllers134and sensors136. The vehicle bus132may be embodied as a controller area network (CAN) bus, a local area network, a wireless network, or another communications network that allows various components of the vehicle130and/or peripheral devices to communicate. The telematics device102is coupled to the vehicle bus132. In some embodiments, the telematics device102may be removably coupled to the vehicle bus132using a vehicle diagnostic connector such as an OBD-II port of the vehicle130. Additionally or alternatively, the telematics device102may be directly connected or otherwise coupled to the vehicle bus132with a wiring harness or other connector.

Each of the controllers134may be embodied as an electronic control unit (ECU), an engine controller, a vehicle controller, a microcontroller, or other embedded computing resource of the vehicle130. Each controller134may provide engine telemetry, ignition signals, odometer signals, or other vehicle telemetry data over the vehicle bus132. Each of the sensors136may be embodied as a location sensor (e.g., a GPS receiver), a speed sensor, a temperature sensor, an environmental sensor, a weight sensor, a vehicle- or application-specific sensor such as a snow plow position sensor, a fork lift position sensor, a tire pressure sensor, a door state sensor, or other sensor device configured to provide sensor data over the vehicle bus132. Although illustrated inFIG.1as being coupled to the telematics device102via the vehicle bus132, it should be understood that in some embodiments one or more of the controllers134and/or the sensors136may be coupled directly to the telematics device102via Bluetooth Low Energy (BLE), wireless networking (WiFi), a direct serial connection, or other connection.

In some embodiments, the vehicle130may include a mobile communication device138coupled to the telematics device102. The mobile communication device138may be embodied as a cellular modem, a smartphone, a cellular telephone, an IoT gateway, an IoT router, or other device that enables communications between the telematics device102and one or more remote devices such as the telematics cloud server104. Additionally or alternatively, in some embodiments the telematics device102may include integrated communication circuitry capable of network communication, such as the communication subsystem128described above.

The telematics cloud server104is configured to provide firmware updates to the telematics devices102and otherwise perform the functions described herein. As shown, the telematics cloud server104may include or otherwise access a firmware configuration database140, which may store firmware binaries, packages, metadata, and any other data used by the firmware update process. The telematics cloud server104may be embodied as any type of computation or computer device capable of performing the functions described herein, including, without limitation, a server, a rack-mounted server, a blade server, a workstation, a network appliance, a web appliance, a desktop computer, a laptop computer, a tablet computer, a smartphone, a consumer electronic device, a distributed computing system, and/or a multiprocessor system. Additionally, in some embodiments, the telematics cloud server104may be embodied as a “virtual server” formed from multiple computing devices distributed across the network106and operating in a public or private cloud. Accordingly, although the telematics cloud server104is illustrated inFIG.1as embodied as a single computing device, it should be appreciated that the telematics cloud server104may be embodied as multiple devices cooperating together to facilitate the functionality described below. Thus, the telematics cloud server104includes components and devices commonly found in a computer or similar computing device, such as a processor, an I/O subsystem, a memory, a data storage device, and/or communication circuitry. Those individual components of the telematics cloud server104may be similar to the corresponding components of the telematics device102, the description of which is applicable to the corresponding components of the telematics cloud server104and is not repeated herein so as not to obscure the present disclosure.

As discussed in more detail below, the telematics devices102and the telematics cloud server104may be configured to transmit and receive data with each other and/or other devices of the system100over the network106. The network106may be embodied as any number of various wired and/or wireless networks. For example, the network106may be embodied as, or otherwise include, a wired or wireless local area network (LAN), a wired or wireless wide area network (WAN), a cellular network, and/or a publicly-accessible, global network such as the Internet. As such, the network106may include any number of additional devices, such as additional computers, routers, stations, and switches, to facilitate communications among the devices of the system100.

Referring now toFIG.2, in the illustrative embodiment, a telematics device102establishes an environment200during operation. The illustrative environment200includes a server interface202, an update policy engine204, and an update manager214. The various components of the environment200may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the environment200may be embodied as circuitry or a collection of electrical devices (e.g., server interface circuitry202, update policy engine circuitry204, and/or update manager circuitry214). It should be appreciated that, in such embodiments, one or more of those components may form a portion of the processor120, the I/O subsystem122, and/or other components of the telematics device102.

The server interface202is configured to send a status report to the telematics cloud server104. The status report is indicative of a current firmware version of the telematics device102. The server interface202is further configured to receive an acknowledgment from the telematics cloud server104in response to sending the status report, and to determine whether the acknowledgment includes a data payload. The data payload may be indicative of a firmware manifest, a download path, a firmware release version, and a firmware release checksum. As described further below, the firmware manifest is indicative of a firmware name, a firmware version, multiple firmware components, and for each firmware component, a firmware component name, a firmware component version, and a firmware component checksum. In some embodiments, the firmware manifest may be indicative of a base component version, a base image path, and a force install flag for each firmware component.

The update policy engine204is configured to determine whether to upgrade firmware based on the data payload. In some embodiments, determining whether to upgrade firmware based on the data payload includes comparing the firmware release version to the current firmware version of the telematics device102. The update policy engine204is further configured to determine, for each firmware component, whether to upgrade the firmware component in response to downloading the firmware manifest. In some embodiments, determining whether to upgrade each firmware component may include comparing a firmware component version of the firmware manifest to a current firmware component version of the telematics device102.

In some embodiments, determining whether to upgrade each firmware component includes determining whether that firmware component is a base component and, if the firmware component is not a base component, determining whether a base component version of the firmware manifest associated with the first firmware component matches a current firmware component version of the telematics device102. In some embodiments, determining whether to upgrade each firmware component further includes determining whether a base image path associated with the firmware component is included in the firmware manifest if the first firmware component is not a base component. In some embodiments, one or more of those functions may be performed by a sub-component such as a version rule engine206.

In some embodiments, to determine whether to upgrade each firmware component includes determining whether a force install flag associated with the firmware component is set. To determine whether to upgrade the first firmware component may further include evaluating a device policy of the telematics device102if the force install flag is not set. Evaluating the device policy may include determining whether the firmware component is included in a predetermined list of allowed firmware components. In some embodiments, one or more of those functions may be performed by a sub-component, such as a device rule engine208.

In some embodiments, evaluating the device policy includes evaluating an advanced rule to determine whether to allow an update of each firmware component. Evaluating the advanced rule may include evaluating sensor data received from a controller134or a sensor136coupled to the telematics device102, evaluating a processing load of the telematics device102, evaluating a network load of the telematics device102, evaluating driver behavior with the telematics device102, or determining a security priority associated with the firmware component. In some embodiments, evaluating the device policy includes evaluating a machine learning risk model, and may further include updating the machine learning risk model with usage information collected by the telematics device102. In some embodiments, one or more of those functions may be performed by a sub-component such as an advanced rule engine210and/or a risk model212.

The update manager214is configured to download the firmware manifest from the telematics cloud server104in response to determining to upgrade the firmware. The update manager214is further configured to download each firmware component from the associated download path in response to determining to upgrade that firmware component and to then install the firmware component. The update manager214may be further configured to verify that each firmware component checksum of the manifest file matches the corresponding firmware component and to install the firmware component in response to verifying the firmware component checksum. In some embodiments, the update manager214is configured to install each firmware component in response to determining that a corresponding force install flag is set, or to install the firmware component in response to evaluating the device policy. In some embodiments, the update manager214is configured to install each firmware component in response to determining that the base component version associated with the firmware component matches the current firmware component version. In some embodiments, the update manager214is further configured to download a base image from the base image path in response to determining that the base component version associated with the first firmware component does not match the current firmware component version and that the base image path is included in the firmware manifest. The update manager214may be further configured to install the base image in response to downloading the base image, and to install the firmware component in response to installing of the base image.

Still referring toFIG.2, in the illustrative embodiment, the telematics cloud server104establishes an environment220during operation. The illustrative environment220includes a package interface222, a package manager224, a storage manager226, and a device interface228. The various components of the environment220may be embodied as hardware, firmware, software, or a combination thereof. As such, in some embodiments, one or more of the components of the environment220may be embodied as circuitry or a collection of electrical devices (e.g., package interface circuitry222, package manager circuitry224, storage manager circuitry226, and/or device interface circuitry228). It should be appreciated that, in such embodiments, one or more of those components may form a portion of the processor, the I/O subsystem, and/or other components of the telematics cloud server104.

The package interface222is configured to receive a compressed firmware package. The compressed firmware package may be received, for example, from a user such as a developer, vendor, or other producer of an updated firmware package.

The package manager224is configured to decompress the compressed firmware package to generate a manifest file and multiple firmware components. The manifest file is indicative of a firmware name, a firmware version, and, for each of the firmware components, a firmware component name, a firmware component version, and a firmware component checksum. In some embodiments, the package manager224may be further configured to compress each of the firmware components to generate a compressed firmware component.

The storage manager226is configured to store the firmware name, the firmware version, and a firmware checksum in response to decompressing the compressed firmware package. The storage manager226is further configured to store the compressed firmware package and the manifest file. The storage manager226is further configured to store a compressed firmware component based on each firmware component. In some embodiments, the storage manager226may be further configured to store a base version associated with the compressed firmware package for a differential update package. In some embodiments, the storage manager226may be further configured to store a force install flag associated with the compressed firmware package.

The device interface228is configured to receive a status report from a telematics device102. The status report is indicative of a current firmware version of the telematics device102. The device interface228is further configured to determine whether an update is available to the telematics device102based on the status report and the manifest file. Determining whether the update is available to the telematics device102may include, in some embodiments, comparing the current firmware version of the telematics device102to the firmware version of the compressed firmware package, determining whether an update is scheduled for the telematics device102, and/or evaluating a firmware update policy. The device interface228is further configured to send an acknowledgment to the telematics device102in response to determining that the update is available. The acknowledgment is indicative of the firmware version, the firmware checksum, the manifest file, and a download path associated with the firmware components. In some embodiments, sending the acknowledgment may further include sending a security update flag associated with the compressed firmware package or sending a base firmware version and a download path associated with the base firmware version for a differential update package.

Referring now toFIG.3, in use, the telematics cloud server104may execute a method300for processing a compressed firmware package. It should be appreciated that, in some embodiments, the operations of the method300may be performed by one or more components of the environment220of the telematics cloud server104as shown inFIG.2. The method300begins with block302, in which the telematics cloud server104receives a compressed firmware package upload from a user. The compressed firmware package may include an updated firmware release, and may include all firmware components available to remote telematics devices102.

In block304, the telematics cloud server104decompresses the compressed firmware package. Decompressing the firmware package recovers a firmware manifest file and one or more firmware components included in the package. Each of the firmware components may be embodied as an image file, an archive, or another collection of firmware files. The firmware components may be stored in the compressed firmware package as individually compressed components. Each firmware component may include an operating system, bootloader, kernel, application, configuration package, or other component of the firmware release included in the firmware package.

In block306, the telematics cloud server104processes the firmware manifest file received with the compressed firmware package. The firmware manifest describes the firmware package and its included firmware components. Accordingly, the firmware manifest may include a firmware name and firmware version associated with the firmware package. Additionally, the firmware manifest may include, for each firmware component of the firmware package, a firmware component name, a firmware component version, and a firmware component checksum. The telematics cloud server104may store such information from the firmware manifest into the firmware configuration database140or otherwise store that information for use in providing firmware updates to the telematics devices102. In block308, the telematics cloud server104stores the firmware name (e.g., package name), firmware version (e.g., package version), and checksum. In block310, the telematics cloud server104stores the firmware component name, firmware component version, and firmware component checksum for each firmware component of the firmware package.

In some embodiments, in block312, the telematics cloud server104may store base version information for a differential package or component. Differential packages or firmware components, which may also be called diff packages or delta packages, include changes from a previous, base version of the firmware package or firmware component, respectively. Thus, a differential package may have a smaller size than a corresponding base package. However, differential packages may require that a particular base firmware version already be installed on the telematics device102; thus, a differential package may not be used to upgrade from other versions of installed firmware. Additionally, unlike base packages, a differential package may not be used to perform a “clean” install or otherwise install onto a blank device. The telematics cloud server104may store the base version information in any appropriate format, tag, or other data field of the manifest. For example, in the illustrative embodiment, each manifest file includes a base version number tag. Continuing that example, for differential packages, the base version number is different from the version of the firmware package or firmware component, and for base packages (i.e., packages that are not differential packages), the base version number is the same as the version of the firmware package or firmware component.

In some embodiments, in block314the telematics cloud server104may store a force install flag associated with the firmware package and/or the firmware component. As described further below, when the force install flag is set, a telematics device102may install a firmware update regardless of the version of firmware currently installed. The force install flag may be set, for example, in response to a scheduled firmware upgrade, in response to a security update, in response to a manual command from an administrator, or otherwise. In some embodiments, the forced install flag may be an indication of dependencies between separate firmware objects. For example, a certain firmware object may require another object to be upgraded to a minimum version in order to work correctly. Thus, the forced install flag may be used to manage dependencies for such firmware objects. In addition to the forced install flag, and as described further below, each telematics device102may evaluate various device policies in order to determine when a particular update may occur. In response to the forced install flag, a telematics device102may ignore some or all of the device policies depending on the device and the policy set. For example, a telematics device102running on internal battery power may require a certain battery capacity in order to upgrade firmware, and such policy should not be ignored.

In block316, the telematics cloud server104stores the compressed firmware package. The compressed firmware package may be stored with a network storage location, a file server, a web server, or other location that is accessible to the telematics devices102, such as the firmware configuration database140. In particular, the compressed firmware package may be accessible at a download path such as a uniform resource indicator (URI), uniform resource locator (URL), or other network address. As described further below, when upgrading the firmware, a telematics device102may download the compressed firmware package from the download path.

Similarly, in block318the telematics cloud server104stores each compressed firmware component. Each compressed firmware component may be stored with a network storage location, a file server, a web server, or other location that is accessible to the telematics devices102, such as the firmware configuration database140. In particular, each compressed firmware component may be accessible at a download path such as a URI, URL, or other network address that may be determined based on the address of the compressed firmware component. As described further below, when upgrading the firmware, a telematics device102may download one or more of the compressed firmware components from the corresponding download path. After storing each compressed firmware component, the method300loops back to block302, in which the telematics cloud server104may receive additional compressed firmware packages from a user.

Referring now toFIG.4, diagram400illustrates one potential configuration of a compressed firmware package and compressed firmware components that may be stored by the telematics cloud server104. As shown, the telematics cloud server104may establish an update database root folder that contains a compressed firmware package (illustratively named PACKAGE.Z). The update database root folder includes an additional folder with the name of the firmware package (i.e., PACKAGE). That package folder includes the MANIFEST file as well as multiple compressed firmware component files (i.e., COMPONENT_1.Z, COMPONENT_2.Z, etc.). A telematics device102may use a download path associated with the update database root folder and the storage structure shown inFIG.4to construct a URI/URL for the compressed package, the manifest file, and each compressed component. Of course, it should be understood that in other embodiments, the firmware components and/or the firmware package may be stored using any appropriate storage technique and/or organization.

Referring now toFIG.5, in use, the telematics cloud server104may execute a method500for providing firmware updates to a remote telematics device102. It should be appreciated that, in some embodiments, the operations of the method500may be performed by one or more components of the environment220of the telematics cloud server104as shown inFIG.2. The method500begins with block502, in which the telematics cloud server104receives a status report from a telematics device102. The status report includes or is otherwise indicative of a current firmware version of the telematics device102. For example, the status report may indicate a version number for a firmware package or other release installed on the telematics device102and/or may include one or more version numbers for firmware components currently installed on the telematics device102(e.g., operating system, kernel, bootloader, application, or configuration version numbers).

In block504, the telematics cloud server104determines whether to make a firmware update available to the telematics device102based on the received status report. The telematics cloud server104may make the firmware update available in response to evaluating one or more device policies or other rules that indicate when the firmware should be updated. In some embodiments, in block506the telematics cloud server104may compare the firmware version included in the status report to the firmware version stored in an associated manifest file. The telematics cloud server104may update the firmware, for example, if the version included in the manifest file is greater than the version reported in the status report. In some embodiments, the telematics cloud server104may determine whether a firmware update has been scheduled. The firmware update may be scheduled for a particular telematics device102, for all telematics devices102, or otherwise configured. In some embodiments, in block510the telematics cloud server104may evaluate one or more additional firmware update rules. For example, the telematics cloud server104may evaluate a device policy such as a component whitelist or other configuration data. As another example, the telematics cloud server104may evaluate one or more advanced rules based on sensor data received by the telematics data102, driver behavior, risk model outputs, or other data. Those evaluations are similar to advanced rules that may be evaluated by the telematics device102, described further below.

In block512, the telematics cloud server104checks whether to update the firmware. If so, the method500branches to block516, described below. If the telematics cloud server104determines not to update the firmware, the method500branches to block514, in which the telematics cloud server104sends a simple acknowledgment to the telematics device102in response to the status report. After sending the acknowledgment, the method500loops back to block502to continue receiving status reports from telematics devices102.

Referring back to block512, if the telematics cloud server104determines to update the firmware, the method500branches to block516, in which the telematics cloud server104sends an acknowledgment with a data payload to the telematics device102in response to the status update. The data payload includes information that may be used by the telematics device102to locate the updated firmware and determine whether to update the firmware package and/or any of its firmware components. In block518, the telematics cloud server104sends a firmware version, firmware name, and checksum in the data payload. In block520, the telematics cloud server104sends a manifest file name and checksum in the data payload. In block522, the telematics cloud server104sends a download path in the data payload. The download path may identify an update database root folder as shown inFIG.4or otherwise identify the firmware package and/or the firmware components.

In block524the telematics cloud server104sends a base firmware version in the data payload. The base firmware version may identify the compatible base version associated with a differential firmware package and/or differential firmware component For a base firmware package or a base firmware component, the base firmware version included in the data payload matches the firmware version included in the data payload. In some embodiments, in block526the telematics cloud server104may send a download path in the data payload. The download path identifies a network location for a base firmware package of the base version identified in the data payload. As described further below, the telematics device102may download the base firmware package in order to perform a differential upgrade.

In some embodiments, in block528the telematics cloud server104may send a force install flag in the data payload. The force install flag may be evaluated by a version rule engine of the telematics device102. For example, if the available firmware version is the same or lower than firmware currently installed on the telematics device102and the force install flag is set, the telematics device102may download and install the available firmware. Thus, the telematics device102may perform firmware reinstallations, downgrades, or other operations. In some embodiments, in block530the telematics cloud server104may send a priority flag in the data payload. The priority flag may indicate that the firmware update includes a high priority update, such as a correction for a security vulnerability or other security content, a fix for a critical bug, such as a bug that may cause the telematics device102to be inoperable or lose network connectivity, or another critical update. As described further below, the telematics device102may evaluate the data payload including the optional force install flag and/or the optional priority flag using various device policies and/or risk models to determine whether to apply the firmware update. After sending the acknowledgment, the method500loops back to block502to continue receiving status reports from telematics devices102.

Referring now toFIG.6, in use, the telematics device102may execute a method600for updating device firmware. It should be appreciated that, in some embodiments, the operations of the method600may be performed by one or more components of the environment200of the telematics device100as shown inFIG.2. The method600begins with block602, in which the telematics device102sends a status update to the telematics cloud server104. The telematics device102may, for example, send periodic status reports or otherwise continue to send status reports while operational. In some embodiments, in block604the telematics device102may send a current firmware version of the telematics device102. For example, the status report may indicate a version number for a firmware package or other release installed on the telematics device102and/or may include one or more version numbers for firmware components currently installed on the telematics device102(e.g., operating system, kernel, bootloader, application, or configuration version numbers).

In block606, the telematics device102receives an acknowledgment from the telematics cloud server104. In block608, the telematics device102determines whether the acknowledgment includes a data payload. As described above, the acknowledge may be a simple acknowledgment without a data payload, or the acknowledgment may include a data payload including information that may be used to locate updated firmware and to determine whether to update a firmware package and/or any of its firmware components. If the acknowledgment does not include a data payload, the method600loops back to block602to continue sending status reports to the telematics cloud server104. If the acknowledgment includes a data payload, the method600advances to block610.

In block610, the telematics device102determines whether to upgrade based on firmware information included in the data payload. For example, the telematics device102may compare the firmware version included in the data payload to the current firmware version of the telematics device102. Additionally or alternatively, the telematics device102may evaluate one or more device policies, advanced rules, or other rules to determine whether to update firmware as describe below in connection with the methods ofFIGS.7-8andFIG.9.

In block612, the telematics device102checks whether to upgrade the firmware. If not, the method600loops back to block602to continue sending status reports to the telematics cloud server104. If the telematics device102determines to upgrade the firmware, the method600advances to block614.

In block614, the telematics device102downloads the manifest file from the telematics cloud server104and verifies a checksum associated with the manifest file. As described above, the firmware manifest describes a firmware package and its included firmware components. Accordingly, the firmware manifest may include a firmware name and firmware version associated with the firmware package. Additionally, the firmware manifest may include, for each firmware component of the firmware package, a firmware component name, a firmware component version, and a firmware component checksum. The telematics device102may verify a checksum associated with the manifest file in order to ensure that the manifest file has been downloaded correctly and is unaltered.

In block616, the telematics device102determines whether to upgrade each firmware component identified in the firmware manifest. For example, the telematics device102may compare the firmware component version included in the firmware manifest to the current firmware component version of corresponding component installed on the telematics device102. Additionally or alternatively, the telematics device102may evaluate one or more device policies, advanced rules, or other rules to determine whether to update firmware as describe below in connection with the methods ofFIGS.7-8andFIG.9.

In block618, the telematics device102checks whether to upgrade the firmware component. If not, the method600branches ahead to block622, described below. If the telematics device102determines to upgrade the firmware component, the method600advances to block620.

In block620, the telematics device102downloads the firmware component for the upgrade and verifies an associated firmware component checksum. The firmware component checksum may be included, for example, in the firmware manifest as described above. Verifying the checksum may ensure that the firmware component has been downloaded correctly and is unaltered.

In block622, the telematics device102determines whether additional firmware components identified in the firmware manifest remain for processing. If so, the method600loops back to block616to continue determining whether to upgrade each firmware component. If no additional firmware components remain, the method600advances to block624.

In block624, the telematics device102installs any firmware components that were identified for upgrade. The telematics device102may use any appropriate technique to install the downloaded firmware components. Illustratively, the downloaded firmware components may be base components or differential components. In some embodiments, and as described further below, the telematics device102may also download and install an appropriate base component before installing a differential component. After installing the upgraded firmware components, the method600loops back to block602to continue sending status updates to the telematics cloud server104.

Referring now toFIGS.7and8, in use, the telematics device102may execute a method700for processing firmware images. It should be appreciated that, in some embodiments, the operations of the method700may be performed by one or more components of the environment200of the telematics device100as shown inFIG.2. The method700may be executed in connection with determining whether to install a firmware package and/or a firmware component as described above in connection with blocks610,616ofFIG.6. The method700begins with block702, in which the telematics device102determines whether a release image version equals a current firmware version of the telematics device102. The telematics device102may determine, for example, whether the version of a release image received from the telematics cloud server104(e.g., a firmware package version or a firmware component version) equals the version of the currently installed firmware package and/or firmware component as appropriate. In block704, the telematics device102checks whether the release version and the current version are equal. If not (e.g., if the release version is greater than the current version), the method700branches to block712, described below. If the release version equals the current version, the method700branches to block706.

In block706the telematics device102determines whether a force install flag of the firmware manifest is set. The force install flag may be set for the firmware package and/or for each of the firmware components included in the firmware manifest. In block708, the telematics device102checks whether the force install flag is set. If so, the method700branches to block724, described below. If the force install flag is not set, the method700branches to block710, in which the telematics device102determines not to install the release image. After determining not to install the release image, the method700is completed. The telematics device102may execute the method700again, for example to evaluate whether to upgrade additional firmware components.

Referring back to block708, if the force install flag is set, the method700branches to block724, in which the telematics device102determines to install the release image. The installed release image may be a firmware package or a firmware component, and the release image may be a base image or a differential image. As described above, the telematics device102may use any appropriate technique to install the release image. In some embodiments, and as described above in connection withFIG.6, the telematics device102may install one or more downloaded release images after downloading or otherwise processing all available release images. After determining to install the image, the method700is completed. The telematics device102may execute the method700again, for example to evaluate whether to upgrade additional firmware components.

Referring back to block704, if the release version and the current version are not equal, then the method700branches to block712, in which the telematics device102determines whether the release version is a base image. The telematics device102may use any appropriate technique to determine whether the release image is a base image. For example, the telematics device102may determine whether a base version number included in the firmware manifest matches the release version included in the firmware manifest. Continuing that example, for a base image, those versions are equal. For other images (e.g., differential images or delta images), the base version number does not match the release version number. In block714the telematics device102checks whether the release image is a base image. If not (e.g., if the release image is a differential image), the method700branches to block726, shown inFIG.8and described below. If the release image is a base image, the method700branches to block716.

In block716, the telematics device102determines whether a force install flag of the firmware manifest is set. As described above, the force install flag may be set for the firmware package and/or for each of the firmware components included in the firmware manifest. In block718, the telematics device102checks whether the force install flag is set. If so, the method700branches to block724, in which the telematics device102determines to install the release image as descried above. If the force install flag is not set, the method700branches to block720.

In block720, the telematics device102determines whether to upgrade the firmware release based on one or more device policies of the telematics device102. Each device policy may be embodied as any rule that may be evaluated by the telematics device102to determine whether to upgrade the firmware release. The device policies may be configured by an administrator or otherwise deployed to each telematics device102. For example, in an embodiment the telematics device102may determine whether the telematics device102is permitted to allow an upgrade to any release version. If not, the telematics device102may always reject an updated firmware release. As another example, the telematics device102may determine whether a release image is in a list of allowed firmware images and/or versions (e.g., a whitelist). If not included in the list, the telematics device102may reject the updated firmware release. Additionally or alternatively, in some embodiments the telematics device102may evaluate one or more device policies as described below in connection withFIG.9to determine whether to upgrade.

In block722, the telematics device102determines whether to upgrade to the firmware release version. If not, the method700branches to block710, in which the telematics device102determines not to install the release image as described above. If the telematics device102determines to upgrade to the firmware release version, the method700branches to block724, in which the telematics device102determines to install the release image as described above.

Referring back to block714, if the release image not a base image (e.g., if the release image is a differential image), the method700branches to block726, shown inFIG.8. In block726, the telematics device102determines whether the base version for the release image equals a version of the current firmware installed on the telematics device102. If the base version of the release image matches the version of the current firmware, then the release image is compatible with the current firmware and can be installed as a differential upgrade. For example, in some embodiments, the telematics device102may have currently installed both a base firmware and a differential firmware. In that example, the telematics device102may compare the base version of the release image to the version of the currently installed base firmware, and if those versions match, installation of the release image may proceed. Additionally or alternatively, in some embodiments the telematics device102may have installed only a single version of firmware. Continuing that example, the currently installed firmware may be a base firmware or a firmware that has been previously patched or otherwise updated by a differential release. In that example, if the base version of the release image matches the version of the currently installed firmware, the installation of the release image may proceed.

In block728, the telematics device102determines whether the base versions are equal. If so, the method700branches to block716, shown inFIG.7, in which the telematics device102determines whether to install the release image as described above. Referring back to block728, if the base versions of the release image and the current firmware are not equal, then the method700advances to block730.

In block730, the telematics device102determines whether a base image path is included in the firmware manifest. As described above, the base image path may be used by the telematics device102to download a base firmware image that is compatible with the release image. In block732, the telematics device102checks whether the base image path is included in the firmware manifest. If so, the method700branches to block734, described below. If the base image path is not included, the method branches to block748, in which the telematics device102determines not to install the release image, similar to block710described above. After determining not to install the release image, the method700is completed. The telematics device102may execute the method700again, for example to evaluate whether to upgrade additional firmware components.

Referring back to block732, if the base image path is included in the firmware manifest, the method700branches to block734, in which the telematics device102determines whether a force install flag of the firmware manifest is set. As described above, the force install flag may be set for the firmware package and/or for each of the firmware components included in the firmware manifest. In block736, the telematics device102checks whether the force install flag is set. If so, the method700branches to block742, described below. If the force install flag is not set, the method700branches to block738.

In block738, the telematics device102determines whether to upgrade the firmware release based on one or more device policies of the telematics device102. In particular, the telematics device102may evaluate the same policies and/or perform the same evaluations described above in connection with block720. In block740, the telematics device102determines whether to upgrade to the firmware release version. If so, the method700branches to block742, described below. If the telematics device102determines not to upgrade to the firmware release version, the method700branches to block748, in which the telematics device102determines not to install the release image. After determining not to install the release image, the method700is completed. The telematics device102may execute the method700again, for example to evaluate whether to upgrade additional firmware components.

Referring back to block740, if the telematics device102determines to upgrade to the firmware release version, the method700branches to block742, in which the telematics device102downloads a base image from the base image path. The base image may be a firmware package, a firmware component, or other firmware image that is compatible with the release image. In particular, the base version of the release image may match the firmware version of the base image. In block744, the telematics device102installs the base image. As described above, the telematics device102may use any appropriate technique to install the base image. In block746, after installing the base image, the telematics device102determines to install the release image, as described above in connection with block724ofFIG.7. After determining to install the image, the method700is completed. The telematics device102may execute the method700again, for example to evaluate whether to upgrade additional firmware components.

Referring now toFIG.9, in use, the telematics device102may execute a method900for evaluating device update policies. It should be appreciated that, in some embodiments, the operations of the method900may be performed by one or more components of the environment200of the telematics device100as shown inFIG.2. The method900may be executed, for example, in connection with determining whether to install a firmware package and/or a firmware component as described above in connection with blocks610,616ofFIG.6. As another example, the method900may be executed in connection with evaluating device policy as described above in connection with block720ofFIG.7and/or block738ofFIG.8. Additionally or alternatively, although illustrated and described as being executed by the telematics device102, it should be understood that in some embodiments, one or more operations of the method900may be performed by the cloud telematics server104.

The method900begins in block902, in which the telematics device102may evaluate one or more advanced rules from an advanced rule set. Telematics devices102used in data critical applications, such as construction and school bussing, may support resilient configuration management processes such that a high quality of service is maintained. More specifically, the telematics device102may provide there can be no disruption of device operations or data flow during or subsequent to any over-the-air (OTA) queries, reports, programming, or other maintenance actions. Accordingly, the telematics device102may employ an advanced rule set and other features to determine whether to install a firmware release while maintaining high quality of service.

The advanced rule set may be configured by an administrator or otherwise deployed to the telematics device102. Each advanced rule may be evaluated to determine whether to install a firmware release, when to install a firmware release, or otherwise adjust firmware upgrade behavior. In addition to time and operational state rules, the advanced rules may include ECU134or sensor136based rules such as RPM, speed, PTO activity. Also the advanced rules may set conditions based on network bandwidth (e.g., Cat M or 2G status), processor load, temperature extremes, or critical data processing such as accelerometer-based crash active or driver behavior processing These advanced rules may determine the telematics device102's ability to receive, process, and instantiate an updated process or application image or script file (e.g., a firmware package, firmware component or other release). Thus, in some embodiments, in block904the telematics device102may evaluate data from one or more controllers134(e.g., ECUs) or sensors136coupled to the telematics device. In some embodiments, in block906the telematics device102may evaluate load of the processor120. In some embodiments, in block908the telematics device102may evaluate network load, bandwidth consumption, or other network conditions. In some embodiments, in block910the telematics device102may evaluate behavior of a driver of a vehicle130coupled to the telematics device102.

As described above, the advanced rule sets may be conditions established at the cloud telematics server104as well, such as if a telematics device102is determined to be in SVR mode and should restrict any remote, over-the-air (OTA) servicing to give full QoS to geospatial data or SVR beacon activation. Additional advanced rules may be built around Driver ID, I/O status, WLAN client load, or other conditions.

In block912, the telematics device102performs block processing tasks for the firmware package or firmware component. In some embodiments, in block914, the telematics device102may evaluate dependencies between firmware components and/or firmware packages and assemble a downloading sequence plan. Remove, over-the-air actions involving firmware delivery may involve multiple binary or script packages to multiple targets. The telematics device102and/or the telematics cloud server104may build a general OTA process model for sequencing all packages. The sequence may be based on criticality, dependency (e.g., a script is dependent upon an updated firmware image in application processor, so a third-party target device (e.g., a camera, a tag) may require an updated protocol in the application processor before the device's own application update.) As another example, a component update may be performed prior to application processor update. Each functional block may be identified in a downloading sequence plan, and each block would then carry its own advanced rule sets or process conditions. In some embodiments, in block916the telematics device102may reassemble one or more differential components. Block processing maps how a particular binary might be “chunked” into multiple elements, such as with differential or delta upgrades, and how each element/block can be built, transferred, re-assembled or reintegrated into a runtime image. The telematics device102may allow this process to occur at certain times or situations in order to minimize or eliminate potential disruptions. In some embodiments, the block processing may be combined with failsafe upgrade functionality.

In block918, the telematics device102may determine an update prioritization associated with a firmware release. Each firmware release or other update may be assigned a level of priority, for example from highest to lowest. The advanced rule set and/or the machine learning risk model may be used to evaluate the priority of the firmware release against the current state of the telematics device102in order to determine whether to install the firmware release or otherwise to determine best update practice. For example, in some embodiments, an update with a patch for a critical bug that may render the telematics device102inoperable may be flagged as high priority, an update with a patch for a bug that is mis-counting engine hours and thus may incorrectly compute the need for maintenance may be flagged as medium priority, and a standard update with feature updates and non-critical bug fixes may have low or standard priority. In some embodiments, in block920, the telematics device102may flag an immediate install or other high priority for a security critical condition or other security priority. For example, a firmware release that patches a critical security vulnerability may be installed immediately, without waiting for a scheduled status report or other scheduled update.

Thus, a particular condition which may prioritize the OTA download/scheduling/block processing functions would be a recently identified security vulnerability. In device telematics, the telematics cloud server104may inform telematics devices102that a vulnerability has been identified, it is a critical condition (e.g., severity 1), and a patch is ready for download. The advanced rule engine would prioritize this function, perhaps even informing affected telematics devices102that they are to suspend operations immediately to receive and process the patch. This may apply to devices102connected directly to assets such as vehicles130or critical infrastructure. Of course, in some embodiments even a high priority update such as a critical security update may be evaluated with a machine learning risk model or other device policies. For example, a device102operating on internal battery power that does not have sufficient power to apply an update may delay installing a critical security update until connected to main vehicle power.

In block922, the telematics device102may evaluate a machine learning risk model. In some embodiments, in block924the telematics device102may update the risk model with usage information collected by the telematics device102. In some embodiments, the telematics device102may build an active process running within the IoT device environment that monitors all inputs to the advanced rule sets and builds a risk model for managing OTA updates. This can be updated by an algorithm which learns over time the usage profile of a telematics device102and identifies operational states beyond the standard rules which should block or de-prioritize OTA download processing. For example, the risk model may identify time periods in which the telematics device102is typically active with accelerometer and speed processing (e.g., alignment, crash, driver behavior data processing). As another example, the risk model may predict that a rule might be triggered while a download is in process. Continuing that example, an algorithm may process sensor136data to determine that a speed rule may possibly be triggered, or priority accelerometer data processing based on the identified driver (Driver ID input). As yet another example, the risk model may effectively build a simple device database to track states of activity based on time-stamped events/triggers. An advanced rule can be applied to devices known for typical high levels of activity based on this database.

After performing one or more of the evaluations described above, the method900is completed. The computing device102may determine whether to upgrade a firmware component, a firmware package, or other release image based on one or more evaluations performed in connection with the method900.