Patent Description:
A telematics system may gather asset data using a telematics device. The telematics device may be integrated into or located onboard the asset. The asset may be a vehicle ("vehicular asset") or some stationary equipment. The telematics device may collect the asset data from the asset through a data connection with the asset. In the case of a vehicular asset, the telematics device may gather the asset data through an onboard diagnostic port. The gathered asset data may include engine speed, battery voltage, fuel level, tire pressure, oil temperature, or any other asset data available through the diagnostic port. Additionally, the telematics device may gather sensor data pertaining to the asset via sensors on the telematics device. For example, the telematics device may have temperature and pressure sensors, inertial measurement units (IMU), optical sensors, and the like. Furthermore, the telematics device may gather location data pertaining to the asset from a location module on the telematics device. When the telematics device is coupled to the asset, the gathered sensor data and location data pertain to the asset. The gathered asset data, sensor data and location data may be received and recorded by a technical infrastructure of the telematics system, such as a telematics server, and used in the provision of fleet management tools, for telematics services, or for further data analysis. Patent publications <CIT>, <CIT>, and <CIT> discuss information that is useful for understanding the background of the invention. In particular <CIT> discloses a telematics unit in a vehicle that receives an update notification from an update server and outputs an optical signal to the driver, which informs the driver of the update and requests the driver, for the purpose of authorization, to place a portable mobile apparatus in a holder such that NFC communication is established. If NFC communication has been established, the telematics unit receives an identifier from the mobile apparatus and transmits it to the update server.

In one aspect of the present disclosure there is provided a method by an over-the-air (OTA) server according to claim <NUM>.

Completing a firmware update may comprise sending a firmware update to an ECU, and the firmware update may become a primary firmware of the ECU after being downloaded thereto.

Completing a firmware update may comprise sending a firmware activation command to an ECU, and the firmware activation command may cause a secondary firmware on the ECU to start executing.

The method may further comprise receiving the location of the vehicle from a telematics server and receiving the location of the operator terminal from the operator terminal.

The operator terminal may be connected with the telematics device via a wired communications module or a wireless communications module.

The method may further comprise receiving a firmware update request from an Original Equipment Manufacturer (OEM) server including a firmware update and a list of vehicle identifiers and sending the firmware update to the telematics device.

In another aspect of the present disclosure, there is provided an over-the-air (OTA) update server according to claim <NUM>.

In another aspect of the present disclosure, there is provided a non-transitory machine-readable storage medium according to claim <NUM>.

Exemplary non-limiting embodiments of the present invention are described with reference to the accompanying drawings in which:.

A large telematics system may collect data from a high number of assets, either directly or through telematic devices. A telematics device may refer to a self-contained device installed at an asset, or a telematics device that is integrated into the asset itself. In either case, it may be said that data is being captured or gathered by the telematics device. <FIG> shows a high-level block diagram of a telematics system <NUM>. The telematics system <NUM> includes a telematics server <NUM>, (N) telematics devices shown as telematics device 200_1, telematics device 200_2. through telematics device 200_N ("telematics device <NUM>"), a network <NUM>, administration terminals 400_1 and 400_2, and operator terminals 450_1, 450_2. through 450_N ("operator terminals <NUM>"). <FIG> also shows a plurality of (N) assets named as asset 100_1, asset 100_2. asset 100_N ("asset <NUM>") coupled to the telematics devices <NUM>, and a plurality of satellites 700_1, 700_2 and 700_3 ("the satellites <NUM>") in communication with the telematics devices <NUM>.

The assets <NUM> shown are in the form of vehicles. For example, the asset 100_1 is shown as a truck, which may be part of a fleet that delivers goods or provides services. The asset 100_2 is shown as a passenger car that typically runs on an internal combustion engine (ICE). The asset 100_3 is shown as an electric vehicle (EV). While the assets have been shown as vehicles, in some examples they may be airborne vehicles such as airplanes, helicopters, or drones. In other examples, the assets may be marine vehicles such as boats, ships, or submarines. In further examples, the assets may be stationary equipment such as industrial machines.

The telematics devices <NUM> are electronic devices which are coupled to assets <NUM> and configured to capture asset data from the assets <NUM>. For example, in <FIG> the telematics device 200_1 is coupled to the asset 100_1. Similarly, the telematics device 200_2 is coupled to the asset 100_2 and the telematics device 200_3 is coupled to the asset 100_3. The components of a telematics device <NUM> are explained in further detail with reference to <FIG>.

The network <NUM> may be a single network or a combination of networks such as a data cellular network, the Internet, and other network technologies. The network <NUM> may provide connectivity between the telematics devices <NUM> and the telematics server <NUM>, and between the administration terminal <NUM> and the telematics server <NUM>.

The telematics server <NUM> is an electronic device having the capability of storing and analyzing telematics data. The telematics server <NUM> is connected to the network <NUM> and may receive telematics data from the telematics devices <NUM>. The telematics server may have a telematics database <NUM> for storing asset information related to the various assets <NUM>. The asset information stored may include information about the user's currently operating a particular asset <NUM>.

The satellites <NUM> may be part of a global navigation satellite system (GNSS) and may provide location information to the telematics devices <NUM>. The location information may be processed by a location module on the telematics device <NUM> to provide location data indicating the location of the telematics device <NUM> (and hence the location of the asset <NUM> coupled thereto). A telematics device <NUM> that can periodically report an asset's location is often termed an "asset tracking device".

The administration terminal is an electronic device, which may be used to connect to the telematics server <NUM> to retrieve data and analytics related to one or more assets <NUM>. The administration terminal may be a desktop computer, a laptop computer such as the administration terminal <NUM>, a tablet, or a smartphone such as the handheld administration terminal <NUM>. The administration terminal <NUM> may run a web browser or a custom application which allows retrieving data and analytics, pertaining to one or more assets <NUM>, from the telematics server <NUM> via a web interface of the telematics server. The handheld administration terminal <NUM> may run a mobile application for communicating with the telematics server <NUM>, the mobile application allowing retrieving data and analytics therefrom. A fleet manager <NUM> may communicate with the telematics server <NUM> using the administration terminal <NUM> or the handheld administration terminal <NUM>. In addition to retrieving data and analytics, the administration terminal allows the fleet manager <NUM> to set alerts and geofences for keeping track of the assets <NUM>, receiving notifications of deliveries, and so on.

The operator terminals <NUM> are electronic devices, such as smartphones or tablets. The operator terminals <NUM> are used by operators <NUM> (for example, vehicle drivers) of the assets <NUM> to both track and configure the usage of assets in a group of assets. For example, as shown in <FIG>, the operator 10_1 has the operator terminal 450_1, the operator 10_2 has the operator terminal 450_2, and the operator 10_N has the operator terminal 450_N. Assuming the operators <NUM> all belong to a fleet of vehicles, each of the operators <NUM> may operate any of the vehicle assets <NUM>. For example, <FIG> shows that the operator 10_1 is associated with the asset 100_1, the operator 10_2 is associated with the asset 100_2, and the operator 10_N is associated with the asset 100_N. However, any operator <NUM> may operate any asset <NUM> within a particular group of assets, such as a fleet. The operator terminals <NUM> are in communication with the telematics server <NUM> over the network <NUM>. The operator terminals <NUM> may run at least one asset configuration application. The asset configuration application may be used by an operator <NUM> to inform the telematics server of the asset <NUM> the operator <NUM> is currently operating. For example, the operator 10_2 may use an asset configuration application on the operator terminal 450_2 to indicate that the operator 10_2 is currently using the asset 100_2. The telematics server <NUM> updates the telematics database <NUM> to indicate that the asset 100_2 is currently associated with the operator 10_2. Additionally, the asset configuration application may be used to report information related to the operation duration of the vehicle, the number of stops made by the operator during their working shift, and so on.

In operation, a telematics device <NUM> is coupled to an asset <NUM> to capture asset data. The asset data may be combined with location data obtained by the telematics device <NUM> from a location module in communication with the satellites <NUM> and/or sensor data gathered from sensors in the telematics device <NUM>. The combined data may be termed "telematics data". The telematics device <NUM> sends the telematics data, to the telematics server <NUM> over the network <NUM>. The telematics server <NUM> may process, aggregate, and analyze the telematics data to generate information about the assets <NUM> or a fleet of assets. The administration terminal <NUM> may connect to the telematics server <NUM>, over the network <NUM>, to access the generated information. Alternatively, the telematics server <NUM> may push the generated information to the administration terminal <NUM>. Additionally, the operators <NUM>, using their operator terminals <NUM>, may indicate to the telematics server <NUM> which assets <NUM> they are associated with. The telematics server <NUM> updates the asset database accordingly. Furthermore, the telematics server <NUM> may provide additional analytics related to the asset operators including work time, location, and operating parameters. For example, for vehicle assets, the telematics data may include turning, speeding, and braking information. The telematics server <NUM> can correlate the telematics data to the vehicle's driver by querying the asset database <NUM>. A fleet manager <NUM> may use the administration terminal to set alerts for certain activities pertaining to the assets <NUM>. When criteria for an alert is met, the telematics server <NUM> sends a message to the fleet manager's administration terminal.

In the attached figures, a telematics device <NUM> is shown as a separate entity connected with a corresponding asset. It would be, however, apparent to those of skill in the art that other configurations are possible. For example, the telematics device <NUM> may be integrated with the asset <NUM> at the time of manufacturing. In other examples, the telematics device <NUM> may be deployed on an asset but not connected therewith. For example, a telematics device <NUM> may be deployed in a vehicular asset and may monitor the vehicle's engine temperature, location, speed, and direction of travel solely using sensors or peripherals on board the telematics device <NUM> such as a temperature sensor, a GPS receiver, an accelerometer, and a gyroscope.

Further details relating to the telematics device <NUM> and how it interfaces with an asset <NUM> are shown with reference to <FIG> depicts an asset <NUM> and a telematics device <NUM> connected thereto. Selected relevant components of each of the asset <NUM> and the telematics device <NUM> are shown. For example, while the asset <NUM> may be a vehicular asset, only components relevant to gathering asset data are shown in <FIG>.

