Ecs-Unit I

Embedded Computing System
UNIT I
Embedded Computing
What is an embedded computer system?

It is any device that includes a programmable computer but is not itself a general-
purpose computer. Thus, a PC is not itself an embedded computing system.
• A fax machine or a clock, Cell phone, Printer.
• Automobile: engine, brakes, dash, etc.
• Airplane: engine, flight controls, nav/comm.
• Digital television.
• Household appliances which are built from a microprocessor are examples
for embedded computing system.
Early history:
A microprocessor is a single-chip CPU. Very large scale integration
(VLSI) —the acronym is the name technology has allowed us to put a complete
CPU on a single chip since 1970s, but those CPUs were very simple.
• Late 1940’s: MIT Whirlwind computer was designed for real-time operations.
➢ Originally designed to control an aircraft simulator.
• First microprocessor was Intel 4004 in early 1970’s.
• HP-35 calculator used several chips to implement a microprocessor in 1972.
• Automobiles used microprocessor-based engine controllers starting in 1970’s.
➢ Control fuel/air mixture, engine timing, etc.

➢ Multiple modes of operation: warm-up, cruise, hill climbing, etc.
➢ Provides lower emissions, better fuel efficiency.
Microprocessors come in many different levels of sophistication; they are usually classified
by their word size.
➢ An 8-bit microcontroller is designed for low-cost applications and includes on-board

memory and I/O devices;
Prof. Meghashri E M, CSE Dept, SVIT Page 1

➢ a 16-bit microcontroller is often used for more sophisticated applications that may
require either longer word lengths or off-chip I/O and memory;
➢ a 32-bit RISC microprocessor offers very high performance for computation-intensive
applications.
Characteristics of Embedded Computing Applications:

Functionality is important in both general-purpose computing and embedded
computing, but embedded applications must meet many other constraints as well.
Complex algorithms: The operations performed by the microprocessor may be very

sophisticated.
For example, the microprocessor that controls an automobile engine must perform
complicated ﬁltering 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.
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.
Example: Missed deadlines in printers, can result in scrambled pages.
Multirate: Many embedded computing systems have several real-time activities going on
at the same time. They may simultaneously control some operations that run at slow rates and
others that run at high rates.
Multimedia applications are prime examples of multirate behavior.
Manufacturing cost: 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.
Why Use Microprocessors?

➢ Microprocessors are a very efﬁcient way to implement digital systems.
➢ Microprocessors make it easier to design families of products that can be built
to provide various feature sets at different price points.
➢ The programmability of microprocessors may provide benefit during the design
process.
➢ It may be possible to reuse software which reduces development time and
manufacturing cost.
➢ Real-Time performance is best achieved by multiprocessor.
➢ Low power and low cost drive us toward multiprocessors.
The Physics of Software

Computing is a physical act. Software performance and energy consumption are very
important properties when embedded computers are connected to the real world.
Understanding the sources of performance and power consumption is important if we are to
be able to design programs that meet our application’s goals.
Challenges in Embedded Computing System Design
➢ How much hardware do we need?
Hardware includes- microprocessor, memory and peripheral devices. Selection of hardware must
meet both performance deadlines and manufacturing cost constraints so 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 but this makes system more expensive.

• 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?

In battery-powered applications, power consumption is extremely important. Even in
non-battery applications, excessive power consumption can increase heat dissipation.
Therefore 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. How can we
design a machine that will provide the required performance for software that we haven’t yet
written?
➢ How 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, such as safety-critical
systems.
Embedded machine design difficult for few reasons:

➢ Complex Testing:
• Testing Embedded system is not as simple as testing a software testing.
• 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 & 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

• 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.
• Generally compile code on one type of machine, such as a PC, and
download it onto the embedded system.
• To debug the code, Embedded Computing Systems rely on programs that run
on the PC or workstation and then look inside the embedded system.
Performance in Embedded Computing
At the heart of embedded computing is real-time computing, the program receives its
input data; the deadline is the time at which a computation must be finished. If the program
does not produce the required output by the deadline, then the program does not work. In
order to understand the real-time behaviour of an ECS we have to analyze the system at
different levels of abstraction.
➢ CPU: The CPU clearly influences the behaviour of the program, particularly when
the CPU is a pipelined processor with a cache.
➢ Platform: The platform includes the bus and I/O devices. The platform components
that surround the CPU are responsible for feeding the CPU and can dramatically
affect its performance.
➢ Program: Programs are very large and the CPU sees only a small window of the
program at a time. We must consider the structure of the entire program to determine
its overall behaviour.
➢ Task: Several programs simultaneously run on a CPU, creating a multitasking
system. The tasks interact with each other in ways that have profound implications
for performance.
➢ Multiprocessor: Many embedded systems have more than one processor— they
may include multiple programmable CPUs as well as accelerators. Once again, the
interaction between these processors adds yet more complexity to the analysis of
overall system performance.

