Vehicle Diagnostics

June 29, 2018
0

How Different are On-board and Off-board Vehicle Diagnostics? A Detailed Analysis of Functions, Scope & Services

Tags : Off-Board Off-Board v/s On-Board Vehicle Diagnostics On-Board Vehicle Diagnostics Vehicle Diagnostics

‘If something can go wrong, it definitely will, states the Murphy’s Law. When we talk about machines, this law which is more of a proverb completely holds true.

So what do we do when a machine goes wrong? We first perform an inspection of the machine to zero in on the problem. Identifying the issue helps us to find the right solution.

This process of inspection or analysis is known as Diagnostics. And this plays a very important role in human beings favorite machine – a Car/Automobile/Vehicle.

How Vehicle Diagnostics Works?

In a car, passenger vehicle or any other automotive, Vehicle Diagnostics is a very elaborate and necessary process. It may also become quite complex at times.

The state of the motion or rest of the car becomes primarily important. Also, the diagnostics parameters change when the vehicle is moving and when it is at rest in a garage. In order to cover both these scenarios, off-board and on-board vehicle diagnostics have been introduced.

The typical vehicle diagnostics feature checks the state of functions performed by the subsystems, sensors and other such components. The errors reported by all these components are recorded in the error memory in the form of DTCs (Diagnostic Trouble Codes).

While on-board vehicle diagnostics protocols like OBD/OBD2 are tasked primarily with emission related diagnosis, off-board vehicle diagnostics (UDS, KWP etc.) handle the diagnostics related to every other vehicle ECU (Electronic Control Unit).

Off-Board v/s On-Board Vehicle Diagnostic

What’s the Functional Scope of On-board Diagnostics System

On-board vehicle diagnostics (OBD2) comes into the picture when the vehicle is moving. The tests are being conducted while the vehicle is on the road. The test results can be seen on the vehicle’s dashboard in the form of MIL (Malfunction indicator light) or an OBD tester tool. The data that the OBD makes accessible is related to:

Emission Control System
Engine and Transmission ECUs (powertrain)

OBD2 was mandatory for all the cars that were manufactured in the USA after the year 1996. This was essentially done to keep the emissions level of the vehicles in check.

Every parameter related to the vehicle emission such as info from oxygen sensors and the fuel injectors etc. is checked. In case of any malfunction, an MIL (malfunction indicator light) is triggered to warn the vehicle owner.

Additionally, a limp home mode may be activated in some high-end cars. This mode activates an algorithm to let you drive home or to the service garage without causing more damage to the vehicle.

The error that triggers the MIL is also stored in the automotive ECU which can later be retrieved by the tester tool at the garage. This error code helps the technicians to pin-point the emission issue and rectify it.

In order to request the data from the vehicle ECU, Parameter IDs (PIDs) are sent to the automotive ECU using the tester tool. Hundreds of PIDs have been specified by SAE J1979 and a few by specific automotive OEMs.

The technician sends the PIDs and gets the response corresponding to that PID. The technician can then zero in on the specific issue that is causing the trouble.

These tester tools perform generic tests that are similar for most vehicles. In some countries, the police is also equipped with such testers that can be used to detect the emission related data of the vehicle. Any breach of standards set by EURO (Europe) and CARB (USA) are liable for penalty.

What needs to be noted here is that on-board diagnostics has services that are not specific to a particular vehicle or variant (except the ones specified by the OEM). In contrast, the off-board diagnostics protocol like UDS may be vehicle specific. We will discuss this further, when we talk in-depth about the off-board vehicle diagnostics

Food for thought: The electric vehicles also have OBD2 diagnostics integrated to the system, despite the fact that there is no emission. This is because the USA mandates the inclusion of OBD2 into every car. However, the OBD2 port doesn’t give any interesting data when a diagnostic tester tool is plugged-in.

More About On-board Vehicle Diagnostics: Services Categorization and their Functions

The services provided by OBD2 are categorized under nodes. Services here refer to the functions of the OBD2 software stack.

Every node has some Parameter identifiers as per the standards set by SAE J1979. The automotive OEMs can also configure some vehicle specific PIDs.

The function of each OBD2 node has been described here in brief.

Mode $01 – Request Live Data from the powertrain that is available to the tester tool.

Mode $02 – Request Freeze Frames i.e. the vehicle data captured when the issue occurred.

Mode $03 – Request Stored Trouble Codes; displays the exact 4 digit code to help identify the fault