The asset <NUM> may have a plurality of electronic control units (ECUs). An ECU is an electronic module which interfaces with one or more sensors for gathering information from the asset <NUM>. For example, an oil temperature ECU may contain a temperature sensor and a controller for converting the measured temperature into digital data representative of the oil temperature. Similarly, a battery voltage ECU may contain a voltage sensor for measuring the voltage at the positive battery terminal and a controller for converting the measured voltage into digital data representative of the battery voltage. A typical vehicle may, for example, have around seventy ECUs. For simplicity, only a few of the ECUs <NUM> are depicted in <FIG>. For example, in the depicted embodiment the asset <NUM> has three electronic control units: ECU 110A, ECU 110B, and ECU 110C ("ECUs <NUM>"). The ECU 110A, the ECU 110B, and the ECU 110C are shown to be interconnected via a bus, such as a Controller Area Network (CAN) bus <NUM>. ECUs <NUM> interconnected using a CAN bus send and receive information to one another in CAN frames by placing the information on the CAN bus <NUM>. When an ECU places information on the CAN bus <NUM>, other ECUs <NUM> receive the information and may or may not consume or use that information. Different protocols are used to exchange information between the ECUs over a CAN bus. For example, ECUs <NUM> in trucks and heavy vehicles use the Society of Automotive Engineering (SAE) J1939 protocol to exchange information over a CAN bus <NUM>. Most passenger vehicles use the On-Board Diagnostic (OBD) protocol to exchange information between ECUs <NUM> on their CAN bus <NUM>. In industrial automation, ECUs use a CANOpen protocol to exchange information over a CAN bus <NUM>. An asset <NUM> may allow access to information exchanged over the CAN bus <NUM> via an interface port <NUM>. For example, if the asset <NUM> is a passenger car, then the interface port <NUM> is most likely an OBD-II port. Data accessible through the interface port <NUM> is termed the asset data <NUM>. In some embodiments, the interface port <NUM> includes a power interface for providing power to a device connecting thereto.

The telematics device <NUM> includes a controller <NUM> coupled to a memory <NUM>, an interface layer <NUM> and a network interface <NUM>. The telematics device <NUM> also includes one or more sensors <NUM> and a location module <NUM> coupled to the interface layer <NUM>, a near-field communications (NFC) module <NUM>, a short-range wireless communications module <NUM>, and a wired communications module such as a serial communications module <NUM>. In some embodiments (not shown), the telematics device <NUM> may have a dedicated power source or a battery. In other embodiments, the telematics device <NUM> may receive power directly from the asset <NUM>. The telematics device <NUM> shown is an example. Some of the depicted components may be optional and are depicted in dashed lines. For example, some telematics devices may not have a location module <NUM> and may rely on an external location module for obtaining location data. Some telematics devices may not have any sensors <NUM> and may rely on external sensors for obtaining sensor data. Some telematics devices <NUM> may not have an NFC module <NUM> or a short-range wireless communications module <NUM>.

The controller <NUM> may include one or any combination of a processor, microprocessor, microcontroller (MCU), central processing unit (CPU), processing core, state machine, logic gate array, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or similar, capable of executing, whether by software, hardware, firmware, or a combination of such, the actions performed by the controller <NUM> as described herein.

The memory <NUM> may include read-only-memory (ROM), random access memory (RAM), flash memory, magnetic storage, optical storage, and similar, or any combination thereof, for storing machine-executable programming instructions and data to support the functionality described herein. The memory <NUM> is coupled to the controller <NUM> thus enabling the controller <NUM> to execute the machine-executable programming instructions stored in the memory <NUM>. The memory <NUM> may contain machine-executable programming instructions, which when executed by the controller <NUM>, configures the telematics device <NUM> for receiving asset data <NUM> from the asset <NUM> via the asset interface <NUM>, and for receiving sensor data from the sensors <NUM> and/or location data from the location module <NUM> via the sensor interface <NUM>. The memory <NUM> may also contain machine-executable programming instructions for combining asset data <NUM>, sensor data and location data into telematics data <NUM>. Additionally, the memory <NUM> may further contain instructions which, when executed by the controller <NUM>, configures the telematics device <NUM> to transmit the telematics data <NUM> via the network interface <NUM> to a telematics server <NUM> over a network <NUM>.

The location module <NUM> may be a global positioning system (GPS) transceiver or another type of location determination peripheral that may use, for example, wireless network information for location determination. The sensors <NUM> may be one or more of: a temperature sensor, a pressure sensor, an optical sensor, an accelerometer, a gyroscope, or any other suitable sensor indicating a condition pertaining to the asset <NUM> to which the telematics device <NUM> is coupled.

The interface layer <NUM> includes an asset interface <NUM> and a sensor interface <NUM>. The sensor interface <NUM> is configured for receiving sensor data and location data from the sensors <NUM> and the location module <NUM>, respectively. For example, the sensor interface <NUM> interfaces with the location module <NUM> and with the sensors <NUM> and receives both sensor data and location data, respectively, therefrom. The interface layer <NUM> also includes an asset interface <NUM> to receive asset data <NUM> from the asset <NUM>. In the depicted embodiment, the asset interface <NUM> is coupled to the interface port <NUM> of the asset <NUM>. In other embodiments where the telematics device <NUM> is integrated into the asset <NUM>, the asset interface <NUM> may receive the asset data <NUM> directly from the CAN bus <NUM>. The asset data <NUM>, received at the telematics device <NUM>, from the asset <NUM> may be in the form of data messages, such as CAN frames. Asset data <NUM> may describe one or more of any of: a property, a state, and an operating condition of the asset <NUM>. For example, where the asset <NUM> is a vehicle, the data may describe the speed at which the vehicle is travelling, a state of the vehicle (off, idle, or running), or an engine operating condition (e.g., engine oil temperature, engine RPM, or a battery voltage). In addition to receiving the asset data <NUM>, in some embodiments the asset interface <NUM> may also receive power from the asset <NUM> via the interface port <NUM>. The interface layer <NUM> is coupled to the controller <NUM> and provides the asset data <NUM>, sensor data, and location data to the controller <NUM>.

The network interface <NUM> may include a cellular modem, such as an LTE-M modem, CAT-M modem, other cellular modem, Wi-Fi modem, or any other communication device configured for communication via the network <NUM> with which to communicate with the telematics server <NUM>. The network interface <NUM> may be used to transmit telematics data <NUM> obtained from the asset <NUM> to the telematics server <NUM> for a telematics service or other purposes. The network interface <NUM> may also be used to receive instructions from the telematics server <NUM> as to how to communicate with the asset <NUM>.

The NFC module <NUM> may be an NFC reader which can read information stored on an NFC tag. The NFC module <NUM> is used to confirm the identity of the operator <NUM> by having the operator <NUM> tap an NFC tag onto the telematics device <NUM> such that the NFC tag is read by the NFC module <NUM>. The read information from the NFC tag may be included in the telematics data <NUM> sent by the telematics device <NUM> to the telematics server <NUM>.

The short-range wireless communications module <NUM> is a component intended for providing short-range communication capability to the telematics device <NUM>. The short-range wireless communications module <NUM> may be a Bluetooth™. wireless fidelity (Wi-Fi), Zigbee™, or any other short-range communications module. The short-range wireless communications module <NUM> allows other devices to communicate with the telematics device <NUM> over a short-range wireless network.

The serial communications module <NUM> is an example of a wired communications module. The serial communications module <NUM> is an electronic peripheral for providing standard serial wired communications to the telematics device <NUM>. For example, the serial communications module <NUM> may include a universal asynchronous receiver transmitter (UART) providing serial communications per the RS-<NUM> protocol. Alternatively, the serial communications module <NUM> may be a serial peripheral interface (SPI) bus, or an inter-integrated circuit (I<NUM>C) bus. As another example, the serial communications module <NUM> may include a universal serial bus (USB) transceiver.

In operation, an ECU <NUM>, such as the ECU 110A, the ECU 110B, or the ECU 110C communicates asset data over the CAN bus <NUM>. The asset data exchanged between the ECUs <NUM>, over the CAN bus <NUM> are accessible via the interface port <NUM> and may be retrieved as the asset data <NUM> by the telematics device <NUM>. The controller <NUM> of the telematics device <NUM> receives the asset data <NUM> via the asset interface <NUM>. The controller <NUM> may also receive sensor data from the sensor <NUM> and/or location data from the location module <NUM> over the sensor interface <NUM>. The controller <NUM> combines the asset data <NUM> with the sensor data and the location data to provide the telematics data <NUM>. The controller <NUM> transmits the telematics data <NUM> to the telematics server <NUM> over the network <NUM> via the network interface <NUM>. The telematics server <NUM> may perform data analytics on the telematics data <NUM>. A fleet manager may use the administration terminal <NUM> or the handheld administration terminal <NUM> to run reports or gather information from the telematics server <NUM>. An asset operator taps an NFC tag to the NFC module <NUM> to identify themself as the operator of the asset <NUM>. Additionally, an external peripheral, such as a GPS receiver, may connect with the telematics device <NUM> via the short-range wireless communications module <NUM> for providing location information thereto.

While asset data <NUM> gathered from the asset <NUM> combined with data obtained from the sensors <NUM> and the location module <NUM> may be used to derive useful data and analytics, there are times when additional data, which is not provided by the asset <NUM> or the peripherals on board the telematics device <NUM>, may be needed. The telematics device <NUM> may have a limited number of sensors <NUM> such as accelerometers or gyroscopes providing limited information about the motion of the asset <NUM> on which the telematics device <NUM> is deployed. The location module <NUM> may provide location and direction information. However, in some cases, more information may be needed to derive useful data and analytics pertaining to the asset <NUM>. One example of information that is not typically provided by the telematics device <NUM> is video capture data. Another example of information that is not typically provided by the telematics device <NUM> is any proprietary signaling provided by devices which does not follow any of the standard protocols (OBD-II, J1939 or CANOpen). Some equipment may not have a CAN bus and may provide proprietary digital and/or analog signals. Examples of such devices include industrial equipment, winter maintenance equipment such as salt spreaders, farming equipment, and the like. Additionally, the telematics device <NUM> may not have an NFC module <NUM> or a short-range wireless communications module <NUM> thus limiting its connectivity features.

To capture and provide information not provided by the asset <NUM> or the telematics device <NUM>; to produce an output, or to perform an action, which is not supported by the telematics device <NUM>, the telematics device <NUM> may be modified to allow an input/output expander device ("I/O expander") to connect thereto, as shown in <FIG>. The I/O expander <NUM> may be an input device configured to capture additional data such as video frames, audio frames, or proprietary signals and provide that data to the telematics device <NUM>. Alternatively, or additionally, the I/O expander <NUM> may be configured as an output device and may include a display for displaying information and/or an audio output device for broadcasting messages pertaining to the asset <NUM>.

