ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

Remote Vehicle Diagnostics over the Internet using the DoIP Protocol

Mathias Johanson Pål Dahle Andreas Söderberg

Alkit Communications AB Volvo Car Corporation SP Technical Research
Mölndal, Sweden Gothenburg, Sweden Institute of Sweden
[email protected] [email protected] Borås, Sweden
[email protected]

Abstract—Next generation vehicles will provide powerful A. Remote vehicle diagnostics

connectivity and telematics services, enabling many new
With the tremendous proliferation of wireless
applications of vehicle communication. We will in this paper
study the opportunities of performing remote vehicle
communication networks, telematics systems and services
diagnostics, where the diagnostic tool (test equipment) and have been designed that make it possible to access
the vehicle are separated by an internetwork, e.g., the diagnostic data from vehicles remotely, without requiring
Internet. The development of a prototype system for remote physical access to the vehicle. Presently, telematics
vehicle diagnostics, based on the emerging Diagnostics over services for diagnostics of general purpose passenger cars
IP (DoIP) ISO standard, is presented and early usage are mainly used during testing and validation of pre-series
experiments with synchronous remote diagnostic read-out vehicles, but aftermarket services are also emerging in
and control are described. A number of safety related issues premium segments, for improved service and maintenance
are identified that will need closer study before a broad offerings [1]. Next generation vehicles will have
deployment of remote diagnostics services is feasible. sophisticated on-board connectivity equipment, providing
Furthermore, a classification of vehicle diagnostics wireless network access to the vehicle for infotainment and
applications is provided, which is intended to elucidate the other telematics services. This will make it possible to
differences between synchronous (online) and asynchronous realize remote diagnostic services for large-scale collection
(offline) operation in local and distributed settings. of diagnostic data from ECUs at level previously
unattainable. Furthermore, this will enable many new
Keywords-vehicle diagnostics, vehicular communication
aftermarket services and will also improve the
opportunities of collecting diagnostic data for use during
I. INTRODUCTION product development.
Access to diagnostic data from Electronic Control B. Integrated automotive diagnostics
Units (ECU) in vehicles is of great importance in the
automotive industry, both from a life cycle support Since automotive diagnostic systems are important
perspective and during product development. Through both for aftermarket services and during many stages of
diagnostic services, the state-of-health of components and product development, a common framework for capture,
subsystems can be monitored to detect and prevent failures analysis and management of diagnostic data is highly
by means of predictive maintenance, which improves desirable. Campos et al. argue that previous generations of
operational availability and lowers support costs. For pre- diagnostics systems have not been well integrated,
series test vehicles, diagnostic services are crucial in order resulting in unnecessary duplication of effort in developing
to be able to track problems as early as possible in the different diagnostic applications, each with its own
development process, preventing serious faults to pass infrastructure, components and software [2]. This leads to
undetected into production vehicles or as a tool during inefficient use of resources and high costs for development
verification and validation activities. In the aftermarket, and maintenance of the diagnostics applications.
diagnostics form an important part of the service and The key to realizing integrated diagnostic systems is to
maintenance process, with Diagnostic Trouble Codes rely on standardized interfaces for communication and
(DTC) routinely being read out from customer vehicles systems integration and to base the diagnostic software
during service for state-of-health monitoring and fault development on a component-based software architecture.
tracing. Automotive manufacturers rely on diagnostic This facilitates re-use of software components and makes
systems in order to improve customer satisfaction by integration of components and subsystems from many
increasing the service technicians' ability to diagnose and different vendors possible in an interoperable way.
remedy problems in the increasingly complex Automotive diagnostics has a long history of
electronically controlled vehicles. As an added value for standardization efforts, driven both by industrial inter-
the automotive manufacturer, the diagnostic data retrieved operability initiatives and legislation. One recent such
during service can be uploaded to the manufacturer's effort is the emerging DoIP standard.
database over the Internet. Statistical analysis of collected
DTCs is important in order to monitor the quality of
components and subsystems, to prioritize in which order II. THE DOIP STANDARD
problems should be addressed and to find correlations The standardization of automotive diagnostics
between different faults, or between faults and the technology was initiated by legislative regulations for
operating environment. emission control. These initiatives have led to numerous

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 226

ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

