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 (OBD). The gathered asset data may include engine revolutions-per-minute (RPM), 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 publication <CIT> discusses information that is useful for understanding the background of the invention.

The present invention is defined by the method and system of the appended independent claims. Preferred embodiments are set out in the appended dependent claims.

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 telematics 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 device 200_1, telematics device 200_2. telematics device 200_N, respectively. Additionally, <FIG> shows a plurality of satellites 170_1, 170_2 and 170_3 ("satellites <NUM>") in communication with the telematics devices <NUM> for facilitating navigation.

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). Other types of vehicles, which are not shown, are also contemplated in the various embodiments of the present disclosure, including but not limited to, farming vehicles, construction vehicles, military vehicles, and the like.

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>, between the administration terminal <NUM> and the telematics server <NUM>, between the handheld administration terminal <NUM> and the telematics server <NUM>, and between the operator terminals <NUM> and the telematics server <NUM>.

The telematics server <NUM> is an electronic device executing machine-executable programming instructions which enable the telematics server <NUM> to store and analyze telematics data. The telematics server <NUM> may be a single computer system or a cluster of computers. The telematics server <NUM> may be running an operating system such as Linux, Windows, Unix, or any other equivalent operating system. Alternatively, the telematics server <NUM> may be a software component hosted on a cloud service, such as Amazon Web Service (AWS). The telematics server <NUM> is connected to the network <NUM> and may receive telematics data from the telematics devices <NUM>. The telematics server <NUM> may have a plurality of software modules for performing data analysis and analytics on the telematics data to obtain useful asset information about the assets <NUM>. The telematics server <NUM> may be coupled to a telematics database <NUM> for storing telematics data and/or the results of the analytics which are related to the assets <NUM>. The asset information stored may include operator information about the operators <NUM> corresponding to the assets. The telematics server <NUM> may communicate the asset data and/or the operator information pertaining to an asset <NUM> to one or more of: the administration terminal <NUM>, the handheld administration terminal <NUM>, and the operator terminal <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 <NUM> 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> or to issue commands to one or more telematics device <NUM> via the telematics server <NUM>. The administration terminal <NUM> may be a desktop computer, a laptop computer such as the administration terminal <NUM>, a tablet (not shown), 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 <NUM>. 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. The mobile application of the handheld administration terminal may also be used to issue commands to one or more telematics device <NUM> via the telematics server <NUM>. A fleet manager <NUM> may communicate with the telematics server <NUM> using the administration terminal <NUM>, the handheld administration terminal <NUM>, or another form of administration terminals such as a tablet. In addition to retrieving data and analytics, the administration terminal <NUM> 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 the assets <NUM>. 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 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 <NUM> that the asset <NUM> is being currently operated by the operator <NUM>. 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. Furthermore, the asset configuration application may allow the operator to configure the telematics device <NUM> coupled to the asset <NUM> that the operator <NUM> is operating.

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> or another device coupled to the telematics device <NUM>. The combined asset data, location data, and sensor 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 asset information pertaining to the assets <NUM> or to a fleet of assets. The telematics server <NUM> may store the telematics data and/or the generated asset information in the telematics database <NUM>. The administration terminal <NUM> may connect to the telematics server <NUM>, over the network <NUM>, to access the generated asset information. Alternatively, the telematics server <NUM> may push the generated asset 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 telematics database <NUM> accordingly to associate the operator <NUM> with the asset <NUM>. Furthermore, the telematics server <NUM> may provide additional analytics related to the operators <NUM> 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 <NUM> 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 <NUM>, and may optionally send alerts to the operator terminal <NUM> to notify an operator <NUM> of the alert. For example, a vehicle driver operating the vehicle outside of a service area or hours of service may receive an alert on their operator terminal <NUM>. A fleet manager <NUM> may also the administration terminal <NUM> to configure a telematics device <NUM> by issuing commands thereto via the telematics server <NUM>.

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> coupled thereto. Selected relevant components of each of the asset <NUM> and the telematics device <NUM> are shown.

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 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 an asset communications bus, such as a Controller Area Network (CAN) bus <NUM>. ECUs <NUM> interconnected using the CAN bus <NUM> send and receive information to one another in CAN data 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 may be 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 SAE J1979 protocol, which is commonly known as 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 electric power to a telematics device <NUM> connected 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>. The telematics device <NUM> may also contain some optional components, shown in dashed lines in <FIG>. For example, the telematics device <NUM> may contain one or more of: a near-field communications (NFC) module such as 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>, via the interface port <NUM>. The telematics device <NUM> shown is an example. Some of the components shown in solid lines may also be optional and may be implemented in separate modules. For example, some telematics devices (not shown) may not have a location module <NUM> and may rely on an external location module for obtaining the location data <NUM>. Some telematics devices may not have any sensors <NUM> and may rely on external sensors for obtaining sensor data <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 controller <NUM> may have an internal memory for storing machine-executable programming instructions to carry out the methods 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> and to access the data stored therein. 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 <NUM> from the sensors <NUM> and/or location data <NUM> 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 <NUM> and location data <NUM> 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>. In some embodiments, the memory <NUM> only stores data, and the machine-executable programming instructions for carrying out the aforementioned tasks are stored in an internal memory of the controller <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 location module <NUM> is coupled to the controller <NUM> and provides location data <NUM> thereto. The location data <NUM> may be in the form of a latitude and longitude, for example.

The sensors <NUM> may be one or more of: a temperature sensor, a pressure sensor, an optical sensor, a motion sensor such as 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 sensors provide sensor data <NUM> to the controller <NUM> via the sensor interface <NUM>.

