CS 404 Embedded Systems

Module 1

Fundamentals of Embedded Systems- complex systems and microprocessors- Embedded

system design process .Specifications- architecture design of embedded system design
of hardware and software components- structural and behavioural description

1. I NTRODUCTION:

Embedded system is a computer system with dedicated function within larger

mechanical or electrical system often with real time computing constarints

 An ES is an electronic/electro-mechanical system designed to perform a specific

function and is a combination of both hardware and firmware (software).
Embedded Systems - Classification based on Generation

 First Generation: The early embedded systems built around 8-bit microprocessors
like 8085 and Z80 and 4-bit microcontrollers
EX. stepper motor control units, Digital Telephone Keypads etc.

 Second Generation: Embedded Systems built around 16-bit microprocessors and 8 or

16-bit microcontrollers, following the first generation embedded systems
 EX.SCADA, Data Acquisition Systems etc.

 Third Generation: Embedded Systems built around high performance 16/32 bit
Microprocessors/controllers, Application Specific Instruction set processors like
Digital Signal Processors (DSPs), and Application Specific Integrated Circuits
(ASICs).Theinstruction set is complex and powerful.
 EX. Robotics, industrial process control, networking etc

 Fourth Generation: Embedded Systems built around System on Chips (SoC’s), Re-
configurable processors and multicore processors. It brings high performance, tight
integration and miniaturization into the embedded device market
 EX Smart phone devices, MIDs etc

Embedded Systems - Classification based on Complexity & Performance

2. On complexity & performance

(i) Small-scale Embedded Systems:
 Simple in application need
 Performance not time-critical.
 Built around low performance & low cost 8 or 16 bit μp/μc.
Example: an electronic toy
(ii) Medium-scale Embedded Systems:

1
  Slightly complex in hardware & firmware requirement.
 Built around medium performance & low cost 16 or 32 bit μp/μc.
 Usually contain operating system.
Examples: Industrial machines.
(iii)Large-scale Embedded Systems:
 Highly complex hardware & firmware.
 Built around 32 or 64 bit RISC μp/μc or PLDs or Multicore Processors.
 Response is time-critical.
Examples: Mission critical applications.

Embedded Systems - Classification Based on deterministic behavior:

It is applicable for Real Time systems. The application/task execution behavior for an
embedded system can be either deterministic or non-deterministic

 These are classified in to two types

1. Soft Real time Systems: Missing a deadline may not be critical and can be
tolerated to a certain degree
2. Hard Real time systems: Missing a program/task execution time deadline can
have catastrophic consequences (financial, human loss of life, etc.)

Embedded Systems - Classification Based on Triggering:

These are classified into two types

Event Triggered : Activities within the system (e.g., task run-times) are dynamic and
depend upon occurrence of different events .
Time triggered: Activities within the system follow a statically computed schedule
(i.e., they are allocated time slots during which they can take place) and thus by
nature are predictable

1.1 Comparison of ES & General Purpose Computing System

Criteria General Purpose Computer Embedded System

Contents A system which is a combination ofA system which is a combination of
a generic hardware and a Generalspecial purpose hardware and embedded
Purpose Operating System forOS/firmware for executing a specific set
executing a variety of applications. of applications

OS It contains a It may or not contain an

general purpose operatingOS for functioning.
system (GPOS).
Alterations Applications are alterable by theApplications are not-alterable by
user. the user.

2
Key factor Performance is key factor. Application specific requirements are key
factors.
Power More Less
Consumption
Response Not critical Critical for some applications
Time
Execution Need not be deterministic Deterministic for certain types of ES like
‘Hard Real Time’ systems.

Typical embedded system

 A typical embedded system contains a single chip controller, which acts as the master
brain of the system.

 The controller can be a Microprocessor or a microcontroller or a Field Programmable

Gate Array (FPGA) device or a Digital Signal Processor (DSP) or an Application
Specific Integrated Circuit (ASIC)/ Application Specific Standard Product (ASSP).

 Embedded hardware/software systems are basically designed to regulate a physical

variable or to manipulate the state of some devices by sending some control signals
to the Actuators or devices connected to the o/p ports of the system, in response to
the input signals provided by the end users or Sensors which are connected to the
input ports.

 Keyboards, push button switches, etc. are examples for common user interface input
devices whereas LEDs, liquid crystal displays, piezoelectric buzzers, etc. are
examples for common user interface output devices for a typical embedded system.

 For example, if the embedded system is designed for any handheld application, such
as a mobile handset application, then the system should contain user interfaces like a
keyboard for performing input operations and display unit for providing users the
status of various activities in progress.