The I/O expander <NUM> of <FIG> is an example I/O expander which is designed to provide additional connectivity options to a telematics device <NUM>. For example, the telematics device <NUM> shown in <FIG> does not have an NFC module, a short-range communications module, or a serial communications module. Instead, the telematics device <NUM> has an I/O expander interface <NUM>.

<FIG> depicts an asset <NUM>, a telematics device <NUM> coupled to the asset <NUM>, and an I/O expander <NUM> coupled to the telematics device <NUM>. The asset <NUM> is similar to the asset <NUM> of <FIG> and therefore the internal components thereof are not shown in <FIG> for simplicity. The telematics device <NUM> has a somewhat similar configuration as the telematics device <NUM> of <FIG> but adds an I/O expander interface <NUM> for interfacing with the I/O expander <NUM>. The I/O expander interface <NUM> is coupled to the controller <NUM> and may be configured for exchanging I/O expander data <NUM> with the I/O expander <NUM>.

An I/O expander <NUM>, which connects with the telematics device <NUM>, varies in complexity depending on the purpose thereof. <FIG> shows an I/O expander <NUM> containing several components which may or may not all be present in other I/O expanders. For example, the I/O expander <NUM> includes a controller <NUM>, an NFC module <NUM>, an output device <NUM>, a short-range communications module <NUM>, a serial communications module <NUM>, an uplink interface <NUM> and a downlink interface <NUM>.

The controller <NUM> may be similar to the controller <NUM>. In some embodiments, the controller <NUM> is a microcontroller with versatile I/O capabilities. For example, the controller <NUM> may be a microcontroller which has a plurality of I/O ports such as general-purpose inputs and outputs (GPIOs), serial ports, analog inputs, and the like. In some embodiments, the controller <NUM> may have built-in persistent memory such as flash memory on which machine-executable programming instructions for carrying out the functionality of the I/O expander <NUM> may be stored. In other embodiments, the controller <NUM> may be coupled to a persistent memory module (not shown) that contains the machine-executable programming instructions for carrying out the functionality of the I/O expander <NUM>. The controller <NUM> may also have built-in volatile memory, such as random-access memory (RAM) for storing data. Alternatively, the I/O expander <NUM> may be connected to an external volatile memory for storing data. The controller <NUM> may execute the machine-executable programming instructions stored in the persistent memory to carry out the functionality of the I/O expander <NUM>.

The uplink interface <NUM> is an electronic peripheral interface coupled to the controller <NUM> and is used to provide data exchange and/or power capabilities to the I/O expander <NUM>. The uplink interface <NUM> allows the I/O expander <NUM> to transmit and receive I/O expander data. The uplink interface <NUM> is configured to use the same protocol and signaling as the I/O expander interface <NUM> of the telematics device <NUM>. Accordingly, the I/O expander <NUM> may exchange the I/O expander data with the telematics device <NUM>. In some embodiments, the uplink interface <NUM> may also include power pins connected to corresponding power pins in the I/O expander interface <NUM>, thus allowing the I/O expander <NUM> to be powered via the telematics device <NUM>. In other embodiments (not shown), the I/O expander <NUM> may have its own power source instead of or in addition to the power provided by the telematics device <NUM> via the uplink interface <NUM>.

The downlink interface <NUM> is an electronic peripheral interface coupled to the uplink interface <NUM>. The downlink interface <NUM> is configured to interface with the uplink interface <NUM> of another I/O expander <NUM> (as will be described below). Allowing the uplink interface <NUM> to connect to the downlink interface <NUM> of another I/O expander <NUM> allows the daisy chaining of I/O expanders <NUM>.

An ECU <NUM> may belong to one of many types. For example, an ECU may be an engine control module (ECM), a powertrain control module (PCM), a transmission control module (TCM), and so on. Accordingly, some ECUs are associated with other subsystems of a vehicle asset. For example, an ECM is associated and is generally provided by the original equipment manufacturer (OEM) of a vehicle's engine. An ECU typically contains a controller, memory, a bus interface and one or more sensor/control interface. A simplified representation of an ECU <NUM> is shown in <FIG> and <FIG>.

In the above-mentioned figures, a telematics device is shown as a separate entity connected with a corresponding asset. The telematics device, however, may have its components integrated into the asset <NUM> at the time of manufacture of the asset <NUM>. This may be the case when the asset <NUM> is a connected car having an asset network interface. For example, with reference to <FIG>, there is shown an asset <NUM>' with the components of a telematics device integrated therein, in accordance with embodiments of the present disclosure. The asset <NUM>' is similar to the asset <NUM> but, being a connected asset such as a connected car, it has an asset network interface <NUM> built into it. In the depicted embodiment, the telematics device controller <NUM> is directly connected to the asset communications bus, which is a CAN bus <NUM> and may directly obtain the asset data <NUM> therefrom. The sensors <NUM> and the location module <NUM> are also integrated into the asset <NUM> and provide the sensor data and the location data to the telematics device controller <NUM> as described above. The asset network interface <NUM> belongs to the asset <NUM>' and may be used by the asset <NUM> to communicate with an original equipment manufacturer (OEM) server, to a roadside assistance server, or for other purposes. The telematics device controller <NUM> may utilize the asset network interface <NUM> for the transmission of telematics data <NUM> provided by the telematics device controller <NUM>. In order to support gathering data types not provided by the integrated peripherals such as the sensors <NUM> and the location module <NUM>, the asset <NUM>' has an I/O expander interface <NUM> coupled to the telematics device controller <NUM> so that an I/O expander <NUM> may be connected to the asset <NUM>' therethrough. The asset <NUM>' may have an interface port <NUM> for connecting other devices other than a telematics device <NUM>, such as a diagnostic tool including, but not limited to, an OBD-II reader device.

First with reference to <FIG>, a block diagram of an ECU 110A is shown. The ECU 110A is comprised of a controller <NUM>, a memory <NUM>, a bus interface <NUM>, and a sensor/control interface <NUM>.

The controller <NUM> is similar to the controller <NUM> described above. The controller <NUM> executes machine-executable programming instructions stored in the memory <NUM>.

The bus interface <NUM> is a hardware peripheral which connects the ECU 110A to a vehicle bus, such as the CAN bus <NUM>. Asset data exchanged over the CAN bus <NUM> can be accessed by the ECU 110A over the bus interface <NUM>.

The sensor/control interface <NUM> connects the ECU 110A to one or more sensors and/or hardware subsystems. For example, the ECU 110A may report the engine temperature in which case the sensor/control interface <NUM> may connect the ECU 110A to a temperature sensor. Output signals generated by the sensor are available as input signals on the sensor/control interface <NUM>. As another example, the ECUA may control a hardware subsystem such as the headlights. In which case the sensor/control interface <NUM> may interface to an electronic relay or similar device for actuating the hardware subsystem. The ECU 110A outputs signals on the sensor/control interface <NUM> for controlling the hardware subsystem connected to the sensor/control interface <NUM>.

The memory <NUM> stores a number of software modules each comprised of a plurality of machine-executable programming instructions. In the depicted embodiment, the memory <NUM> stores a boot loader <NUM>, a firmware download module <NUM>, and a primary firmware <NUM>.

The primary firmware <NUM> performs the main functions of the ECU 110A. For example, if the ECU 110A mainly obtains information from sensors, the primary firmware <NUM> may interpret input signals received from one or more sensors, over the sensor/control interface <NUM>. If the ECU 110A controls a hardware subsystem in the vehicle, then the primary firmware <NUM> generates output signals on the sensor/control interface <NUM> for controlling the hardware subsystem connected thereto. A firmware update may be used to add additional functions to the ECU 110A, enhance its performance, or fix problems.

The boot loader <NUM> is the first module that is executed by the controller <NUM> when the ECU 110A is powered-up. The boot loader <NUM> causes the controller <NUM> to execute the primary firmware <NUM>.

The firmware download module <NUM> downloads the new versions of the firmware (i.e., firmware updates). The firmware download module <NUM> stores the firmware update as the primary firmware <NUM>, and causes the ECU 110A to be rebooted so that the boot loader <NUM> causes the controller <NUM> to execute the firmware update (now stored as the primary firmware <NUM>).

In operation, when the ECU 110A is powered up the controller <NUM> executes the boot loader <NUM>. The boot loader <NUM> starts executing the primary firmware <NUM>. The primary firmware <NUM> may detect an indication that a new firmware update is available for download. The indication that a new version of the firmware is available for download may be a byte pattern or a packet with a particular type received over the bus interface <NUM>. In response to detecting the indication, the primary firmware <NUM> may invoke the firmware download module <NUM>. The firmware download module <NUM> may start downloading the new firmware into the memory <NUM> replacing the primary firmware <NUM>. At the end of the firmware update download, the firmware download module <NUM> causes the ECU 110A to be reset (rebooted). Upon resetting, the controller <NUM> executes the boot loader <NUM> which, in turn, executes the primary firmware <NUM> which has been updated with the new firmware update.

<FIG> depicts another example of an ECU 110B having both a primary firmware <NUM> and a secondary firmware <NUM> placeholders in the memory <NUM> thereof. The secondary firmware <NUM> is similar to the primary firmware <NUM> but is a placeholder for testing a new version of the firmware such as a firmware update.

The firmware download module <NUM> downloads the new versions of the firmware and stores the newly downloaded versions of the firmware into the secondary firmware <NUM>. The firmware download module <NUM> may also set a flag indicating whether the primary firmware <NUM> or the secondary firmware <NUM> should run by default, may check for an indication that the newly downloaded firmware should be the default firmware, and may replace the primary firmware <NUM> with the secondary firmware <NUM> as will be explained below.

