The Development of Remote Diagnostic System for

Internet-connected Vehicles

Chu-Yuan Hsu, Rong-Terng Juang, Tian-Li Wang, and Chi-Cheng Chen

Engineer, Automotive Research & Testing Center
No.6, Lugong S. 7th Rd., Lugang, Changhua County 50544, Taiwan
[email protected]

ABSTRACT

This paper presents the implantation of unified diagnostic services (UDS) on connected
road vehicles and its application on remote diagnostic systems. The diagnostic equipment
can remotely access vehicles through wireless connections and acquire vehicle information,
such as diagnostic trouble codes, vehicle speed, battery voltage, engine speed, temperature
of coolant, etc. According to ISO 14229, an international UDS standard, this paper reveals a
software architecture for the implantation of UDS services. Based on the UDS software,
furthermore, it presents a prototype of remote diagnostic system for electric vehicles. The
diagnostic system consists of UDS software, a remote supervisory station (RSS), and the
implemented UDS software. Real-time information of vehicles is sent to the RSS
automatically through telecommunication links. Technicians at the RSS will launch the
UDS software to inspect the vehicle when any abnormal situation is detected. Lastly, this
paper presents verifications of the remote diagnostic systems at ARTC proving grounds. The
results show that driver safety can be secured and the malfunction vehicles can be repaired
quickly by using our remote diagnostic system.

Keywords: Internet of Things; Unified Diagnostic Service; Remote Diagnostic System

INTRODUCTION

The Internet of Things (IOT) (1) refers to ubiquitous forms of computing in which every
object is connected in some way to the Internet. It can be applied to various applications
such as smart cities and smart metering. Thanks to advances in wireless communications,
connected road vehicle is one of the merging applications of IOT (2). As a result, vehicle
information can be sent to a remote server on line and further analyzed for providing
various services. This application is one of popular topics for today's automotive industry.

Internet-connected vehicles are the wave of the future. Recently, governments and private
-1-
sectors have invested in the related developments. For example, the United States
Department of Transportation has built a test bed in Michigan for verifying the
improvement of road safety and efficiency by adopting connected vehicle technologies.
Regarding emergency services, automotive manufactures have cooperated with
telecommunication carriers on eCall services, by which not only a call can be made
manually or automatically when any accident occurred but also relevant information about
the incident can be sent to a nearest emergency centre. Therefore, the severity of the
accident can be assessed in advance and emergency services personnel with proper
equipment can be dispatched quickly. For information services, real-time traffic data can be
collected through connected vehicle technologies. Then the data can be used to support
information services such as dynamic navigation or other cloud services in order to improve
fuel efficiency by avoiding traffic congestions.

This paper discusses remote diagnostic system (3) for internet-connected Vehicles. The first
generation of on–board diagnostic (OBD) requirements was developed by the California Air
Resources Board (CARB) in 1985 and became law in 1988. The regulations require
emission-related system on vehicles to be monitored. Any system failure should be
indicated through Malfunction Indicator Lamp (MIL) on dashboard. Therefore, the problem
can be fixed as soon as possible.

In contrast to the early OBD system, enhance-OBD nowadays provides versatile services,
such as communication management and data transmission. Among those services, remote
diagnostics through wireless connections is the focus of this paper. Figure 1 shows the
structure of remote diagnosis for internet-connected vehicles, where the diagnostic
equipment can access vehicle information through wireless connections.

This paper presents the software implementation of the wireless unified diagnostic service
protocols for internet-connected Vehicles and its application on remote diagnostic system.
The software implementation follows the standard of the International Organization for
Standardization (ISO) 14229. This rest of this paper is organized as follows. Section II
reviews the ISO 14229 international standard for unified diagnostic services (UDS). Section
III presents the protocol and software architecture of the UDS services. Then the functional
tests are given in section IV. Section V demonstrates the Remote Diagnostic System and one
of its usage case. Lastly, some conclusions and remarks are given in the end of this paper.

-2-
 GPS

Internet
Internet

Figure 1. The architecture of remote diagnosis for connected vehicles

REVIEW OF ISO 14229 SPECIFICATIONS

Table 1. ISO 14229-Diagnostic Service List