3
2. COMPLEX SYSTEM AND MICROPROCESSORS:

“An embedded system is a system that has software embedded into computer-hardware, which makes
a system dedicated for an application (s) or specific part of an application or product or part of a large
system”. Its software usually embeds into a ROM (Read Only Memory) or flash.” It has 3 main
components embedded into it.
Three main tasks or components in embedded system design:

 It embeds hardware similar to a computer.

 It embeds main application software generally into a flash or ROM and so the
application software performs concurrently the number of tasks.

 It embeds a Real Time Operating System, or an RTOS which supervises the application
software. It enables the execution of concurrent tasks. The RTOS, in effect, sets the
framework of rules during the execution of application processes so as to enable
finishing of a process in good time and with the appropriate priority.

In simple words, Embedded System = (Hardware + Software) dedicated for a particular

task with its own memory.

Embedded computing system design is a useful skill for many types of product design. Automobiles,
cell phones, and even household appliances make extensive use of microprocessors.

4
2.1 Embedding Computers:

Computers have been embedded into applications since the earliest days of computing

APPLICATIONS OF EMBEDDED SYSTEMS IN VARIOUS SECTORS:

We can find applications of embedded systems in following sectors:

a. Daily Life Electronic appliances( Lift, Microwave Oven, Refrigerator, Washing

Machine)

b. Health Care( X-ray, ECG, Cardiograph, diseases diagnosis devices etc)

c. Education (Laptop or desktop, projector, printer, calculator, lab equipments

etc)

d. Communication( Mobile phone, satellite, Modem, Network Hub, Router,

Telephone, Fax)

e. Security System( CC Camera, X ray Scanner, RFID System, Password protected

door, Face detection)

f. Entertainment(Television etc)

g. Banking System(ATM etc)

h. Automation

i. Navigation

j. Consumer Electronics: Camcorders, Cameras.

k. Household appliances: Washing machine, Refrigerator.

l. Automotive industry: Anti-lock breaking system(ABS), engine control.
m. Home automation & security systems: Air conditioners, sprinklers, fire alarms.
n. Telecom: Cellular phones, telephone switches.
o. Computer peripherals: Printers, scanners.
p. Computer networking systems: Network routers and switches.
q. Healthcare: EEG, ECG machines.
r. Banking & Retail: Automatic teller machines, point of sales.
s. Card Readers: Barcode, smart card readers.
2.2 Characteristics of Embedded Computing Applications:
a. Complex Algorithms
b. User Interface
c. Real Time
d. Multirate
e. Manufacturing Cost non functional requirements

5
 f. Power
■Complex algorithms: The operations performed by the microprocessor may be very sophisticated.
For example, the microprocessor that controls an automobile engine must perform complicated
filtering functions to optimize the performance of the car while minimizing pollution and fuel
utilization.
■User interface: Microprocessors are frequently used to control complex user interfaces that may
include multiple menus and many options. The moving maps in Global Positioning System (GPS)
navigation are good examples of sophisticated user interfaces.

To make things more difficult, embedded computing operations must often be performed to meet
deadlines:
■Real time: Many embedded computing systems have to perform in real time—if the data is not
ready by a certain deadline, the system breaks. In some cases, failure to meet a deadline is unsafe and
can even endanger lives
Hard real time: Missing deadline causes failure
Soft real time: Missing deadline causes degraded performances
■Multirate: must handle operation at varying rate

Costs of various sorts are also very important:

■Manufacturing cost: The total cost of building the system is very important in many cases.
Manufacturing cost is determined by many factors, including the type of microprocessor used, the
amount of memory required, and the types of I/O devices.
■Power and energy: Power consumption directly affects the cost of the hardware, since a larger
power supply may be necessary. Energy consumption affects battery life, which is important in many
applications, as well as heat consumption, which can be important even in desktop applications.

2.3 Why Use of Microprocessors to design digital systems:

There are many ways to design a digital system: custom logic, field-programmable gate arrays
(FPGAs), and so on. Why use microprocessors? There are two answers:
i. Microprocessors are a very efficient way to implement digital systems.
ii. Microprocessors make it easier to design families of products that can be built to provide
various feature sets at different price points and can be extended to provide new features to
keep up with rapidly changing markets.
iii. Predesigned instruction set processor may in fact result in faster implementation of your
application than designing your own custom logic.
iv. But there are two factors that work together to make microprocessor-based designs fast.

6
 a) First, microprocessors execute programs very efficiently. Modern RISC processors can