THE EMBEDDED SYSTEM DESIGN PROCESS
A design methodology is important for three reasons.

➢ It allows us to keep a scorecard on a design to ensure that we have done everything we
need to do, such as optimizing performance or performing functional tests.
➢ It allows us to develop computer-aided design tools. First breaking the process into
manageable steps and automate the steps one at a time.
➢ A design methodology makes it much easier for members of a design team to
communicate. By defining the overall process, team members can more easily
understand what they are supposed to do, what they should receive from other team
members at certain times.
The major goals of the design:
➢ Manufacturing cost;
➢ Performance ( both overall speed and deadlines); and
➢ Power consumption.
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.
Major levels of abstraction in the design process:
• Design process follows Top-down design:
• start from most abstract description;
• work to most detailed.
• And also Bottom-up design:
• work from small components to big system.
• Real design uses both techniques.

Requirements:
Gather an informal description from the customers known as requirements, and refine the
requirements into a specification that contains enough information to begin designing the
system architecture.
Requirements may be Functional or Nonfunctional requirements:
1. Performance
➢ The speed of the system is often a major consideration both for the usability of
the system and for its ultimate cost.
➢ 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.
2. 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 engi- neering (NRE) costs
include the personnel and other costs of designing the system.
3. Physical size and weight:

➢ The physical aspects of the final system can vary greatly depending upon the
application.
➢ A handheld device typically has tight requirements on both size and weight
that can ripple through the entire system design.
4. Power Consumption:
➢ Power 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.
A sample requirements form:
Consider the entries in the form:
1. Name: Giving a name to the project not only simplifies talking about it to other
people but can also crystallize the purpose of the machine.
2. Purpose: This should be a brief one- or two-line description of what the system is
supposed to do.
3. Inputs and outputs: 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? Occasional user inputs? How many bits per data element?
➢ Types of I/O devices: Buttons? Analog/digital converters? Video displays?

4. 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.
5. Performance: Computation must be performed within a certain time frame.

Performance requirements must be identified early and analyzed to ensure that the
system works properly.
6. Manufacturing cost: This includes primarily the cost of the hardware components..
Cost has a substantial influence on architecture.
7. Power: Machine will be battery powered or plugged into the wall. Battery-powered
machines must be much more careful about how they spend energy.
8. Physical size and weight: Required to take some architectural decision.
The requirements for a GPS moving map system:

Specification:
➢ The specification must be carefully written so that it accurately reflects the customer’s
requirements.
➢ 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.
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.
Architecture Design
➢ The specification does not say how the system does things, only what the system does.
➢ Describing how the system implements those functions is the purpose of the architecture.
➢ 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.
A sample architecture or block diagram of the moving map:
➢ Block diagram shows major operations & data flow among them.
➢ The task performed by software running on a CPU and the operations performed by
special purpose hardware is not clear.

• Search the topographic DB & render the result for the display.
➢ Initial system block diagram is refined into two block diagram i.e one for hardware
and another for software.
Hardware block diagram:
➢ One central CPU surrounded by memory and I/O devices

➢ Two memory units:
• A frame buffer for the pixels to be displayed.
• A separate program/data memory for general use by the CPU.
Software block diagram:
➢ Software block diagram follows the system block diagram.

➢ A timer is added to control the instant to read the buttons on the user
interface and render data on to the screen.
➢ Architectural descriptions must be designed to satisfy both functional and
non-functional requirements.

➢ To meet constraints on speed , cost and so on , we must be able to estimate

the properties of the components of the block diagram.
Designing Hardware and Software components

