Vehicle diagnostics architecture that enables vehicle services to move out of workshops

Vehicle services are moving out of workshops and garages and are becoming mobile. This instance first began in 1990 with the launch of GPS-based navigation systems that automatically selected the route for the driver depending on information received about traffic conditions. This process will now continue with the eCall-System, stipulated for new vehicles from 2018 onwards. It will automatically place an emergency call using the present GPS position in the event of an accident.

The performance and complexity of electronic functions are constantly increasing because of autonomous driving, drive-by-wire, and entertainment. According to current estimates, 90% of the innovations in the automotive sector are taking place in automotive electronics and software. The direct consequence of this trend is that these electronic functions need to be analysed, diagnosed, and then maintained and improved in the field. For future technologies, such as autonomous driving, it is absolutely necessary to monitor the algorithms in the field on one hand, and on the other, to incorporate the findings into the cars without having to take the car to the workshop. If several series of vehicles are simultaneously affected by software updates, as in the case of an exhaust issue by a German automaker, then field measures carried out by authorised workshops are expensive and take up a lot of time.

Figure 1: Standardised architecture of the diagnostic system with remote interfaces

Considering the standardised architecture of diagnostic systems used nowadays, the interfaces are as shown in green dashed lines in the figure above: (1) CAN-Bus; (2) VCI connection to PC via USB, LAN, Wi-Fi, Bluetooth, etc.; (3) the D-PDU API as interface to the tester and (4) the (D) COM interface to the server that is already remote-enabled and the (5) business logic. For further consideration, the VCI has additionally been bifurcated along the line (3) into an upper PC-based part and an embedded part. This internal interface available in the VCIs is functionally described in ISO 22900-2 to enable several VCIs to connect via a common D-PDU API. Based on this, it will be shown how the above discussed issues can actually be resolved, without affecting the timing requirements of the overall system.

Data Link Layer

If you separate at the data link layer, in this case the RAW CAN in accordance with ISO 11898 1, then you can receive short messages of up to 8 bytes in length. The resulting time requirements are high, which happens in case of consecutive frames. There are already several solutions for this in the market that are available as “CAN over Bluetooth” or “CAN over IP”. These solutions are characterised by the fact that individual CAN frames can be packed directly into the data packets of the remote connection. The application is restricted to local networks due to the latency time and the bandwidth requirements.

Currently, there are several regulatory hurdles slowing down the adoption of innovations, such as self-driving cars, for instance. While traditional players can use the cushion of regulation to buy more time, this may not necessarily be wise. There is the very real risk of lagging behind in advancements and getting commercially overtaken

Network and transportation layers

Both these layers described in ISO 15765-2 can be considered together. Resulting from the fact that the separation is done after the transportation layer, the required bandwidth for the same payload is already reduced by 50 percent.

Figure 1: Standardised architecture of the diagnostic system with remote interfaces

There is an issue here of transmitting segmented messages, which is already familiar in case of gateways. The package timeout P2 starts when the request is sent and ends when the first segmented response frame is received. The ISO 15765-4 (OBD) specifies a P2Timeout= 50 ms.

If the separation is carried out at the interface (2) of the data flow, then meeting at this point becomes a challenge. To send a response to the VCI module as quickly as possible, the “FirstFrame” must be forwarded immediately, so that the P2 timer of the VCI module is triggered. The following frames can then be collected and transported together. Although Electronic Control Units (ECU) nowadays need less than 10 ms to generate a response, the remaining response time of 40 ms also represents a requirement that cannot be guaranteed for a remote solution. The consequence is that we need to intervene in the time response of the entire system to ensure that the communication is stable.

Application layer within the D-PDU API

Therefore, a separation above the VCI modules, which are responsible for the network and datalink timings, makes more sense. The D-PDU is divided into a PC part, which itself contains the C-API interface and an embedded part for protocol handling on the VCI. There exists only a few application timings above the VCI modules, such as Tester Present, which are in the range of seconds and hence easy to fulfil. Since only the pure payload is transported in the form of PDUs, the protocol overhead is eliminated completely. In addition, metadata such as protocol parameters and the status of individual objects are also required to be transported, but this can be easily achieved.

The concept described here replaces the previous VCI connection via proprietary interfaces through a standard Ethernet connection within the D-PDU API. Such a solution with the VCI “TC XS” from ACTIA I+ME is already being used successfully in development, production, and especially in after sales in large German OEMs. With an appropriate connection management, it will be possible to operate several VCIs at different locations from only one diagnostic tester to a pair of testers, and VCIs in various combinations using the Ethernet interface.

Diagnostic services, which are not time critical, such as reading fault memory or measurement values and carrying out coding’s of ECUs do not pose any problem, even if the diagnostic tester and the VCI are separated by several 100 kms. Remote Flashing is also possible with UDS using the latest ECU as already shown by prototypes. This approach is suitable for implementing Software as a Service (SaaS) running in the cloud.

The above architecture has proven to be excellent in practice, because the amount of data to be sent via the remote connection is minimal since the protocol overhead is missing and the timings can be guaranteed.

Presentation layer (D-PDU API interface)

Since PDUs are also transmitted here, this solution is technically quite similar to the previous solution. The standard solution do not specify any method for serialisation of calls and return values of the C interface of the D-PDU API, which means that also only proprietary solutions are available, which practically coincide with solution 3.

Application layer (D-Server API)

All the interfaces above the D-PDU API require that the diagnostic data (ODX and OTX) are locally available. This data can be very extensive and thus cannot be sent via a commonly available remote interface in the field if necessary. The requirements on the underlying (embedded) system also increase significantly since the data is stored and locally interpreted in the diagnostic runtime system. This also completely covers all the diagnostic use cases including Flash programming and replacement of the controller.

Application layer (D-Server API)

All the interfaces above the D-PDU API require that the diagnostic data (ODX and OTX) are locally available. This data can be very extensive and thus cannot be sent via a commonly available remote interface in the field if necessary. The requirements on the underlying (embedded) system also increase significantly since the data is stored and locally interpreted in the diagnostic runtime system. This also completely covers all the diagnostic use cases including Flash programming and replacement of the controller.

Figure 1: Standardised architecture of the diagnostic system with remote interfaces

This concept has been successfully implemented together by KPIT and ACTIA I + ME using the controller xNET α (see Figure 3). KPIT’s diagnostic server gets its data from the D-PDU API interface and encodes/decodes these PDUs with the help of ODX and OTX data and makes this functionality available in the D-Server API to the various applications (business logic) on the xNET α. In the process, information is obtained which ultimately determines the expansion stage of the VCIs and the options to be realised. For autonomous Flash processes, it is necessary to store the Flash data including control data (ODX and OTX) on the VCI, i.e., the memory expansion determines the capacity of the Flash process here. The practical challenges are in the area of data security and organising the work packages that need to be processed on the VCI.

To summarise, it has been seen that the above architecture has proven to be excellent in practice and provides high availability and simultaneous coverage of all the use cases. This ensures an optimal point of entry into vehicle remote diagnostics

Business logic and cloud-based diagnostics

The last possible interface is the application itself. It can provide its services to other systems via a remote-enabled interface such as HTTP. The possibilities and requirements mostly correspond to the previous system (5), whereby the wheel had to be reinvented here so far for various specific solutions. Improvements are expected by the end of 2017 here in the new ISO 20078 (Web services).

Conclusion

The various interfaces for mobile diagnostics have their respective strengths and weaknesses, which are reflected especially in the timing and data volume. These remote technologies are currently in the innovation part of the cycle between the “Early adopter” and the “Early majority” phase in the market.

Future prospects

Remote diagnostics will develop further, especially in the layers above the D-PDU API, in order to meet the timing requirements and to cover all the use-cases of vehicle diagnostics. Cloud-based diagnostics will enable new and interesting business models in the future, which will bring the vehicle customers even closer.

About KPIT Technologies Ltd.

KPIT Technologies GmbH is a subsidiary of KPIT Technologies Limited, India – a fast-growing global product engineering and IT consulting partner, focused on co-innovating domain intensive technology solutions for Automotive & Transportation, Manufacturing and Energy & Utilities corporations. KPIT is at the forefront of automotive engineering globally with solutions in the areas of AUTOSAR and in-Vehicle Networks, Body Electronics, Chassis, Safety and Driver Assistance, Functional Safety, Vehicle Diagnostics, Infotainment and Powertrain.

ACTIA I+ME GmbH headquartered in Braunschweig – is a subsidiary of ACTIA Automotive SA Toulouse. The consolidated group has more than 2,500 employees, over 25 years successfully operating in the areas of vehicle communication, workshop diagnostics, energy storage & management technology, on-board and control electronics. ACTIA I+ME is a recognized systems supplier for well-known companies from the automotive sector.

Press Contact:

Stefanie Koehler, Tel: +49 89 322 99 66 140, Stefanie.koehler @ kpit.com