execute one instruction per clock cycle most of the time and high performance processors can
execute several instructions per cycle.
b) Second, microprocessor manufacturers spend a great deal of money to make their CPUs
run very fast. With the slight changes designer can make the microprocessor to run at the
highest possible speed.
v. Microprocessors are efficient utilizers of logic
vi. Microprocessors can be used for many different algorithms simply by changing the program it
executes.
vii. The microprocessors allows program design to be separated from the design of hardware on
which programs will be running.

2.4 Challenges in Embedded Computing System Design:

i. How much hardware do we need?
ii. How do we meet deadlines?
iii. How do we minimize power consumption?
iv. How do we design for upgradability?
v. Does it really work?
vi. Complex testing
vii. Limited observability and controllability
viii. Restricted development environments

External constraints are one important source of difficulty in embedded system design. Let’s consider
some important problems that must be taken into account in embedded system design.
How much hardware do we need?
We have a great deal of control over the amount of computing power we apply to our problem. We
cannot only select the type of microprocessor used, but also select the amount of memory, the
peripheral devices, and more. Since we often must meet both performance deadlines and
manufacturing cost constraints, the choice of hardware is important—too little hardware and the
system fails to meet its deadlines, too much hardware and it becomes too expensive.
How do we meet deadlines?
The brute force way of meeting a deadline is to speed up the hardware so that the program runs faster.
Of course, that makes the system more expensive. It is also entirely possible that increasing the CPU
clock rate may not make enough difference to execution time, since the program’s speed may be
limited by the memory system.
How do we minimize power consumption?

7
In battery-powered applications, power consumption is extremely important. Even in non battery
applications, excessive power consumption can increase heat dissipation. One way to make a digital
system consume less power is to make it run more slowly, slowing down the system can obviously
lead to missed deadlines. Careful design is required to slow down the noncritical parts of the machine
for power consumption while still meeting necessary performance goals.
How do we design for upgradability?
The hardware platform may be used over several product generations or for several different versions
of a product in the same generation, with few or no changes. However, we want to be able to add
features by changing software.
Does it really work?
Reliability is always important when selling products—customers rightly expect that products they
buy will work. Reliability is especially important in some applications. If we wait until we have a
running system and try to eliminate the bugs, we will be too late—we won’t find enough bugs, it will
be too expensive to fix them, and it will take more time.

Let’s consider some ways in which the nature of embedded computing machines makes their design
more difficult.
■Complex testing: Exercising an embedded system is generally more difficult than typing in some
data. We may have to run a real machine in order to generate the proper data. The timing of data is
often important, meaning that we cannot separate the testing of an embedded computer from the
machine in which it is embedded.
■Limited observability and controllability: Embedded computing systems usually do not come with
keyboards and screens. This makes it more difficult to see what is going on and to affect the system’s
operation. We may be forced to watch the values of electrical signals on the microprocessor bus, for
example, to know what is going on inside the system. Moreover, in real-time applications we may not
be able to easily stop the system to see what is going on inside.
■Restricted development environments: The development environments for embedded systems (the
tools used to develop software and hardware) are often much more limited than those available for
PCs and workstations. We generally compile code on one type of machine, such as a PC, and
download it onto the embedded system. To debug the code, we must usually rely on programs that run
on the PC or workstation and then look inside the embedded system.
3. EMBEDDED SYSTEM DESIGN PROCESS:

Designing can be done in two ways. They are

■ Top down
■ Bottom –up

8
 Figure 1.1 summarizes the major steps in the embedded system design process. In this top–down
view, we start from the system requirements. In bottom up approach we start with components.
Specification, we create a more detailed description of what we want. But the specification states only
how the system behaves, not how it is built. The details of the system’s internals begin to take shape
when we develop the architecture, which gives the system structure in terms of large components.
Once we know the components we need, we can design those components, including both software
modules and any specialized hardware we need. Based on those components, we can finally build a
complete system. In this section we will consider design from the top–down—we will begin with the
most abstract description of the system.
The alternative is a bottom–up view in which we start with components to build a system.
Bottom–up design steps are shown in the figure as dashed-line arrows. We need bottom–up design
because we do not have perfect insight into how later stages of the design process will
turn out.

Fig 1.1: Major levels of abstraction in design process

We need to consider the major goals of the design:
■manufacturing cost;
■performance (both overall speed and deadlines); and
■power consumption.
We must also consider the tasks we need to perform at every step in the design process. At each step
in the design, we add detail:
■We must analyze the design at each step to determine how we can meet the specifications.
■We must then refine the design to add detail.
■And we must verify the design to ensure that it still meets all system goals, such as cost, speed, and
so on.
3.1 Requirements

9
 Clearly, before we design a system, we must know what we are designing. The initial stages
