Diagnostics in the Driving Seat

Vehicles are increasingly connecting themselves with their environment: with other vehicles, parts of the infrastructure, the cloud. And this is in fact the key to new functions such as autonomous driving. Together with the increasing electrification of vehicles, this is placing even more demands on diagnostics – but at the same time is also presenting completely new opportunities.

It is no secret that the car industry is facing a radical shake-up. Every manufacturer is working flat out to make electrically driven vehicles which autonomously get their passengers from A to B and – in the case of commercial vehicles – spontaneously pick up other passengers along the way. The terms “driver” and “combustion engine” are no longer part of this vision; what is essential for passenger logistics and autonomous driving is the communication with other vehicles, the surrounding infrastructure and the cloud. This scenario makes much higher demands on the availability and reliability of internal vehicle systems as well as on their ability to connect with the environment as was the case to date.

On the road to new diagnostic functions In many ways these scenarios have a major influence on the subject of vehicle diagnostics – in all phases of the life cycle. Today, diagnostics is used in Engineering to validate ECU functions and in Manufacturing to check the correct (partial) installation of components at the right point of the production line. Even repairing a vehicle – today a network of up to 120 microcomputers – is no longer possible without diagnostics. Here, an error is first localized using diagnostics and, ultimately, the correct repair is confirmed with the identical system. Error detection always takes place in two phases: First of all the ECUs continuously check their environment of sensors, actuators and other ECUs for errors (on-board diagnostics) and store any irregularities detected (fault memory). An external expert system, mostly on a PC basis, can then, if necessary, access these entries in the fault memory via the OBD jack and – also by linking several entries – give tips on the cause of a particular error and how to repair it. The ECUs are accessed using standardized protocols, the parameterization of the expert systems using standardized description formats such as ODX (Open Diagnostic Data Exchange) and OTX (Open Test Sequence Exchange). The description formats are subject to a well-defined creation and release process and contain both diagnostic descriptions as well as all information necessary for the flash programming of the ECUs.

Current developments are making it necessary to run diagnostics on completely new vehicle systems. One very obvious example is the battery unit together with its charging system. The central energy store for all driving, comfort and safety systems plays a central role in terms of its availability, which Extending vehicle functions into the cloud will also make additional diagnostics necessary. The cloud is effectively an independent ECU and has to be monitored with its own diagnostics – including the underlying connections. This concerns systems which the vehicle manufacturer cannot control or verify in each possible status during a trip.

Future areas of implementation

It is precisely the opening up of vehicles in the cloud which, on the other hand, makes numerous new functionalities possible on the basis of diagnostics. The most important are:

  • Vehicle ECG: Permanent diagnostics is run at defined intervals with lots of vehicles. The results are available for later evaluation.
  • Flash programming (SOTA – Software over the Air): The vehicle software is updated over the air interface without the vehicle actually having to be taken to the repair shop.

In today’s ECUs, the error status can usually only be queried when it is read out: effectively a snapshot. is permanently monitored with on-board diagnostics, and the status of which also has to be reported simultaneously to consuming systems as well as the driver. New chemical and physical processes are the subject of diagnostics; other users access the results. While today’s expert systems are used in every repair shop – which means we are immediately talking about several tens of thousands of testers – repairs to batteries probably only take place in a few specialist workshops due to the necessary expertise as well as the ability to adhere to stringent safety regulations. This naturally has an effect on the cost/effect ratio of the diagnostic sequences to be created.

If, however, data is stored permanently, new evaluation possibilities arise over time. This means you can follow the development of an error. When surveying a larger number of vehicles, general statements can actually be made about specific parts. This results in a large number of new areas of implementation particularly in Engineering and After-Sales Service. For example, in Engineering diagnostics can be carried out from the very beginning from the test board through the test bench to the road test, enabling much more precise statements both about downtime probability and parts fatigue. In After-Sales Service, cloud diagnostics enables the implementation of mechanisms for predictive maintenance, via which particularly fleet operators can be informed in advance of problems which are likely to occur. The relevant repairs can thus be timed so that the downtime of the vehicle is minimized. If it proves difficult to localize a problem that has been reported in a customer vehicle, the sporadic error can be acquired using cloud diagnostics (Figure 2) making analysis much less expensive.

Numerous challenges can also be solved without much ado with the help of flash programming. In Engineering new software versions, which naturally occur on a regular basis there, are quickly and simply transferred to all intended vehicles. This applies equally to test benches and test drives where the update can take place over the lunch break for example. In the case of customer vehicles, the update can basically take place at any time, whenever the driver approves it: The owner does not have to drive to the repair shop; and the repair shop no longer has to reserve masses of time for the service tester.

Diagnostics 4.0 – what is already reality…

The good news: New areas of implementation do not need completely new diagnostic systems; they can usually be varied accordingly. Today’s diagnostic systems usually consist of three parts (Figure 1): a VCI, which secures the real-time-critical services over the integrated protocol mechanisms, middleware and a GUI which visualizes diagnostic access depending on the particular use case. Middleware comprises components which concern communication (ODX engine/ D-Server) and others which run diagnostic sequences (OTX engine/OTX Runtime). By splitting the diagnostic system to suit the particular application case, you can nearly always come up with a suitable complete system while taking the existing infrastructure into consideration. As regards the infrastructure, particularly costs for data transmission, latencies in the system (e.g. for measurement data acquisition) and the required bandwidth (for example with flash programming) have to be taken into account. In cloud applications the GUI is replaced by automated functionality, the middleware tailored accordingly: In application cases with stable transmission technology, e.g. in the repair shop, the middleware can in many cases run in the cloud, at least in part. If ECUs are to be programmed or moving vehicles diagnosed, the middleware usually has to be taken to the vehicle, however. This takes place either on a suitable VCI or directly in the vehicle.

…and how the journey is likely to progress

The mega trends of the automotive industry mean diagnostics is facing new challenges, but at the same time represent new functionalities. These can be introduced gradually with existing diagnostic systems as these can be scaled according to the requirements and the relevant infrastructure. The advantages of the solution depicted are obvious: Established release processes can remain in place, migration scenarios with existing vehicles which will be used in repair shops for decades to come can be represented without any additional effort.

Markus Steffelbauer
heads up Product Management and Marketing at Softing Automotive and is a committed member of standardization bodies.