Transcript
Page 1: AutoPlug - University of Pennsylvania

AutoPlug Open Architecture for Automotive Services

Overview

Simulation Layer

ECU Network Layer

Middleware Layer

Results

Authors:

Ross Boczar, ESE ’11

Jason Suapengco, CIS ’11

Gabriel Torres, ESE/CIS ’11

Advisor:

Dr. Rahul Mangharam, mLab,

University of Pennsylvania

Abstract:

AutoPlug is an automotive ECU

testbed to develop mechanisms and

protocols for remote diagnosis,

programming and testing of future

vehicles. The goal of AutoPlug is to

allow car manufacturers to better

identify, characterize, and predict

automobile software errors.

This system is able to demonstrate

scenarios where a software error is

observed in simulation,

quantitatively diagnosed, and then

corrected by upgrading the software

through the AutoPlug framework.

Senior Project Poster Day 2010

-

Department of Computer and

Information Science

-

University of Pennsylvania

To simulate the operation of a car,

AutoPlug uses the open-source

racing simulator TORCS (Fig. 3.1).

Using this physics – based racing

simulator, we can generate the

appropriate inputs and outputs to

interact with the individual car

ECUs, using a data acquisition

board (DAQ) (Fig. 3.2).

Physics

Update,

Graphics

Update

Car

Update ∆t=0.002s

Get physics engine

outputs

DAQ Read/Write

Update car state with

inputs

Fig. 3.1 – TORCS Simulation

Fig. 3.2 – TORCS Software Flow

AutoPlug is able to record simulation data from the ECU network over

the CAN bus, qualitatively diagnose errors, and provide the ability to

update individual ECU software over the CAN bus.

Example Scenario (Fig. 5): The cruise control module of the car is

malfunctioning, and causes large errors with respect to the desired

(set) speed.

The user or manufacturer notices the cruise

control working incorrectly, and this error can

be seen in an AutoPlug visualization.

The software diagnoses the ECU, and if a

manufacturer update is available, flashes

the ECU with user consent.

The new cruise control ECU software is able to

be verified to be working correctly by the

AutoPlug visualization.

Conclusions:

AutoPlug provides a framework for car manufacturer to remotely

diagnose and correct ECU software errors. The large increase in

electronic and software functions in vehicles has led to a need for

manufacturers to efficiently address these problems without having

to resort to traditional mechanical techniques (test and replace).

AutoPlug provides a better and more cost effective method for

dealing with software errors, giving the manufacturer better options

at handling large scale recalls as well as isolated software errors.

The AutoPlug testbed implements the following features that

provide an inexpensive and efficient way for manufacturers to

diagnose, repair, and recall vehicles:

• Remote Diagnostics: Manufactures are able to interface

with a vehicle remotely and determine if the car is operating

properly.

• Preemptive Maintenance: Historical data gathered by

the middleware layer can be used to warn the user about faults.

• ECU Firmware Upgrades: Upgrades to ECUs can be

deployed without having to access the physical unit.

• Recall Management: The manufacturer would be able to

access the vehicle and determine if the vehicle falls under a

recall.

Simulation

Layer

ECU

Network

Middleware

Layer DAQ Board CAN Bus

Fig. 1.2 – AutoPlug System Overview

AutoPlug consists of three layers (Fig. 1.2) which validate the test

bed through simulation, as well as provide an interface for the

hardware manufacturers to access the vehicle’s information.

Cruise

Control

Anti-lock

Brakes

Steering

ECU

Pedals

ECU

CAN Bus

Fig. 2.2 – Partial ECU Network Fig. 2.1 – ECU Network Diagram

. . .

. . .

The ECU network (Fig. 2.1) consists of individual HC12

microcontrollers that perform each function of the car. Each

controller is networked through the CAN protocol which allows the

ECUs to communicate to each other. The ECU network in AutoPlug

implements electronic functionality for basic options such as

steering, throttle, and transmission as well as more complex

functionality such as ABS and Cruise Control.

The middleware layer (Fig. 4.1-2) provides the manufacturer an

interface by which they can visualize the vehicle, perform

diagnostics, upgrade ECUs and transmit data to remote devices..

The dashboard validates the simulation and ECU network and

displays vehicle state. The middleware also provides an interface for

upgrading individual ECUs over CAN.

Fig. 4.1 – Vehicle Visualizations Fig. 4.2 – CAN Information Display

Spee

d (

km/h

)

Time (1.5 s)

Speed vs. Time

Fig. 5 – Scenario Flow

Implementation

Recalls due to software errors

have increased steadily as cars

become more electronically

complex. This results in huge

costs for the manufacturers, the

bulk of which could be avoided by

better diagnostics for vehicles

already on the road and more

efficient repair methods for

electronic errors. AutoPlug aims

to provide a framework where

these concepts can be

implemented.

" ...[The AutoPlug team]

represent[s] a future when

hardware and software will

play a delicate technology

tango, each shaping the

other to enable safer,

cleaner, and smarter

cars.―

- Dr. K. Venkatesh Prasad,

Ford Motor Company

The modern automobile

features more software

components and electronics

than ever before (Fig. 1.1).

Unfortunately, many of these

components (known as ECUs -

Electronic Control Units) are

―black boxes‖—their internal

states are difficult to

determine. Thus, there is a need

to remotely diagnose, update

and certify automotive software

for efficient warranty and safety

management. Fig. 1.1 – The Modern Car

Top Related