➢ The architectural description tells us what components we need.
➢ The components in general include both hardware—FPGAs, boards,and so on—and
software modules.
➢ Some of the components will be ready-made like CPU, memory chips etc.
• In GPS Moving map, GPS receiver is a specialized standard component.
➢ Make use of standard software modules.
• Topographic database and standard routines to access the DB.
➢ Using standard software:
• Saves design time
• Faster implementation for specialized functions such as data decompression
phase.
➢ Some components are to be designed by ourselves. Ex: Printed Circuit Board and
customized program.
System Integration
➢ System integration is difficult because it uncovers problems.

➢ Debugging is more challenging as compared to desktop system.
➢ Ensure during the architectural and component design phases that it is possible
to assemble the system in phases and test functions relatively independently.
➢ Careful attention to inserting appropriate debugging facilities during design
can help ease system integration problems.
FORMALISMS FOR SYSTEM DESIGN

➢ Visual language that can be used to capture all tasks in the design process is Unified
Modeling Language. And is an Object Oriented Modeling Language.
➢ UML encourages the design to be described as a number of interacting objects.

Structural Description
Structural description is nothing but the basic components of the system.
➢ The principal component of an object-oriented design is, naturally enough, the object.
➢ An object includes a set of attributes that define its internal state.
An object describing a display (such as a CRT screen) is shown in UML notation.
➢ 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 an array of pixels that holds the contents of the display in the above
example.
➢ 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.
Class:
➢ 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.
➢ 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.
The UML description of the Display class

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.
Unified Modeling Language allows to define one class in terms of another. Consider an
example:
➢ Here deriving two particular types of displays. The 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.
➢ Color_map_display, uses a graphic device known as a color map to allow the user to
select from a large number of available colors even with a small number of bits per
pixel.
➢ A derived class inherits all the attributes and operations from its base class. In this
class, Display is the base class for the two derived classes.

➢ A derived class is defined to include all the attributes of its base 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.
UML also allows us to define multiple inheritance, in which a class is derived from more
than one base class.
Example:
➢ A Multimedia_display class is created 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.
Link:
➢ A link describes a relationship between objects.
➢ 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.

Association:
➢ Association between classes.
➢ 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
labelled 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.
Behavioral Description
➢ One way to specify the behavior of an operation is a state machine.

➢ The transition between two states is shown by a skeleton arrow in UML.
➢ 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.
➢ An event is some type of action. Action may be internal or external.

A State and Transition in UML
Three types of events defined by UML:
➢ 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.
➢ A call event follows the model of a procedure call in a programming language.
➢ 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 state machine specification in UML which helps in understanding the semantics of UML
state machines.
➢ The start and stop states are special states that help us to organize the flow of the state
machine.
➢ The states in the state machine represent different conceptual operations.
➢ State machine includes state transition based on conditional and unconditional
transition.
➢ Both the unconditional and conditional transitions make use of the call event.
A sequence diagram in UML

The sequence diagram is designed to show a particular scenario or choice of events. 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.
➢ The boxes along the lifelines shows the focus of control in the sequence,that is,when
the object is actively processing.
➢ 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.

MODEL TRAIN CONTROLLER
The user sends messages to the train with a control box attached to the tracks. The control
box may have familiar controls such as a throttle, emergency stop button, and so on. Since
the train receives its electrical power from the two rails of the track, the control box can send
signals to the train over the tracks by modulating the power supply voltage.
MODEL TRAIN CONTROL SYSTEM:

Requirements
➢ The console shall be able to control up to eight trains on a single track.
➢ The speed of each train shall be controllable by a throttle to at least 63 different levels
in each direction (forward and reverse).
➢ There shall be an inertia control that shall allow the user to adjust the responsiveness
of the train to commanded changes in speed.
➢ There shall be an emergency stop button.
➢ An error detection scheme will be used to transmit messages.
Example:
DCC: Digital Command Control
➢ DCC created by the National Model Railroad Association to support interoperable

digitally-controlled model trains.
➢ Defines way in which model trains, controllers communicate.
➢ DCC created to provide a standard that could be built by any manufacturer.
The DCC standard documents:

➢ Standard S-9.1, DCC Electrical Standard.
• Defines how bits are encoded on the rails.
➢ Standard S-9.2, DCC Communication Standard.
• Defines packet format and semantics.
Any DCC conforming device must meet these specifications.

DCC electrical standard:

➢ The data signal swings between two voltages around the power supply
voltage.
➢ Bits are encoded in the time between transitions, not by voltage levels.
➢ A 0 is at least 100 _s while a 1 is nominally 58 _s. The durations of the high
(above nominal voltage) and low (below nominal voltage) parts of a bit are
equal to keep the DC value constant.
Bit encoding in DCC
DCC Communication standard:

Regular Expression or basic packet format: PSA(sD)+E
➢ P: preamble = 1111111111.
➢ S: packet start bit = 0.
➢ A: address data byte which gives the address of the unit
➢ s: data byte start bit.
➢ D: data byte (data payload) which includes eight bits
➢ E: packet end bit = 1.
Baseline packet: minimum packet that must be accepted by all DCC implementations. It has
3 data bytes.
• Address data byte gives receiver address.
• Instruction data byte gives basic instruction.
• Error correction data byte gives ECC.
Conceptual Specification
A train control system turns commands into packets. Commands and packets may not
to be generated in a 1 to 1 ratio.

There are 2 major subsystems: the command unit and the train-board component.
Class diagram for the train controller messages:
UML Collaboration diagram for major subsystems of the train controller system:
The command unit and receiver are each represented by objects; the command unit sends a
sequence of packets to the train’s receiver, as illustrated by the arrow .The notation on the
arrow provides both the type of message sent and its sequence in a flow of messages; since
the console sends all the messages, we have numbered the arrow’s messages as 1..n.Those
messages are carried over the track.
Break down the command unit and receiver into their major components.
➢ The console needs to perform three functions: read the state of the front panel on the
command unit, format messages, and transmit messages.
➢ The train receiver must also perform three major functions: receive the message,
interpret the message (taking into account the current speed, inertia setting, etc.),and
actually control the motor.
A UML class diagram for the train controller showing the composition of the subsystems.

Basic Characteristics of Console class :

➢ The Console class describes the command unit’s front panel, which contains the
analog knobs and hardware to interface to the digital parts of the system.
➢ The Formatter class includes behaviors that know how to read the panel knobs and
creates a bit stream for the required message.
➢ The Transmitter class interfaces to analog electronics to send the message along the
track.
Special classes that represent analog components:
• Knobs* describes the actual analog knobs, buttons, and levers on the
control panel.
• Sender* describes the analog electronics that send bits along the track.
Basic Characteristics of Train class:
➢ The Receiver class knows how to turn the analog signals on the track into digital
form.
➢ The Controller class includes behaviors that interpret the commands and figures out
how to control the motor.
➢ The Motor interface class defines how to generate the analog signals required to
control the motor.

We define two classes to represent analog components:

• Detector* detects analog signals on the track and converts them into digital form.
• Pulser* turns digital commands into the analog signals required to control the motor
speed.
Train Set is special class which represents system can handle multiple trains.
Detailed Specification
Conceptual specification that defines the basic classes, refine it to create a more
detailed specification.
Class diagram includes attributes and behaviors of the classes.
The Panel has three knobs: train number (which train is currently being controlled), speed
(which can be positive or negative), and inertia. It also has one button for emergency-stop.
When we change the train number setting, we also want to reset the other controls to the
proper values for that train so that the previous train’s control settings are not used to change
the current train’s settings .To do this, Knobs* must provide a set-knobs behavior that allows
the rest of the system to modify the knob settings.
The speed of electric motors is commonly controlled using pulse-width modulation. The
digital interface to the motor system specifies that pulse width as an integer, with the
maximum value being maximum engine speed. A separate binary value controls direction.

Controlling motor speed by pulse-width modulation.
Class diagram for the panel and motor interfaces:
The Panel class defines a behavior for each of the controls on the panel. The new-settings
behavior uses the set-knobs behavior of the Knobs* class to change the knobs settings
whenever the train number setting is changed. The Motor-interface defines an attribute for
speed that can be set by other classes.
Class diagram for Transmitter and Receiver class:

The Transmitter provides a distinct behavior for each type of message that can be sent; it
internally takes care of formatting the message. The Receiver class provides a read-cmd
behavior to read a message off the tracks.
Class diagram for Formatter class:
The formatter holds the current control settings for all of the trains. The send-command
method is a utility function that serves as the interface to the transmitter. The operate
function performs the basic actions for the object. The panel-active behaviour returns true
whenever the panel’s values do not correspond to the current values.
Sequences diagram for transmitting a control input:

Two changes to the knob settings: first to the throttle, inertia, or emergency stop; then to the train
number. The panel is called periodically by the formatter to determine if any control settings have
changed. If a setting has changed for the current train, the formatter decides to send a command,
issuing a send-command behavior to cause the transmitter to send the bits. Because transmission is
serial, it takes a noticeable amount of time for the transmitter to finish a command; in the meantime,
the formatter continues to check the panel’s control settings. If the train number has changed, the
formatter must cause the knob settings to be reset to the proper values for the new train.
State diagram for the formatter operate behaviour:
If the train number changes, it updates the panel display; otherwise, it causes the required
message to be sent.
State diagram for the panel-active behaviour:

Class diagram for controller class:
The operate behavior is called by the receiver when it gets a new command; operate looks at
the contents of the message and uses the issue-command behavior to change the speed,
direction, and inertia settings as necessary.
State diagram for the Controller operate behavior:

Sequence diagram for a set-speed command received by the train:
The Controller’s operate behavior must execute several behaviors to determine the nature of
the message. Once the speed command has been parsed, it must send a sequence of
commands to the motor to smoothly change the train’s speed.

Ecs-Unit I

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ecs-Unit I

Transféré par

Droits d'auteur :

Formats disponibles

Embedded Computing System

What is an embedded computer system?

• HP-35 calculator used several chips to implement a microprocessor in 1972.

• Automobiles used microprocessor-based engine controllers starting in 1970’s.

➢ Control fuel/air mixture, engine timing, etc.

➢ An 8-bit microcontroller is designed for low-cost applications and includes on-board

Prof. Meghashri E M, CSE Dept, SVIT Page 1

Characteristics of Embedded Computing Applications:

Complex algorithms: The operations performed by the microprocessor may be very

User interface: Microprocessors are frequently used to control complex user

Manufacturing cost: Manufacturing cost is determined by many factors, including

Prof. Meghashri E M, CSE Dept, SVIT Page 2

Why Use Microprocessors?

The Physics of Software

Challenges in Embedded Computing System Design

➢ How much hardware do we need?

• too much hardware and it becomes too expensive.

Prof. Meghashri E M, CSE Dept, SVIT Page 3

➢ How do we minimize power consumption?

➢ How do we design for upgradability?

➢ How Does it Really work ?

Embedded machine design difficult for few reasons:

• Embedded computing systems usually do not come with keyboards and

Prof. Meghashri E M, CSE Dept, SVIT Page 4

Performance in Embedded Computing

Prof. Meghashri E M, CSE Dept, SVIT Page 5

THE EMBEDDED SYSTEM DESIGN PROCESS

A design methodology is important for three reasons.

• start from most abstract description;

• work to most detailed.

• And also Bottom-up design:

• work from small components to big system.

• Real design uses both techniques.

Prof. Meghashri E M, CSE Dept, SVIT Page 6

3. Physical size and weight:

Prof. Meghashri E M, CSE Dept, SVIT Page 7

A sample requirements form:

Consider the entries in the form:

➢ Types of I/O devices: Buttons? Analog/digital converters? Video displays?

Prof. Meghashri E M, CSE Dept, SVIT Page 8

5. Performance: Computation must be performed within a certain time frame.

8. Physical size and weight: Required to take some architectural decision.

The requirements for a GPS moving map system:

Prof. Meghashri E M, CSE Dept, SVIT Page 9

A specification of the GPS system would include several components:

Prof. Meghashri E M, CSE Dept, SVIT Page 10

➢ One central CPU surrounded by memory and I/O devices

➢ Software block diagram follows the system block diagram.

Prof. Meghashri E M, CSE Dept, SVIT Page 11

➢ To meet constraints on speed , cost and so on , we must be able to estimate

Designing Hardware and Software components

➢ System integration is difficult because it uncovers problems.

FORMALISMS FOR SYSTEM DESIGN

Prof. Meghashri E M, CSE Dept, SVIT Page 12

Prof. Meghashri E M, CSE Dept, SVIT Page 13

Prof. Meghashri E M, CSE Dept, SVIT Page 14

Unified Modeling Language considers inheritance to be one form of generalization. A

➢ A Multimedia_display class is created by combining the Display class with a Speaker

Prof. Meghashri E M, CSE Dept, SVIT Page 15

➢ One way to specify the behavior of an operation is a state machine.

Prof. Meghashri E M, CSE Dept, SVIT Page 16

A State and Transition in UML

Three types of events defined by UML: