Click here to refresh results
Click here to refresh results
Computer Science Technical Report Archive
USC Computer Science Technical Reports, no. 921 (2011)
(USC DC Other)
USC Computer Science Technical Reports, no. 921 (2011)
Copy asset link
Request this asset
Transcript (if available)
, Nilesh Mishra
, Luis Pedrosa
, Christopher Riesz
, and Ramesh Govindan
University of Southern California
Rutgers University, Camden
Wireless sensing and actuation have been explored in
many contexts, but the automotive setting has received rel-
atively little attention. Automobiles have tens of onboard
sensors and expose several hundred engine parameters which
can be tuned (a form of actuation). The optimal tuning for
a vehicle can depend upon terrain, traffic, and road condi-
tions, but the ability to tune a vehicle has only been avail-
able to mechanics and enthusiasts. In this paper, we de-
scribe the design and implementation of CARMA (Car Mo-
bile Assistant), a system that provides high-level abstrac-
tions for sensing automobile parameters and tuning them.
Using these abstractions, developers can easily write smart-
phone “apps” to achieve fuel efficiency, responsiveness, or
safety goals. Users of CARMA can tune their vehicles at the
granularity of individual trips, a capability we call person-
alized tuning. We demonstrate through a variety of appli-
cations written on top of CARMA that personalized tuning
can result in over 10% gains in fuel efficiency. We achieve
this through route-specific or driver-specific customizations.
Furthermore, CARMA is capable of improving user satisfac-
tion by increasing responsiveness when necessary, and pro-
moting vehicular safety by appropriately limiting the range
of performance available to novice or unsafe drivers.
Categories and Subject Descriptors
D.2.13 [Software Engineering]: Reusable Software—
Domain engineering; J.7 [Computers in Other Systems]:
Design, Experimentation, Performance
Automobile, Engine Control Unit, Scanning, Tuning
This material is based upon work supported by the National
Science Foundation under Grants No. CNS-021778, CCF-0830569
and CCF-1048606 and CCF-820230. Any opinions, findings and
conclusions or recomendations expressed in this material are those
of the author(s) and do not necessarily reflect the views of the Na-
tional Science Foundation (NSF).
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. To copy otherwise, to republish, to post on servers or to redistribute
to lists, requires prior specific permission and/or a fee.
SenSys’11, November 1–4, 2011, Seattle, WA, USA.
Copyright 2011 ACM 978-1-4503-0718-5/11/11 ...$10.00
Networked sensing and actuation have been explored in
many natural and man-made environments, most recently in
smart-grid and smart-building technologies [42, 28]. The
emergence of smartphones has added a new dimension to
networked sensing, enabling context awareness  and par-
ticipatory sensing . However, one ubiquitous man-made
artifact, the automobile, has received relatively less attention.
Automobiles have tens of onboard sensors which can
continuously monitor engine parameters such as the air flow,
the current gear setting, the engine RPM and speed. More
importantly, automobiles can be tuned by modifying engine
parameters, such as RPM limits, transmission shift points, or
air fuel mixtures. In general, automotive tuning is a com-
plex and dangerous task, so it is performed today by trained
mechanics, enthusiasts, or fleet operators.
There are, however, benefits to being able to tune cars on
a larger scale. Specifically, personalized tuning, in which a
user tunes a car at a granularity of a trip, can potentially have
significant fuel efficiency benefits. Most cars come with fac-
tory default parameters and are rarely modified, but as with
any parameterizable system, a single set of parameters is un-
likely to be optimal across all settings. Indeed, the fuel effi-
ciency of a car can vary widely with the route, the conges-
tion along the route, terrain, and other factors (Section 2).
Personalized tuning can determine route-specific engine pa-
rameters to squeeze efficiency gains.
Fuel efficiency is not the only motivation for personalized
tuning. This capability can be used to improve safety or to
increase the responsiveness
of the car when necessary. For
example, it is possible to set speed and RPM limits on cars
in order to prevent misuse or rash driving, a capability that is
useful when handing off a car to a teenaged driver.
This paper explores the design and implementation of
CARMA, a system for smartphones that is designed to de-
mocratize personalized tuning (Section 3). Because it runs
on smartphones, CARMA is highly portable and makes
trip-granularity tuning convenient. CARMA is also pro-
grammable, enabling the development of smartphone apps
that permit personalized tuning for flexibly achieving fuel
Responsiveness is the measure of how quickly and forcefully
a vehicle reacts to changes in throttle position. This includes en-
gine braking while off the throttle, and maintaining a lower gear for
quicker acceleration during throttle increases.
Figure 1. CARMA application workflow
efficiency, responsiveness, and safety goals.
CARMA is designed to enable the following personal-
ized tuning scenario (Figure 1). Before embarking on a
trip to a mountain resort, Alice pulls out her smartphone
and launches a CARMA app (Section 4) designed to tune
her car for fuel efficiency. She indicates the target destina-
tion and selects the route she prefers. The app accesses an
online database of routes and route characteristics to deter-
mine speed limits, the expected congestion, the density of
stoplights, and the terrain along the route. It then analyzes,
based on car sensor readings obtained from previous trips,
her driving habits on hilly roads, and sets engine parameters
to improve fuel efficiency on her trip without sacrificing re-
sponsiveness. When she reaches her destination, she invokes
another app that installs a speed limiter on her car, before
handing it off to a valet.
This paper takes a first step towards this goal by instan-
tiating many of the elements of the scenario. We have de-
signed and implemented the CARMA system, which pro-
vides high-level abstractions for automotive sensing and con-
trol. We have also implemented several apps that illus-
trate many of the benefits that come from programmability,
portability, and Internet-connectedness. To our knowledge,
CARMA is the only system to have these capabilities.
Using our implementation of CARMA on the Android
operating system, we demonstrate the benefits of personal-
ized tuning. In experiments (Section 5) conducted over 1100
miles and spanning a wide variety of traffic conditions, we
find that CARMA’s personalized tuning obtains 10% or more
fuel economy gains on most trips. This may seem modest,
but, if applied to the 250 million cars on US roads today,
over $19 billion in savings could be generated annually. We
also demonstrate CARMA’s flexibility, by implementing and
evaluating apps that promote safety and responsiveness, and
attempt to customize cars based on driver behavior.
2 Motivation for Personalized Tuning
Modern car engines have several parameters that deter-
mine their performance. Examples of such parameters in-
clude air flow, transmission shift points, and spark timings.
Settings for these parameters can determine the car’s fuel ef-
ficiency and its responsiveness. Cars come with factory de-
faults for these settings, and tuning modifies these parame-
ters. By personalized tuning, we mean the ability to modify a
car’s parameters at the granularity of a single trip: for exam-
ple, to optimize engine performance for the particular driver,
or the route, or traffic conditions.
A motivating scenario for personalized tuning is the teen-
mode or valet-mode. Before handing off a car to a teen or a
valet, an owner could limit engine performance to prevent
misuse or rash driving. When the car is returned, the owner
would restore the original settings before his or her next trip.
Beyond ensuring public safety, the premise underlying
personalized tuning is that a single set of parameters can-
not possibly be appropriate for different conditions (drivers,
routes, and traffic). To assess this premise, we conduct the
following series of experiments on two different cars: Car
A, owned by Driver A is a 2011 Ford Fiesta (manual trans-
mission), and Car B, owned by Driver B is a 1998 Toyota
Corolla (manual transmission). For each car, we have the
owner drive the car under the following scenarios: Int, a
drive along a local section of an Interstate highway during an
off-peak time; Int-T, a drive along an interstate highway dur-
ing rush hour; Hill, a segment of an undulating, but lightly
traveled, road; and Street, a flat section of a moderately busy
thoroughfare with several traffic lights in a large metropoli-
tan area. In addition, we conduct one experiment, Switch,
in which we switch drivers for the two cars, while following
the same route as Int. For each experiment, we measure the
fuel economy (in miles per US gallon) using the methodol-
ogy described in Section 5. Each experiment was conducted
in parallel to ensure that both cars experienced roughly the
same traffic conditions.
Figure 2. Fuel Economy for Two Cars
Figure 2 depicts the results of these experiments for the
two cars. Since the cars are from different manufacturers, we
cannot perform a meaningful comparison across cars. How-
ever, for a given car, there are significant performance differ-
ences across the experiments. For example, the Hill experi-
ment has almost 30% lower fuel economy than the Int route,
for both cars, while the Street experiment has a 50% lower
fuel economy than Int for Car A, and a 60% lower fuel econ-
omy for Car B. This is not surprising, and is also well known,
but motivates our work: there is significant variability across
different conditions, so it must be possible to extract better
performance by tuning the car separately for each condition.
Some of this variability is intrinsic. Notice that the per-
formance of the two cars under different conditions is quali-
tatively similar. This is because the work done to overcome
friction and wind resistance on a high-speed interstate with-
out traffic is different from the work done to climb hills or
to start and stop the car in traffic. This intrinsic variability
cannot be exploited by tuning.
There is also extrinsic variability that comes from having
non-optimal parameter settings. For example, every car has a
“sweet spot” engine RPM setting at which fuel consumption
is lowest for a required power output: lower or higher RPM
values can increase fuel consumption . It may be possi-
ble to tune the car’s transmission shift points so that the en-
gine RPM is maintained in a narrow band around this sweet
spot. Default settings usually permit a larger RPM band to
increase vehicle responsiveness.
Another example of extrinsic variability is illustrated by
comparing Int and Int-T for the two cars. Driver A is ac-
tually more fuel-efficient on the interstate in rush-hour, than
in the absence of traffic; the opposite is the case for Driver
B, whose Int-T fuel economy is 12% lower than Int. After
these experiments, we interviewed both drivers and found
that Driver A drives aggressively on an empty interstate, but
tries to maintain a steady speed in rush-hour traffic. Driver
B, on the other hand, drives steadily on an empty interstate,
but aggressively during rush-hour traffic (filling in the space
between his car and the one ahead to prevent lane changes).
Engines can be tuned to dampen these forms of aggression,
trading off some responsiveness for increased fuel efficiency.
A concrete example of extrinsic variability is illustrated
by our Switch experiment. Figure 3 shows the CDF of the
for Drivers A and B driving Car B on Int.
The throttle position is measured as a percentage, and corre-
sponds to the degree to which the accelerator is depressed.
As Figure 3 shows, Driver B has almost 9% higher fuel econ-
omy compared to Driver A because his throttle position is
lower more often; for 90% of the experiment, his throttle po-
sition is lower than 25%, while for driver A the correspond-
ing number is almost 40%. This form of extrinsic variability
can be exploited by appropriately tuning the engine.
10 20 30 40 50 60 70 80
Throttle Position (%)
Figure 3. Throttle position CDF in theSwitch experiment
In this paper, we explore the potential of personalized
designing a system called CARMA for conveniently
and flexibly tuning cars (Section 3), and
demonstrating that personalized tuning can exploit ex-
trinsic variability to obtain significant fuel efficiency or
responsiveness gains under different conditions (Sec-
By throttle position we mean the extent to which the gas pedal
is pushed down (measured in percentage). This is measured by an
ECU sensor and logged during experiments.
3 CARMA Design and Implementation
In this section, we begin with an introduction of auto-
motive sensing and control, then provide an overview of
CARMA, a system for personalized tuning. We follow this
with a description of its components, and a discussion of
the implications of our work. The next section evaluates
CARMA in detail.
3.1 Automotive Sensing and Control: Back-
CARMA provides two capabilities, sensing and control
of automobiles. Before we describe its design in detail, we
introduce the kinds of sensing and control possible in modern
automobiles and describe some terminology. CARMA pro-
vides higher-level abstractions for these capabilities, thereby
enabling flexible automotive personalization.
3.1.1 Sensing or Scanning
Modern cars are equipped with an Engine Control Unit
(ECU), an electronic device which controls engine and trans-
mission operations. The ECU can be queried for several
“sensor” values using a standard called On-Board Diagnos-
tics II (OBD-II). This standard was developed to provide ve-
hicles with self-diagnostics and reporting capabilities and is
mandatory in all cars sold in the United States after 1996.
The ECU is generally accessed using an OBD-II port. A
few standardized messaging formats (all of them based on
the Society of Automotive Engineers’ J1979 ) define a
uniform method for communicating with the ECU. Over the
years, multiple signaling protocols have been used over the
OBD-II interface, but all cars sold since 2008 in the United
States are now required to use the ISO 15765-4 (CAN) 
standard signaling protocol. To interface a computer with
the OBD-II port, an OBD-II-to-serial adapter is used for our
setup. The port can also be accessed wirelessly by using an
additional Serial-to-Bluetooth adapter.
Using OBD-II, it is possible to continuously sense (or
scan), in near real-time and while the car is operational, in-
stantaneous values of several parameters: vehicle speed, en-
gine RPM, throttle position, air flow, and so forth. While
there are different ways to obtain these values, the most gen-
eral approach is request-response: sending a request for a
parameter value to the ECU elicits a response from the ECU
containing the corresponding value. Using this, it is possi-
ble to write software that can scan a set of parameters peri-
odically. Each parameter is associated with a parameter ID
(PID) standardized in , and each PID is associated with
a conversion formula which transforms the bytes in the re-
sponse to the actual parameter value. Table 1 shows the spec-
ifications for four standardized PIDs; in this table, b
the i-th byte of the parameter value in the response message.
The set of PIDs supported in a car is manufacturer-
dependent. In the cars we used, 15 to 31 PIDs were sup-
ported. Beyond that, each manufacturer supports a variety of
car-specific (“enhanced”) PIDs, but their definitions are of-
ten not freely available. However, some manufacturers make
The requirements are specified by the 1990 Amendments to the
Clean Air Act . In Europe the related EOBD standard was made
mandatory in 2001 via the European Emission Standards Directive
PID Length Description Min / max values Formula
0A 1 Byte Fuel pressure 0 / 765 b
0C 2 Bytes Engine RPM 0 / 16383.75 (b
0F 1 Byte Intake air
-40 / 215 b
11 1 Byte Throttle po-
0 / 100 b
Table 1. Examples of PID definitions
these PID definitions available for a fee and tools that use
these enhanced PIDs have better diagnostic capabilities.
3.1.2 Control or Tuning
Beyond scanning, it is possible to modify engine param-
eters in order to improve a car’s performance or fuel effi-
ciency. This form of control, called tuning, is achieved by
updating the ECU firmware with the desired parameter set-
tings. Often, this form of tuning is performed in cars during
regular maintenance. Unfortunately, unlike scanning, tuning
methods are highly proprietary and are not readily available
to the average consumer. The main goal of this paper is to
explore the methods for, and benefits arising out of, democ-
ratizing personalized tuning.
Limited forms of tuning are available to consumers. At
one end of the spectrum, many cars come with modes that
users select for fuel economy or performance. Examples of
cars with such modes include the 2011 Dodge Grand Cara-
van , or 2011 Infiniti M . These modes are relatively
inflexible and coarse-grained, so cannot accommodate vari-
ability in driver behavior or traffic conditions.
At the other end of the spectrum, enthusiasts perform
fine-grained after-market tuning using specialized tuning
software [15, 7]. Examples of fine-grained tuning include:
changing the transmission shifting points, adjusting the fuel
delivery into the engine, or tweaking the traction control.
Sometimes, such tuning is necessitated by after-market ad-
ditions, such as turbochargers and superchargers, for which
engine behavior may need to be altered. Companies that de-
velop the tuning software do so by reverse-engineering the
ECU firmware or the expensive image flashing tools pro-
vided to mechanics by car manufacturers, or by purchasing
the software specifications from the manufacturer where pos-
sible. The developers of tuning software are helped by the
fact that manufacturers frequently reuse old vehicle software
and hardware and just add new functionality as required by
their newer models; nevertheless, the process of developing
this software is arduous and error-prone.
Even with this software, tuning a vehicle is a complex
task. Without proper knowledge of many of the car’s sys-
tems it is easy to make changes that make the car dangerous
to drive, or cause engine or transmission damage. This is
because most tuning systems provide very low levels of ab-
straction, allowing users to modify arbitrary combinations of
parameters. Changing a parameter can have significant side
effects. For example, igniting spark plugs earlier can im-
prove performance, but may induce knock retard which gen-
erates undesired vibrations and can result in catastrophic en-
gine failure. Some software gives the user extensive instruc-
tions on safe modifications, yet most commercial software
struggles with the flexibility-safety trade-off. Existing tuning
systems have erred towards giving users greater flexibility,
and for this reason their use has been limited to experts who
deeply understand the operation of their car. Typically, these
experts make modifications by trial-and-error: they modify
the car, scan all relevant parameters during a test drive, and
iterate on this procedure until they are satisfied with the re-
sult. They also exchange their tuning experiences in online
forums, promoting shared learning .
CARMA seeks a middle ground in this spectrum, and
is designed to provide more tuning choices than the limited
number of built-in modes, but in a manner that is more ac-
cessible to the average consumer.
3.2 Overview and System Architecture
CARMA is a smartphone-based system that provides
make and model-independent programming abstractions for
scanning and tuning automobiles. This capability, motivated
by our findings in Section 2, permits the development of
that take advantage of Internet connectivity and allow
non-expert users to customize their vehicles for routes, ter-
rain, and traffic conditions, and can result in improved per-
formance, fuel efficiency, and safety. To our knowledge, no
such capability exists today.
Existing tools have several shortcomings that motivate
the need for CARMA. Because the OBD-II signaling pro-
tocols are standardized, many scanning tools are publicly
available, some even for smartphones [22, 18]. These tools
cannot be used for tuning. As discussed in Section 3.1.2,
the tuning tools are often not extensible or modular and have
been developed for less portable computer platforms (laptops
or desktops). Moreover, they often only provide a graphical
user interface for setting specific engine parameters. These
tools are not programmable and cannot be invoked from an-
other application. Thus, these tools have been designed as-
suming infrequent customization and expert knowledge.
In contrast, CARMA’s programmability ensures the de-
velopment of applications which can be used by non-experts.
Our current CARMA prototype can be used to develop apps
that perform many kinds of useful personalizations. For ex-
ample, one app could automatically increase the responsive-
ness of a vehicle on a hilly route, by querying a geospatial
database over the Internet to obtain the elevation gain on
the route, then calculating the appropriate gear shift points
to give the driver a greater sense of control. Another app
could exploit the diversity in fuel efficiency (Section 2) un-
der different route and traffic conditions and tunes the en-
gine to the specific route or the expected traffic conditions.
Yet another app could personalize the car’s parameters for a
specific driver, by analyzing a GPS-tagged history of engine
parameters, thereby exploiting user diversity. Finally, other
apps could promote safety, by analyzing an online database
of routes to set vehicle speed and RPM limits commensurate
with the route under consideration.
Moreover, these customizations can be applied at the
granularity of a single trip, and can be changed for different
drivers. This capability arises from CARMA’s portability:
CARMA is implemented on smartphones for this reason. As
mentioned above, the use of smartphones has another ben-
We use this term to denote applications for smartphones.
Application 1 Application 2 Application 3
Scanning Subsystem Tuning Subsystem
Binary Mod. Subsystem
Figure 4. CARMA System Architecture
efit: apps can consult online databases to make intelligent
tuning decisions. That said, the use of smartphones is not
a fundamental requirement of CARMA (any programmable,
Internet-connected embedded computer with some capabil-
ities for user interaction would suffice), but the ubiquity of
smartphones makes them an attractive choice for CARMA.
The eventual aim of CARMA is to enable an ecosystem for
the development of third-party tuning apps, and to make cus-
tom vehicle tuning as common, simple, and safe as mapping
a route using a GPS software is today. Many other chal-
lenges must be overcome to achieve this vision, as discussed
in Section 3.6.
The CARMA software architecture is illustrated in Fig-
ure 4. At a high level, CARMA is sub-divided into two major
subsystems: the Scanning Subsystem that reads current sen-
sory data from the phone (e.g. GPS) and from the car (e.g.
RPM) and the Tuning Subsystem that allows engine param-
eter modifications. Each of these sub-systems exposes a pro-
cedural API and each communicates with the vehicle’s ECU
using the OBD-II port, connected via Bluetooth. In addition,
the Scanning subsystem accesses the smartphone’s sensors
in order to tag sensor readings with time and location.
The Tuning subsystem is internally divided into three
conceptually distinct parts. The ModAPI exports car-
independent abstractions for modifying engine parameters.
Apps access only this API and do not have access to other
components of the Tuner subsystem. The ECU Binary
Reader/Writer component performs low-level communica-
tion with the electronic control unit, and provides facili-
ties to read and write the system parameters. The Binary
Modification Subsystem updates the system’s firmware in
response to calls made to the ModAPI. These components
are model-dependent; our current implementation instanti-
ates these components for a specific car model and year (Sec-
CARMA is implemented on the Android 2.2 operating
system, and is presented to apps as an Android Background
Service. Apps communicate with the CARMA API using
Android’s native RPC system. CARMA mediates concurrent
access to the ECU, and ensures reliable reads and writes.
Like many sensor APIs, the Scanner component provides
API calls to select the “sensors” to retrieve data from, and
the frequency with which to access them. In CARMA, each
engine parameter is modeled as a distinct sensor, and apps
are provided with an abstraction of a sensing session. Apps
can call start session(pid set, frequency) to begin a
sensing session; pid set is a list of symbolic values for en-
gine parameters to be retrieved. All PIDs in thepid set are
retrieved at the specified frequency: this ensures that the
set of specified PIDs is sampled at approximately the same
time. If thefrequency is not specified, the Scanner attempts
to retrievepid set as quickly as possible (see below).
Once this function is invoked, the Scanner repeatedly re-
trieves pid set until a stop session() is called. After re-
trieving this set, the Scanner returns it asynchronously to the
application. Internally, the scanner performs format conver-
sions (the “Formula” column in Table 1). In this manner, the
Scanner abstracts both the details of the OBD-II signaling
protocol and the messaging formats for applications.
Since not all standard PIDs are supported by all manu-
facturers, the Scanner exports aget supported PIDs() call
which returns the PIDs supported on the currently connected
vehicle. Furthermore, for convenience, other sensors on the
phone are also modeled as special PIDs. For example, the
GPS sensor is modeled using three distinct PIDs, one each
for latitude, longitude, and altitude. Similarly, the clock and
the sample interval (the time required to acquire the specified
set of PIDs once) are also modeled as PIDs.
The Scanner is implemented as a service in Android
and apps create Android listeners to receive sensor readings
asynchronously. Multiple apps can concurrently access the
Scanner component. Our default ScanApp, which uses the
Scanner API, provides a user interface that lets the user se-
lect which PIDs to scan, and invokes the Scanner component.
It also stores session identification information and all scan
results in a database so that other applications can analyze
this historical data to perform customizations or to later up-
load this data to a cloud service for trend analysis.
Our Scanner implementation supports two different com-
mercially available OBD-II port adapters. The ELM327 
adapter includes built-in Bluetooth support, and abstracts
some of the details of the OBD-II signaling. A more expen-
sive alternative, the A VT adapter  requires a Bluetooth-to-
serial dongle, but essentially provides a serial link abstrac-
tion to the ECU, so the scanner must implement the OBD-II
signaling and message formats. The latter also supports tun-
ing (as described below), while the former does not. We
used the ELM327 adapter for the experiments in Section 2,
and the A VT adapter for the experiments in Section 5.
The frequency at which engine parameters can be
scanned is limited by two factors. Recall that each PID must
be individually scanned using a request-response protocol.
First, the round-trip time of each request-response can vary
significantly across manufacturers, depending on the capa-
bilities of the ECU. Second, the time to retrieve onepid set
increases linearly with the number of PIDs, since each PID
requires a separate request and response. For example, scan-
ning 10 PIDs on one of our vehicles takes 850 ms. A small
subset of manufacturers also provide a stream interface, in
which one can specify the pid set once, and the ECU re-
turns the requested set periodically. For the same 10 PIDs,
latency of retrieval is 250 ms using the stream interface.
3.4 Tuner: The Binary Reader/Writer
To our knowledge, most ECUs run a bare-minimum oper-
ating system for real-time control of engine operations, not
a general purpose operating system. As such, they do not
provide advanced facilities for updating the operating sys-
tem in-place. Instead, modifications to the ECU generally
require retrieving the entire system image including the code
and data segments, modifying the image appropriately, and
rewriting the modified system image. On our test car these
modifications can only be performed when the car is sta-
tionary, since the ECU is disabled while being programmed
and reboots afterwards. However, in some cases, aftermarket
ECUs  permit parameter tuning while the engine is oper-
ational, a capability that can increase CARMA’s potential.
While this model holds across many manufacturers, the
size and layout of the system image can vary across manu-
facturers, and even across different model years. This is be-
cause the system image depends upon the type of processor
used in the ECU and on the specific version of the operating
system, which may evolve from year to year as new engine
features are introduced.
For CARMA, it is unsafe to allow apps to modify the
entire system image directly since that can lead to unpre-
dictable vehicle behavior. Moreover, it is important to ab-
stract the process of retrieving and rewriting the system im-
age so that applications need not deal with variability across
manufacturers or model years.
At a high level, CARMA provides a transactional ab-
straction for modifying engine parameters. An app may call
prepare() to begin the process of modification. CARMA’s
ModAPI, discussed in Section 3.5, defines several API func-
tion calls to set or modify parameters. Acommit() call com-
mits all of the modifications made after theprepare() atom-
ically; applications may alsoabort() a set of modifications.
CARMA mediates access to these calls so that concurrent
modifications are serialized.
A central challenge in the design of CARMA is the im-
plementation of this API; in CARMA, the API is imple-
mented by the Binary Reader/Writer components. The meth-
ods to update the binary images on vehicles are proprietary.
As discussed before, the format of the binary image itself can
vary across manufacturers and models. A comprehensive Bi-
nary Reader/Writer implementation must, therefore, contain
model-specific implementations of these API calls.
Since our goal was to demonstrate the flexibility
and benefits of CARMA, we have implemented a Bi-
nary Reader/Writer only for a small subset of vehicles.
Specifically, CARMA currently supports about 24 different
1998/1999 General Motors models. All of these vehicles use
the same ECU
. Our Binary Reader/Writer implementation
is reverse-engineered from a commercial tuner implementa-
tion  for these models. In general, our reverse-engineering
methods employ code disassembly and packet capture.
GM Serv. No. 16236757
The implementation of prepare() loads the binary im-
age from the ECU onto memory. There are two steps in
the process: an authentication step, followed by a download
step. Before executing these steps, prepare() attempts to
acquire a lock, thereby ensuring exclusive access to the bi-
nary for modification.
The authentication step uses challenge-response: it in-
volves receiving a 2-byte seed challenge from the ECU for
which the correct 2-byte key response has to be sent back
within a bounded time. The key generation algorithm de-
pends upon the seed and an identifier for the operating sys-
tem. Although we were able to reverse-engineer this algo-
rithm, in many cases it is also possible to identify the correct
key by using brute force since the seed request always trig-
gers the same seed response in many ECU models .
In the download step, the Binary Reader/Writer first up-
loads a small bootstrap routine to the ECU. Subsequently, it
sends requests to this bootstrap routine to successively down-
load 1 Kbyte chunks of the binary image. For the ECU model
we support, the image is 512 Kbytes in size.
The implementation ofcommit() is similar, but with one
performance optimization: when writing the updated image,
we only write the 128 Kbyte data segment since the code
segment is never altered. Finally, abort() simply releases
the lock and flushes the in-memory copy of the binary image.
The Binary Reader/Writer communicates with the ECU
over Bluetooth. A Bluetooth-to-serial adapter is connected
to the A VT OBD-II adapter  ; A VT supports ECU writes,
in addition to scanning.
3.5 ModAPI and Binary Modification
At the core of CARMA lies its ModAPI, a collection
of predefined modifications (or mods). Our prototype cur-
rently supports eleven such mods, listed in Table 2. Ex-
amples of mods supported by ModAPI include: setting an
RPM limit, setting a speed limit, changing the RPM values at
which gear shifts occur, enabling exhaust gas re-circulation
(if equipped), changing the spark timings, setting the speed
at which fuel injectors are disabled, and so on. These mods
were designed in consultation with a domain expert who be-
lieves that many responsiveness, fuel efficiency, or safety im-
provements can be accomplished with these modifications.
Intuitively, the ModAPI follows a layered approach that
raises the level of abstraction relative to existing commer-
cial tuning software (Section 3.1.2): rather than exporting
low-level engine parameter settings, it encapsulates common
tuning primitives into abstract mods. The rationale for this is
similar to that for other high-level programming systems: by
capturing many common tuning primitives, CARMA aims to
support the development of rich apps that enable non-expert
users to achieve performance and fuel efficiency goals with-
out needing to understand the details of engine mechanics.
This approach also creates a separation of concerns that
increases CARMA’s safety and interoperability. The Tun-
ing subsystem, developed by specialists and car manufac-
turers, restricts sensitive and car specific functionality to the
lower layers of the system, thereby promoting safety. De-
velopers of user applications are restricted to the ModAPI,
allowing applications to be developed in a safe and vehicle
agnostic fashion. This separation of concerns can prevent
poorly-designed or malicious apps from causing damage.
Our current set of mods is by no means complete, and we
expect the ModAPI to evolve with experience. At any instant
in the evolution of ModAPI, there will always be expert users
for whom the supported mods may not suffice; these users
will need low-level access to individual engine parameters
provided by existing commercial tuning software. However,
these deeply specialized modifications, once they have been
fully tested and their impacts well understood, can then be
encapsulated as mods in the ModAPI. Indeed, this is how
the set of mods in Table 2 were obtained.
The challenge in the implementation of these modifica-
tions is in determining how to apply them to the binary im-
age. For the ECU that we have chosen, the data segment
of the binary image is a collection of over 500 different ta-
bles, each one of which governs one low-level engine pa-
rameter . The rows and columns of each table specify
the values for the parameter under different conditions. For
example, the desired RPM in idle state depends on the engine
coolant temperature (ECT) since ECT values below a certain
threshold have a negative effect on the car’s performance. To
capture this dependency, the idle RPM table specifies idle
RPM settings as a function of engine coolant temperature;
idling is set higher for lower temperatures thus increasing the
amount of heat generation and consequently the ECT value.
The complexity of the semantics of the parameters and
their dependence on other engine parameters is the reason
why it is necessary to develop a higher level of abstrac-
tion (the mod) to modify engine parameters. In general,
each mod’s implementation may modify several tables, in
a manner that is consistent with the dependency between
parameters. In practice, this dependency must be learned
from engine specifications obtained from the manufacturer,
or reverse-engineered by enthusiasts through trial and error.
Thus, ModAPI effectively encapsulates domain knowledge
in updating parameters, and provides a safe update abstrac-
tion which can be used by application developers without
complete knowledge of the intricacies of engine operation.
Each mod allows the user to set, increase, or decrease a
tuning variable (such as RPM limit, speed limit, or trans-
mission shift points). Its implementation performs bounds
checking of tuning variable values, and updates entries in one
or more tables in a consistent way. It also performs format
conversions and scaling, as necessary. All mods operate on
the current system image obtained from a call toprepare()
(Section 3.4). Mods invoked before a prepare() or after a
commit() fail. We omit a detailed discussion of the imple-
mentation of each mod for space reasons.
The current instantiation of CARMA was designed as a
proof-of-concept to demonstrate the advantages of person-
alized tuning. Much needs to happen before personalized
tuning becomes a reality. While our current implementation
is constrained by the test vehicles we had at our disposal,
we believe that CARMA can be extended to work on other
vehicles. CARMA has already been designed to be vehicle-
agnostic, so it can be extended to support other vehicles with-
out modifying applications.
The scanning subsystem follows the OBD-II standard,
but extended and enhanced PIDs are easy to add. A more
significant challenge is presented in porting the tuning ca-
pabilities to other vehicles. CARMA’s Tuner was reverse-
engineered from a proprietary implementation. In general,
this careful reverse engineering may not scale unless auto en-
thusiasts can be incentivized to contribute to an open-sourced
CARMA. Manufacturers will likely need to actively partici-
pate in the development of personalized tuning systems and
apps. There are encouraging signs that they may do this:
already some manufacturers have started providing limited
controls and access to car diagnostics using smartphone apps
(e.g., GM’s OnStar MyLink , or Fiat’s EcoDrive ).
Another challenge is to converge to the right set of mods;
this can happen only with iterative experimentation over a
wider range of models. Moreover, the safety of each mod
is an important issue. In our own development process, we
have had to be extremely careful in developing and testing
these modifications to ensure the safety of our experimenters.
We set up a test bench in our laboratory (Figure 5), which
consists of an ECU extracted from a 1998 Pontiac Grand
Prix. We used an A VT-838 adapter  to interface with the
OBD-II port. Although this setup appears to be bulky, we
believe it is possible to embed a streamlined Bluetooth-to-
OBD II port in future vehicles. We tested each modifica-
tion with a 1998 Pontiac Grand Prix Automatic belonging to
one of the authors. To minimize the risk of damaging the
test vehicle, all mods and apps were validated by comparing
the system binary generated by CARMA with one produced
manually, from the same set of changes, using a commercial
tuner . Even so, we irreversibly damaged several ECUs
while reverse-engineering the upload step.
Much more attention needs to be paid to security; as re-
cent work has shown , the internal communications in-
frastructure of modern automobiles can be relatively easily
breached, and a capability for wirelessly re-programming the
ECU can amplify potential security holes. Our current im-
plementation, being a proof-of-concept prototype, has min-
imal security provisions — password-based authentication
for Bluetooth communication, and this is clearly insufficient.
Furthermore, while our efforts have been focused mainly on
creating the programming infrastructure, it will be neces-
sary to create a developer ecosystem in the form of an app-
store. Additional safety measures could be enforced within
this ecosystem, such as application certification or manda-
tory kill-switches. Such measures would work together with
the guarantees already provided by CARMA’s layering and
API restrictions, thus minimizing the likelihood of damage
by a misguided or malicious application.
4 CARMA Apps
Using the ModAPI, we have developed several smart-
phone apps that illustrate the power and flexibility of
CARMA. These apps generally aim to achieve one or more
of the following goals. Some apps improve fuel efficiency,
which can have environmental and economic benefits. Car
manufacturers already have to meet regulatory limits on fuel
efficiency (e.g. CAFE in the United States ), which im-
poses strict design constraints. CARMA’s fuel efficiency
Name Response Economy Safety Description
DisableEGR X X Disables exhaust gas recirculation to improve performance; re-enabling opti-
mizes fuel efficiency.
EnrichMixture X X Enriches full throttle air-to-fuel ratio. When applied, increases horsepower and
torque; factory defaults optimize for fuel efficiency.
EnrichPartThrottle X X Enriches cruise and heavy throttle air-to-fuel mixture, thus increasing horsepower
and torque; factory defaults optimize for fuel efficiency to some extent.
IncreaseSparkTiming X X Increases power output by igniting the spark plugs slightly earlier; factory de-
faults are conservative and may allow for increases.
AdjustShiftDownPoints X X X Adjusts down-shift points. Raising them makes the car feel more responsive;
lowering provides greater comfort and fuel economy.
AdjustShiftUpPoints X X X Adjusts shift points. Raising them makes the car feel more responsive; lowering
provides greater comfort and fuel economy.
LimitRPM X X X Sets an RPM limit.
LimitSpeed X X X Sets a speed limit.
DecreaseShiftTime X Makes the car shift faster; factory defaults provide greater comfort.
IncreaseShiftPressure X Makes the car shift faster by increasing the shift pressure; factory defaults provide
SimulateManTransmission X Prefers lower gears, emulating a manual transmission in hilly terrain and curvy
routes; factory defaults provide greater comfort.
Table 2. ModAPI Tunable Parameters
AVT Adapter Bluetooth-to-Serial
Figure 5. CARMA test bench
apps can help make “run-time” mods towards the same goals.
These apps attempt to shape driver behavior by appropriately
setting trip-specific or driver-customized RPM and speed
limits, or transmission shift points. Other apps maximize
the car’s responsiveness, which enhances user satisfaction at
the possible expense of fuel efficiency. To achieve this, mul-
tiple parameters can be altered including an increase in shift
points, gear change speed, and speed limit. Finally, safety
apps improve overall public safety, by enforcing RPM and
speed limits. Such apps can be used to prevent rash driving
by teens or valets. The following paragraphs describe some
of these applications.
TuneWizard asks the user to qualitatively specify the
characteristics of the route, and the desired performance
goal, and automatically performs the appropriate mods.
Specifically, users can specify the type of terrain (flat, low
hills, or steep hills), the degree of congestion expected on
the route (low, medium, or high), the traffic light density
(no lights, few lights, and many lights), and the maximum
speed limit on the route. Users then select one or more of
three goals: fuel efficiency, performance, or safety; conflict-
ing goals are resolved using a static preference order among
these goals. Based on these inputs, TuneWizard applies the
recommended mods for that route and the desired perfor-
mance goals. TuneWizard’s mod choices are derived from
discussions with a domain expert.
Many of TuneWizard’s choices can be automated, using
the capability of the smartphone to access online databases.
To demonstrate this, we developed a RouteEvaluator app,
which, given a specific route, estimates the type of terrain
and the speed limit. It does this by consulting the Google
Directions API and Elevation API, which are both available
as a web service. Given the start and end points of a trip, the
web service returns a route specification as a list of polylines,
with each polyline encoding a chain of waypoints approxi-
mating the actual route. Associated with each polyline is an
estimated travel time. RouteEvaluator uses this information
to derive an approximate speed limit, the maximum grade
and the elevation gain along the route. These latter pieces of
information are used to classify the terrain. Other online ser-
vices, such as Navteq’s MapTP routing service , might
be able to provide more accurate estimates, but we have left
these to future work. Finally, RouteEvaluator is not yet in-
tegrated into TuneWizard, because we are currently explor-
ing algorithms for estimating expected congestion and traffic
light density along the route.
TheValetMode app only allows driving in the two lowest
gears and enforces an RPM limit of 2000, thus preventing
misuse of the car. The app’s name refers to well-publicized
incidents of joy riding by valets.
Finally, the DriverCustomizer app is a reflective appli-
cation that analyzes the past performance of the driver and
automatically modifies car behavior to curb aggressive driv-
ing. This app analyzes the locally stored scan results from
Interface Operation Time
Scan a PID (single) 0.085 s
Scan a PID (streamed) 0.025 s
Read a full ECU image 195 s
Write data section of an ECU image 51 s
Table 3. Processing times for basic ECU operations
previous trips (recall that our ScanApp, Section 3.3, stores
scan results in a database on the phone). It then determines
the percentage of trip time for which a driver’s throttle po-
sition was over a certain preset limit (40% for our test car).
If this percentage exceeds 5%, the driver is deemed aggres-
sive (Figure 3) and an RPM cutoff limit of 3000 is applied
if the user intends to drive on a flat terrain. Actively curbing
aggression can reduce fuel consumption and relieve engine
stress. More sophisticated analytics are possible, but we have
left these to future work.
In this section, we quantify, through experiments on our
CARMA prototype, several features of CARMA. All our
experiments on CARMA are conducted on a 1998 Pon-
tiac Grand Prix, one of the models supported by our Tuner.
Specifically, our experiments demonstrate:
that CARMA has relatively low overhead, and provides
a high enough level of abstraction to support flexible
personalized tuning apps,
that personalized tuning can provide significant fuel ef-
ficiency benefits, and
that CARMA is expressive enough to design apps that
promote safety or improve a car’s responsiveness, an-
alyze driver behavior to curb aggressiveness, and sim-
plify per-trip tuning through automation.
We conclude this section with a discussion of the implica-
tions of our results.
5.1 CARMA Microbenchmarks
In this section, we quantify some aspects of CARMA
performance, and the ease of app development in CARMA.
Table 3 summarizes the execution times for basic ECU op-
erations used by the Scanner and Tuner. The high values
for reading or writing an ECU image are mainly a result of
bandwidth limitations of the connection between the tool and
the ECU. In our test environment we used the SAE J1850
VPW protocol which supports a bandwidth of 10.4 kbps in
standard mode and 41.6 kbps in high speed mode (see SAE
J2534 ). In our experiments, we are actually able to
achieve the nominal four-fold speed-up of the high speed
mode, so we believe that these times can be reduced by more
than an order of magnitude in newer cars equipped with the
new ISO 15765-4 (CAN) bus which provides a bandwidth of
up to 500 kbps .
Table 4 shows the size of the CARMA implementation,
broken down by component and measured in lines of code
(LOC). This table gives a rough measure of the complexity
of the various subsystems. The Scanner, ModAPI and OBD-
II logic change little across multiple ECU models, but the
Component LOC (w/ UI)
OBD-II Logic 894
Scanner API 550
Binary Reader/Writer 411
Binary Mod. Subsystem 579
ScanApp 98 (453)
TuneWizard 214 (462)
ValetMode 60 (214)
DriverCustomizer 76 (234)
Table 4. Implementation code size of CARMA compo-
nents and sample applications. The numbers in paren-
theses denote total lines-of-code values including UI logic.
Binary Reader/Writer and the Binary Modification Subsys-
tem need to implement ECU-specific functions.
Our apps are fairly concise, requiring between 60 and
400 lines of code, not including user interface code. The
largest app,RouteEvaluator, calculates terrain characteristics
and speed limits; the smallest, ValetMode, simply invokes a
few static mods. These numbers are encouraging, and sug-
gest that CARMA’s choice of abstractions are at a reason-
able level. Additional app development is necessary to gain
more confidence in our assessment, and we leave this to fu-
5.2 The Benefits of Personalized Tuning
CARMA was motivated by personalized tuning, the ca-
pability to tune a car at the granularity of a single trip. In
this section, we quantify the benefits of personalized tuning
by conducting experiments on a variety of traffic conditions
All our experiments were conducted on a 1998 Pontiac
Grand Prix belonging to one of the authors. In Section 2, we
used two other car models (mainly for ease of experimenta-
tion) to motivate CARMA; these models are not supported
by our Tuner. Our test car also shows variability with route,
terrain and traffic conditions (Section 2), as discussed below.
Our experiments are conducted on several trips, each
with qualitatively different characteristics. The trips covered
different types of routes, levels of congestion, traffic light
density, and terrain. Each trip is unidirectional from a fixed
starting point to a fixed end point. The trips and their char-
acteristics are summarized in Table 5.
For each trip, we conducted two runs: a baseline run on
the test car without any modifications, and a mod run which
uses a fuel efficiency modification suggested byTuneWizard.
Recall that TuneWizard takes as input the characteristics of
a route and automatically suggests the appropriate modifica-
tions. On a subset of these trips, we conducted baseline and
mod runs with additional drivers to quantify the impact of
driver behavior. All in all, our experiments logged over 1100
Trip 4a and 4b share the same route but exhibit different con-
Trip Road Type Distance Speed Limit Elevation Gain Max. Grade Congestion Signal Density
1 County Route 8.3 mi 30 - 50 mph 761 ft 9% low low
2 State Highway 11.0 mi 45 - 55 mph 906 ft 2% medium medium
3 Interstate 15.2 mi 55 mph 151 ft < 1% low none
4a State Highway 8.5 mi 40 - 50 mph 98 ft < 1% none medium
4b State Highway 8.5 mi 40 - 50 mph 98 ft < 1% heavy medium
Table 5. Characteristics of Trips
Trip Speed Limit RPM Limit
1 50 3300
2 55 3000
3 55 2600
4a 50 2700
4b 50 2100
Table 6. Parameters for the LimitSpeed and
LimitRPM mods employed on test trips
miles. Moreover, during each trip we continuously measured
13 PIDs using our ScanApp at a frequency of 4 Hz.
Our metric of performance is the improvement in fuel
economy of the mod run over the baseline run. The fuel
economy on a trip is measured using the scan data as dis-
cussed in Appendix A.
Each of our trips uses a public thoroughfare along which
it is difficult to conduct a controlled experiment. We were
careful to conduct the baseline and mod runs at the same
time of day, and under similar temperature and humidity
(since these can affect engine air intake). Furthermore, all
our trips are at least 20 min long, so that initial and final tran-
sients have minimal effect, and minor variability evens out.
We discarded runs of the experiment where the experimenter
noticed significant differences in traffic conditions (e.g., con-
gestion) between the baseline and the mod run. To measure
the variability across multiple runs, we repeated the baseline
run for one of our trips 3 times and found that the mean de-
viation in fuel economy across those three runs was less than
1.54%. As we show below, our fuel economy improvements
are well above this variability.
Finally, the experimenters were aware of the possibility
of bias skewing the results and were instructed to drive nor-
mally. Also, our tests are conducted on only one vehicle.
Conducting blind trials to remove bias or testing on other ve-
hicles has insurance and legal implications that extend well
beyond the scope of this work.
For each of our trips, TuneWizard suggested the mods
shown in Table 6. As discussed earlier, this app encapsu-
lates domain expertise and suggests modifications based on
the characteristics of the route chosen. All of these mods
limit both the speed and the RPM based on the trip’s charac-
teristics. For example, trip 1 is over hilly terrain with steep
grades which may require higher RPM to surmount. Simi-
larly, trip 4b in rush-hour traffic on a relatively flat route can
be navigated using a much lower RPM limit.
Figure 6 plots the fuel efficiency for the baseline and the
mod runs across each of our trips. First, observe that there
18.4 (+4.4%) 18.4 (+4.4%)
22.2 (+12.8%) 22.2 (+12.8%)
24.4 (+11.1%) 24.4 (+11.1%)
23.1 (+13.7%) 23.1 (+13.7%)
16.7 (+13.3%) 16.7 (+13.3%)
Figure 6. Fuel economy comparison for different trips
is significant variability in baseline fuel economy across the
different trips. This is qualitatively consistent with results
presented, using other makes and models, in Section 2.
More important, the mod run’s fuel economy was at least
10% higher than that of the baseline run for a majority of
trips. This is a significant improvement, especially consider-
ing that manufacturers engineer their cars for fuel efficiency
to comply with fuel economy standards. It is also the cen-
tral result of our paper, suggesting that personalized tuning
may have significant economic benefits. The U.S. Bureau of
Transportation Statistics  estimates that the annual fuel
consumption of passenger cars is about 70 billion gallons.
A 10% increase in fuel economy would save approximately
6.3 billion gallons, reducing fuel costs by over $19 billion
per year and significantly reducing carbon emissions.
To understand the reasons for fuel economy improve-
ments, we present a more detailed analysis of the scan data
obtained from the experiments. Specifically, we focus on
the results of the experiments on trip 3 and 4b since each of
them illustrates a qualitatively different reason for fuel econ-
omy gains. On other trips, fuel economy gains are achieved
through a combination of these two factors, and we omit a
detailed analysis of these trips for space reasons.
As Table 6 shows, we enforce a speed limit of 55 mph
on the mod run on trip 3, a high-speed interstate highway
with little congestion. As a result, the average and maximum
speed observed during the mod run drops significantly on
this trip, as shown in Figure 7.
On this graph, the baseline run has fewer data points
since the driver reaches the destination earlier. Fuel effi-
ciency gains are obtained in this scenario through two means.
First, an enforced speed limit leads to a smoother speed curve
especially on a decongested highway, since the driver is un-
likely to encounter a slower car, thereby avoiding extra de-
celeration and unnecessary propulsive work, resulting in im-
proving fuel efficiency . Second, lower speeds are more
0 200 400 600 800 1000 1200
Figure 7. Speed on trip 3
1000 1500 2000 2500 3000 3500 4000
Figure 8. RPM CDF on trip 4b
Trip 1 Trip 2
Relative difference to baseline (%)
Figure 9. Fuel economy variability with
driver on trips 1 and 2
fuel efficient than higher speeds : the Transportation En-
ergy Data Book  reports an average fuel economy loss of
17:1% when driving at a speed of 70 mph instead of 55 mph.
Some of these fuel efficiency gains can be obtained through
driver education; we discuss this in Section 5.4.
However a reduction of the speed is not the only reason
for a better fuel economy. To see this, we turn to an analy-
sis of the experiments for trip 4b. Since these experiments
were conducted during rush hour, our speed limit was rarely
reached; instead, congestion induced frequent stop-and-go
behavior. On this trip, the RPM limit contributes to improved
fuel economy, by preventing spikes in RPM (caused by fre-
quent starting and stopping), or short bursts of high RPM
values caused by frequently pushing the throttle by a large
extent. Figure 8 shows the relative RPM frequencies for the
baseline and the mod run. The distribution of RPM is clearly
different for the mod run compared to the baseline run. In
general, substantially more fuel is consumed at high RPM
values. By preventing these situations we were able to im-
prove the fuel efficiency by 13.7% for this trip.
Finally, we demonstrate that the relative improvements
in fuel economy can vary significantly for different drivers
in Figure 9. As the figure shows, for trip 1, one of the drivers
exhibits slightly higher improvements in fuel efficiency than
the other, but for trip 2 the roles are reversed and the dif-
ferences are much more significant. These differences arise
from variations in driving habits. CARMA attempts to im-
pose a specific driver behavior with its RPM and speed lim-
its. On some types of roads, one of our drivers may already
closely match the targeted behavior (e.g., driving steadily on
a highway) while the other may not, resulting in a higher
potential for fuel efficiency gains in the latter case.
5.3 The Expressivity of CARMA
CARMA has uses beyond improving fuel efficiency.
It can be used to increase responsiveness of a car. On
each of our trips, we also conducted a responsiveness mod
run in addition to the runs discussed above. TuneWizard in-
creases responsiveness by changing gear shift timings and
transmission shift points. This has the effect of staying at a
lower gear until higher RPM values than normal, and shift-
ing gears more quickly than normal. On terrain with fre-
quent turns, these changes can make the car feel much more
responsive. These changes, especially the gear shift timings,
occur at finer time scales than supported by the scanning pro-
tocol our test vehicle uses, so we cannot quantify them; with
the faster CAN protocol (found in newer cars) , they may
be visible. However, one of our additional drivers (not an
author of the paper) reported a perceived increase in respon-
siveness, and enjoyed being able to drive more aggressively.
We have left to future work a user study that validates re-
CARMA can also promote safety. ValetMode limits
the maximum RPM and prevents the car from shifting into
higher gears thus implicitly enforcing a speed limit.
demonstrate this app, we ran an experiment where the driver
was asked to maintain a constant throttle position on a car to
which ValetMode had been applied. Figure 10 illustrates the
behavior of ValetMode, and plots the RPM distribution dur-
ing a test run as a function of time. Ordinarily, at a constant
throttle position, the car should continuously accelerate and
increase the revolution frequency. As the figure shows, the
car’s RPM value drops once the limit is reached (a bounc-
ing effect), demonstrating the impact of the RPM limiter. A
similar behavior is observed for speed since the car cannot
accelerate once a certain speed is reached with the gear and
RPM limiter in force.
CARMA can also be used to design reflective applica-
tions that analyze driver behavior and tune engine param-
eters based on this analysis. DriverCustomizer (Section 4)
curbs aggressive driving by establishing an RPM limit for
drivers who exceed a fixed throttle position relatively fre-
quently. Figure 11 shows the results from an experiment
in which a driver was asked to drive aggressively. Without
the curbs, the driver produces spikes in the RPM using high
throttle positions. When the curbs are in place, the ECU
cuts fuel to the engine when the RPM limit is reached even
at high throttle position: this prevents excessive acceleration
and fuel consumption. In this experiment, the DriverCus-
tomizer app improved fuel economy by 24%. As shown in
Figure 11 no high throttle position values were observed dur-
ing the modified run. With the mods, when the driver tries to
depress the throttle, the ECU cuts off fuel to the engine be-
yond the RPM limit. At that point, the open throttle causes
engine vibrations leading the driver to ease the throttle.
The LimitSpeed mod does not apply to this scenario since
speed limits are not enforced below a certain threshold.
0 10 20 30 40
Figure 10. RPM time series forValetMode
1000 2000 3000 4000 5000 6000
Throttle Position (%)
Figure 11. RPM vs. Throttle Position for the
Route Max. Grade (est./real) Speed Limit (est./real)
1 8% / 9% 40 mph / 50 mph
2 3% / 2% 55 mph / 55 mph
3 0:6% / < 1% 70 mph / 55 mph
4 0:6% / < 1% 65 mph / 50 mph
Table 7. Comparison of the RouteEvaluator estimations
with the real values
Finally, CARMA’s programmability and Internet con-
nectivity can be used to simplify the process of tuning. Cur-
rently, TuneWizard requires the user to manually specify
the characteristics of the route. Instead, our RouteEvalua-
tor can calculate many of these characteristics using online
databases and can eventually be integrated with a navigation
application, requiring the user to only input start and end
points. Table 7 shows preliminary results for the RouteE-
valuator: its classification of the maximum grade on a route
matches that of a human classifying the route from memory,
while the estimation of the maximum speed deviates from
the posted maximum. This deviation results from our esti-
mation of speed limits from Google Maps’ travel times; us-
ing a web service which provides explicit speed limits such
as Navteq’s MapTP Service  can give better estimates.
5.4 Summary and Discussion
Across a wide variety of driving conditions, CARMA’s
personalized tuning can often achieve more than 10% in fuel
efficiency gains. Even small gains in fuel economy can have
significant economic and social consequences. CARMA
also enables the development of responsiveness and safety-
oriented apps, as well as those that customize car behav-
ior based on driver behavior, or those that perform complex
route calculations to automate the process of tuning.
Our test car had hardware after-market performance
modifications done on it. One consequence was a lower fuel
economy at low RPM values compared to an unmodified car:
for example, our test car would only achieve 35 mpg instead
of the 40 mpg in an unmodified car. Thus, our results likely
underestimate the gains achievable in unmodified cars.
CARMA’s personalized tuning capability effectively
shapes driver behavior by changing the way the engine per-
forms. Some of its benefits, such as fuel efficiency, could
have been achieved with driver education (e.g., the eco-
driving [9, 38] movement). While education can certainly
help, CARMA can be an additional tool for ensuring so-
cially responsible driving. With CARMA’s mods, drivers do
not have to consciously practice responsible driving and may
not need to change their driving habits at all. Exploring this
trade-off is beyond the scope of this paper.
The RPM and speed cutoff limits in TuneWizard were
suggested by our domain expert. These RPM limits were set
generously to allow drivers to accelerate for safety reasons,
such as when entering an interstate highway. Other safety
concerns, such as an investigation of possible negative ef-
fects of using CARMA’s apps, safe though they may be, on a
vehicle’s lifetime, is left to future work. That said, we believe
the risk of effects on lifetime to be negligible since car enthu-
siasts and fleet operators have been performing such mods
for quite some time and with far more aggressive settings
than what we allow. Moreover, many of the mods CARMA
allows, such as the RPM and speed limiters, have no fore-
seeable side effects and simply enforce the kinds of behavior
drivers may use under certain circumstances.
The emergence of hybrids does not diminish the im-
portance of CARMA. Extrinsic variability in the form of
driver behavior is a crucial factor determining the fuel ef-
ficiency gains with hybrids. To ensure the regenerative brak-
ing, drivers must drive hybrids differently than they would
normal cars . Personalized tuning of hybrids to enforce
some of these “hyper-miling” tricks on appropriate route seg-
ments can improve the achieved fuel efficiency. Whether
personalized tuning can improve the energy efficiency of
electric vehicles is an open question.
Eventually, a much finer grained form of personalized
tuning, where the car continually adapts, in real-time, to
driver behavior and changes in route characteristics, can pro-
vide significant gains. This Utopian vision might be achiev-
able with relatively modest ECU re-engineering, together
with sophisticated on-board diagnostics and analytics.
Figure 12. CARMA and related work
6 Related Work
CARMA is, to our knowledge, the first platform that pro-
vides high-level interfaces for scanning and tuning a vehicle,
thereby enabling the development of applications on smart-
phones for vehicle sensing, analysis and control. Figure 12
puts CARMA in the context of some of the prior work in this
area, which we discuss below.
With OBD-II standardization, scanning software and sys-
tems are widely available. For example, users of Android
smartphones can find apps that work with the ELM327
adapter. One such app is Torque , which allows users
to view OBD-II scan data in real-time or to log it for offline
analysis. Unlike these apps, CARMA supports tuning in ad-
dition to scanning.
Car manufacturers are also seeing the value in providing
such services to their customers. Two such systems, General
Motors OnStar  and MyFord Touch , have incorpo-
rated some forms of vehicle diagnostics and monitoring, al-
lowing users to visualize scan data on the car’s dash-board
or on a smartphone. Fiat’s eco:Drive  service provides
feedback to drivers on their driving habits and provides tips
on how to increase their fuel efficiency. None of these sys-
tems support personalized tuning.
Scanners have also been used in such projects as Car-
Tel  and GreenGPS . The CarTel project focuses on
the networking and query abstraction challenges in mobile
vehicular environments. The GreenGPS project analyzes ve-
hicle sensor data to obtain fuel efficiency metrics. This data
is then geotagged and crowd-sourced to create a database of
“green” routes that can be queried. CARMA goes a step fur-
ther: beyond sensing and data analysis, it enables tuning to
achieve fuel efficiency or other goals.
There is a smaller body of work on tuning. Several
companies offer customized tuners, which either replace the
ECU entirely  or are hardware add-ons with limited per-
sonalization capabilities . Some cars, like the Cadillac
CTS , support performance modes, selectable on the dash-
board, which modify gear shift points in order to emulate a
more sporty handling behavior. These tools do add a small
level of customization, but do not offer the same flexibil-
ity as CARMA as they reduce the user’s choice to a limited
set of modes. Complementary to CARMA are methods that
attempt to adapt automatically to user driving habits, with-
out any user intervention [36, 20]. These approaches get
closer to CARMA’s goal of driver-specific tuning, but lack
the broader programmability that CARMA permits.
The complexity and inherent risk involved in tuning has
led to few software tuners, and these are targeted towards
mechanics and car enthusiasts. The proprietary DHP Powr-
Tuner  and the open-source RomRaider  offer a full
tuning suite, allowing one to download a vehicle’s binary
image, modify tables using a UI, and upload it back to the
ECU all within a single program. Unlike CARMA, they have
been developed for a PC platform, and lack programmabil-
ity; however, we have used the PowrTuner in the develop-
ment and validation of our tuning subsystem. Another tool,
Tiny Tuner , only supports off-line modifications to ta-
bles in binary image files (unlike CARMA which also trans-
fers and installs images). Because it is open-source, Tiny
Tuner was helpful in developing our ModAPI. Finally, re-
cent work  has exposed the security risks inherent in car
modification. As we have discussed in Section 3.6, mecha-
nisms to secure modification are necessary before personal-
ized tuning becomes a reality. Autoplug  is an emulator
for ECU code updates that would enable off-line testing of
mods for safety.
In this paper we described CARMA, a smartphone-based
system that provides high-level abstractions for safe auto-
motive sensing and control. Such a system can enable an
application ecosystem for innovative car tuning apps; we
have illustrated this potential by developing several proof-of-
concept applications which allow users to customize their ve-
hicle for specific routes, increase fuel efficiency and respon-
siveness, or even limit the vehicle’s abilities to prevent rash
driving. Through experiments on our prototype we show that
our apps do, in fact, achieve their desired effect, and that
driver and route specific personalization can, in most cases,
achieve more than 10% improvement in fuel economy.
Much work remains. For CARMA to be useful to a
broader audience, further work is needed to support tuning
on a wider range of car makes and models. Additionally,
even though we have already demonstrated simple apps that
analyze scanned data and react to modify vehicle behavior
accordingly, improved data analysis and modeling could be
developed to better shape driver behavior. Applications like
the RouteEvaluator can be expanded to estimate other route
characteristics such as congestion and traffic light density;
ideally, the user should be able to just specify a route using a
navigation application and the system should consult online
databases to automatically and accurately derive all of the
route-relevant features. Usability studies are needed to quan-
tify the effects of response mods. Finally, for the CARMA
vision to become reality, app development must drive the it-
erative improvement of ModAPI abstractions to find a level
that best balances the complexity-flexibility trade-off.
Ben Gertner and Hilda Aldana worked on initial feasi-
bility studies. Timothy Riesz and Michele Trendler helped
as additional drivers of the test vehicle during evaluation.
Michael Riley from Advanced Vehicle Technologies, Inc.
helped us understand the ECU communication. Our shep-
herd, Cormac Sreenan, and the anonymous reviewers pro-
vided insightful suggestions on improving the technical con-
tent and presentation of the paper. We thank them all.
 2011 Dodge Grand Caravan Owner Manual. http://www.
 2011 Infiniti M Hybrid Specifications. www.infinitiusa.
 Advanced Vehicle Technologies. http://www.avt-hq.
 A’PEXi Power FC ECU. http://www.apexi-usa.com/
 Cadillac CTS Owners Manual. http://www.cadillac.
 Corporate average fuel economy (CAFE). http://www.
 DHP PowrTuner. http://www.powrtuner.com/.
 DiabloSport: Gas and Diesel Tuning Systems. http://www.
 ECOWILL. http://www.ecodrive.org/.
 ELM327 OBD to RS232 Interpreter. www.elmelectronics.
 European Emission Standards Directive 98/69/EC.
 Fiat eco:Drive. http://www.fiat.co.uk/ecodrive/.
 Fuel Consumption by Mode of Transportation in Physical
 General Motors OnStar. http://www.onstar.com/.
 HP Tuners. http://www.hptuners.com/.
 MyFord Touch. http://www.ford.com/technology/
 NA VTEQ MapTP routing service: Calculating routes
with detailed route descriptions. http://www.nn4d.
 OBD GPS Logger. http://icculus.org/obdgpslogger/.
 RomRaider. http://www.romraider.com/.
 Smart App Design . http://www.google.com/events/io/
 Tiny Tuner. http://tinytuner.sourceforge.net/.
 Torque: Engine Performance and Diagnostic Tool for Auto-
motive Professionals and Enthusiasts. http://torque-bhp.
 ZZ Performance. http://www.zzperformance.com/.
 Fuel Economy Guide. U.S. Department of Energy, 2011.
 N. Chapnick. Hypermiling: Quest for Ultimate Fuel
html, May 2007.
 S. Checkoway, D. McCoy, B. Kantor, D. Anderson,
H. Shacham, S. Savage, K. Koscher, A. Czeskis, F. Roesner,
and T. Kohno. Comprehensive Experimental Analyses of Au-
tomotive Attack Surfaces. In Proceedings of the 2011 Usenix
 S. C. Davis, S. W. Diegel, and R. G. Boundy. Transporta-
tion Energy Data Book. Oakridge National Laboratory, 29th
 S. Dawson-Haggerty, J. Ortiz, X. Jiang, J. Hsu, S. Shankar,
and D. Culler. Enabling Green Building Applications. In
6th Workshop on Hot Topics in Embedded Networked Sen-
sors, HotEmnets ’10, 2010.
 U. Drolia, Z. Wang, Y . Pant, and R. Mangharam. AutoPlug:
An Automotive Test-bed for Electronic Controller Unit Test-
ing and Verification. In 14th Int. IEEE Conference on Intelli-
gent Transportation Systems, 2011, ITSC. IEEE, 2011.
 R. K. Ganti, N. Pham, H. Ahmadi, S. Nangia, and T. F. Ab-
delzaher. GreenGPS: a participatory sensing fuel-efficient
maps application. In Proceedings of the 8th international con-
ference on Mobile systems, applications, and services, Mo-
biSys ’10, pages 151–164, New York, NY , USA, 2010. ACM.
 B. Georgi, S. Hunkert, J. Liang, and M. Willmann. Realizing
Future Trends in Diesel Engine Development (SAE Paper No.
 B. Hull, V . Bychkovsky, Y . Zhang, K. Chen, M. Goraczko,
A. Miu, E. Shih, H. Balakrishnan, and S. Madden. CarTel: a
distributed mobile sensor computing system. In Proceedings
of the 4th international conference on Embedded networked
sensor systems, SenSys ’06, pages 125–138, New York, NY ,
USA, 2006. ACM.
 International Organization for Standardization. Road vehicles
- Diagnostics on Controller Area Networks (CAN) - Part 4:
Requirements for emissions-related systems, 2011.
 B. D. Lightner. A VR-Based Fuel Consumption Gauge. Circuit
Cellar, (183):59–67, 2005.
 H. Lu, W. Pan, N. D. Lane, T. Choudhury, and A. T. Camp-
bell. SoundSense: scalable sound sensing for people-centric
applications on mobile phones. In Proceedings of the 7th in-
ternational conference on Mobile systems, applications, and
services, MobiSys ’09, pages 165–178, New York, NY , USA,
 A. Malikopoulos, P. Papalambros, and D. Assanis. A
Learning Algorithm For Optimal Internal Combustion En-
gine Calibration in Real Time. In Proceedings of the ASME
2007 International Design Engineering Technical Confer-
ences and Computers and Information in Engineering Con-
ference, IDETC/CIE 2007. ASME, 2007.
 M. Mun, S. Reddy, K. Shilton, N. Yau, J. Burke, D. Estrin,
M. Hansen, E. Howard, R. West, and P. Boda. PEIR, the per-
sonal environmental impact report, as a platform for partici-
patory sensing systems research. In Proceedings of the 7th in-
ternational conference on Mobile systems, applications, and
services, MobiSys ’09, pages 55–68, New York, NY , USA,
 Y . Saboohi and H. Farzaneh. Model for developing an eco-
driving strategy of a passenger vehicle based on the least fuel
consumption. Applied Energy, 86(10):1925–1932, 2009.
 A. B. Schwarzkopf and R. B. Leipnik. Control of highway
vehicles for minimum fuel consumption over varying terrain.
Transportation Research, 11(4):279–286, 1977.
 Society of Automotive Engineers. E/E Diagnostic Test Modes
 Society of Automotive Engineers. Recommended Practice for
Pass-Thru Vehicle Programming (J2534/1), 2010.
 J. Taneja, D. Culler, and P. Dutta. Towards Cooperative Grids:
Sensor/Actuator Networks for Promoting Renewables. In
Proceedings of the First IEEE International Conference on
Smart Grid Communications, SmartGridComm ’10, Wash-
ington, DC, USA, October 2010. IEEE Computer Society.
 United States Congress. Clean Air Act. http://www.epa.
A Measuring Fuel Economy
We used a variety of cars for our experiments (1998 Pon-
tiac Grand Prix GTP, 1998 Toyota Corolla and 2011 Ford Fi-
esta) which support different sets of PIDs. Depending on the
PIDs available on these cars, we use two different formulas
for computing instantaneous fuel consumption (IFC).
The first formula uses the measured mass air flow (MAF)
and scan cycle duration (DUR) to compute the fuel consump-
tion. It also uses two additional parameters, air-to-fuel ra-
tio (AFR) and fuel density (DEN), which remained constant
throughout all experiments. The air-to-fuel ratio has a chem-
ically optimal value of 14.7 (14.7 grams of air are consumed
per gram of fuel) and the engine constantly tries to maintain
this ratio. The fuel density depends on the gasoline type used
which was fixed as well .
The second formula uses the measured injector pulse
width (IPW), revolutions per minute (RPM) and scan cycle
duration (DUR) to compute the fuel consumption. For this
computation, we need the number of cylinders (CYL), the
fuel flow rate (FFR) and the fuel density (DEN) as additional
CY L RPM IPW FFR DUR
Using these formulas, we calculate the fuel consumption for
each scan cycle, then divide the total distance traveled by the
fuel consumption to obtain our fuel economy measure.
Abstract (if available)
Computer Science Technical Report Archive
USC Computer Science Technical Reports, no. 961 (2015)
USC Computer Science Technical Reports, no. 944 (2014)
USC Computer Science Technical Reports, no. 931 (2012)
USC Computer Science Technical Reports, no. 773 (2002)
USC Computer Science Technical Reports, no. 774 (2002)
USC Computer Science Technical Reports, no. 949 (2014)
USC Computer Science Technical Reports, no. 782 (2003)
USC Computer Science Technical Reports, no. 934 (2013)
USC Computer Science Technical Reports, no. 796 (2003)
USC Computer Science Technical Reports, no. 760 (2002)
USC Computer Science Technical Reports, no. 905 (2009)
USC Computer Science Technical Reports, no. 677 (1998)
USC Computer Science Technical Reports, no. 848 (2005)
USC Computer Science Technical Reports, no. 697 (1999)
USC Computer Science Technical Reports, no. 732 (2000)
USC Computer Science Technical Reports, no. 751 (2001)
USC Computer Science Technical Reports, no. 915 (2010)
USC Computer Science Technical Reports, no. 839 (2004)
USC Computer Science Technical Reports, no. 914 (2010)
USC Computer Science Technical Reports, no. 797 (2003)
Tobias Flach, Nilesh Mishra, Luis Pedrosa, Christopher Riesz, Ramesh Govindan. "CarMA: Towards personalized automotive tuning." Computer Science Technical Reports (Los Angeles, California, USA: University of Southern California. Department of Computer Science) no. 921 (2011).
USC Computer Science Technical Reports, no. 921 (2011)
CarMA: Towards personalized automotive tuning (
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA
11-921 CarMA Towards Personalized Automotive Tuning (filename)
15 pages (extent),technical reports (aat)
Internet Media Type
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/
Computer Science Technical Report Archive
University of Southern California. Department of Computer Science. Technical Reports
The author(s) retain rights to their work according to U.S. copyright law. Electronic access is being provided by the USC Libraries, but does not grant the reader permission to use the work if the desired use is covered by copyright. It is the author, as rights holder, who must provide use permission if such use is covered by copyright.
USC Viterbi School of Engineering Department of Computer Science
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Computer Science Technical Report Archive
1991 to 2017
USC Viterbi School of Engineering Department of Computer Science
Department of Computer Science. USC Viterbi School of Engineering. Los Angeles\, CA\, 90089
Department of Computer Science,USC Viterbi School of Engineering, University of Southern California, 3650 McClintock Avenue, Los Angeles, California, 90089, USA (publisher)
In copyright - Non-commercial use permitted (https://rightsstatements.org/vocab/InC-NC/1.0/