Apparatus and method for asset platform determination for assets with multi-interface ports

Abstract

A method is provided by a telematics device for identifying an asset platform of an asset coupled to the telematics device. The asset has a multi-interface port, and the telematics device determines the asset platform based on matching tags on both a primary interface and a secondary interface. Identifying the asset platform facilitates obtaining asset data and avoiding operational disruptions.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Provisional Application 63 / 567,631, filed March 20, 2024, the contents of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to asset telematics, and more particularly to apparatus and methods for determining an asset platform for assets with multiple interface ports. Background Technology

[0004] Telematics systems use telematics devices to collect asset data. These devices are typically coupled to the asset at their interface ports. The asset may be a vehicle (“Vehicle Asset”). The telematics device collects asset data from the asset through the interface port. In the case of a vehicle asset, the interface port is typically an On-Board Diagnostics (OBD) port. Asset data includes engine data, powertrain data, accessory data, entertainment system data, etc. Additionally, the telematics device can collect sensor data related to the asset via sensors on the telematics device. Furthermore, the telematics device can collect location data related to the asset from a location module on the telematics device. When the telematics device is coupled to the asset, the collected sensor data and location data are asset-related. The collected asset data, sensor data, and location data can be received and recorded by the telematics system's technical infrastructure (e.g., a telematics server) and used in providing fleet management tools, telematics services, or further data analysis. Summary of the Invention

[0005] In one aspect of this disclosure, a method performed by a telematics device is provided. The method includes: determining a primary asset interface among a plurality of interfaces on an interface port of an asset to which the telematics device is coupled; determining a secondary asset interface among the plurality of interfaces; detecting a first tag on the primary asset interface; detecting a second tag on the secondary asset interface; and determining an asset platform of the asset based on the detection of the first tag on the primary asset interface and the detection of the second tag on the secondary asset interface.

[0006] The method may also include selecting at least one asset data query based on the determined asset platform to obtain asset data.

[0007] The method may also include performing at least one asset data query by listening to broadcast asset data or by sending an asset data request to the asset via an interface port and processing the received corresponding asset data response.

[0008] The primary asset interface can be the first of multiple interfaces to detect asset activation events.

[0009] Detecting asset activation events can include attempting to detect an asset activation event for each of multiple interfaces, for each combination of an asset communication protocol and multiple baud rates.

[0010] Determining a secondary asset interface may include: for each of the multiple interfaces other than the primary asset interface, for each combination of an asset communication protocol and a baud rate among the multiple asset communication protocols: listening for understandable asset data; and designating the current interface among the multiple interfaces as the secondary asset interface when understandable asset data is detected on the current interface among the multiple interfaces.

[0011] Determining the secondary asset interface may further include: when, in response to listening for understandable asset data but no understandable asset data is detected, for each of the multiple interfaces other than the primary asset interface, for each combination of an asset communication protocol among the multiple asset communication protocols and a baud rate among the multiple baud rates: sending a request for asset data on the current interface among the multiple interfaces other than the primary asset interface; and in response to receiving a response to the request, designating the current interface among the multiple interfaces other than the primary asset interface as the secondary asset interface.

[0012] Detecting a first label on the main asset interface may include one of the following: detecting a first standard label broadcast on the main asset interface; detecting a second standard label in response to sending a standard request on the main asset interface; and detecting the absence of a third standard label on the main asset interface for a predetermined duration.

[0013] Detecting a second tag on the secondary asset interface may include one of the following: detecting a first proprietary broadcast tag on the secondary asset interface; detecting a second proprietary tag in response to sending a proprietary request on the secondary asset interface; and detecting the absence of a third proprietary broadcast tag on the secondary asset interface for a predetermined duration.

[0014] Determining an asset platform may include: determining a first asset sub-platform based on detecting a first tag on a primary asset interface; determining a second asset sub-platform based on detecting a second tag on a secondary asset interface; and determining an asset platform based on both the first and second asset sub-platforms.

[0015] The method may also include determining a third asset interface among multiple interfaces. Determining the asset platform may include: determining a first asset sub-platform based on detecting a first tag on a primary asset interface; determining a second asset sub-platform based on detecting a second tag on a secondary asset interface; determining a third asset sub-platform based on detecting a third tag on a third asset interface; and determining the asset platform based on the first, second, and third asset sub-platforms.

[0016] In another aspect of this disclosure, a telematics device for connecting to an asset is provided. The telematics device includes: a controller; an asset interface coupled to the controller for connecting the telematics device to an asset communication bus of the asset; a network interface coupled to the controller; and a memory coupled to the controller. The memory stores machine-executable programming instructions that, when executed by the controller, configure the telematics device to: determine a primary asset interface among a plurality of interfaces on an interface port of the asset; determine a secondary asset interface among the plurality of interfaces; detect a first tag on the primary asset interface; detect a second tag on the secondary asset interface; and determine an asset platform of the asset based on the detection of the first tag on the primary asset interface and the detection of the second tag on the secondary asset interface.

[0017] The machine can execute programming instructions and can also configure the telematics device to select at least one asset data query based on the determined asset platform to obtain asset data.

[0018] The machine can execute programming instructions and can also configure the remote information processing device to perform at least one asset data query by listening to broadcast asset data or by sending an asset data request to the asset via an interface port and processing the received corresponding asset data response.

[0019] Machine-executable programming instructions that configure a telematics device to determine a primary asset interface may include machine-executable programming instructions that configure the telematics device to detect an asset activation event on a first interface among a plurality of interfaces.

[0020] Machine-executable programming instructions that configure a telematics device to detect asset activation events on a first interface of a plurality of interfaces may include machine-executable programming instructions that configure the telematics device to attempt to detect asset activation events for each of the plurality of interfaces and for each combination of an asset communication protocol of a plurality of asset communication protocols and a baud rate of a plurality of baud rates.

[0021] Machine-executable programming instructions that configure a telematics device to determine a secondary asset interface may include machine-executable programming instructions that configure the telematics device to: for each of a plurality of interfaces other than the primary asset interface, for each combination of an asset communication protocol and a baud rate from a plurality of asset communication protocols; and designate the current interface from the plurality of interfaces as the secondary asset interface when the current interface from the plurality of interfaces detects the intelligible asset data.

[0022] The machine-executable programming instructions that configure the telematics device to determine a secondary asset interface may also include the following machine-executable programming instructions: the machine-executable programming instructions configure the telematics device to: when, in response to listening for understandable asset data and not detecting understandable asset data, for each of a plurality of interfaces other than the primary asset interface, for each combination of an asset communication protocol among a plurality of asset communication protocols and a baud rate among a plurality of baud rates: send a request for asset data on the current interface among the plurality of interfaces other than the primary asset interface; and in response to receiving a response to the request, designate the current interface among the plurality of interfaces other than the primary asset interface as the secondary asset interface.

[0023] Machine-executable programming instructions that configure a telematics device to detect a first tag on a main asset interface may include one of the following: machine-executable programming instructions that configure a telematics device to detect a standard tag broadcast on the main asset interface; machine-executable programming instructions that configure a telematics device to detect a standard tag in response to sending a standard request on the main asset interface; and machine-executable programming instructions that configure a telematics device to detect the absence of a third standard tag on the main asset interface for a predetermined duration.

[0024] Machine-executable programming instructions that configure a telematics device to detect a second tag on a secondary asset interface may include one of the following: machine-executable programming instructions that configure a telematics device to detect a proprietary broadcast tag on a secondary asset interface; machine-executable programming instructions that configure a telematics device to detect a proprietary tag in response to sending a proprietary request on a secondary asset interface; and machine-executable programming instructions that configure a telematics device to detect the absence of a third proprietary broadcast tag on a secondary asset interface for a predetermined duration.

[0025] Machine-executable programming instructions that configure a telematics device to determine an asset platform may include the following machine-executable programming instructions: the machine-executable programming instructions configure the telematics device to: determine a first asset sub-platform based on the detection of a first tag on a primary asset interface; determine a second asset sub-platform based on the detection of a second tag on a secondary asset interface; and determine an asset platform based on the first asset sub-platform and the second asset sub-platform.

[0026] The machine-executable programming instructions may further include machine-executable programming instructions for configuring the telematics device to determine a third asset interface among a plurality of interfaces, wherein the machine-executable programming instructions for configuring the telematics device to determine an asset platform include: machine-executable programming instructions for configuring the telematics device to detect a first asset sub-platform based on detecting a first tag on a primary asset interface; machine-executable programming instructions for configuring the telematics device to detect a second asset sub-platform based on detecting a second tag on a secondary asset interface; machine-executable programming instructions for configuring the telematics device to detect a third asset sub-platform based on detecting a third tag on a third asset interface; and machine-executable programming instructions for configuring the telematics device to determine an asset platform based on the first asset sub-platform, the second asset sub-platform, and the third asset sub-platform.

[0027] In any of the foregoing aspects, the third asset interface may include a coupling harness that captures asset data via capacitive coupling.

[0028] In any of the foregoing aspects, the main asset interface may be associated with the first set of interface pins on the interface port.

[0029] In any of the foregoing aspects, the sub-asset interface may be associated with a second set of interface pins on the interface port. Attached Figure Description

[0030] Exemplary, non-limiting embodiments of this disclosure are described with reference to the accompanying drawings, in which:

[0031] Figure 1 It is a schematic diagram of an exemplary telematics system including multiple telematics devices coupled to multiple vehicle assets;

[0032] Figure 2 This is a block diagram illustrating a telematics device that is coupled to a communication bus of an asset via an interface port;

[0033] Figure 3 An exemplary On-Board Diagnostic II (OBD-II) connector is depicted;

[0034] Figure 4It is a graph depicting the logic voltage levels of Controller Area Network (CAN) signals;

[0035] Figure 5 It is a diagram depicting the CAN frame, the transmission frame within the CAN frame, and the diagnostic protocol frame within the transmission frame;

[0036] Figure 6 It is a block diagram depicting the interface ports of assets with associated messages and two asset communication buses;

[0037] Figure 7 Depicting Figure 3 The OBD-II port connector shows an additional CAN interface on some of its pins;

[0038] Figure 8 This is a block diagram showing the asset communication bus connected to the interface port via a bus gateway;

[0039] Figure 9 It is a block diagram depicting the coupling harness connected to the telematics device via the I / O expander interface;

[0040] Figure 10 It is a block diagram of a remote information processing device with a primary asset interface, a secondary asset interface, and a tertiary asset interface;

[0041] Figure 11 It is a flowchart depicting a method used by a telematics device to determine an asset platform; and

[0042] Figure 12 It is a diagram that depicts the relationship between the asset platform and its sub-platforms. Detailed Implementation

[0043] This disclosure relates to apparatus and methods for determining an asset platform for assets with multiple interface ports.

[0044] An "asset" is a vehicle or stationary piece of equipment that has an interface port for providing "asset data" related to the asset. Examples of assets include, but are not limited to, vehicles, industrial machinery, and medical equipment. An asset contains an electronic control unit (ECU) that generates and / or consumes asset data. Asset data includes data relating to the operational status of the asset. The discussion will focus on an "asset as a vehicle asset," i.e., an implementation of a vehicle. However, the asset tagging system disclosed and claimed can work with other assets that provide asset data via their "interface ports."

[0045] An "interface port" includes one or more interfaces to one or more asset communication buses of an asset. An "asset communication bus" is an interconnect that allows different ECUs of the asset to exchange asset data. Asset data exchanged by the ECUs on the asset communication bus can be captured via the interface port. In vehicle assets, interface ports typically include on-board diagnostics (OBD) ports. The asset communication bus of a vehicle asset is typically a Controller Area Network ("CAN bus").

[0046] An asset can contain multiple interface connections on its interface ports. This occurs when an asset has multiple asset communication buses, and each asset communication bus has an interface connection on an interface port. Therefore, a "multi-interface port" is an interface port with multiple interface connections to multiple asset communication buses. For example, for a vehicle asset, there may be multiple CAN buses connecting various ECUs. Each CAN bus can be connected to an OBD port via a separate interface pin.

[0047] A "telematics processing device" is an electronic device coupled to an asset and collecting "asset data" therefrom. For vehicle assets, "asset data" includes "vehicle data." Vehicle data includes engine data, powertrain data, accessory data, entertainment system data, etc. The telematics processing device uses "asset data querying" to capture asset data. Performing asset data querying includes listening for "broadcast asset data" or sending at least one "asset data request" to the asset to request specific asset data, and then processing the received "asset data response" to obtain the asset data. The asset provides asset data using one or more asset communication protocols. In vehicle assets, the telematics processing device uses "vehicle data querying" to capture vehicle data. Performing vehicle data querying may include listening for "broadcast vehicle data" transmitted on the CAN bus via the OBD port. Broadcast vehicle data is typically transmitted on the CAN bus as "broadcast CAN data frames." Alternatively, performing vehicle data querying may include sending a "vehicle data request" to the CAN bus via the OBD port, and then processing the "vehicle data response" corresponding to the sent vehicle data request. Vehicle data requests typically use standard protocols, such as the OBD protocol.

[0048] In this disclosure, "tag" refers to data in the form of a signature or data pattern used to assist in the identification of an asset platform. "Vehicle tag" refers to a data pattern or signature used to assist in the identification of a vehicle platform. Vehicle tags are present in some vehicle data captured by a telematics device. Vehicle data containing vehicle tags is broadcast vehicle data (e.g., broadcast CAN data frames) or a vehicle data response to a request for vehicle data.

[0049] The following description uses a telematics device connected to a vehicle. The telematics device is deployed within a telematics system used to collect vehicle data for analysis, data analysis, and fleet management. However, the apparatus and methods used to determine asset platforms can also be used to determine asset platforms for non-vehicle assets in order to optimally collect asset data from such non-vehicle assets.

[0050] Remote Information Processing System

[0051] Telematics systems are technologies that combine telecommunications and computer science to monitor and manage remote assets, including vehicles and other equipment. Telematics systems collect data from multiple assets through telematics devices. Figure 1 A high-level block diagram of a telematics system 101 is shown. The telematics system 101 includes a telematics server 130, N telematics devices shown as telematics devices 200_1, 200_2, ..., up to 200_N ("telematics devices 200"), a network 50, a management terminal 140, and operator terminals 150_1, 150_2, ..., up to 150_N ("operator terminals 150"). Figure 1 Also shown are multiple (N) assets, named Asset 100_1, Asset 100_2, ..., Asset 100_N (“Asset 100”), respectively coupled to telematics devices 200_1, 200_2, ..., 200_N. Furthermore, Figure 1 Multiple satellites 170_1, 170_2 and 170_3 (“Satellite 170”) are shown communicating with the telematics unit 200 to facilitate navigation.

[0052] Asset 100 is shown in the form of a vehicle. For example, Asset 100_1 is shown as a truck, which may be part of a fleet delivering goods or providing services. Asset 100_2 is shown as a passenger vehicle. Asset 100_3 is shown as an electric vehicle (EV). Other types of vehicles (not shown) are also contemplated in various embodiments of this disclosure, including but not limited to: agricultural vehicles, construction vehicles, military vehicles, etc. Most vehicles currently use internal combustion engines (ICE), including spark ignition (“gasoline”) engines and compression ignition (“diesel”) engines. Both gasoline and diesel engines utilize the reciprocating motion of one or more pistons in a cylinder. Gasoline and diesel engines can use four-stroke or two-stroke cycles. Less commonly used ICEs are rotary (“Wankel”) engines. Electric vehicles (EVs) come in various types. Battery electric vehicles (BEVs) are fully electric vehicles propelled solely by electricity. They are equipped with large battery packs to store electricity, which is used to power electric motors. Hybrid electric vehicles (HEVs) have both an internal combustion engine and an electric motor, but cannot be externally charged. They rely on regenerative braking to charge a small battery that assists the internal combustion engine during acceleration and provides additional power when needed. Plug-in hybrid electric vehicles (PHEVs) combine an internal combustion engine (usually gasoline) with an electric motor and a larger battery pack. They can be charged from a power outlet, allowing them to operate for a certain distance in pure electric mode before switching to the internal combustion engine. Range-extended electric vehicles (EREVs) are similar to PHEVs but typically have a larger battery pack, allowing for a longer pure electric range. When the battery is depleted, the onboard gasoline engine acts as a generator to charge the battery and power the electric motor. The gasoline engine does not directly drive the wheels, making the EREV functionally electric for most of its use. Fuel cell electric vehicles (FCEVs) use hydrogen as a fuel source, which combines with oxygen from the air in a fuel cell to generate electricity to power the electric motor. The only emission from an FCEV is water vapor. Solar-powered electric vehicles integrate solar panels on their roof or other surfaces. These panels generate electricity from sunlight to supplement the vehicle's battery charging.

[0053] Although Figure 1 The assets shown are all land-based vehicles, but this is not always the case. Assets can also be sea-based or air-based vehicles powered by ICE, electric motors, or any other type of engine (such as jet engines, rocket propulsion engines, etc.). In some cases, assets are stationary machinery, such as generators, concrete mixers, compressors, etc.

[0054] The telematics device 200 is coupled to asset 100. For example, in Figure 1In this embodiment, telematics device 200_1 is coupled to asset 100_1. Similarly, telematics device 200_2 is coupled to asset 100_2, and telematics device 200_3 is coupled to asset 100_3. (Refer to...) Figure 2 Further explanation of the components of the remote information processing device 200.

[0055] Network 50 may be a single network or a combination of networks such as data cellular networks, the Internet, and other network technologies. Network 50 may provide connectivity between telematics device 200 and telematics server 130, between management terminal 140 and telematics server 130, and between operator terminal 150 and telematics server 130.

[0056] In some implementations of the telematics system 101, network 50 is a cellular network utilizing cellular technology. In one implementation, network 50 uses second-generation (2G) cellular technology based on the Global System for Mobile Communications (GSM) protocol and supporting data transmission protocols such as General Packet Radio Service (GPRS) or Enhanced Data Rate GSM Evolution (EDGE). In another implementation, network 50 uses third-generation (3G) cellular technology utilizing the Universal Mobile Telephone System (UMTS) which supports data transmission using the High-Speed ​​Packet Access (HSPA) protocol. In yet another implementation, network 50 uses fourth-generation (4G) cellular technology using the Long Term Evolution (LTE) protocol. In yet another implementation, network 50 uses fifth-generation (5G) cellular technology. In yet another implementation, network 50 uses Narrowband Internet of Things (NB-IoT), a low-power wide-area network (LPWAN) technology that is part of the 3rd Generation Partnership Project (3GPP) standard.

[0057] In some implementations of the telematics system 101, network 50 includes a WAN using non-cellular wide area network (WAN) technology. One example of a non-cellular WAN technology that network 50 can use is WiMAX, based on the Institute of Electrical and Electronics Engineers (IEEE) 810.16 family of standards. ™ Another example of a non-cellular WAN technology that Network 50 can use is LoRaWAN (LoRa Wide Area Network). ™ This technology is a low-power WAN protocol. Another example of a non-cellular WAN technology that Network 50 can use is Weightless, a family of open standard low-power WAN (LPWAN) technologies that operate in the sub-GHz band.

[0058] In some implementations, network 50 is a combination of the technologies specified above.

[0059] Telematics server 130 is an electronic device that executes machine-executable programming instructions that enable it to store and analyze telematics data. Telematics server 130 can be a single computer system or a cluster of computers. In some implementations, telematics server 130 utilizes an operating system such as Linux, Windows, Unix, FreeBSD, macOS Server, VMware ESXi, Microsoft Hyper-V Server, Oracle Solaris, IBM AIX, or any other equivalent operating system. In other implementations, telematics server 130 is implemented on a cloud computing platform, such as Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), IBM Cloud, Oracle Cloud, and Alibaba Cloud. Telematics server 130 is connected to network 50 and is capable of receiving telematics data from telematics device 200. In some implementations, telematics server 130 has multiple software modules for performing data analysis and analytics on the telematics data to obtain useful asset information about asset 100. In some implementations, the telematics server 130 is coupled to the telematics database 132 for storing telematics data and / or analysis results related to asset 100. In some implementations, the stored asset information includes operator information about the operator 10 corresponding to the asset. In some implementations, the telematics server 130 transmits asset data and / or operator information related to asset 100 to management terminal 140 and / or operator terminal 150.

[0060] Satellite 170 is part of a Global Navigation Satellite System (GNSS), a satellite-based navigation system that provides positioning, navigation, and timing services globally. The four major GNSS systems currently in operation are the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), Galileo, and BeiDou. GPS is developed and operated by the United States, GLONASS is Russia's equivalent of GPS, Galileo is the European Union's GNSS, and BeiDou is China's GNSS system. Other less commonly used GNSS systems are QZSS (Japan) and IRNSS or NavIC (India). Location information can be processed by a location module on telematics device 200 to provide location data indicating the location of telematics device 200 (and thus the location of asset 100 coupled to it). In other implementations (not shown), telematics device 200 may determine its location using other means outlined below.

[0061] Management terminal 140 is an electronic device capable of connecting to telematics server 130 via network 50. Management terminal 140 can be configured to: retrieve data and analysis related to one or more assets 100; receive alerts from telematics server 130 regarding one or more conditions on telematics devices 200; and / or issue commands to one or more telematics devices 200 via telematics server 130. Management terminal 140 is shown as a laptop computer; however, this is not necessarily the case. Management terminal can be any of the following: desktop computer, industrial human-machine interface (HMI), touchscreen panel, table, smartphone, augmented reality (AR) headset, and network operations center (NOC). In some implementations, management terminal 140 runs a web browser or custom application that allows retrieval of data and analysis related to one or more assets 100 from telematics server 130 via its web interface. In some implementations, management terminal 140 is used to issue commands to one or more telematics devices 200 via telematics server 130. In some implementations, the administrator 11 uses a management terminal 140 to communicate with a telematics server 130. In addition to retrieving and analyzing data, the management terminal 140 also allows the administrator 11 to set alarms and geofences to track assets 100, receive delivery notifications, receive vehicle status notifications, and receive alarms related to driver behavior.

[0062] Operator terminal 150 is an electronic device similar to management terminal 140. Operator terminal 150 is shown as a smartphone; however, this is not necessarily the case. Operator terminal can be any of the following: desktop computer, industrial human-machine interface (HMI), touchscreen panel, table, smartphone, augmented reality (AR) headset, and network operations center (NOC). Operator terminal 150 is used by the operator 10 of asset 100 (e.g., a vehicle driver) to track and configure the use of asset 100. For example, as... Figure 1 As shown, operator 10_1 has operator terminal 150_1, operator 10_2 has operator terminal 150_2, and operator 10_N has operator terminal 150_N. Assume that all operators 10 belong to the fleet, and each of the operators 10 can operate any asset 100. For example, Figure 1 The diagram shows that operator 10_1 is associated with asset 100_1, operator 10_2 is associated with asset 100_2, and operator 10_N is associated with asset 100_N. However, any operator 10 can operate any asset 100 within a specific asset group (e.g., a fleet). Operator terminal 150 communicates with telematics server 130 via network 50. Operator terminal 150 can run at least one asset configuration application. The asset configuration application can be used by operator 10 to inform telematics server 130 that asset 100 is currently being operated by operator 10. For example, operator 10_2 can use the asset configuration application on operator terminal 150_2 to indicate that operator 10_2 is currently using asset 100_2. Telematics server 130 updates telematics database 132 to indicate that asset 100_2 is currently associated with operator 10_2. Furthermore, the asset configuration application can be used to report information related to vehicle operation duration, the number of stops made by the operator during a work shift, etc. In addition, the asset allocation application can allow the operator to configure a telematics device 200 coupled to the asset 100 being operated by the operator 10.

[0063] In operation, the telematics device 200 is coupled to asset 100 to capture asset data. In some implementations, the asset data is combined with location data obtained by the telematics device 200 from a location module communicating with satellite 170 and / or sensor data collected from sensors in or coupled to the telematics device 200. The combined asset data, location data, and sensor data are referred to as “telematics data”. The telematics device 200 transmits the telematics data to a telematics server 130 via network 50. The telematics server 130 processes, aggregates, and / or analyzes the telematics data to generate asset information related to asset 100 or the asset fleet. In some implementations, the telematics server 130 stores the telematics data and / or the generated asset information in a telematics database 132. In some implementations, a management terminal 140 connects to the telematics server 130 via network 50 to access the generated asset information. In other implementations, the telematics server 130 pushes the generated asset information to the management terminal 140. In some implementations, the operator 10 uses the operator terminal 150 to indicate to the telematics server 130 which assets 100 they are associated with. In response, the telematics server 130 updates the telematics database 132 to associate the operator 10 with the asset 100. In some implementations, the telematics server 130 provides additional analysis related to the operator 10, including working hours, location, and operating parameters. For example, for vehicle assets, telematics data may include turning, speeding, and braking information. The telematics server 130 can associate telematics data with vehicle drivers by querying the telematics database 132 for a specific vehicle and retrieving associated driver information. In some implementations, the administrator 11 uses the management terminal 140 to set alarms for certain activities related to asset 100. When alarm criteria are met, the telematics server 130 sends a message to the management terminal 140 to notify the administrator 11. In some implementations, the telematics server 130 sends an alert to the operator terminal 150 to notify the operator 10 of the alert. For example, a vehicle driver operating the vehicle outside of a service area or service hours (HOS) can receive the alert on their operator terminal 150. In some implementations, an administrator 11 uses a management terminal 140 to configure the telematics device 200 by issuing commands to it via the telematics server 130. In some implementations, the telematics server 130 sends an alert to the telematics device 200 to generate an alarm for the driver, such as a beep, a displayed message, or an audio message.

[0064] Asset 100 can have multiple electronic control units (ECUs). A vehicle can, for example, have approximately seventy ECUs. For simplicity, Figure 2 Only a few ECUs 110 are depicted. For example, in the depicted embodiment, asset 100 has three ECUs, shown as ECU 110A, ECU 110B, and ECU 110C (“ECU 110”). ECU 110A, ECU 110B, and ECU 110C are shown interconnected via an asset communication bus.

[0065] The most commonly used asset communication bus type is the Controller Area Network (CAN) bus. CAN is a robust and standardized communication protocol designed for real-time control applications. The CAN bus is the physical bus used to connect various ECUs and sensors, allowing them to exchange data and commands. The CAN bus ensures seamless collaboration between different vehicle systems. ECUs connect to the CAN bus using dedicated CAN transceivers and connectors.

[0066] Another type of asset communication bus is the Local Interconnect Network (LIN) bus, which is used for low-speed communication between certain ECUs, particularly for non-critical functions such as interior lighting and seat control. FlexRay is another communication protocol used in some high-performance and safety-critical applications. It offers faster data rates and deterministic communication, making it suitable for advanced driver assistance systems (ADAS) and other critical functions. In some modern vehicles, especially those with advanced infotainment systems and autonomous driving capabilities, Ethernet networks are used to handle high-bandwidth data communication. Therefore, while this disclosure discusses CAN and related protocols, it will be apparent to those skilled in the art that the methods described herein are applicable to the protocols mentioned above and similar protocols.

[0067] As discussed above, the most commonly used asset communication bus type is the CAN bus. For example, in Figure 2 In this configuration, ECU 110 interconnects using CAN bus 104. ECU 110 sends and receives vehicle data in CAN data frames from each other by placing information on CAN bus 104. When ECU 110 places vehicle data on CAN bus 104, other ECU 110 receives the information and may consume or use the vehicle data, or may not consume or use the vehicle data.

[0068] Multiple asset communication protocols can be used to exchange information between ECUs via asset communication buses. For vehicle assets, various automotive protocols can be used to exchange information via the CAN bus. For example, ECU 110 in trucks and heavy vehicles uses the SAE J1939 protocol to exchange information via CAN bus 104. J1939 is based on CAN and is used for diagnostic and communication purposes. Most passenger vehicles use the SAE J1979 protocol, commonly known as the On-Board Diagnostics II (OBD-II) protocol, to exchange information between ECUs 110 on their CAN bus 104. OBD-II is a standardized diagnostic protocol used in most vehicles manufactured since the late 1990s. OBD-II provides a common interface for diagnostic tools to communicate with various ECUs in a vehicle, including the Engine Control Module (ECM), Transmission Control Module (TCM), etc. OBD-II allows reading diagnostic fault codes (DTCs), real-time data, and performing various diagnostic tests. The Unified Diagnostic Services (UDS) protocol is a diagnostic protocol that runs on various physical layers, including CAN, LIN, and FlexRay. ISO 9141 is an older diagnostic protocol, commonly used in vehicles manufactured in the 1990s and early 2000s. While largely superseded by OBD-II, it can still be found in some older vehicles. Keyword Protocol 2000 (KWP2000) is another older protocol used for vehicle diagnostics, particularly in European vehicles. Like ISO 9141, it has also been largely superseded by OBD-II. Some automakers, such as General Motors (GM) and Ford, have proprietary diagnostic protocols for communicating with the ECUs in their vehicles. GM has the GMLAN protocol, and Ford has the Ford Standard Corporation Protocol (SCP). Similarly, Volkswagen Group Communications (VAG-COM) is a proprietary diagnostic protocol used in Volkswagen Group (VAG) vehicles, including VW, Audi, SEAT, and Skoda. Internet Protocol-Based Diagnostics (DoIP) is a newer diagnostic protocol that utilizes Ethernet or IP-based networks for vehicle diagnostics. DoIP is used in some modern vehicles with advanced electronic systems.

[0069] Asset 100 may allow access to information exchanged on CAN bus 104 via interface port 102. For example, if asset 100 is a passenger vehicle, interface port 102 is likely an OBD-II port. When asset 100 is a vehicle asset, the vehicle data accessible via interface port 102 is a form of asset data 112. In some implementations, interface port 102 includes a power interface for supplying power to a telematics device 200 connected thereto.

[0070] Remote information processing device

[0071] Reference Figure 2 Further details are shown regarding the telematics device 200 and how the telematics device 200 interfaces with the asset 100. Figure 2 Asset 100 and telematics device 200 coupled to asset 100 are depicted. Selected relevant components of each of asset 100 and telematics device 200 are shown.

[0072] The telematics device 200 includes a controller 230 coupled to a memory 240, an asset interface 202, and a network interface 220. The telematics device 200 also includes one or more sensors 204 and a position module 206 coupled to the controller 230. In some implementations, the telematics device 200 includes an inertial measurement unit, shown as an IMU 290. The telematics device 200 may also include optional components, Figure 2 The components shown are indicated by dashed lines. For example, the telematics device 200 may include one or more of the following: a near-field communication (NFC) module (e.g., NFC module 260), a short-range wireless communication module 270, and a wired communication module (e.g., serial communication module 280). In some embodiments (not shown), the telematics device 200 may have a dedicated power supply or battery. In other embodiments, the telematics device 200 may receive power directly from the asset 100 via interface port 102. Some components shown by 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 206 and may rely on an external location module to acquire location data. Some telematics devices may not have any sensors 204 and may rely on external sensors to acquire sensor data.

[0073] Controller 230 may include one or any combination of the following: a processor, microprocessor, microcontroller (MCU), central processing unit (CPU), system-on-a-chip (SoC), processing core, state machine, logic gate array, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or any other hardware component or combination of hardware components capable of executing machine-executable programmable instructions. Controller 230 may follow a von Neumann architecture, Harvard architecture, or a modified Harvard architecture. Controller 230 may be a Complex Instruction Set Computer (CISC) processor supporting a complex instruction set, which can perform multiple operations in a single instruction. Alternatively, controller 230 may be a Reduced Instruction Set Computer (RISC) processor with a simplified and streamlined instruction set and employs a pipelined architecture to optimize execution. Controller 230 may have a single processor core or multiple processor cores supporting parallel execution of instructions. Controller 230 may have internal memory for storing machine-executable programmable instructions that will be executed by controller 230 to perform the steps of the methods described in this disclosure.

[0074] Memory 240 is an electronic storage component capable of storing data and machine-executable programmable instructions. Memory 240 may be a read-only memory (ROM), including programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Memory 240 may be random access memory (RAM), including static RAM (SRAM) and dynamic RAM (DRAM). Alternatively, memory 240 may be ferroelectric RAM (FRAM), magnetic random access memory (MRAM), or phase-change memory (PCM). Memory 240 may also be any combination of the foregoing types. Memory 240 is used to store machine-executable programmable instructions and / or data to support the functions described in this disclosure. Memory 240 is coupled to controller 230 via a memory bus, thereby enabling controller 230 to execute machine-executable programmable instructions stored in memory 240 and access data stored therein.

[0075] The location module 206 determines the location of the telematics device 200. The location data may be in latitude and longitude form, Universal Transverse Mercator (UTM) coordinate form, or any other similar form.

[0076] In some implementations, the position module 206 is a GNSS transceiver supporting one or more of the aforementioned GNSS technologies. The position module 206 may be integrated into the controller 230 or coupled to the controller 230 via a serial interface such as a Serial Peripheral Interface (SPI), an Internal Integrated Circuit (I2C), a Universal Asynchronous Receiver / Transmitter (UART), a Universal Serial Bus (USB), and a Secure Digital Input / Output (SDIO) interface.

[0077] In other implementations, location module 206 uses cellular tower triangulation to determine the location of telematics device 200 via a cellular network. In this case, location module 206 is a firmware module that calculates the location based on information received from network interface 220, which in this case is a cellular modem providing signal measurement results from multiple nearby cellular towers. Location module 206 uses the signal measurement results to estimate the location of telematics device 200. The location data determined by location module 206 is sent to controller 230.

[0078] Sensor 204 can be one or more of the following: a temperature sensor, a pressure sensor, an optical sensor, a humidity sensor, a gas sensor, an acoustic sensor, a pH sensor, a soil moisture sensor, or any other suitable sensor indicating a condition related to asset 100 to which telematics device 200 is coupled. Sensor 204 is coupled to the controller via any of serial, parallel, or bus technologies. For example, some of sensor 204 may be connected to controller 230 via a parallel interface. Other sensors 204 may be connected to controller 230 via a bus using any of the known bus technologies, such as Industry Standard Architecture (ISA), Extended ISA (EISA), Micro Channel Architecture (MCA), Video Electronics Standards Association (VESA), Peripheral Component Interconnect (PCI), PCI Express (PCI-X), Personal Computer Memory Card Industry Association (PCMCIA), Accelerated Graphics Port (AGP), and Small Computer System Interface (SCSI). Sensor 204 may be connected to the controller via a serial link, such as a Universal Asynchronous Receiver / Transmitter (UART), Serial Peripheral Interface (SPI), or Internal Integrated Circuit (I2C) link. Sensor 204 provides sensor data to controller 230. Some telematics devices may not have any sensor 204 and may only provide location information and / or IMU information. Some telematics devices may have the ability to pair with external sensors via wired or wireless interfaces.

[0079] Asset interface 202 is a hardware subsystem that allows telematics device 200 to read asset data 112 from interface port 102 of asset 100 and also sends asset data requests to one or more ECUs. Some asset data requests may be in the form of configuration commands that configure ECU 110 in a specific manner to, for example, adjust the performance of the vehicle. In some implementations, asset interface 202 receives power from asset 100 via interface port 102 to power telematics device 200. In the case of an asset employing CAN bus 104, asset interface 202 includes an interface connector and at least one CAN transceiver.

[0080] In some implementations, the interface connector of asset interface 202 is an OBD-II connector configured to mate with the corresponding OBD-II connector of interface port 102 of asset 100. In this case, interface port 102 will be an OBD-II port. On CAN bus 104, data is exchanged on two signal lines named CANH (CAN high level) and CANL (CAN low level).

[0081] A typical OBD-II port on an asset has multiple pins, including at least one CANH pin and a CANL pin. Figure 3 The pin arrangement of the J1962 16-pin connector (also known as the OBD-II port 300) for vehicles is depicted. Figure 3 As shown, the OBD-II connector 400 has different signal lines that can be used by different protocols. Signal line 1 is called the SAE J1850 Bus+ (“J1850+”) signal line, and signal line 2 is called the SAE J1850 Bus- (“J1850-”) signal line. The J1850+ / J1850- signal lines are used by the Variable Pulse Width (VPW) protocol and the Pulse Width Modulation (PWM) protocol. Signal line 7 is called the ISO9141 K-line (“K-line”) signal line, and signal line 15 is called the ISO9141 L-line (“L-line”) signal line. The K-line and L-line are used by the ISO9141 protocol and the ISO14230 protocol. Signal line 6 is the ISO 15765-4 CAN High (“CANH”) signal line, and signal line 14 is the ISO 15765-4 CAN Low (“CANL”) signal line. The CANH and CANL signal lines are used by the CAN protocol. Signal line 16 is the battery voltage, typically +12V. Signal line 5 is signal ground.

[0082] The CAN transceiver converts the CAN level signal at interface port 102 into a digital level signal that the controller 230 can read. Conversely, the CAN transceiver also converts the digital level signal output by the controller 230 into a CAN level signal that is sent to the CAN bus 104 via interface port 102. Digital level signals are typically 5V or 3.3V for logic "1" or HIGH, and 0V for logic "0" or LOW. CAN logic levels are... Figure 4 As shown in the diagram. Data on the CAN bus is represented by the CANH and CANL signals. For example... Figure 4 As shown, the CAN interface defines logic "0" ("LOW") as the dominant state and logic "1" ("HIGH") as the recessive state. In the dominant state, the CANH signal is set to 3.5V, and the CANL signal is set to 1.5V. In the recessive state, both CANH and CANL are set to 2.5V. The CAN transceiver converts the logic LOW on the CAN bus to a 0V digital LOW signal and the logic HIGH on the CAN bus to a positive voltage (e.g., 5V) digital HIGH signal.

[0083] Back Figure 2 The IMU 290 is an inertial measurement unit. An IMU 290 is a device used to measure and provide information about the motion, orientation, and acceleration of a telematics device. An IMU 290 may include several components that work together. For example, an IMU 290 may include one or more of the following: an accelerometer, a gyroscope, a magnetometer, and a barometer. An accelerometer measures linear acceleration on three axes (typically X, Y, and Z). A gyroscope measures angular velocity or rotational rate about each of the three axes. A magnetometer measures the strength and direction of a magnetic field and thus determines heading or orientation relative to the Earth's magnetic field. A barometer measures atmospheric pressure, and this can be used to estimate changes in altitude. Some IMUs contain a microcontroller or processor that runs sensor fusion algorithms to combine and process data from the various sensors mentioned above. Some IMUs contain an embedded machine learning core (MLC). An MLC is an in-sensor engine with classification-based AI algorithms (decision trees) that can run different tasks as the sensor detects motion data. Examples of IMUs with MLCs include STMicroelectronics. ™ The iNEMO inertial module. Some IMUs include a communication interface for interfacing with an external microcontroller or processor. Some telematics devices may not include an IMU unit and can report motion determined based on changes in position reported by position module 206.

[0084] The IMU 290 can be integrated into the controller 230, or it can be a separate component communicating with the controller 230 via a parallel interface, a serial interface using any of the serial technologies mentioned above, or a bus interface using any of the bus technologies mentioned above. Alternatively or additionally, the IMU 290 can be directly connected to the general purpose input / output (GPIO) pins and / or interrupt pins of the controller 230. The controller 230 can configure the IMU 290 by sending its configuration commands. Furthermore, the controller 230 can query the status of the IMU 290 generally or in response to receiving an interrupt signal from the IMU 290.

[0085] In some implementations, network interface 220 includes a cellular modem utilizing cellular technology. In one implementation, network interface 220 uses second-generation (2G) cellular technology based on the Global System for Mobile Communications (GSM) protocol and supporting data transmission protocols such as General Packet Radio Service (GPRS) or Enhanced Data Rate GSM Evolution (EDGE). In another implementation, network interface 220 uses third-generation (3G) cellular technology utilizing the Universal Mobile Telephone System (UMTS) supporting data transmission using the High-Speed ​​Packet Access (HSPA) protocol. In yet another implementation, network interface 220 uses fourth-generation (4G) cellular technology using the Long Term Evolution (LTE) protocol. In yet another implementation, network interface 220 uses fifth-generation (5G) cellular technology. In yet another implementation, network interface 220 uses Narrowband Internet of Things (NB-IoT), a low-power wide-area network (LPWAN) technology that is part of the 3rd Generation Partnership Project (3GPP) standard.

[0086] In some implementations, network interface 220 includes a WAN modem using non-cellular wide area network (WAN) technology. Network interface 220 can use non-cellular WAN technology. One example of a non-cellular WAN technology that network interface 220 can use is WiMAX, a microwave access global interoperability technology based on the IEEE 810.16 family of standards. ™ Another example of a non-cellular WAN technology that network interface 220 can use is LoRaWAN (LoRa Wide Area Network). ™ This technology is a low-power WAN protocol. Another example of a non-cellular WAN technology that can be used on a network interface is weightless technology, which is a family of open standard low-power WAN (LPWAN) technologies that operate in the sub-GHz band.

[0087] In some implementations, when the telematics device 200 is coupled to an asset providing a wired network connection, the network interface 220 uses wired network technology. Examples of wired network technologies include Ethernet, Fast Ethernet, and LocalTalk. ™ Token Ring, Fiber Distributed Data Interface (FDDI), and Asynchronous Transfer Mode (ATM).

[0088] The network interface 220 can be integrated into the controller, or coupled to the controller via a parallel interface, a serial interface using any of the serial technologies mentioned above, a bus interface using any of the bus technologies mentioned above, or can be directly connected to the general purpose input / output (GPIO) pins and interrupt pins of the controller 230.

[0089] Network interface 220 allows remote information processing device 200 to send data to / receive data from a remote device (e.g., remote information processing server 130).

[0090] The short-range wireless communication module 270 is a component designed to provide short-range wireless communication capability to the telematics device 200. The short-range wireless communication module 270 includes at least one of the following: Bluetooth. ™ Module, Wi-Fi ™ ) module, Zigbee ™ Modules, Z-Wave modules, and radio frequency identification (RFID) ™ Alternatively, the short-range wireless communication module 270 may include any other short-range wireless communication module. Bluetooth is a widely used wireless technology used for short-range communication between devices. Bluetooth operates in the 2.4 GHz band and supports different versions with different data rates and ranges. Wi-Fi is a wireless communication technology commonly used for local area network (LAN) connections. Wi-Fi operates in different frequency bands, including 2.4 GHz and 5 GHz, and offers higher data rates compared to Bluetooth. Zigbee is a low-power wireless communication protocol designed for short-range communication in wireless sensor networks, operating according to the IEEE 810.15.4 standard. Z-Wave is a wireless communication technology operating in the sub-GHz frequency range, allowing for longer range and better penetration compared to some other wireless technologies. RFID is a technology that uses electromagnetic fields to wirelessly identify and track objects or individuals. It consists of tags or labels that store data and readers that send and receive signals to interact with the tags. The short-range wireless communication module 270 allows other devices to communicate with the telematics device 200 via a short-range wireless network. For example, an external wireless sensor can send sensor data to a remote information processing device 200 via a short-range wireless communication module 270.

[0091] NFC module 260 is a near field communication (NFC) module. ™ NFC is a short-range wireless communication technology that enables devices to establish communication and exchange data when they are close to each other. In some implementations, NFC module 260 is an NFC reader capable of reading information stored on an NFC tag. NFC module 260 can be used to verify the identity of operator 10 by having operator 10 tap an NFC tag against telematics device 200, allowing the NFC tag to be read by NFC module 260.

[0092] Serial communication module 280 is an example of a wired communication module. Serial communication module 280 is an electronic peripheral device used to provide serial wired communication for telematics device 200. For example, serial communication module 280 can be one of the following: Universal Asynchronous Receiver / Transmitter (UART), Serial Peripheral Interface (SPI), Internal Integrated Circuit (I2C) module, Controller Area Network (CAN) transceiver, or RS-232 transceiver. UART supports synchronous data transmission between devices and supports relatively low data rates. SPI is a synchronous serial communication protocol that allows devices to exchange data in full-duplex mode. I2C is a serial communication protocol that enables devices to communicate using a two-wire interface. CAN is a serial communication bus commonly used in automotive and industrial applications. In some implementations, telematics device 200 accepts connections from input / output devices using the CAN protocol. In some implementations, serial communication module 280 allows external devices to connect to telematics device 200 to download asset data 112 from telematics device 200. In some implementations, the serial communication module allows external sensors to send sensor data to the remote information processing device 200.

[0093] In operation, ECU 110 communicates with asset data 112 via an asset communication bus. Telematics unit 200 captures asset data 112 via interface port 102 through the asset communication bus. As an example, ECU 110 (e.g., ECU 110A, ECU 110B, or ECU 110C) places CAN data on CAN bus 104. Asset data exchanged between ECUs 110 via CAN bus 104 is accessible via interface port 102 and can be retrieved by telematics unit 200 as asset data 112. The controller 230 of telematics unit 200 receives asset data 112 via asset interface 202. In some implementations, controller 230 receives sensor data from sensor 204 and / or position data from position module 206. Controller 230 combines asset data 112 with sensor data and position data to obtain telematics data 212. The controller 230 transmits telematics data 212 to the telematics server 130 via network interface 220 through network 50. The telematics data 212 can be used by the telematics server 130 to derive useful asset information and for analysis. Optionally, the operator 10 can tap an NFC tag against the NFC module 260 to identify themselves as the operator 10 of asset 100. Furthermore, external peripheral devices (such as GPS receivers) can connect to the telematics device 200 via short-range wireless communication module 270 or serial communication module 280 to provide location information to the telematics device 200. In some implementations, the telematics device 200 receives commands from the telematics server 130 via network interface 220. The received commands instruct the telematics device 200 to configure itself in a specific manner.

[0094] Capture asset data

[0095] The telematics device 200 can capture asset data 112 via interface port 102 of asset 100 using one of two main methods. The first method is that the telematics device 200 listens for "broadcast asset data" placed on the asset communication bus by the ECU 110. In the case of vehicle assets, broadcast asset data includes "broadcast vehicle data." The format of the broadcast vehicle data depends on the protocol used by the vehicle (e.g., CAN, J1939, CANOpen, etc.). For example, for passenger vehicles using the CAN protocol, the asset communication bus is a CAN bus, such as CAN bus 104. In this case, the broadcast vehicle data is in the form of "broadcast CAN data frames." For example, for CAN bus 104, the ECU 110 can place broadcast CAN data frames on CAN bus 104, and the telematics device 200 can capture these data frames via interface port 102 (which will be the OBD port). The second method is that the telematics device 200 actively solicits asset data via an "asset data request." For vehicle assets, the asset data request is a "vehicle data request." Vehicle data requests are made using one of several protocols, such as OBD-II and UDS. Similarly, ECU 110 receives vehicle data requests and, if appropriate, prepares a "vehicle data response" corresponding to the vehicle data request. For passenger vehicles using the CAN protocol, the vehicle data request and vehicle data response are encapsulated in a CAN data frame, typically within a transport protocol frame. The CAN data frame carrying the vehicle data request and vehicle data response is typically addressed to a specific entity, rather than being broadcast on the CAN bus 104. Figure 5 The typical arrangement of the protocol within a CAN data frame for a vehicle using the CAN protocol is depicted.

[0096] Figure 5 A standard CAN data frame in the form of CAN data frame 600 is described. Encapsulated within CAN data frame 600 is transmission frame 640, and encapsulated within transmission frame 640 is diagnostic frame 660. CAN data frame 600 consists of an 11-bit CAN identifier 602, a Remote Transmission Request (RTR) bit in the form of RTR bit 604, an Identifier Extension (IDE) bit in the form of IDE bit 606, a Data Length Code (DLC) in the form of DLC 608, an 8-byte CAN data frame payload 610, a CRC field 618, and an acknowledgment field in the form of ACK field 620.

[0097] An 11-bit identifier field stores the CAN identifier 602. The CAN protocol requires all contention messages to have a unique identifier. ECU 110 typically has a CAN ID on which it receives vehicle data requests and another CAN ID on which it sends vehicle data responses. For example, the ECU can receive a vehicle data request on CAN ID 0x750 and then provide a vehicle data response using CAN ID 0x758. In this case, the diagnostic tool or telematics device prepares a CAN data frame 600 containing CAN ID 0x750 and a vehicle data request payload encapsulated within the CAN data frame 600. The diagnostic tool or telematics device then places the CAN data frame 600 on the CAN bus 104. Subsequently, to receive a vehicle data response, the diagnostic tool or telematics device listens on the CAN data frame 600 containing CAN ID 0x758 on the CAN bus 104 and then checks the CAN data frame payload 610 to obtain the vehicle data response corresponding to the vehicle data request. More information about vehicle data requests and vehicle data responses will be explained below.

[0098] RTR bit 604 indicates a remote transfer request.

[0099] When CAN data frame 600 is a standard CAN data frame with an 11-bit identifier, the value of IDE bit 606 is 0. When the CAN data frame is an extended CAN data frame, the value of IDE bit 606 is 1.

[0100] DLC 608 indicates the length of the relevant bytes in the CAN data frame payload 610. The total length of the payload is 8 bytes; however, some CAN data frames may carry fewer than 8 bytes.

[0101] The CAN data frame payload 610 is 8 bytes long and can contain raw data or diagnostic protocol frames encapsulated in the transmission frame, as will be explained below.

[0102] The CRC field 618 contains a checksum used for error detection.

[0103] The ACK field 620 is set by the node that receives the accurate CAN message.