of the design process capture this information for use in creating the architecture and
components. We generally proceed in two phases:
1. First, we gather an informal description from the customers known as requirements;
2. second we refine the requirements into a specification that contains enough information to
begin designing the system architecture.
Separating out requirements analysis and specification is often necessary because of the large
gap between what the customers can describe about the system they want and what the
architects need to design the system. Requirements may be functional or nonfunctional.
Typical nonfunctional requirements include:
■Performance: The speed of the system is often a major consideration both for the usability of the
system and for its ultimate cost. As we have noted, performance may be a combination of soft
performance metrics such as approximate time to perform a user-level function and hard deadlines by
which a particular operation must be completed.
■Cost: The target cost or purchase price for the system is almost always a consideration. Cost
typically has two major components:
 Manufacturing cost includes the cost of components and assembly
 Nonrecurring engineering (NRE) costs include the personnel and other costs of designing
the system.
■Physical size and weight: The physical aspects of the final system can vary greatly depending upon
the application. An industrial control system for an assembly line may be designed to fit into a
standard-size rack with no strict limitations on weight. A handheld device typically has tight
requirements on both size and weight that can ripple through the entire system design.
■Power consumption: Power, of course, is important in battery-powered systems and is often
important in other applications as well. Power can be specified in the requirements stage in terms of
battery life.
Validating a set of requirements is ultimately a psychological task since it requires
understanding both what people want and how they communicate those needs. One good way to
refine at least the user interface portion of a system’s requirements is to build a mock-up. The mock-
up may use scanned data to simulate functionality in a restricted demonstration, and it may be
executed on a PC or a workstation.
Requirements analysis for big systems can be complex and time consuming. However,
capturing a relatively small amount of information in a clear, simple format is a good start towards
understanding system requirements. As part of system design to analyze requirements, we will use a
simple requirements methodology. Figure 1.2 shows a sample requirements form that can be filled
out at the start of the project. Let’s consider the entries in the form:

10
 Name
Purpose
Inputs
Outputs
Functions
Performance
Manufacturing cost
Power
Physical size and weight

FIG 1.2: Sample requirements form.

■Name: This is simple but helpful. Giving a name to the project should tell the purpose of the
machine.
■Purpose: This should be a brief one- or two-line description of what the system is supposed to do. If
you can’t describe the essence of your system in one or two lines, chances are that you don’t
understand it well enough.
■Inputs and outputs: These two entries are more complex than they seem. The inputs and outputs to
the system encompass a wealth of detail:
— Types of data: Analog electronic signals? Digital data? Mechanical inputs?
— Data characteristics: Periodically arriving data, such as digital audio samples? How many bits per
data element?
— Types of I/O devices: Buttons? Analog/digital converters? Video displays?
■Functions: This is a more detailed description of what the system does. A good way to approach
this is to work from the inputs to the outputs: When the system receives an input, what does it do?
How do user interface inputs affect these functions? How do different functions interact?
■Performance: Many embedded computing systems spend at least some time to control physical
devices or processing data coming from the physical world. In most of these cases, the computations
must be performed within a certain time.
■Manufacturing cost: This includes primarily the cost of the hardware components. Even if you
don’t know exactly how much you can afford to spend on system components, you should have some
idea of the eventual cost range. Cost has a substantial influence on architecture.
■Power: Similarly, you may have only a rough idea of how much power the system can consume, but
a little information can go a long way. Typically, the most important decision is whether the machine
will be battery powered or plugged into the wall. Battery-powered machines must be much more
careful about how they spend energy.

11
■Physical size and weight: You should give some indication of the physical size of the system that
helps to take architectural decisions.

After writing the requirements, you should check them for internal consistency. To practice the
capture of system requirements, Example 1.1 creates the requirements for a GPS moving map system.
Example 1.1
Requirements analysis of a GPS moving map
The moving map is a handheld device that displays for the user a map of the terrain around the user’s
current position; the map display changes as the user and the map device change position. The moving
map obtains its position from the GPS, a satellite-based navigation system. The moving map display
might look something like the following figure.

What requirements might we have for our GPS moving map? Here is an initial list: ■Functionality:
This system is designed for highway driving and similar uses. The system should show major roads
and other landmarks available in standard topographic databases.
■User interface: The screen should have at least 400_600 pixel resolution. The device should be
controlled by no more than three buttons. A menu system should pop up on the screen when buttons
are pressed to allow the user to make selections to control the system.
■Performance: The map should scroll smoothly. Upon power-up, a display should take no more than
one second to appear, and the system should be able to verify its position and display the current map
within 15 sec.
■Cost: The selling cost of the unit should be no more than $100.
■Physical size and weight: The device should fit comfortably in the palm of the hand.
■Power consumption: The device should run for at least eight hours on four batteries.

12
Requirements form for GPS moving map system:
Name GPS moving map
Purpose Consumer-grade moving map for driving use
Inputs Power button, two control buttons
Outputs Back-lit LCD display 400 _ 600
Functions Uses 5-receiver GPS system. Three user-selectable
Resolutions: always display current latitude and l
longitude
Performance Updates screen within 0.25 seconds upon movement
Manufacturing cost $30
Power 100mW
Physical size and weight No more than 2” _ 6,” 12 ounces

The selling price is four to five times the cost of goods sold (the total of all the component costs).
3.2 Specification
 The specification is more precise—it serves as the contract between the customer and the
architects.
 The specification must be carefully written so that it accurately reflects the customer’s
requirements and that can be clearly followed during design.
 The specification should be understandable enough so that someone can verify that it meets
system requirements and overall expectations of the customer.
 It should also be unambiguous enough that designers know what they need to build. An unclear
specification leads different types of problems. If the behavior of some feature in a particular
situation is unclear from the specification, the designer may implement the wrong functionality.
 The specification form should be correct and complete. If the specifications are wrong or
incomplete, the overall system architecture derived from the specification may be inadequate to
meet the needs of implementation.
A specification of the GPS system would include several components:
■Data received from the GPS satellite constellation.
■Map data.
■ User interface.
■Operations that must be performed to satisfy customer requests.
■Background actions required to keep the system running, such as operating the GPS receiver.

3.3 Architecture Design

13
The architecture is a plan for the overall structure of the system that will be used later to design the
components that make up the architecture.
To understand what an architectural description is, let’s look at sample architecture for the moving
map of Example 1.1. Fig1.3 shows sample system architecture in the form of a block diagram that
shows major operations and data flows among them.

.
Fig 1.3: Block diagram for the moving map

14
For more implementation details we should refine that system block diagram into two block diagrams:
 Hardware block diagram (Hardware architecture)
 Software block diagram(Software architecture)
These two more refined block diagrams are hardware and software block diagrams. Figure 1.4 shows
hardware block diagram, we have one central CPU surrounded by memory and I/O devices.

Fig 1.4: Hardware architecture for moving map

In particular, we have chosen to use two memories:
1. Frame buffer— to store the pixels to be displayed
2. Memory—to store program/data memory for general use by the CPU.
Fig 1.5 shows software block diagram, closely follows the system block diagram, but we have added a
timer to control when we read the buttons on the user interface and render data onto the screen.

Fig 1.5: Software architecture for moving map

Architectural descriptions must be designed to satisfy both functional and nonfunctional requirements.
Not only must all the required functions be present, but we must meet cost, speed, power and other
nonfunctional constraints. Starting out with system architecture and refining that to hardware and
software architectures is one good way to ensure that we meet all specifications: We can concentrate
on the functional elements in the system block diagram, and then consider the nonfunctional
constraints when creating the hardware and software architectures.

15
3.4 Designing Hardware and Software Components
1. The architectural description tells us what components we need.
2. In general components include both hardware—FPGAs, boards, and so on—and software
modules.
3. Some of the components will be ready-made.
3.5 System Integration
Putting hardware and software components together will give complete working system. Bugs are
typically found during system integration, and good planning can help us to find the bugs quickly. If
we debug only a few modules at a time, we are more likely to uncover the simple bugs and able to
easily recognize them.
System integration is difficult because it usually uncovers problems. It is often hard to
observe the system in sufficient detail to determine exactly what is wrong— the debugging facilities
for embedded systems are usually much more limited than what you would find on desktop systems.
As a result, determining why things do not work correctly and how they can be fixed is a challenge in
itself.
4. FORMALISMS FOR SYSTEM DESIGN
We perform a number of different design tasks at different levels of abstraction: creating requirements
and specifications, architecting the system, designing code, and designing tests. It is often helpful to
conceptualize these tasks in diagrams.
The Unified Modeling Language (UML). UML was designed to be useful at many levels of
abstraction in the design process. UML is an object-oriented modeling language.
The design in terms of actual objects helps us to understand the natural structure of the system.
Object-oriented specification can be seen in two complementary ways:
■Object-oriented specification allows a system to be described in a way that closely models real-
world objects and their interactions.
■Object-oriented specification provides a basic set of primitives that can be used to describe systems
with particular attributes, irrespective of the relationships of those systems’ components to real-world
objects.
What is the relationship between an object-oriented specification and an object oriented programming
language?
A specification language may not be executable. But both object-oriented specification and
programming languages provide similar basic methods for structuring large systems.
4.1 Structural Description
1. By structural description, we mean the basic components of the system .
2. The principal component of an object-oriented design is object.
3. An object includes a set of attributes that define its internal state.