Mode $04 – Clear/Reset Stored Emissions Related Data

Mode $05 – Request Oxygen Sensors Test Results

Mode $06 – Request On-Board System Tests Results from exhaust gas sensors, catalyst monitor, fuel system monitor and others; an advanced mode that can be accessed only by professional grade tester tool

Mode $07 – Request Pending Trouble Codes captured during the current or last driving instance.

Mode $08 – Request Control of On-Board Systems by an off-board diagnostics system

Mode $09 – Request Vehicle Information like vehicle identification number, calibration identification etc.

Mode $0A – Request Permanent Trouble Codes. Any code that turns the malfunction indicator light and is stored in a non-volatile memory must be logged as a permanent trouble code.

Exploring the Scope of Off-board Diagnostics in the Vehicle

Off-board vehicle diagnostics takes care of the diagnostics of every other vehicle ECU function other than emission. There are several protocol standards defined for off-board diagnostics, however, Unified Diagnostics Services (UDS) is the most popular diagnostic protocol.

P.S: We would use UDS and off-board diagnostics interchangeably for the convenience of reading and better understanding.

The diagnostics managerof the UDS protocol stores every issue as fault codes called Diagnostics Trouble Code (DTC). When a vehicle is running, the off-board diagnostics is also active. However, the contrast with on-board diagnostics lies in the reporting part.

In case of OBD, the fault is communicated to the information cluster by triggering the Malfunction indicator light. Whereas, in the off-board diagnostics, no such instant reporting is carried out. The issue is stored in the EEPROM part of the vehicle ECU for retrieval at the service garage using a vehicle diagnostic testing tool.

However, the scope of off-board diagnostics (UDS) is not limited to just storing the diagnostic trouble codes (DTCs). It is capable of offering services such as vehicle ECU reprogramming, remote routine activation, writing data on the automotive Electronic Control Unit and even more.

Detailed explanation of some of these services can be found here.

We also mentioned about the vehicle-specific aspect of the UDS protocol earlier in the blog. This is one of the major aspects that differentiates on-board and off-board vehicle diagnostics.

When the UDS stack is integrated to the vehicle ECU, the UDS services are configured to it. These configurations are mostly OEM-specific. It means that a tester tool authorized by the same automotive OEM can only read or write data from the vehicle ECU. Unlike the OBD 2, any after-market tester tool will not work.

A Comprehensive List of Off-board Diagnostics (UDS) Services

As UDS has been accepted by many automotive OEMs as the de facto Off-board diagnostics, its services are very important. We have compiled them here:

SID	UDS Services	Description
0x10	Diagnostic Session Control	Enable various diagnostics sessions within ECU
0x11	ECU Reset	Resetting the ECU to be back in the default session
0x27	Security Access	Limit access to data and services to prevent unauthorized access
0x3E	Tester Present	Alert the ECU(s) that client is still connected so that diagnostic sessions remain active.
0x22	Read Data By Identifier	Request data from ECU(s)
0x2E	Write Data By Identifier	Write data onto ECU(s)
0x14	Clear Diagnostic Information	Clear diagnostic trouble codes (DTC) stored in the ECU
0x19	Read DTC Information	Read DTC from the ECU
0x2F	Input Output Control By Identifier	Control the input/output signals through the diagnostic interface
0x31	Routine Control	Control all the routine services (erasing memory, testing routines etc.)
0x34	Request Download	Request ECU to initiate download session based on request from the tester
0x36	Transfer Data	Manage actual transmission ( upload and download) of data
0x37	Request Transfer Exit	Terminate and exit data transfer
0x28	Communication Control	Manage the exchange of messages in the ECUs
0x85	Control DTC Setting	Enable/disable updating of DTC settings in ECU
0x87	Link Control	Control the ECU- client (tester) communication to gain bus bandwidth for diagnostic purposes.
0x23	Read Memory By Address	Read memory data from the memory address provided
0x24	Read Scaling Data By Identifier	Read scaling data stored in the server using data identifier.
0x3D	Write Memory By Address	Write information into the server memory location
0x35	Request Upload	Request ECU to upload data

On-board vs Off-board Vehicle Diagnostics: A Quick Comparison

We hope the scope and services of both on-board and off-board vehicle diagnostics should be clear by now. Emission being a very crucial aspect of a vehicle, on-board diagnostics is completely dedicated to it. The strict CARB and EURO emission guidelines call for real-time monitoring of emission related parameters. The Malfunction Indicator light is also associated with the on-board diagnostics, implying the urgency an emission related issue requires.