[0104] For vehicle data requests and responses exchanged between ECU 110 and diagnostic tools or telematics devices, a transport protocol is typically used to transmit the request within a transport frame. Transport frame 640 is encapsulated within CAN data frame 600 and its CAN data frame payload 610. Transport frame 640 typically consists of a header and a payload. The header of the transport protocol can contain both type 642 and length 644. For example, in the International Organization for Standardization Transport Protocol (ISO-TP), the upper half of byte 0 contains an indication of the transport frame type. For ISO-TP, type value 0 indicates that the transport frame is a single frame, and the data encapsulated in transport payload 646 is all the data being transmitted. Transport frame 640 is encapsulated within CAN data frame payload 610 of CAN data frame 600, and the first byte of the transport frame contains type 642 and length 644. Therefore, the payload of transport payload 646 can hold a maximum of 7 bytes. While this may be sufficient for many vehicle data requests, 7 bytes may not be enough for some vehicle data responses carrying large amounts of data. In this configuration, ISO-TP provides multi-frame data transmission. The first frame of the multi-frame message is of type 1. Furthermore, the lower half of type 642 and length 644 contain the full size of the data being transmitted. In this configuration, the maximum data size that a multi-frame ISO-TP message can transmit is 4095 bytes (0x0FFF). The first frame of the multi-frame message may only carry the first 6 bytes of the multi-frame ISO-TP message. Subsequent frames of the multi-frame message have an upper half of type 2, and the lower half contains the frame number between 0x0 and 0xF, starting from 1 and rolling back to 0 after reaching 0xF. The flow control frame, which controls whether to acknowledge individual frames and the time duration between subsequent frames, is of type 3. Additionally, the flow control frame has 2 bytes specifying flow control and duration. Another variant of ISO-TP is BMW-TP, which includes an additional byte at byte position 0, which is the low byte of the response CAN ID that a specific ECU will use to respond.

[0105] There are specific diagnostic protocols used to query ECU 110 to request specific data or configure the ECU in a specific mode. Examples of diagnostic protocols include On-Board Diagnostics (OBD), Unified Diagnostic Services (UDS), and Keyword Protocol (KWP). Diagnostic frames 660 typically have a Service Identifier (SID) 662, which specifies the diagnostic service requested from the ECU, and one or more Data Identifiers (DIDs), such as DID_1 (shown as field 664) and DID_2 (shown as field 666). Diagnostic frames 660 may also contain other data 668. Diagnostic request frames are typically short enough (e.g., 3 bytes) to be sent within the transport payload 646 of a single-frame transport protocol message. Since the transport payload 646 of a single-frame transport message is 7 bytes, a diagnostic request can be 7 bytes long, which is generally sufficient to specify the service and multiple DIDs. Diagnostic responses typically contain more than 7 bytes and are therefore usually distributed across multiple transport messages.

[0106] Several standardized high-level protocols define how data stored in the CAN data frame payload 610 of CAN data frame 600 is converted into asset data highly utilized in vehicle telematics (e.g., OBD2, SAE J1939, CANopen). For example, in J1939, vehicle parameters (e.g., speed, tire pressure) are encoded into the CAN data frame payload 610 of CAN data frame 600 and organized by Suspicious Protocol Number (SPN), which is represented as a tag in the CAN data frame payload 610, and further organized by Parameter Group Number (PGN), which is represented as a tag in the CAN identifier 602. As an example, as described in J1939-71 (revised June 2006), the vehicle parameter "wheel-based vehicle speed" is labeled as SPN 84 under PGN 65265 and represented as 2 bytes of data (providing 1s and 0s) in the CAN data frame payload 610 of CAN data frame 600. (16 = 65536 possible combinations), each bit increments by 1 / 256 km / h (increasing the number by 1 means increasing by 1 / 256 km / h or 0.00390625 km / h), with an offset of 0 (i.e., "00000000" represents 0 km / h). This formula used to derive a human-understandable value for "wheel-based vehicle speed" can form part of a "signal definition." In this disclosure, a signal definition is a set of instructions used to acquire data messages and decode them into usable information.

[0107] Challenges of different modes of transportation

[0108] Increasingly, vehicles, including electric vehicles (EVs), do not specifically use standardized high-level protocols to provide asset data. Telematics devices can be configured to also use proprietary protocols; however, proprietary vehicle data queries over proprietary protocols, or even standard protocols, require knowledge of the vehicle type. Therefore, knowing which vehicle the telematics device is installed in is essential for sending vehicle data queries appropriate for that vehicle.

[0109] Furthermore, a proprietary vehicle data request for device status data from one ECU in a first vehicle type may have unintended consequences when received by another ECU in a second vehicle type. Since some CAN or diagnostic protocol messages are used to configure the ECU, a misinterpreted vehicle data request can lead to malfunctions or unexpected operational behavior. Such a situation is sometimes referred to as “engine interference” or more broadly as “operational interference” because it can interfere with other components of the powertrain, such as the transmission, anti-lock braking system (ABS), etc. In this disclosure, “operational interference” refers to an unintended misconfiguration of an ECU due to the reception of CAN messages intended for different purposes and coincidentally having a similar pattern (e.g., another proprietary CAN message).

[0110] It is becoming increasingly difficult for telematics devices to determine, without explicit instructions, which type of vehicle they are installed in, and therefore, which set of messaging protocols to use to begin collecting information from the vehicle. In the past, when most vehicles relied primarily on one of the common, standardized high-level protocols, telematics devices could be installed in any vehicle, and a fairly simple procedure was used to determine which common standardized protocol the system was using and configure itself accordingly. However, with increasing deviations from common standardized protocols (including in jurisdictions where communication protocol standardization is less prevalent), more sophisticated methods are needed to determine which type of vehicle the telematics device is installed in.

[0111] Asset platform and transportation platform

[0112] In this disclosure, we define an “asset platform” as a group of assets of different types but sharing some attributes. Specifically, assets in an asset platform generate similar asset data in response to similar asset data queries, provide expected information in response to a set of asset data queries, and experience operational interference in response to a set of asset data requests that lead to errors. As an example of an asset platform, we define the concept of a “vehicle platform.” A vehicle platform is defined as a group of vehicles sharing some attributes. Specifically, vehicles in a particular vehicle category generate similar vehicle data in response to a set of vehicle data queries, provide expected information in response to a set of vehicle data queries, and experience operational interference in response to a set of vehicle data requests that lead to errors. A vehicle platform is not a specific car manufacturer or model. One reason for defining a vehicle platform differently from a vehicle brand or model is that a vehicle platform will be primarily defined by the ECU installed in the vehicle. Many ECUs may be common across different brands of vehicles. Another reason for defining a vehicle platform differently from a vehicle brand or model is that different car manufacturers collaborate and manufacture essentially similar vehicles with different brands and models. For example, “MazdaPrevia”. ™ And "Ford Escape" ™ In reality, they are the same car with different brands and appearances. Similarly, the "Pontiac Vibe" ™ and "Toyota Matrix" ™ These are also similar vehicles with different brands and models. Therefore, a transportation platform can include vehicles of different brands and models that share the aforementioned common attributes.

[0113] Label

[0114] In this disclosure, we define the term "asset tag" (or simply "tag") as a signature or pattern that aids in identifying an asset platform. For an asset, the telematics device determines the asset platform by detecting at least one tag on an interface port. The asset platform is determined by the telematics device to better select the appropriate protocol for querying the asset. The telematics device also uses the asset platform to select the best asset data query to use with the asset in order to retrieve asset data from the asset. Furthermore, the telematics device can avoid operational interference by not using any asset data requests that would lead to errors, specifically targeting the determined asset platform.

[0115] For vehicle assets, "vehicle tags" assist in identifying the vehicle platform. The telematics device determines the vehicle platform by detecting at least one tag on the vehicle's interface port. Using the identified vehicle platform, the telematics device selects the appropriate vehicle protocol to use with the vehicle, chooses the best vehicle data query for obtaining vehicle data, and avoids vehicle data requests that are mistakenly identified as targeting the identified vehicle platform.

[0116] Assets with multiple interfaces

[0117] Recently, some assets have built multiple interfaces on their interface ports. Each interface connects to the asset's communication bus. Typically, assets with more than one interface have two interfaces: a primary interface and a secondary interface. (See reference...) Figure 6 The diagram shows a conceptual block diagram of interface port 102 for an asset. Interface port 102 includes a main interface 102A and a secondary interface 102B. The main interface 102A is connected to the main asset communication bus 105A, and the secondary interface 102B is connected to the secondary asset communication bus 105B. The main interface 102A is typically used to exchange standard messages that are mandated to conform to specific standards. Examples of standard messages include: standard broadcast message 702, standard request message 704, and standard response message 706. The secondary interface 102B is typically used to exchange proprietary messages, including proprietary broadcast message 712, proprietary request message 714, and proprietary response message 716. However, in some cases, standard messages may be sent on the secondary interface 102B, and proprietary messages may be sent on the main interface 102A.

[0118] For vehicle assets, vehicle manufacturers have begun using multiple CAN buses on vehicles to exchange different types of messages. For most vehicles, interface port 102 takes the form of OBD-II port 300. Some vehicles now use two CAN buses, with the primary CAN bus serving as the primary asset communication bus 105A and the secondary CAN bus serving as the secondary asset communication bus 105B. The primary CAN bus is accessed via the primary CAN interface, and the secondary CAN bus is accessed via the secondary CAN interface. The primary and secondary CAN interfaces are interface pins on the vehicle's OBD-II port J1962 connector. Figure 9 It shows Figure 3The OBD-II J1962 connector is used, but with additional signals specified for the secondary CAN bus. It has been observed that the primary CAN bus is typically accessible via interface pins 6 and 14. Therefore, the primary interface includes the first CAN interface (CAN1) using pins 6 (CAN1H) and 14 (CAN1L). Different vehicle types use different pins for the secondary CAN interface. The second CAN interface (referred to as CAN2) uses pins 2 (CAN2H) and 10 (CAN2L). The third CAN interface (referred to as CAN3) uses pins 3 (CAN3H) and 11 (CAN3L). The single-wire CAN interface (referred to as SWC) uses pin 1. Because SWC uses digital logic voltages, the signals on SWC are relative to ground. In other words, SWC uses pins 1 and 5 (signal ground). The most commonly used CAN interface is CAN1, which uses interface pins 6 and 14. Therefore, vehicles using two CAN buses typically route the primary CAN bus to interface pins 6 and 14 (CAN1), and the secondary CAN bus to any one of CAN2, CAN3, or SWC.

[0119] The primary CAN interface is typically used for mandatory and standard protocol messages. For example, OBD and UDS messages, as well as standard broadcast CAN messages, are usually transmitted on the primary CAN bus, which is routed to the primary CAN interface (CAN1) using interface pins 6 and 14. Secondary CAN interfaces are typically used for proprietary messages specific to a particular vehicle platform. While this is generally the case, some vehicles may include ECUs that exchange proprietary messages on the primary CAN interface. Similarly, some vehicles may include ECUs that exchange standard protocol messages on secondary CAN interfaces. Typically, vehicles do not use multiple secondary CAN interfaces; that is, there is usually one primary CAN interface and one secondary CAN interface.

[0120] Assets with restricted access interfaces

[0121] Some assets may have an asset communication bus, a gateway, and an interface port. In such assets, the gateway is located between the asset communication bus and the interface port. The gateway has one or more rules that prevent certain data from being transmitted from the asset communication bus to the interface port. For example, the gateway may block broadcast traffic from one or more ECUs from reaching the interface port. Conversely or additionally, the gateway may prevent request messages from reaching the asset communication bus.

[0122] For example, in the case of a vehicle asset having a bus gateway, refer to Figure 8 . Reference Figure 8Gateway 107 is an electronic device that connects CAN bus 104 to interface port 102. Gateway 107 is configured to allow only certain types of data to be transmitted from CAN bus 104 to interface port 102. For example, in some implementations, gateway 107 prevents broadcast CAN data frames from being transmitted from CAN bus 104 to interface port 102. Therefore, a telematics device connected to interface port 102 cannot capture any broadcast vehicle data, such as broadcast CAN data frames. In some implementations, gateway 107 blocks some or all vehicle data requests (e.g., requests made using OBD and / or UDS protocols) and prevents them from reaching CAN bus 104.

[0123] Coupled wire harness

[0124] For vehicle assets, coupling harnesses have been developed to capture vehicle data using capacitive coupling to one or more signal lines within the vehicle. The coupling harness comprises capacitive clips clamped onto the signal lines within the vehicle. In some implementations, the coupling harness is configured to clamp onto CAN bus signal lines (wires) corresponding to the CANH and CANL signals. As signals travel across the CAN bus signal lines, the capacitive clips capture the signals through capacitive coupling. For example, see reference... Figure 9 A simplified depiction of a coupling harness 900 is shown, which captures asset data in the form of coupled CAN signals from CAN bus 104 (or other signal lines containing asset data) and transmits the coupled CAN signals to telematics device 201 via I / O expander interface 250. Figure 9 In the example, I / O expander interface 250 is a CAN transceiver.

