Real-Time Support for Automotive

Embedded Systems
M. Tech. Seminar Report
Submitted in partial fulfillment of the requirements
for the degree of
Master of Technology

by
Ashish Govind Gudhe
Roll No: 05305028

under the guidance of

Prof. Krithi Ramamritham

Department of Computer Science and Engineering

Indian Institute of Technology, Bombay
Mumbai

Acknowledgments
I would like to thank my guide, Prof. Krithi Ramamritham for the consistent motivation and directions he has fed into my work. I would also like to thank Mr. Vamshi
Krishna and Mr. Sachitanand Malewar for the help extended in understanding the practical aspect of automotive systems.

Declaration
I hereby declare that I have written this report. Wherever I have borrowed material from
other sources, I have cited the source of the material.
Ashish Govind Gudhe
MTech-I
CSE, IITB

Contents
1 Introduction
1.1 Automotive applications . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Adaptive Cruise Control(ACC) : An overview . . . . . . . . . . . . . . . .
1.2.1 ACC system description . . . . . . . . . . . . . . . . . . . . . . . .
2 Requirements of Automotive systems
2.1 Data Requirements . . . . . . . . . . . . . . . . .
2.1.1 Automotive Data Requirements . . . . . .
2.1.2 ACC Data Requirements . . . . . . . . . .
2.2 Processing Requirements . . . . . . . . . . . . . .
2.2.1 Automotive Processing Requirements . . .
2.2.2 ACC Processing Requirements . . . . . . .
2.3 Communication Requirements . . . . . . . . . . .
2.3.1 Automotive Communication Requirements
2.3.2 ACC Communication Requirements . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

3 Real-time support for Automotive systems

3.1 Real-time database support for Automotive systems .
3.1.1 Real-time database . . . . . . . . . . . . . . .
3.1.2 Real-time database support for ACC . . . . .
3.2 Real-time processing support for Automotive systems
3.2.1 Real-time scheduling algorithms . . . . . . . .
3.2.2 Scheduling of ACC tasks . . . . . . . . . . . .
3.3 Communication support for Automotive systems . . .
3.3.1 Communication protocols . . . . . . . . . . .
3.3.2 Communication protocols for ACC . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

1
1
3
4

.
.
.
.
.
.
.
.
.

5
5
5
6
7
7
7
8
9
10

.
.
.
.
.
.
.
.
.

11
11
11
12
13
13
15
15
15
17

4 Conclusions and Future Work

19
4.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Abstract
Real-time systems play a vital role for safety-critical applications. One such application
is to be studied called Adaptive Cruise Control(ACC) for safety of driver and vehicle.
The real-time database, real-time processing and real-time communication are the major
areas to be focused on. In order to maintain temporal consistency of environmental
and processed data we need support of real-time database. This temporal consistency is
essential to maintain exact status of environment. The real-time scheduling is essential
for timely execution of various tasks running in the application. The consistent data and
timely execution of tasks is crucial for proper functioning of automotive systems. The
components of a automotive system need to communicate without any delay or error
which is guaranteed by real-time communication system. The purpose is to realize the
requirements of the automotive systems with ACC as a specific application. Once the
requirements are found, an attempt is made to meet them through the real-time support
from data, processing and communication point of view .

Chapter 1
Introduction
The automotive industry is lot more dependent on the electronic systems these days. The
heavier mechanical and hydraulic parts are gradually replaced by electronic hardware.
The vehicles have embedded systems which is a combination of hardware and software
designed specifically for controlling certain components of a vehicle. Thus, computers are
extensively used by the manufacturers for monitoring and controlling the vehicle. With
the technological advancements and growth of semiconductor industry the cost of systems
has gone down and computers have become cheaper. Thus the electronic systems are
installed in vehicles to provide safety, comfort, fuel efficiency, etc at affordable cost. Most
of these systems are supposed to operate in real-time e.g. engine control, chassis control.
[1] Real time systems are those systems in which the correctness of the system depends
not only on the logical result of computation, but also on the time at which the results
are produced. The tasks executing in such systems are required to meet their deadlines
otherwise some catastrophic results may occur. Throughput and average response are not
the primary goals of real-time systems. The main aim is to maximize the percentage of
tasks that meet their deadlines and guaranteeing that all critical tasks always meet their
deadlines [2].
Some automotive applications are safety-critical whose tasks must be scheduled by
some Real-time operating system. There are many issues in handling such applications
which are studied as a part of this seminar. Chapter 2 gives details about the requirements
for data, processing and communication in an automotive system. Chapter 3 discusses
the support that a real-time system provides to meet the above gathered requirements.
Chapter 4 concludes the work and discusses the future directions in this work.

1.1

Automotive applications

The automotive systems is a complex system consisting of various subsystems. These

subsystems span various controls of the vehicle. There are sensors for data acquisition
to monitor the various parameters in the vehicle. Each system is an embedded system
which has a computer processing data and carrying out actions on the vehicle. Some of
these applications are listed below :
Engine Control :
The engine control system detects throttle valve angle and controls the fuel injection
1

rate accordingly. It helps in meeting strict emission requirements which maximizes