The off-board vehicle diagnostics, on the other hand, may not require enough urgency to light up an MIL. However, it has many other roles to play. Its comprehensive set of services help the garage personnel perform tests, run routines, update the ECU, write data and much more.

The crux of the story is that both on-board and off-board systems perform diagnostics and have their scope clearly demarcated by their services. While one takes care of the emission the other handles everything other than that.

May 7, 2018
0

Decoding the Implementation of UDS Vehicle Diagnostics in AUTOSAR Base Software Module

Tags : AUTOSAR Base Software Module AUTOSAR Software AUTOSAR software Architecture UDS vehicle diagnostics Vehicle Diagnostics

Category : Embedded Blog

For all the automotive technology enthusiasts, AUTOSAR needs no introduction. The AUTOSAR consortium was formed by the automotive OEMs to counter the complexities created due to increase in the use of ECUs (Electronic Control Units) in the automobiles.

This AUTOSAR software Architecture ensured the decoupling of product functionalities from the hardware and software services.

This standardization has helped the automotive embedded developers in focusing primarily on the innovations in the product feature development rather than working on different architectures.

This shift in automotive ECU development approach has proved to be equally beneficial for the automotive OEMs and their Tier-1 suppliers. Why, you ask? Post-AUTOSAR, OEMs’ and Tier-I Suppliers have been able to save costs spent on different software development tools required in era of non-standard architecture.

AUTOSAR software architecture has brought about a standardization that the OEMs and suppliers follow to develop software without facing any compatibility issues.

When Vehicle Diagnostics Met AUTOSAR Software Architecture

In automotive, diagnostics is required to be performed on all ECUs to ensure there is no issue with any electronically controlled component of the vehicle. Any issue encountered by the automotive ECU is stored as Diagnostics Trouble Code (DTC) in the Electrically Erasable Programmable Read-Only Memory (EEPROM). These codes can be retrieved later using an automotive diagnostic tool.

Now the vehicle diagnostics system needs to be implemented in the AUTOSAR architecture and this is what this blog aims to explore.

To understand how the diagnostics is implemented in AUTOSAR architecture, let us quickly revisit the architecture.

In the base software layer, there are hundreds of software modules including those categorized under the Microcontroller Abstraction Layer (MCAL), ECU Abstraction Layers and Service layer.

The blog will focus on the service layer of the AUTOSAR Base Software Module as the vehicle diagnostics services are stored here.

There are essentially three modules inside this layer tasked with different responsibility with respect to vehicle diagnostics. We will discuss them in the subsequent sections.

In the diagram below, the different components of the diagnostic stack(DCM, DEM, FIM etc.) can be seen.

Source: Mathworks

Diagnostics Communication Manager (DCM)
The diagnostic communication manager (DCM) has the responsibility of reading and writing the fault codes or diagnostic trouble code in the fault memory of the automotive ECU. It supports the implementation of the diagnostic protocols such as UDS (ISO 14229) and OBD II.

When an automotive ECU receives a diagnostics request from the tester tool, the DCM preprocesses it. While it handles majority of the requests, any other request is routed to the functional software. Every new version of DCM has an enhanced functional range which increases its ability to handle diverse types of diagnostic requests

DCM comprises of the service identifiers (SID), data identifiers (DID) sub-functions and routine identifiers to handle the vehicle diagnostics requests.

While handling the diagnostics requests from external testing tools during ECU software development, vehicle program production or garage servicing, the DCM also manages the session and security states.

For instance, the DCM checks whether a particular diagnostic request can be supported and also if the execution of that service will be carried out in the current session.

We will delve little deeper into the different components of DCM and how they interact with each other.

Diagnostic Session Layer: This sub-module is tasked with ensuring the flow of data related to the diagnostic requests and the responses. Diagnostic session and security states are managed by this layer along with the supervision of timing parameters of the diagnostic protocol.

Diagnostic Service Dispatcher: The validity of the incoming diagnostic requests needs to be checked and this is where this sub-module comes into the picture. In addition to ensuring the validity of the request, it also keeps track of the progress of the request.

After the validation is done, this sub-module processes a stream of diagnostic data and also transmits the response post data processing.

Diagnostic Service Processing (DSP) Module: This is the place where the real processing happens. DSP analyzes the format of the service request and interacts with other components of the AUTOSAR BSW to fetch the data required for the processing. The service response is also assembled by it.

