PRESENTED BY M.SHINO PRATHIBHA III-IT V.

PRIYANGA III-IT

SYED AMMAL ENGINEERING COLLEGE DR.E.M.ABDULLAH CAMPUS, RAMNAD E-mail:shinoraj7@gmail.com priyangafathima@gmail.com

Real-Time Embedded Hybrid Control Software For Intelligent Cruise Control Applications

ABSTRACT Embedded systems various application like chocolate vending machine for children. Provide money through ATM for college students for going movies. For homemakers its used for home appliance purchase. There are various applications. We concern ourselves with the development and implementation of model-based, real-time, embedded, hybrid control software. In particular, we target intelligent cruise control applications, including Adaptive Cruise Control (ACC), in which a forward looking range sensor (radar or Lidar, usually) is used to follow a vehicle, and Cooperative ACC (CACC), a variation in which wireless communications are used to supplement the forward looking sensor. We discuss modeling and simulation as well as experimental results obtained on 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 each step.

INTRODUCTION Real-time, embedded systems have become prevalent in our everyday life. An embedded system is a special-purpose computer system built into a larger device . Since many embedded systems are produced in the tens of thousands to millions of units range, reducing cost is a major concern. Embedded systems often use a (relatively) slow processor clock speed and small memory size to cut costs. Programs on an embedded system often must run with real-time constraints; that is, a late answer is considered a wrong answer. Often there is no disk drive, operating system, keyboard or screen. Cell phones, PDA, televisions, washing machines, microwave ovens and calculators all contain embedded processors.

Requirement Specification System Specification System Design Module Design

System Delivery System Test System Integration Module Test

Implementation

Figure 1. Typical embedded software development process [1]

Demands placed on the functionality, complexity and critical nature of embedded systems are ever increasing. Modern-day automobiles now contain many different processors that perform functions ranging from engine control to ABS to vehicle stability and traction control to electronic control of power windows, mirrors, and driver-seat settings. Aircraft control systems can be several orders of magnitude more complicated, due in part to greater need for system reconfiguration from mission to mission, and to fault tolerance and redundancy requirements that include having several back-up copies of critical sensing and actuation systems. As expectations abound for ever more complicated embedded systems, organized real-time, embedded software development

processes are needed. Current industry standards fall short of producing high degree of confidence, reusable code. Our I tractions with automotive partners indicate that then typical embedded software development process is as shown in figure 1. A large pitfall of the current state of the art is that most bugs are caught in the final phases of the process, at system integration and testing time. Correcting the problem often involves modifying the system requirements, specification or design, and such changes are costly as they simply significant rework of the system. The model-based process we present in this paper, shown in 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 cost associated with fixing the problems. We choose to frame our models and controllers in the context of hybrid automata. The use of a model with well understood mathematical properties allows formal verification of the controller, and additional information about the experimental platform allows us to verify timing properties of the software. This gives us a high degree of confidence in the performance of the generated code. Hybrid verification of control analysis of timing properties are conducted through third party tool.
Simulation
QNX Low -level C code Device drivers P/S database C++

Plant Library
CA CC
code

QNX Machine QNX Machine

Car, Pentiums

Until HSIF matures

Hybrid System Verification

Third party tools

Schedulability Analysis
Third party tools

Figure 2. Intelligent cruise control software development process.

This development process was conceived in a joint effort between the University of California at Berkeley, Ford Scientific Research Laboratories and General Motors. We

start with hybrid system models of the plant and controller, which allows formal verification, simulation and automatic code generation. Timing properties of the generated code can be checked. The approach is applied to Adaptive Cruise Control (ACC) and Cooperative ACC systems. While regular cruise control systems track a desired vehicle speed, Adaptive Cruise Control (ACC) systems adapt their behavior if there is a vehicle ahead on the roadway, and follow the leader vehicle at a driver requested time gap using line-of-sight sensors such as radar and/or Lidar. When there is no leader vehicle present, ACC defaults to conventional cruise control and reverts to the driver set speed. ACC systems are 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 production ACC systems obtain their distance and closing rate information about the leading vehicle through the use of their forwardlooking 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 to change in its speed. A variant if Cooperative ACC (CACC), where the forward-looking sensor is complemented by a wireless communication link that provides hop-by-hop, leader to follower updates of critical information. Such a system can be designed to follow vehicles with higher accuracy and faster response than traditional ACC systems, and should allow for freeway throughput capacity increases. In addition, the CACC system can be designed to have proven string stability, so it could contribute to dampening shock waves in the freeway traffic stream. This application domain makes use of several robotic technologies that are applied to intelligent transportation 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 supplement information obtained from the forward-looking sensors, wireless communications were used to provide frequent updates of key information. Automotive vehicles can be very nonlinear, and the control of such systems