the efficiency of fuel combustion to ensure cleaner exhaust and low fuel consumption.
Antilock brake system(ABS) :
Anti-Lock Braking Systems (ABS) are designed to maintain driver control and stability of the car during emergency braking. ABS allows maximum braking to be
applied while retaining the ability to steer out of trouble. The operation of ABS
can slightly reduce stopping distance in some cases like on wet road surfaces, but
it can increase the stopping distance in others, as may be the case in deep snow or
gravel.
Temperature Control (TC) :
The temperature inside the vehicle and various components is monitored using temperature controllers. Temperature Control, as its name implies, is an automatic
climate control system, which automatically controls interior temperature based on
the drivers demands and temperature information from various sources. TC does
this through direct interaction with the vehicles A/C and heating systems. Some
TC systems have separate zones, where different temperatures can be maintained
according to personal needs.
Active body control (ABC) :
Active Body Control is a semi active suspension, that virtually eliminates body roll
in many driving situations including cornering, accelerating, and braking. The systems computer detects body movement from sensors located throughout the vehicle,
and controls the action of the active suspension with the use of hydraulic servos.
Adaptive cruise control (ACC) :
Adaptive cruise control is a vehicle following technique designed to give comfort to
the driver from frequent brake/throttle control. The driver can set the cruise speed
for the vehicle on a highway. The ACC can detect any lead vehicle in the lane
and depending upon the relative speed between the vehicles and timegap set by the
driver it controls the vehicles acceleration.
Collision Avoidance(CA) :
The Collision Avoidance system prevents a collision when it perceives the dangerous
situation and automatically control the vehicle out of danger. When the driver fails
to perform the necessary emergency maneuver, a collision avoidance system will
take the control and brakes and/or steers the vehicle to avoid a collision.
Electronic stability control (ESC) :
ESC is an extension of antilock brake technology(ABS), which has speed sensors
and independent braking for each wheel. For ESC, additional sensors continuously
monitor how well a vehicle is responding to a drivers steering input. These sensors
detect when a vehicle is about to stray from the drivers intended line of travel, i.e.
lose control, which usually occurs in high-speed maneuvers or on slippery roads.
When it detects loss of control, stability control brakes individual wheels automatically to keep the vehicle under control.

 Brake/Throttle Control :
The vehicle can be accelerated or decelerated with these controls. The Brake/Throttle
control is achieved with controllers which send signals to the brake/throttle actuators which in turn carry out the operation. With the advent of brake-by-wire
and throttle-by-wire the controller has significance in the automotive systems for
efficient fuel usage and provides service to other applications.
Drive-by-wire Control :
Drive-by-wire is a technology of replacing the mechanical and hydraulic components
by electronic systems e.g. brake-by-wire, steer-by-wire, etc. In this system there are
no mechanical links between driver controls and the actuators. Instead such links
are replaced by communication links which send signals to the actuator controller.
Some of the application in the above list demand real-time support. For such applications
the data acquisition, processing and communication with other subsystems has to be
performed within a specified time constraint. One such applications called Adaptive
Cruise Control is studied in details.

1.2

Adaptive Cruise Control(ACC) : An overview

Adaptive Cruise Control is an extension to the Conventional Cruise Control and has
additional capability to maintain safe distance between vehicles. It provides assistance
to the driver in the task of longitudinal control of the vehicle. The system controls the
accelerator and vehicle brakes to maintain desired time gap from the vehicle ahead. ACC
performs the longitudinal following control task for a driver within limited acceleration
ranges.
ACC is an intelligent system that automatically adjusts vehicle speed to maintain
a driver selected distance from the vehicle ahead. Conventional cruise control has the
capability to maintain speed on highway when no lead vehicle is present. But when a
vehicle from other lane suddenly come in its path then the driver has to intervene. The
drivers response time is very crucial in such a situation to avoid collision. There is no
danger if the lead vehicle has higher speed compared to the cruise controlled vehicle. If
the speed of lead vehicle reduces then the system need to decelerate. This adaptive nature
is provided in Adaptive cruise control which tries to maintain safe distance, selected by
driver, from the lead vehicle. ACC is not a replacement for driver, it gives comfort to the
driver in critical times. The emphasis is on safely increasing driving comfort rather than
increasing road capacity.
[3] ACC is believed to reduce the risk of accidents, improve safety, increase capacity,
reduce fuel consumption and enhance overall comfort and performance for drivers. It
operates in high-speed motorway driving conditions and not suitable for high density and
low-speed traffic. Efficiency of traffic flow reduces due to larger inter-vehicular distances
selected by driver.

USER
INTERFACE

THROTTLE
ACTUATOR

VEHICLE
SENSORS

CONTROL
UNIT
BRAKE
ACTUATOR

RADAR
SENSOR

Figure 1.1: ACC Block Diagram

1.2.1

ACC system description

The system in figure 1.1 consists of radar and vehicle sensors, real-time data repository,
controllers and actuators. The radar sensors are used to detect the lead vehicle and measure its speed. The vehicle sensors are used to monitor vehicle speed and throttle/brake
positions. These sensors provide the latest information about the environment. This data
is stored in a real-time data repository which is updated to maintain consistency with the
actual environment.
There is a two-level controller for brake/throttle control. The upper-level controller
reads the data from repository and computes the data required for the lower-level controller. The upper-level controller is the adaptive cruise controller itself that calculates
the desired acceleration and sends signals to lower-level controller to carry out the action.
The lower-level controller actually carries out the action of sending signals to the actuators. The advantage in separating the controllers is to have independence of operation.
The upper-level controller represents the driver behavior and environmental status and is
independent of the vehicle to be controlled. The lower-level controller is highly dependent
on the vehicle dynamics but independent of the driver behavior [4].
ACC operates in following two modes depending upon whether lead vehicle is present
or not.
Speed Control
This is the conventional cruise control of vehicle where the vehicle maintains constant speed on a highway when no lead vehicle is present. This speed is set by the
driver. The driver has to intervene when a lead vehicle suddenly appears ahead of
host vehicle. If the lead vehicle decelerates at some point then the host vehicle must
also decelerates.
Distance Control
When the lead vehicle decelerates, the ACC must decrease the speed of host vehicle
to maintain safe-distance. In this mode the system can adjust the speed of vehicle so
as to maintain the separation between the vehicles. The driver sets the safe-distance
which is to be followed by the host vehicle in this mode.

