Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 77
The Car and the Cloud
Automotive Architectures for 2020
Rahul Mangharam
University of Pennsylvania
Over the past two decades, automobile journey durations have doubled.
Further ore, travelers increasingly use their vehicle as a mobile office, meeting
m
room, and even living room. With this evolution, informational and entertain-
ment needs in the vehicle now transcend mechanical, electronic, and software
b
oundaries to include services for the driver, passengers, and the vehicle itself.
Three trends are emerging in drivers’ expectations for their vehicle: (1) con-
tinuous connectivity with both the infrastructure (e.g., smart traffic intersections)
and other commuters, (2) enhanced levels of productivity and entertainment for
the duration of travel, and (3) reduction in cognitive load through semiautonomous
operation and automated congestion-aware route planning. To address these
demands, vehicles should become more programmable so that almost every
aspect of engine control, cabin comfort, connectivity, navigation, and safety will
be remotely upgradable and designed to evolve over the lifetime of the vehicle.
Progress toward the vehicle of the future will entail new approaches in the
design and sustainability of vehicles so that they are connected to networked traf-
fic systems and are programmable over the course of their lifetime. To that end,
our automotive research team at the University of Pennsylvania is developing an
in-vehicle programmable system, AutoPlug, an automotive architecture for remote
diagnostics, testing, and code updates for dispatch from a datacenter to vehicle
electronic controller units. For connected vehicles, we are implementing a net-
worked vehicle platform, GrooveNet, that allows communication between real and
simulated vehicles to evaluate the feasibility and application of vehicle-to-vehicle
(V2V) and vehicle-to-infrastructure (V2I) communication; the focus in this paper
is on its application to safety. Finally, we are working on a tool for large-scale traf-
fic congestion analysis, AutoMatrix, capable of simulating more than 16 million
77
OCR for page 78
78 FRONTIERS OF ENGINEERING
vehicles on any US street map and computing real-time fastest paths for a large
subset of vehicles. The tools and platforms described here are free and open source
from the author.
PROGRAMMABLE VEHICLES
Vehicles today are built in long design cycles and with electronic architectures
that are static in both form and function. Technology adoption is considered only
at the beginning of the design cycle, frozen for the lifetime of ownership of the
vehicle (~12 years1), and often obsolete within 6 years.2,3 In contrast, the vehicle
of the future will be programmable with services for the long-term health and
performance of both humans and vehicles.
Electronics and software for engine and cabin controls currently account for
over 30% of the cost of an automobile, and this figure is expected to grow as vehicles
evolve from mechanical to electronic to software-controlled to service-based mobile
cyber-physical system (CPS) platforms. As new automotive electronic architectures
are developed to enable remote diagnosis and reprogrammability throughout the life
of the vehicle, drivers will be able to choose from a software component marketplace
to enhance the safety, performance, and comfort of their vehicle.
Ensuring the safe and correct programming of the new service features is
paramount. Automotive plug-and-play devices that communicate to and from the
vehicle will allow new classes of services and customization such as online vehicle
diagnostics, warranty management, networked infotainment, and integration of
applications such as driver behavior and vehicle performance measurements for
personalized insurance services.
CONNECTED VEHICLES
Every year, approximately 6.4 million car accidents occur in the United
States, typically involving three people (two drivers and one passenger). That
translates to roughly 19.2 million Americans injured in car accidents each year,
or odds of 1:16 for every individual. Several sources4 estimate that over 90% of
vehicle crashes are due to driver negligence and therefore avoidable (Duri´c and
Miladinov-Mikov 2008).
1
Polk.com. 2012. Average age of vehicles reaches record high, January 17. Available online at
http://goo.gl/TN5Ow.
2 S DOE Office of Energy Efficiency and Renewable Energy, Vehicle Technologies Program.
U
2010. Average Length of Light Vehicle Ownership, May 10. Available online at www1.eere.energy.
gov/vehiclesandfuels/facts/2010_fotw622.html.
3Polk.com. 2012. Americans are keeping new vehicles an average of nearly six years, February 22.
Available online at http://goo.gl/7R3N3.
4See, for example, The Economist. Look, no hands: Automotive technology: Driverless cars promise
to reduce road accidents, ease congestion and revolutionise transport, September 1. Available online
at www.economist.com/node/21560989.
OCR for page 79
THE CAR AND THE CLOUD 79
A vehicle’s “safety bubble” is currently limited to its physical body, with inte-
grated crash and proximity sensors (e.g., ultrasonic, LiDAR, radar). In the vehicle
of the future, V2V and V2I wireless communication is expected to enhance safety.
Such communication technology, when interfaced with the vehicle’s powerrain t
and using audio and haptic feedback, will be able to issue safety alerts to all
approaching vehicles during events such as sudden braking, loss of traction, or
airbag deployment. Early warning messages communicated down the highway in
a timely “multi-hop” manner (i.e., from one vehicle to another in a few hundred
milliseconds) will allow for longer reaction and stopping time and thus prevent
a pile-up.
Connected vehicle architectures for such safety-critical automotive systems
require much work to ensure security and privacy together with the timely delivery
of traffic alerts, warnings, and information updates.
NETWORKED TRAFFIC SYSTEMS
Delays due to traffic congestion cost Americans $78 billion in the form of
4.2 billion lost hours and 2.9 billion gallons of wasted fuel, and 35–55% of these
delays are caused by point-based traffic incidents rather than recurring congestion.
As the density of vehicles increases, there is a need for large-scale traffic conges-
tion management such that real-time “eco-routing” can be provided to prevent,
avoid, and alleviate traffic back-ups. Models and tools for nationwide traffic
congestion management, with networked streaming vehicle data, are required to
compute the fastest and most eco-friendly routes without new infrastructure costs.
In the Real-Time Systems Lab at Penn, we are investigating the design of
such a platform to enable the scaling of traffic network operations to handle data
processing for millions of vehicles, estimate and predict congestion, and facili-
tate route assignment as well as to model traffic operations and disaster response
during congestion.
IN-VEHICLE SYSTEMS: REMOTE DIAGNOSTICS,
TESTING, AND REPROGRAMMING
More than 20.3 million vehicles were recalled in 2010, many because of soft-
ware issues related to electronic systems such as cruise control, antilock braking,
traction control, and stability control. New and scalable methods are necessary to
evaluate such controls in a realistic and open setting.
The increasing complexity of software in automotive systems has resulted in
the rise of firmware-related vehicle recalls due to undetected bugs and software
faults.5 In 2009, Volvo recalled 17,614 vehicles because of a software error in the
engine-cooling fan control module that could result in engine failure and possibly
5 EEE Spectrum. 2011. Honda recalls 936,000 more vehicles for electrical and software fixes,
I
September 7. Available online at http://spectrum.ieee.org.
OCR for page 80
80 FRONTIERS OF ENGINEERING
lead to a crash (NHTSA 2009). In August 2011, Jaguar recalled 17,678 vehicles
because of concerns that the cruise control might not respond to normal inputs and
once engaged could not be switched off.6 In November 2011, Honda recalled 2.5
million vehicles to update the software that controls its automatic transmissions. 7
Current automotive systems lack a systematic approach and infrastructure
to support postmarket runtime diagnostics for control software (although at least
one online source indicates that there is a significant effort to incorporate automo-
tive software testing and verification at the design stage8). Once a vehicle leaves
the dealership lot, its performance and operation safety are a “black box” to the
manufacturers and the original equipment providers.
Furthermore, for the more than 100 million lines of code and 60-plus elec-
tronic controller units (ECUs) in a vehicle (Schäuffele and Zurawka 2005), there
are only about eight standard diagnostic trouble codes (DTCs) for software and
they are extremely general (e.g., “memory corruption”). Of the DTCs for software,
none targets the ECU software even though systems such as stability, cruise, and
traction control are critical for safety.
In-Vehicle Diagnostics and Recall Management
The current approach to vehicle recalls is reactive: the manufacturer recalls all
vehicles of a particular year/make/model only after a problem occurs in a signifi-
cant number of them. For a software-related recall, the vehicle is taken to a service
center and a technician either manually replaces the ECU that has the faulty code
or reprograms the ECU code with the new version provided by the manufacturer.
The wait-and-see approach to recalls has a significant cost in both time and
money and may have a negative impact on the vehicle manufacturer’s reputation.
Furthermore, the current recall method relies on word of mouth or the transmis-
sion of manually logged information from the service centers to the manufacturer,
which takes time—during which a safety-critical system may malfunction.
Consequently, there is an urgent need for systematic postmarket in-vehicle
diagnostics for control system software so that issues can be detected early. An
in-vehicle system would log sensor values and perform runtime evaluation of the
states of the system controls. A remote diagnostic center (RDC) would receive
the data (over a network link) to prepare a fault detection and isolation response
(Figure 1), in the form of a proposed dynamic diagnostic trouble code (DyDTC)
that “observes” the ECUs and system control tasks in question. Once sufficient
data are captured, the RDC, using a gray-box model of the vehicle (i.e., with
6 EEE Spectrum. 2011. Jaguar software issue may cause cruise control to stay on, October 25.
I
Available online at http://spectrum.ieee.org.
7 euters. 2011. Honda recalls 2.5 million vehicles on software issue, August 25. Available online
R
at www.reuters.com.
8 UTOSAR (Automotive Open System Architecture); www.autosar.org.
A
OCR for page 81
THE CAR AND THE CLOUD 81
FIGURE 1 Remote diagnostics of automotive control systems showing the vehicle’s
software architecture (in dashed box) and the remote diagnostics center (RDC) commu-
nicating over a network link. The RDC communicates via the onboard “supervisor” with
the vehicle control system to observe its state and update its software in the event of an
unexpected fault. C0, Cf1, Cf2 = software-based controllers in the vehicle (e.g., for stabil-
ity, traction, antilock braking, and cruise control). Using dynamic diagnostic trouble codes
(DyDTCs), the RDC observes the state of the vehicle software for postmarket analysis of
unanticipated faults.
s
ensor and control system observation logs), executes system identification to
build a model of the vehicle. It then develops a fault-tolerant controller to address
the problem and the vehicle is remotely reprogrammed by a code update.
We have developed an early design of such a system, AutoPlug, although we
recognize that the approach will be difficult in practice because it would require
extensive runtime verification of the updated controller.
Overview of AutoPlug
AutoPlug is an automotive ECU architecture between the vehicle and an
RDC to diagnose, test, update, and verify control software. Within the vehicle, we
evaluate observer-based runtime diagnostic schemes and introduce a framework
for remote management of vehicle recalls. The diagnostic scheme deals with both
OCR for page 82
82 FRONTIERS OF ENGINEERING
real- and non-real-time faults, with a decision function to detect and isolate system
faults with modeling uncertainties.
We also evaluate the applicability of “opportunistic diagnostics,” where the
observer-based diagnostics are scheduled in the ECU’s real-time operating system
(RTOS) only when there is slack available in the system (i.e., it can work with
existing hardware in vehicles without interfering with current task sets). The
performance of this aperiodic diagnostic scheme is similar to that of the stan-
dard, periodic scheme under reasonable assumptions. The framework integrates
in-vehicle and remote diagnostics and makes vehicle warranty management more
cost-effective.
The aim of the AutoPlug architecture, illustrated in Figure 2, is to make the
vehicle recall process less reactive with a runtime system for diagnosis of automo-
tive control systems and software. Our focus is on the online analysis of the con-
trol system and control software both in the vehicle ECU network and between the
vehicle and the RDC. We assume the network link between the two is available.
The runtime system within the vehicle manages:
• Fault detection and isolation. Sensor, actuator, and control system
states are logged for the specific ECU. The data are analyzed locally,
and a summary of the states is transmitted to the RDC.
• Fault-tolerant controllers. Once a fault is detected, the high-performance
controller is automatically replaced with a backup controller.
• ECU reprogramming for remote code updates. Upon receipt of
reformulated controller code from the RDC (which will guarantee the
stability and safety of the vehicle), the runtime system reprograms the
particular controller task(s) with the updated code. This can be done
over a cellular or wireless communication link.
• Patched controller runtime verification. The updated code is moni-
tored with continuous checks for safety and performance.
While the onboard system provides state updates of the specific controller,
the RDC provides complementary support through:
• Data analysis and fault localization. By observing sensor and control
system operations locally, structured system identification is used to cre-
ate a model of the vehicle and its control system is evaluated to isolate
faulty behavior.
• Reformulation of control and diagnostic code. A new controller is
formulated for the specific vehicle model and further diagnostic code
dispatched.
• Recall management. Reformulated controller code is transmitted to the
vehicle.
OCR for page 83
FIGURE 2 End-to-end stages of the AutoPlug automotive architecture. (1) When an unexpected fault is reported, the remote diagnostic center
(RDC) sends custom diagnostic code to the vehicle to observe its performance. Using vehicle models developed during the design phase, the
RDC safely observes the operation of the software on the vehicle while it is running. Using this information it extracts a new model for the
vehicle (perhaps with changes due to wear and tear, faulty sensors, changes in suspension). (2-3) With the updated vehicle model, the control
system design is reformulated to correct the faults in the vehicle. (4-5) The RDC remotely updates and verifies the correctness and safety of
the reformulated control software. CAN = controller area network; ECU = electronic controller unit.
83
OCR for page 84
84 FRONTIERS OF ENGINEERING
• Generation of controller verification profiles. The updated controller
is probed for performance and safety.
The remote diagnostic system is capable of diagnosing and reformulating
controllers with real-time faults (e.g., delay, jitter, incorrect sampling rates)
and system faults (e.g., stuck-at faults, calibration faults, and noise in sensors/
actuators).
AutoPlug Testbed
To design and validate the proposed architecture we developed the AutoPlug
testbed, which consists of a hardware-in-loop simulation platform for ECU devel-
opment and testing (Figure 3). The hardware is in the form of a network of ECUs,
interfaced by a controller area network (CAN) bus, on which we implement the
control and diagnostic algorithms. Each ECU runs a nano-RK RTOS, a resource
kernel (RK) with preemptive priority-based real-time scheduling.
Instead of a real vehicle, we use an open-source racecar simulator, which
provides high-fidelity physics-based vehicle models and different road terrains,
thus affording both the realism of an actual vehicle and the flexibility to implement
our own code. In addition, we can introduce faults not covered by standard DTCs.
We have tested basic control algorithms, running as real-time tasks on nano-RK,
for antilock braking systems (ABS), traction control, cruise control, and stability
control to see that the testbed does indeed perform as a real vehicle would.
The main contributions of our applied research and development are threefold:
• an architecture that uses both in-vehicle and remote diagnostics for
remote recall management of deployed vehicles;
• modification of the traditional observer-based fault detection and isola-
tion scheme for in-vehicle opportunistic diagnosis, as well as an experi-
mental thresholding scheme in the presence of modeling uncertainties;
and
• implementation and evaluation of these schemes on real ECUs for
hardware-in-loop simulation.
These three features facilitate postmarket diagnostics, testing, and reconfigu-
ration from a remote data center.
VEHICLE-TO-VEHICLE/INFRASTRUCTURE NETWORKING
FOR ENHANCED SAFETY
Connected vehicles involve a special class of wireless networks where the
maximum relative speeds are in excess of 80 meters per second, the node density
can span more than 9,000 vehicles/mi2, and, most importantly, the dynamics of
OCR for page 85
FIGURE 3 (a) AutoPlug hardware-in-loop testbed with real-time monitoring and diagnostics. CAN = controller area network; ECU = elec-
tronic controller unit. (b) Real-time monitors for stability controller showing the sensor information of the vehicle dynamics. (c) Analysis of
the error signal (i.e., residual) of a particular sensor and its expected values. A smart thresholding scheme is used at the remote diagnostics
center to determine the extent of the fault based on the residual signal.
85
OCR for page 86
86 FRONTIERS OF ENGINEERING
the vehicle, the environment, driver reaction, and interaction with other vehicles
are considered in every communication and control decision. Vehicles enabled
with programmable short-range wireless networking can communicate with each
other and with the infrastructure to enhance the driver’s perception of oncoming
danger within hundreds of milliseconds and, within seconds or minutes, route the
vehicle based on real-time traffic congestion.
With connected vehicles, it is necessary to analyze and validate the effect of
incremental deployment of V2V technologies on message delay, coverage, and
persistence in the region of interest. Because it is expensive to develop and test
experimental protocols on a large fleet of vehicles, there is a need for vehicular
network simulators that faithfully model first-order effects of the street topology,
vehicle congestion, speed limits, communication channels, and spatiotemporal
trends in traffic intensity on the performance and reliability of V2V networking.
Once protocols are designed and evaluated through simulation, their performance
must be tested with real vehicles and realistic traffic densities. Although it may
be possible to deploy a small fleet of vehicles (e.g., a dozen), it is not yet pos-
sible to assess the scalability of such protocols in rush-hour bumper-to-bumper
vehicle densities.
GrooveNet Connected Vehicle Virtualization Platform
We have developed the GrooveNet vehicular network virtualization platform
to simulate thousands of vehicles on any street map and communicate between
real and simulated vehicles. GrooveNet supports a variety of models, network
and vehicular system interfaces, message types, and operating modes and, by
using the same protocols, algorithms, and software implementation in both real
and virtual vehicles, facilitates model-based design, model validation, graceful
deployment, and rapid prototyping. It works as both a simulator and in-vehicle
network platform with connections to the CAN bus and radios using the recently
standardized dedicated worldwide spectrum for vehicular communications (IEEE
802.11p/WAVE standard), a GPS unit, and a cellular interface.
Our tests of GrooveNet with a fleet of five vehicles over 400 miles across
urban, rural, and suburban terrain show that it has realistic models for car follow
ing, communication, mobility, driver types, traffic lights, road-side communica-
tion nodes (e.g., wireless stations that transmit updates about traffic lights to
enable drivers to adjust their speed accordingly), and other interactive features
of real-time driving. Each GrooveNet-enabled vehicle is capable of tight time
synchronization via the GPS pulse-per-second signal for time-critical multi-hop
communication. Using this platform we will develop a suite of V2V and V2I
safety communication protocols to relay traffic incident alerts and warnings of
unsafe road conditions in the Philadelphia and Pittsburgh areas.
OCR for page 87
THE CAR AND THE CLOUD 87
Simulated and Actual Use of GrooveNet
Figure 4 shows three real vehicles (in the circles), which I refer to here as R1,
R2, and R3 (from left to right). The first two vehicles are within communication
range; R3, over a mile away, is not. Thus if a safety alert is triggered by an airbag
deployment in R1, only R2 receives the message. To illustrate the progression of
the message to approaching vehicles, we simulate virtual vehicles on the same
road, each of which will enable a “hop” for the data transmission. R2 sends the
message over a cellular link to the vehicle operations director, which simulates the
progression of the message from one to another of the virtual vehicles (V1, V2,…)
until another real vehicle is in the vicinity of the virtual vehicles. The message
thus travels across multiple hops to be received by R3 over the cellular link as if
it were from R1. We mask the cellular link’s latency by speeding up the simulated
communication across the virtual vehicles.
All vehicles follow the same rebroadcast policy, observe the posted speed
limit, and obey car following standards. Vehicle density can be increased arbi-
trarily and its effects observed by a driver in a real vehicle on the road. Varying
the number of virtual vehicles enables us to study the performance of the protocols
and network algorithms under various densities, driving conditions, and street
topologies. As more experimental vehicles become available, we can increase
the realism and validation of our models. In the meantime, network virtualization
provides the best of both model-based design and real-world validation with rapid
prototyping, with only a few real vehicles needed to operate as mobile gateways.
Figure 5 presents a screen shot of GrooveNet implemented in Linux. In the
top left panel is the list of simulated and real vehicles with their current position,
street speed, and heading (i.e., direction). The top right panel provides a visualiza-
tion of the current position and heading of vehicles in Pittsburgh, Pennsylvania.
Small circles designate vehicles; circles around a dark arrow represent vehicles
that rebroadcast an alert message. The bottom panel shows network connectivity
between real vehicles via a wireless communication using the 802.11p/WAVE
radio interface and between real and virtual vehicles over the cellular network.
For this test we drove five real vehicles along Forbes Avenue in Pittsburgh and
conducted experiments with more than 4,000 virtual vehicles.
Such hybrid simulation provides application users with an intuitive feel of
the impact of communicating vehicle density on packet delivery ratio and event
response time, and provides the developer with feedback about accuracy and
details needed in the simulation models. This network virtualization will make it
possible to answer questions such as: Under what driving conditions and market
penetration of networked vehicles will application A achieve the desired perfor-
mance? How does the probability distribution of model M compare with the real
world? Is the resultant powertrain response safe and under what conditions is it
unsafe?
OCR for page 88
88
FIGURE 4 Mixed evaluation of real and virtual connected vehicles with the GrooveNet platform. The three vehicles in the circles are real
vehicles communicating with short-range wireless communication (using the IEEE 802.11p/WAVE protocol) on the street. The remaining
vehicles are simulated to facilitate communication between real and virtual vehicles. This platform allows for scalable and high-fidelity evalu-
ation of vehicle-to-vehicle and vehicle-to-infrastructure network protocols. DSRC = dedicated short-range communication; V = virtual vehicle.
OCR for page 89
THE CAR AND THE CLOUD 89
FIGURE 5 GrooveNet hybrid simulation demonstrating hundreds of virtual vehicles
communicating with five real vehicles in the city of Pittsburgh, Pennsylvania. See text
for discussion.
TRAFFIC CONGESTION ANALYSIS
To better understand empirical models of traffic congestion in different
street topologies across the nation, and to develop sound traffic prediction and
congestion-aware fastest-path routing algorithms, it is necessary to analyze large-
scale traffic mechanisms. We have developed a traffic analysis tool, AutoMatrix,
that simulates and routes over 16 million vehicles on any US street map and
provides real-time traffic routing services with hierarchical and synthetic traffic
matrices (Figure 6). Using this tool, we are able to investigate the design of adap-
tive routing strategies, methods to mitigate congestion, and ways to better use
traffic network resources. Vehicles are modeled to be car following, have speed
variations, communicate periodically, and be capable of multiple distributed and
centralized routing algorithms.
AutoMatrix operates on a graphics processing unit (GPU) and so is capable of
very large-scale microsimulation and traffic analytics. We have implemented A*
routing, which executes each vehicle’s search for a fastest path between its origin
and destination in a parallel processing manner on the GPU. AutoMatrix is capa-
ble of hierarchical routing so routes with different levels of details are ossible.
p
OCR for page 90
90
FIGURE 6 AutoMatrix real-time traffic congestion modeling and congestion-aware traffic prediction and routing algorithm design. (Left)
Traffic congestion simulation showing more than 800,000 vehicles in Washington, DC. (Center) Hierarchical routing showing one vehicle’s
coarse-grained route (in large boxes), which is determined at the beginning of the trip. The real-time congestion-aware fine-grained fastest
route shows the ¾-mile route ahead of the vehicle. (Right) Thousands of vehicles (each small box represents a vehicle), each with unique
origins and destinations, routed with real-time congestion-aware fastest-path routes around Philadelphia.
OCR for page 91
THE CAR AND THE CLOUD 91
Vehicles can be guided with adaptive routing—the assigned route “responds”
to changes in congestion patterns and reroutes the vehicle to the updated fastest
path. By modeling point-based congestion, such as blocked lanes due to vehicle
breakdowns or accidents, we can model queuing effects as vehicles back up and
congestion spreads through the region.
Using these approaches, AutoMatrix has the potential to improve response
time to traffic incidents by advising drivers to take the updated fastest path to their
destination. We are working to use live traffic congestion data to support the needs
of urban transportation operation centers.
CONCLUSION
The future of the automobile lies in the design and development of new
vehicles that are programmable, connected vehicles, and networked traffic centers.
These efforts are a step toward safer, more efficient, and more enjoyable commut-
ing with automobiles.
REFERENCES
Duri´c P, Miladinov-Mikov M. 2008. Some characteristics of drivers having caused traffic ac-
cidents. Medicinski Pregled 61(9-10):464–469. Available online at www.ncbi.nlm.nih.gov/
pubmed/19203062.
NHTSA [National Highway Traffic Safety Administration]. 2009. Safety Recalls, ID: 09V218000.
Washington, DC: US Department of Transportation. Available online at www.safercar.gov.
Schäuffele J, Zurawka T. 2005. Automotive Software Engineering: Principles, Processes, Methods,
and Tools. Warrendale PA: SAE International.
OCR for page 92
