![Fig. 2- Reference Architecture [A].PNG](https://cdn.pressebox.de/r/15aea1e0aebeba44/attachments/98/19/76/thumbnail_981976_746x466.webp)
In today's times, Vehicle Manufactures are churning out new models and variants laced with hi-tech features, functionalities, and a host of Innovative Value-Adds, and they seem to be doing all this, almost at the Drop of a hat! From the side lines, it's only fair to think that the Automotive Industry has hit a purple patch, and is on a constant up-swing. Whilst, there is no denying the feats achieved by the Auto Industry in translating tech advancements to convenience, comfort and superlative driving experiences for the end users, there, however are a few fundamental challenges faced by the Industry, which if not tended to, could become a big sore in the very near future. Increasing No-Trouble-Found instances, Reduction in Fix-First-Visit (FFV) rates, Increasing vehicle downtimes, and resultant customer dis-satisfaction, top the list of the afore mentioned challenges.
So, where are these challenges stemming from?
As today's vehicles become more advanced, they start relying more and more on the electronic and software content, embedded within. As this quantum increases, it adds to the vehicle complexity, thereby impacting the ability to accurately diagnose, troubleshoot and repair the vehicle. Today's service technicians at the dealerships with access to conventional service tools, are constrained by the fact that they have to be near to the vehicle in-order to diagnose and conclude the root cause of the problem. Due to this, it increases service turnaround time, repair costs, and more so, it lowers the customer satisfaction. This Article, features one of the most advanced approaches to Vehicle Diagnostics, and highlights the need thereof, to enable service technicians with Next-generation Diagnostic tools, for a fair-pitched battle between the Man and his Machine.
Abbreviations used in the Article
DLC Data Link Connector, i. e. OBD II
ECU Electronic Control Unit (ISO 14229-1)
ODX Open Diagnostic Data eXchange (ISO 22901)
OTX Open Test Sequence eXchange (ISO 13209)
D-Server APIs Diagnostic Server Application Programming Interface (ISO 22900-3)
D-PDU APIs Protocol Data Unit (ISO 22900-2)
MVCI Modular Vehicle Connector Interface
UDS Unified Diagnostic Services (ISO 14229)
TCU Telematics Control Unit
DID Data Identifier
MQTT Message Queuing Telemetry Transport
INTRODUCTION
Ability to diagnose a vehicle is a very important aspect of the vehicle architecture. The most common approach followed within the automotive industry is to gain access to all the diagnostic data (DTC, measurement values etc.) through the vehicle's OBD-II port. There are tools available in the market (through OEMs or IAM vendors) which help service technicians access the status of the various vehicle subsystems, and in accordance troubleshoot the issues and apply repair procedures. However, the service tool based approach can fix the problem only when technician is physically present at the vehicle site.
As mobility is increasingly becoming a norm across Industries, remote vehicle diagnostics can hardly be labelled an exception. With ever increasing level of electronics and software components incorporation into vehicles, the customer's expectations on reduced down-times and servicing turn-around times, are growing in proportion. On the back of these changing customer dynamics, the Industry is anticipating and envisaging solutions that will enable comprehensive vehicle diagnosis from remote locations.
Today, there are numerous solutions available in the market claiming proficient remote diagnostics using OBD-II dongles. However, the fact remains, that these solutions can only read diagnostic information pertinent to emission norms, thereby limiting their Value-Add to the service technician from a holistic (On & Off-board) diagnostic perspective.
The Embedded diagnostic approach (showcased in this article) leverages ISO Standard specified Infrastructure components (i.e. ODX, OTX) as the foundation, thereby paving the way for a highly data driven architecture The diagnostic infrastructure components inside the vehicle allow seamless communication with the ECU network in a manner similar to how the Service tool functions, thereby enabling all the diagnostic use-cases to be executed from remote locations.
The entire solution comprises of 5 main components. The Telematics Control Unit (TCU), Diagnostic runtime, OTX sequences, ODX data and the Diagnostic server to support diagnostic functions.
The TCU provides the environment and necessary resources for the execution of Diagnostic-Runtime to realize different use-cases like read Data Identifier (DID), vehicle scanning, re-programming etc. Normally TCU runs LINUX as an operating system with varied sizes of RAM/Flash memory and CPU power.
OTX is a domain driven graphical programming language and allows one to create automated diagnostic procedures in a graphical manner. OTX procedures are specified in the standard XML format.
ODX is a XML based standard to define ECU diagnostic data in OEM independent way. It contains all necessary data for the diagnostic communication for example communication parameters, ECU variant relationship, diagnostic services, units of measures, precision, data-types etc. The complexity and size of the ODX data depends on ECU variants and amount of diagnostic services supported by the ECUs
Diagnostic runtime provides infrastructure components for the diagnostic communication over network (CAN, Ethernet etc.). The infrastructure components include, Diagnostic APIs, OTX runtime, D-Server APIs and D-PDU APIs. The Diagnostic APIs provide convenience layer on top of D-Server and OTX Runtime components to provide convenience layer for the engineering, assembly end-of-line and after-sales service diagnostic use-cases. It is a highly customizable component based on the diagnostic requirements.
The OTX Runtime provides environment to execute OTX procedures and derive output as defined. The D-Server APIs defines object oriented application programming interface to provide access to the measurement and adjustment objects and to the diagnostic services. The D-PDU APIs defines application programming interface to abstract communication over diagnostic protocols and description of Modular Vehicle Communication Interface (MVCI) module.
The Diagnostic server hosts the application which implements HMI for the end-user and it also communicates with the TCU for diagnostic information exchange. The communication between diagnostic server and TCU is happens over standard messaging protocols like Message Queuing Telemetry Transport (MQTT) as the data transmission reliability is the highest priority.
Challenges
While the approach mentioned in this article enables next generation diagnostic capabilities, it also invites certain challenges which need to be addressed to make it a viable production candidate. Some of those challenges are as mentioned:
Managing the state of the vehicle For example, On-board diagnostic runtime stack needs to ensure that it does not over-load the network traffic or it does not interfere with the vehicle functions in case of failure.
Security The diagnostic content available on-board and to/from TCU data needs to be highly secured to prevent them from unauthorized access Software updates Availability of required infrastructure for supporting over-the-air updates in case software components inside TCU fails.
Cellular bandwidth Ensure optimum usage of cellular bandwidth for the data transmission between diagnostic server and TCU.
Limited hardware resources inside TCU Ensure optimum usage of cellular bandwidth for the data transmission between diagnostic server and TCU.
Conclusion The software components mentioned in this article already exist, and are used in production of various engineering, manufacturing and after-sales service use-cases. Additionally, more and more OEMs are in the process of introducing TCUs as a core component of their vehicle architectures. Fast changing technology trends, evolving customer expectations and a highly competitive marketplace will drive OEMs and TCU suppliers to adopt the stated approach for building diagnostic systems of the future. At KPIT, we have already witnessed such a trend with our technologically advanced customers. KPIT's Diagnostic and Connectivity Platform (K-DCP) is already in production (in Embedded environment) serving use-cases like over-the-air ECU flashing and remote diagnostic.
Future prospects
Embedded vehicle diagnostics has the potential to drive benefits throughout the automotive value chain. At the OEM end of the chain, they can gain hugely through Reduction of costs associated with vehicle recalls, Reduction of No-Trouble-Found (NTF) backed warranty claims, all made possible through advanced and guided diagnostics. The Service dealerships will benefit by improving the Fix-First-Visit ratios, reducing service time and cost through remote/guided diagnostics, achieving higher technician efficiencies and productivity, and last but by no means the least, the Customer (Vehicle owner) will enjoy higher levels of convenience and comfort through the service dealerships new found abilities around preventive/predictive maintenance, resulting in Improved vehicle up-times. With 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, will find more believers, by the day!
So, where are these challenges stemming from?
As today's vehicles become more advanced, they start relying more and more on the electronic and software content, embedded within. As this quantum increases, it adds to the vehicle complexity, thereby impacting the ability to accurately diagnose, troubleshoot and repair the vehicle. Today's service technicians at the dealerships with access to conventional service tools, are constrained by the fact that they have to be near to the vehicle in-order to diagnose and conclude the root cause of the problem. Due to this, it increases service turnaround time, repair costs, and more so, it lowers the customer satisfaction. This Article, features one of the most advanced approaches to Vehicle Diagnostics, and highlights the need thereof, to enable service technicians with Next-generation Diagnostic tools, for a fair-pitched battle between the Man and his Machine.
Abbreviations used in the Article
DLC Data Link Connector, i. e. OBD II
ECU Electronic Control Unit (ISO 14229-1)
ODX Open Diagnostic Data eXchange (ISO 22901)
OTX Open Test Sequence eXchange (ISO 13209)
D-Server APIs Diagnostic Server Application Programming Interface (ISO 22900-3)
D-PDU APIs Protocol Data Unit (ISO 22900-2)
MVCI Modular Vehicle Connector Interface
UDS Unified Diagnostic Services (ISO 14229)
TCU Telematics Control Unit
DID Data Identifier
MQTT Message Queuing Telemetry Transport
INTRODUCTION
Ability to diagnose a vehicle is a very important aspect of the vehicle architecture. The most common approach followed within the automotive industry is to gain access to all the diagnostic data (DTC, measurement values etc.) through the vehicle's OBD-II port. There are tools available in the market (through OEMs or IAM vendors) which help service technicians access the status of the various vehicle subsystems, and in accordance troubleshoot the issues and apply repair procedures. However, the service tool based approach can fix the problem only when technician is physically present at the vehicle site.
As mobility is increasingly becoming a norm across Industries, remote vehicle diagnostics can hardly be labelled an exception. With ever increasing level of electronics and software components incorporation into vehicles, the customer's expectations on reduced down-times and servicing turn-around times, are growing in proportion. On the back of these changing customer dynamics, the Industry is anticipating and envisaging solutions that will enable comprehensive vehicle diagnosis from remote locations.
Today, there are numerous solutions available in the market claiming proficient remote diagnostics using OBD-II dongles. However, the fact remains, that these solutions can only read diagnostic information pertinent to emission norms, thereby limiting their Value-Add to the service technician from a holistic (On & Off-board) diagnostic perspective.
The Embedded diagnostic approach (showcased in this article) leverages ISO Standard specified Infrastructure components (i.e. ODX, OTX) as the foundation, thereby paving the way for a highly data driven architecture The diagnostic infrastructure components inside the vehicle allow seamless communication with the ECU network in a manner similar to how the Service tool functions, thereby enabling all the diagnostic use-cases to be executed from remote locations.
The entire solution comprises of 5 main components. The Telematics Control Unit (TCU), Diagnostic runtime, OTX sequences, ODX data and the Diagnostic server to support diagnostic functions.
The TCU provides the environment and necessary resources for the execution of Diagnostic-Runtime to realize different use-cases like read Data Identifier (DID), vehicle scanning, re-programming etc. Normally TCU runs LINUX as an operating system with varied sizes of RAM/Flash memory and CPU power.
OTX is a domain driven graphical programming language and allows one to create automated diagnostic procedures in a graphical manner. OTX procedures are specified in the standard XML format.
ODX is a XML based standard to define ECU diagnostic data in OEM independent way. It contains all necessary data for the diagnostic communication for example communication parameters, ECU variant relationship, diagnostic services, units of measures, precision, data-types etc. The complexity and size of the ODX data depends on ECU variants and amount of diagnostic services supported by the ECUs
Diagnostic runtime provides infrastructure components for the diagnostic communication over network (CAN, Ethernet etc.). The infrastructure components include, Diagnostic APIs, OTX runtime, D-Server APIs and D-PDU APIs. The Diagnostic APIs provide convenience layer on top of D-Server and OTX Runtime components to provide convenience layer for the engineering, assembly end-of-line and after-sales service diagnostic use-cases. It is a highly customizable component based on the diagnostic requirements.
The OTX Runtime provides environment to execute OTX procedures and derive output as defined. The D-Server APIs defines object oriented application programming interface to provide access to the measurement and adjustment objects and to the diagnostic services. The D-PDU APIs defines application programming interface to abstract communication over diagnostic protocols and description of Modular Vehicle Communication Interface (MVCI) module.
The Diagnostic server hosts the application which implements HMI for the end-user and it also communicates with the TCU for diagnostic information exchange. The communication between diagnostic server and TCU is happens over standard messaging protocols like Message Queuing Telemetry Transport (MQTT) as the data transmission reliability is the highest priority.
Challenges
While the approach mentioned in this article enables next generation diagnostic capabilities, it also invites certain challenges which need to be addressed to make it a viable production candidate. Some of those challenges are as mentioned:
Managing the state of the vehicle For example, On-board diagnostic runtime stack needs to ensure that it does not over-load the network traffic or it does not interfere with the vehicle functions in case of failure.
Security The diagnostic content available on-board and to/from TCU data needs to be highly secured to prevent them from unauthorized access Software updates Availability of required infrastructure for supporting over-the-air updates in case software components inside TCU fails.
Cellular bandwidth Ensure optimum usage of cellular bandwidth for the data transmission between diagnostic server and TCU.
Limited hardware resources inside TCU Ensure optimum usage of cellular bandwidth for the data transmission between diagnostic server and TCU.
Conclusion The software components mentioned in this article already exist, and are used in production of various engineering, manufacturing and after-sales service use-cases. Additionally, more and more OEMs are in the process of introducing TCUs as a core component of their vehicle architectures. Fast changing technology trends, evolving customer expectations and a highly competitive marketplace will drive OEMs and TCU suppliers to adopt the stated approach for building diagnostic systems of the future. At KPIT, we have already witnessed such a trend with our technologically advanced customers. KPIT's Diagnostic and Connectivity Platform (K-DCP) is already in production (in Embedded environment) serving use-cases like over-the-air ECU flashing and remote diagnostic.
Future prospects
Embedded vehicle diagnostics has the potential to drive benefits throughout the automotive value chain. At the OEM end of the chain, they can gain hugely through Reduction of costs associated with vehicle recalls, Reduction of No-Trouble-Found (NTF) backed warranty claims, all made possible through advanced and guided diagnostics. The Service dealerships will benefit by improving the Fix-First-Visit ratios, reducing service time and cost through remote/guided diagnostics, achieving higher technician efficiencies and productivity, and last but by no means the least, the Customer (Vehicle owner) will enjoy higher levels of convenience and comfort through the service dealerships new found abilities around preventive/predictive maintenance, resulting in Improved vehicle up-times. With 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, will find more believers, by the day!