standardization efforts of automotive diagnostic services, including mobile customer equipment such as smart
on virtually all technological levels, from hardware phones or PDAs.
interfaces to communication protocols and software APIs. The use case descriptions and communication
The perhaps most visible and influential initiative to date is scenarios described in ISO 13400-1 shows a considerable
the OBD-II specification issued by the California Air focus on communication between an in-vehicle network
Resource Board (CARB), which is now mandatory for all and external equipment in the immediate vicinity of the
cars sold in the US and the EU. Building further on this, vehicle, such as test equipment connected through an
the United Nations has initiated work on a new Ethernet cable or a local area network (LAN), or mobile
standardization framework called WWH-OBD (World devices connected through wireless LAN (WLAN)
Wide Harmonized On-Board Diagnostics), with the aim of technology. Uses cases such as the one focused in this
rendering regional standards of vehicle diagnostics for paper, i.e., the opportunity of doing vehicle diagnostics
emission control unnecessary and to replace them with a with the external test equipment (or mobile device) being
global standard. Moreover, this new standard will be a arbitrarily far away from the vehicle, interconnected by a
great leap forward in terms of new technology and true internetwork (i.e., a routed, packet-switched network
protocols, enabling entirely new applications and services. like the Internet) is not specifically discussed. This is also
One of the results of the WWH-OBD effort is the choice of reflected in the design of the DoIP communication
using the Internet Protocol (IP) for communication protocol itself, for instance in the reliance on subnet
between off-board and on-board diagnostic systems and broadcasts for vehicle announcements.
for this purpose the Diagnostics over IP (DoIP) protocol is Part 2 defines network and transport layer protocols
being developed by ISO, the International Organization for and services for vehicle diagnostics. This includes IP
Standardization, under the formal name ISO 13400 [3]. address assignment, vehicle announcement and vehicle
The main motivation for introducing IP into the family discovery, connection establishment, communication
of automotive diagnostics protocols is that the recent protocol message format, data routing to in-vehicle nodes,
developments of new in-vehicle networks has led to the status information and error handling. The focus on
need for communication between external test equipment applications where the external test equipment is in the
and on-board ECUs using many different data link layer immediate vicinity (i.e., on the same subnetwork) as the
technologies. To avoid having to implement, maintain and vehicle is manifest primarily in the mechanism designed
optimize transport and data link layer protocols for each for vehicle announcement and discovery. This mechanism
new communication equipment development, and to easily is intended to make external test equipment aware of the IP
be able to introduce new physical and data link layer address and Vehicle Identification Number (VIN) of the
technologies, a common internetworking protocol is vehicles connected to the same subnetwork. This is
needed, which is exactly what IP was designed for. performed through subnet broadcasts of Vehicle
There is however a very interesting side-effect of this Announcement and Vehicle Identification Request
choice of network protocol, since it will improve the messages. Once the external test equipment has learned the
opportunities of interconnecting in-vehicle networks with IP address of a vehicle, a direct TCP connection to the
the Internet for many new applications, including online, vehicle's gateway node can be established, and the
remote automotive diagnostics, which is the focus of this diagnostic data (or other data) exchange can be initiated.
paper. The message format designed for carrying the data is a
lightweight message format based on a generic header and
A. DoIP protocol overview a payload specific header. The 8 byte generic header
The ISO 13400 standard consists of four parts: contains the DoIP protocol version number, payload type
• Part 1: General information and use case identifier and payload length field. The payload format for
definition diagnostic data exchange adds a 4 byte header containing
• Part 2: Transport protocol and network layer the 16-bit source and destination addresses (identifying the
services test equipment and ECU respectively), followed by the
• Part 3: IEEE802.3 based wired vehicle interface variable length data (up to 4 Gbytes). The connection set-
• Part 4: Ethernet-based High-speed Data Link up and data exchange can be carried out according to the
Connector DoIP specification regardless of whether the external test
In Part 1, the use cases that have guided the design of equipment and the vehicle are on the same local network
the protocol are outlined and a number of typical or separated by an internetwork, providing that some
communication scenarios are described. Five main use mechanism external to DoIP is used for vehicle discovery.
case clusters are identified: (i) Pre-defined information This is the basis for the remote online diagnostics
request (such as state-of-health monitoring or road- application that will be described in detail in Section V.
worthiness assessment), (ii) vehicle inspection and repair Parts 3 and 4 of the standard specifies the data link
(e.g., vehicle diagnostic fault tracing or vehicle readiness layer and physical layer requirements, which are based on
qualification), (iii) vehicle/ECU software reprogramming the Ethernet (IEEE 802.3) protocol and the ISO 15031-3
(i.e., firmware upgrade of ECUs during service or (SAE J1962) connector.
manufacturing), (iv) vehicle/ECU assembly line inspection Note that, despite the name Diagnostics over IP, the
and repair (similar to (ii) but in a manufacturing DoIP protocol specifies several payload types that are not
environment) and (v) multi-purpose data transfer from and directly related to diagnostics in terms of the ISO 14229
to the vehicle, which involves non-diagnostic data scope [4]. (Only payload types 8000 and 8001 are intended
exchange between vehicle and external equipment, for ISO14229 diagnostics.)

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 227

ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