Diagnostic and Comm.
Data Transmission Stored Data Transmission
Management
Diagnostic Session Control Read Data By Identifier Clear Diagnostic Information
(0x10) (0x22) (0x14)
Read Memory By Address
ECU Reset (0x11 hex) Read DTC Information (0x19)
(0x23)
Read Scaling Data By
Security Access (0x27) Input/Output Control
Identifier (0x24)
Communication Control Read Data By Periodic Input Output Control By
(0x28) Identifier (0x2A hex) Identifier (0x2F)
Dynamically Define Data
Tester Present (0x3E) Remote Activation of Routine
Identifier (0x2C)
Access Timing Parameter Write Data By Identifier
Routine Control (0x31)
(0x83) (0x2E)
Secured Data Transmission Dynamically Define Data
Upload Download
(0x84) Identifier (0x2C)
Write Data By Identifier
Control DTC Setting (0x85) Request Download (0x34)
(0x2E)
Write Memory By Address
Response On Event (0x86) Request Upload (0x35)
(0x3D)
Link Control (0x87) Transfer Data (0x36)
Request Transfer Exit (0x37)

ISO 14229 is a set of standards specifying the implementation of UDS. It consists of six
parts: Part one covers the specifications and requirements of UDS, Part two specifies
session layer services. Parts 3, 4, 5, and 6 specify the implementations of UDS on controller
area network, FlexRay, internet protocol, and K-Line, respectively.
Table 1 shows the diagnostic services listed in ISO 14229-1 (5). The services can be divided

-3-
into six categories, including diagnostic and communication management, data transmission,
stored data transmission, input/output control, remote activation of routine, and upload and
download. Each category covers various services.

The developed wireless diagnostic system consists of an external tester, a gateway and an
on-vehicle electronic control unit (ECU). The ECU could be an electronic fuel injection,
automatic gear box, anti-lock braking system, etc. connected on a serial data link embedded
in a vehicle. Table 2 shows the OSI (Open System Interconnection Reference Model)
protocols of the developed wireless diagnostic system. Each layer adopts a specific standard.
Firstly, the application layer in tester follows ISO 14229-1 and ISO14229-5 (6); session
layer follows ISO14229-2 (7); network layer and transport layer follow ISO 13400-2 (8);
and data link layer and physical layer follows IEEE 802.11 (9). Secondly, the application
layer of the internal ECU follows ISO 14229-1 and ISO14229-3 (10); session layer follows
ISO 14229-2; network layer and transport layer follow ISO 15765-2 (11); and data link
layer and physical layer follow ISO 11898-1 (12). Lastly, the task of the gateway is for
message translation between ISO 15765-2 and ISO 13400-2 in network layer and transport
layer.

Application Layer

The protocol at application layer specifies data link independent requirements of the
diagnostic services, which allows the external diagnostic tester to control diagnostic
functions in on-vehicle ECUs. Specifically, the tester makes a request of diagnostic service
to the ECU by way of the gateway. Then the ECU responses a positive/negative diagnostic
message upon a request from the tester.

Table 2. The OSI protocols of the wireless diagnostic system

Tester Gateway ECU

Application ISO 14229-1 ISO 14229-1

(Layer 7) ISO 14229-5 ISO 14229-3

Presentation
(Layer 6)
Session
ISO 14229-2 ISO 14229-2
(Layer 5)
Transport
(Layer 4)
ISO 13400-2 ISO 13400-2 ISO 15765-2 ISO 15765-2
Network
(Layer 3)
Data Link
(Layer 2)
IEEE 802.11 IEEE 802.11 ISO 11898-1 ISO 11898-1
Physical
(Layer 1)

-4-
 Session Layer

The protocol at session layer specifies services to provide independence between the
application layer and the transport and network layers. Specifically, each time the diagnostic
service is called, the session layer shall signal the completion (or failure) of the message
transmission to the upper layer. Meanwhile it shall verify that the arrival of the service
response is within certain waiting time. A typical time limit between the sending of a service
request and the receiving of the response is 2000 ms. Any exceeding of the time limit
produces an error code.

Transport Layer and Network Layer