16
 4. When implemented in a programming language, these attributes usually become variables or
constants held in a data structure. In some cases, we will add the type of the attribute after the
attribute name for clarity, but we do not always have to specify a type for an attribute.

Fig 1.6: An object in UML notation

An object describing a display (such as a CRT screen) is shown in UML notation in Fig 1.6. The text
in the folded-corner page icon is a note; it does not correspond to an object in the system and only
serves as a comment. The attribute is, in this case, an array of pixels that holds the contents of the
display.
The object is identified in two ways: It has a unique name, and it is a member of a class. The name is
underlined to show that this is a description of an object and not of a class.

1. A class is a form of type definition—all objects derived from the same class have the same
characteristics, although their attributes may have different values.
2. A class defines the attributes that an object may have. It also defines the operations that
determine how the object interacts with the rest of the world. In a programming language, the
operations would become pieces of code used to manipulate the object.
The UML description of the Display class is shown in Figure1.7.

Fig 1.7: A class in UML notation

The class has the name that we saw used in the d1 object since d1 is an instance of class Display. The
Display class defines the pixels attribute seen in the object;

A class defines both the interface for a particular type of object and that object’s implementation.
When we use an object, we do not directly manipulate its attributes—we can only read or modify the
object’s state through the operations that define the interface to the object. As long as we do not

17
change the behavior of the object seen at the interface, we can change the implementation as much as
we want.
There are several types of relationships that can exist between objects and classes:
■Association occurs between objects that communicate with each other but have no ownership
relationship between them.
■Aggregation describes a complex object made of smaller objects.
■Composition is a type of aggregation in which the owner does not allow access to the component
objects.
■Generalization allows us to define one class in terms of another (use to represent inheritance
relation)
Unified Modeling Language, like most object-oriented languages, allows us to define one class in
terms of another. An example is shown in Fig1.8, where we derive two particular types of displays.
The first, BW_display, describes a black and- white display. This does not require us to add new
attributes or operations, but we can specialize both to work on one-bit pixels.

Fig 1.8: Derived classes as a form of generalization in UML

A derived class inherits all the attributes and operations from its base class. Here Display is the base
class for the two derived classes. A derived class is defined to include all the attributes of its base
class. This relation is transitive—if Display were derived from another class, both BW_display and
Color_map_display would inherit all the attributes and operations of Display’s base class as well.
Inheritance has two purposes. It allows us to describe one class that shares some characteristics with
another class.
Unified Modeling Language considers inheritance to be one form of generalization.
A generalization relationship is shown in a UML diagram as an arrow with an open (unfilled)
arrowhead.

18
 Fig 1.9: Multiple inheritance in UML
multiple inheritances:
Both BW_display and Color_map_display are specific versions of Display, so Display generalizes
both of them. UML also allows us to define multiple inheritances, in which a class is derived from
more than one base class. (Most object-oriented programming languages support multiple inheritances
as well.) An example of multiple inheritances is shown in Fig1.9; In this case, we have created a
Multimedia_display class by combining the Display class with a Speaker class for sound. The derived
class inherits all the attributes and operations of both its base classes, Display and Speaker.
A link describes a relationship between objects; association is to link as class is to object. Fig1.10
shows an example of links and an association. When we consider the actual objects in the system,
there is a set of messages that keeps track of the current number of active messages (two in this
example) and points to the active messages. In this case, the link defines the contains relation.
When generalized into classes, we define an association between the message set class and the
message class. The association is drawn as a line between the two labeled with the name of the
association, namely, contains. The ball and the number at the message class end indicate that the
message set may include zero or more message objects. We can give these patterns names, which are
called stereotypes in UML. A stereotype name is written in the form <<signal>>.

19
 Fig 1.10: Links and associations in UML

4.2 Behavioral Description

We have to specify the behavior of the system as well as its structure. One way to specify the
behavior of an operation is a state machine. Fig1.11 shows UML states; the transition between two
states is shown by arrow. These state machines will not rely on the operation of a clock, as in
hardware; rather, changes from one state to another are triggered by the occurrence of events.

Fig 1.11: A state and transition in UML

An event is some type of action. Events are divided into two categories. They are:
 External events: The event may originate outside the system, such as a user pressing a button.
 Internal events: It may also originate inside, such as when one routine finishes its computation
and passes the result on to another routine.