III. REMOTE ONLINE DIAGNOSTICS data collection from a fleet of test vehicles (or possibly
We use the term Remote Online Diagnostics to refer to customer vehicles) is set up to gather performance data or
data communication for vehicle diagnostics between one statistics for use in product development. In such a
or more in-vehicle network nodes and an external test scenario, a batch of diagnostic queries is scheduled for
equipment that are interconnected by an internetwork. download to a number of vehicles. At a suitable time
Thus, “remote” here means that the communication (when they have come online), the vehicles' telematics
endpoints are not required to be connected to the same systems download and execute the diagnostic queries,
local subnetwork. This means that the physical distance assemble the responses, and upload the results to a central
between the external test equipment and the vehicle can be database, possibly at a much later time.
arbitrarily large, providing there is a network infrastructure The same place / different times case does not have as
available. We use the “online” qualifier to characterize our immediately obvious applications as the others, but one
intended use of the DoIP protocol to perform diagnostic can envision a situation where a service technician (or an
data exchange synchronously over a TCP connection set automotive engineer) performs time consuming diagnostic
up between the endpoints. This is in contrast to “offline” or tests of vehicles available locally, by downloading a
asynchronous diagnostic data exchange being performed diagnostic script file to an onboard tester that performs the
by an on-board test equipment that performs the read-out tests, assembles the results, and then sends the results back
locally in the vehicle, possibly remotely triggered, and then to the test equipment (or a server), notifying the technician
uploads the result to a server at a suitable time using when the process is done.
whatever network connection is available. The most interesting case for analysis in our present
context is the distinction between the online and offline
A. A classification of vehicle diagnostics modes of remote diagnostics.
It will be useful to study the different modes of B. Diagnostic read-out versus diagnostic control
diagnostics a bit more closely, to identify possible
applications and to distinguish the technological solutions A distinction must be made between diagnostic read-
needed to implement them, their advantages and out and diagnostic control. The purpose of diagnostic
drawbacks. We will start this by classifying vehicle read-out is to query the status of the ECUs, typically by
diagnostics applications according to whether the reading out DTCs for fault tracing or state-of-health
diagnosis is performed with the vehicle and the external applications. In diagnostic control applications, diagnostic
test equipment being in the same place (connected to the commands that may alter the behavior of the vehicle are
same local subnetwork) or in different places (connected generated, for instance to turn the lights on and off. Thus,
by an internetwork) and whether the diagnostic data diagnostic read-out is a read-only operation, whereas
exchange is performed synchronously (at the same time) or diagnostic control is read/write.
asynchronously (at different times). This classification, C. Wireless versus wired diagnostics
inspired by the classic time/space taxonomy of Groupware
by Ellis et al. [5] is shown in Figure 1. Note that our definition of remote versus local
diagnostics does not depend on whether the
communication is performed using wired or wireless
Same time Different times
(synchronous) (asynchronous)
networks. A wireless local diagnostic application is for
instance when a service technician connects to a locally
Same place (local Traditional Local Offline present vehicle over a short-range wireless communication
network) Diagnostics Diagnostics
technology such as Bluetooth or IEEE 802.11 for
Different places Remote Online Remote Offline diagnostics. In the wireless remote diagnostics case, some
(internetwork) Diagnostics Diagnostics wide area wireless network technology is used (such as
Figure 1. Time / space taxonomy of automotive diagnostics applications GPRS, 3G or 4G), or a combination of short range wireless
communication and wired networks.
The same place / same time case is the “traditional”
diagnostic application, wherein a service technician (or D. Online versus offline diagnostics
automotive engineer) connects an external tester to the Although elements of the DoIP standard could be used
vehicle's OBD-II connector, reads out and analyzes to implement both the online and offline modes of remote
diagnostic data for fault tracing or state-of-health purposes. diagnostics described above, it is clear that the DoIP
The different places / same time case is the application protocol has been primarily designed with synchronous
we focus on in this paper (remote online diagnostics), operation in mind. Since the main use cases that governed
which gives the possibility for a service technician or the design of the protocol are actually in the same place /
engineer to do the same diagnostic read-out and fault same time category of Figure 1, this is not surprising. An
tracing without being at the same place as the vehicle. A interesting point to observe is that systems designed for
specific use scenario might be that a customer detects a same place / same time applications can, if implemented
malfunction in a vehicle and calls a service technician for using the DoIP protocol, with very minor changes be used
support. The technician can then perform the fault tracing also for different places / same time applications, i.e., for
remotely and online, detecting and possibly solving the remote online diagnostics. For instance, a traditional
problem, and instructing the customer on how to proceed. diagnostic read-out tool used in a service repair shop for
The different places / different times case is a remote fault tracing could with small modifications be used to
offline diagnostic application. A typical example of when remotely diagnose a vehicle on another continent. A
this type of service is useful is when large scale diagnostic drawback of using the online approach for remote

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 228

ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