[0125] In addition to the main CAN interface and the secondary CAN interface, the coupling harness can be used as a third asset communication bus and a third asset interface. Alternatively, vehicles using only the main CAN interface (CAN1, interface pin 6 and interface pin 14) can provide proprietary messages or information on the third CAN interface provided by the coupling harness 900. Figure 10 This is a simplified block diagram depicting a telematics device 200 having a primary asset interface 202A, a secondary asset interface 202B, and a third asset interface in the form of an I / O expander interface 250 and a coupling harness 900. Figure 10 In the middle, the main asset interface 202A uses interface pin 6 and interface pin 14 ( Figure 7The primary CAN interface is CAN1. The secondary asset interface 202B is connected to CAN2 (pins 2, 10), CAN3 (pins 3, 11), and SWC (pins 1, 5) in a multiplexed arrangement. As described below, the telematics device 200 needs to determine which of the CAN2, CAN3, and SWC interfaces is used by the vehicle as the secondary asset interface. The telematics device 200 undergoes a process in which different possible interfaces are examined to determine the primary and secondary asset interfaces used by the asset.

[0126] Asset platforms that identify assets with multiple interfaces

[0127] In one aspect of this disclosure, and with reference to Figure 11 A method 1100, executed by a telematics device, is provided. Method 1100 is used to identify an asset platform. The method begins at step 1110, wherein the telematics device 200 determines a primary interface among a plurality of interfaces to which the telematics device 200 is coupled. Determining the primary interface includes detecting an asset activation event on a first interface among the plurality of interfaces. For example, refer to... Figure 7 and Figure 9The telematics device 200, coupled to the vehicle asset, determines that the CAN interface CAN1 (i.e., interface pins 6 and 14) is the main interface when the telematics device detects a vehicle start event on interface pins 6 and 14. For vehicles with an internal combustion engine (ICE), the vehicle start event is an ignition event. Detecting an ignition event may include detecting a revolutions per minute (RPM) greater than a certain threshold. For example, for vehicles with an ICE, detecting an ignition event may begin with sensing motion via IMU 290, indicating that someone has entered the vehicle. After sensing motion, the battery voltage may be checked for a cranking event, in which the battery voltage drops significantly and then rises to a charging level. After detecting a cranking event, the telematics device 200 checks various interface pins for data using different protocols and different baud rates. For example, the telematics device 200 may try different protocols, such as CAN, J1939, or CANOpen. Detecting an ignition event may include requesting RPM on each set of interface pins of the interface port using different combinations of protocols and baud rates. When a telematics device receives an RPM value greater than a certain threshold on a specific interface signal line, it designates that interface as the primary asset interface. For example, if a vehicle responds to an RPM on the first CAN interface (CAN1, interface pins 6 and 14), the telematics device designates CAN1 as the primary asset interface for that vehicle. For EVs, the asset activation event is the EV ON signal, indicating that the EV is turned on. Most EVs report such signals on interface pins 6 and 14, while some EVs may report the EV ON signal on pins 3 and 11.

[0128] At step 1120, the telematics device 200 determines the secondary asset interface of the asset. Determining the secondary asset interface involves examining all interface pins except those designated as the primary asset interface. For each of the multiple asset interfaces other than the primary asset interface, the telematics device examines understandable asset data. The telematics device examines the understandable asset data by listening on each interface using a specific protocol and a specific baud rate combination. In some implementations, the telematics device 200 stores a table of communication protocols and associated supported baud rates. The telematics device 200 iterates through such a table and listens on each of the multiple asset interfaces other than the primary asset interface. The telematics device 200 decodes any asset data obtained through listening and checks whether it contains understandable asset data. Understandable asset data refers to asset data containing expected information and values ​​typically used by standard or proprietary protocols. For example, understandable asset data may contain CAN data frames, transport frames, diagnostic protocol frames, or proprietary data frames that the telematics device identifies as carrying information that can be decoded. Detecting understandable asset data on an asset interface confirms that the asset interface uses the communication protocol at the baud rate it uses. Detecting understandable asset data on an asset interface also confirms that the asset uses such an asset interface as a secondary asset interface. Up to this point, the telematics device 200 has only been listening to data in an attempt to identify the secondary asset interface. However, it is possible that the secondary asset interface does not contain much broadcast asset data, so simply listening is insufficient for the telematics device 200 to identify the secondary asset interface. When no understandable asset data is detected in response to listening for understandable asset data, the telematics device 200 uses a more proactive method to identify the secondary asset interface. Specifically, the telematics device sends requests on multiple interfaces of the asset, excluding the primary asset interface. For each of the multiple asset interfaces other than the primary asset interface, the telematics device sends at least one asset data request on the current interface other than the primary asset interface using a different combination of asset communication protocol and baud rate. The telematics device 200 iterates through the interfaces, selecting one interface at a time and sending a request on it using the asset communication protocol and baud rate combination. In this disclosure, "current interface" is the interface currently selected by the telematics device 200 on which it is sending an asset data request. In response to receiving at least one response to at least one request, the telematics device designates the current interface, other than the primary asset interface, as the secondary asset interface among a plurality of interfaces.

[0129] In step 1130, the telematics device detects a first tag on the main asset interface. Detecting a tag means receiving asset data with a signature containing a pattern of the first tag. For example, on the main interface of a vehicle using the CAN protocol, receiving a CAN data frame with a specific value in CAN identifier 602 may include detecting the first tag. As another example, the telematics device 200 may send a vehicle data request using one of the standard protocols (e.g., OBD or UDS) and then receive a vehicle data response corresponding to the vehicle data request. Receiving the vehicle data response may include detecting the first tag. In other implementations, receiving a vehicle data response with a specific value at a specific location within the response frame may include detecting the first tag. In some implementations, the absence of broadcast asset data for a predetermined duration may include detecting the first tag. For example, some vehicles may not broadcast certain data, while others may. In this case, the absence of data may include detecting the first tag. As discussed, most tags checked on the main interface correspond to standard protocol frames, such as broadcast CAN frames, OBD requests and responses, and UDS requests and responses. In most implementations, the tags checked at the main interface are standard tags. Standard tags are patterns or signatures found in standard protocol frames. Standard tags can be broadcast, i.e., as part of a broadcast frame, such as a broadcast CAN data frame. Alternatively, standard tags can be sent in asset data responses, such as responses to OBD or UDS requests.

[0130] At step 1140, the telematics device detects a second tag on the secondary asset interface. As discussed, the secondary asset interface is primarily used for proprietary messaging specific to a particular asset platform. Detecting a second tag on the secondary interface may include detecting proprietary tags broadcast on the secondary asset interface. A proprietary tag is a signature of a pattern present in a proprietary frame broadcast on the secondary asset interface. Detecting at least one tag on the secondary asset interface may also include detecting a proprietary tag in response to sending a proprietary request on the secondary asset interface. In this case, the telematics device sends an asset data request using a proprietary protocol and checks for an asset data response with a specific signature or pattern (if any). If the signature or pattern is present in the asset data response, the telematics device has detected a proprietary tag. Detecting a second tag on the secondary asset interface may also include detecting the absence of proprietary broadcast tags within a predetermined duration. To differentiate between different asset platforms, listening to proprietary broadcast tags can provide insight into the asset platform or at least eliminate some possible asset platforms. For example, the absence of periodically sent proprietary broadcast tags can allow the elimination of some asset platforms and thus aid in identifying the asset platform of an asset.

[0131] In step 1150, the telematics device determines the asset platform based on the detection of a first tag on the primary asset interface and the detection of a second tag on the secondary asset interface. (Refer to...) Figure 12 In some implementations, tags detected on the primary asset interface 1320 are used to determine the first asset sub-platform 1220, and tags detected on the secondary asset interface 1330 are used to determine the second asset sub-platform 1230. The telematics device 200 determines the asset platform 1210 from the first asset sub-platform 1220 and the second asset sub-platform 1230. For example, the first asset sub-platform may contain a first set of asset types, and the second asset sub-platform may contain a second set of asset types. The telematics device can derive the asset platform 1210 by performing a set intersection operation on the first and second sets of asset types. The result is a set of asset types representing the asset platform 1210. In another implementation, the asset platform 1210 is the union of the first and second sets of asset types.

[0132] In some implementations, the asset provides a primary asset interface, a secondary asset interface, and a third asset interface. In this implementation, method 1100 further includes the additional step of determining the third asset interface. For a vehicle asset, determining the third asset interface involves reading broadcast asset data from the coupling harness 900 and checking the broadcast tag. In this case, the third asset sub-platform is determined based on the broadcast tag on the third asset interface.

[0133] Advantageously, the asset platform is determined, thereby optimally obtaining asset data from the assets and avoiding operational interference.

[0134] Implementations of the technology in circuit systems and / or computer-executable instructions have been described. It should be understood that some implementations may take the form of methods or processes, and at least one example of such methods or processes has been provided. Actions performed as part of a method or process can be ordered in any suitable manner. Therefore, implementations can be constructed that perform actions in an order different from the order shown, which may include performing some actions simultaneously, even if they are shown as sequential actions in the illustrative embodiments. Various aspects of the above-described embodiments can be used individually, in combination, or in various arrangements not specifically discussed in the embodiments described above, and are therefore not limited in their application to the details and arrangements of the components set forth in the above description or shown in the accompanying drawings. For example, aspects described in one embodiment can be combined in any way with aspects described in other embodiments.

Claims

1. A method executed by a telematics device, comprising: Identify the primary asset interface among multiple interfaces on the interface port of the asset to which the remote information processing device is coupled; Identify the sub-asset interface among the plurality of interfaces; Detect the first tag on the main asset interface; Detect the second tag on the secondary asset interface; as well as The asset platform is determined based on the detection of the first tag on the main asset interface and the detection of the second tag on the secondary asset interface.

2. The method according to claim 1, wherein, The main asset interface is associated with the first set of interface pins on the interface port.

3. The method according to claim 1 or 2, wherein, The sub-asset interface is associated with a second set of interface pins on the interface port.

4. The method according to any one of claims 1 to 3, further comprising: Based on the identified asset platform, select at least one asset data query to obtain asset data.

5. The method according to claim 4, further comprising: The at least one asset data query is performed by listening to broadcast asset data or by sending an asset data request to the asset via the interface port and processing the received corresponding asset data response.

6. The method according to any one of claims 1 to 5, wherein, The main asset interface is determined to include detecting asset activation events on a first interface among the plurality of interfaces.

7. The method according to claim 6, wherein, Detecting the asset activation event includes: For each of the plurality of interfaces: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Attempt to detect the asset activation event.

8. The method according to any one of claims 1 to 7, wherein, The sub-asset interface is defined as including: For each of the plurality of interfaces other than the main asset interface: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Listening to understandable asset data; and When understandable asset data is detected on the current interface among the plurality of interfaces, the current interface among the plurality of interfaces is designated as the sub-asset interface.

9. The method according to claim 8, wherein, The sub-asset interface also includes: When responding to listening for understandable asset data but no understandable asset data is detected: For each of the plurality of interfaces other than the main asset interface: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Send a request for asset data on the current interface other than the main asset interface among the plurality of interfaces; and In response to receiving a response to the request, the current interface other than the primary asset interface among the plurality of interfaces is designated as the secondary asset interface.

10. The method according to any one of claims 1 to 9, wherein, Detecting the first tag on the main asset interface includes one of the following: Detect the first standard tag broadcast on the main asset interface; Detect the second standard tag in response to sending a standard request on the main asset interface; as well as The missing third standard label is detected on the main asset interface within a predetermined duration.

11. The method according to any one of claims 1 to 10, wherein, Detecting the second tag on the secondary asset interface includes one of the following: Detect the first proprietary broadcast tag on the secondary asset interface; Detect the second proprietary tag in response to sending a proprietary request on the secondary asset interface; as well as The missing third proprietary broadcast tag is detected on the secondary asset interface within a predetermined duration.

12. The method according to any one of claims 1 to 11, wherein, The asset platform is defined as including: The first asset sub-platform is determined based on the detection of the first tag on the main asset interface; The second asset sub-platform is determined based on the detection of the second tag on the secondary asset interface; and The asset platform is determined based on the first asset sub-platform and the second asset sub-platform.

13. The method according to any one of claims 1 to 11, further comprising determining a third asset interface among the plurality of interfaces, wherein, The asset platform is defined as including: The first asset sub-platform is determined based on the detection of the first tag on the main asset interface; The second asset sub-platform is determined based on the detection of the second tag on the secondary asset interface; The third asset sub-platform is determined based on the detection of a third tag on the third asset interface; and The asset platform is determined based on the first asset sub-platform, the second asset sub-platform, and the third asset sub-platform.

14. The method according to claim 13, wherein, The third asset interface includes a coupling harness that captures asset data via capacitive coupling.

15. A telematics device for connecting to an asset, comprising: Controller; An asset interface coupled to the controller, the asset interface being used to connect the telematics device to the asset's asset communication bus; A network interface coupled to the controller; as well as A memory coupled to the controller stores machine-executable programming instructions that, when executed by the controller, configure the telematics device to: Identify the primary asset interface among multiple interfaces on the interface port of the asset; Identify the sub-asset interface among the plurality of interfaces; Detect the first tag on the main asset interface; Detect the second tag on the secondary asset interface; as well as The asset platform is determined based on the detection of the first tag on the main asset interface and the detection of the second tag on the secondary asset interface.

16. The remote information processing apparatus according to claim 15, wherein, The main asset interface is associated with the first set of interface pins on the interface port.

17. The remote information processing apparatus according to claim 15 or 16, wherein, The sub-asset interface is associated with a second set of interface pins on the interface port.

18. The telematics apparatus according to any one of claims 15 to 17, wherein, The machine-executable programming instructions also configure the telematics device to: select at least one asset data query to obtain asset data based on the determined asset platform.

19. The remote information processing apparatus according to claim 18, wherein, The machine-executable programming instructions also configure the remote information processing device to perform at least one asset data query by listening to broadcast asset data or by sending an asset data request to the asset via the interface port and processing the received corresponding asset data response.

20. The remote information processing apparatus according to claim 15, wherein, The machine-executable programming instructions that configure the telematics device to determine the main asset interface include the following machine-executable programming instructions: the machine-executable programming instructions configure the telematics device to detect an asset activation event on a first interface among the plurality of interfaces.

21. The remote information processing apparatus according to claim 20, wherein, The machine-executable programming instructions that configure the telematics device to detect asset activation events on a first interface of the plurality of interfaces include the following machine-executable programming instructions: These machine-executable programming instructions configure the telematics device to: For each of the plurality of interfaces: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Attempt to detect the asset activation event.

22. The telematics apparatus according to any one of claims 15 to 21, wherein, The machine-executable programming instructions that configure the telematics device to determine the sub-asset interface include the following machine-executable programming instructions: These machine-executable programming instructions configure the telematics device to: For each of the plurality of interfaces other than the main asset interface: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Listen to understandable asset data; as well as When understandable asset data is detected on the current interface among the plurality of interfaces, the current interface among the plurality of interfaces is designated as the sub-asset interface.

23. The remote information processing apparatus according to claim 22, wherein, The machine-executable programming instructions that configure the telematics device to determine the sub-asset interface further include the following machine-executable programming instructions: these machine-executable programming instructions configure the telematics device to: When responding to listening for understandable asset data but no understandable asset data is detected: For each of the plurality of interfaces other than the main asset interface: For each combination of one asset communication protocol among multiple asset communication protocols and one baud rate among multiple baud rates: Send a request for asset data on the current interface other than the main asset interface among the plurality of interfaces; as well as In response to receiving a response to the request, the current interface other than the primary asset interface among the plurality of interfaces is designated as the secondary asset interface.

24. The telematics apparatus according to any one of claims 15 to 23, wherein, The telematics device is configured to detect the machine-executable programming instructions of the first tag on the main asset interface, including one of the following: The telematics device is configured to detect machine-executable programmable instructions of a first standard tag broadcast on the main asset interface; The telematics device is configured to detect machine-executable programmable instructions for a second standard tag in response to a standard request sent on the main asset interface; as well as The telematics device is configured to detect the absence of a third standard tag on the main asset interface for a predetermined period of time via machine-executable programmable instructions.

25. The telematics apparatus according to any one of claims 15 to 24, wherein, The telematics device is configured to detect the machine-executable programming instructions of the second tag on the secondary asset interface, including one of the following: The telematics device is configured to detect machine-executable programmable instructions for a first proprietary broadcast tag on the secondary asset interface. The telematics device is configured to detect machine-executable programmable instructions for a second proprietary tag in response to a proprietary request sent on the secondary asset interface. as well as The telematics device is configured to detect the absence of a third proprietary broadcast tag on the secondary asset interface for a predetermined duration via machine-executable instructions.

26. The telematics apparatus according to any one of claims 15 to 25, wherein, The telematics device is configured to determine that the machine-executable programming instructions of the asset platform include the following machine-executable programming instructions: These machine-executable programming instructions configure the telematics device to: The first asset sub-platform is determined based on the detection of the first tag on the main asset interface; The second asset sub-platform is determined based on the detection of the second tag on the secondary asset interface; as well as The asset platform is determined based on the first asset sub-platform and the second asset sub-platform.

27. The telematics apparatus according to any one of claims 15 to 25, wherein, The machine-executable programming instructions further include machine-executable programming instructions for configuring the telematics device to determine a third asset interface among the plurality of interfaces, wherein the machine-executable programming instructions for configuring the telematics device to determine the asset platform include: The telematics device is configured to detect machine-executable programmable instructions of the first asset sub-platform based on the detection of the first tag on the main asset interface. The telematics device is configured to detect machine-executable programmable instructions of the second asset sub-platform based on the detection of the second tag on the sub-asset interface. The telematics device is configured to detect machine-executable programming instructions of the third asset sub-platform based on the detection of a third tag on the third asset interface; and The telematics device is configured to determine the machine-executable programming instructions of the asset platform based on the first asset sub-platform, the second asset sub-platform, and the third asset sub-platform.

28. The remote information processing apparatus according to claim 27, wherein, The third asset interface includes a coupling harness that captures asset data via capacitive coupling.

Images