Softing envisions secure, reliable predictive maintenance
This article also appears in
Subscribe now »
Graphical user interface of model selection in TDX.workshop demo. (Softing)

Softing envisions secure, reliable predictive maintenance

As heavy-duty vehicles become increasingly automated, on-board diagnostics, condition monitoring and predictive maintenance become even more vital.

Modern heavy-duty vehicles, such as trucks and buses but also forestry and agricultural machines or construction equipment, are packed with E/E components that support self-diagnostic functions and increase the quality of maintenance, service, and repair processes. In service workshops, “right the first try” reduces expensive downtime and saves a lot of money. This objective is supported by a process that captures the already generated in-vehicle data and sends it to a cloud server for analysis and the creation of vehicle- and/or fleet-specific predictive maintenance sequences. The sequences support the service technician in the predictive maintenance process.

Current condition-monitoring systems continuously monitor specific parameters during operation, such as temperatures, vibration, and acoustic emissions to detect upcoming failures, but they need sensors that are usually not necessary for operation. Most conditioning-monitoring systems work well for stationary machines. In the E/E system of a moving vehicle, control units exchange data over an in-vehicle network and execute self-diagnostic functions. If a severe failure occurs, a diagnostic trouble code (DTC) is stored and in some cases a warning lamp is switched on, so the driver can get the vehicle to the next service workshop; however, by then it already can be too late.

Figure 1 shows the setup for Inspection and Maintenance (I/M) with a simplified architecture of a vehicle’s E/E system. The Data Link Connector (DLC, e.g. SAE J1962 or SAE J1939-13) is connected to the Gateway, which separates the diagnostic channel (DoCAN) from the in-vehicle network (CAN). As a result, it is not possible to monitor the CAN traffic between the control units (ECM, TCM) at the DLC.

For service and maintenance, the technician follows the guided diagnostics/fault-finding process. The communication between the diagnostic tester (TST) and the vehicle’s E/E system consists of diagnostic service requests sent from the TST to the vehicle and diagnostic service responses sent by the vehicle to the TST. In the workshop, the DLC of the vehicle is connected to a Vehicle Communication Interface (VCI). The DLC-to-VCI connection (1) is either highspeed-CAN or 100Base-TX 4-wire Ethernet.

The VCI is connected to the TST, which supports (diagnostic) communication protocols such as OBD on CAN, SAE J1939, UDS on CAN or UDS on IP. While the connection between the vehicle and the VCI is always wired, the VCI-to-TST connection (2) is either wired (USB, Ethernet) or wireless (Wi-Fi).

Note: A big difference between service of heavy-duty road vehicles and service of non-road mobile machinery (NRMM) is that a road vehicle is usually driven to a workshop, whereas the service technician must drive to the NRMM for service. And, the technician must bring the test equipment to the machine.

The extended Telematics Control Unit (xTCU) connects the vehicle with a cloud infrastructure via radio data link (4G/LTE). Installed in the vehicle, it is connected to the (powertrain) CAN and the DLC. It monitors the CAN traffic and logs pre-configured CAN messages. In addition, it supports diagnostic protocols for requesting diagnostic data. Figure 2 shows the xTCU of Globalmatix AG.

The xTCU comes with an embedded Subscriber Identity Module (eSIM) for unambiguous identification and a modem with antenna as 4G/LTE radio data link to the cloud storage system, such as Microsoft Azure or Amazon AWS. In this use case, the xTCU acts as a CAN-to-LTE gateway. For the precise determination of the vehicle’s position, the xTCU contains a Global Navigation Satellite System (GNSS). It also measures acceleration, deceleration, and the angular velocity via a gyroscope.

Installed in a vehicle (Figure 3), the xTCU typically shifts several hundred data values per second in the cloud. Other than in the workshop setup shown in Figure 1, when the vehicle is not moving and connected to the stationary tester only for a few minutes, the xTCU periodically acquires data (signals) over time and under real driving conditions.

Note: The ISO 14229-Service 0x22 = read data by identifier is parameterized by a 2-Byte data identifier (DID), meaning that the DID theoretically represents 65,535 different data values. In addition, the vast number SAE J1939 Suspect Parameter Numbers (SPNs) is continuously increasing.

The acquisition of preconfigured data over time and a smart analysis allows a vehicle-specific condition monitoring. Condition monitoring allows the identification of significant parameter changes and thus the prediction of a failure or breakdown – before it occurs. Condition monitoring is a major component of predictive maintenance.

Figure 4 illustrates a fleet of vehicles, each equipped with an xTCU. The fleet data is sent to the cloud as MQ Telemetry Transport (MQTT) packets, decompressed and decrypted, and then further analyzed and processed. Usually, the objective of the data analysis is to generate data for a Computerized Maintenance Management System (CMMS). In this use case, we generate predictive maintenance instructions and describe them in the internationally standardized Open Test Sequence (OTX) format. The OTX scripts are part of the parameter set (content) of a TDX-based workshop tester.

TDX content is generated with TDX.studio, which is a toolbox with tools for the development of a diagnostic tester. In this use case, the diagnostic tester is also parameterized by OTX sequences for predictive maintenance. The hardware of the TDX TST can be either a WIN-PC or a smart device with iOS or Android as Operating System. Figure 5 shows the software components of the TDX TST.

The Smart Diagnostic Engine (SDE) processes OTX scripts, using diagnostic data that is stored in ODX files. ODX files contain the specification of the diagnostic requests and responses and the information to translate hexadecimal diagnostic data in meaningful values. The application of the TDX TST processes diagnostic sequences and test sequences, such as actuator tests. The graphical user interfaces of the TDX TST are created in the platform-independent language QML (Qt Company).

Especially in automated and autonomous vehicles and machines, control is withdrawn from the driver or machine operator. For safety reasons, the reliable and error-free function of the entire system and all its components must be guaranteed at all times. Functional safety, cybersecurity, on-board diagnostics (OBD), condition monitoring and predictive maintenance become more important than ever.

Peter Subke, director of business development for Softing Automotive Electronics GmbH, wrote this article for SAE Truck & Off-Highway Engineering magazine.

Continue reading »
X