These three sub-modules interact with each other with the help of defined interfaces. Describing these interfaces is beyond the scope of the blog and we will discuss them in detail in the subsequent blogs.

In order to make the automotive ECU an AUTOSAR compliant product, DCM needs to be first configured using tools like Vector Tool Chain. During the development process, all the necessary APIs are coded in the DCM including the general DCM definitions.

Unit testing and integration testing follows the development process. Unit testing is performed using tools like Tessy Test Systems where the source module is analyzed and the functions are tested.

Integration test is performed on the evaluation board where the data exchanged between the modules is verified. Basically, it tests if all the interfaces are functioning without any issue.
Diagnostics Event Manager (DEM)
DEM is responsible for storing and processing diagnostic errors (events) and all the data associated with it. In addition to it, DEM provides the diagnostic trouble codes (DTC) to the Diagnostic Communication Manager (DCM) as and when required.

Providing the interface to the application layer of the ECU and to other modules of the AUTOSAR Base Software Module is also one of the responsibilities of DEM.

There can be two type of event that can be reported to DEM:
- Base Software Event- Event reported by the base software
- Software Component Event reported by the AUTOSAR application layer
The events reported to the DEM need to be first qualified to ensure that whether it is a fault (failure of a component) or just an occurrence (irregular system behavior).

After the event is qualified, DEM records the event data and communicates with DCM for event handling and FIM (Function Inhibition Module) for functional control (Described in next section).
Function Inhibition Module (FIM):
FIM is essentially the control mechanism for AUTOSAR Base Software and software components. The FIM has to control the functionality available to these components depending on their inhibit conditions.

An identifier is assigned to the functionalities with an inhibit condition. Only in the scenario of inhibit condition being not true, the functionality is executed.

The role of FIM is to configure and modify the inhibiting conditions of the functionalities. By doing so, a particular functionality can be adapted easily to a new system context.

FIM services are primarily focused on the applications residing in the software components; however, the AUTOSAR Base Software (BSW) can also use the services of FIM when required.

The FIM has a close connection with DEM as the diagnostic events and their status info are considered as inhibit function by the FIM. When a failure is detected, it is reported to the DEM and it is the job of FIM to stop the particular functionality.

Conclusion

The implementation of UDS in the Base Software of AUTOSAR architecture requires two states of designing and highly complex coding during the configuration.

Moreover, the configuration of the Diagnostic Communication Manager (DCM) needs to be done with respect to certain parameters defined by AUTOSAR. This is where AUTOSAR Tool Chains become very important.

These platforms help the developers’ auto-generate certain code and write the rest. Configuration of the parameters also becomes quite easy with the tool chain programs like Electrobit, Vector Tool Chain and a few others.

March 20, 2018
0

KWP 2000 and UDS Protocols for Vehicle Diagnostics: An Analysis and Comparison

Tags : KWP 2000 KWP2000 & UDS Difference KWP2000 and UDS KWP2000 vs UDS UDS Protocols Vehicle Diagnostics

Category : Embedded Blog

Vehicle diagnostics as a process has undergone numerous transformations over the past 2 decades. The demand for a more accurate, standard and efficient fault detection in vehicle diagnostics, has led to breakthrough innovations and developments.

Evolution of Vehicle Diagnostics:

Earlier, there were flash codes wherein technicians had to look for flashes and convert them to codes or sometimes the technician had to physically remove vehicle components, disconnect wires for fault detection.

The increasing complexity of vehicle systems over the time mandated the need for diagnostics standards to efficiently track their scope and relevance.

To cater to this need of the hour, various vehicle diagnostic protocols were conceptualized and developed.

ISO and SAE (Society of Automotive Engineers) introduced various diagnostic protocols and standards, designed to cater to the different types of automotive ECU systems and diagnostics specifications from the vehicle manufacturers.

OBD II (On-Board Diagnostics), K-Line per ISO 9141-2, KWP 2000 (Keyword Protocol 2000), UDS (Unified Diagnostic Services) are some of the vehicle diagnostic protocols designed and deployed during the evolution in off-board and on-board vehicle diagnostics.

Image credit: nextews.com & brezan.nl)

Although a large number diagnostics protocols and systems were developed and used within the automotive industry, many of them have become obsolete due to the rapid “Electronification “of the automotive ECU (control units).

