Built-in Remote Diagnostics

Embedded Remote Diagnostics - THE FUTURE OF REMOTE DIAGNOSTICS

 

The ability to diagnose a vehicle is a very important aspect of vehicle architecture. The most common approach followed in the automotive industry is to gain access to all diagnostic data (DTCs, measurement values, etc.) via the vehicle's OBD-II port. There are tools available on the market that help service technicians to access the status of different vehicle subsystems according to troubleshooting and apply repair procedures. However, the service tool approach can only solve the problem when the technician is physically present at the vehicle site

 

As mobility becomes the norm in all industries, remote vehicle diagnostics can hardly be labelled an exception. With a greater level of incorporation of electronics and software into vehicles, customer expectations for reduced downtime and maintenance times are on the rise. Based on this changing customer dynamic, the industry is anticipating and considering solutions that will enable complete vehicle diagnostics in remote locations.

 

Today, there are numerous solutions available on the market that claim competent remote diagnosis using OBD-II dongles. However, the fact remains that these solutions can only read diagnostic information relevant to emission standards, thus limiting the added value to the service technician from an overall diagnostic perspective (On & Off-board).

 

The embedded diagnostics approach (presented in this article) uses the infrastructure components specified in the ISO standard (i.e. ODX, OTX) as a basis, thus paving the way for a data-driven architecture. The in-vehicle diagnostic infrastructure components allow seamless communication with the ECU network in a manner similar to how the Service tool works, thus allowing all diagnostic use cases to be executed from remote locations.

 

 

 

Built-in diagnostics:

 

Ecosystem view

 

The whole solution consists of 5 main components. Telematics Control Unit (TCU), diagnostic time, OTX sequences, ODX data and diagnostic server to support diagnostic functions

 

The TCU provides the environment and resources needed to run Diagnostic-Runtime to perform various use cases such as Data Identifier Reading (DID), vehicle scanning, reprogramming, etc. Normally, the TCU runs LINUX as an operating system with varying sizes of RAM/Flash Memory and CPU power.

Diagnostic runtime provides infrastructure components for diagnostic communication over the network (CAN, Ethernet, etc.). Infrastructure components include diagnostic APIs, OTX runtime, D-Server APIs and D-PDU APIs. Diagnostic APIs provide a comfort layer on top of the D-Server and OTX Runtime components to provide a comfort layer for engineering, end-of-line and after-sales service use cases. It is a component that can be customized to your diagnostic requirements.

 

OTX Runtime provides an environment to execute OTX procedures and get results as defined. D-Server APIs define an object-oriented application programming interface to provide access to measurement and adjustment objects and diagnostic services. The D-PDU APIs define the application programming interface to abstract communication through diagnostic protocols and the Modular Vehicle Communication Interface (MVCI) module description.

 

The Diagnostic Server hosts the application that implements the HMI for the end user and also communicates with the TCU for the exchange of diagnostic information. Communication between the diagnostic server and the TCU takes place via standard messaging protocols, such as Message Queuing Telemetry Transport (MQTT), as the reliability of data transmission is the highest priority.

 

Reference architecture [A]

 

The above architecture assumes that the necessary hardware resources are available inside the TCU. If the TCU has hardware resource limitations, the architecture is very flexible to support these limitations, if any.

 

In a resource-constrained scenario, it is possible to implement only lightweight D-PDU API components on the TCU and the rest of the components (diagnostic APIs, OTX Runtime, D-Server APIs) can be implemented on the remote server.

 

The concept of such an architecture [B] is presented below.

Architecture selection requires a trade-off analysis in terms of business requirements, e.g. support for online/offline mode, required use cases (full service functionality versus reprogramming only), etc.

 

Challenges

 

While the approach mentioned in this article enables next-generation diagnostic capabilities, it also invites certain challenges that must be addressed to become a viable candidate for production. Some of these challenges are as mentioned:

 

Vehicle condition management

For example, the on-board diagnostic stack must ensure that it does not overload network traffic or interfere with vehicle functions in the event of a fault

Security

Diagnostic content available on-board and to/from TCU data must be highly secured to prevent unauthorised access to it

Software updates

Availability of the necessary infrastructure to support over-the-air upgrades in case software components in the TCU fail

Cell bandwidth

Ensure optimal use of cellular bandwidth for data transmission between diagnostic server and TCU

Limited hardware resources inside the TCU

Software running inside the TCU must be very efficient to operate within the resource availability limit, at the same time it should ensure that other TCU applications do not impact

 

Conclusions

 

 

The software components mentioned in this article already exist and are used in the production of various use cases for engineering, manufacturing and after-sales services. In addition, more and more OEMs are in the process of introducing TCUs as a core component of their vehicle architecture. Rapidly changing technology trends, evolving customer expectations and a highly competitive market will drive OEMs and TCU suppliers to adopt the stated approach to building the diagnostic systems of the future. At KPIT, we have already witnessed such a trend with our technologically advanced customers. KPIT's Diagnostics and Connectivity Platform (K-DCP) is already in production (in the embedded environment) and serves use cases such as over-the-air ECU interfacing and remote diagnostics.

 

Future perspectives

 

Embedded vehicle diagnostics has the potential to generate benefits throughout the automotive value chain. At the OEM end of the chain, they stand to gain enormously by reducing costs associated with vehicle recalls, reducing claims for no-fault backed warranty (NTF), all made possible through advanced, guided diagnostics. Service reps will benefit from improved Fix-First-Visit ratios, reduced service time and costs through remote/guided diagnostics, achieving higher technician efficiency and productivity, and last but not least, the customer (vehicle owner) will enjoy higher levels of comfort and convenience through service dealers' newfound abilities in preventive/predictive maintenance, resulting in improved vehicle uptime.

 

With the prospects of creating a win-win for all involved, it's safe to say that the Embedded Diagnostics space will continue to evolve and grow and, most importantly, find more believers, every day!