We will concentrate on the following three types of events defined by UML, as illustrated in figure
1.12(signal and call event) and figure 1.13(Time out event)
■A signal is an asynchronous occurrence. It is defined in UML by an object that is labeled as a
<<signal>>. The object in the diagram serves as a declaration of the event’s existence. Because it is
an object, a signal may have parameters that are passed to the signal’s receiver.

20
■A call event follows the model of a procedure call in a programming language.

Fig 1.12: Signal and Call events in UML

■A time-out event causes the machine to leave a state after a certain amount of time. The label
tm(time-value) on the edge gives the amount of time after which the transition occurs. A time-out is
generally implemented with an external timer.

Figure 1.13: Time out event in UML

unconditional and conditional transitions:

The states in the state machine represent different conceptual operations. In some cases, we take
conditional transitions out of states based on inputs or the results of some computation done in the
state. In other cases, we make an unconditional transition to the next state. Both the unconditional and
conditional transitions make use of the call event. Let’s consider a simple state machine specification
to understand the semantics of UML state machines. A state machine for an operation of the display is
shown in Fig1.14. The start and stop states are special states that help us to organize the flow of the
state machine.

21
 Figure 1.14: State diagram specification for display in moving map
Sequence diagram:
It is sometimes useful to show the sequence of operations over time, particularly when several objects
are involved. In this case, we can create a sequence diagram, like the one for a mouse click scenario
shown in Fig1.15.A sequence diagram is somewhat similar to a hardware timing diagram, although
the time flows vertically in a sequence diagram, whereas time typically flows horizontally in a timing
diagram. The sequence diagram is designed to show a particular scenario or choice of events. In this
case, the sequence shows what happens when a mouse click is on the menu region. Processing
includes three objects shown at the top of the diagram. Extending below each object is its lifeline, a
dashed line that shows how long the object is alive. In this case, all the objects remain alive for the
entire sequence, but in other cases objects may be created or destroyed during processing.

Fig1.15: A sequence diagram in UML

The boxes along the lifelines show the focus of control in the sequence, that is, when the object is
actively processing. In this case, the mouse object is active only long enough to create the
mouse_click event. The display object remains in play longer; it in turn uses call events to invoke the
menu object twice: once to determine which menu item was selected and again to actually execute the
menu call. The find_region ( ) call is internal to the display object, so it does not appear as an event in
the diagram.

22
23
5 DESIGN EXAMPLE: MODEL TRAIN CONTROLLER
The model train controller, which is shown in the below figure.
1. The user sends messages to the train with the control box attached to the tracks.
2. The control box may have familiar controls such as throttle, emergency stop button and so on.
3. Since train receives its electrical power from the track, the control box can send a signal to the
train over the track by modulating the power supply voltage.
4. As shown Fig1.16, the control panel sends packet over the tracks to the receiver on the train.
Each packet includes an address so that the console can control several trains on the same
track. The packet also includes an error correction code (ECC) to guard against transmission
errors. This is a one-way communication system- the model train cannot send commands
back to the user.

Fig 1.16: A model train control system

We start by analyzing the requirements for the train control system, then develop two specifications: a
simple, high-level specification and then a more detailed specification.
REQUIREMENTS:
 The console shall be able to control up to eight trains on a single track
 The speed of each train shall be controlled by a throttle to at least 63 different levels in each
direction.
 There shall be an emergency stop button
 There shall be an inertia control that allow the user to adjust the responsiveness of the train to
commanded changes in speed
 An error direction scheme will be used to transmit messages
Requirement form for model train controller:
Name Model train controller
Purpose Control speed of up to eight model trains
Inputs Throttle, inertia setting, emergency stop, train number
Outputs Train control signal
Functions Set engine speed based upon inertia settings,
Respond to emergency stop
Performance Can update train speed at least 10 times per second

24
Manufacturing cost $50
Power 10W (plugs into walls)
Physical size and weight Console should be comfortable for two hands, approximate
size of standard keyboard. Weight less than 2 pounds

CONCEPTUAL SPECIFICATION OF MODEL TRAIN CONTROLLER:

1. Objects: Console , Train
2. Commands: set speed, set inertia, Estop.
3. Console: panel, formatter, transmitter
4. Train: receiver, controller, motor interface
The conceptual specification allows us to understand the system little better. Writing of conceptual
specification will help us to write a detailed specification. Defining the messages will help us
understand the functionality of the components. The set of commands that we can use to implement
the requirements placed on the system.
The commands are:
Command name Parameters
Set-speed Speed (positive or negative integer)
Set-inertia inertia-value (nonnegative)
Estop None