As of now, Keyword Protocol 2000 (KWP 2000) and Unified Diagnostic Services (UDS) remain one of the most widely used vehicle diagnostics protocols. Let us have a look at two protocols in detail:

KWP 2000:

KWP2000 or the Keyword Protocol 2000 is an on-board diagnosis (OBD) protocol complaint with ISO 14230 standard.

It defines a common set of communication codes, for exchange of data, used by vehicle ECUs as per the guidelines the OBDII regulatory standard. KWP 2000 is compatible with both K-Line (ISO 9141) and CAN (ISO 11898) in-vehicle networking systems.

The KWP 2000 protocol uses a physical layer, identical to ISO 9141-2, for bidirectional serial communication over K-line with the controller. The protocol also uses L-Line (optional) unidirectional communication, to wake up the automotive ECU.

The average data rate of KWP 2000 is between 1.2 and 10.4 kilo baud, and the data fields within the message may contain up to 255 bytes.

UDS protocol – Unified Diagnostics Service:

The Unified Diagnostics Services protocol (ISO 14229) is an off-board diagnostic system. It is designed in compliance with ISO 14230-3 (KWP2000) and ISO 15765-3 (Diagnostic Communication over Controller Area Network (DoCAN)) standards.

The maximum size of message supported within UDS is up to 8 bytes. For exchanging messages exceeding 8-bytes, the UDS protocol uses ISO 15765-2 layer, an international standard for transfer of data packets over a CANBus. UDS diagnostic implementation is independent of the underlying physical layer and is also compatible over both LIN and CAN in-vehicle networks.

UDS as a diagnostic protocol was developed to unify all the diagnostics standards that existed previously and to come up with a single valid set of diagnostic services for the automotive ECUs.

This has ensured that integration of the UDS protocol stack reduces the additional costs for the development of diagnostic communication applications.

Comparison Between KWP 2000 and UDS Protocol:

While, UDS protocol can be seen as a superset of the KWP 2000, since it is derived from the latter, a comparison of both as the diagnostic protocols gives out some interesting facts:

Support for in-vehicle communication networks: The KWP 2000 protocol supports CAN and K-line bus systems . The UDS protocol is designed to be independent of the underlying vehicle network as it supports a range of bus systems including CAN, CAN -FD, LIN, etc.
KWP 2000 is highly preferred where the vehicles are based on legacy systems such as K-line. Otherwise, these days UDS protocol is the go to standard for vehicle diagnostics.

Transfer of Key Measurement Values: Both the diagnostic protocol facilitate exchange of request and command messages from the test equipment to the automotive ECU; and key measurement values (data) in response from the vehicle ECU.
But, there is a key difference between the two protocols in the way these measurement values are exchanged between the tester and ECU:

UDS uses the 2-byte dataIdentifiers (DID), whereas the KWP uses a 1-byte recordLocalIdentifier and 2-byte commonIdentifier.
The advantage of the UDS protocol is that the tester can request several measurement values with one UDS service request using its 2 bytes ( 16 bits) long data identifiers as compared to the 1-byte ( 8 bits) Local identifier used by KWP 2000 standard. This means increased efficiency of data exchange.

Diagnostic Communication between Test equipment and vehicle ECU: The exchange of messages between testing device and the vehicle ECU forms the basis of the diagnostic system.
The natures of request and response messages and data transfer interval between them form an important factor in vehicle diagnostics.
KWP2000 favors symmetrical communication sequence where the number of request and response messages between the testing device and server are symmetrical.

On the other hand, UDS is based on an event driven and periodic communication sequence. This means, the number of request and response messages can be different.
Moreover, in a periodic communication sequence based on UDS standard, the test equipment sends periodic requests for updated information from automotive ECUs. This helps in closely monitoring vehicle condition in regular intervals. The vehicle ECU may respond to the periodic request with one or several data record values.

This also helps in identifying any deviation from the threshold/ideal values associated with crucial vehicle functions such as airbag deployment , engine fuel injection, engine speed and heating etc.
Thus UDS offers more detailed information related to the fault through periodic update.

Error Memory Management: While the KWP 2000 provides 4 services for error memory management, the UDS protocol specifies just two services.
KWP 2000 uses following services for error memory management:

$14 (clearDiagnosticInformation),
$18 (readDTCByStatus),
$17 (readStatusOfDTC), and
$12 (readFreezeFrameData).

While, UDS uses only the

$14 (clearDiagnosticInformation) and
$19 (readDTCInformation)

