Objective 2 – The truth behind Telemetry Data

The collection of telemetry data creates significant opportunities for OEMs to gather more information and insight into their product’s condition during its use phase from the real time

aerospace industry, to monitor the condition of products remotely. The primary function of the system is to extract raw or pre-processed data and transmit the data by means of wireless communication devices remotely to a dedicated radio receiver for real time monitoring, data analysis etc. Telemetry systems do not create any data, but may pre-process raw data in order to lower the transmission cost by reducing the amount of data before transmitting. Data are typically signals created by electronic devices, installed at the key areas or components that require close monitoring within the product, and the data are broadcast as messages onto a CAN bus, being a specialised internal communication network that connects components inside various types of equipment ranging from agriculture and construction to on and off-highway vehicles.

The CAN bus is the standard which allows electronic devices to communicate to each other, without the requirement of a host computer. J1939 and J2012 are vehicle standards that dictate the communication and diagnostics between vehicle components and electronic devices. All messages are communicated as groups of binary codes categorized by a parameter group number (PGN), each PGN generally consists of 8 bytes of data. Some PGNs are already pre-allocated in J1939 to contain specific messages such as engine temperature.

However OEMs are allowed to create other own PGNs as proprietary CAN bus messages to be broadcasted globally within the CAN bus. Table 5-1 is an example of a PGN and the information it contains;

Name Engine temperature 1 - ET1

Transmission rate: 1s

Data Length: 8 bytes

Extended Data Page: 0

Data Page: 0

PDU format: 254

PDU specific: 238

Default priority: 6

PG Number: 65,262 (00FEEE16)

Description of data:

Byte: 1 Engine Coolant Temperature

2 Engine Fuel Temperature 1 3, 4 Engine Oil Temperature 1

5, 6 Engine Turbocharger Oil Temperature 7 Engine Intercooler Temperature

8 Engine Intercooler Thermostat Opening

Table 5-1: Example of a PGN definition

In this particular example, there are 6 messages embedded in the PGN. Due to the size of the message, two of them require 2 bytes to store the data. This is because engine temperature has to be measured at an increment of 0.03125 ºC/bit between a data range of -273 ºC to 1734.96875 ºC, in take into considerations extreme conditions and required resolution. 1 byte can only achieve a much lower resolution increment value of 7.84362793 ºC/bit for the same data range, therefore 2 bytes were used instead (SAE International 2015).

A Suspect Parameter Number (SPN) is assigned to each message in the PGN. SPN is a 19 bit number, ranging between 0 – 524287 for redefined messages and 520198 – 524287 for proprietary messages. Each SPN contains information about how the data can be interpreted in the units of the particular SPN. Table 5-2 is an example for such definitions and as the resolution is 0.4% per bit, any data captured from this SPN will need to be multiplied by 0.4 to obtain the true value before any analysis can be done.

SPN 38 – Fuel Level

Ratio of volume of fuel to the total volume of fuel in the second or right-side storage container.

Data Length: 1 bytes

Resolution: 0.4% bit, 0 offset

Data Range: 0 to 100% Operational Range: Same as data range

Type: Measured

Supporting Information:

PGN reference: 65276

Table 5-2: SPN Definition

On some equipment, the Electronic Control Unit (ECU) may support the diagnostic functions and be able to broadcast Diagnostic Messages on to the CAN bus, that contains a Diagnostic Trouble Code (DTC) to address suspected trouble or problem areas, and an indicator is used to dictate the appropriate service procedure. Each DTC is a combination dictated by SPN, FMI and the source address in accordance with ISO 15031-6:2010. A 3-byte DTC is the common structure adopted by OEMs, allowing them to create their own DTCs but also constraining them to use DTC that are controlled by ISO/SAE standards. As a result, an accurate record of all the OEMs’ proprietary DTCs definitions is essential to enrich the data for interpretation so that an appropriate service procedure can be selected.

However, as for any complicated electrical systems that consist of multiple functions, OEMs also need to be conscious of the data reliability. The proprietary list may be poorly maintained and became inadequate if it fails to capture any obsoleted or newly introduced DTCs.

Furthermore, faulty sensors from the suppliers or “bugs” in the diagnostic programs may remain undiscovered until a challenge is raised. Therefore, historical records such as warranty and service records were used to clarify hypotheses during this research project.

5.1.2.1 Key Findings of Work Package 2

A major finding from work package 2 is the significant effect of BCD on the productivity and fuel efficiency of a hydraulic excavator.. While productivity is a well-researched area within operations research, a review of literature and industry guidance identified a gap in respect of fuel efficiency and productivity for hydraulic excavators. It has been found that BCD and engine speed settings can affect fuel efficiency and productivity of the operation of a hydraulic excavator. In addition, the results over ruled the existing, common perception that the highest speed setting will achieve highest productivity. Conversely, low engine speed settings do not necessarily consume the least fuel to complete the same task. The results also

improvement on productivity (m³/h), 24% saving on fuel efficiency (l/kg) and an overall amount of 62% more spoil moved per hour and litre of fuel consumed. The relevant published paper can be found in appendix W. It is also important to understand that telemetry is not the source of real time product data but is merely a tool to remotely extract data from the local CAN bus network on the machine. The extracted data are signals generated by various electronic devices installed on the machines to monitor the behaviour of specific areas of interest. These signals are constantly being broadcast as simple messages such as fuel level or diagnostic messages in the form of DTCs. These messages are either controlled by ISO/SAE or are reserved as proprietary messages for particular OEMs, but all messages require the understanding of specific rules in order to decipher them into meaningful information.

Applying an appropriate analytical process to the current hydraulic CAN bus messages on a JCB twenty-two tonne class hydraulic excavator, enables these messages to be understood sufficiently to provide a certain level of product insight as required by PSS.