In operation, when the ECU 110B is powered up the controller <NUM> executes the boot loader <NUM>. In some embodiments, the boot loader checks a new firmware flag. The new firmware flag indicates whether new firmware has been downloaded as the secondary firmware <NUM>. If the new firmware flag is set, the boot loader <NUM> may start executing the secondary firmware <NUM>. If the new firmware flag is not set, the boot loader <NUM> may start executing the primary firmware <NUM>. As discussed above, the primary firmware <NUM> may detect an indication that a new version of the firmware is available for download and invoke the firmware download module <NUM>. The firmware download module <NUM> may start downloading the firmware update and store the firmware update as the secondary firmware <NUM>. The ECU 110B continues to execute the primary firmware <NUM> until the new firmware is activated. The firmware download module <NUM> may monitor the bus interface <NUM> waiting for an activation command of the newly downloaded firmware. In some embodiments, in response to receiving an activation command on the bus interface <NUM>, the firmware download module <NUM> sets a new firmware flag indicating that the newly downloaded firmware stored as the secondary firmware <NUM> should be activated. In some embodiments, upon receipt of the firmware activation command, the firmware download module <NUM> may trigger a power cycling or reset (reboot) of the ECU 110B.

On power-up or reset of the ECU 110B, the boot loader <NUM> checks the new firmware flag and determines that a new firmware has been downloaded as the secondary firmware <NUM>. In response to determining that a new firmware has been downloaded as the secondary firmware, the boot loader <NUM> executes the secondary firmware <NUM>. In some embodiments, the secondary firmware <NUM>, during execution, checks for an indication or a command that indicates whether the secondary firmware <NUM> should become the primary firmware <NUM>. For example, when a new firmware is downloaded and stored as the secondary firmware <NUM>, the ECU 110B may be tested in this mode. If it is determined that the secondary firmware <NUM> is working properly, a command may be sent to the ECU 110B to make the secondary firmware <NUM> the primary firmware <NUM>. In response to receiving the command, secondary firmware <NUM> transfers control to the firmware download module <NUM> along with an indication that the secondary firmware <NUM> has been verified and is to become the primary firmware <NUM>. In some embodiments, in response to receiving the indication, the firmware download module <NUM> copies the secondary firmware <NUM> onto the primary firmware <NUM>, clears the new firmware flag, and resets the ECU. In other embodiments, the secondary firmware <NUM> becomes the default firmware and a new firmware update is downloaded as the primary firmware <NUM>.

When the ECU 110B is reset, the boot loader <NUM> determines that the new firmware flag is clear and executes the primary firmware <NUM>. The placeholder for the secondary firmware <NUM> is available for downloading a new firmware update in the future.

Updating the ECUs <NUM> in a vehicle may be done by a handheld firmware programming unit. For example, a firmware programming unit <NUM> is shown in <FIG> connected to an interface port <NUM> of an asset <NUM> for providing firmware update to the ECUs of the asset <NUM>. The firmware programming unit includes a controller <NUM>, a memory <NUM>, and an asset interface <NUM>.

The controller <NUM> may be similar to the controller <NUM>, the asset interface <NUM> is similar to the asset interface <NUM> of the telematics device <NUM>, and the memory <NUM> is similar to the memory <NUM> of the telematics device <NUM>. The memory <NUM> contains a firmware update module <NUM> which includes machine-executable programming instructions which, when executed by the controller <NUM>, configure the firmware programming unit <NUM> to upload a firmware update <NUM> for one or more of the ECUs <NUM> of the asset <NUM>. For example, the memory <NUM> contains Firmware A for ECU 110A, Firmware B for the ECU 110B, and Firmware C for ECU 110C. The firmware programming unit <NUM> may upload the Firmware A, Firmware B, and/or Firmware C over the asset interface <NUM> for programming the ECUs 110A, 110B and 110C, respectively. Each firmware update <NUM> may be encapsulated in at least one packet or frame including a header identifying the ECU to which the respective firmware is to be uploaded. The firmware programming unit <NUM> is also configured to allow sending an activation command to an ECU which causes the ECU to execute the newly downloaded firmware as its default firmware.

While updating ECU firmware in a vehicle using a firmware programming unit <NUM> is possible, the process has many problems. For starters, the firmware programming unit <NUM> needs to be loaded with firmware for different ECUs. Additionally, OEMs determine when firmware in their respective ECUs need to be updated. Different OEMs will send firmware updates for their respective ECUs at different time thus requiring that vehicles be updated a number of times making the use of a firmware programming unit <NUM> tedious. A fleet of vehicles would need to repeat the firmware update process for all vehicles in the fleet which is a laborious process.

The telematics system <NUM> shown in <FIG> presents a suitable solution for updating vehicle ECUs in a seamless manner. <FIG> shows a modified telematics system <NUM> in which an OEM server <NUM> and an OTA update server <NUM> have been integrated into the telematics system <NUM> for providing firmware updates to their respective ECUs.

The telematics system <NUM> is similar to the telematics system <NUM> of <FIG> in some respects and therefore some of the components will not be described again in detail.

The OEM server <NUM> is operated by an OEM that manufactures ECUs and holds firmware updates for one or more ECU types deployed in the field. The OEM server <NUM> includes or is coupled to an OEM database <NUM>. The OEM database <NUM> keeps track of the different types of ECUs made by the OEM and whether firmware updates are available for each of the ECU types. The OEM server <NUM> is accessible by a fleet manager <NUM> via the administration terminal <NUM> or the handheld administration terminal <NUM>. Additionally, the OEM server <NUM> may include a web portal which is accessible from any web browser. The OEM server <NUM> may receive requests from a fleet manager <NUM> to receive firmware updates for ECUs deployed in a fleet's assets <NUM>. The OEM server <NUM> may prepare the firmware updates for the respective ECUs and send them to another server, such as the OTA update server <NUM>, for delivery to the respective assets <NUM>, as will be described below.

The OTA update server <NUM> may be operated by the same entity as the telematics server <NUM>, namely a telematics and asset tracking solutions provider. The OTA update server <NUM> is in communication with the OEM server <NUM> for receiving firmware updates for various ECUs. The OTA update server <NUM> is also in communication with a plurality of telematics devices <NUM> deployed in a plurality of assets <NUM>. Accordingly, the OTA update server <NUM> may send ECU firmware updates received from the OEM server <NUM> to a plurality of telematics devices <NUM> for downloading into the ECUs of the respective assets <NUM> to which the telematics devices <NUM> are connected.

While <FIG> shows the telematics server <NUM> and the OTA update server <NUM> as separate servers, they may be integrated into a single server. For example, the OTA update functionality may be built into the telematics server <NUM> and the database <NUM> may be accessible from the telematics server <NUM>.

The telematics system <NUM> of <FIG> can be used to provide ECU firmware updates to one or more vehicle assets <NUM> belonging to a fleet of vehicle assets. In order to receive ECU firmware updates, a fleet manager <NUM> may first register with an OEM that manufactures vehicle components and request to receive ECU firmware updates for the ECUs of the vehicle components made by the OEM. For example, an engine manufacturer may receive a request from a customer, such as a fleet owner or a fleet manager, to receive updates of firmware for Engine Control Modules (ECMs) made by the OEM. AN ECM is a type of ECU specific to engine control. The OEM can utilize the telematics system <NUM> to deliver the ECU (in this case ECM) firmware update to the respective vehicles as will be described below. First, a registration process <NUM> described in <FIG> is carried out.

<FIG> outlines the exchanges between a customer terminal <NUM>, and an OEM server <NUM> for registering a customer's vehicles for firmware updates with the OEM. The OEM server <NUM> has been discussed above. The customer terminal <NUM> may, for example, be the administration terminal <NUM> or the handheld administration terminal <NUM>.

At step <NUM> a customer that owns one or more vehicles sends a firmware update registration request from the customer terminal <NUM> to the OEM server <NUM>. The OEM server <NUM> receives the firmware update registration request. In some embodiments, the firmware update registration request of step <NUM> identifies the update server (e.g., the OTA update server <NUM>) of the telematics provider that the customer is using for their vehicle. An exemplary firmware update registration request <NUM> is shown in <FIG>. The firmware update registration request <NUM> includes a type <NUM>, an update server identifier <NUM>, and a vehicle identifier <NUM>.

The type <NUM> is set to FIRMUPD_REG_REQ indicating to the OEM server <NUM> that the customer wishes to register for firmware updates for the vehicle specified by the vehicle identifier <NUM>.

The update server identifier <NUM> specifies the server which can receive firmware updates from the OEM server <NUM> and can send the firmware updates to the respective ECUs as described further below. The update server identifier <NUM> may be a Universal Resource Locator (URL), an Internet Protocol (IP) address, or any other suitable identifier that allows the OEM server <NUM> to communicate therewith. In some embodiments, the update server identifier <NUM> may refer to the telematics server <NUM> to which a telematics device <NUM> deployed in the vehicle designated by the vehicle identifier <NUM> is connected. As discussed above, in some embodiments, the OTA update server <NUM> may be integrated into the telematics server <NUM>. In other embodiments, the telematics server <NUM> and the OTA update server <NUM> are distinct servers, and the update server identifier <NUM> refers to the OTA update server <NUM>. In further embodiments, the update server identifier <NUM> may refer to the telematics server <NUM> which may be configured as a proxy for the OTA update server <NUM>. In such embodiments, when a firmware update is sent by the OEM server <NUM> to the telematics server <NUM>, the telematics server <NUM> is configured to forward the firmware update to the OTA update server <NUM>.

The vehicle identifier <NUM> is a unique identifier that identifies a vehicle in which ECUs for which firmware updates are being registered for are installed. The vehicle identifier enables the OEM server <NUM> to determine the ECM/ECUs installed in the vehicle. As an example, the vehicle identifier <NUM> may be a VIN such as "VIN1". VINs are usually comprised of a long sequence of letter and numbers. For simplicity, in this disclosure we use easy-to-read values such as "VIN1".

Turning back to <FIG>, at step <NUM>, the OEM server <NUM> processes the firmware update registration request <NUM>. The OEM server <NUM> queries the OEM database <NUM> for the vehicle identified by the firmware update registration request <NUM>. For example, with reference to the example of <FIG>, the OEM server <NUM> queries the OEM database for a vehicle identifier equal to "VIN1". An example of a database table <NUM> of the OEM database <NUM> is shown in <FIG>. Each row or tuple of the database table <NUM> is comprised of at least four fields: the ECM/ECU field <NUM>, the VIN field <NUM>, the registration field <NUM>, and the update server field <NUM>.

The ECM/ECU field <NUM> contains an identifier for an ECU or ECM model, made by the OEM, and installed in the vehicle identified by the VIN stored in the VIN field <NUM>. There may be more than one ECU or ECM made by the OEM installed in the vehicle designated by the vehicle identifier stored in the VIN field <NUM>.