With the help of the readDTCInformation service in the UDS protocol , the testing device can not only read diagnostic related DTC data, but it can also read additional parameters of the component ( say engine) at the time of the occurrence of fault. This helps in pinpointing the root cause of fault/damage and then undertaking the right repair and maintenance operations.

Read DTC Subfunctions: The KWP2000 protocol specifies 3 function for the Read DTC ( Read DiagnosticTroubleCodes) service . On the contrary, the UDS protocol specifies 21 sub functions for the Read DTC service.
With the help of the additional sub functions, UDS enables the tester to collect more diagnostic information. This is useful in the modern automotive industry where the complexity of design and number of components in the vehicle are increasing.

KWP and UDS- A Quick Comparison:

Parameters	KWP2000	UDS
ISO Standard Compliance	Is based on ISO 14230	Is based on ISO 14229-1 and is derived from ISO 14230-3 (KWP2000) and ISO 15765-3.
Protocol Dependency	KWP 2000 functionalities for measurement value transfer and error memory management were improved for UDS standards.	It is an extended version of KWP2000 on CAN (specified under ISO 15765-2) and many other previous diagnostic standards.
Tester-ECU Communication:	Supports a symmetrical number of requests and response between the tester and the ECU(s).	Is based on event-driven and periodic services. Hence number of requests and response between the tester and the ECU can vary.
Transfer of measurement values:	Involves a 1-byte “record Local Identifer” and another 2-byte “Common Identifer”	Involves 2-byte data identifier and allows higher number of IDS to be exchanged.
Error Memory Management:	Specifies four services for the error memory management: $14 (clearDiagnosticInformation), $18 (readDTCByStatus), $17 (readStatusOfDTC), and $12 (readFreezeFrameData).	Specifies two services for error memory management: $14 (clearDiagnosticInformation) and $19 (readDTCInformation)
Read DTC Functions	KWP2000 specifies 3 subfunctions under the ReadDTC service	UDS specifies 21 sub functions under the ReadDTC service
Vehicle Network Supported	Runs on several transport layers such as K-line (serial) or CAN.	It is independent of the vehicle bus systems. Runs on CAN, LIN, and Ethernet on transport protocol.
ECU Identification	Contains a specific function to identify the ECUs – Read ECUIdentification	Doesn’t include a separate service to identify the ECU, rather this functionality is included within the Read databyidentifier.

Reference: Road Vehicles: Diagnostic Communication : Technology and Applications- By Christoph Marscholik, Peter Subke

KWP 2000 and UDS are both used in modern automobiles for efficient and accurate diagnosis of vehicle health and faults. Over the time, UDS protocol owing to its robustness and a broader service spectrum is expected to be the future of automobile diagnostics.

UDS protocol is defined by redundancy of functionalities whereby various UDS services can be used to execute a certain diagnostic function. For example, both SIDs 0x36 (TransferData) and 0x3D ( writeMemoryByAddress) are effective for flash memory programming. Similarly, any of the 0x2E (writeDataByIdentifier) and 0x3D (writeMemoryByAddress) can be used for data manipulation within ECU.

Thus, UDS as a diagnostic protocol paves way for added services and functionalities. But it also calls for additional requirement for ECU memory along with extra development costs. Thus it is important to ponder over certain questions, before deciding on the implementation of UDS services for your application, listed as:

What services are necessary for you?

What sub functions and parameters are important to be considered for UDS implementations?

What data identifier and parameters should be focused on?

If you take these questions into account, you will be able to successfully implement UDS within your automotive application without any unnecessary development costs or efforts. Talk to our Automotive experts to know how you can seamlessly implement and integrate UDS software stack according to your automotive use-case.

May 3, 2016
0

What are the Trends and Challenges of Telematics Remote Vehicle Diagnostics

Tags : Automotive Telematics Remote Vehicle Diagnostics Vehicle Diagnostics

Category : automotive-insights

Telematics Wire, a media and market research firm in the domain of Vehicle Telematics, recently interviewed Aneesh Adkadkam, Head Automotive (Product Engineering Services), Embitel Technologies.

In this conversation, Aneesh shared details about the trends and challenges faced by Telematics and Remote Vehicle Diagnostics market.

Following are the details of this conversation:

How the use of Telematics & Connectivity is continuously changing the way we manage our vehicles?

One of the key challenges for an OEM to provide aftermarket support is the limited access they have to the vehicle. Any remote diagnostics or preventive vehicle maintenance is possible only when the vehicle is taken to the service station for a scheduled service or repair.