is of paramount interest to the robotics community, as common 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 smooth manner, a problem that is currently a topic of research for robotic vehicles as well as automotive applications. Finally, the software development process that we present is equally applicable to the development of robot mission software. The generated code has been run and tested as a prototype on automated vehicles. The vehicle and controller models are presented. Implementation of the controllers on automated cars is discussed, in terms is sensing issues, experimental platform capabilities and software implementation, and experimental results are shown. II. VEHICLE MODEL AND CONTROLLER DESIGN The vehicle model used for controller development is an eleven-state model, which includes vehicle state dynamics, throttle and brake system dynamics, a two-state model for the spark-ignition engine as presented in , including external data maps which require interpolation, and models the of torque converter, transmission and wheel slip, as shown in figure 3.

Th ot le r t
1 C.T. St e at representing t hrottle dynam ics.

Veh icle St e Dy am at n ics

2 C.T. St es P osition, Velocity. at : Includes vehicle m ass, air drag, rolling resistance, etc.

Br es ak
1 C.T. St e at representing tim e response lag

Sp k Ig it n En i e ar n io gn
C.T. nonlinear m odel: Maps are used which require both 1 and 2 -d

To q e Co v t r u n er er
No C.T. st ates. 2 Hy r b id st es Coupled at : & Uncoupled

Tr an sm ission
Discrete transitions are taken during gear changes based on vehicle speed. Abrupt gear changes cause abrupt gear ratio changes, so a filter is added which includes 1 C.T. st e at .

W e h el Slip M d o el
Models the tire slip dynam ics. Requires 4 C.T. St es one per at wheel.

60 0 50 20 0 0 0 4 00 e

Figure 3. Vehicle model (figure courtesy of Michael Drew, [2])

The vehicle state dynamics have two continuous states, 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 representing actuator dynamics for 6

the throttle and time response lag for the brakes. Complete details of the model are available The controller design process stems from system requirements. We consider only the longitudinal control of passenger vehicles (no automatic steering). Vehicles may be heterogeneous, that is of different types, makes and models. In our experiments, we limit ourselves to the utilization of two automated cars. This excludes cut-in scenarios for the experiments (they were considered in simulation). The automated cars are 1996 and 1997 model-year Buick LeSabres. The maximum acceleration recorded on the test track (zero to full throttle as a step) is on the order of 4m/s 2, and the maximum deceleration obtained during this project on the track is on the order of -4m/s 2, obtained manually. Dynamic capabilities of the1) vehicles must also be considered. the1) Environmental limitations include wanting to avoid stationary objects, such as trees and a fence that runs the length of the test track. The desired behavior for the automated vehicle is to perform cruise control2) if the road is clear, otherwise follow the vehicle in front at control2) a predetermined time gap. The controller was split hierarchically between an upper level controller that has several modes, namely cruise control (CC), adaptive cruise control (ACC) and coordinated adaptive cruise control (CACC). In ACC mode we use only information from the host vehicles forward-looking sensors, and in CACC mode we supplement this information with data from the wireless communication system.

Low -Level Control

desired acceleration accel. to torque switching law throttle brake

High-Level Control
state of car

DB1

DB2

off c c acc cacc

throttle, brake, state of car

desired acceleration

Figure 4. Decomposition of the vehicle control system in modes .

The upper control generates a desired host vehicle acceleration, which is sent to the lower-level controller. The lower-level controller converts this desired acceleration to a desired torque, then chooses whether to apply the brakes or throttle, and in what amount. Both controllers are run on separate control computers. Fa is the aerodynamic drag force. Mrr is the rolling resistance moment. Rg is the gear ratio (related to engine and vehicle speeds) bades is the desired synthetic acceleration ct is the control torque h is the effective wheel radius.

Throttle control is used if:

ades + Rg ( M rr + Fa + mg sin ) ct 0

For throttle control, the desired torque is computed as: Brake control is used if:

edes = ades + Rg ( M rr + hFa + mgh sin ) ades + Rg ( M rr + Fa + mg sin ) ct < 0

For brake control, the desired torque is computed as:

+ edes = ades ct M rr hFa mgh sin Rg

Throttle control