Chapter 2
Requirements of Automotive systems
The requirements of any automotive system vary from system to system. Some system
demand real-time support in which stress is on freshness of data, timely processing of
data and error-free and timely communication with other systems. Adaptive Cruise Control(ACC) is studied with the following requirements. These include data acquisition,
processing and computation, and communication. This requirement analysis is helpful in
order to use appropriate algorithms and protocols for proper functioning of ACC. These
requirements put some restrictions on adopting algorithms or protocols to satisfy them.
In this chapter detailed requirements for automotive systems are presented which span
data, processing and communication.

2.1
2.1.1

Data Requirements
Automotive Data Requirements

The automotive applications have to continuously monitor the vehicle in order to know the
status of the vehicle. Each application is responsible for a certain subsystem in the vehicle
which needs data. This data is acquired from the sensors attached to the subsystem solely
for a specific task. The data in a system relates to sensor data and processed data. The
data can be classified into two parts :
base data
This real-world data which actually dictates the state of the system and environment
is called base data. This data is obtained by processing the raw data acquired from
the sensors. For example, the wheel sensors gives some data regarding the number
of rotations in a given time period and vehicle speed is computed. The driver set
safe-distance is also a base data which is an invariant data.
derived data
The derived data represents the data that is computed using the base data. For
example, the desired acceleration of vehicle can be calculated by processing the base
data.
The above data needs to be fresh i.e. it should be consistent with the environment
status. The actual velocity of vehicle should be accurately computed with the help of
5

sensor data. The acquired and computed data is stored in a database for further reference.
If the data becomes stale and is used for processing then some catastrophe may occur,
since current status may be totally different from the stored values. Thus, there is a
need to have temporally consistent data to avoid reading stale data and compute the
derived data values for safe driving of vehicle. The real-time database is responsible for
this consistency of data.

2.1.2

ACC Data Requirements

There are number of sensors in the vehicle which contribute to the functioning of the ACC.
The ACC has a radar to detect the lead vehicle and wheel sensors to get the vehicle speed
data. These sensors in ACC monitor the host vehicle and lead vehicle e.g. vehicle sensors
provide data such as host vehicles speed, throttle/brake positions, etc. and the radar
sensors provide data such as separation distance between both the vehicles, timegap, etc.
This data is called the base data which is used to calculate the required acceleration of
vehicle, throttle/brake actuator values, etc.
The data in ACC[5] consists of :
Wheel Speed : The wheel data is obtained from the wheel sensors. There are 4 wheel
sensors which provide independent data. Though there is redundancy of sensors, it
is essential when the terrain is rough. Thus data from one sensor can not dictate
the velocity of the vehicle.
Vehicle Speed : The vehicle speed is computed from the wheel data. There are four
wheel sensors that individually compute wheel rotations and send data periodically.
The fusion algorithm accepts this data and calculates the actual vehicle speed.
Desired Throttle Position : The desired acceleration of the vehicle is computed from
host vehicle velocity and lead vehicle velocity, the timegap between the vehicles,
driver-set timegap and current acceleration. The controller calculates this data and
sends it to the throttle actuator.
Current Throttle Position : The current throttle position is the feedback data that
is read from the throttle sensors. This is the measure of the current acceleration of
the vehicle.
Desired Vehicle Speed : The desired vehicle speed can be either the driver set cruise
speed or the speed required to maintain the separation between the vehicles. In
case of absence of any lead vehicle the desired vehicle speed should be set to the
driver-set speed. When a lead vehicle is detected the ACC gets operational and the
desired speed is computed based upon the separation required by the driver.
Desired Brake Actuator Position : When the lead vehicle decelerates the host vehicle also has to decelerate to maintain separation. The controller calculates the
deceleration values and send the corresponding values to the brake actuators.
Current Brake Actuator Position : The current brake actuator position is the feedback data that is read from the brake sensors. This data along with the current
6

throttle position is required in the closed loop control of the vehicle where the feedback data is used to reduce the error.
Driver Data : The driver of the vehicle can feed some data through the user-interface.
This data does not vary frequently depending upon the drivers requirements. For
example, the timegap or separation distance between the vehicle, cruise speed, etc.

2.2
2.2.1

Processing Requirements
Automotive Processing Requirements

In a automotive system there are various tasks that operate on data, accept data from a
subsystem, carry out computation on the data, outputs values to a subsystem, etc. Some
of these tasks are periodic in nature which execute at regular intervals of time e.g. the
sensor reading tasks are periodic so as to capture the real-world objects(base data) to
maintain consistency with the environment. Some tasks are aperiodic like the database
updation task, which computes and updates derived data before the data becomes outdated. In a real-time system tasks are characterized by their periods, worst-case execution
time and deadline [2]. The tasks executing in such systems are required to meet their
deadlines otherwise some catastrophic results may occur. The throughput and average
response are not the primary goals of real-time systems. The processing requires that
scheduling of tasks be done to maximize the percentage of tasks that meet their deadlines
and guaranteeing that all critical tasks always meet their deadlines. This strictness in
meeting the deadlines makes scheduling an important issue in the correctness and reliability of the system.

2.2.2