The error/fault code memory in electronic control units (ECU) helps to certain extent only when the vehicle is in service station, but the whole vehicle diagnosis and maintenance is constrained with lack access to vehicle parameters, limited expertise available in the service station and lack of knowledge of how the vehicle is used (driver behavior).

This is where automotive telematics and connectivity helps. An OEM is able to get real-time access to the vehicle.

This helps the OEM to drastically improve the aftermarket vehicle diagnosis and maintenance by providing alerts on potential problem, tips to correct wrong driver behavior, to improve mileage based on the usage pattern and remote support in case of on-road breakdown

What makes telematics-driven vehicle diagnostics useful for a cost-sensitive market like India?

The incremental cost of providing remote diagnostics is not huge. BOM cost of the device will be less than $50. There is an additional cost of setting up cloud-based IT infrastructure and services; however OEMs already have similar infrastructures that connect multiple service stations in place.

The preventive vehicle diagnostics and remote support will also reduce the cost of maintenance of the vehicle.

This particularly helps commercial vehicles market where the opportunity cost of a vehicle under service/repair is huge. In addition there is advantage of getting access to lot of data which can be monetized and this can reduce the overall cost.

Traditionally, Indian fleet managers have been using telematics in its very basic form (track and trace). Do you anticipate a widespread adoption of telematics services by them in future?

Traditional automotive telematics is limited to access to vehicle location information and few other parameters like vehicle speed, engine data.

Connected Car technology helps in accessing a whole gamut of data.

This helps in fleet-management by reducing the cost of operations through preventive vehicle maintenance, remote vehicle diagnosis and support from OEM service team, reduction in fuel consumption, analyzing and correcting driver behavior

These cost advantages should trigger wide-spread adoption of telematics driven remote vehicle diagnostics.

What are the various metrics that are crucial for OEMs (or fleet managers) under remote diagnostic services?

For the OEM, the key parameter is to improve the customer satisfaction through better aftermarket support. The challenge is to make this available at low or no additional cost.

Advantage for the OEM is access to real time data which can be used for improving the product reliability.

Once the vehicle is on-road every vehicle acts as a test vehicle – any vehicle can be monitored for any parameter. This can help in product planning and design, improving the vehicle performance and reliability.

In addition the data can be used for other commercial purposes like targeted sales and marketing, customized insurance plans

Could you share with us details of any recent Telematics or Connected Vehicle project/pilot done with OEMs in India?

Embitel has delivered multiple projects in this area. We have readily available reference design, which can be customized for remote diagnostics implementation and help in reducing the time-to-market.

The reference design includes device (VCI- Vehicle Communication Interface) to access vehicle parameters and DTCs (diagnostic trouble codes), connectivity over 3G/4G and Blutooth, GPS and cloud connected apps (Iphone and Android)

When it comes to vehicle preventive maintenance, what is the value-addition that Embitel offers to the customers?

Our value proposition is our expertise across the entire value-chain of remote vehicle diagnostics from getting the data from the vehicle, making the data available to the cloud servers and application programming.

Embitel has extensive experience working with various control units like engine control units (ECU), body control units, ADAS, Chassis systems and this gives us a good domain knowledge on making these data available for remote diagnostics application.

We have worked on all the major technologies in vehicle networking and diagnostics like CAN, OBD, KWP2000, UDS, J1939 .This along with expertise on embedded technologies like GPS, 3G/4G module integration, Bluetooth, Wi-Fi, etc. helps us in providing connectivity solutions.

We also have a strong team working on cloud and mobile technologies, which creates webapps and smartphone apps for both business and consumers.

Globally, there has been a buzz around “autonomous vehicles” . What is your take on this?

Health of the vehicle and subsystems will be a key concern in autonomous vehicles. This will call for real time monitoring of the vehicles for any safety issues and makes remote diagnostics mandatory for such vehicles.

When do you think telematics features would become “must-have” in new vehicles, rather than a nice-to-have feature?

It is NOW, as already some OEMs started offering connectivity solution and using this as a marketing tool especially in passenger car segment. OEMs are already working on various platforms to offer this and partial adoption is likely to happen quickly. Key challenges will be connectivity issues, legal aspects, privacy concerns and cyber security.

Happy to Help!

This website doesn't store cookies. Enjoy the experience, without worrying about your data!

Great, thanks!