From the desired torque, the desired throttle angle is computed using an engine map. Brake control From the desired torque, two different brake control strategies have been implemented. In the first strategy, the master cylinder pressure is controlled. A pressure regulator valve controls the pressure applied on the hydraulic actuator. Seal friction exists in the master cylinder and the actuator, and a small amount of hysteresis is present in the pressure regulation valve. The friction is modeled as hyperbolas from various points in the hysteresis loop and can be written as: Pmc = g(u) Feed-forward plus proportional feedback control is used, as developed in [6]. The control law can be written as:

ub = g 1 ( Pmc ) + kb ( Pmc _ des Pmc )

Where ub is the applied command input to the brake solenoid valve, Pmc_des the desired master cylinder pressure, Pmc the measured master cylinder pressure, and kb>0 a feedback gain. In the second brake control strategy, the wheel brake pressure is controlled, and the brake system is modeled. The control law uses dynamic surface control and can be written as:
2

Pwdes b ( Pw Pwdes ) Pmc = Pw Pw C V q

Where Pw_des is the desired wheel pressure, V is the volume of displaced brake fluid, Pw the pressure at the wheel, Cq a flow coefficient, and b is a control gain.

The following figure shows data that was taken during an acceleration-tracking run on the test car, using the low-level control law. The desired acceleration is a square pattern. The velocity, acceleration and desired acceleration are shown on the first line, versus time. The second line has the desired and actual brake pressure, and throttle angle, vs. time.

Figure 5 Results of . acceleration tracking run, on test track. Green quantities are actual, red are measured, blue are filtered.

Cruise Control Law The purpose of cruise control is to maintain a desired velocity. A vehicle may be in cruise control mode if it is not equipped with ACC or CACC, has no vehicle immediately in front of it or has at least 100 meters of clearance to the preceding vehicle, or by decision of the human driver. The controller uses a feedback and feed-forward control law of the form:

a d = vd k(v vd )
Where: ad is the desired acceleration of the vehicle, v is the speed of the vehicle, vd is the desired speed of the vehicle and k is a gain set to 0.75.

ACC and CACC Law

10

The control law for ACC and CACC is identical. The main difference between both modes is in the sensor fusion, and in the quality of the state information. Also, the operating logic is different in both modes. The purpose of an ACC or CACC law is to regulate the range between vehicles to a user-selected value, and to adjust the vehicle speed to the speed of downstream traffic. Velocity dependent (headway) control is used, with: Rdes = v + Typical values for headway time range form 1.8 seconds to 0.7 seconds. The control law was designed using sliding control, where a surface is usually defined as a function of the error, derivatives of the error and/or integrals of the error. The surface is defined such that the state will exponentially decay along the surface to the desired point. The input is chosen to guarantee that the state will converge and stay on the sliding surface. We define the error as:
e = R Rd where the range R is defined as R = x - x2, 1

R = x1 x 2 and

R = x1 x2 = a1 a 2 .
We derive the sliding surface control in two different ways, which basically lead to the same control law. Feedback linearization: Let a2 = a1- Then . Let

R = . = Rd k d e k p e . Then e +k d e + k p e = 0 .

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. Double First-Order Method: Define s =e + . Then s 0 e We have: Now,

. e 0

s = e + . If: e = e ks , then s +ks = 0 . e e = R R d = a1 a 2 R d .

a 2 = a1 R d + +ks , e

This leads to the following control law: that is:

a 2 = a1 R d +( +k )e +k e

Once again, the first two terms in the control law are feed forward, and the last two are feedback. Both control laws are in essence equivalent.

11

Double click the icon

III.

SOFTWARE

DEVELOPMENT PROCESS We used a model-based approach throughout the control and software development. We phrased the vehicle models as hybrid automata and used the TEJA language to simulate and exercise the models. We designed our controllers, and also phrased them as hybrid automata in TEJA. This allowed us to perform simulation over a wide range of conditions. In particular, switching conditions from one mode to the next (for example ACC into CACC) were designed by hand and were tested carefully. In addition, hybrid system verification was conducted to answer questions such as will the distance between the two vehicles ever become less than zero? (an undesirable circumstance). Results were obtained by several different groups and can be found .TEJA allows true control and software architecture co-design, in that the programmer can organize his/her hybrid automata into tasks, allocate tasks to processors (manually), and select communication mechanisms between distributed processors, or between separate tasks. The chosen architecture can then be simulated, and C or C++ code can be generated for each task independently. This allows us to maintain a single model containing all of our control and software information. The code that is generated from TEJA for the controllers interfaces with legacy code, such as device drivers, driver display units etc, through the use of a shared-memory database on the publish-andsubscribe model. On the experimental test vehicles, all of the software is run on Pentium computers running the QNX4.25 real-time operating system. After experimental testing, calibrations may be made to the controller by modifying the original TEJA automata, then regenerating the TEJA code. IV. IMPLEMENTATION AND EXPERIMENTAL RESULTS