diagnostics is that applications that perform a complete connection congestion or processing overload. This can be
diagnostic read-out of DTCs from all ECUs typically solved by filtering out vehicle announcement packets from
generate a large number of query/response transactions. the VPN connections of the external testers. A side benefit
With a considerable round-trip delay, as is often of using a VPN based approach is the resolution of several
unavoidable in internetwork configurations, this can lead security issues.
to a long total read-out time. The obvious remedy for this An alternative to the VPN approach to the vehicle
is to instead download a batch of queries, perform them identification problem is to develop a dedicated vehicle
locally in the vehicle, assemble the responses and send identification mechanism for remote online diagnostics
back. This is the offline approach described above. applications. In the prototype application development
However, it is not always easy to design a generic batch of described in Section V, a very simple vehicle identification
diagnostic queries, since the choice of which queries to mechanism is used, wherein each vehicle that comes
include depends on the answer to previous queries. This online connects using TCP to a proxy server, reports its
means that a lot of logic needs to be present in the onboard VIN number and then waits for a DoIP session to begin
tester in order to be able to execute the diagnostics (keeping the TCP connection alive). The external tester
properly in all situations. It is generally beneficial to keep connects to the proxy, queries for a particular VIN and if
this complexity at the infrastructure (server) side, rather the vehicle is connected to the proxy the two TCP
than in the vehicle. connections are interconnected and the DoIP session can
The main technological difference between the begin. An additional benefit of this approach is that it also
synchronous and the asynchronous case is that in the solves the problem that appears if the vehicle is not
synchronous case the diagnostic queries or commands are assigned a public IP address, due to Network Address
sent by the external test equipment and directly responded Translation (NAT) firewalls being used.
to by the ECUs, whereas in the asynchronous case there is For security reasons, and practical reasons, it might be
a time difference between query and response, and the desirable to let the vehicles use private IP addresses. This
network connection is not required to be kept alive during is often the case with addresses being assigned to mobile
this time interval in the asynchronous case. The division network devices in commercial wireless Internet access
between the two is not clear-cut however, and one can services. The problem with this is that private IP addresses
imagine hybrid approaches combining the two modes. are not reachable from outside; all communication sessions
must be initiated from the mobile device (the vehicle in our
E. Remote online diagnostics using DoIP case). Both mechanisms for vehicle discovery described
As previously discussed, the core of the DoIP protocol above avoid this problem by having the VPN and DoIP
can be used unmodified for remote online diagnostics, TCP connections respectively initiated from the vehicle
provided that the vehicle discovery and identification side.
mechanism is supported by some additional means. Recall
that the problem of the DoIP-mechanism for vehicle IV. SAFETY ASPECTS OF REMOTE DIAGNOSTIC OPERATIONS
announcement and discovery is that it relies on subnet Introducing the possibility to remotely control a vehicle
broadcasts, and thus these messages will not be accessible using diagnostic operations creates a new range of safety
outside the local IP subnet the vehicle is connected to. One related problems to address.
approach to overcome this problem is to establish a Virtual Safety can generally be divided into two main cases;
Private Network (VPN) connection from the vehicle to safety in normal operation and safety for a system that is
some enterprise network from where the operation of under influence of one or several system faults. The
remote testers is supported. Alternatively, the VPN former, safety in normal operation, mainly addresses the
connection is terminated at a proxy server that listens to task of creating a system that is safe with respect to usage,
the vehicle announcements and keeps track of the IP whereas the latter is about what is generally referred to as
addresses and VIN identifiers of the connected vehicles. functional safety or system safety. This involves building
The test equipment also connect through VPN to the proxy more reliable or even fault tolerant systems and addresses
server, send vehicle identification requests, and receive the issues about the process of reducing faults due to
VIN identifiers and IP addresses of the currently connected systematic (i.e., design) errors.
vehicles. Clearly this approach will have scalability
implications, when a very large number of vehicles are A. Normal operation
connected, typically for aftermarket applications. By introducing a remote diagnostic function, even if
Performance scalability issues at the server side can be used by trained multi-skilled technicians, we may have
easily resolved by scaling up the number of proxy servers introduced the possibility of the following new safety
for load-balancing, using some simple heuristic method implications:
for deciding which server handles which subset of vehicles • the mechanic cannot directly observe the situation
(e.g., based on IP subnet masks or similar). The problem that the vehicle is in,
that will appear at the external tester side is that the tester • the mechanic may not get visual feedback on
might get overly many responses to an unqualified vehicle what is really happening with the vehicle when it
identification request (i.e., a vehicle identification request is under diagnostic control,
message without VIN or EID). This can be resolved by
• the mechanic cannot interact with the vehicle in
only allowing vehicle identification request messages with
any other ways than using the terminal and an
EID or VIN at the proxy servers. Another problem is that
established communication session,
all vehicle announcement messages will be propagated to
the connected external testers, which might cause network

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 229

ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