The system console controls the train by sending messages on to the tracks. The transmissions are
packetized: each packet includes an address and a message. A typical sequence of train control
commands is shown as a UML sequence diagram.

Fig 1.17: A UML sequence diagram for a typical sequence of train control commands

The focus of the control bars shows the both the console and receiver run continuously. The packets
can be sent at any time—there is no global clock controlling when the console sends and the train

25
receives, we do not have to worry about detecting collisions among the packets. Set- inertia message
will sent infrequently. Most of the message commands are speed commands. When a train receives
speed command, it will speed up and slow down the train smoothly at rate determined by the set-
inertia command. An emergency stop command may be received, which causes the train receiver to
immediately shut down the train motor.

We can model the commands in UML with two level class hierarchy as shown in the Fig1.18. Here
we have one base class command, there are three sub classes set-speed, set-inertia, Estop, derived
from base class. One for each specific type of command.

Fig 1.18: Class diagram for the train controller messages

We now need to model the train control system itself. There are clearly two major subsystems: the
control-box and the train board component. Each of these subsystems has its own internal structure.

Role of message classes

• Implemented message classes derived from message class.

• Attributes and operations will be filled in for detailed specification.

• Implemented message classes specify message type by their class.

• May have to add type as parameter to data structure in implementation.

Subsystem collaboration diagram:

Shows relationship between console and receiver (ignores role of track):

Fig 1.19: Collaboration diagram for major sub systems of the train controller system

The console and receiver are each represented by objects: the console sends a sequence of packets to
the train receiver, as illustrated by the arrow. The notation on the arrow provides both the type of

26
message sent and its sequence in a flow of messages .we have numbered the arrow’s messages as
1…n .

Let’s break down the console and receiver into three major components.

The console needs to perform three functions

• Console:

• Read state of front panel

• Format messages

• Transmit messages.

The train receiver must also perform three major functions

• Train receiver:

• receive message

• interpret message

• control the train

The UML class diagram is show in the below figure

CONSOLE SYSTEM CLASSES:

Fig 1.20: Console system classes

Console class roles:

• Panel: Describes the console front panel, which contains analog knobs and interface
hardware to interface to the digital parts of the system.

• Formatter: It knows how to read the panel knobs and creates bit stream for message.

• Transmitter: Send the message along the track.

TRAIN CONTROL CLASSES:

27
 Fig 1.21: Train control classes

Train class roles:

• Receiver: It knows how to turn the analog signal on the track into digital form.

• Controller: Interprets received commands and figures out how to control the motor.

• Motor interface: Generates the analog signals required to control the motor.

We define two classes to represent analog components

• Detector *: Detect the analog signal on the track and converts them into the digital
commands
• Pulser *: Converts the digital commands into the analog signal required to control the motor.

28
DETAILED SPECIFICATION:

Conceptual specification that defines the basic classes, let’s refine it to create a more detailed
specification. We won’t make a complete specification. But we will add details to the class. We can
now fill in the details of the conceptual specification. Sketching out the spec first helps us understand
the basic relationships in the system.

We need to define the analog components in a little more detail because there characteristics will
strongly influence the formatter and controller. Fig1.22, 23, 24, 25 shows a little more detail than Fig
1.20, Fig1.21. It includes attributes and behavior of these classes. The panel has three knobs:

Fig 1.22: classes describing analog physical objects in the train control system

Fig 1.23: Class diagram for analog physical objects in the train control system

Train number (which train is currently being controlled), speed and inertia. It also has emergency
stop. When we change train number settings, we also want to reset the other controls, so that the
previous train control settings are not used. To do this, Knobs* must provide a set-knobs() , that
allows the rest of the system to modify the knob settings.

29
 Fig 1.24: Class diagram for formatter, controller

Fig 1.25: Class diagram for transmitter and receiver

SEQUENCE DIAGRAM:

Fig 1.26: Sequence diagram for transmitting a control input

30
 Fig 1.27: State diagram for the formatter operate behavior

The state diagram for a very simple version of the operator behavior of the formatter class is shown in
Fig1.27. This behavior watches the panel for activity: if the train number changes, it updates the panel
display. Otherwise it sends the required message.

Sequence diagram for set-speed command:

Fig 1.28: Sequence diagram for a set-speed command received by the train

The operation of the controller class during the reception of a set speed command is shown in Fig1.28.
The controller’s operate behavior must execute several behavior to determine the nature of the
message. Once the speed command has been sent, it must send a sequence of commands to the motor
to smoothly change the train speed.

Controller operate behavior:

Fig 1.29: State diagram for the controller operate behavior

31
Fig1.30: state diagram for the panel-active behavior

32