12

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 simple outputs. We used two different types of radar and a lidar, in addition to the wireless communications (conducted over 802.11b). The first radar we consider is microwave radar that was custom-made by Delco for vehicle platoon operations. It operates in the millimeter-wave region at 76-77 GHz, has a narrow beam and a range of approximately 40m. The short range made this radar useless for highway-speed type ACC, but very useful for slowspeed, stop-and-go type ACC and CACC that were also developed as part of this project. The second radar we considered is a Doppler (monopulse) radar, part of the EVT300 collision warning system (Eaton-Vorad Technologies), with a 12 degree beam width. It provides range, derivative of range and azimuth information for up to 7 targets, has a range of approximately 100m, and, due to its operating principles, provides no information on objects having zero relative velocity. The lidar we used is a Mitsubishi unit with a field of view of 12 degrees (+/- 6) in the horizontal plane. It provides distance and intensity values for each of 80 equal segments over the 12 degrees of field of view. Due to the nature of the sensors, the raw sensor data must be processed to provide fused information about a single target vehicle, ahead of the host vehicle, in the same lane, that is used by the control algorithm. Several strategies were evaluated for processing of the radar and lidar data, including limiting potential targets to those in a target zone, which can be shaped to accommodate for curves in the road using information from a gyro, placing thresholds, target locking based on persistence over time, elimination of non-feasible objects, etcIn addition, the algorithms were developed to function both in highway conditions (high

13

speeds, low curvature) and in stop and- go conditions (low speeds, and one may have parked cars, pedestrians etc on the road). This presented an additional level of difficulty. Details about the sensor processing and fusion algorithms can be found.

B. Experimental Platform The experimental vehicles are 1996 and 1997 model-year Buick LeSabres. They are equipped with throttle, brake and steering actuating systems , as well as with numerous sensors, including accelerometers, wheel speed sensors, engine speed and manifold pressure sensors, as well as magnetometers that are used as part of the lateral control. In addition, for our project, both radars and the lidar described above were

Figure 6. Experimental test vehicles .

mounted to the front bumper of the vehicles. There are two control computers located in the trunk. Both run the QNX 4.25 operating system and communicate over serial port connections. The computers run a host of tasks necessary for automated control of the vehicles, including reading sensor data and writing to actuators, control computations such as those described above for the ACC/CACC system and low-level controllers, and tasks pertaining to driver display information. There are about 30 different tasks running on the most heavily loaded of the control computers, and timing is fairly critical as human test drivers are in the cars during runs and their safety is paramount. In consequence, we teamed up with another MoBIES team at Carnegie Mellon University to perform schedulability analysis of all tasks, using Rate 14

Monotonic Scheduling algorithms . Execution times for the different tasks were measured on the control computer, and a choice of priorities to set the tasks at in QNX was found that guarantees that timing properties are not violated.

C. Experimental Results The next figure shows a velocity-tracking run on the test car, using the cruise controller. The vehicle is tracking a half-sine wave in velocity, as shown in the top-left portion of the figure. The speed limit on the Berkeley test track is 25mph. higher speed testing is done regularly remote facility. Results for

Figure 7. Results of velocity-tracking cruise control run, on test track. Green quantities are actual, red are measured, blue are filtered.

a CACC run on the Berkeley test track are presented below. Green line indicates velocity of lead car, red velocity of follower car; blue lines indicate relative velocity as obtained from the communications and radar filtering. The vehicle speeds match well, especially when the discontinuous nature of the speed profile is taken into consideration. A constant range policy was used for this particular low-speed test and the range between the vehicles was maintained at 15 meters throughout the test.

15

V. CONCLUSIONS 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 passenger vehicles. The model-based approach was developed in partnership between the University of California at Berkeley, 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

Figure 8. Results of CACC cruise control run, on test track. Green line indicates velocity of lead car, red velocity of follower car, blue lines indicate relative velocity as obtained from the communications and radar filtering.

challenge. The problem domain of intelligent cruise control applications has been described in detail, along with control and software development methodologies. We are currently

16

working on applying the same model-based approach to the development of intelligent cruise control systems for automated transit buses. Thanking you

17