The interface layer <NUM> may include a sensor interface <NUM> and an asset interface <NUM>. The sensor interface <NUM> is configured for receiving the sensor data <NUM> from the sensors <NUM>. For example, the sensor interface <NUM> interfaces with the sensors <NUM> and receives the sensor data <NUM> therefrom. The asset interface <NUM> receives 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>. 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 data frames. The 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 revolutions-per-minutes (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 both the asset data <NUM> and the sensor data <NUM> 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> for configuring the telematics device <NUM> in a certain mode and/or requesting a particular type of the asset data <NUM> from 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> may be 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 information read 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 wireless 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 wireless 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 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 be 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 <NUM> from the sensors <NUM> over the sensor interface <NUM>. Furthermore, the controller <NUM> may receive location data <NUM> from the location module <NUM>. The controller <NUM> combines the asset data <NUM> with the sensor data <NUM> and the location data <NUM> to obtain 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>. Optionally, an operator <NUM> may tap an NFC tag to the NFC module <NUM> to identify themself as the operator <NUM> 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> or the serial communications module <NUM> for providing location information thereto. In some embodiments, the telematics device <NUM> may receive, via the network interface <NUM>, commands from the telematics server <NUM>. The received commands instruct the telematics device <NUM> to be configured in a particular way. For example, the received commands may configure the way in which the telematics device gathers asset data <NUM> from the asset <NUM> as will be described in further detail below.

The telematics data <NUM> which is comprised of asset data <NUM> gathered from the asset <NUM> combined with the sensor data <NUM> and the location data <NUM> may be used to derive useful data and analytics, by the telematics server <NUM>. However, there are times when additional data, which is not provided by the asset <NUM>, the sensors <NUM> or the location module <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 capabilities.

To capture and provide information or services not provided by the asset <NUM> or the telematics device, to produce an output, or to perform an action not supported by the telematics device, the telematics device <NUM> may be modified to allow an input/output expander device ("I/O expander") to connect thereto, as shown in <FIG> shows a telematics device <NUM>' coupled to an asset <NUM>. An I/O expander <NUM> is 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 some of the optional components have been removed. Furthermore, the telematics device <NUM>' 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>.

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>, which has more limited features than the one shown in <FIG>. For example, the telematics device <NUM>' shown in <FIG> does not have an NFC module, a short-range wireless communications module, or a serial communications module. Instead, the telematics device <NUM>' has an I/O expander interface <NUM>.

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>.

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>, an image sensor <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> of <FIG>. 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 image sensor <NUM> may be a digital still camera or a digital video camera capable of capturing images. For example, the image sensor <NUM> may be a road-facing dashboard camera for monitoring the road ahead. In other examples, the image sensor <NUM> may be a driver-facing dashboard camera for identifying the operator <NUM> and/or their condition.

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>.

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>. In the depicted embodiment, the 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 <NUM> and the location data <NUM> to the 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 controller <NUM> may utilize the asset network interface <NUM> for the transmission of telematics data <NUM> provided by the controller <NUM>. In order to support further not provided by the integrated peripherals such as the sensors <NUM> and the location module <NUM>, the asset has an I/O expander interface <NUM> coupled to the 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.

As briefly mentioned above, a vehicle asset may be connected to a diagnostic tool <NUM>, such as an OBD-II reader, in addition to having a telematics device <NUM> connected therewith. <FIG> depicts an asset <NUM> connected to both a telematics device <NUM> and a diagnostic tool <NUM> via a splitter connector <NUM>.

The asset <NUM> may be a vehicle asset similar to the asset <NUM> of <FIG>. As discussed above, the asset <NUM> may have an interface port <NUM> which gives access to the CAN bus <NUM> thereof.

The telematics device <NUM> may be a telematics device similar to the telematics device <NUM> of <FIG> or the telematics device <NUM>' of <FIG>.

In this disclosure a "diagnostic tool" is an electronic device that may be used to read asset data <NUM> for the purpose of diagnosing problems or conducting performance testing such as emission testing. A diagnostic tool may also clear some engine error codes. A diagnostic tool may also be referred to as a "scan tool" or a "testing tool". In the depicted embodiment of <FIG>, the diagnostic tool <NUM> may be an OBD-II reader or any other diagnostic tool for use with a vehicle asset. For example, the diagnostic tool <NUM> may read asset data <NUM> for the purpose of performing an emissions test, or to check error codes generated by the vehicle asset's ECUs in response to the "check engine" indicator being turned on in the vehicle asset's dashboard. The diagnostic tool <NUM> may be a stationary diagnostic tool installed in a workshop, or a portable diagnostic tool. The diagnostic tool <NUM> may send request frames to at least some of the ECUs <NUM> of the asset <NUM> requesting certain information. For example, for an asset having a CAN bus <NUM>, the diagnostic tool <NUM> sends CAN data frames containing request commands that cause one or more of the ECUs <NUM> to respond with information that is used by the diagnostic tool <NUM> to report errors or diagnose problems. Additionally, the diagnostic tool may send CAN data frames containing commands that may resets one or more error conditions on one or more ECUs <NUM>.

In this disclosure, a "splitter connector" refers to a device, cable, or harness that splits an electrical connection into two thus allowing two electrical devices to connect to the same interface. A splitter connector may include a Y-connector or a T-connector. The splitter connector <NUM> depicted in <FIG> comprises a Y-connector <NUM> for splitting a connection from the vehicle's interface port <NUM> into two connections so that both the telematics device <NUM> and the diagnostic tool <NUM> may have access to the interface port <NUM> and the CAN bus <NUM>. For example, if the telematics device <NUM> is not to be removed from the vehicle at any time or the vehicle may be in violation of some regulations, then in order to also perform some diagnostics or emission tests, the telematics device <NUM> is connected to one of the two connections provided by the splitter connector <NUM>. As a result, the diagnostic tool <NUM> may be connected to the other one of the two connections provided by the splitter connector <NUM>. In some cases, a splitter connector may be referred to as a "splitter harness".

With reference to <FIG>, there is shown an asset <NUM>' having a telematics device integrated therein as discussed above with reference to <FIG>. In this embodiment, a diagnostic tool <NUM> may be connected directly to the interface port <NUM> and gain access to the asset communications bus, such as the CAN bus <NUM>. As such, both the telematics device, which is integrated into the asset <NUM>', and the diagnostic tool <NUM> may communicate with the ECUs <NUM> of the asset <NUM>'.

In the embodiments of both <FIG> and <FIG>, there is a concern regarding a conflict between the telematics device <NUM> and the diagnostic tool <NUM> as they both communicate with the ECUs <NUM> of the asset <NUM> or the asset <NUM>' on the asset communications bus, such as the CAN bus <NUM>. The conflict may be a result of the way both the telematics device <NUM> and the diagnostic tool <NUM> interact with the assets <NUM> or <NUM>', coincidental similarities in the format of the frames exchanged, or other reasons. The telematics device <NUM> may obtain asset data <NUM> from the asset <NUM> or the asset <NUM>' in a number of ways. In some instances, the telematics device <NUM> listens to data frames broadcast or sent over the vehicle communications bus, such as the CAN bus <NUM>. The data frames may contain the asset data <NUM> that the telematics device <NUM> may use to infer the status of the asset. In other instances, the telematics device <NUM> requests the asset data <NUM> of interest thereto from the asset. Requesting the asset data <NUM> includes the telematics device <NUM> sending request frames to one or more ECU <NUM> in the asset. Upon receiving the request command frames, the one or more ECU <NUM> responds with the requested data by placing the requested asset data <NUM> on the vehicle communications bus, such as the CAN bus <NUM>.

<FIG> is a message sequence diagram <NUM> illustrating the different ways that the telematics device <NUM> captures asset information from the asset <NUM>, which may be a vehicle asset. It should be understood from <FIG> that the asset <NUM> represents a plurality of ECUs <NUM> that may broadcast asset data or send asset data in response to requests. The first way that an asset <NUM> may provide asset data <NUM> is depicted as the first alternative of the sequence diagram. The first way involves the telematics device <NUM> listening for broadcasted asset data <NUM> from the asset <NUM>. At step <NUM>, the asset <NUM> broadcasts the asset data <NUM> on the communications bus, such as the CAN bus <NUM>. Both the telematics device <NUM> and the diagnostic tool <NUM>, which are connected to the CAN bus <NUM>, may receive and consume the asset data <NUM>. For example, at step <NUM>, the diagnostic tool <NUM> consumes a first portion of the asset data <NUM> that is relevant to the function of the diagnostic tool <NUM>. Similarly, at step <NUM>, the telematics device <NUM> consumes a second portion of the asset information112 that is relevant to the function of the telematics device <NUM>. The first and second portions of the asset data <NUM> that are processed by the telematics device <NUM> and the diagnostic tool <NUM> may be the same or different. For example, the telematics device <NUM> may focus on processing real-time engine data and ignore other portions of the asset data <NUM>. Conversely, the diagnostic tool <NUM> may only process engine error codes and parameters related to emissions testing such as evaporation system and oxygen sensor data. In the first alternative of the message sequence diagram <NUM>, where the telematics device <NUM> listens for broadcasted asset data, it is unlikely that a conflict arises between the telematics device <NUM> and the diagnostic tool <NUM> when they are both listening for data frames placed on the CAN bus <NUM> by the ECUs <NUM> of the asset <NUM>.

The second way that the telematics device <NUM> may obtain the asset data <NUM> from the asset <NUM> is by directly requesting some specific data via a request command sent in a request frame over the asset communications bus, such as the CAN bus <NUM>. This way is depicted as the second alternative of the message sequence diagram <NUM> in which the telematics device <NUM> requests asset data by sending a request frame to the asset <NUM>. At step <NUM>, the telematics device <NUM> sends a request frame to the asset <NUM>. For example, the telematics device <NUM> may send a CAN data frame on the CAN bus <NUM>, wherein the CAN data frame contains a command which requests specific data from one or more ECUs <NUM> of the asset <NUM>. Due to the nature of the CAN bus <NUM> where frames are placed on the bus and are accessible by any ECU <NUM> or another device connected to the CAN bus <NUM>, the CAN data frame sent by the telematics device <NUM> may also be read by the diagnostic tool <NUM>. In some instances, the diagnostic tool <NUM> may ignore the CAN data frame sent by the telematics device <NUM> as a frame containing a payload that the diagnostic tool <NUM> is not interested in. However, in other instances, the diagnostic tool <NUM> may assume that the CAN data frame sent by the telematics device <NUM> was sent by an ECU <NUM> of the asset <NUM> and may process it at step <NUM>, which is undesirable. Processing the CAN data frame, which was sent by the telematics device <NUM>, requesting asset data <NUM>, by the diagnostic tool <NUM> is undesirable because it may lead the diagnostic tool <NUM> to deduce that the asset <NUM> is not functioning properly or is incompatible with the diagnostic tool <NUM>. In some cases, as shown in step <NUM>, the diagnostic tool <NUM> may issues an error message and/or refrain from capturing further frames containing asset data from the asset communications bus, such as the CAN bus <NUM>. As a result, the diagnostic tool <NUM> may fail to report engine error codes or complete an emissions test.

In response to receiving the request frame sent at step <NUM>, at least some of the ECUs <NUM> of the asset <NUM> may process the request frame pertaining thereto, at step <NUM>. In response to processing the information request frame, at step <NUM> the ECU(s) <NUM> which have processed the request frame may send a portion of asset data <NUM> pertaining to the request frame to the telematics device <NUM>. At step <NUM>, the telematics device <NUM> processes the portion of asset data <NUM> provided by the asset <NUM> in step <NUM>. Since the CAN bus <NUM> is a shared bus to which the diagnostic tool <NUM> is connected, the diagnostic tool <NUM> may also receive the portion of asset data <NUM> requested by the telematics device <NUM> at step <NUM>. As a result, at step <NUM> the diagnostic tool <NUM> may also process the portion of the asset data <NUM> provided by the asset <NUM>. As a result of processing the portion of the asset data <NUM> that the diagnostic tool <NUM> did not request, the diagnostic tool <NUM> may report an error or stop capturing asset data from the asset <NUM> as shown in step <NUM>.

To address the conflict arising from the telematics device <NUM> posting request frames on the communications bus of the asset <NUM>, the present disclosure proposes what is termed a non-interfering mode for the telematics device <NUM>. The non-interfering mode is a mode in which the telematics device <NUM> does not interfere or at least significantly minimizes the possibility of interfering with a diagnostic tool <NUM> connected to the same asset communications bus. In this disclosure, the "non-interfering mode" of the telematics device <NUM> may be one of two modes: a "listen-only" mode, and a "requests-blocked" mode.

In a listen-only mode, the telematics device <NUM> configures the asset interface <NUM> thereof to only listen for frames on the CAN bus <NUM>, totally refrains from sending any frames thereon, and does not acknowledge receipt of any frame on the CAN bus <NUM>. On a vehicle asset that does not have a gateway between the CAN bus <NUM> and the interface port <NUM>, a listen-only mode is an appropriate non-interfering mode. Since the telematics device <NUM> is directly connected to the CAN bus <NUM>, even if the telematics device <NUM> does not acknowledge receipt of a CAN data frame containing a portion of asset data <NUM>, other ECUs <NUM> on the CAN bus <NUM> will acknowledge receipt of the portion of asset data <NUM>. Accordingly, the ECU <NUM> which has placed that portion of asset data <NUM> on the CAN bus <NUM> may continue to place similar portions of asset data <NUM> on the CAN bus <NUM>. As discussed earlier, any data placed on the CAN bus <NUM> is available to all ECUs <NUM>. An ECU <NUM> may acknowledge receipt of the data even if that ECU <NUM> does not consume the data placed on the CAN bus <NUM>. For example, when one ECU <NUM> places data on a CAN bus <NUM> other ECUs pull an acknowledgement (ACK) bit low on the bus indicating that the data has been consumed. The ECU which placed the data on the CAN bus <NUM> does not know which other ECU (or telematics device) has consumed the data.

In some assets, there is a gateway placed between the asset communications bus and external devices. The gateway controls the asset data <NUM> available to the external devices. In some instances, the gateway requires an explicit acknowledgement of the asset data from the external devices connected to the asset communications bus via the gateway. In the event that the gateway makes some data available to external devices but does not receive an acknowledgement of that the data has been consumed by the external devices, the gateway may refrain from making portions of asset data <NUM> available to external devices going forward. In this case, the listen-only mode for the telematics device <NUM> is not an appropriate non-interfering mode. The telematics device <NUM> uses a requests-blocked mode as the non-interfering mode. To illustrate, <FIG> illustrates an asset <NUM>" incorporating a gateway <NUM> providing access to the CAN bus <NUM>. The telematics device <NUM> is connected to the asset <NUM>" via the gateway <NUM>. It may be said that the telematics device <NUM> is connected on an external CAN bus <NUM> of the asset <NUM>". In the illustrated embodiment, the interface port <NUM> is incorporated into the gateway <NUM> and is not shown as a separate component for simplicity. The gateway <NUM> may place a CAN data frame 180A on the external CAN bus <NUM> so it may be read by the telematics device <NUM>. The gateway <NUM> expects to receive an acknowledged (ACK) CAN data frame 180B in response to placing the CAN data frame 180A on the external CAN bus <NUM>. If the telematics device <NUM> does not acknowledge the CAN data frame 180A, then the gateway <NUM> may assume that no external devices are connected to the external CAN bus <NUM> and may refrain from placing further CAN data frames thereon. Accordingly, the telematics device <NUM> uses a requests-blocked mode as its non-interfering mode when connected to vehicles incorporating a gateway <NUM>. In the requests-blocked mode, the telematics device <NUM> does not explicitly send any requests to the asset <NUM>", but acknowledges any CAN data frames containing asset data when it receives same from the asset <NUM>" via the gateway <NUM>.

A telematics device may enter a non-interfering mode such as a listen-only mode or a requests-blocked mode based on a number of factors. In some embodiments, the telematics device <NUM> may receive a command from the telematics server <NUM> indicating that the asset <NUM> to which the telematics device <NUM> is coupled is in a workshop and thus may be undergoing diagnostics or maintenance. In this disclosure "workshop mode" refers to the asset <NUM> coupled to a telematics device <NUM> being in a service center or a workshop. In response to receiving the command to enter workshop mode, the telematics device <NUM> enables a non-interfering mode. In some embodiments, the telematics device enters a non-interfering mode based on detecting the connection of a diagnostic tool <NUM> thereto. This will be described in more detail below.

The command, sent by the telematics server <NUM> to the telematics device <NUM> causing it to enable workshop mode may be sent based on a number of factors. These factors include receiving an indication from the operator <NUM> indicating that the asset <NUM> is in a workshop, determining at the telematics server <NUM> that the asset <NUM> is geographically located at a workshop, and receiving a command from an administration terminal <NUM> (operated by a fleet manager <NUM>, for example) instructing the telematics server <NUM> to enable the workshop mode on the telematics device <NUM> for a specified asset <NUM>.

In some embodiments, an operator <NUM> may, using an operator terminal <NUM>, provide some input indicating that a vehicle asset is in a workshop. The user input indicating that the vehicle is in a workshop is sent to the telematics server <NUM>. In response to receiving the user input, the telematics server <NUM> may send a workshop enable command to the telematics device <NUM>.

In some embodiments, the telematics device <NUM> may report its location, as part of the telematics data, to the telematics server <NUM>. The telematics server <NUM> may determine, based on geofencing rules, that the telematics device <NUM> is located inside a zone corresponding to a workshop, garage, or maintenance facility. The telematics server <NUM> first sends a message to an administration terminal <NUM> indicating that the asset <NUM> coupled to the telematics device <NUM> is in a workshop. In response, a fleet manager <NUM> may send a command, via the administration terminal <NUM>, to the telematics server <NUM> instructing the telematics server <NUM> to send a workshop enable command to the telematics device <NUM>.

<FIG> depicts a message sequence diagram <NUM> illustrating an exemplary method of switching a telematics device <NUM> into a non-interfering mode, in accordance with embodiments of the present disclosure. At step <NUM>, the telematics device <NUM> sends telematics data <NUM> to the telematics server <NUM>. The telematics data <NUM> may include location data <NUM> and asset data <NUM> gathered from the asset <NUM>.

In some embodiments, in addition to the telematics data <NUM> received at step <NUM>, the telematics server <NUM> may receive additional input from the asset's operator <NUM>, as discussed above. For example, at step <NUM>, the operator <NUM> of the asset <NUM> may provide input via the operator terminal <NUM>, and such operator input may be sent to the telematics server <NUM>. The operator input may comprise an indication that the asset <NUM> is in the workshop for the purpose of diagnosing a problem, performing an emissions test, or for carrying out any type of maintenance. It should be noted that the operator, via the operator terminal <NUM>, has to identify the particular asset <NUM> they are operating.

At step <NUM>, the telematics server <NUM> evaluates conditions for enabling workshop mode based on the telematics data <NUM> received at step <NUM> and/or the operator input.

In some embodiments, the telematics server <NUM> may have prior knowledge of the locations of a number of service centers. The telematics server <NUM> may compare the location data <NUM> reported by the telematics device <NUM> as part of the telematics data <NUM> with the locations of service centers. For example, zones or geofences may be defined around a number of service centers and the telematics server <NUM> may determine whether the asset <NUM>, which may be a vehicle, has entered, is present at, or has exited a service center. The telematics server <NUM> may decide, based on the presence of the asset <NUM> in the zone defining the service center that it needs to enable workshop mode for telematics device corresponding to the asset <NUM> in order to avoid potential conflict with a diagnostic tool <NUM> while the asset <NUM> is at the service center location. To identify the telematics device <NUM> corresponding to an asset <NUM>, the telematics server <NUM> may query the telematics database <NUM> coupled thereto.

In some embodiments, the telematics server <NUM> may determine that workshop mode for the telematics device <NUM> needs to be enabled based on the operator input provided by the operator <NUM> at the operator terminal <NUM>, which may include an indication that the asset <NUM> is in a workshop.

In some embodiments, one or the other of the aforementioned conditions is prioritized over the other or both of them may need to be satisfied so that the telematics server <NUM> determines that workshop mode needs to be enabled.

In one embodiment, the telematics server <NUM> may determine that workshop mode is to be enabled when both the asset <NUM> is within the boundary of the zone around a service center and the operator provides input indicating that the vehicle is undergoing a service that requires the connection of a diagnostic tool.

In another embodiment, the telematics server <NUM> may determine that workshop mode is to be enabled solely based on the location data <NUM> indicating that the asset <NUM> is in a workshop.

In yet another embodiment, the telematics server <NUM> may determine that the workshop mode is to be enabled solely based on the operator input provided at the operator terminal <NUM>.

In a further embodiment (not shown), the telematics server <NUM> may determine that the workshop mode is to be enabled based on receiving a command from an administration terminal <NUM> to enable the workshop mode.

After step <NUM> is executed, either step <NUM> or step <NUM> is executed depending on the outcome of the evaluation done at step <NUM>. If, at step <NUM>, the telematics server <NUM> determines that the conditions for enabling workshop mode are satisfied then step <NUM> and step <NUM> are executed. If, at step <NUM>, the telematics server <NUM> determines that the conditions for enabling workshop mode are not satisfied, then step <NUM> is executed.

At step <NUM>, the telematics server <NUM> sends a message (or command) to the telematics device <NUM> indicating that workshop mode is to be enabled. In some embodiments (not shown), the telematics device <NUM> may send back a message to the telematics server <NUM> acknowledging receipt of the message to enable the workshop mode.

At step <NUM>, the telematics device <NUM> may enter a non-interfering mode in response to receiving the command to enable workshop mode and/or on other conditions. In some embodiments, the telematics device <NUM> may be configured to enter the non-interfering mode based solely on the enable workshop mode command received in step <NUM>. In other embodiments, the telematics device <NUM> may still perform diagnostic tool detection before entering the non-interfering mode. This will be described in further detail below.

At step <NUM>, the telematics device <NUM> evaluates other conditions for entering the requests-blocked mode, as will be described below.

At step <NUM>, the telematics device <NUM> may optionally report back to the telematics server <NUM> on the status of the operating mode thereof, i.e., whether the non-interfering mode is enabled or disabled.

In some embodiments, the method described with reference to <FIG> may be modified such that the operator terminal <NUM> communicates directly with the telematics device <NUM> over a short-range communications link such as a Bluetooth link. In such embodiment, the operator input provided in step <NUM> may comprise a command to enable workshop mode and may be sent directly to the telematics device <NUM> over the short-range communications link. In such embodiments, the telematics server <NUM> evaluates, at step <NUM>, whether the telematics device <NUM> is located in a service center only. In some embodiments, the telematics device <NUM> may prioritize an enable workshop mode command received directly from the operator terminal <NUM> and enter the non-interfering mode in response to the enable workshop mode command regardless of the enable workshop command received at step <NUM> from the telematics server <NUM>.

In some embodiments, the method described with reference to <FIG> may also be modified such that instead of the operator terminal <NUM>, it is the administration terminal <NUM> or the handheld administration terminal <NUM> that provides input to the telematics server <NUM> requesting that workshop mode be enabled for a particular asset <NUM>. For example, the operator <NUM> may use the operator terminal <NUM> to request permission to halt normal operation of the asset <NUM> and submit the asset for testing or diagnostics. The request for permission may be sent to the telematics server <NUM> and forwarded to the administration terminal <NUM> or to the handheld administration terminal <NUM>. In response, the fleet manager <NUM> may approve the testing or diagnostics for the asset <NUM> by responding, using the administration terminal <NUM>, to the telematics server <NUM> with a response authorizing the testing or diagnostics. The response approving the testing or diagnostics for the asset <NUM> may also cause the telematics server <NUM> to send a command to enable workshop mode, as described above with reference to step <NUM>.

As discussed above with reference to <FIG>, the telematics device <NUM> at step <NUM> evaluates other conditions for enabling a non-interfering mode when no workshop enable command is received from the telematics server. The telematics device <NUM> attempts to determine whether a diagnostic tool <NUM> is connected to the CAN bus <NUM> of the asset <NUM> to which it is coupled. Determining whether a diagnostic tool is connected to the CAN bus <NUM> comprises examining CAN data frames exchanged on the CAN bus <NUM>. As such, it is helpful to examine the format of a CAN data frame, which is done with reference to <FIG>. While <FIG> depicts a simplified depiction of a CAN data frame <NUM>, it would be apparent to those of skill in the art that the methods for detecting a diagnostic tool described in this disclosure may work with other types of messages.

A CAN data frame <NUM> is shown in <FIG>. The CAN data frame <NUM> consists of an arbitration field <NUM>, a control field <NUM>, a payload field <NUM>, a CRC field <NUM>, and an acknowledgement (ACK) field <NUM>.

The arbitration field <NUM> contains a CAN identifier field <NUM> and a remote transmission request (RTF) indicator (not shown). The CAN protocol requires that all contending messages have a unique identifier. A detailed description of the various fields of the CAN data frame <NUM> is beyond the scope of this disclosure. An examination of the CAN identifier field <NUM> may give insight as to whether the CAN data frame <NUM> was sent by an ECU <NUM> of the asset <NUM>, potentially by another device other than an ECU <NUM> of the asset <NUM>, or by a diagnostic tool <NUM>. In some embodiment, detecting a particular diagnostic tool entails the telematics device <NUM> inspecting the payload field <NUM> as will be described below.

<FIG> depicts a method <NUM> of configuring a telematics device <NUM> to operate in a non-interfering mode, in accordance with embodiments of the present disclosure. The method <NUM> is performed by a telematics device <NUM>, coupled to an asset <NUM>, and in communication with a telematics server <NUM>. In method <NUM>, operating in a non-interfering mode may be based on receiving a workshop enable command or on detecting a diagnostic tool connected to the communications bus of the asset to which the telematics device <NUM> is connected. The factors that the telematics device <NUM> considers may also have global flags associated therewith that either enables or disables them as will be discussed below.

At step <NUM>, the telematics device <NUM> checks whether a workshop mode enablement command similar to the one described with reference to step <NUM> above has been received. Checking for the reception of a workshop enablement command may involve receiving a message from the telematics server <NUM>. If a workshop mode enablement command has been received, control goes to step <NUM>. If, at step <NUM>, no workshop mode enable command was received, the telematics device proceeds to step <NUM>.

At step <NUM>, the telematics device <NUM> checks a diagnostic tool checking flag. If the diagnostic tool checking flag is not set, then the telematics device <NUM> is not configured to detect the presence of a diagnostic tool <NUM> connected to the asset <NUM>. If that is the case, the fact that a workshop mode enable command was received at step <NUM> is sufficient for the telematics device to enter a non-interfering mode and control goes to step <NUM>. If the diagnostic tool checking flag is set, then a diagnostic tool detection must be performed before the device may enter the non-interfering mode, and control goes to step <NUM>. Step <NUM> may be optional in some embodiments in which the workshop enable command has a higher precedence than diagnostic tool detection. As such, the decision box for step <NUM> is shown in dashed lines.

At step <NUM>, the telematics device <NUM> enters a non-interfering mode. As discussed above, the non-interfering mode may be a listen-only mode in which the telematics device <NUM> only listens for frames on the asset communications bus, such as the CAN bus <NUM> for a vehicle asset. Alternatively, the non-interfering mode may be a requests-blocked mode in which the telematics device may listen for frames on the asset communications bus and may also acknowledge such frames.

In some embodiments, when the telematics device <NUM> enters the non-interfering mode the telematics device <NUM> may save an indication that it is in the non-interfering mode in persistent storage, such as flash memory so that this mode is retained even if the telematics device <NUM> is reset.

At step <NUM>, the telematics device <NUM> checks a diagnostic tool checking flag. If the diagnostic tool checking flag is not set, then the telematics device <NUM> is not configured to detect the presence of a diagnostic tool <NUM> connected to the asset <NUM>. Since a workshop mode enable command was not received at step <NUM> and the telematics device is not configured to detect the presence of a diagnostic tool <NUM>, then control goes back to step <NUM>.

At step <NUM>, the telematics device <NUM> checks whether a CAN frame tagged with an external identifier is detected on the asset communications bus, such as on the CAN bus <NUM>. The external identifier refers to an identifier in the CAN identifier field <NUM> which is not expected to be seen on the CAN bus <NUM> when no other devices other than the ECUs <NUM> are connected. If the telematics device <NUM> does not detect an external identifier on the asset communications bus, then control goes back to step <NUM>. If an external identifier is detected on the asset communications bus, then control goes to step <NUM>.

At step <NUM>, the telematics device <NUM> evaluates a diagnostic tool detection sensitivity setting. The diagnostic tool detection sensitivity setting determines whether the telematics device <NUM> enters the non-interfering mode upon detecting any external identifier or only upon detecting a specific diagnostic tool. The diagnostic tool detection sensitivity setting may be set to a particular value by the telematics server <NUM>. In some embodiments, the fleet manager <NUM> may use the administration terminal <NUM> to configure the diagnostic tool detection sensitivity setting for a telematics device <NUM>. The telematics server <NUM> may then push the diagnostic tool detection sensitivity setting to the telematics device <NUM>.

A low sensitivity setting configures the telematics device <NUM> to enter the non-interfering mode only if a specific diagnostic tool is determined to be present on the asset communication bus, such as the CAN bus <NUM>. In one embodiment, the telematics device <NUM> determines that a specific diagnostic tool is present on the CAN bus <NUM>, when a CAN data frame <NUM> containing one of a plurality of specific external identifiers known to belong to one or more diagnostic tools is detected on the CAN bus <NUM>. The one of a plurality of specific external identifiers being detected in an identifier field, such as CAN identifier field <NUM> of the CAN data frame <NUM> are considered diagnostic tool identifiers. In another embodiment, the telematics device <NUM> determines that a specific diagnostic tool is present on the CAN bus <NUM> when the payload field <NUM> of a CAN data frame <NUM> detected on the CAN bus <NUM> contains a particular pattern known to be sent by a specific diagnostic tool or a plurality of diagnostic tools. In yet another embodiment, the telematics device <NUM> determines that a specific diagnostic tool is present on the CAN bus <NUM> when both the identifier field such as the CAN identifier field <NUM> of the CAN data frame <NUM> corresponds to a specific diagnostic tool and the payload field <NUM> of the CAN data frame <NUM> contains a pattern indicative of at least one diagnostic tool.

A high sensitivity setting configures the telematics device <NUM> to enter the non-interfering mode if any external identifier is detected on the asset communications bus, such as the CAN bus <NUM>. Specifically, the CAN identifier field <NUM> of all CAN data frames <NUM> received by the telematics device <NUM> from the CAN bus <NUM> are checked. If the telematics device <NUM> detects an identifier in the CAN identifier field <NUM> that is not expected from the ECUs <NUM> of the asset <NUM> to which the telematics device <NUM> is coupled, then the telematics device <NUM> treats this detection as a trigger to enter the non-interfering mode, when the telematics device <NUM> is configured with high-sensitivity diagnostic tool detection.

At step <NUM>, if the sensitivity is high, i.e., the sensitivity mode is not low, then control goes to step <NUM> in which the telematics device <NUM> enters the non-interfering mode since an external identifier has been detected in step <NUM>. If, at step <NUM>, the diagnostic tool detection sensitivity mode is set to low sensitivity, then control goes to step <NUM>.

At step <NUM>, telematics device <NUM> determines whether a specific diagnostic tool is present on the communications bus, such as the CAN bus <NUM> of the asset <NUM> to which the telematics device <NUM> is connected. In some embodiments, the external identifier which was detected on the asset communications bus is checked to determine whether it corresponds to a known diagnostic tool. For example, the telematics device <NUM> may compare the external identifier (i.e., the CAN identifier field <NUM> of a CAN data frame <NUM>) with a plurality of known identifiers corresponding to a plurality of commonly used diagnostic tools. Alternatively, or additionally, the telematics device may inspect the payload field <NUM> of the CAN data frame <NUM> to check for particular patterns that are indicative of one or more known diagnostic tools. If there is a match with a known external identifier known to belong to one or more known diagnostic tools or a pattern in the payload field <NUM> that is indicative of one or more diagnostic tools is detected, the telematics device <NUM> determines that a known diagnostic tool is present on the asset communications bus, such as the CAN bus <NUM> and control goes to step <NUM> where the telematics device <NUM> enters the non-interfering mode. If there is no match between the external identifier which was detected on the asset communications bus and the plurality of known identifiers corresponding to the plurality of commonly used diagnostic tools, and no pattern in the payload field <NUM> is indicative of a commonly used diagnostic tool, then the telematics device determines that no known diagnostic tool is present on the CAN bus <NUM>. In the latter case, control goes back to step <NUM>. As discussed above, determining the presence of a diagnostic tool <NUM> may be based on contents of the CAN identifier field 1004of a broadcast frame, on contents of the payload field <NUM> of the broadcast frame, or on both.

The method <NUM> described above may be repeated periodically, by the telematics device <NUM>, to ensure the proper detection of either being in a workshop or having a diagnostic tool <NUM> connected to the asset, and to ensure that the non-interfering mode is adequately entered. Advantageously, interfering with the operation of the diagnostic tools is averted as discussed above.

Configuring the telematics device <NUM> is in the non-interfering mode has the advantage of avoiding interfering with the operation of a diagnostic tool <NUM>. However, configuring the telematics device <NUM> in the non-interfering mode limits the asset data <NUM> gathered by the telematics device <NUM> from the asset <NUM>. This is because some asset data <NUM> are only sent by the ECUs <NUM> in response to requests for such data. In a non-interfering mode, the telematics device <NUM> is either in a listen-only mode or in a requests-blocked mode, both of which do not allow the telematics device <NUM> to make explicit requests for some asset data <NUM> provided by the ECUs <NUM>. Accordingly, the telematics device <NUM> needs to exit the non-interfering mode whenever it is not necessary to be in that mode in order not to miss capturing asset data <NUM> unnecessarily as some of the asset data <NUM> may contain important information about the operation of the asset <NUM>. Both the telematics server <NUM> and the telematics device <NUM> may periodically evaluate the conditions that led to the telematics device <NUM> to operate in the non-interfering mode. For example, the telematics server <NUM> may periodically evaluate whether the telematics device <NUM> is still geographically located in a workshop or if it has received an indication from an operator terminal <NUM> indicating that the telematics device <NUM> is no longer in a workshop. The telematics device <NUM> may periodically check the CAN data frames <NUM> on the CAN bus to determine whether the conditions that led to the telematics device <NUM> entering the non-interfering mode are no longer satisfied. <FIG> depicts a message sequence diagram illustrating a method <NUM> for disabling the non-interfering mode based on conditions evaluated both at the telematics server <NUM> and at the telematics device <NUM>, in accordance with embodiments of the present disclosure.

At step <NUM>, the telematics device <NUM> sends telematics data <NUM> as described above with reference to step <NUM>. The telematics server <NUM> receives the telematics data <NUM>. The telematics data <NUM> may contain location data <NUM> for the telematics device <NUM>.

At step <NUM>, the operator terminal <NUM> may send operator input to the telematics server <NUM>. The operator input sent at step <NUM> may comprise an indication that maintenance performed on an asset <NUM> coupled to the telematics device <NUM> has been concluded, or that the asset <NUM> is no longer in a service center, such as a workshop. The operator input sent at step <NUM> is received by the telematics server <NUM>. In another embodiment (not shown), the fleet manager <NUM> provides input on an administration terminal <NUM> indicating that a particular asset <NUM> is no longer undergoing maintenance. The input is sent from the administration terminal <NUM> to the telematics server <NUM> in a manner similar to what is described herein with reference to step <NUM>.

At step <NUM>, the telematics server <NUM> evaluates the conditions that determine whether the telematics device <NUM> should exit out of workshop mode. The telematics server <NUM> evaluates the telematics data <NUM> including the location of the telematics device <NUM> which is also the location of the asset <NUM> to which the telematics device is coupled. For example, as discussed above with reference to step <NUM> of <FIG>, the telematics server <NUM> may determine whether the asset <NUM> is located inside a zone corresponding to a service center. If the location data <NUM> included in the telematics data <NUM> received by the telematics server <NUM> indicates that the asset <NUM> is no longer located at a service center, the telematics server <NUM> may determine that the telematics device <NUM> needs to exit from workshop mode. In some embodiments, the telematics server <NUM> determines that the asset <NUM> needs to exit from workshop mode in response to receiving the operator input in step <NUM>. For example, the telematics server <NUM> may determine that the telematics device <NUM> needs to exit from workshop mode in response to receiving an operator input indicating that the vehicle is no longer undergoing any diagnostics or maintenance. In other embodiments, the telematics server <NUM> may determine that the telematics device <NUM> needs to exit workshop mode based on both the operator input and the telematics data <NUM>. If the telematics server <NUM> determines that the telematics device <NUM> needs to exit from workshop mode, i.e., that the conditions for disabling workshop mode are satisfied then control goes to step <NUM>. If the telematics server <NUM> determines that the conditions for disabling workshop mode are not satisfied, then control goes to step <NUM>.

At step <NUM>, the telematics server <NUM> sends a workshop mode disable command to the telematics device <NUM>. The telematics device <NUM> receives the workshop mode disable command.

At step <NUM>, the telematics device <NUM> may exit the non-interfering mode in response to receiving the command to disable workshop mode from the telematics server <NUM> after evaluating other conditions for the non-interfering mode. This is explained in further detail below.

In the absence of receiving a command to disable workshop mode, as in step <NUM>, at step <NUM> the telematics device <NUM> may evaluate other conditions which determine whether or not the telematics device <NUM> should exit the non-interfering mode. This is explained further below with reference to <FIG>.

The method described in <FIG> may be modified, in accordance with some embodiments. In some embodiments, the operator terminal <NUM> may communicate directly with the telematics device <NUM> and control whether it exits workshop mode. For example, the operator <NUM> may know immediately when the asset <NUM> is no longer undergoing diagnostics although it is still geographically located in a service center. Accordingly, the operator <NUM> may cause the operator terminal <NUM> to send a message to the telematics device <NUM> causing it to exit workshop mode irrespective of its location. In some embodiments, the operator terminal <NUM> may be connected with the telematics device <NUM> over a short-range communications link, such as Bluetooth.

In other embodiments, the method of <FIG> may employ an administration terminal <NUM> or a handheld administration terminal <NUM> in place of the operator terminal <NUM>. In such embodiments, the fleet manager <NUM> may use the administration terminal <NUM> or handheld administration terminal to provide input to the telematics server <NUM> that may result in the telematics server <NUM> sending a command to disable workshop mode to a telematics device <NUM>. In some embodiments, the administration terminal <NUM> or handheld administration terminal <NUM> respond to a request to exit workshop mode and the response to the telematics server <NUM> authorizing exiting the workshop mode causes the telematics server <NUM> to send a command to disable workshop mode at a telematics device <NUM>, as described above in step <NUM>.

<FIG> is a flow chart depicting a method <NUM> for disabling a requests-blocked mode in a telematics device <NUM>, in accordance with embodiments of the present disclosure.

At step <NUM>, the telematics device <NUM> checks whether a command to disable workshop mode has been received, for example from the telematics server <NUM>. If a command to disable workshop mode has been received, control goes to step <NUM>. If a command to disable workshop mode has not been received, control goes to step <NUM>.

At step <NUM>, the telematics device <NUM> checks whether it is configured to also check for diagnostic tool connectivity. This step may involve checking a configuration flag. If the telematics device <NUM> was configured to check for diagnostic tool connectivity, then the telematics device <NUM> may still wish to check whether a diagnostic tool is connected to the asset communications bus and control goes to step <NUM>. Conversely, if at step <NUM>, it is determined that checking for diagnostic tool presence on the asset communications but is not necessary, then control goes to step <NUM>. The configuration which is checked at step <NUM> determines whether a workshop disable command should take precedence over determining whether a diagnostic tool is present on or connected to the asset communications bus, when determining whether to disable the non-interfering mode of the telematics device <NUM>.

At step <NUM>, the telematics device <NUM> determines whether it is in a mode which checks for diagnostic tool connectivity. This step is similar to step <NUM>. If the configuration flag is set, then control goes to step <NUM> to proceed with steps that check for diagnostic tool connectivity. If, at step <NUM>, the telematics device <NUM> determines that it does not need to check for diagnostic tool connectivity, then control goes back to step <NUM>.

The configuration flag checked in steps <NUM> and <NUM> may be considered a master switch for diagnostic tool detection. The master switch may enable or disable scan tool detection. When scan tool detection is disabled, the telematics device <NUM> enters or exits the non-interfering mode based solely on the workshop mode enable command and workshop disable command, respectively.

Checking whether the telematics device <NUM> should exit the non-interfering mode based on diagnostic tool connectivity involves exiting the non-interfering mode if no traffic from a diagnostic tool is detected for a particular period of time, which may be referred to as the idle time. Accordingly, the telematics device <NUM> may set a timer after the last frame or packet is received from a diagnostic tool or after the last frame with an external identifier is detected. If no other packets or frames are received from the diagnostic tool or having an external identifier for the duration of the timer, then upon the expiry of the timer the telematics device <NUM> exits the non-interfering mode. Packet or frames received from a diagnostic tool are identified by external identifiers or by patterns in their payload as described above.

At step <NUM>, an idle duration timer is started. The idle duration timer is used to trigger exiting the non-interfering mode when no external identifiers are detected for an idle duration based on the sensitivity setting of the telematics device <NUM> as described further below. The idle duration may be set to a predetermined period. For example, the idle duration may be set to <NUM> minutes.

At step <NUM>, the telematics device <NUM> checks whether a frame containing an external identifier is detected. If no frames with an external identifier are detected, then control goes to step <NUM>. Otherwise, if at least one frame with an external identifier is detected, then control goes to step <NUM>.

At step <NUM>, the telematics device <NUM> checks whether the diagnostic tool detection sensitivity is low or high. If the diagnostic tool detection sensitivity is high, that means that the device has entered the non-interfering mode based on the detection of any external identifier. Accordingly, if the condition at step <NUM> is false, then the received external identifier should cause the telematics device <NUM> to remain in the non-interfering mode. Additionally, the idle timer should be restarted. Therefore, if the condition at step <NUM> is false, control goes back to step <NUM>.

If the condition at step <NUM> is true, then the telematics device <NUM> has only entered the non-interfering mode in response to receiving an external identifier that corresponds to a diagnostic tool <NUM> or detected a pattern corresponding to a diagnostic tool <NUM> in the payload field <NUM> of a CAN data frame <NUM>. In this case, control goes to step <NUM>.

At step <NUM>, the external identifier detected at step <NUM> is checked to determine whether it corresponds to a diagnostic tool <NUM>. Alternatively, or additionally, the payload field <NUM> of the corresponding frame may be checked for a pattern corresponding to the diagnostic tool <NUM>. If the external identifier detected corresponds to a diagnostic tool <NUM> or if the payload field <NUM> contains a pattern corresponding to the diagnostic tool, then the telematics device <NUM> needs to remain in the non-interfering mode. Furthermore, the idle duration timer needs to be restarted. Accordingly, control goes to step <NUM>.

If, at step <NUM>, it is determined that the received frame does not contain an indication that it corresponds to a diagnostic tool <NUM>, then control goes to step <NUM>.

At step <NUM>, the telematics device <NUM> has determined that it has not received an indication that a diagnostic tool <NUM> is currently connected to the asset communications bus. However, the telematics device <NUM> does not exit the non-interfering mode until sufficient time has passed during which it has not received an indication that a diagnostic tool <NUM> is not connected to the asset communications bus. This accounts for situations where a diagnostic tool <NUM> may pause sending messages (e.g., packets or frames) on the asset communications bus, such as CAN bus <NUM> to perform some computations or display some reports. Accordingly, the telematics device <NUM> remains in the non-interfering mode until the idle duration has expired without receiving any external identifiers that would require the telematics device to exit the requests-blocked mode. At step <NUM>, the telematics device <NUM> checks whether the idle duration timer has expired.

If, at step <NUM>, the idle duration timer has not expired, then control goes back to step <NUM> to check for another received frame, such as a CAN data frame <NUM> and determine whether the received frame contains an indication that a diagnostic tool <NUM> is still present on the asset communications bus.

If, at step <NUM>, the idle duration timer has expired, then this indicates that a sufficient time has passed without the telematics device <NUM> receiving any indication of a diagnostic tool connected to the asset communications bus. In response, control goes to step <NUM> where the telematics device exits the non-interfering mode. When the telematics device <NUM> exists the non-interfering mode at step <NUM>, the telematics device <NUM> may save an indication that it is no longer in the non-interfering mode in persistent storage, such as flash memory so that this mode is retained even if the telematics device <NUM> is reset.

As discussed above, the telematics device <NUM> may be deployed in a vehicle asset. Under normal operation, when the vehicle's ignition is enabled, the telematics device <NUM> draws power from the vehicle's interface port <NUM>, which may be an OBD port. However, when a vehicle's ignition is disabled, the telematics device <NUM> may enter into one or more power-saving modes in which the telematics device <NUM> powers down many of the peripherals thereof and wakes up periodically. One of the peripherals which may be powered down is the network interface <NUM>. The telematics device <NUM> enters the one or more power saving modes to avoid draining the battery of the vehicle to which it is coupled.

A first power-saving mode may involve a relatively short wake-up period. For example, the telematics device <NUM> may enter a first power-saving mode, such as a sleep mode, and wake up every <NUM> minutes. When the telematics device wakes up, it powers up the network interface <NUM> and, among other activities, connects with the telematics server <NUM>. When the telematics device connects with the telematics server <NUM>, any pending commands that the telematics server <NUM> had attempted to send to the telematics device <NUM> while the network interface was powered down, are sent to the telematics device <NUM> when the telematics device <NUM>. This may include a workshop disable command that is intended to take the telematics device <NUM> out of the non-interfering mode. If the workshop disable command is sent, by the telematics server <NUM>, to the telematics device <NUM> at the start of a sleep period, it may take up to <NUM> minutes for the telematics device <NUM> to wake up, receive the workshop disable command, and exit the non-interfering mode. Under normal operation, the telematics device <NUM> wakes up and prematurely ends the sleep period if the ignition of the vehicle is turned on. While an ignition may be detected when the telematics device <NUM> is in normal operation, when the telematics device is in a non-interfering mode, ignition detection may be impaired as it relies on requests which are blocked in the non-interfering mode. For example, if the telematics device <NUM> cannot request the RPM of an internal combustion engine or an ignition signal for an electric vehicle, then the telematics device <NUM> will not wake up until the expiry of the sleep duration. As a result, a vehicle may be started and become operational, but the telematics device <NUM> remains in sleep mode and fails to capture some of the asset data <NUM>.

When a vehicle is parked for an extended period of time, the telematics device <NUM> may enter a second power-saving mode in which the telematics device wakes up far less frequently than the first power-saving mode. For example, in the second power-saving mode, the telematics device <NUM> may wake up every <NUM> hours. When the telematics device <NUM> is in sleep mode for <NUM> hours, for example, the problem described above with the failure to capture some of the asset data <NUM> is even more pronounced. Since the network interface, <NUM>, is powered-off for <NUM> hours, potentially up to <NUM> hours of asset data <NUM> are not captured by the telematics device <NUM> due to the inability of the telematics device <NUM> to detect the ignition, exit sleep mode, and receive the workshop disable command from the telematics server <NUM>.

In some instances, the telematics device <NUM> is configured to remain in sleep mode indefinitely and solely rely on the ignition detection mechanism to take the telematics device <NUM> out of sleep mode. In cases where the telematics device <NUM> is in a non-interfering mode and ignition detection is not possible, the telematics device <NUM> may remain in sleep mode for an indefinite amount of time.

In the aforementioned cases where the telematics device <NUM> may be in a low-power (or sleep) mode for an extended period of time and is unable to detect an ignition signal from the vehicle, methods of waking up the telematics device <NUM> other than the ignition signal are contemplated.

In some embodiments, the telematics device <NUM> is configured to wake-up on motion. For example, the sensors <NUM> may include at least one motion sensor such as an accelerometer. The telematics device <NUM> may be configured to wake up from sleep mode when the accelerometer detects movement that is above a particular threshold, such as <NUM> (where g = <NUM>/s<NUM>). In this case, if the vehicle to which the telematics device <NUM> is coupled is driven, the accelerometer detects the movement and causes the telematics device <NUM> to wake up. Upon wake up, the telematics device is able to receive a command to disable workshop mode from the telematics server <NUM>. In some embodiments, the feature which allows the telematics device <NUM> to wake up from sleep is disabled by a command from the telematics server <NUM>. For example, a vehicle may be transported on a rough road with many potholes. A fleet manager <NUM> may use an administration terminal <NUM> to instruct the telematics server <NUM> to disable the wake up on movement feature for a telematics device <NUM> so that the telematics device <NUM> does not drain the vehicle's battery. If the telematics device <NUM> is in a non-interfering mode, then the telematics device <NUM> may ignore the command to disable the wake up on movement feature to prevent a situation of having the telematics device <NUM> stuck indefinitely in sleep mode.

In some embodiments, when a telematics device <NUM> remains in sleep mode for an extended duration while in the non-interfering mode, the telematics device <NUM> may automatically disable the non-interfering mode and return to normal mode of operation. For example, the telematics device <NUM> may set a timer that expires after <NUM> hours or <NUM> hours when the non-interfering mode is enabled. If the timer expires and the non-interfering mode is still enabled, the telematics device <NUM> may autonomously disable the non-interfering mode.

<FIG> is a flowchart for a method <NUM> for enabling a non-interfering mode in a telematics device, in accordance with embodiments of the present disclosure. The method <NUM> starts at step <NUM>.

At step <NUM>, a telematics server <NUM> determines that a telematics device <NUM> coupled to an asset communications bus, such as a CAN bus <NUM>, must operate in a non-interfering mode.

At step <NUM>, the telematics server <NUM> sends, for example over a network <NUM>, to the telematics device <NUM> a command to cause the telematics device <NUM> to operate in the non-interfering mode.

At step <NUM>, the telematics device <NUM> enables the non-interfering mode thereon in response to receiving the command from the telematics server <NUM>.

<FIG> is a flowchart for a method <NUM> for disabling a non-interfering ode in a telematics device <NUM>, in accordance with embodiments of the present disclosure. The method starts at step <NUM>.

At step <NUM>, the telematics server <NUM> determines the telematics device <NUM> coupled to an asset communications bus, such as the CAN bus <NUM> of the asset <NUM> must not operate in a non-interfering mode.

At step <NUM>, the telematics server <NUM> sends a command to the telematics device <NUM> to cause the telematics device <NUM> to disable the non-interfering mode.

At step <NUM>, telematics device <NUM> disables the non-interfering mode in response to receiving the command from the telematics server <NUM>.

Claim 1:
A method, comprising:
operating a telematics device (<NUM>) coupled to an asset communications bus (<NUM>) of an asset (<NUM>) in a first mode in which the telematics device (<NUM>) obtains asset data (<NUM>) by sending request frames to the asset (<NUM>);
determining, by a telematics server (<NUM>), that the telematics device (<NUM>) must operate in a non-interfering mode in which the telematics device (<NUM>) does not send request frames to the asset (<NUM>);
sending, by the telematics server (<NUM>), to the telematics device (<NUM>), a command to cause the telematics device (<NUM>) to operate in the non-interfering mode; and
enabling the non-interfering mode, by the telematics device (<NUM>) in response to receiving the command from the telematics server (<NUM>);
wherein determining that the telematics device (<NUM>) must operate in the non-interfering mode comprises:
receiving, at the telematics server (<NUM>), a user input from an operator terminal (<NUM>), the user input comprising an indication that the telematics device (<NUM>) must operate in the non-interfering mode; or
determining, at the telematics server (<NUM>), that a location of the telematics device (<NUM>) is within a zone defining a service center.