The VIN field <NUM> stores a vehicle identifier, such as a VIN for a vehicle in which one or more ECUs made by the OEM are installed. Accordingly, as seen in the database table <NUM>, "VIN1" has multiple entries (rows or tuples) in the database table <NUM> each representing a different ECU associated with the vehicle represented by the vehicle identifier "VIN1".

The registration field <NUM> is a flag indicating whether the vehicle designated by the VIN stored in the VIN field <NUM> is registered to receive firmware updates for the ECM/ECU field <NUM>. When a vehicle, designated by a VIN stored in a VIN field <NUM>, is not registered to receive an update for an ECM/ECU specified in the ECM/ECU field <NUM>, the value of the registration field <NUM> is "No". Conversely, upon successful registration of the vehicle to receive a firmware update for an ECM/ECU deployed therein, the value of the registration field <NUM> is set to "Yes".

The update server field <NUM> stores an identifier for the update server to use to send firmware updates to the vehicle specified in the VIN field <NUM>. The update server field <NUM> uses the same specifier format as the update server identifier <NUM> of the firmware update registration request <NUM>.

Turning back to step <NUM> in <FIG>, the OEM server <NUM> searches the OEM database <NUM>, and specifically the database table <NUM> for entries corresponding to the vehicle identifier <NUM> specified in the firmware update registration request. With reference to <FIG>, there are two entries corresponding to "VIN1", which is the vehicle identifier specified in the firmware update registration request <NUM> of <FIG>. <FIG> shows that the vehicle designated by "VIN1" is not registered for firmware updates either for the ECM designated as ECM_123 or the ECU designated as ECU_456. This is represented by a "No" in the registration field <NUM> and also by the update server field <NUM> being blank or null. In response to receiving the firmware update registration request of <FIG>, the OEM server <NUM> updates both entries in the database table <NUM> which correspond to "VIN1" to indicate that the vehicle represented by "VIN1" is registered for firmware updates that become available for the ECM model ECM_123 and the ECU model ECU_456. The OEM server <NUM> also updates the update server field <NUM> with an identifier of the OTA update server <NUM> to indicate that firmware updates for the vehicle "VIN1" are to be delivered to the OTA update server <NUM> when available.

At step <NUM> of <FIG>, the OEM server <NUM> sends back a firmware update registration response to the customer terminal <NUM>. The firmware update registration response may contain a status code that indicates to the customer terminal <NUM> whether the firmware update registration request is successful or not.

After the firmware update registration is completed for a particular vehicle's ECUs, whenever a firmware update is available for one or more of the particular vehicle's ECUs, the OEM server <NUM> may push the firmware update to an update server stored in the update server field <NUM>, such as the OTA update server <NUM>. This is described in more detail with reference to <FIG> and <FIG>.

<FIG> depicts a method 1200A for updating an ECU <NUM> deployed in a vehicle asset, in accordance with embodiments of the present disclosure. The method 1200A assumes that the registration process <NUM> of <FIG> has been executed and that the OTA update server <NUM> has registered for firmware updates with the OEM server <NUM>. It is also assumed that the OEM server <NUM> now has a firmware update for an ECU deployed in one or more vehicle assets registered for firmware updates.

At step <NUM>, the OEM server <NUM> has a new firmware update for an ECU. The OEM server <NUM> needs to determine how to deliver the firmware update to vehicles which are registered for firmware updates. The OEM server <NUM> queries the OEM database <NUM> and particularly the database table <NUM>. As an example, the firmware update may be for an ECM model type "ECM_123". Upon querying the table <NUM>, the OEM server <NUM> determines that the vehicles "VIN1" and "VIN99" both have the ECM of type "ECM_123" deployed therein. However, the OEM server <NUM> also determines that the vehicle "VIN99" is not registered for firmware updates as indicated by the value "No" in the registration field <NUM> corresponding thereto. Accordingly, the OEM server <NUM> determines that it needs to send the firmware update for ECM_123 to the vehicle "VIN1". The OEM server <NUM> checks the update server field <NUM> corresponding to the row for ECM_123 and VIN1 and determines that the firmware update for the ECM_123 can be delivered to the vehicle VIN1 via the OTA update server <NUM>.

Based on the determination made in step <NUM>, at step <NUM>, the OEM server sends a firmware update message (for "ECM_123") to the OTA update server <NUM>. The firmware update message includes both an ECU firmware update and a list of vehicle identifiers associated with the OTA update server <NUM> and which are to receive the ECU firmware update. For example, <FIG> shows a firmware update message <NUM> including the ECU firmware update for ECM_123 accompanied by a list of vehicle identifiers including "VIN1".

At step <NUM>, the OTA update server <NUM> needs to identify the telematics device <NUM> associated with each of the VINs specified in <FIG>, including "VIN1". The OTA update server <NUM> sends a request for the telematics device identifier of the telematics device <NUM> coupled with the vehicle asset having a vehicle identifier specified in the firmware update message <NUM>. For example, the OTA update server <NUM> may request the telematics device identifier of the telematics device coupled to the vehicle having the vehicle identifier "VIN1". The request is received at the telematics server <NUM>.

At step <NUM>, in response to receiving the request for the telematics device identifier corresponding to a vehicle asset, such as "VIN1", the telematics server <NUM> queries the telematics database <NUM>. Specifically, and with reference to <FIG>, the telematics server <NUM> locates the entry, in the table <NUM>, which corresponds to "VIN1" and contains "VIN1" in the vehicle identifier field <NUM>. The telematics server <NUM> then determines that the telematics device identifier <NUM> of the telematics device coupled to the vehicle "VIN1" is "TD00101".

At step <NUM>, the telematics server <NUM> sends the telematics device identifier <NUM> back to the OTA update server <NUM>. For example, for the vehicle "VIN1", the corresponding telematics device ID <NUM> has the value "TD00101".

It should be noted that, in another embodiment, the steps <NUM>, <NUM>, and <NUM> may be performed before the method 1200A is started and as part of a registration process, such as the registration process <NUM> of <FIG>. For example, after step <NUM> of <FIG>, the customer terminal <NUM> may send the list of vehicle identifiers for which the firmware update registration has been completed to the OTA update server <NUM>. In turn the OTA update server <NUM> may perform steps <NUM>, <NUM> and <NUM> of <FIG> and maintain a table of the vehicle identifiers and corresponding telematics device identifiers.

The OTA update server <NUM> and the telematics device <NUM> are configured to communicate with one another using a networking protocol. Now the OTA update server <NUM> has been provided with the telematics device identifier <NUM> for the telematics device coupled to the vehicle identified by "VIN1" in step <NUM>. At step <NUM>, the OTA update server <NUM> sends an ECU firmware update for an ECU installed in the vehicle identified by the vehicle identifier "VIN1" to the telematics device coupled thereto. For example, at step <NUM>, the OTA update server <NUM> may send the ECU firmware update for ECM_123 to the telematics device <NUM> having a telematics ID "TD00101". The telematics device <NUM> may receive the ECU firmware update, such as the firmware update for ECM_123 over the network interface <NUM>.

At this point, the telematics device <NUM> may send the ECU firmware update to the ECU <NUM>. For example, the memory <NUM> of the telematics device <NUM> may contain machine-executable programming instructions which when executed by the controller <NUM> configure the telematics device <NUM> to send the ECU firmware, such as the firmware for ECM_123, over the asset interface <NUM> to the interface port <NUM> of the asset <NUM>. For example, to send the ECU firmware for ECM_123 to the vehicle having the identification "VIN1", the firmware update is placed on the CAN bus <NUM> of the vehicle asset <NUM>, where it is received by the ECU <NUM> (ECM_123) for which the firmware update is designated. Specific protocols and services are used for an ECU firmware update, such as the unified diagnostic services (UDS) protocol.

In case of the ECU <NUM> configuration of <FIG>, where the ECU <NUM> has only a primary firmware <NUM>, downloading the firmware update to the ECU <NUM> will cause the ECU <NUM> to replace the existing primary firmware <NUM> with the firmware update and will cause the ECU <NUM> to reset. If the vehicle is operating while the firmware update is taking place, the vehicle operation may be disrupted, and unforeseen dangerous situations may occur. Accordingly, a number of conditions have been identified for a safe OTA firmware upgrade. For example, it is safer if the firmware update is completed when: <NUM>) the vehicle is stopped or stationary, <NUM>) the parking brake is engaged (if available), <NUM>) the battery is connected and the ignition is on, <NUM>) the engine is off, i.e. the RPM is <NUM>, <NUM>) the battery voltage is adequate, <NUM>) cellular/satellite coverage is adequate (i.e. the signal strength is strong enough for reliable communications), and <NUM>) the driver is close to the vehicle. As such, at step <NUM>, the telematics device <NUM> queries a number of ECUs <NUM> in the vehicle and confirms that aforementioned conditions have been satisfied.

If the operating conditions of the vehicle permit completion of the firmware update, then at step <NUM>, the telematics device <NUM> sends the ECU firmware update to the ECU <NUM> as described above. On the other hand, if the operating conditions prohibit the upgrade, then the firmware update is not sent to the ECU <NUM>. The telematics device <NUM> may cache the firmware update and retry at another time.

In another embodiment of <FIG>, shown in <FIG> the OTA update server <NUM> checks the conditions of the vehicle before sending the ECU firmware update to the telematics device <NUM> in step <NUM>. <FIG> depicts a method 1200B which is a variation of the method 1200A of <FIG>. <FIG> shows steps <NUM> and up due to space limitations. It is assumed that the steps <NUM>-<NUM> of <FIG> have been performed. At step <NUM>, the OTA update server <NUM> receives the telematics device identifier coupled to the vehicle from the telematics server as described above.

At step <NUM>, the OTA update server <NUM> requests the vehicle operating conditions from the telematics device <NUM>.

At step <NUM>, the telematics device <NUM> sends the vehicle operating conditions back to the OTA update server <NUM>. The OTA update server <NUM> receives the vehicle operating conditions.

At step <NUM>, the OTA update server <NUM> checks the operating conditions of the vehicle.

If the operating conditions allow the update, then at step <NUM> the OTA update server <NUM> sends the firmware update to the telematics device <NUM>. Then, at step <NUM> the telematics device <NUM> acts as a pass-through device and sends the ECU firmware update to the ECU <NUM>. As described above with reference to <FIG>, a firmware update to the ECU <NUM> triggers a reset and the execution of the new firmware update as the primary firmware <NUM>. In other words, the ECU is updated upon download of the firmware update.