ACC Processing Requirements

There are various tasks responsible for operation of ACC. These tasks include sensor
reading, database updation, actuators signalling, etc. They are associated with deadlines
on their computations. It is the time constraints which adds complexity to the systems.
There is a need to satisfy the time-constraints of all tasks for proper functioning of ACC.
The real-time scheduling algorithms play a vital role in execution of these tasks.
The sensor reading tasks monitor the host vehicle and lead vehicle, and writes the
data into database. These tasks are periodic in nature which samples the sensor data at
regular intervals of time. The base data so acquired e.g. host velocity, lead-vehicle velocity,
and the derived data like timegap is stored in the first-level data repository. Thus, the
first-level repository represents the actual environmental and vehicle status. The secondlevel repository holds the data which satisfies the temporal validity of each data object.
Thus the second-level repository is updated only when certain condition is satisfied. This
makes the database updation tasks aperiodic in nature. Whenever there is a change in the
second-level repository, the upper-level controller is triggered which generates the desired
acceleration of the host vehicle depending upon the second-level data. The aperiodic
changes to the second-level repository makes the upper-level controller also aperiodic.

The lower-level controller operates on the input from upper-level controller. It is periodic
in nature which commands the throttle and brake actuators continuously. If there is no
change in the second-level repository then the upper-level controller does not perform any
computation so that the lower-level controller takes old values. Thus if data consistency is
not satisfied at the second-level repository, it can severely affect the operation of vehicle.
The tasks in ACC system can be classified based upon their timing constraints. Some
of these tasks are typical transactions in the real-time database system. But the timing
requirements are still valid for such transactions. In order to achieve data consistency
these tasks are to be scheduled in such a way as to satisfy all the timing constraints. The
next chapter gives details regarding the scheduling of tasks.

2.3

Communication Requirements

Nowadays electronics play an important role in many automotive applications e.g. steerby-wire, brake-by-wire and is expected to gradually replace the mechanical or hydraulic
means to control these systems. This not only reduces the weight of car but imparts faster
response to the user request. The number of electronic components in a car has therefore
significantly grown up. In-car bus networks are largely adopted that replace the extensive
wirings that interconnect electronic components. The steer-by-wire, brake-by-wire, etc
are commonly called X-By-Wire(XBW).
With the progress of XBW auto design, in-vehicle data traffic is ever growing. Conventionally, individual wire harnesses were used for data transfers between control units and
their associated sensors or display devices. As the number of control units and associated
devices increases, the numbers of wires and interconnections required is swelling. The
in-vehicle LAN provides an answer to this problem. It minimizes the use of wirings for
data exchanges and reduces both interconnections and vehicle weight. The in-vehicle LAN
demands reliable LAN components with minimum signal delays, so as to assure error-free
transfers of different types of data signals that share a single LAN cable.
The automotive system is nowadays a complex distributed system with various demands
of networking capabilities. There is a strong need of interaction between the various
components in an automotive application. One automotive application consists of several
Electronic Control Units(ECUs). These ECUs are interconnected for interaction and
carrying out specific control activity to satisfy the requirements of the application. In
near future hydraulic automotive systems, such as steering and braking, will be replaced
by communication networks.
Communication can be time-triggered or event-triggered. Time-triggered communication [6] uses time-division multiplexing(TDM) to allocate each message a unique access
time within a periodic transmission schedule. The time-triggered architecture (TTA)
uses this approach. It eliminates the need for an explicit collision-resolution mechanismeach transmitter determines its turn to access the network by checking a time reference.
Additionally, with timing entirely determined at design time, computation of worst-case
timing of messages becomes simple. Reduced flexibility in system design is the main
8

disadvantage of this approach. Communication and task scheduling on the control units
have to be synchronized during operation in order to satisfy strict timing requirements
of the system. The main advantage of event-triggered systems is their ability to quickly
react to asynchronous external events which are not known in advance. Thus, they show
a better real-time performance in comparison with time-triggered systems. In addition,
event-triggered systems possess a higher flexibility and can adapt to the actual demand
without a redesign of the complete system.

2.3.1

Automotive Communication Requirements

The requirements of an automotive communication network depend on the applications it

has to support. [7] Major automotive applications that involve networking and the usage
of fieldbuses are X-By-Wire, chassis systems, powertrain systems and infotainment or
multimedia, etc. The requirements of applications include fault-tolerance, determinism,
bandwidth, dependability, fault-containment etc. Some of them are listed below :
Composability : [8] An architecture is called composable with respect to a specified
property, if the system integration will not invalidate a property that has been established at the subsystem level. If a specified property holds for all components
at component level the integration of these components should exhibit the same
property at system level. Communication systems in the automotive environment
always include several autonomous ECUs that interact via a real-time communication service to achieve the desired system objectives. The complexity of such
systems requires composability which allows the design of smaller subsystems and
a following integration without any unintended side-effects.
Fault-tolerance : Fault tolerance uses redundancy of system resources to provide
alternate means of providing the system functionality and operation. This enables
the system to sustain one or more faults or errors, in a way that is transparent to
the operating environment and users. It prevents a fault from causing a failure, by
masking the effects of errors resulting from that fault.
Fault-Containment : This property assures that a fault is precluded from propagating and affecting system level performance. The fault extent describes the scope of
a fault: how far it propagates through the system, and which areas of the system are
effected. The boundary of this area is called the Fault Containment Region(FCR).
Dependability : This property supports the fault-tolerance strategies through active replication. The nodes of the system form a fault containment regions. This
property ensures that the functions of such FCRs should fail independently.
In case of XBW systems, the two most important requirements are dependability and
fault-containment. However, for chassis systems determinism is more important whereas
high bandwidth is needed in powertrain systems. Multimedia devices require high bandwidth and plug-n-play capabilities. Thus, different applications have different requirements. Numerous fieldbuses are used to address these various communication demands.
These networks follow different protocols amongst which we have to choose a set of protocols for our requirements.
9

2.3.2

ACC Communication Requirements

The ACC system has number of subsystems such as wheel sensor, radar sensors, two-level
data repository, two-level controller, throttle actuator, brake actuator, driver-interface.
The transactions in the data repository(real-time database) have to access the sensor
data. The controller has to read data from the repository and send data to the actuators.
Thus there is a need to interconnect the various subsystems in the ACC system. The data
must be communicated in real-time so that control tasks are carried on time and actions
take place at the right moment.
The ACC communication requirements include determinism and fault-tolerance. Bandwidth is not of much importance as the system is not concerned with speed of communication. The stress is on processing of error-free data made available within a specified
deadline. Thus, there is time constraint on the processing as well as availability of data.

10

Chapter 3
Real-time support for Automotive
systems
Adaptive Cruise Control is a safety critical application which is supported by the real-time
system. From the previous chapter it is clear that the data, processing and communication
need some kind of real-time support. This chapter is about the algorithms and protocols
that satisfy all the requirements of Automotive systems.
A real-time system is a system in which all tasks are guaranteed to execute without
missing their deadlines. [9] A real-time system consists of a controlling system and a
controlled system. The controlled system is an environment with which the computer
and its software interacts. The controlling system interacts with its environment based
on the data available from various sensors e.g. distance and speed sensors. The state
of the environment perceived by the controlling system should be consistent with the
actual state of the environment to a high degree of accuracy. Otherwise, the effects of
the controlling systems activities may be disastrous. Therefore, timely monitoring of the
environment as well as timely processing of the sensed information is necessary.

3.1
3.1.1

Real-time database support for Automotive systems

Real-time database

Data temporal consistency must be maintained in order for the tasks to deliver accurate
results in a timely fashion. In hard realtime system a result produced too late becomes
less useful and in some cases may even cause catastrophe. Timing constraints of a hard
realtime task include its deadline in addition to the temporal consistency of the data it
accesses. Data in a realtime system depicts the state of the real world and continuously
changes as the state of the real world changes. A task must read sufficiently current data
in order to deliver correct result. [10] Temporal consistency defined in terms of age and
dispersion of data, is concerned with the time characteristics of the data objects involved
in the computation. The age of the data object describes how up-to-date its value is, the
dispersion of two data objects is the difference in their ages. At any time instant, the
ages and dispersions of the data objects tell us whether the objects represent a timely
11

snapshot of the realworld at that instant. The data objects are said to be temporally
consistent if their ages and dispersions are sufficiently small to meet the requirements
of the application. Traditional databases deal with persistent data. Real-time database
deal with temporal data i.e. data that become outdated after certain time. Traditional
databases stress on the throughput and response time of transactions while real-time
databases stress on meeting deadline requirements for a transaction.
[9] The need to maintain consistency between the actual state of the environment and
the state as reflected by the contents of the database leads to the notion of temporal
consistency. It has two components :
1. Absolute consistency : Consistency between the state of the environment and the
stored state in the database.
2. Relative consistency : Consistency among the data used to derive other data. This
is required to maintain closeness among the values of data used to derive other data.
[9]A data item in real-time database is denoted by d : (value, avi, timestamp), where
dvalue is the current state of d and dtimestamp is the time when the observation relating
to d was made. davi is the absolute validity interval i.e. the length of the time interval
following timestamp during which d has absolute validity. The data value is supposed to
be updated within this validity interval. Let R be a set of data items used to derive a
new data item from relative consistency. Each such set R is associated with a relative
validity interval denoted by Rrvi .
Assume that d R. d has a correct state iff
1. dvalue is logically consistent i.e. it satisfies all integrity constraints.
2. d is temporally consistent i.e. it should have :
(a) absolute consistency : (current time dtimestamp ) davi
(b) relative consistency : d0 R, |dtimestamp d0 timestamp | Rrvi .

3.1.2

Real-time database support for ACC

A two-level data repository [11] is studied with an aim to provide temporal consistency to
the data. The figure shows a two-level data repository with repositories R1 and R2. The
first-level data repository R1 is used to store the base and derived data which represents
the current status of the environment. The frequency with which this data is updated
depends upon the sampling rates of the sensors. The second-level repository R2 keeps
track of the data that is currently responsible for the operation of the system. The R2
data is not updated frequently so as to avoid overhead. The updation of data is carried
before the validity interval is violated. Thus the R2 data may not be the replica of the
R1 data. The upper-level controller reads the data repository R2 to compute the desired
speed and corresponding accelerometer or brake actuator values. Thus small change in
the values of R1 does not affect the R2 data values which reduces the overhead of carrying
out some computational tasks.
The Real-time database described here not only ensures logical consistency of data
but also temporal consistency. There are number of concurrency-control protocols that
12

From
Speed
Sensors

REPOSITORY
R1

Update
R2

REPOSITORY

UpperLevel
Controller

R2
LowerLevel
Controller

From
RADAR
sensor

Raw Data Items

Base Data Items

+
Derived Data Items

BRAKE/THROTTLE
ACTUATORS

Figure 3.1: Two Level Repository Model

maintains the consistency of data. [12][13] describe details of the concurrency control
protocols.