ISO 13400 specifies the requirements for diagnostic communication between the external
tester and on-vehicle gateway using Internet Protocol (IP) as well as transmission control
protocol (TCP) and user datagram protocol (UDP). On the other hand, ISO 15765-2, which
is a network protocol tailored to meet the requirements of CAN-based vehicle network
systems, specifies the requirements for diagnostic communication between the gateway and
on-vehicle ECU. The major task here is to ensure data is compliance with certain formats.

Data Link Layer and Physical Layer

The protocols here include IEEE 802.11 and ISO 11898-1. IEEE 802.11 specifies the data
link layer and physical signaling of the IP network outside the vehicle, while ISO 11898-1
specifies the data link layer and physical signaling of the controller area network inside the
vehicle.

THE SOFTWARE ARCHITECTURE OF THE IMPLEMENTED UNIFIED

DIAGNOSTIC SERVICES

Figure 2 illustrates a basic wireless UDS system, which consists of an external test tester, a
gateway and internal ECUs.

-5-
 ECU ECU

CAN BUS

ECU ECU

Figure 2. The illustration of a basic wireless UDS system

External Diagnostic Tester

In the paper, a tablet computer is used as the external test equipment. Through the human
machine interface (HMI), users can specify the address of the on-vehicle ECU and the
diagnostic service along with some options. Figure 3 is one screenshot of the HMI, which
covers the address of the target ECU, the service information, service request button, and
response message.

Figure 3. The screenshot of the HMI on the diagnostic tester

Figure 4 shows the software architecture of the developed diagnostic tester. When any
service request is triggered, the application layer of the diagnostic tester first makes sure the
request is illegal than passes the request message to session layer. Session layer marks down
the departure time of the request and waits for the arrival of diagnostic response from the
on-vehicle ECU. Transport and network layer packs the request message into a specific
format and passes it down to data link and physical layers for transmission. The
transmission result will report to application layer so as to wait for service response or make
a retransmission. Upon receiving the service response from the on-vehicle ECU, the
message is decoded at transport and network layers and delivered to session layer, which

-6-
checks if the arrival time of the service response within certain time limit. Finally,
application layer checks if the diagnostic services have been rendered.

Service
External tester
Request Request Event List
Event
Application Layer
Confirm()

Request() Req_Confirm() Indication()

Session Layer

Request() Confirm() Indication()

Transport and Network Layers

Indication()
Request() Confirm()
Msg Queue

Data Link and Physical Layers

Transmitter() Receiver()

Figure 4. Software architecture of the diagnostic tester

Gateway

In the paper, Mircrochip’s Explorer 16 Demo Board is used as the platform of the gateway
implementation. The software is ported to the PIC32MX795F512L micro-processor on the
demo board. This demo board accesses the CAN bus via a Microchip’s CAN transceiver (12)
and Wi-Fi channel via ROVINC Networks’ RN-171 Wi-Fi module. As shown in Table 2, the
main task of the gateway is to transform the package format from TCP/IP to CAN, and vise
versa.

On-vehicle Electric Controller Unit

Figure 5 shows the software architecture of the developed on-vehicle ECU. Upon receiving
any diagnostic request, the message is decoded at transport and network layers and
delivered to session layer, which marks down the arrival time of the service request and
waits for the departure of diagnostic response from upper layer. Per the service request,
application layer makes a specific response and send the responding message down to the
lower layer. Session layer checks if the response is made within certain time limit. The
request message is then packed into a specific format at transport and network layers and
passed down to data link and physical layers for transmission. The transmission result will
report to application layer so as to check if a retransmission is necessary.

-7-
 On-Vehicle ECU

Application Layer

Indication() Response Rsp_Confirm()

Session Layer

Indication() Request() Confirm()

Transport and Network Layers

Indication()
Request() Confirm()
Msg Queue

Data Link and Physical Layers

Receiver() Transmitter()

Figure 5. Software architecture of the on-vehicle ECUs

FUNCTIONAL TESTS OF THE IMPLEMENTED DIAGNOSTIC SERVICES

