Big Data and Next-Gen Prognostics for Heavy-Duty Vehicles
Diagnostics have been around for a long time and are well understood and standardized. Huge amounts of diagnostic data have piled up over the years; fortunately, the data is machine readable. What is not as well understood is how to make efficient use of all that data.
Experts participating in the prognostics portion of the “Evolution of Big Data for Advanced Technology” symposium at SAE COMVEC 2018 will attempt to clarify the topic and provide some solutions to this challenging issue. As part of this forum, representatives from Casebank Technologies, RA Consulting, Robert Bosch, Volvo Trucks North America, and Softing Automotive Electronics will cover a range of topics tied to the next generation of prognostics development.
Advancements and challenges in automated driving, advanced driver-assistance systems (ADAS), connectivity, big data, and cybersecurity also are part of the COMVEC symposium, taking place Sept. 12-13 in Rosemont, Illinois.
One of the introductory presentations focusing on prognostics—summarized here—will address the question of how vehicle-specific data can be collected from the E/E system, transfer to the cloud and the interpretation by a cloud (D-) server.
Today, heavy-duty trucks and buses, as well as off-highway machines, are equipped with electronic control units (ECUs) that are connected to sensors and actuators. In addition, ECUs are connected to each other via in-vehicle networks, such as the controller area network (CAN). The assembly of all electrical and electronic components is referred to as the E/E system of the road-vehicle or mobile machine.
The E/E system processes digital coded information, meaning that it works with and produces data. Thus, the E/E system serves as a data source.
The data communication between ECUs is referred to as on-board communication. In addition, data can be read from the ECUs by sending a diagnostic service request, such as the ISO 14229 service request 0x22 = read data by identifier. Table 1 shows an excerpt of the data identifiers (DIDs) that can be requested with service 0x22. (Note: The examples of Table 1 only show static data that specify the architecture of the E/E system.)
Sending diagnostic service requests and receiving responses is referred to as diagnostic communication, which requires a diagnostic protocol to be supported by both the E/E system and the data acquisition system. In the context of this article, examples of diagnostic protocols are OBD, or on-board diagnostics (SAE J1979), SAE J1939-73 and UDS on CAN (ISO 14229 and ISO 15765).
OBD is legally required by the U.S. EPA and California Air Resources Board for all road-vehicles including heavy-duty trucks and buses.
What data is needed?
The evolution of big data starts with the answer to one question: What data do I need?
An unfiltered data-mining frenzy ends in several terabytes of data per vehicle, per day. Instead, the user of the data shall first specify the data needed and then find the sources. Examples of data sources include the vehicle specification (e.g., VIN, model, type, model year), owner-specific data (service workshop locations, fleet size, use cases), driver-specific data (driving hours, etc.), geographical data (GPS position latitude and longitude, road grade, barometric pressure, ambient temperature), maintenance data (last service, next service, downtime, uptime, work performed), and finally, E/E-system data as it is listed in Table 2.
This article deals with the E/E systems of heavy-duty road-vehicles (trucks and buses) as data sources. In the context of this article, data provided by the E/E system can be grouped as follows:
- Data of the CAN on-board communication (e.g., SAE J1939)
- OBD data (SAE J1939-73, SAE J1979)
- Enhanced service diagnostic data (ISO 14229-3 on ISO 15765-2).
A lot of data is available on the CAN bus as so-called on-board data. To read that data, a device needs to be connected to the CAN bus, and the CAN-specific parameters (CAN-ID and the associated content of the data field) must be known. If the E/E system supports SAE J1939, the information is available as Excel table SAE J1939-DA and can be purchased from SAE International. The subset of actually-available data is part of the E/E system specification and needs to be known by the user.
If the E/E system does not support J1939, the specification of the CAN matrix, which is usually stored in a dbc-file, must be available.
Figure 1 illustrates how a data acquisition device (xTCU, or extended telematics control unit) is connected to the E/E system of a road-vehicle. In this simplified example, the engine control module (ECM), the transmission control module (TCM) and the gateway (GW) are connected to each other by CAN.
On the left-hand side of Figure 1, the xTCU is connected to the CAN bus, reading the on-board communication. On the right-hand side, it’s connected to the Data Link Connector (DLC), which is commonly known as the OBD II port. And, the xTCU is connected to the GW for the purpose of diagnostic communication with a protocol other than SAE J1979.
If the data acquisition device is connected to the CAN bus, it can perform diagnostic communication to get data that is not on-board data. Today, the employment of UDS on CAN as a diagnostic protocol, especially within the powertrain of road-vehicles, can be considered as common practice.
Figure 2 shows the entire data acquisition system. The trucks are equipped with xTCUs that have access to the CAN and thus to the on-board data and to diagnostic data via J1979 and UDS. The xTCUs are equipped with a radio device (GSM, LTE, 4G) for the connection with the cloud server.
The connection of a fleet of trucks with the cloud server supports the acquisition of data that serves for prognostic applications.
Smart diagnostic engine
For the purpose of diagnostic communication, the firmware of the xTCU is equipped with a smart diagnostic engine, or sDE (Figure 3). The sDE consists of an MVCI (modular vehicle communication interface) compliant D-server according to ISO 22900 that processes ODX runtime data, and an OTX-RT that serves as an interpreter for OTX sequences. OTX is specified in ISO 13209, the ODX format in ISO 22901. The ODX database contains the diagnostic protocol and any information that is necessary for the interpretation of the diagnostic service responses.
Examples of OTX sequences for data acquisition include reading sets of measurement values and reading diagnostic data from distributed functions that are performed by multiple ECUs.
The sDE software modules are available as off-the-shelf products for Windows, ioS, Android and Linux. They can be easily integrated in existing hardware, such as digital tachographs or TCUs.
In the past, diagnostic data from vehicles were collected in the service workshops, then aggregated and analyzed by the vehicle manufacturer. The task of a workshop is to service the vehicle and get it on the road as quickly as possible—not to be burdened by the collection of data.
With an extended TCU that is installed in the vehicle, on-board and diagnostic data can be collected on-the-fly. If the TCUs are equipped with a radio data link, data from a fleet of vehicles can be sent to a cloud server. Smart data-analyzing procedures that support predictive maintenance will help to significantly increase the uptime of heavy-duty vehicles.
Peter Subke is Director of Business Development, Heavy-Duty Applications at Softing Automotive Electronics in Germany.