Patent Description:
A telematics system may gather asset data using a telematics device. The telematics device may be integrated into or located onboard the asset. The asset may be a vehicle ("vehicular asset") or some stationary equipment. The telematics device may collect the asset data from the asset through a data connection with the asset. In the case of a vehicular asset, the telematics device may gather the asset data through an onboard diagnostic port. The gathered asset data may include engine 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 document <CIT> "VEHICLE TRAVEL DIRECTION ESTIMATION DEVICE" discloses a vehicle travel direction estimation device.

Patent document <CIT> "Reversing vehicle remote telematics detection" discloses a reverse detection method.

In one aspect of the present invention, there is provided a method in accordance with appended claim <NUM>.

Sending the reversing determination model update to the second telematics device may be done periodically.

Sending the reversing determination model update to the second telematics device may be done in response to an improvement in an output confidence level of the central reversing determination machine-learning model.

Sending the reversing determination model update to the second telematics device is done in response to an update request from the second telematics device.

Capturing the captured acceleration data may be done in response to a synchronous event.

Capturing the captured acceleration data may comprise copying sampled accelerometer readings from accelerometer First-In-First-Out buffers after the synchronous event.

Capturing the captured acceleration data comprises copying sampled accelerometer readings from accelerometer First-In-First-Out buffers prior to the synchronous event.

Capturing the training acceleration data may be in response to a trigger event that consists of a vehicle-reversing indication.

Capturing the training acceleration data may comprise capturing post-trigger event acceleration data.

Capturing the training acceleration data may comprise capturing pre-trigger event acceleration data and post-trigger event acceleration data.

Capturing pre-trigger event acceleration data may comprise copying sampled accelerometer readings from accelerometer First-In-First-Out buffers prior to the trigger event.

Capturing post-trigger event acceleration data may comprise copying sampled accelerometer readings from accelerometer First-In-First-Out buffers after the trigger event and before an expiry of a post-trigger duration timer.

The method may further comprise logging, by the telematics server, the machine-learning-determined reversing indication for the second vehicle in a telematics database coupled to the telematics server.

The method may further comprise sending, by the second telematics device, the machine-learning-determined reversing indication for the second vehicle to the telematics server.

In yet another aspect of the present invention, there is provided a telematics system, in accordance with appended claim <NUM>.

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

