Get documents about "Real-Time Embedded Hybrid Control Software for Intelligent Cruise
Document Sample
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 1
Real-Time Embedded Hybrid Control Software
for Intelligent Cruise Control Applications
Anouck R. Girard and J. Karl Hedrick
power windows, mirrors, and driver-seat settings. Aircraft
Abstract— We concern ourselves with the development and control systems can be several orders of magnitude more
implementation of model-based, real-time, embedded, hybrid complicated, due in part to greater need for system
control software. In particular, we target intelligent cruise reconfiguration from mission to mission, and to fault tolerance
control applications, including Adaptive Cruise Control (ACC), and redundancy requirements that include having several
in which a forward looking range sensor (radar or Lidar, “back-up” copies of critical sensing and actuation systems.
usually) is used to follow a vehicle, and Cooperative ACC As expectations abound for ever more complicated embedded
(CACC), a variation in which wireless communications are used systems, organized real-time, embedded software development
to supplement the forward looking sensor. We discuss modeling processes are needed. Current industry standards fall short of
and simulation as well as experimental results obtained on producing high degree of confidence, reusable code.
automated vehicles. Our approach emphasizes the maintenance
of a single model throughout the development process, with
particular emphasis on “tight-loop” verification and testing at Requirement System
each step. Specification Delivery
Index Terms — Intelligent Cruise Control , Embedded System System
Specification Test
Software, Hybrid Systems, Control Architecture
System System
Design Integration
I. INTRODUCTION
eal-time, embedded systems have become prevalent in our
R everyday life. An embedded system is a special-purpose
Module
Design
Module
Test
computer system built into a larger device [3]. Since many
embedded systems are produced in the tens of thousands to
Implementation
millions of units range, reducing cost is a major concern.
Embedded systems often use a (relatively) slow processor Figure 1. Typical embedded software development process [1].
clock speed and small memory size to cut costs. Programs on
an embedded system often must run with real-time constraints; n
Our i teractions with automotive partners indicate that the
that is, a late answer is considered a wrong answer. Often there typical embedded software development process is as shown
is no disk drive, operating system, keyboard or screen. Cell in figure 1. A large pitfall of the current state of the art is that
phones, PDA, televisions, washing machines, microwave most bugs are caught in the final phases of the process, at
ovens and calculators all contain embedded processors. system integration and testing time. Correcting the problem
Demands placed on the functionality, complexity and critical often involves modifying the system requirements,
nature of embedded systems are ever increasing. Modern-day specification or design, and such changes are costly as they
automobiles now contain many different processors that imply significant rework of the system.
perform functions ranging from engine control to ABS to The model-based process we present in this paper, shown in
vehicle stability and traction control to electronic control of figure 2, places strong emphasis on performing as much testing
and verification in “tight-loops” as possible. Thus we hope to
catch bugs early on in the development process and minimize
Manuscript received March 15, 2003. This work was supported by
cost associated with fixing the problems. We choose to frame
DARPA/ITO in the MoBIES project (Model-Based Integration of
Embedded Systems) under Grant F33615-00-C-1698.
our models and controllers in the context of hybrid automata.
A. Girard is a visiting post-doctoral researcher and lecturer at the The use of a model with well understood mathematical
University of California at Berkeley, Berkeley, CA, 94720 USA (e-mail: properties allows formal verification of the controller, and
anouck@eecs.berkeley.edu). additional information about the experimental platform allows
J. K. Hedrick is a Professor of Mechanical Engineering at the us to verify timing properties of the software. This gives us a
University of California at Berkeley, Berkeley, CA, 94720 USA (e-mail: high degree of confidence in the performance of the generated
khedrick@me.berkeley.edu).
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 2
code. Hybrid verification of the controller and analysis of This application domain makes use of several robotic
timing properties are conducted through the use of third party technologies that are applied to intelligent transportation
tools. systems. Measurement systems are used to keep track of the
target vehicle. In particular, microwave and Doppler radars, and
a Lidar were considered in this project. In addition, to
QNX
Simulation Low-level C code supplement information obtained from the forward-looking
Device drivers
P/S database sensors, wireless communications were used to provide
frequent updates of key information. Automotive vehicles can
C++
QNX Machine
Car, Pentiums be very nonlinear, and the control of such systems is of
Plant Library
CA CC paramount interest to the robotics community, as common
QNX Machine
code nonlinearities such as actuator saturation affect both worlds.
The intelligent cruise controller has multiple modes and must
deal with switching between CC, ACC and CACC in a safe and
Hybrid System Schedulability
Until HSIF
Verification Analysis
smooth manner, a problem that is currently a topic of research
matures
Third party Third
for robotic vehicles as well as automotive applications. Finally,
tools
party tools
the software development process that we present is equally
Figure 2. Intelligent cruise control software development applicable to the development of robot mission software. The
process. generated code has been run and tested as a prototype on
automated vehicles.
This development process was conceived in a joint effort The vehicle and controller models are presented.
between the University of California at Berkeley, Ford Implementation of the controllers on automated cars is
Scientific Research Laboratories and General Motors. We start discussed, in terms is sensing issues, experimental platform
with hybrid system models of the plant and controller, which capabilities and software implementation, and experimental
allows formal verification, simulation and automatic code results are shown.
generation. Timing properties of the generated code can be
checked. The approach is applied to Adaptive Cruise Control
(ACC) and Cooperative ACC systems. II. VEHICLE M ODEL AND CONTROLLER DESIGN
While regular cruise control systems track a desired vehicle
The vehicle model used for controller development is an
speed, Adaptive Cruise Control (ACC) systems adapt their
eleven-state model, which includes vehicle state dynamics,
behavior if there is a vehicle ahead on the roadway, and follow
throttle and brake system dynamics, a two-state model for the
the leader vehicle at a driver requested time gap using line-of-
spark-ignition engine as presented in [4], including external
sight sensors such as radar and/or Lidar. When there is no
data maps which require interpolation, and models o the f
“leader” vehicle present, ACC defaults to conventional cruise
torque converter, transmission and wheel slip, as shown in
control and reverts to the driver set speed. ACC systems are
figure 3.
now available on several production cars, including the Nissan
Q45 and FX45, the Mercedes S-class, the Lexus 330 and 430,
the Audi A8, and select Jaguar and Cadillac models. These
Throttle Vehicle State Dynamics Brakes
production ACC systems obtain their distance and closing rate • 2 C.T. States: Position, Velocity. • 1 C.T. State
• 1 C.T. State
representing time
information about the leading vehicle through the use of their representing • Includes vehicle mass, air drag, rolling response lag
throttle dynamics. resistance, etc.
forward-looking sensor. These sensors are typically subject to
noise, interference, false alarms and drop-outs, and their use
requires heavy filtering. This, in turn, introduces delays into
the system, and limits the ability of the ACC – equipped
vehicles to follow the leader vehicle closely or respond quickly Spark Ignition Engine
Torque Converter
to change in its speed. A variant if Cooperative ACC (CACC), • Uses&2-state C.T. nonlinear model:
?, m a • No C.T. states. 2 Hybrid states: Coupled
& Uncoupled
where the forward-looking sensor is complemented by a Wheel Slip Model
• 3 External Data Maps are used Transmission
wireless communication link that provides hop-by-hop, leader which require both 1 and 2-d
interpolation. •Discrete transitions are taken during gear • Models the tire slip
changes based on vehicle speed. dynamics.
to follower updates of critical information. Such a system can 200
300
200
100
• Requires 4 C.T.
150 0
-100
•Abrupt gear changes cause abrupt gear
be designed to follow vehicles with higher accuracy and faster 100
50
-200
100
50 400
60
0 ratio changes, so a filter is added which States – one per
wheel.
includes 1 C.T. state.
0
100 P 200
m ωe
80 60
0 0 0
500
60 400
response than traditional ACC systems, and should allow for
40 300
P 20
0 ω
m 20 0
10 e
0 0
freeway throughput capacity increases. In addition, the CACC
Figure 3. Vehicle model (figure courtesy of Michael Drew, [2]).
system can be designed to have proven string stability, so it
could contribute to dampening shock waves in the freeway
The vehicle state dynamics have two continuous states,
traffic stream.
vehicle position and velocity, and consider vehicle mass, air
drag and rolling resistance. The throttle and brake dynamics
are both first-order, with one continuous state for each
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 3
representing actuator dynamics for the throttle and time • τct is the control torque
response lag for the brakes. Complete details of the model are • h is the effective wheel radius
available in [2].
Throttle control is used if:
β ades + Rg ( M rr + Fa + mg sin θ ) − τ ct ≥ 0
The controller design process stems from system requirements.
For throttle control, the desired torque is computed as:
We consider only the longitudinal control of passenger
vehicles (no automatic steering). Vehicles may be τ edes = β ades + Rg ( M rr + hFa + mgh sin θ )
heterogeneous, that is of different types, makes and models. In Brake control is used if:
our experiments, w limit ourselves to the utilization of two
e β ades + Rg ( M rr + Fa + mg sin θ ) − τ ct < 0
automated cars. This excludes cut-in scenarios for the
experiments (they were considered in simulation). The For brake control, the desired torque is computed as:
automated cars are 1996 and 1997 model-year Buick LeSabres. β + τ ct
The maximum acceleration recorded on the test track (zero to τ edes = − ades − M rr − hFa − mgh sin θ
full throttle as a step) is on the order of 4m/s 2, and the maximum Rg
deceleration obtained during this project on the track is on the
order of -4m/s 2, obtained manually. Dynamic capabilities of the 1) Throttle control
vehicles must also be considered. Environmental limitations From the desired torque, the desired throttle angle is computed
include wanting to avoid stationary objects, such as trees and using an engine map.
a fence that runs the length of the test track. The desired
behavior for the automated vehicle is to perform cruise control 2) Brake control
if the road is clear, otherwise follow the vehicle in front at a From the desired torque, two different brake control strategies
predetermined time gap. have been implemented.
In the first strategy, the master cylinder pressure is controlled.
The controller was split hierarchically between an upper level A pressure regulator valve controls the pressure applied on
controller that has several modes, namely cruise control (CC), the hydraulic actuator. Seal friction exists in the master cylinder
adaptive cruise control (ACC) and coordinated adaptive cruise and the actuator, and a small amount of hysteresis is present in
control (CACC). In ACC mode we use only information from the pressure regulation valve. The friction is modeled as
the host vehicle’s forward-looking sensors, and in CACC mode hyperbolas from various points in the hysteresis loop and can
we supplement this information with data from the wireless be written as:
communication system.
Pmc = g(u)
Low-Level Control High-Level Control
desired acceleration state of car Feed-forward plus proportional f eedback control is used, as
developed in [6]. The control law can be written as:
ub = g −1 ( Pmc ) + kb ( Pmc _ des − Pmc )
accel. to torque DB1 DB2
off
switching law
cc acc cacc
throttle brake Where u b is the applied command input to the brake solenoid
valve, Pmc_des the desired master cylinder pressure, Pmc the
throttle, brake, state of car desired acceleration measured master cylinder pressure, and kb >0 a feedback gain.
Figure 4. Decomposition of the vehicle control system in In the second brake control strategy, the wheel brake pressure
modes. is controlled, and the brake system is modeled. The control law
uses dynamic surface control and can be written as:
2
The upper control generates a desired host vehicle
acceleration, which is sent to the lower-level controller. The Pwdes − λb ( Pw − Pwdes )
&
Pmc = Pw −
lower-level controller converts this desired acceleration to a
∂Pw
desired torque, then chooses whether to apply the brakes or Cq
throttle, and in what amount [5]. Both controllers are run on ∂V
separate control computers. Where Pw_des is the desired wheel pressure, V is the volume
of displaced brake fluid, Pw the pressure at the wheel, Cq a
In the following equations, the following variables are used: flow coefficient, and λb is a control gain.
• Fa is the aerodynamic drag force
• M rr is the rolling resistance moment as
The following figure shows data that w taken during an
• Rg is the gear ratio (related to engine and acceleration-tracking run on the test car, using the low-level
vehicle speeds) control law. The desired acceleration is a square pattern. The
• βades is the desired synthetic acceleration velocity, acceleration and desired acceleration are shown on
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 4
the first line, versus time. The second line has the desired and e = R – Rd
actual brake pressure, and throttle angle, vs. time.
where the range R is defined as R = x1 - x2, & & &
R = x1 − x 2 and
&& && x
R = x1 − &&2 = a1 − a 2 .
We derive the sliding surface control in two different ways,
which basically lead to the same control law.
Feedback linearization:
&&
R =ν .
Let a2 = a1-ν. Then
&& − k e − k e . Then e& + k e + k e = 0 .
Let ν = Rd & & &
d p d p
The control law obtained by feedback linearization is:
&&
a 2 = a1 − Rd + k d e + k p e
&
The first two terms in the control law are feed-forward, and the
last two are feedback.
.
Figure 5 Results of acceleration tracking run, on test track.
Double First-Order Method:
Green quantities are actual, red are measured, blue are filtered.
Define s = e + λe . Then s ≡
& 0 ⇒ e →0.
Cruise Control Law
The purpose of cruise control is to maintain a desired velocity. We have: s = && + λe . If: && = −λe − ks , then s + ks = 0 .
& e & e & &
A vehicle may be in cruise control mode if it is not equipped && && &&
Now, e = R − Rd = a1 − a 2 − Rd .&&
with ACC or CACC, has no vehicle immediately in front of it or
This leads to the following control law:
has at least 100 meters of clearance to the preceding vehicle, or
&&
a 2 = a1 − Rd + λe + ks ,
&
by decision of the human driver.
The controller uses a feedback and feed-forward control law of that is:
the form: &&
a 2 = a1 − Rd + (λ + k )e + kλe
&
a d = v d − k (v − v d )
&
where: ad is the desired acceleration of the vehicle, v is the Once again, the first two terms in the control law are feed-
speed of the vehicle, v d is the desired speed of the vehicle and forward, and the last two are feedback. Both control laws are in
k is a gain set to 0.75. essence equivalent.
ACC and CACC Law III. SOFTWARE DEVELOPMENT PROCESS
The control law for ACC and CACC is identical. The main
difference between both modes is in the sensor fusion, and in We used a model-based approach throughout the control and
the quality of the state information. Also, the operating logic is software development. We phrased the vehicle models as
different in both modes. The purpose of an ACC or CACC law hybrid automata and used the TEJA [7] language to simulate
is to regulate the range between vehicles to a user-selected and exercise the models. We designed our controllers, and also
value, and to adjust the vehicle speed to the speed of phrased them as hybrid automata in TEJA. This allowed us to
downstream traffic. Velocity dependent (headway) control is perform simulation over a wide range of conditions. In
used, with: particular, switching conditions from one mode to the next (for
Rdes = λv + µ example ACC into CACC) were designed by hand and were
Typical values for headway time range form 1.8 seconds to 0.7 tested carefully.
seconds. In addition, hybrid system verification was conducted to
answer questions such as “will the distance between the two
The control law was designed using sliding control, where a vehicles ever become less than zero?” (an undesirable
surface is usually defined as a function of the error, derivatives circumstance). Results were obtained by several different
of the error and/or integrals of the error. The surface is defined groups and can be found in [8].
such that the state will exponentially decay along the surface TEJA allows true control and software architecture co-design,
to the desired point. The input is chosen to guarantee that the in that the programmer can organize his/her hybrid automata
state will converge and stay on the sliding surface. into tasks, allocate tasks to processors (manually), and select
communication mechanisms between distributed processors,
We define the error e as: or between separate tasks. The chosen architecture can then
be simulated, and C or C++ code can be generated for each
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 5
task independently. This allows us to maintain a single model target locking based on persistence over time, elimination of
containing all of our control and software information. The non-feasible objects, etc…
code that is generated from TEJA for the controllers interfaces In addition, the algorithms were developed to function both in
with legacy code, such as device drivers, driver display units highway conditions (high speeds, low curvature) and in stop-
etc…, through the use of a shared-memory database on the and-go conditions (low speeds, and one may have parked cars,
“publish-and-subscribe” model. On the experimental test pedestrians etc… on the road). This presented an additional
vehicles, all of the software is run on Pentium computers level of difficulty. Details about the sensor processing and
running the QNX4.25 real-time operating system. fusion algorithms can be found in [5].
After experimental testing, calibrations may be made to the
controller by modifying the original TEJA automata, then
B. Experimental Platform
regenerating the TEJA code.
IV. IMPLEMENTATION AND EXPERIMENTAL RESULTS The experimental vehicles are 1996 and 1997 model-year Buick
LeSabres.
The TEJA-generated software for CC, ACC and CACC was run
on experimental test vehicles operated by California PATH.
A. Sensor Issues
In the TEJA simulation, we considered that we had range and
closing rate information available (for ACC, supplemented by
communicated acceleration and maximum braking rate for
CACC) for a target vehicle located ahead of the host vehicle.
We considered noise models for the range, closing rate and
lead vehicle acceleration and dropped packets and bandwidth
limitations for the communicated data. However, the sensors
that were mounted on the test vehicles did not have such Figure 6. Experimental test vehicles.
simple outputs. We used two different types of radar and a
lidar, in addition to the wireless communications (conducted They are equipped with throttle, brake and steering actuating
over 802.11b). systems , as well as with numerous sensors, including
The first radar we consider is a microwave radar that was accelerometers, wheel speed sensors, engine speed and
custom-made by Delco for vehicle platooning operations. It manifold pressure sensors, as well as magnetometers that are
operates in the millimeter-wave region at 76-77 GHz , has a used as part of the lateral control. In addition, for our project,
narrow beam and a range of approximately 40m. The short both radars and the lidar described above were mounted to the
range made this radar useless for highway-speed type ACC, front bumper of the vehicles.
but very useful for slow-speed, stop-and-go type ACC and There are two control computers located in the trunk. Both run
CACC that were also developed as part of this project. the QNX 4.25 operating system and communicate over serial
The second radar we considered is a Doppler (monopulse) port connections. The computers run a host of tasks necessary
radar, part of the EVT300 collision warning system (Eaton- for automated control of the vehicles, including reading sensor
Vorad Technologies), with a 12 degree beam width. It provides data and writing to actuators, control computations such as
range, derivative of range and azimuth information for up to 7 those described above for the ACC/CACC system and low-
targets, has a range of approximately 100m, and, due to its level controllers, and tasks pertaining to driver display
operating principles, provides no information on objects information.
having zero relative velocity. There are about 30 different tasks running on the most heavily
The lidar we used is a Mitsubishi unit with a field of view of 12 loaded of the control computers, and timing is fairly critical as
degrees (+/- 6) in the horizontal plane. It provides distance and human test drivers are in the cars during runs and their safety
intensity values for each of 80 equal segments over the 12 is paramount. In consequence, we teamed up with another
degrees of field of view. MoBIES team at Carnegie Mellon University to perform
schedulability analysis of all tasks, using Rate Monotonic
Due to the nature of the sensors, the raw sensor data must be Scheduling algorithms [9]. Execution times for the different
processed to provide fused information about a single target tasks were measured on the control computer, and a choice of
vehicle, ahead of the host vehicle, in the same lane, that is priorities to set the tasks at in QNX was found that guarantees
used by the control algorithm. that timing properties are not violated.
Several strategies were evaluated for processing of the radar
and lidar data, including limiting potential targets to those in a C. Experimental Results
“target zone”, which can be shaped to accommodate for curves
in the road using information from a gyro, placing thresholds,
> REPLACE THIS LINE WITH YOUR PAPER IDENTIFICATION NUMBER (DOUBLE-CLICK HERE TO EDIT) < 6
The next figure shows a velocity-tracking run on the test car, passenger vehicles. The model-based approach was developed
using the cruise controller. The vehicle is tracking a half-sine in partnership between the University of California at Berkeley,
wave in velocity, as shown in the top-left portion of the figure. Ford Research Labs and GM. A prototype ACC and CACC
system has been tested in prototype phase, both at highway
speeds and in stop-and-go situations (such as driving in
congested traffic).
Robotic technologies such as range, velocity and acceleration
measurements, and their processing and fusion were used as
part of the system. In addition, vehicles can present very
nonlinear behavior, especially at low speeds, and their control
presents a formidable challenge.
The problem domain of intelligent cruise control applications
has been described in detail, along with control and software
development methodologies. We are currently working on
applying the same model-based approach to the development
of intelligent cruise control systems for automated transit
buses.
A CKNOWLEDGMENTS
Figure 7. Results of velocity-tracking cruise control run, on test
track. Green quantities are actual, red are measured, blue are
filtered. The authors would like to acknowledge the assistance of the
Experimental Group at California PATH, in particular Dan
The speed limit on the Berkeley test track is 25mph. Higher- Empey and Paul Kretz, for their assistance with vehicle
speed testing is done regularly at a remote facility. Results for instrumentation, testing and data collection, and the help of
a CACC run on the Berkeley test track are presented below. Adam Howell and Mike Drew with TEJA model development
and testing, and Stephen Spry with controller development,
implementation and testing. Figure 6 is courtesy of PATH
publications.
REFERENCES
[1] Personal communication, Ken Henry, GM Research.
[2] M. Drew and J.K. Hedrick, “ A Discussion of Vehicle Modeling for
Control”, Vehicle Dynamics Laboratory T echnical Report,
Mechanical Engineering Department, UC Berkeley.
[3] http://www.wikipedia.org/wiki/Embedded_system, from Wikipedia,
the free Encyclopedia
[4] D. Cho and J.K. Hedrick, “ Automotive Engine Modeling for
Control”, ASME Journal of Dynamic Systems, Measurement and
Control, December 1989, Vol. 111, pp. 568-576.
[5] Girard, A.R., Spry, S.C., Kretz, P.R. Dickey, S.R., Empey, D.M.,
Figure 8. Results of CACC cruise control run, on test track. Misener, J.A., Variaya, P.P. and Hedrick, J.K., “Vehicle-to-Vehicle
Green line indicates velocity of lead car, red velocity of Open Experimental Platform Reference Manual”, Report to
follower car, blue lines indicate relative velocity as obtained DARPA on the MoBIES Project, available in its latest version for
from the communications and radar filtering. the web at:
http://robotics.eecs.be rkeley.edu/~anouck/v2v_report.pdf
[6] D.B. Maciuca and J.K. Hedrick, “ Advanced Nonlinear Brake
The vehicle speeds match well, especially when the System Control for Vehicle Platooning”, Proceedings of the T hird
discontinuous nature of the speed profile is taken into European Control Conference, ECC 95, Rome, Italy . Vol.3, 1995,
consideration. A constant range policy was used for this pp.2402-7.
particular low-speed test and the range between the vehicles [7] www.teja.com
was maintained at 15 meters throughout the test. [8] Franjo Ivancic, “ Report on Verification of the MoBIES Vehicle-
Vehicle Automotive OEP Problem”, Technical Report # MS-CIS-
02-02, University of Pennsylvania, Philadelphia, PA, March 2002.
V. CONCLUSIONS
[9] www.timesys.com
This paper presents the use of a model-base approach to the
development of real-time, embedded, hybrid control software.
The concepts are illustrated with a scenario involving speed
profile tracking and vehicle following applications for
Other docs by slappypappy125
ABSTRAK Aini Nurul 2006 Penerapan Model Pembelajaran Kooperatif ABSTRAK Aini
Views: 316 | Downloads: 9