3.2

Real-time processing support for Automotive systems

The tasks running in the Adaptive Cruise Control system are studied. Depending upon
their nature they are scheduled by a real-time scheduler. The scheduling algorithm is a set
of rules that determines the task to be executed at a particular moment. A group of tasks
is said to be schedulable if each task is guaranteed to be meet its deadline. Scheduling
these tasks on a processor so that real-time constraints are met is a difficult problem. The
following section describes few scheduling algorithms for a real-time system.

3.2.1

Real-time scheduling algorithms

The scheduling algorithms are broadly classified into two categories :

Static scheduling : Static scheduling decides the order of tasks execution according
to their priorities which are fixed once the system is designed.
Dynamic scheduling : Dynamic scheduling decides the order of tasks execution according to their priorities which undergo change as the tasks get ready for processing.
For static scheduling complete knowledge of the characteristics of the tasks is known
beforehand. The run-time cost is less but the system cannot adapt to the changes in the
environment. The dynamic scheduling algorithm plans the task schedule at run-time and
therefore can respond better to the changes in the environment. But the run-time cost
is high and there is a possibility of missing some deadlines. Dynamic scheduling cannot
ensure that all tasks will meet their deadlines. Thus, they may not be applicable to a
specific type of task known as safety critical task [14].
13

The scheduling decision of tasks is made by the algorithm based on the priority of the
tasks. Priority is a measure of the urgency of each task and can be determined either
statically at compile time or dynamically at runtime.
Rate Monotonic Algorithm(RMA)
The rate monotonic algorithm is a static priority preemptive scheduling algorithm
which assigns priority to the tasks based on their periods i.e. frequency of task
invocation. Thus it is applicable only for the periodic tasks. Larger the value
of period lower is the frequency and hence lower is the priority. The task with
higher request rate becomes active frequently, so it will get the control of CPU if
it has highest priority among the currently active tasks. The algorithm does not
consider the execution time of the tasks while assigning priorities to them. The ratemonotonic priority assignment is optimum i.e. no other fixed priority assignment
can schedule a task set which cannot be scheduled by the rate-monotonic priority
assignment. The feasibility of the schedule generated by this algorithm depends
upon the processor utilization. The processor utilization factor is the fraction of
processor time spent in the execution of the task set. For a task i the utilization
factor is Ci /Ti where Ci is the run-time and Ti is the time period. The utilization
factor for m tasks is given by
U=

m
X

(Ci /Ti )

i=1

The schedule is said to be feasible if the utilization factor U 0.693 [15].

Earliest Deadline First(EDF)
The earliest deadline first is a dynamic scheduling algorithm which assigns priority
to the tasks according to the deadline of their current requests. Thus the priority of
a task is not fixed and changes at run-time. The next scheduled task should be the
one whose deadline is the nearest. The feasibility of the EDF algorithm is similar
to RMA but here higher CPU utilization factor is desired as the processor idle time
decreases. For a given set of m tasks, the schedule generated by the EDF algorithm
is feasible if and only if U 1 [15]. The algorithm is optimum since a set of tasks
that can be scheduled by any algorithm can also be scheduled by EDF.
Constant Bandwidth Server(CBS)
The RMA and EDF are appropriate for scheduling periodic tasks. In case of aperiodic tasks i.e. tasks whose arrival time is unknown, the CBS is used. This technique
reserves a share of processor bandwidth for each of the aperiodic tasks in the system. CBS provides hard real-time services guarantees to the aperiodic tasks if the
worst case execution parameters are known. In CBS each aperiodic task is assigned
a fraction of the CPU and it is scheduled in such a way that it will never demand
more than its reserved bandwidth. The tasks are assigned deadlines computed as a
function of the reserved bandwidth and its actual CPU requests. The CBS assigns
each job an initial deadline, which is postponed each time the task is demanding
more than the reserved bandwidth.
14

3.2.2

Scheduling of ACC tasks

There are various tasks running in the Adaptive Cruise Control system. Some of these
are periodic and some are aperiodic in nature. The sensor tasks have periodic nature as
they have to continuously monitor the environment and the vehicle. While the R2 data
repository updation and upper-level controller tasks are aperiodic in nature.
RMA : The Rate Monotonic Algorithm is suitable for periodic tasks like the sensor
tasks. The priorities can be set to the various sensor tasks based on their periodicity. Though EDF is also suitable for periodic tasks, it is not used for safety-critical
application like ACC. There are sensor tasks that monitor host-vehicle, lead vehicle,
brake/throttle positions, and lower-level controller tasks that periodically sends signals to the brake/throttle actuators. These tasks must be periodic so as to monitor
the current status of the environment and vehicle, and output controlling parameters to control the vehicle. Thus, RMA is a suitable scheduling algorithm for such
tasks.
CBS : The CBS is suitable for aperiodic tasks like tasks which carry out the updation of the second-level data repository. These tasks become active when the data
needs to be refreshed to maintain temporal consistency. Their time of activation is
unknown and hence they do not have periodic behavior. There are various tasks
on ACC system in this category like R2 repository update tasks and upper-level
controller tasks.

3.3

Communication support for Automotive systems

In the previous chapter the communication requirements are pointed out for different automotive applications. In this chapter various communication network technologies are
studied which satisfy the requirements. All the requirements cannot be satisfied by one
protocol due to its shortcomings. Hence, depending upon requirements, a specific network is selected. Thus a automotive system has a inter-network of various communication
networks.
Some safety-critical applications require a deterministic behavior of message transmissions. A certain transmission latency of all safety-related messages must be guaranteed
even at peak-load. Time-triggered communication protocols can provide the deterministic behavior. In addition to hard real-time performance, they support composability and
dependability. As a consequence, time-triggered protocols are becoming more and more
accepted as the communication infrastructure for safety-critical applications.

3.3.1

Communication protocols

The Electronic Control Units are interconnected to provide real-time communication so

that control activities are ensured to satisfy their timing requirements. This communication takes place through various technologies which are briefly explained here. Common
fieldbus technologies interconnecting ECUs today are Controller Area Network(CAN),
15

the Local Interconnect Network(LIN), Byteflight and the Media Oriented Systems Transport(MOST). Their detailed explanation is given in [7] which is as follows :
Controller Area Network (CAN) : The CAN is most widely used vehicular network
for intra-vehicular communication. The CAN communication protocol is a carriersense multiple-access protocol with collision detection and arbitration on message
priority (CSMA/CD+AMP). CSMA means that each node on a bus must wait for
a prescribed period of inactivity before attempting to send a message. CD+AMP
means that collisions are resolved through a bit-wise arbitration, based upon a
preprogrammed priority of each message in the identifier field of a message. The
higher priority identifier always wins bus access. CAN transmits message frames in
an event triggered fashion.
Frames can be transmitted at speeds of up to 1 Mbps. The engine control, Anti-lock
Braking System and ACC require 500 Kbps for which CAN can be suitable. The
comfort electronics need around 125 Kbps. CAN is very good in handling eventtriggered traffic, and today it can be found on many systems in a car, ranging from
engine control and ABS-systems to body and comfort systems. [16] Advantages of
CAN are flexibility and ability to achieve a high average performance through multiplexing of bandwidth between communicating components. However, CAN lacks
essential properties for systems that have substantial timeliness and dependability
requirements. CAN protocol lacks multicast mechanism and fault-tolerance.
Local Interconnect Network (LIN) : The Local Interconnect Network is a time-triggered
master-slave fieldbus. It is an inexpensive network that is used in automotive systems to control devices such as seat control, light sensors and climate control which
do not demand much bandwidth. Thus lower bandwidth applications are well supported by LIN. The frames are sent at speed of 20 Kbps. It is chiefly used for body
control as a communication path that connects various sensors to the CAN network.
Byteflight : It is a flexible TDMA network using star topology. Messages are sent
at speed of 10 Mbps. Physical medium is plastic optical fiber. It supports event
triggered message transmission. Byteflight guarantees deterministic (constant) latencies for a bounded number of high priority real-time messages. Applications
supported by Byteflight are airbag systems and rearbelt tensioners which demand
faster response.
Media Oriented Systems Transport(MOST) : MOST supports multimedia applications and time and event triggered traffic with predictable frame transmission at
speeds of 25 Mbps. It uses plastic optical fibre as communication medium. It is used
for interconnection of telematics(Automotive telematics refers to any kind of vehicle
information or communication service that relies on a wireless communication link)
and infotainment such as video display, active speakers and digital radios.
Latest Communication protocols :
The latest technologies like XBW systems demand fault-tolerant communication
with deterministic message transmissions and low jitter. For such systems Time
16

Division Multiple Access(TDMA) protocols are used that supports deterministic

nature. Three common TDMA based fieldbuses for automotive applications are
TT-CAN, TTP and FlexRay. They differ in their bandwidth and fault-tolerant
capabilities. The following is the list of communication protocols preferred in latest
technologies.
Time-Triggered CAN (TT-CAN) : TT-CAN is an extension of the CAN protocol. It
is a time triggered session layer on top of CAN. This allows both time-triggered and
event triggered traffic. The communication is based on the periodic transmission of
a reference message by a time master. Based on this time the different messages are
assigned time window in the basic cycle. It can provide deterministic behavior due
to time-triggering capability. However, since it relies on the CAN lower layers, it is
lacking fault-tolerant mechanisms and bandwidth capabilities. Hence, TT-CAN is
not commonly suggested for XBW solutions today.
Time Triggered Protocol (TTP) : The TTP is a pure time triggered TDMA protocol. TTP frames are sent at speeds of 5-25 Mbps depending on physical medium.
TTP is a highly fault-tolerant network developed and intended for safety-critical
systems such as XBW and avionics. TTP is very deterministic at the cost of being less flexible in terms of message transmissions compared with FlexRay. Due to
inflexible message transmission and high cost the use of another fieldbus would be
needed for other applications such as powertrain where high bandwidth together
with event-triggered capabilities are needed. The communication network topology
is a broadcast bus.
FlexRay : FlexRay is supposed to fulfill future requirements of next generation
automotive systems especially for XBW and powertrain applications. It is a deterministic, fault-tolerant and high bandwidth system. This technology provides both
time-triggered and event-triggered message transmission. It is suitable for both
powertrain systems which demands high bandwidth and event-triggered operation
and XBW systems which demands dependability and fault-containment.
FlexRay protocol supports :
1. Flexibility and determinism
2. Fault-tolerant clock synchronization via a global time base
3. Collision-free bus access and guaranteed message latency
4. Message oriented addressing via identifiers
5. Scalable system fault-tolerance with either single or dual channels.

3.3.2

Communication protocols for ACC

The sensor data sent by the vehicle sensors and radar sensor must be read continuously
and without any delay. Such a communication must be deterministic. Since the data is the
only way the ACC system can know about the current status, a communication failure may
cause catastrophe. Thus communication mechanism has to be fault tolerant. For real-time
behavior of the system determinism and fault tolerance must be guaranteed. The sensor
17

tasks and the lower-level controller tasks are periodic so time-triggered communication
is needed to transfer data. The updation tasks for second-level data repository and
the upper-level controller are aperiodic so they behave in event-triggered fashion. Thus,
ACC needs both the types of communication systems. TT-CAN being a time-triggered
protocol, is suitable for deterministic communication required for the interaction between
the components of ACC. But TT-CAN is CAN based so it is not fault-tolerant. The
FlexRay supports both the event and time triggered communication apart from being
fault-tolerant, deterministic and dependable. It appears to be the best choice as it satisfies
most of the requirements of the ACC system.

18

Chapter 4
Conclusions and Future Work
4.1

Conclusions

The study of the automotive embedded systems has been carried out. Adaptive Cruise
Control is one such application that is studied. The study has highlighted the requirements
of these systems from data, processing and communication point of view. The crucial data
required in such applications are studied and various processing and communication tasks
are classified based upon their characteristics. The tasks and the data have strict timing
constraints which must be satisfied. Hence, the need of real-time system is realized that
supports the automotive application. Requirements analysis is carried out for general
automotive systems with ACC as a specific application. This includes data, processing
and communication requirements which is essential for selection of appropriate protocols
and algorithms. The study has detailed out real-time scheduling protocols and realtime communication protocols. Once the application specific requirements are recognized,
appropriate protocols and algorithms are adopted to meet these requirements.

4.2

Future Work

The study has been done to understand data, processing and communication requirements alongwith real-time support to satisfy them. The future work lies in the
integration of all these concepts in building an automotive application.
The real-time concepts like real-time databases, scheduling and real-time communication are studied in general sense. The OSEK/VDX (Open systems and corresponding interfaces for automotive electronics / Vehicle Distributed eXecutive) is
a standard, which includes specifications for an embedded operating system, communication subsystem, and an embedded network management system. The OSEK
compliant Real-Time Operating System has to be studied for implementation of a
automotive application.
Here intra-vehicular communication is studied which can be extended for intervehicular and road-side communication. This will help in gathering more information about the objects in the vicinity of the vehicle.

19

 Wireless communication is one area that can be explored.

The practical aspects of schedulability analysis have to be focused. This will help
in better understanding of the real-time systems.
Flash-based database can be implemented in the automotive embedded system for
data storage.

20

References
[1] Krithi Ramamritham, John A. Stankovic. Scheduling algorithms and operating systems
support for real-time systems. Proceedings of the IEEE, 82(1):5567, Jan 1994.
[2] John A. Stankovic and Krithi Ramamritham. The spring kernel: A new paradigm for
real-time systems. IEEE Software., 8(3):6272, 1991.
[3] Ardalan Vahidi, Azim Eskandarian. Research advances in intelligent collision avoidance
and adaptive cruise control. IEEE Transactions on Intelligent Transportation Systems,
4(3):143153, Sep 2003.
[4] Mikael P., Fredrik B., Erik H., and Rolf J. Stop & go controller for adaptive cruise control.
IEEE International Conference on Control Applications, pages 16921697, Aug 1999.
[5] Gurulingesh. R. Adaptive cruise control. Masters thesis, Indian Institute of Technology,
Bombay, 2005.
[6] Amos Albert, Robert Bosch. Comparison of event-triggered and time-triggered concepts
with regard to distributed control systems. Proceedings of Embedded World Conference,
17:235252, 2004.
[7] Thomas Nolte, Hans Hansson, and Lucia Lo Bello. Implementing next generation automotive communications. In Proceedings of the 1st Embedded Real-Time Systems Implementation Workshop (ERTSI04) in conjunction with the 25th IEEE International Real-Time
Systems Symposium (RTSS04), Lisbon, Portugal, December 2004.
[8] E Dilger, L.A.Johansson, H. Kopetz. Towards an architecture for safety related fault tolerant systems in vehicles. In Proceedings of the ESREL 97 International Conference, Lisbon,
Portugal, June 1997.
[9] Bhaskar Purimetla, Rajendran M. Sivasankaran, Krithi Ramamritham, and John A.
Stankovic. Real-time databases: Issues and applications. Advances in real-time systems,
pages 487507, 1995.
[10] Song X., Jane W.S. Liu. How well can data temporal consistency be maintained? In
Proceedings IEEE Symposium on Computer-Aided Control System Design, pages 275284,
1992.
[11] Neera Sharma. Design of adaptive cruise control-applying a time-critical databased aproach.
Masters thesis, Indian Institute of Technology, Bombay, 2005.
[12] Lui Sha, Sang Hyuk Son, Ragunathan Rajkumar, and Chun-Hyon Chang. A real-time
locking protocol. IEEE Transactions on Computer., 40(7):793800, 1991.

21

[13] Jiandong Huang, John A. Stankovic, Krithi Ramamritham, and Donald F. Towsley. Experimental evaluation of real-time optimistic concurrency control schemes. In VLDB 91:
Proceedings of the 17th International Conference on Very Large Data Bases, pages 3546,
San Francisco, CA, USA, 1991. Morgan Kaufmann Publishers Inc.
[14] John Stankovic. S. Biyabani, K. Ramamritham. The integration of deadline and criticalness
in hard real-time scheduling. In Proceedings of the Real-Time Systems Symposium, 1988.
[15] C. L. Liu and James W. Layland. Scheduling algorithms for multiprogramming in a hardreal-time environment. Journal of the ACM, 20(1):4661, 1973.
[16] CAN Emulation in a Time-Triggered Environment An Overview, TTTech.

22