The implemented UDS software was installed on a self build electric vehicle, as shown in
Figure 6. The external diagnostic tester can access the on-vehicle ECUs by way of the
gateway. To verify the functionalities of the UDS software, we provide functional test
before combining our UDS software into the remote diagnostic system which will be
present in next section. The intention is to create simulate a situation that a consumer’s
vehicle breaks down and the manufacturer can offers roadside assistance remotely. In this
section, we demonstrate three UDS functionalities, including time-out function, read and
clear diagnostic trouble codes (DTC).

Figure 6. The installation of the developed UDS services on a self build electric
vehicle

-8-
Time-out is one important function that UDS software should implement, because the
communication link maybe lost due to varying radio signal quality. If any response message
dose not arrive within certain time limit, a time-out warring will be raised. In this time-out
test, the vehicle was kept out of the reach the external diagnostic tester. As a result, a
time-out warring popped up after a service request was made, as shown in Figure 7. Then,
the external tester was automatically reset.

Read DTC and clear DTC are two essential functions the UDS should support. DTC codes
along with their status are how OBD identifies and communicates to technicians where and
what on-board problems exist. This paper adopts three DTC codes, 0x110114, 0x124251,
and 0xd54233, which represent overheat of motor, overspeed of motor and overcurrent,
respectively. Table 3 shows the definition of the DTC status. In the test, the electric vehicle
was driven with maximum output power on an uphill track. The track was so steep that the
motor of the electric vehicle was overheated and the MIL was illuminated to alert the driver.
Then the external tester was used to read the DTC as repair information. Figure 8 shows the
screenshot of the request and response of ReadDTCInformation (0x19) service. As a result,
the tester successfully read the DTC codes of overheat and overcurrent. After repairing the
vehicle, the recorded DTC codes should be erased. Therefore, the external tester requested
the ClearDiagnosticInformation (0x14) service to clear the DTC codes. Figure 9 shows the
screenshot of the request and response of ClearDiagnosticInformation (0x14) service. As a
result, when the ReadDTCInformation service was requested again, the on-vehicle ECU
returned sub-function ID (0x02) and DTCStatusAvailabilityMask (0xee), which means there
was no DTC record available.

Figure 7. Time out warning of external tester

-9-
 Figure8. Request and response of ReadDTCInformation (0x19) service

Figure 9. Request and response of ClearDiagnosticInformation (0x14) service

Table 3. Status of DTC (5)

bit Status Of DTC Description

1 testFailed DTC is no longer failed at the time of the request.

2 testFailedThisOperationCycle DTC never failed on the current operation cycle.
3 pendingDTC DTC failed on the current or previous operation cycle.

4 confirmedDTC DTC is not confirmed at the time of the request.

5 testNotCompletedSinceLastClear DTC test has been completed since the last code clear.
6 testFailedSinceLastClear DTC test failed at least once since last code clear.
7 testNotCompletedThisOperationCycle DTC test completed this operation cycle.

8 warningIndicatorRequested Server is not requesting warning indicator to be active.

THE DEVELOPED REMOTE DIAGNOSTIC SYSTEM

Based on the UDS software, this paper further builds an advanced remote diagnostic system,

- 10 -
which includes not only vehicles but also a remote supervisory station, as shown in Figure
10. The detailed architecture of the self build electric vehicle is shown in Figure 11, where
two CAN buses are deployed. CAN bus 1 is used to transmit information of primary
controllers such as MCU, BCU, and the gateway. CAN 2 is used to transmit information of
other controllers such as AAC. The vehicle sends its information, such as voltage, current,
speed, and temperature, to the supervisory station periodically. The vehicle information is
used to monitor the status of the vehicle. Figure 12 shows one screenshot of the monitoring
station. If any abnormal situation is detected, compared to previous collected data, the
personal at the supervisory station can further inspect the vehicle immediately by launching
the UDS services. According to the acquired DTCs, technicians at the supervisory station
can give the driver instructions for safety concerns or provide roadside assistance services
by sending out rescue team with proper equipment.

Figure 10. The installation of the developed UDS on a self build electric vehicle

CAN 1
MCU EPS
BCU
Panel VCU : Vehicle Control Unit
RS232 VCU Gateway
BCU : Battery Control Unit
330 V