In the case of the ECU <NUM> configuration of <FIG>, where the ECU <NUM> has both a primary firmware <NUM> and a secondary firmware <NUM>, the ECU firmware update is downloaded into the secondary firmware <NUM> without checking the vehicle conditions. This is because the ECU <NUM> will continue to run the primary firmware <NUM> until an activation command is received by the ECU <NUM> from the telematics device <NUM>. In such embodiments, the step <NUM> of <FIG> and the steps <NUM>, <NUM>, and <NUM> of <FIG> are skipped. Instead, a separate activation process is used to activate the secondary firmware <NUM> as will be described below.

After the method 1200A or the method 1200B is executed, the firmware update for the ECU, such as ECM_123 is stored as the secondary firmware <NUM>. The firmware update, however, is not activated and does not become the currently executing firmware as the ECU continues to execute the primary firmware <NUM>. To activate the newly downloaded firmware update, the telematics device <NUM> needs to send an activation command to the ECU <NUM>. As discussed above with reference to <FIG>, the activation command causes the ECU to execute the secondary firmware <NUM> which now contains the firmware update. The activation command is only sent after the vehicle's operating conditions are deemed safe as discussed above. For example, it is safer if the ECU switches from executing the primary firmware <NUM> to the secondary firmware <NUM> (containing the new firmware update), when: <NUM>) the vehicle's motion status is stopped or stationary, <NUM>) the parking brake is engaged (if available), <NUM>) the battery is connected and the ignition is on, <NUM>) the engine is off (i.e. the RPM is ), <NUM>) the battery voltage is adequate, <NUM>) cellular/satellite coverage is adequate, and <NUM>) the driver is close to the vehicle.

Some or all of the above conditions need to be met to ensure that the firmware activation may not cause any problems that would render the vehicle unsafe or inoperable. As discussed above, in order for the firmware to be activated, the ECU needs to be rebooted. This means that the ECU would be inoperable for a certain duration. Depending on the function of the ECU, rebooting the ECU may cause a vehicle's engine to stall, may affect steering, may affect braking, or may affect any other essential function of the vehicle. Accordingly, activating an ECU firmware while the vehicle is in motion is considered unsafe. Similarly, activating an ECU firmware while the parking brake is not engaged may not guard against an unpredicted movement of the vehicle upon rebooting the ECU. When activating the firmware update, it is desired to ensure that the battery is connected, that ignition is on, and that the battery voltage is adequate. Since activating the firmware may entail copying the firmware update as the primary firmware, if there is insufficient battery power, the ECU may stop working before the firmware update has been copied as the primary firmware. A partially copied firmware would be inoperable thus making the ECU defective. Ensuring there is enough cellular and satellite coverage is another condition. If the satellite coverage is weak, then the location module may not accurately indicate whether the vehicle is stationary or in motion.

Some of the aforementioned conditions can be determined by the telematics device <NUM> from the vehicle asset <NUM>, while others cannot. A telematics device <NUM> which contains accelerometers and/or a location module can determine whether the vehicle asset containing the ECU for which the firmware is to be activated is stationary. The telematics device <NUM> may thus contain machine-executable programming instructions which when executed by the controller <NUM> configure the telematics device <NUM> to read inertial measurement unit (IMU) data from the accelerometers to determine whether the vehicle asset is stationary. Additionally, machine-executable instructions may configure the telematics device <NUM> to continually read the device's location as reported by the location module <NUM> and determine if the vehicle is stopped or in motion. If the vehicle is not stationary and/or in motion, then the telematics device <NUM> refrains from sending an activation command causing the firmware update for the ECU to be activated.

In some embodiments, the vehicle's operating conditions may be available via the interface port <NUM> either periodically or upon request. For example, the vehicle may periodically report the status of the parking brake, battery voltage, and ignition status on the CAN bus <NUM>. As another example, the telematics device <NUM> may send commands requesting the status of the parking brake, the battery voltage, and the ignition. In response to the commands, the respective ECUs place such information on the CAN bus which is accessible through the interface port <NUM>. The telematics device <NUM> may read these statuses and refrain from sending an activation command to the ECU until all the aforementioned conditions are satisfied. This is described with reference to <FIG> below.

<FIG> and <FIG> each depicts a method of activating a firmware update in an ECU <NUM> having both a primary firmware <NUM> and a secondary firmware <NUM>, in accordance with embodiments of the present disclosure. The method 1300A (or the method 1300B) may be executed after a firmware update has been downloaded into the secondary memory of an ECU <NUM> such as the ECU <NUM> of <FIG>.

First, with reference to <FIG>, there is shown a method 1300A for activating a firmware update in which a telematics device <NUM> checks the operating conditions of the vehicle before sending a firmware activation command to an ECU deployed in the vehicle.

At step <NUM>, the OTA update server <NUM> sends a firmware activation command to the telematics device <NUM>. The firmware activation command instructs the telematics device <NUM> to attempt to activate the newly downloaded firmware update for an ECU. For example, the firmware activation command may instruct the telematics device <NUM> to activate the firmware update for the ECU "ECM_123" on the vehicle identified by "VIN1" which is coupled to the telematics device <NUM>.

At step <NUM>, the telematics device <NUM> checks the vehicle's operating conditions to ascertain whether the vehicle's operating conditions allow the update to the ECU firmware to be completed. The update to the ECU firmware is completed when the newly downloaded firmware update to the ECU becomes the currently running (active) firmware. The operating conditions that would allow an update to be completed are that the vehicle is stopped and stationary, the engine is not running, the ignition is on, the battery voltage is sufficient, and the parking brake is engaged.

If the vehicle operating conditions allow the firmware update to be completed then steps <NUM>, <NUM>, <NUM> and <NUM>, are performed. If, on the other hand, at least one vehicle operating condition would prohibit the completion of the firmware update, then step <NUM> is performed.

At step <NUM>, the telematics device <NUM> sends a command, via the asset interface <NUM> and the interface port <NUM>, to the ECU ("ECM_123") which has the newly downloaded firmware update to activate the newly downloaded firmware update.

At step <NUM>, the ECU activates the firmware update, which is stored as the secondary firmware <NUM>. Activating the firmware update may involve setting a flag indicating that the secondary firmware is to become the active firmware and rebooting the ECU so that the boot loader executes the secondary firmware after rebooting.

At step <NUM>, upon completion of the activation of the firmware update, the ECU <NUM> sends an activation complete message to the telematics device <NUM> confirming that the firmware update is now the active firmware running thereon.

At step <NUM>, and in response to receiving the activation completion message from the ECU, the telematics device <NUM> sends an ECU firmware update completion message back to the OTA update server <NUM>. The OTA update server <NUM> may update its database <NUM> to indicate the new firmware version that the ECU ("ECM_123") on the vehicle "VIN1" is currently running.

At step <NUM>, and in response to determining that the vehicle operating conditions would prohibit the completion of the firmware update on an ECU, the telematics device <NUM> sends an ECU firmware update not completed message to the OTA update server <NUM>. In response to the ECU firmware update not completed message, the OTA update server <NUM> may retry sending the firmware activation command (sent at the step <NUM>) at a later time.

<FIG> depicts a method 1300B which is a variation on the method 1300A in which the OTA update server <NUM> checks and verifies the vehicle's operating conditions before proceeding with activating an ECU firmware update.

The method 1300B of <FIG> starts at step <NUM>. At step <NUM>, the OTA update server requests the relevant vehicle operating conditions from the telematics device <NUM>. The telematics device <NUM> receives the request for the operating conditions. The telematics device <NUM> may query the various ECUs <NUM> on the vehicle.

At step <NUM>, the telematics device <NUM> sends a response to the OTA update server <NUM> with the vehicle's operating conditions. The OTA update server <NUM> receives the response.

At step <NUM>, the OTA update server checks the operating conditions of the vehicle. If the vehicle's operating conditions permit the activation of the firmware update, then steps <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are carried out. If the vehicle's operating conditions prohibit the activation of the firmware update, then no steps are performed.

While many vehicles can report status conditions such as whether the engine is running, the battery is connected and has adequate voltage, the ignition is on, and the parking brake is engaged, some older vehicles cannot. In this case, it may be adequate to rely on the vehicle operator to check the conditions and confirm. Requesting that the operator of the vehicle confirm before the firmware update is complete and the newly downloaded firmware is activated may be a regulatory requirement in some jurisdictions. In order to guard against the vehicle operator confirming without checking, it is preferred that the vehicle operator is in close proximity to the vehicle.

<FIG> depicts a simplified block diagram showing selected components of an operator terminal <NUM>, a telematics device <NUM>, a telematics server <NUM>, and an OTA update server <NUM>, in accordance with embodiments of the present disclosure which verifies that the operator of a vehicle is in proximity therewith before asking the operator to authorize a firmware update completion. The depicted system may be used to allow an operator to confirm a firmware update in case of an ECU such as that of <FIG> wherein the firmware update is activated upon download. The depicted system may also be used to allow an operator to confirm an activation of an already downloaded firmware update, such as the case with ECUs of the type shown in <FIG>.

The operator terminal <NUM> is used by the operator <NUM> of a vehicle asset <NUM>. The operator terminal <NUM> may be a smartphone or tablet. In the depicted embodiment, the operator terminal <NUM> runs a driver telematics application <NUM>, which also has an OTA update add-in <NUM> in communication with an operator location module <NUM> as discussed below.

The driver telematics application <NUM> is a mobile application in communication with the telematics server <NUM> over a network such as the network <NUM> in <FIG>. The driver telematics application <NUM> is typically used to associate an operator <NUM> with a vehicle asset <NUM> and keep track of the operator's use of the vehicle. Upon starting the driver telematics application, the operator is prompted to enter the vehicle they will be operating. Then as the operator is using the vehicle, various activities are tracked. For example, the driver telematics application <NUM> logs when the operator is on the move, taking a break, or using the vehicle for a personal trip. The logged information about the operator and the vehicle is uploaded to the telematics server <NUM>.

The operator location module <NUM> is a software component for determining location information about the operator terminal <NUM>.

In one embodiment, the operator location module <NUM> is coupled to a GPS module and reports an absolute location of the operator terminal <NUM>.

With reference to <FIG>, the telematics device <NUM> includes an NFC module <NUM>. According to the invention, the operator location module <NUM> indicates that the operator terminal <NUM> is in close proximity to the telematics device <NUM> (and hence the vehicle) if the NFC module <NUM> has been tagged within a prior period of time. If the operator (driver) of the vehicle taps the NFC module <NUM> on the telematics device <NUM> with an NFC tag, it is known that the operator is in the vehicle. Within a few seconds of the tap, the operator cannot have moved very far from the vehicle. For example, the operator location module <NUM> may report that the operator is in close proximity to the vehicle, if the NFC module <NUM> reports an NFC tap within the prior <NUM> seconds.

The OTA update add-in <NUM> is an additional module such as a plug-in that is coupled to the driver telematics application for extending the function of the driver telematics application to support firmware update activation. in connection with the operator location module <NUM> deployed in the operator terminal <NUM> and receives the location information provided by the operator location module <NUM>. The OTA update add-in <NUM> is also in communication with the OTA update server <NUM>, via a network, and sends the location information obtained from the operator location module <NUM> to the OTA update server <NUM> upon receiving a request for the driver location information from the OTA update server <NUM>. Additionally, the OTA update add-in <NUM> displays a firmware activation confirmation user interface on a display of the operator terminal <NUM> for receiving confirmation from the operator <NUM> that an ECU firmware activation may proceed as will be described in detail below. Furthermore, the OTA update add-in <NUM> sends an indication to the OTA update server <NUM> when an operator has confirmed that the ECU firmware activation may proceed.

The telematics device <NUM> of <FIG> is similar to the telematics devices described with reference to <FIG> and <FIG>. In the context of <FIG>, the telematics device <NUM> reports the location of the vehicle as part of the telematics data <NUM> sent to the telematics server <NUM>. The telematics device <NUM> also sends a command to activate the firmware update in response to receiving a command from the OTA update server <NUM> as described above.

The telematics server <NUM> receives telematics data <NUM> from the telematics device <NUM>, the telematics data <NUM> including the identity and location of the telematics device <NUM> coupled to the vehicle asset, which therefore indicates the location of the vehicle asset <NUM>. The telematics server <NUM> stores the vehicle identification and vehicle location in the telematics database <NUM>. For example, table <NUM> in <FIG> shows a few exemplary entries of vehicle assets having a vehicle identifier field <NUM> containing a vehicle identifier such as a VIN, the telematics device identifier <NUM> of the telematics device <NUM> coupled to each asset, and the asset location <NUM> that is the location of the telematics device <NUM> coupled to each asset. For example, the vehicle identified by the vehicle identifier <NUM> has a telematics device identified by the telematics device identifier TD0010 coupled thereto, and is located at the latitude/longitude location of <NUM>° N, <NUM>° W.

The telematics server <NUM> also receives from the driver telematics application <NUM>, an association between the operator <NUM> and the vehicle asset <NUM>. For example, when the operator <NUM> starts the driver telematics application <NUM> and selects a particular vehicle, such as by entering the vehicle's VIN, the driver telematics application <NUM> sends an association between the operator <NUM> and the vehicle asset <NUM> to the telematics server. The vehicle's operator <NUM> may be identified by the operator terminal <NUM> that they are using. The telematics server <NUM> may save the association between the vehicle asset and the operator terminal <NUM> in a table <NUM> in the telematics database <NUM>, as shown in <FIG>. The vehicle identifier field <NUM> may contain the vehicle's VIN as discussed above. The operator terminal <NUM> may be identified by the operator terminal's network address, an international mobile subscriber identity (IMSI), or any other identifier that uniquely identifies the operator terminal <NUM> and makes it possible for an entity to communicate therewith. As an example, the vehicle identified by "VIN1" is currently driven by an operator using an operator terminal <NUM> having the identity "OT0012".

The telematics server <NUM>, may receive requests from a server, such as the OTA update server <NUM> for information about a vehicle asset including the driver identification and the vehicle location. The telematics server <NUM> may correlate the information from the tables <NUM> and <NUM> to provide the requested information. For example, with reference to <FIG>, the telematics server <NUM> may send the shown asset information record <NUM> to the OTA update server <NUM> in response to a request from the OTA update server <NUM> for information about the vehicle identified by "VIN1". The asset information record for "VIN1" indicates that the telematics device identifier <NUM> is TD00101, the asset location <NUM> is "<NUM>° N, <NUM>° W", and that the operator terminal <NUM> for the operator currently using the vehicle "VIN1" is "OT0012".

The OTA update server <NUM> contains a vehicle information module <NUM>, a proximity determination module <NUM>, a firmware activation module <NUM>, and a driver location module <NUM>.

The vehicle information module <NUM> requests information about a particular vehicle, identified by an asset ID, from the telematics server <NUM>. The vehicle information module <NUM> receives an asset information record <NUM> from the telematics server <NUM> as discussed above. The vehicle information module <NUM> saves the asset information record <NUM>. For example, the vehicle information module <NUM> may save the asset information record in the OTA update database <NUM>.

The driver location module <NUM> requests the operator location from the OTA update add-in <NUM>. As discussed above, the OTA update add-in <NUM> obtains the location of the operator terminal <NUM> from the operator location module <NUM>. The driver location module <NUM> requests and receives the operator location, which is the location of the operator terminal from the OTA update add-in <NUM>.

The firmware activation module <NUM> determines whether an update to an ECU firmware on a particular vehicle may be completed. In some embodiments, the ECU firmware update may be completed by sending the update to a telematics device <NUM> for download and activation on an ECU of the type shown in <FIG>. In other embodiments, the ECU firmware update is completed by the activation of a firmware update that is residing as a secondary firmware <NUM> in ECUs of the type shown in <FIG>. The firmware activation module <NUM> ensures that the driver is in close proximity to the vehicle before proceeding with completing a firmware update. The firmware activation module <NUM> receives an indication that the driver is in close proximity to the vehicle from the proximity determination module <NUM>. The firmware activation module <NUM> sends an indication to the OTA update add-in <NUM> on an operator's terminal <NUM> indicating that an ECU firmware update needs an operator's approval to proceed. In response to receiving an indication from the OTA update add-in <NUM> that an ECU firmware activation may proceed, the firmware activation module <NUM> either sends a firmware update or sends a message to the telematics device <NUM> indicating that the ECU firmware may be activated.

The components depicted in <FIG> thus cooperate to provide an activation to an ECU firmware update. <FIG> depicts a sequence diagram for a method <NUM> of activating an ECU firmware update, in accordance with embodiments of the present disclosure.

At step <NUM>, the operator terminal <NUM> registers an operator with a vehicle. As discussed above, the operator may use a driver telematics application to select a vehicle to operate. In the step <NUM>, the operator terminal <NUM> sends both an operator terminal identifier and a vehicle identifier to the telematics server <NUM>. In response to receiving the registration of the operator with the vehicle, the telematics server <NUM> creates an association, such as an entry in a database table, associating the operator identifier with the vehicle identifier.

At step <NUM>, the telematics device <NUM> reports the location of the vehicle asset to which it is coupled to the telematics server <NUM>. Since the telematics device <NUM> is typically coupled to the interface port <NUM> of the vehicle, the location of the telematics device <NUM>, as reported by an on-board location module or a location module disposed in an I/O expander indicates the location of the vehicle asset. The telematics server <NUM> receives the location of the vehicle and the vehicle identifier (as reported by the vehicle to the telematics device in the form of a VIN) from the telematics device <NUM> and notes the location of the vehicle in a database entry in a table of the telematics database <NUM>. It should be noted that the step <NUM> may take place periodically and is not dependent on step <NUM>.

At step <NUM>, the OTA update server <NUM> requests the vehicle location for a particular vehicle for which an ECU update has been performed but for which the update has not yet been activated. The OTA update server <NUM> provides a vehicle identifier, such as a VIN, to the telematics server <NUM>. The telematics server <NUM> locates the vehicle in the telematics database <NUM> and obtains the vehicle location.

At step <NUM>, the telematics server <NUM> sends the vehicle location to the OTA update server. The vehicle location is received by the OTA update server <NUM> and recorded in a database <NUM> of the OTA update server <NUM>.

At step <NUM>, the OTA update server <NUM> requests the operator location from the operator terminal <NUM>. The OTA update add-in <NUM> receives the request for the operator location.

At step <NUM>, the OTA update add-in <NUM> sends the operator location to the OTA update server <NUM>.

At step <NUM>, the OTA update server <NUM> determines whether the operator and the vehicle are in proximity.

If the operator is proximate to the vehicle, then at step <NUM>, the OTA update server <NUM> sends a request for operator confirmation to the operator terminal <NUM>.

At step <NUM>, and in response to receiving the request for operator confirmation, the OTA update add-in <NUM> displays a firmware update user interface (Ul) including a confirmation UI prompting the operator to confirm that certain operating conditions are satisfied for the ECU firmware download and/or activation. An exemplary firmware update UI is depicted in <FIG> and described below.

If the operator confirms that the ECU firmware update may proceed, then at step <NUM>, the OTA update add-in <NUM> sends an operator confirmation message to the OTA update server <NUM>.

At step <NUM>, in response to receiving the operator confirmation, the OTA update server <NUM> sends a firmware update or a firmware activation command to the telematics device <NUM> coupled to the vehicle requiring the ECU firmware update. In response to receiving the firmware update or firmware activation command, the telematics device may check the vehicle condition as was done in step <NUM> of <FIG>. This step is not shown as it is assumed that the operator has confirmed that the conditions are met. However, in some embodiments, the step <NUM> of checking the vehicle conditions may be carried out in response to receiving the firmware activation command at step <NUM>. In some embodiments, checking the vehicle conditions may be done by the telematics device <NUM>, as was the case in <FIG>. In other embodiments, checking the vehicle conditions may be performed by the OTA update server <NUM>, as shown in <FIG>.

At step <NUM>, the telematics device <NUM> sends an ECU firmware update complete indication to the OTA update server <NUM>.

At step <NUM>, the OTA update server <NUM> sends an indication to the operator terminal <NUM> indicating that the ECU firmware update is now complete. The OTA update add-in <NUM> may update the firmware update UI displayed in step <NUM> above to indicate that the firmware update has been completed. This is shown with some detail in Figures 20A through 20E.

In some embodiments, the method <NUM> depicted in <FIG> includes additional steps. For example, prior to step <NUM>, the OTA update server <NUM> may obtain the vehicle's operating conditions from the telematics device <NUM> and include it with the request for operator confirmation of step <NUM>. In this embodiment, the firmware update UI reflects the vehicle's operating conditions which were determined in an automated manner.

<FIG> depicts a simplified block diagram of an OTA update server <NUM>, in accordance with embodiments of the present disclosure. The OTA update server <NUM> is comprised of a controller <NUM>, a memory <NUM>, and a network interface <NUM>.

The controller <NUM> is similar to the controller <NUM> described above.

The memory <NUM> stores machine-executable programming instructions which, when executed by the controller <NUM> perform the method steps performed by the OTA update server <NUM>. Specifically, the machine-executable programming instructions comprise the vehicle information module <NUM>, the proximity determination module <NUM>, the firmware activation module <NUM> and the driver location module <NUM> all of which have been described above.

The network interface <NUM> is similar to the network interface <NUM> described above and enables the OTA update server <NUM> to communicate with the operator terminal <NUM>, the telematics device <NUM>, the telematics server <NUM>, and the OEM server <NUM>.

<FIG> depict user firmware update user interfaces which are displayed by the OTA update add-in <NUM>, in accordance with embodiments of the present disclosure.

<FIG> depicts a UI <NUM> including an indication of the availability of an ECU firmware update and listing the conditions that the operator of the vehicle needs to ensure are met before proceeding with the update, in accordance with embodiments of the present disclosure. The UI <NUM> includes an application banner <NUM>, a UI banner <NUM>, an update conditions message <NUM>, a confirmation user interface element <NUM>, a deferment user interface element <NUM>, a next button <NUM>, and a cancel button <NUM>. The application banner <NUM> indicates that the application currently running is the OTA update application. The UI banner <NUM> includes a message indicating what the purpose of the currently displayed UI <NUM>. The UI banner <NUM> displays a message indicating that an update is available for an ECU of the vehicle that the operator is currently operating. The update conditions message <NUM> includes a list of the conditions that need to be met before the ECU firmware update may proceed. For example, the conditions shown include ensuring that the vehicle is stationary, that the parking brake is engaged, that the engine is off, that the ignition key is on, that the battery is connected, and that the cellular coverage is good. The confirmation user interface element <NUM> is comprised of a confirmation message <NUM> and a checkbox <NUM>. The deferment user interface element <NUM> is comprised of a clickable message that may trigger an action. For example, clicking the deferment user interface element <NUM> causes the UI <NUM> to disappear and then be re-displayed at a later time. The next button <NUM> may be used by the OTA update add-in <NUM> to advance to the next user interface where the OTA firmware update may proceed. Initially, the next button <NUM> may be grayed out and disabled until the operator has confirmed that the requirements for the OTA firmware update are met. The cancel button <NUM> allows permanent closing of the OTA update add-in457.

The UI <NUM> is displayed as shown. The operator may manually review the update conditions message <NUM> and carry out whichever activities are necessary to comply with the conditions listed. When the operator is confident that the conditions listed in the update conditions message <NUM> are satisfied, the operator may enable the confirmation user interface element <NUM> by clicking the checkbox <NUM>. In response to detecting that the confirmation user interface element <NUM> has been enabled, the OTA update add-in <NUM> updates the UI <NUM> by enabling the next button <NUM>. At this point, the operator may then click the "Next" button <NUM> to proceed. In response to detecting that the "Next" button has been clicked, the OTA update add-in <NUM> may send an operator confirmation as was described above with reference to step <NUM> of <FIG>. If the operator needs more time until the conditions listed in the update conditions message <NUM> are complied with, then there are other options. If the operator believes the conditions may be complied with within a short duration, such as five minutes, then the operator may use the deferment user interface element <NUM> to give the operator more time. For example, in response to actuating the deferment user interface element <NUM>, the OTA update add-in <NUM> causes the UI <NUM> to disappear and then be re-displayed at a later time, such as after <NUM> minutes. If the operator believes that complying with the conditions listed in the update conditions message <NUM> will take a long time to be satisfied, the operator may click the cancel button <NUM> to abandon the update process and try again at a later time. In response to receiving an actuation of the cancel button <NUM>, the OTA update add-in <NUM> exits. The UI <NUM> thus relies on the operator to confirm that operating conditions of the vehicle and instruct the OTA update add-in <NUM> to proceed with either downloading the update or activating the update if it had been already downloaded but not activated.

<FIG> depicts a UI <NUM> of the OTA update add-in <NUM> in which the vehicle operating conditions for a firmware update/activation are automatically checked, in accordance with embodiments of the present disclosure. The UI <NUM> includes the application banner <NUM>, a UI banner <NUM>, a list of condition indication UI elements (<NUM> to <NUM>), a deferment user interface element <NUM>, a next button <NUM>, and a cancel button <NUM>.

The UI banner <NUM> indicates that the requirements (or conditions) for proceeding with allowing a firmware update are being checked.

The condition indication UI elements <NUM> to <NUM> indicate each condition and the status thereof. If a condition is met, such as the condition that the vehicle is stationary, then a checkbox is displayed next thereto. If a condition is being tested and the status thereof has not yet been ascertained, then progress donut showing a partial progress is displayed as shown with the condition indication UI element <NUM>. For conditions that have not been met yet, a progress donut indicating no progress is displayed as shown with the conditions <NUM>, <NUM>, <NUM>, and <NUM>.

The deferment user interface element <NUM>, the next button <NUM>, and the cancel button <NUM> are similar to the deferment user interface element <NUM>, the next button <NUM>, and the cancel button <NUM> discussed above with reference to <FIG>.

In this embodiment, the OTA update add-in <NUM> may display the UI <NUM> when The telematics device <NUM> may report to the OTA update add-in <NUM> the operating condition of the vehicle couped thereto, and the quality of the cellular connection of the telematics device <NUM>. This may be via a direct connection between the operator terminal <NUM> and the telematics device <NUM>, or by the OTA update add-in <NUM> querying the OTA update server <NUM> for the operating conditions of the vehicle to which the telematics device <NUM> is coupled, as shown above in steps <NUM> and <NUM> of <FIG>.

For example, as discussed above, the OTA update server <NUM> may obtain the vehicle's operating conditions and sends the vehicle's operating conditions with the request for operator confirmation in step <NUM>. As shown in <FIG>, while the vehicle is stationary, the other operating conditions for an update are not met. Accordingly, the UI <NUM> indicates to the user that the vehicle is not ready and provides an option for the user to retry after a period of time. For example, the operator may click the cancel button and go back to the previous Ul.

<FIG> depicts a UI <NUM> of the OTA update add-in <NUM> which indicates that all of the vehicle operating conditions required for completing a firmware update, are satisfied. The UI <NUM> has an application banner <NUM>, UI banner <NUM> and a list of operating conditions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> and <NUM> ("<NUM> through <NUM>"). The UI <NUM> also has an install button <NUM> and a cancel button <NUM>. The UI banner <NUM> indicates that an update may be installed. The update may be installed because all of the operating conditions of both the vehicle and the telematics device are appropriate for proceeding with the update. This is indicated by the fact that all of the operating conditions <NUM> through <NUM> have a checked checkbox as shown. In this case, actuating an install activation user interface element, such as the install button <NUM> will cause the OTA update add-in <NUM> to send an operator confirmation to the OTA update server <NUM>, as was described above in step <NUM> of <FIG>. In response to the operator confirmation, the OTA update server sends either a firmware update or a firmware activation command to the telematics device <NUM>.

<FIG> depicts a UI <NUM> which provides status and instructions while the firmware update is in progress. The UI <NUM> has an application banner <NUM>, a UI banner <NUM>, an installation progress indicator <NUM>, a wait message <NUM>, a list of forbidden tasks <NUM>. The UI banner indicates that the firmware installation to the ECU is in progress. The installation progress indicator <NUM> shows the progress of the installation and is shown as a progress donut. The wait message <NUM> tells the operator that they need to wait before operating the vehicle. The list of forbidden tasks <NUM> is a list of tasks which if performed might jeopardize the update process and render the ECU unusable.

<FIG> depicts a UI <NUM> indicating that the firmware update is completed. The UI <NUM> is displayed when the OTA update add-in <NUM> receives the firmware update completion message as in step <NUM> of <FIG>. The UI <NUM> has an application banner <NUM>, a UI banner <NUM>, an update completion message <NUM>, and a finish button <NUM>. The UI banner <NUM> indicates whether the update has been successful. The update completion message <NUM> indicates to the operator that they may start using the vehicle. The finish button <NUM> causes the OTA update add-in <NUM> to exit.

<FIG> depicts a block diagram of an operator terminal <NUM>, in accordance with some embodiments of the present disclosure. The operator terminal <NUM> comprises a controller <NUM>, a network interface <NUM> coupled to the controller <NUM>, and a memory <NUM> coupled to the controller <NUM>. The memory <NUM> stores machine-executable programming instructions which when executed by the controller <NUM> configures the operator terminal to carry out the methods described herein. Specifically, the memory <NUM> stores machine-executable programming instructions for a driver telematics application <NUM>, an OTA update add-in <NUM>, and an operator location module <NUM>.

The methods described herein may be performed by machine-executable programming instructions stored in non-transitory computer-readable medium and executable by a controller.

Claim 1:
A method by an over-the-air, OTA, update server (<NUM>), the method comprising:
Determining, by the OTA update server (<NUM>), whether an operator (<NUM>) of a vehicle (<NUM>) is in close proximity to the vehicle (<NUM>);
in response to determining, by the OTA update server (<NUM>), that the operator (<NUM>) is in close proximity to the vehicle (<NUM>), sending, by the OTA update server (<NUM>), a request to an operator terminal (<NUM>) used by the operator (<NUM>) requesting a confirmation by the operator (<NUM>) for proceeding with completing a firmware update for an electronic control unit, ECU, (<NUM>) deployed on the vehicle (<NUM>); and
in response to receiving, at the OTA update server (<NUM>), the confirmation for proceeding with completing the firmware update, sending, by the OTA update server (<NUM>), a request to a telematics device (<NUM>) coupled to the vehicle (<NUM>) to complete the firmware update;
wherein determining that the operator (<NUM>) of the vehicle (<NUM>) is in close proximity to the vehicle (<NUM>) comprises
receiving an indication from the telematics device (<NUM>) of a near-field communications, NFC, tap of an NFC tag with an NFC module (<NUM>, <NUM>) on the telematics device (<NUM>) by the operator (<NUM>) within a prior period of time to identify themself as the operator (<NUM>) of the vehicle (<NUM>).