A large telematics system may collect data from a high number of assets, either directly or through telematic devices. A telematics device may refer to a self-contained device installed at an asset, or a telematics device that is integrated into the asset itself. In either case, it may be said that 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 (collectively referred to as the 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 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>, using a network interface thereof (not shown), 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 have 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 and/or 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>. 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. 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 track or configure the usage of 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> 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 currently being 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.

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 telematics 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 administration terminal <NUM> to inform a fleet manager <NUM>, and may optionally send alerts to the operator terminal <NUM> to notify an operator <NUM> of the alert. For example, an operator <NUM>, who is operating the vehicle outside of a service area or hours of service may receive an alert on their operator terminal <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> connected thereto. Selected relevant components 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, a few of the ECUs <NUM> are depicted in <FIG>. For example, in the depicted embodiment the asset <NUM> has three electronic control units: the ECU 110A, the ECU 110B, and the ECU 110C ("ECUs <NUM>"). The ECU 110A, the ECU 110B, and the ECU 110C are shown to be interconnected via an asset communications bus. One example of the asset communications bus is a controller area network (CAN) bus. For example, the telematics device <NUM> is shown to have a CAN bus <NUM>. ECUs <NUM> interconnected using a CAN bus may send and receive information to one another in CAN frames by placing the information on the CAN bus <NUM>. When an ECU places information on the CAN bus <NUM>, other ECUs <NUM> receive the information and may or may not consume or use that information. Different protocols 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 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 memory <NUM> may include read-only-memory (ROM), random access memory (RAM), flash memory, magnetic storage, optical storage, and similar, or any combination thereof, for storing machine-executable programming instructions and data to support the functionality described herein. The memory <NUM> is coupled to the controller <NUM> thus enabling the controller <NUM> to execute the machine-executable programming instructions stored in the memory <NUM>. The memory <NUM> may contain machine-executable programming instructions, which when executed by the controller <NUM>, configures the telematics device <NUM> for receiving asset data <NUM> from the asset <NUM> via the asset interface <NUM>, and for receiving sensor data <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>.

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

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

The NFC module <NUM> may be an NFC reader which can read information stored on an NFC tag. The NFC module <NUM> 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 include a universal serial bus (USB) transceiver.

In operation, an ECU <NUM>, such as the ECU 110A, the ECU 110B, or the ECU 110C communicates asset data over the CAN bus <NUM>. The asset data exchanged between the ECUs <NUM>, over the CAN bus <NUM> are accessible via the interface port <NUM> and may be retrieved as the asset data <NUM> by the telematics device <NUM>. The controller <NUM> of the telematics device <NUM> receives the asset data <NUM> via the asset interface <NUM>. The controller <NUM> may also receive sensor data <NUM> from the sensors <NUM> and/or location data <NUM> from the location module <NUM> over the sensor interface <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> for providing location information thereto.

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

One of the most dangerous activities vehicle drivers do is backing up or reversing. It has been reported (by Secure Insurance, for example) that approximately one in four vehicle accidents occur when drivers are going in reverse. The US National Highway Transportation Safety Agency (NHTSA) reports an average of <NUM> fatalities and <NUM>,<NUM> injuries are caused by back-up accidents each year. The fatalities and injuries may also be accompanied by vehicle damage. Fleet owners and managers, therefore, wish to monitor and track reversing events in vehicles of their fleets. Many vehicles provide a reverse gear indication as part of the asset data <NUM>. For example, a vehicle transmission ECU coupled to the vehicle's transmission may detect when the transmission is configured in the reverse gear ("R") and generate a reverse gear indication <NUM>. The reverse gear indication <NUM> may be sent over the vehicle's communications bus, such as the CAN bus <NUM> and captured by a telematics device <NUM> over the interface port <NUM>. Alternatively, if the telematics device <NUM> is integrated into the vehicle, the reverse gear indication <NUM> may be directly received by the controller <NUM> as part of the asset data <NUM>. A reverse gear indication <NUM> by itself is not an indication that the vehicle is reversing. The vehicle speed indication is combined with the reverse gear indication to determine whether the vehicle is reversing, i.e., moving in the reverse direction. For example, vehicle reversing may be defined as a vehicle moving in the reverse direction by a current speed that is greater than about <NUM>. In the context of this disclosure, about <NUM> is defined as a speed which is above <NUM> and above a very low threshold. For example, about <NUM> may be defined as a speed of <NUM>/h.

In some embodiments, a telematics device <NUM> may combine a vehicle speed <NUM> which is greater than about <NUM> (e.g., <NUM>/h or higher) with a reverse gear indication to conclude that the vehicle is reversing. The telematics device <NUM> may derive a vehicle-provided reversing indication <NUM> from the vehicle speed <NUM> and the reverse gear indication <NUM>, as shown in <FIG>. IN response to concluding that the vehicle is reversing, the telematics device <NUM> may sound an alarm or playback a message to the driver indicating that the vehicle is reversing. In other embodiments, the telematics device <NUM> may, additionally or alternatively, include the reverse gear indication <NUM> and vehicle speed <NUM> as part of the telematics data <NUM> sent to the telematics server <NUM>. In this case, the telematics server <NUM> may determine that the vehicle is reversing, and record and analyze the reversing events made by a particular vehicle. A fleet manager <NUM>, for example, may indicate to some vehicle drivers that their reversing is excessive or unnecessary and that they should find better ways to park and maneuver their vehicles. In some embodiments, the telematics server <NUM> may send a message to the operator terminal <NUM> for alerting the operator <NUM> regarding their reversing events either in real-time or at a later time.

While many vehicles report a reverse gear indication <NUM> as part of the asset data <NUM>, many other vehicles do not. Accordingly, the telematics device <NUM> may need to rely on the sensors <NUM> to detect that the vehicle is moving in reverse direction. <CIT> ("'<NUM>") discloses a telematics device, deployed in a vehicle, the telematics device being capable of detecting when the vehicle is reversing. Specifically, the telematics device of the `<NUM> patent detects an autonomously sensed change in a vehicle's operational state from an initial state to a subsequent state. At the initial state, the vehicle's speed equals about <NUM> (i.e., <NUM>/h or less, for example). At the subsequent state, the vehicle's speed is greater than about <NUM>, and an accelerometer disposed in the telematics device indicates that the vehicle is moving in a longitudinal reverse direction.

The method by the telematics device in the '<NUM> patent works in a telematics device having an accelerometer oriented along the longitudinal axis of the vehicle. Additionally, the forward and reverse directions need to be known so that the telematics device may determine that the vehicle is in reverse motion. This is not always the case. A telematics device <NUM> may be installed below the dashboard of a vehicle connected to an interface port <NUM> or may be attached at the end of a harness connected to the interface port <NUM>. In either case, there is no guarantee that a particular accelerometer of the telematics device <NUM> will be oriented along the longitudinal axis of the vehicle. For example, with reference to <FIG>, a telematics device <NUM> may have an inertial measurement unit (IMU), such as the IMU <NUM> including a three-axis accelerometer <NUM> installed therein. In some embodiments, the IMU <NUM> may also include a gyroscope <NUM>. The IMU <NUM> may be part of the sensors <NUM> or a separate component. The three-axis accelerometers <NUM>, may be comprised of three accelerometers in the X-, Y-, and Z-direction, as shown in <FIG>. While the X-axis accelerometer may be oriented along the longitudinal axis of the telematics device <NUM>, this may not always be the case. Additionally, with reference to <FIG>, a telematics device <NUM> may be deployed in a vehicle and may have any orientation, particularly if it is connected to the interface port <NUM> via a harness. It is, therefore, challenging to identify which accelerometer in the three-axis accelerometer <NUM> represents motion along the longitudinal axis of the vehicle. It is also challenging to determine the forward and reverse directions since it is not clear to the telematics device where the front and rear of the vehicle are. Furthermore, vehicles do not always back up in a straight line. In many instances when a vehicle is backing up from a parking position, the vehicle is reversing in a curved path. Accordingly, two accelerometers in the X-Y plane may report acceleration readings during a reversing event thus making it difficult to identify motion along the longitudinal axis and thus making it more difficult to ascertain that the vehicle is reversing.

In this disclosure, the inventors have proposed new methods and systems for detecting vehicle reversing events. The methods and systems utilize artificial intelligence and in particular machine learning techniques. For example, with reference to <FIG>, there is shown a conceptual diagram for determining a machine-learning-determined reversing indication <NUM> using machine learning, in accordance with embodiments of the present disclosure. A central reversing determination machine-learning model <NUM> may be located at a server in a centralized location within a system. For example, the central reversing determination machine-learning model <NUM> may be located on the telematics server <NUM> within the telematics system <NUM>. The central reversing determination machine-learning model <NUM> is provided with captured acceleration data <NUM> captured by a three-axis accelerometer <NUM> which is part of an IMU <NUM> deployed in an asset <NUM> either directly or as part of a telematics device <NUM> deployed in the asset <NUM>. The manner in which the captured acceleration data <NUM> is captured is described below. The telematics device <NUM> sends the captured acceleration data <NUM> as part of the sensor data <NUM> included in the telematics data <NUM> sent to the telematics server <NUM>. The central reversing determination machine-learning model <NUM> has a plurality of model parameters which need to be calibrated in order to accurately predict the machine-learning-determined reversing indication <NUM>. Calibrating an ML model's parameters is done by training the model. The central reversing determination machine-learning model <NUM> may be trained as described below with reference to <FIG>.

<FIG> depicts a conceptual diagram depicting the training of the central reversing determination machine-learning model <NUM>. The central reversing determination machine-learning model <NUM> is trained using training data. Training data is comprised of labelled data, or input data for which the corresponding ML model output is known and that corresponding ML model output. In the depicted embodiment, the central reversing determination machine-learning model <NUM> is trained by training data comprising training acceleration data <NUM> and a vehicle-provided reversing indication <NUM> corresponding to the training acceleration data <NUM>. The training data is gathered from vehicles providing a reverse gear indication <NUM> and a vehicle speed <NUM> as part of the asset data <NUM>. A vehicle providing the training data includes a telematics device <NUM> having an IMU <NUM> including a three-axis accelerometer <NUM>. When the vehicle's engine reports a reverse gear indication <NUM> and a vehicle speed indication indicating a vehicle speed which is greater than about <NUM>/h, it can be concluded that the vehicle is reversing. Accordingly, a vehicle-provided reversing indication <NUM> comprises a reverse gear indication <NUM> and a vehicle speed <NUM> indicating that the vehicle speed is greater than about <NUM>/h. The vehicle-provided reversing indication <NUM> represents a known output label, which may be provided to the central reversing determination machine-learning model <NUM> as part of the training data. The training acceleration data <NUM> represents accelerometer data corresponding to the vehicle moving in a reverse direction as indicated by the vehicle-provided reversing indication <NUM>. Accordingly, the training data comprising the vehicle-provided reversing indication <NUM> and the training acceleration data <NUM> train the central reversing determination machine-learning model <NUM> by fine tuning the parameters thereof. As the central reversing determination machine-learning model <NUM> is better trained, the central reversing determination machine-learning model <NUM> is able to analyze captured acceleration data <NUM> from vehicles which do not include a reverse gear indication <NUM> and determine a machine-learning-determined reversing indication <NUM>. The output prediction certainty of the machine-learning-determined reversing indication <NUM> is increased as the central reversing determination machine-learning model <NUM> is further trained with training data comprising the training acceleration data <NUM> and the vehicle-provided reversing indication <NUM> corresponding to the training acceleration data <NUM>.

A three-axis accelerometer <NUM> deployed in a vehicle as part of an IMU <NUM> either installed directly in the vehicle or is part of a telematics device <NUM> coupled to the vehicle may be represented as shown in <FIG>. The three-axis accelerometer <NUM> of <FIG> may be comprised of three accelerometers: an X-axis accelerometer <NUM>, a Y-axis accelerometer <NUM>, and a Z-axis accelerometer <NUM>. Accelerometers detect and report acceleration in real-time at a particular sampling rate. For example, each of the X-axis accelerometer <NUM>, the Y-axis accelerometer <NUM>, and the Z-axis accelerometer <NUM> may have a sampling rate of <NUM> or <NUM>. Sampled accelerometer readings generated by each accelerometer may be buffered in a First-In-First-Out (FIFO) buffer. For example, as shown in <FIG>, the X-axis accelerometer <NUM> generates sampled X-axis acceleration readings <NUM> which are buffered in the X-axis accelerometer FIFO buffer <NUM>. Similarly, the Y-axis accelerometer <NUM> generates sampled Y-axis acceleration readings <NUM> which are buffered in the Y-axis accelerometer FIFO buffer <NUM> and the Z-axis accelerometer <NUM> generates sampled Z-axis acceleration readings <NUM> which are buffered in the Z-axis accelerometer FIFO buffer <NUM>. The controller <NUM> of the telematics device <NUM> reads buffered acceleration readings from the X-axis accelerometer FIFO buffer <NUM>, the Y-axis accelerometer FIFO buffer <NUM>, and the Z-axis accelerometer FIFO buffer <NUM>. The telematics device <NUM> may send the buffered acceleration readings from the three accelerometers to the telematics server <NUM>.

In order to better understand the nature of the captured acceleration data <NUM> and the training acceleration data <NUM>, an overview of how the acceleration readings are buffered is helpful. <FIG> illustrates the operation of an accelerometer FIFO buffer <NUM> which is similar to the X-axis accelerometer FIFO buffer <NUM>, the Y-axis accelerometer FIFO buffer <NUM>, and the Z-axis accelerometer FIFO buffer <NUM> described above. With reference to the accelerometer FIFO buffer <NUM>, a first sampled acceleration reading from an accelerometer is stored in the accelerometer FIFO buffer <NUM> at the first FIFO location <NUM> at a first sampling time. On the second sampling time, the contents of the accelerometer FIFO buffer <NUM> are shifted to the right and the second sampled acceleration reading from the accelerometer is stored at the first FIFO location <NUM>. Assuming the FIFO buffer <NUM> has a size of N storage locations, then at the Nth sampling time, the first sampled acceleration reading has shifted N times until it is at the last FIFO location <NUM> and the Nth sampled acceleration reading is at the first FIFO location <NUM>. After the accelerometer FIFO buffer <NUM> is full, further shifting of the contents of the accelerometer FIFO buffer <NUM> to the right will cause older sampled acceleration readings to be discarded. Accordingly, at any point, the controller <NUM> may read a finite number of sampled acceleration readings representing a period of time commensurate with the length of the accelerometer FIFO buffer <NUM>. By way of example, assume that the accelerometer FIFO buffer <NUM> has <NUM> storage locations starting with the first FIFO location <NUM> and ending with the last FIFO location <NUM>. Further assume that an accelerometer coupled with the accelerometer FIFO buffer <NUM> provides a sampled acceleration reading every <NUM>, or <NUM> sampled acceleration readings per second. In this example, the accelerometer FIFO buffer <NUM> stores <NUM> or <NUM> second's worth of sampled acceleration readings.

For capturing training acceleration data <NUM>, a correlation needs to be made between the vehicle-provided reversing indication <NUM> and the acceleration data. As such, the vehicle-provided reversing indication <NUM> is used as a capture trigger event for gathering the training acceleration data <NUM>. <FIG> illustrates capturing acceleration readings before and after a capture trigger event <NUM>. The accelerometer FIFO buffer 805A represents the accelerometer FIFO buffer <NUM> before the capture trigger event <NUM>. The accelerometer FIFO buffer 805B represents the accelerometer FIFO buffer <NUM> after the capture trigger event <NUM>. The telematics device <NUM> may capture acceleration readings for a capture duration <NUM> that includes a pre-trigger event duration 840A and a post-trigger event duration 840B. Upon detecting a capture trigger event <NUM>, the controller <NUM> of the telematics device <NUM> may save the acceleration readings of the accelerometer FIFO buffer 805A. Additionally, the controller <NUM> may set a timer that expires after a post-trigger event duration 840B, which is the duration that it takes for the accelerometer FIFO buffer 805B to be filled with acceleration readings after the capture trigger event <NUM>. To use the numerical example discussed above, the accelerometer FIFO buffer 805A contains <NUM> second worth of acceleration readings captured before the capture trigger event <NUM>, which may be a vehicle-provided reversing indication <NUM>. The controller <NUM> of the telematics device <NUM> may, in response to the capture trigger event <NUM>, store a copy of the accelerometer FIFO buffer 805A, then set a post-trigger duration timer that expires after <NUM> second. Upon the expiry of the post-trigger event time, the controller <NUM> then copies the contents of the accelerometer FIFO buffer 805B which contains <NUM> second worth of acceleration readings captured after the capture trigger event <NUM>. Accordingly, the captured training acceleration data contains acceleration readings covering a duration centered around the capture trigger event <NUM>. For example, the telematics device <NUM> may capture <NUM> seconds worth of accelerometer data including a pre-trigger event duration of <NUM> second and a post-trigger event duration of <NUM> second.

The above-described capturing of training acceleration data <NUM> is done for the three accelerometers of a three-axis accelerometer <NUM>. This is explained with reference to <FIG> and <FIG>.

<FIG> depicts the X-axis accelerometer FIFO buffer <NUM>, shown as the pre-trigger event X-axis accelerometer FIFO buffer 815A before the capture trigger event <NUM> and as the post-trigger event X-axis accelerometer FIFO buffer 815B after the capture trigger event <NUM>. <FIG> also depicts the Y-axis accelerometer FIFO buffer <NUM>, shown as the pre-trigger event Y-axis accelerometer FIFO buffer 825A before the capture trigger event <NUM> and as the post-trigger event Y-axis accelerometer FIFO buffer 825B after the capture trigger event <NUM>. Furthermore, <FIG> depicts the Z-axis accelerometer FIFO buffer <NUM>, shown as the pre-trigger event Z-axis accelerometer FIFO buffer 835A before the capture trigger event <NUM> and as the post-trigger event Z-axis accelerometer FIFO buffer 835B after the capture trigger event <NUM>. <FIG> depicts a representation of the training acceleration data <NUM>. The training acceleration data <NUM> is comprised of pre-trigger event acceleration data 850A and post-trigger event acceleration data 850B. The pre-trigger event acceleration data 850A is comprised of the pre-trigger event X-axis acceleration data 852A, the pre-trigger event Y-axis acceleration data 854A, and the pre-trigger event Z-axis acceleration data 856A. The post-trigger event acceleration data 850B is comprised of the post-trigger event X-axis acceleration data 852B, the post-trigger event Y-axis acceleration data 854B, and the post-trigger event Z-axis acceleration data 856B. Each of the pre- and post-trigger acceleration data is comprised of a plurality of sampled accelerometer readings buffered in their respective accelerometer FIFO buffers as described above.

In response to detecting a capture trigger event <NUM>, the controller <NUM> of a telematics device <NUM> saves, stores, or copies each of: the pre-trigger event X-axis acceleration data 852A from the X-axis accelerometer FIFO buffer <NUM> (shown as 815A before the capture trigger event <NUM>), the pre-trigger event Y-axis acceleration data 854A from the Y-axis accelerometer FIFO buffer <NUM> (shown as 825A before the capture trigger event <NUM>), and the pre-trigger event Z-axis acceleration data 856A from the Z-axis accelerometer FIFO buffer <NUM> (shown as 835A before the capture trigger event <NUM>). In response to detecting the capture trigger event <NUM>, the controller <NUM> also configures a post-trigger duration timer that expires after a duration that ensures that sufficient post-trigger event acceleration data has been stored in the corresponding FIFO buffer, i.e. in the X-axis accelerometer FIFO buffer <NUM> (shown as 815B after the capture trigger event <NUM>), in the Y-axis accelerometer FIFO buffer <NUM> (shown as 825B after the capture trigger event <NUM>), and in the Z-axis accelerometer FIFO buffer <NUM> (shown as 835B after the capture trigger event <NUM>). The post-trigger event acceleration data 850B is deemed sufficient if it can be used to train a central reversing determination machine-learning model <NUM>. For example, a second of post-trigger event acceleration data 850B may be sufficient in combination with a second of pre-trigger event acceleration data 850A to train the central reversing determination machine-learning model <NUM>. In response to the expiry of the post-trigger duration timer, the controller <NUM> of the telematics device copies the post-trigger event X-axis acceleration data 852B stored in the X-axis accelerometer FIFO buffer <NUM>, the post-trigger event Y-axis acceleration data 854B stored in the Y-axis accelerometer FIFO buffer <NUM>, and the post-trigger event Z-axis acceleration data 856B stored in the Z-axis accelerometer FIFO buffer <NUM> into the memory <NUM> and then sends copied data as part of the training acceleration data <NUM> (shown in <FIG>) to the telematics server <NUM>.

The capture trigger event <NUM> comprises a vehicle-provided reversing indication <NUM>, which is comprised of a vehicle speed <NUM> that indicates that the vehicle speed is greater than about <NUM>, and a reverse gear indication <NUM>. If the vehicle-provided reversing indication <NUM> is determined in near-real-time, then the post-trigger event acceleration data 850B may be sufficient to train the central reversing determination machine-learning model <NUM>. For example, if the vehicle provides CAN frames containing the vehicle speed <NUM> at a frequent rate and provides a reverse gear indication <NUM> within a brief duration of the reverse gear being engaged, then the trigger event <NUM> is early enough in the reversing action that little to no pre-trigger event acceleration data 850A may be needed to train the central reversing determination machine-learning model <NUM>. In such cases, the training acceleration data <NUM> is comprised of post-trigger event acceleration data 850B. In the example provided earlier, a FIFO holds about <NUM> second worth of acceleration data. If the reverse gear is engaged and the reverse gear indication arrives at the telematics device <NUM> within say <NUM>, then <NUM>% of the FIFO buffer contains buffered acceleration data that is not related to the reversing action. In this case, it is safe to ignore the pre-trigger event acceleration data in the FIFO.

If the vehicle-provided reversing indication <NUM> is determined after a delay, then the pre-trigger event acceleration data 850A contains valuable acceleration data and needs to be part of the training acceleration data <NUM>. For example, if a reverse gear indication <NUM> or the vehicle speed <NUM> are delayed until sometime after the vehicle has started moving in reverse direction, then the training acceleration data <NUM> is best comprised of both the pre-trigger event acceleration data 850A and the post-trigger event acceleration data 850B. In the example provided earlier, a FIFO holds about <NUM> second worth of acceleration data. If the reverse gear is engaged and the reverse gear indication arrives at the telematics device more than <NUM> second later, then at the time the reverse gear indication arrives (i.e., when the trigger event is detected), the pre-trigger event acceleration data 850A contains acceleration data that is highly correlated with the reversing action. Accordingly, the training acceleration data <NUM> is best comprised of both the pre-trigger event acceleration data 850A and the post-trigger event acceleration data 850B.

<FIG> depicts a method <NUM> of gathering the training acceleration data <NUM> by a telematics device <NUM> deployed in a vehicle asset that provides a gear reverse indication as part of the asset data <NUM>. The method begins at step <NUM> at which the telematics device <NUM> receives a vehicle speed <NUM> from the vehicle. The vehicle speed <NUM> may be periodically requested by the telematics device or provided in a broadcast CAN frame that is regularly sent by an ECU <NUM>, such as a transmission ECU, on the CAN bus. At step <NUM>, the telematics device <NUM> receives gear data from the vehicle. In some embodiments, the gear data is sent whenever the current gear in the vehicle's transmission is switched to another gear. At step <NUM>, the telematics device <NUM> determines whether the vehicle speed is greater than about <NUM>/h. For example, the condition at step <NUM> may become true if the vehicle speed is <NUM>/h or higher. If the vehicle speed is less than about <NUM>, then control goes back to step <NUM>. If the vehicle speed <NUM> is greater than about <NUM>, then control proceeds to step <NUM>.

At step <NUM>, the gear data is checked to determine the presence of a reverse gear indication <NUM> in the received gear data. If no reverse gear indication <NUM> is detected or received, then control goes back to step <NUM>. If a reverse gear indication <NUM> is received, then it is determined that the vehicle is reversing based on the vehicle speed <NUM> being greater than about <NUM> and on the reverse gear indication <NUM>. The combination of the vehicle speed <NUM> being greater than <NUM> and the reverse gear indication <NUM> comprises a vehicle-provided reversing indication <NUM>, which is a known output label. Additionally, the combination of the vehicle speed being greater than <NUM> and the reverse gear indication <NUM> represents a capture trigger event <NUM> for capturing the training acceleration data <NUM>.

At step <NUM>, the telematics device <NUM> copies the pre-trigger event acceleration data 850A from the respective accelerometer FIFO buffers. As discussed above, in some embodiments the pre-trigger event acceleration data 850A may not be included in the training acceleration data <NUM>. As such the step <NUM> may be optional as discussed above.

At step <NUM>, the telematics device <NUM> starts a post-trigger duration timer.

At step <NUM>, the telematics device <NUM> checks whether the post-trigger duration timer has expired. If the post-trigger duration timer has not expired, then control stays in step <NUM>. When the post-trigger duration timer expires, control goes to step <NUM>.

At step <NUM>, the post-trigger event acceleration data 850B is copied from the respective accelerometer FIFO buffers. The training acceleration data <NUM> and the vehicle-provided reversing indication <NUM> corresponding to the training acceleration data <NUM>, gathered by the method <NUM> are sent, by the telematics device <NUM>, to the telematics server <NUM> where they are used to train the central reversing determination machine-learning model <NUM> which is implemented on the telematics server <NUM>.

Gathering the captured acceleration data <NUM> from vehicles that do not provide a reverse gear indication <NUM> may be done as described with reference to <FIG>. The accelerometer FIFO buffers shown represent the contents of the X-axis accelerometer FIFO buffer <NUM>, the contents of the Y-axis accelerometer FIFO buffer <NUM>, and the contents of the Z-axis accelerometer FIFO buffer <NUM> as they are sampled periodically. The accelerometer FIFO buffers are sampled in response to a first synchronous trigger event 819A and a second synchronous trigger event 819B. The first synchronous trigger event 819A causes the contents of the three accelerometer FIFO buffers, which were captured from the accelerometers prior to the first synchronous trigger event 819A, to be copied by the telematics device <NUM> and stored. The second synchronous trigger event 819B causes the contents of the three accelerometer FIFO buffers, which were captured from the accelerometers after the first synchronous trigger event 819A but before the second synchronous trigger event 819B, to be copied by the telematics device <NUM> and stored. The acceleration data captured in response to the first synchronous trigger event 819A and the acceleration data captured in response to the second synchronous trigger event 819B are combined to form the captured acceleration data <NUM>. The captured acceleration data <NUM> is similar in structure to the training acceleration data <NUM> shown in <FIG>. Similar to the numerical example given above with respect to the training acceleration data <NUM>, the captured acceleration data <NUM> may comprise <NUM> seconds of sampled acceleration data.

The first synchronous trigger event 819A and the second synchronous trigger event 819B may be timer expiration events such as timer interrupts. In the depicted embodiment, the captured acceleration data <NUM> represents acceleration data captured from the three accelerometers at two successive timer periods. In some embodiments, acceleration data captured in a single timer period may comprise the captured acceleration data <NUM> and may be sufficient for the central reversing determination machine-learning model <NUM> to determine a machine-learning-determined reversing indication <NUM>. In this case, captured acceleration data <NUM> is sent to the telematics server <NUM> every timer period at synchronous trigger events generated by the timer expiry.

In some embodiments, the first synchronous trigger event 819A and the second synchronous trigger event 819B are not generated unless the vehicle reports a speed that is greater than about <NUM>. In other words, if the vehicle is substantially stationary then there is little value in sending captured acceleration data as the vehicle is likely not reversing. The capturing of acceleration data in response to synchronous trigger events is only activated in response to detecting a vehicle speed greater than about <NUM>.

A simplified system architecture shown in <FIG> illustrates how a first vehicle may send training acceleration data <NUM> to train the central reversing determination machine-learning model <NUM>, while a second vehicle may send captured acceleration data <NUM> which the central reversing determination machine-learning model <NUM> can use to generate a machine-learning-determined reversing indication <NUM>.

The system shown in <FIG> includes an asset 100_1 to which a telematics device 200_1 is coupled. The asset data provided by the asset 100_1 does not include gear data, so it is not shown as it is not relevant to the method being discussed. The telematics device 200_1 sends telematics data 212_1 which includes captured acceleration data <NUM> to the telematics server <NUM>. The telematics server <NUM> runs a central reversing determination machine-learning model <NUM> and, in response to receiving the captured acceleration data <NUM>, the telematics server <NUM> uses the central reversing determination machine-learning model <NUM> to generate a machine-learning-determined reversing indication <NUM>.

The system shown in <FIG> also includes an asset 100_2 to which a telematics device 200_2 is coupled. The asset data 112_2 provided by the asset 100_2 contains a vehicle-provided reversing indication <NUM>. The vehicle-provided reversing indication <NUM> is comprised of an indication that the vehicle's reverse gear is engaged and an indication that the vehicle speed is greater than about <NUM>. The telematics device 200_2 contains a three-axis accelerometer <NUM> and gathers training acceleration data <NUM> therefrom as discussed above. The asset data 112_2, including the vehicle-provided reversing indication <NUM>, and the training acceleration data <NUM> are included in the telematics data 212_2 sent to the telematics server <NUM>. The telematics server <NUM> uses the training acceleration data <NUM> and the vehicle-provided reversing indication <NUM> to train the central reversing determination machine-learning model <NUM> to generate a machine-learning-determined reversing indication <NUM>.

In some embodiments, a method carried out by the system of <FIG> includes the step of the telematics server <NUM> logging the machine-learning-determined reversing indication <NUM> for the first vehicle in the telematics database <NUM>.

In some embodiments, the telematics server <NUM> sends the machine-learning-determined reversing indication <NUM> to the telematics device <NUM>. The telematics device <NUM> may generate an alert to the driver indicating that the vehicle is reversing.

The system shown in <FIG> utilizes a central reversing determination machine-learning model <NUM> which is residing on the telematics server <NUM>. As discussed above, the telematics device 200_1 sends captured acceleration data <NUM> to the telematics server <NUM> and the central reversing determination machine-learning model <NUM> provides a machine-learning-determined reversing indication <NUM> which indicates whether the asset 100_1 is reversing. In some embodiments, the telematics server <NUM> may send the machine-learning-determined reversing indication <NUM> back to the telematics device 200_1 so that the telematics device 200_1 may provide some feedback to the operator 10_1 of the asset 100_1. For example, the telematics device 200_1 may beep or flash an indicator so that the operator 10_1 is alerted to the vehicle reversing condition.

While the system shown in <FIG> may provide feedback to the operator 10_1 as just described, the communication with the telematics server <NUM> may introduce some latency such that the feedback provided to the operator 10_1 is not in real-time. Furthermore, other actions that may need to be taken in response to the machine-learning-determined reversing indication <NUM> may also not be carried out in real-time due to the latency in the communication between the telematics server <NUM> and the telematics device <NUM>. Accordingly, in another embodiment of the present disclosure, there is provided a system for reversing detection that includes an edge reversing determination machine-learning model <NUM>, as discussed below with reference to <FIG>.

With reference to <FIG>, there is shown a system for providing a machine-learning-determined reversing indication that utilizes an edge reversing determination machine-learning model <NUM> on the telematics device 200_1. The system depicted in <FIG> is somewhat similar to the system of <FIG>. Accordingly, emphasis will be to describe the differences therebetween. Additionally, some components were omitted due to space limitations and to emphasize other components, of the telematics device 200_1, for example.

The telematics server <NUM> has a central reversing determination machine-learning model <NUM> that is trained by the training acceleration data <NUM>, included in the telematics data 212_2 provided by the telematics device 200_2.

The telematics device 200_1 has an edge reversing determination machine-learning model <NUM>. The term "edge" indicates that the edge reversing determination machine-learning model <NUM> is residing on the telematics device 200_1 as opposed to being in a central location on the telematics server <NUM>. The edge reversing determination machine-learning model <NUM> receives captured acceleration data <NUM> and provides a machine-learning-determined reversing indication <NUM>. The machine-learning-determined reversing indication <NUM> is determined at the telematics device 200_1 and may be used to generate an alert for the operator 10_1 of the asset 100_1. Additionally, the machine-learning- determined reversing indication <NUM> may be sent to the telematics server <NUM> so that the telematics server <NUM> may log the reversing event and/or alert a fleet manager <NUM> using an administration terminal <NUM>.

The edge reversing determination machine-learning model <NUM> is not trained by training acceleration data. Instead, a reversing determination model update <NUM> is sent by the telematics server <NUM> to the telematics device 200_1. Specifically, upon training the central reversing determination machine-learning model <NUM>, which resides on the telematics server <NUM>, a reversing determination model update <NUM> containing updated values of the model parameters is sent to the telematics device 200_1 to update the model parameters of the edge reversing determination machine-learning model <NUM>. In some embodiments, the reversing determination model update <NUM> is sent periodically by the telematics server <NUM> and received by the telematics device 200_1. In other embodiments, the telematics server <NUM> examines the accuracy of the output prediction of the central reversing determination machine-learning model <NUM>. When the accuracy of the output prediction of the central reversing determination machine-learning model <NUM> is improved, the telematics server <NUM> sends a reversing determination model update <NUM> to the telematics device 200_1 to update the edge reversing determination machine-learning model <NUM>.

<FIG> depicts a method <NUM> for determining a machine-learning-determined reversing indication, in accordance with embodiments of the present disclosure. The method <NUM> may be performed by the system of <FIG>.

At step <NUM>, a telematics device 200_1 coupled to a vehicle, such as the asset 100_1 captures captured acceleration data <NUM> from a three-axis accelerometer <NUM> installed in the telematics device 200_1.

At step <NUM>, the telematics device 200_1 sends the captured acceleration data <NUM> to a telematics server <NUM>. The telematics server <NUM> includes a central reversing determination machine-learning model <NUM>.

At step <NUM>, the telematics server <NUM> receives the captured acceleration data <NUM> from the telematics device 200_1.

At step <NUM>, the central reversing determination machine-learning model <NUM> determines a machine-learning-determined reversing indication <NUM> for the first vehicle.

<FIG> depicts a method <NUM> by a telematics device, in accordance with embodiments of the present disclosure. The method <NUM> may be performed by telematics device 200_1 of the system of <FIG>.

At step <NUM>, an edge reversing determination machine-learning model <NUM> residing on a telematics device 200_1 is updated. The edge reversing determination machine-learning model <NUM> is trained using a reversing determination model update <NUM> received from a central reversing determination machine-learning model <NUM>.

At step <NUM>, the telematics device 200_1 obtains the captured acceleration data <NUM> from a three-axis accelerometer <NUM> of the telematics device 200_1.

At step <NUM>, the telematics device 200_1 determines, using the edge reversing determination machine-learning model <NUM>, a machine-learning-determined reversing indication <NUM> from the captured acceleration data <NUM>.

<FIG> is a message sequence diagram depicting a method <NUM> by the system of <FIG>, in accordance with embodiments of the present disclosure.

The method starts at step <NUM>. At step <NUM>, the telematics device <NUM>-<NUM> sends telematics data 212_2 to the telematics server <NUM>. The telematics data 212_2 is comprised of training acceleration data <NUM> and a vehicle-provided reversing indication <NUM>, as discussed above. The telematics data 212_2 is received at the telematics server <NUM>.

At step <NUM>, the telematics server <NUM> trains the central reversing determination machine-learning model <NUM> and generates a reversing determination model update <NUM> using the training acceleration data <NUM> and the vehicle-provided reversing indication <NUM> to. As discussed above, the vehicle-provided reversing indication <NUM> represents a known output label and is used with the training acceleration data <NUM> corresponding to the vehicle-provided reversing indication <NUM> to update the model parameters of the central reversing determination machine-learning model <NUM>.

At step <NUM>, the telematics server <NUM> sends a reversing determination model update <NUM> to the telematics device 200_1. The reversing determination model update <NUM> comprises updated model parameters that were updated in step <NUM>. In some embodiments, the telematics server <NUM> periodically sends a reversing determination model update <NUM> to the telematics device 200_1. In such embodiments, the telematics server <NUM> notes and stores the date and time that the reversing determination model update <NUM> was sent to the telematics device 200_1. This enables the telematics server <NUM> to determine which telematics device has been recently updated and which telematics device has not been recently updated. Accordingly, the telematics server <NUM> only sends a reversing determination model update to a telematics device 200_1 that has not been updated for a predetermined period of time.

In other embodiments, the telematics server <NUM> checks the output confidence level of the central reversing determination machine-learning model <NUM>. If, as a result of the training of the central reversing determination machine-learning model <NUM>, the output confidence level of the central reversing determination machine-learning model <NUM> is improved by a percentage that is above a predetermined output confidence level improvement threshold, then the telematics server <NUM> sends the reversing determination model update <NUM> to the telematics device 200_1. In some embodiments, the telematics server <NUM> notes and stores the output confidence level associated with the reversing determination model update <NUM> sent to the telematics device 200_1. A reversing determination model update <NUM> is sent to the telematics device 200_1 if the output confidence level of the central reversing determination machine-learning model <NUM> is higher than the output confidence level associated with the last instance of the reversing determination model update <NUM> sent to the telematics device 200_1 by an improvement threshold, such as <NUM>% or <NUM>%.

In other embodiments, the telematics device 200_1 may request a reversing determination model update <NUM> from the telematics server <NUM>. The request may be made based on the output confidence level of the edge reversing determination machine-learning model <NUM>. For example, if the output confidence level of the edge reversing determination machine-learning model <NUM> is below <NUM>%, the telematics device 200_1 sends an update request requesting a reversing determination model update <NUM> from the telematics server <NUM>. In response, the telematics server <NUM> sends the reversing determination model update <NUM> to the telematics device 200_1 for updating the model parameters of the edge reversing determination machine-learning model <NUM>.

In all cases, the telematics device 200_1 receives the reversing determination model update <NUM>.

At step <NUM>, the telematics device 200_1 uses the reversing determination model update <NUM> to update the model parameters of an edge reversing determination machine-learning model <NUM>.

At step <NUM>, the telematics device 200_1 uses the edge reversing determination machine-learning model <NUM> to determine a machine-learning-determined reversing indication <NUM> based on captured acceleration data <NUM>, as discussed above.

Advantageously, the method <NUM> utilizes an edge reversing determination machine-learning model <NUM> to determine a machine-learning-determined reversing indication <NUM>. The machine-learning-determined reversing indication <NUM> is determined in real-time on the telematics device 200_1 and may be used to generate a notification by either the telematics device 200_1 or another device coupled thereto. Additionally, the edge reversing determination machine-learning model <NUM> is kept simple and does not undergo training by training data. The model training is offloaded to the central reversing determination machine-learning model <NUM>. Advantageously, the telematics device 200_1 is not burdened with the training and does not need to process data from another telematics device 200_2. This is particularly advantageous when the privacy of the telematics data 212_2 is of a concern. The telematics data 212_2 from the telematics device 200_2 is anonymized and only sent to the telematics server <NUM>. The telematics data 212_2 from the telematics device 200_2 is not shared with the telematics device 200_1. In a system such as the one shown in <FIG>, many telematics devices such as the telematics device 200_2 may provide training data comprising training acceleration data <NUM> and a vehicle-provided reversing indication <NUM> as part of the telematics data sent to the telematics server <NUM>. Advantageously, the central reversing determination machine-learning model <NUM> is trained frequently resulting in a high output confidence level. The high output confidence level attained at the central reversing determination machine-learning model <NUM> results in a reversing determination model update <NUM> being sent to one or more telematics device to update an edge reversing determination machine-learning model <NUM> thereof. This enables the telematics devices to determine a machine-learning-determined reversing indication <NUM>.

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

Claim 1:
A method, comprising:
capturing training acceleration data (<NUM>) by a first <NUM>-axis accelerometer (<NUM>) of a first telematics device (200_2) deployed in a first vehicle (100_2) and having any orientation;
receiving, at a telematics server (<NUM>), training data comprising:
the training acceleration data (<NUM>) from the first telematics device(200_2), and
a known output label in the form of a vehicle-provided reversing indication (<NUM>) from the first telematics device (200_2), including:
a vehicle speed (<NUM>), provided by the first vehicle (100_2) to the first telematics device (200_2), which is greater than <NUM> and
a reverse gear indication (<NUM>), provided by the first vehicle (100_2) to the first telematics device (200_2) via an asset communications bus (<NUM>) and an interface port (<NUM>) of the first vehicle (100_2);
training, by the telematics server (<NUM>), a central reversing determination machine-learning model (<NUM>) using the training acceleration data (<NUM>) and the vehicle-provided reversing indication (<NUM>);
generating and sending, by the telematics server (<NUM>), a reversing determination model update (<NUM>) to a second telematics device (200_1) having any orientation and coupled to a second vehicle (100_1) which does not provide a reverse gear indication (<NUM>);
updating, by the second telematics device (200_1), an edge reversing determination machine-learning model (<NUM>) using the reversing determination model update (<NUM>);
capturing, by a second <NUM>-axis accelerometer (<NUM>) in the second telematics device (200_1), captured acceleration data (<NUM>) for the second vehicle (100_1);
determining, by the edge reversing determination machine-learning model (<NUM>), a machine-learning-determined reversing indication (<NUM>) for the second vehicle (100_1) based on the captured acceleration data (<NUM>); and
generating an alert of a reversing event at the second telematics device (200_1) in response to determining the machine-learning-determined reversing indication (<NUM>).