• the connection between the operator and the predict what the function developers will introduce in the
vehicle may be unreliable in terms of latency and future. Thus, the key has been to find a generalized way to
bandwidth, analyze the system faults instead of looking at specific
• there might be significant (non-deterministic) actuators that may be involved in the cause of the hazard.
delays between the issuing of a diagnostic The general findings need then be applied at the various
command and the moment when action is taken subsystems that use diagnostics as a tool, by considering
in the vehicle, faulty diagnostics as a source of hazards as well as any
• there may be persons nearby or even inside the other root cause.
vehicle, e.g., the driver of the vehicle. Note that nothing of the above makes any difference
In connection to the prototype development of a remote between traditional off-board diagnostics and remote
diagnostics system described in Section V, a safety diagnostics. The diagnostic subsystem is present even in
mechanism involving the remote user in diagnostic actions today's vehicles. However there is one specific difference:
has been designed. In this solution we have concluded that the test equipment that is traditionally connected to the
• the user of the vehicle needs to confirm her or his OBD connector in the vehicle would now usually (from a
presence at the vehicle, business case point of view) be integrated within the
• the user needs to understand and subsequently vehicle and is always present even if inactive. This
approve the action to be taken, internal tester needs special attention when it comes to the
• the user needs to be in charge of triggering of the analysis of the source of any hazards.
remote action.
V. PROTOTYPE SYSTEM IMPLEMENTATION AND EXPERIMENTS
The mechanic, with diagnostic and service expert
knowledge, is initiating the diagnostic request by down- In order to gain practical experiences from remote
loading a diagnostic task to the vehicle. The mechanic has online diagnostics and to explore how this can be realized
to be in contact with the remote user (e.g., by phone) to be using the DoIP protocol, a prototype system was
able to give instructions and get confirmation of implemented and tested in a controlled environment. Since
understanding and approval to proceed. Presence control no vehicle with an on-board DoIP gateway was available,
can easily be achieved by interacting with the vehicle (e.g., it was decided that a DoIP gateway would be implemented
entering a code in the vehicle). Finally a trigger device on a Linux-based telematics system that could be
(e.g., the remote key-fob) connected to the vehicle will connected to a standard vehicle's CAN buses through the
trigger the diagnostic action to be taken. OBD-II connector. The telematics platform has GPRS,
It is believed that pure diagnostic read-out poses no EDGE and WLAN network interfaces as well as Ethernet
safety risk, whereas only a limited set of diagnostic control interfaces. The DoIP entity implemented in the telematics
actions can be considered safe under all circumstances. A unit handles the routing of diagnostic data between the in-
large amount of actuators in the vehicle are risk related, vehicle (CAN) networks and the DoIP TCP connection on
especially in certain situations, such as when the vehicle is the wireless network interfaces.
moving. Approval of safety limited synchronous diagnostic To avoid having to develop a full-fledged diagnostics
control therefore leads to a complex task of actuator safety application from scratch the aftermarket diagnostics
classification. Furthermore, combinatory effects between software VIDA, developed by Volvo Cars, running on an
sensors and other actuators complicate this matter even ordinary Windows PC was used as the external tester.
further. Since there were no DoIP functionality implementation in
VIDA at the time of this work, and since the
B. Functional safety implementation of this in VIDA itself was deemed not to
A soon to be finalized ISO standard being applied be feasible within the time frame of the project, the client
intensively by many vehicle OEMs, ISO26262 [6], that side DoIP interface was implemented in a dynamically
addresses functional safety for E/E systems within liked library (DLL) that VIDA can access through the
passenger cars is the natural starting point when studying J2534 interface. This way we were able to develop an
the system safety aspects of the diagnostic (sub-)system. online remote vehicle diagnostics system without
The standard, which comes in 10 parts, has been jointly modifying the vehicle or the actual diagnostics tool.
developed within a global automotive engineering With this approach, the diagnostics application (VIDA)
community for the last 5-10 years. It is expected to become on the PC will communicate ISO 14229 diagnostic
the de facto platform for system safety within the messages through the J2534 DLL in the same way as if the
automotive domain, since it spans the fields of system PC was connected directly to the vehicle's CAN bus. What
engineering, hardware and software development, but also really happens is that the DLL encapsulates the ISO 14229
is specifically tailored to fit how automotive development messages in DoIP messages that are transmitted over the IP
is traditionally organized by OEMs and suppliers. network to the DoIP gateway in the vehicle, that
Specifically, we have done work within the "concept decapsulates them, relays them onto the CAN bus, reads
phase" (part 3 of the standard) by considering the and assembles the responses (if any) and returns over the
diagnostic sub-system as the system under focus in the DoIP connection back to the DLL that forwards the result
Item definition. This has proven to be difficult considering to the application. The diagnostics application can then
the natural characteristics of the diagnostic system: it process the response and go on to send the next query. The
contains limited functionality, but spans virtually all DoIP protocol is in this situation completely transparent to
(electrical) sensors and actuators in the vehicle. Moreover, the diagnostic application.
the system is constantly expanding as new sensors and Except for being a resource efficient way to implement
actuators are introduced in the vehicle and it is hard to our prototype system for experimentation, demonstration

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 230

ICSNC 2011 : The Sixth International Conference on Systems and Networks Communications

and proof-of-concept, this approach is also interesting in the salient features of the DoIP protocol, which has been
that it provides a way to integrate diagnostics software designed first and foremost for synchronous, local
completely unmodified into a DoIP-based infrastructure. applications. However, since DoIP is using the IP protocol,
This could help migration towards DoIP of the large which is also the network protocol of the Internet, truly
installed base of tools and services based on J2534. A remote diagnostic applications are possible. The feasibility
drawback of the design is that some of the complexities of of designing such remote, online diagnostic applications
the transport protocol used for implementing ISO 14229 was demonstrated through a prototype implementation,
diagnostics services over CAN (i.e., ISO 15765-2), such as wherein a legacy vehicle diagnostics system was adapted
the management of flow control filters, needs to be to use the DoIP protocol. Experiments with the prototype
duplicated between the DLL and the DoIP gateway in the shows that remote diagnostic read-out over relatively
vehicle. narrowband wireless internetworks is possible. Remote
diagnostic control applications were also demonstrated.
A. Experiments One of the biggest challenges for introducing remote
The experiments carried out with the remote online vehicle diagnostic services at a large scale is how to ensure
diagnostics system prototype was first of all to demonstrate the safety of the users of the vehicles. Our safety analysis
that a complete diagnostic read-out session could be shows that pure diagnostic read-out can be safely
performed over a wireless Internet connection, using the implemented, whereas diagnostic control applications in
GPRS interface of the telematics unit. The PC was located the general case are problematic. A related critical issue is
in an office environment connected to the Internet using a how to protect a remote diagnostic service from illicit
LAN connection. A complete read-out of DTCs and malevolent access. A comprehensive analysis of security
additional data from the approximately 20 ECUs on the issues in remote vehicle diagnostics is currently being
two CAN buses of a Volvo V70 takes around 10 minutes conducted in relation to the work being presented here.
over a GPRS network connection. This is primarily due to The outcome of this analysis will have a profound impact
the significant round-trip delay in GPRS networks. When on the design of the remote diagnostic system.
using a WLAN connection, significantly shorter read-out Our main conclusion from this work is that the DoIP
times were measured: around 3 minutes, which is similar protocol, when deployed broadly throughout the auto-
to local read-out using a directly connected CAN device. motive industry, will enable many new applications of
In addition to the DRO experiments, diagnostic control remote vehicle data access and control. This will pose
commands were also tested, for instance recording of pedal many challenges in terms of performance, scalability,
positions, with real-time visualization of the pedal security, safety and resource management, but will at the
positions in the diagnostic application. Commands same time give rise to very interesting new added-value
requiring write access were also tested, but limited to services for the customers, and will also bring great
relatively safe operations, in the context of the opportunities to improve automotive product development.
experiments, like turning the engine fan or the lights on
and off. ACKNOWLEDGMENT
In principle, remote ECU reprogramming should also This work was supported by the SIGYN-II project co-
be possible to do in this way, but this was not tested, due to funded by VINNOVA, the innovation agency of Sweden.
practical obstacles. In practice, remote reprogramming of
ECUs is much more likely to be implemented based on a
remote offline diagnostics model. This is because REFERENCES
reprogramming of ECUs is typically time consuming, and [1] Hiraoka, C. "Technology Acceptance of Connected
the requirement to keep an online connection alive Services in the Automotive Industry," Gabler, ISBN 978-3-
throughout the reprogramming will in many cases be 8349-1870-3, Wiesbaden, 2009.
failure prone. If the connection is disrupted during the [2] Campos, F.T., Mills, W.N. and Graves, M.L. "A reference
reprogramming, the entire session will have to be rolled architecture for remote diagnostics and prognostics
back. A better alternative is to download the software applications," Proceedings of Autotestcon, pp. 842-853,
ISBN 0-7803-7441-X, Huntsville, USA, October 2002.
update to the vehicle asynchronously, perform the
[3] ISO/CD 13400, "Road vehicles — Diagnostic
reprogramming in offline mode, and then reestablish the communication between test equipment and vehicles over
connection to report the status. Such an approach is Internet Protocol (DoIP)," 2009.
described by Nilsson and Larson [7]. [4] ISO 14229-1, "Road vehicles - Unified diagnostic services
(UDS) -- Part 1: Specification and requirements," 2006.
VI. CONCLUSIONS [5] Ellis, C., Gibbs, S. and Rein, G. “Groupware - Some Issues
In this paper we have shown how remote online vehicle and Experiences,” Communications of the ACM, Vol. 34
No. 1, pp. 38-58, 1991.
diagnostics can be realized based on the DoIP protocol. To
define what we mean by remote online diagnostics, we [6] ISO/FDIS 26262, "Road vehicles – Functional safety,"
Parts 1-10, 2010.
performed a classification of automotive diagnostics
[7] Nilsson, D. and Larson, U. "Secure Firmware Updates over
applications, based on whether the diagnosis is performed the Air in Intelligent Vehicles," Proceedings of the First
over a local network or over an internetwork spanning an IEEE Vehicular Networks and Applications Workshop
arbitrarily large distance, and whether the diagnostic (Vehi-Mobi), pp. 380-384, Beijing, People's Republic of
session is synchronous or asynchronous. We then outlined China, May 2008.

Copyright (c) IARIA, 2011. ISBN: 978-1-61208-166-3 231