Display
AAC : Automotive Air-Conditioning
12 V
EPS : Electric Power Steering
DC/DC CAN 2
MCU : Motor Control Unit
AAC Others

330 V

Figure 11. The network architecture of the self build electric vehicle

- 11 -
 Figure 12. The page of powertrain in supervisory station at ARTC

To verify the functionalities of the remote diagnostic system, the electric vehicle was tested
at ARTC’s proving ground, as shown in Figure 13. For explanation purpose, one diagnostic
case is given below. The temperature and current of VCU on the vehicle were below upper
limits but higher than normal values. The supervisory station recognized this situation and
monitored the duration of these events. After the duration exceeded a certain threshold, the
UDS software was launched to acquire the DTCs. The DTCs indicated that the motor torque
was overloaded. Therefore, the vehicle was instructed to pull over immediately and
technicians were sent out to further inspect the vehicle. It turned out that the problem was
caused by mechanical brake components. As a result, the driver safety was secured and the
problem was fixed.

- 12 -
 Figure 13. The proving ground at ARTC

CONCLUSIONS

This paper has demonstrated the implantation of UDS software for internet-connected
vehicles and its application on remote diagnostic systems. The basic diagnostic system
consists of an external tester, a gateway and on-vehicle ECUs. All the nodes on the system
comply with corresponding specifications, such as ISO 14229-1, ISO 14229-3 and ISO
14229-5 at application layer, ISO 14229-2 at session layer, ISO 13400-2 and ISO 15765-2
at network layer and transport layer, and IEEE 802.11 and ISO 11898-1 at physical layer.
Based on the UDS software, this paper has also presented an advanced remote diagnostic
system. The remote supervisory station constantly monitors the status of vehicles. Upon the
detection of any abnormal situation, technicians at the supervisory station can launch the
UDS software for further inspection of the vehicle. Therefore, malfunction vehicles can be
repaired quickly and driver safety can be secured.

REFERENCE

(1) J. Zheng, D. Simplot-Ryl, C. Bisdikian, and H. T. Mouftah, "The internet of things,"

IEEE Communications Magazine, Vol. 49, Issue 11, pp.30-31, 2011.
(2) The Hammersmith Group, "The internet of things: Vehicles as networked objects,"
The Hammersmith Group Research Report, July 2009.
(3) J. Lin, S.-C. Chen, Y.-T. Shih, and S.-H. Chen, ―A study on Remote On-Line
Diagnostic System for Vehicle by Integrating the Technology of OBD, GPS, and
3G‖, World Academy of Science, Engineering and Technology, 2009.
(4) P. Dzhelekarski and D. Alexiev, ―Reading and Interpreting Diagnostic Data form
Vehicle OBDII System‖, ELECTRONICS’2005, Sep. 21, 2005.
(5) Road vehicles — Unified Diagnositc Services — Part 1: Specification and
requirements, ISO 14229-1, April 15, 2007.
(6) Road vehicles — Unified Diagnositc Services — Part 5: Unified Disgnostic
Services on Internet Protocol Implementation (UDSonIP), ISO 14229-5, March 28,
2012.

- 13 -
(7) Road vehicles — Unified Diagnositc Services — Part 5: Session layer services, ISO
14229-2, Feb 15, 2013.
(8) Road vehicles — Diagnostic Communication over Internet Protocol (DoIP) — Part
2: Transport Protocol and Network Layer Services, ISO 13400-2, Jun. 01, 2012
(9) IEEE 802.11: Wireless LAN Medium Access Control and Physical Layer
Specifications. IEEE-SA. April 5, 2012.
(10) Road vehicles — Diagnostic Communication over Internet Protocol (DoIP) — Part
3: Unified Diagnostic Services on CAN Implementation (UDSonCAN), ISO
14229-3, Jan. 15, 2013.
(11) Road vehicles — Diagnostics on Controller Area Networks (CAN) — Part 2:
Network Layer Services, ISO 15765-2, Oct. 15, 2004.
(12) Road vehicles — Control Area Network — Part 1: Data Connection Layer and
Physical Signal, ISO 11898-1, May 24, 2006.

- 14 -