MODULE-4

Programming tools
Evolution of embedded programming tools,
Modelling programs, Code optimization, Logic
analyzers, Programming environment
BUILDING PROCESS
FOR EMBEDDED
SYSTEMS

2
 BUILDING PROCESS FOR EMBEDDED SYSTEMS

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 BUILDING PROCESS FOR EMBEDDED SYSTEMS

Edit-Test-Debug Cycle implementation phase of the

development process

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 BUILDING PROCESS FOR EMBEDDED SYSTEMS
 Embedded systems programming is not substantially
different from the programming you've done before.

 The only thing that has really changed is that you

need to have an understanding of the target hardware
platform. Furthermore, each target hardware
platform is unique.

 Unfortunately, this uniqueness among hardware

platforms leads to a lot of additional software
complexity, and it's also the reason you'll need to be
more aware of the software build process than ever
before.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILDING PROCESS FOR EMBEDDED SYSTEMS
 When build tools run on the same system as the program
they produce, they can make a lot of assumptions about
the system.

 This is typically not the case in embedded software

development, where the build tools run on a host
computer that differs from the target hardware platform.

 Embedded software development tools, can rarely make

assumptions about the target platform.

 Instead, the user must provide some knowledge of the

system to the tools by giving them more explicit
instructions.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILDING PROCESS FOR EMBEDDED SYSTEMS
 Software Development is performed on a Host computer
 Compiler, Assembler, Linker, Locator, Debugger
 Produces executable binary image that will run on Target
Embedded System

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 BUILDING PROCESS FOR EMBEDDED SYSTEMS

 Software Tools
1. Software Development Kit (SDK)
2. Source-code Engineering Software
3. RTOS
4. Integrated Development Environment (IDE)
5. Emulator
6. Editor
7. Interpreter
8. Compiler
9. Assembler
10.Cross Assembler
11.Locator
12.Testing and debugging tools
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PROCESS FOR DEVELOPING EMBEDDED SOFTWARE
 To develop software for a General Purpose Computer
 Create source file
 Type in C code
 Build: compile and link
 Execute: load and run

 To develop software for an embedded system

 Create source file (on Host)
 Type in C code (on Host)
 Compile/Assemble: translate into machine code (on Host)
 Link: combine all object files and libraries, resolve all symbols (on Host)
 Locate: assign memory addresses to code and data (on Host)
 Download: copy executable image into Target processor memory
 Execute: reset Target processor
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PROCESS FOR DEVELOPING EMBEDDED SOFTWARE

The Embedded Software Development Process

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PROCESS FOR DEVELOPING EMBEDDED SOFTWARE

SOURCE CODE INTO EXECUTABLE BINARY IMAGE

Each of the source files must be compiled or assembled into

an object file

All of the object files that result from the first step must be
linked together to produce a single object file, called the re-
locatable program.

Physical memory addresses must be assigned to the relative

offsets within the re-locatable program in a process called
relocation.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PREPROCESSING

 Pre-processing is not a part of the compiler, but is a

separate step in the compilation process
 Pre-processing is a process of running a set of
instructions provided by the programmer explicitly as
code before the program compiles.
 The pre-processor provides the ability for the inclusion of
header files, macro expansions, conditional compilation,
and line control.
 Pre-processor instructions are called pre-processor
directives, and they all start with a hash symbol (#). Few
examples: "#include",
MODULE - 5
"#define", "#line", and many
CSE3006 – EMBEDDED SYSTEM DESIGN
 COMPILING
 Compiler translate programs written in some human-
readable language into an equivalent set of op-codes (or
machine language) for a particular processor.

 Compiler performs conversion of Source Code --> Object

file

 Object file is binary file that contains set of machine-

language instructions (opcodes) and data resulting from
language translation Process

 Each processor has its own unique machine language, so

you need to choose a compiler that produces programs
MODULE for
-5 your specific target
CSE3006 –processor.
EMBEDDED SYSTEM DESIGN
 CROSS COMPILING
 In the embedded systems case, compiler almost
always runs on the host computer.

 A Native-compiler runs on a computer platform and

produces code for that same computer platform

 A Cross-compiler runs on one computer platform and

produces code for another computer/target platform

 The use of a cross-compiler is one of the defining

features of embedded software development.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 COMPILER - EXAMPLE
 The GNU C compiler (gcc) and assembler (as) can be
configured as either native compilers or cross-
compilers.

 These tools support an impressive set of host-target

combinations.

 The gcc compiler will run on all common PC and Mac

operating systems.

 The target processor support is extensive, including

AVR, Intel x86, MIPS, PowerPC, ARM, and SPARC.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 COMPILER – OBJECT FILE FORMAT
 Regardless of the input language (C, C++, assembly,
or any other), the output of the cross-compiler will
be an object file.

 Although parts of this file contain executable code,

the object file cannot be executed directly.

 The contents of an object file can be thought of as a

very large, flexible data structure.

 The structure of the file is often defined by a

standard format such as the Common Object File
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 COMPILER – OBJECT FILE
 Most object files begin with a header that describes the
sections that follow.

 Each of these sections contains one or more blocks of

code or data that originated within the source file you
created.

 However, the compiler has regrouped these blocks into

related sections.

 For example, in gcc

 text - all of the code blocks are collected into this section,
 data - initialized global variables (and their initial values) into
MODULE - 5
this section CSE3006 – EMBEDDED SYSTEM DESIGN
 COMPILER – SYMBOL TABLE

 There is also usually a symbol table somewhere in the

object file that contains the names and locations of all
the variables and functions referenced within the source
file.

 Parts of this table may be incomplete, however, because

not all of the variables and functions are always defined
in the same file.

 These are the symbols that refer to variables and

functions defined in other source files.

 And it is up to the
MODULE - 5
linker to resolve such unresolved
CSE3006 – EMBEDDED SYSTEM DESIGN
 LINKER
 All of the object files resulting from the compilation in
step one must be combined.

 The object files themselves are individually incomplete,

some of the internal variable and function references not
yet been resolved.

 The job of the linker is to combine these object files and,

in the process, to resolve all of the unresolved symbols

 By merging the text, data, and bss sections of the input

object files, the linker creates a new object file that
contains all of the code and data from the input object
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LINKER
 When the linker is finished executing, all of the machine
language code from all input object files will be in text
section of the new file.

 And all of the initialized and uninitialized variables will

reside in the new data and bss sections, respectively.

 After merging all of the code and data sections and

resolving all of the symbol references, the linker
produces an object file that is a special “relocatable”
copy of the program.
 In other words, the program is complete except for one
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOCATOR
 The tool that performs the conversion from relocatable
program to executable binary image is called a locator.

 You have to do most of the work in this step yourself, by

providing information about the memory on the target
board as input to the locator.

 The locator uses this information to assign physical

memory addresses to each of the code and data sections
within the relocatable program.

 It then produces an output file that contains a binary

memory image that can be loaded into the target.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOCATOR
 The output of this final step of the build process is a
binary image containing physical addresses for the
specific embedded system.

 This executable binary image can be downloaded to the

embedded system or programmed into a memory chip.

 There is a separate development tool, called a locator, to

assign addresses. However, in the of GNU tools, this
feature is built into the linker (ld).

 The memory information required by the GNU linker can

be passed to it in the form of a linker script.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOCATOR - EXAMPLE
example of a linker script

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LOCATOR - EXAMPLE
 The first executable instruction is ENTRY command,
which appears on the first line and the entry point is the
function main.

 This script informs the GNU linker’s built-in locator about

the memory on the target board, which contains 64 MB
of RAM and 16 MB of flash ROM.

 The linker script file instructs the GNU linker to locate

the data, bss, and text sections in RAM starting at
address 0x00400000.

 Names in the linker command file that begin with an

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOCATOR - EXAMPLE
 The linker will use these symbols to resolve references in
the input object files.

 So, for example, there might be a part of the embedded

software (usually within the startup code) that copies
the initial values of the initialized variables from ROM to
the data section in RAM.

 The start and stop addresses for this operation can be

established symbolically by referring to the addresses as
_DataStart and _DataEnd.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

 In this section, we show an example build procedure for

the Arcom VIPER-Lite development board.

 If another hardware platform is used, a similar process

should be followed using the tools and conventions that
accompany that hardware.

 Once the tools are installed, the commands covered in

the following sections are entered into a command shell.

 For Windows users, the command shell is a Cygwin bash

shell (Cygwin is a Unix environment for Windows); for
Linux users, it is a regular command shell.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE

 First we look at the individual commands in order to

manually perform the three separate tasks (compiling,
linking, and locating)

 Later, we will learn how to automate the build procedure

with makefiles.

 The Blinking LED example consists of two source

modules: led.c and blink.c.

 The first step in the build process is to compile these two

MODULE -files.
5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE
 The basic structure for the gcc compiler command is:

 The command-line options we’ll need are:

-g To generate debugging info in default format
-c To compile and assemble but not link
-Wall To enable most warning messages
-I../include To look in the directory include for header files

 Here are the actual commands for compiling:

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

COMPILE
 We broke up the compilation step into two separate
commands, but you can compile the two files with one
command.

 To use a single command, just put both of the source

files after the options. If you wanted different options for
one of the source files, you would need to compile it
separately as just shown.

 The result of each of these commands is the creation of

an object file that has the same prefix as the .c file, and
the extension .o.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

 We now have the two object files—led.o and blink.o—that

we need in order to perform the second step in the build
process.

 As we discussed earlier, the GNU linker performs the

linking and locating of the object files.

 For the third step, locating, there is a linker script file

named viperlite.ld that we input to ld in order to
establish the location of each section in the Arcom
board’s memory.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

 The structure for the linker and locater ld command is:

 The command-line options we’ll need for this step are:

-Map blink.map To generate a map file and use the given filename
-T viperlite.ld To read the linker script
-N To set the text and data sections to be readable and
writable
-o blink.exe To set the output filename (if this option is not
included, ld will use the default output filename a.out)

 The actual command for linking and locating is:

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

 The order of the object files determines their placement
in memory. Because we are not linking in any startup
code, the order of the object files is irrelevant.

 If startup code were included, you would want that

object file to be located at the proper address.

 The linker script file can be used to specify where you

want the startup routine (and other code) to reside in
memory.

 Furthermore, you can also use the linker script file to

MODULE -specify
5 exact addresses for code
CSE3006 – EMBEDDED or data, should you find
SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

 As you can see in this command, the
two object files—led.o and blink.o—
are the last arguments on the
command line for linking.

 The linker script file, viperlite.ld, is

also passed in for locating the data
and code in the Arcom board’s
memory.

 The result of this command is the

creation of two files—blink.map and
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 BUILD PROCEDURE FOR THE ARCOM VIPER-LITE DEVELOPMENT BOARD

LINK AND LOCATE

 The .map file gives a complete listing of all code and

data addresses for the final software image.

 It provides information similar to the contents of the

linker script described earlier.

 However, these are results rather than instructions and

therefore include the actual lengths of the sections and
the names and locations of the public symbols found in
the relocatable program.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LINKER MAP FILES
 The linker map file provides valuable information that can
help you understand and optimize memory.

 The map file is a symbol table for the whole program.

 The most straightforward pieces of information in the map

file are the actual memory regions, with location, size and
access rights granted to those regions

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LINKER MAP FILES
 Linker script and memory map section contains a breakdown
of the memory contribution of each and every file that was
linked into the final image.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LOADING ON THE TARGET

 Previously, we saw how the code or software to be

executed on the embedded system (target board) is
written on a computer.

 The resulting code created after subjecting it to be build

process is called the binary executable image or simply
hex code.

 This topic explains how the hex code is loaded on the

target board which is referred as downloading

 And what are the various possible ways of debugging a

MODULE -code
5 meant to runCSE3006
on a– EMBEDDED
embedded system.
SYSTEM DESIGN
 LOADING ON THE TARGET

 There are two ways of

downloading the binary
image on the embedded
system:

1. Using a Device
Programmer

2. In-system programming
(ISP)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LOADING ON THE TARGET
1. Using a Device Programmer:
 Step 1: Once the binary image is ready on the computer,
the device programmer is connected to the computer.

 Step 2: The uP/uC or memory chip, usually the ROM which

is supposed to contain the binary image is placed on the
proper socket on the device programmer.

 Step 3: The device programmer contains a software

interface through which the user selects the target uP/uC
for which the binary image has to be downloaded.

 Step 4: The Device programmer then transfers the binary

image bit by bit to the chip.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOADING ON THE TARGET
1. Using a Device Programmer:
uP/uC/Memory Chip

Host Computer
Device Programmer

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 LOADING ON THE TARGET
2. Using In System Programmer(ISP):
 Certain Target embedded platforms uses a piece of
hardware called ISP that have a hardware interface to both
the computer as well the target board’s chip where the
code is to be downloaded.

 ISP is also called in-circuit serial programming (ICSP), is

the ability of programming the embedded
processor/controller while it is installed in a complete
system, rather than requiring the chip to be programmed
prior to installing it into the system.

 It also allows firmware updates to be delivered to the on-

chip memory of microcontrollers and related processors
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 LOADING ON THE TARGET
2. Using In System Programmer(ISP):
 The user through the ISP’s software interface sends the
binary image to the target board. This avoids the
requirement of frequently removing the microprocessor /
microcontroller or ROM for downloading the code if a
device programmer had to be used.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS
SIMULATOR
 Simulator is a host-based program that simulates
functionality and instruction set of target processor.

 The front-end has text or GUI-based windows for source

code, register contents, etc.

 Simulators are valuable during early stages of

development.

 Disadvantage of this method is that, it only simulates the

processor, and not the peripherals.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
REMOTE DEBUGGER
 Remote debuggers are one of the commonly used
downloading and testing tools during development of
embedded software

 It is used to monitor/control embedded SW. It is used to

download, execute and debug embedded software over
a comm. link.

 The program running on the host of a remote debugger

has a user interface (GUI/Command-line) that looks just
like other debugger

 The front-end ofCSE3006

MODULE - 5 the– EMBEDDED
GUI SYSTEM
debuggers
DESIGN contain several
 DEBUGGING TOOLS
REMOTE DEBUGGER
 Backend provides low-level control of target processor,
runs on target processor and communicates to the front-
end over a communication link.
 Debugger and software being debugged are executing
on two different computer systems.
-Start/restart/kill, and stepping through program.
- Software breakpoints.
- Reading/writing registers or data at specified address.

 Disadvantage: inability to debug startup Code, code must

execute from RAM, requires a target processor to run the
MODULE -final
5 software package
CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
 Emulation refers to the ability of a computer program or
electronic device to imitate another program or device.
 An emulator is a piece of hardware/software that enables
one computer system to run programs that are written
for another computer system.
 An in-circuit emulator (ICE) provides a lot more
functionality than a remote debugger.
 In addition to providing the features available with a
remote debugger, an ICE allows you to debug startup
code and programs running from ROM, etc.,
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 DEBUGGING TOOLS
IN-CIRCUIT EMULATOR (ICE)
 In-Circuit Emulator (ICE) takes the place of the target
processor. It contains a copy of target processor, plus
RAM, ROM, and its own embedded software.

 It allows you to examine the state of the processor while

the program is running. It uses the remote debugger for
human interface.

 ICE provides greater flexibility, ease for developing

various applications on a single system in place of
testing that multiple targeted systems. Disadvantage of
this method is that, it is expensive.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 Petri net
model

Modelling
embedded
Unified
systems Data
model Flow
language Graph

50
 Modelling Programs
Representation of a program

 Modelling the programs in Embedded systems.

 Program has basic blocks, conditional statements etc.

 Can be represented by
 Data Flow graph (DFG)
 Control Data Flow Graph (CDFG)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Representation of a program

 Model a program that has no conditionals

 Basic blocks - having one entry and exit point.
 Before go for DFG represent the program in single
assignment form
 Single assignment form
 Having statement in a program, where the assignment variables (in
left)appears only one.
 It verifies no cyclic form in the statements or blocks.
 It identifies the unique location of variables in the code
 Any use of repeated assignment to single variable need to be rewrite
and assigns the latest assigned variable if it is used further.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Representation of a program

 Two types of nodes

 Round nodes - represents or denotes operators.
 Square nodes - represents values.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Single assignment form

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Advantages of DFG

 It orders the way operations can be performed in a

program.
 Determines the feasible reordering's of the operations,
this will reduce the pipeline or cache conflicts

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

 Constructs a model for decision flow and data flow of a

program.

 Data flow nodes represented by basic block (set of

statements).

 Control flow of a sequential program is represented by

decision nodes

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

 Basic block nodes

 Decision nodes

 Edges labelled with possible outcomes

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Building loop in CDFG

while (a < b)
{
a = proc1(a,b);
b= proc2(a,b);
}

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Condition blocks using CDFG

if (cond1)
basic_block_1( );
else
basic_block_2();
basic_block_3( );
switch (test1) {
case c1: basic_block_4( ); break;
case c2: basic_block_5( ); break;
case c3: basic_block_6( ): break;
}

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 Modelling Programs
Control DFG

 CDFG is a hierarchical representation.

 Each block in CDFG is expanded using Data flow graph.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

PETRINET MODEL

61
 PETRI NET MODEL

 Petri net can also called as Place/Transition net

 It is used for describing and analyzing concurrent
process
 Petri net is also a graphical tool
 Petri Net(PN) is Very similar to State Transition
Diagrams which model the system behavior
 It is an abstract model to show the interaction
between asynchronous processes
 In asynchronous process, start and sequence of
processes may vary during the execution

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
COMPONENTS OF PETRINET MODEL
 Petri net Model consists of four types of components
- places (circles), transitions (rectangles) and arcs
(arrows), tokens(black dot):
 Places represent possible states of the system;
 Transitions are events which cause the change of
state
 Every arc simply connects a place with a transition
or a transition with a place.
 Change of state is denoted by a movement of
token(s) from place(s) to place(s)
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

COMPONENTS OF PETRINET MODEL

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
 Change of state is caused by the firing of a transition

 Firing refers to the occurrence of an event

 The firing is based on the input conditions, denoted

by token availability

 A transition is enabled when sufficient tokens are

available in input places

 Once firing is initiated, tokens will be transferred

from input to output places
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

COMPONENTS OF PETRINET

 Below is an example Petri net with two places and

one transaction.

- p1: input place

p1 t1 p2 - p2: output place

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

PROPERTIES
 Sequential Execution: Transition t2
can take place only after t1. Here
a constraint is imposed “t2 after
t1”

 Concurrency: This property is used

in Modelling distributed control
system. t1 and t2 are concurrent
process

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

PROPERTIES

 Merging: When several tokens are

arrived at same transition merging
will take place

 Synchronization: Transition t1 will

be enabled only when at least one
token is available at each of its
input places

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-1 POINT OF SALE (POS) MACHINE

 A point of sale terminal (POS terminal) is an
electronic device used to process card payments at
retail locations. A POS terminal generally does the
following:
 Reads the information off a customer’s credit or debit card
 Validate the user using 4-digit PIN number
 Checks whether the funds in a customer’s bank account are
sufficient
 Transfers the funds from the customer’s account to the
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

EXAMPLE-1 POINT OF SALE (POS) MACHINE

 Scenario 1: Normal
 Enters all 4 digits
and press OK.

 Scenario 2:
Exceptional
 Enters only 3
digits and press
OK.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

EXAMPLE-2 VENDING MACHINE

 The machine dispenses two kinds of snack bars 20c

and 15c. Constraint: 10c and 5c coins can only be
used
 Scenario 1:
 Deposit four 5c, take 20c snack bar.
 Scenario 2:
 Deposit 10 + 5c, take 15c snack bar.
 Scenario 3:
 Deposit 5 + 10 + 5c, take 20c snack bar.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL

EXAMPLE-2 VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 PETRINET MODEL
EXAMPLE-3 ORDER MANAGEMENT IN A RESTAURANT
 In the real world, many events are concurrent in
nature. Many applications have global state formed
from local state.
 Scenario 1:
 Waiter takes order from customer 1
 Serves customer 1
 Takes order from customer 2
 Serves customer 2.
 Scenario 2:
 Waiter takes order from customer 1
 Takes order from customer 2
 Serves customer 2
MODULE - 5  CSE3006 – EMBEDDED SYSTEM DESIGN
 PETRINET MODEL

EXAMPLE-3 ORDER MANAGEMENT IN A RESTAURANT

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

UNIFIED Modelling
LANGUAGE (UML)

75
 UNIFIED Modelling LANGUAGE (UML)
 What is Modelling Language?
A Modelling language is a graphical/textual computer
language explains design and construction of any
model or structure following a set of guidelines.

 Importance of Modelling : Visualization, reduced

complexity, documentation

 To effectively model a system, you need a language

with which the model can be described and here's
where UML comes in.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

INTRODUCTION

 UML - general purpose visual Modelling language

 It is used to visualize, specify, construct, and
document
 Using tools codes can be generated with UML
diagrams in various languages
 It is a pictorial language
 It can be used for both Modelling the software
system and non-software systems
 For example, modelling a process flow in automated
systems, etc.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

INTRODUCTION
 UML is used in many applications by many people
like business users, common people to make the
system simple, clear and understandable

 It is a simple modelling mechanism to model most of

the practical systems

 It is a object-oriented analysis based method

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
INTRODUCTION
UML Uses:
 Forecast systems
 To estimate the reusability.
 Lower costs
 Plan and analyze system behavior
 Easier maintenance/modification

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
INTRODUCTION
There are two types of diagram in UML
1. Structure diagram: explains static structure of a
system
 Class diagram
 Object diagram
 Deployment diagram
 Package diagram
2. Behavior diagram : used to model dynamic changes
 Use case diagram
 Interaction diagram
 Activity diagram
MODULE - 5  State diagramCSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
 Principles of UML Modelling

System
Use case diagrams
Requirement

System Structure Class diagram

System Sequence, state and

characteristics activity diagram

Implementation Component diagram

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

USE CASE DIAGRAM

82
 UNIFIED Modelling LANGUAGE (UML)

USE CASE DIAGRAM

 The use case diagram shows different ways a user
can interact with the system
 It can be used in scenarios like when system interact
with people or any other external systems
 It contains “use-cases” and ‘’actors’’
 Use case diagram depicts how the actor interacts
with use cases
 It describes the relationship between functionalities
and their controllers

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

USE CASE DIAGRAM

System

Actors

Use Cases

Relationships

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 9

 UNIFIED Modelling LANGUAGE (UML)
UML NOTATIONS
 Notations are very important in any modelling
language

 Efficient use of notations play a major role in making

any model meaningful

 Use case diagram: Notations of things and

relationships
 Extensibility makes UML more powerful and flexible.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS
 Use case - high level functionalities of a system.
 Use case is represented as an eclipse

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - ACTOR
 An actor - the internal or external entities.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - DEPENDENCY
 Dependency - relationship between two elements of
a system
 Dependency - dotted arrow
 Arrow head represents - independent element
 Other end - dependent element

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - ASSOCIATION
 Association - relationship between two elements
 Association describes how the elements are
associated.
 Association is represented by a dotted line with
(without) arrows on both sides
 The multiplicity (1, *, etc.) to show how many objects
are associated

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - GENERALIZATION
 Generalization - parent-child relationship
 Generalization - inheritance relationship of the
object-oriented concept
 Generalization - arrow with a hollow arrow head

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE NOTATIONS - <<include>> and <<extend>>

 ‘Extend’ and ‘Include’ – between use cases

 Include: invocation of one use case by the other

 Extend: extending use case will work exactly like the

base use case

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Banking Application

Verify
Primary actor – Initiates the process
<<Include>>
Password
Log in
Secondary actor – Responds
<<Extend>>
Error
Check Use case – Action
Balance
Customer
Association
Transfer
fund
Bank Exclude
Make
Include
Payment
Generalization

New Old
customer customer

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE- ATM SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 24

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE WASHING MACHINE
LAUNDRY

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 25

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE ELEVATOR SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 26

 UNIFIED Modelling LANGUAGE (UML)
USE CASE DIAGRAM EXAMPLE ELEVATOR SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 26

CLASS DIAGRAM

98
 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
 Class diagram- use to document software
architecture

 It is used to refine the use case diagram

 Set of interrelated classes

 It contains methods and attributes for classes

 Classes can be "is-a" or "has-a" relationship

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
 Class diagram - Static diagram, Structural diagram

 Class diagram - attributes and operations of a class

 It explains the constraints on the system

 It is a collection of classes, interfaces, associations,

collaborations and constraints

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

CLASS DIAGRAM
 The purpose of the class diagram can be summarized
as −

 Analysis and design of system

 Describe responsibilities of a system

 Conceptual modelling

 Forward and reverse engineering

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
UML NOTATIONS - CLASS
 Classes are used to represent objects

 UML class diagram is divided into four parts.

 Top section - name the class.
 Second - attributes of the class.
 Third - operations or methods performed by the class.
 Fourth - any additional components.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Class

Relationship
Attributes s

Method
s

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Student Information-Class Diagram
Class Student
Visibility
+ name: String + Public
#Roll: Int - Private
Attributes -Section: String # protected
~ Package/default
+ display ()
Method -Add () Inheritan
s -Edit () ce
# Delete ()
Associatio
n

Anil Aggregati
Sunil
on

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Classroo
m Multiplicity
N
0…*
0…1
1…*
m…n

1…* 1
Tables Projecto
r
Compositi
on

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE- ATM SYSTEM

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 43

 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE ELEVATOR SYSTEM

Simplified Class Diagram Detailed Class Diagram

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 45

 UNIFIED Modelling LANGUAGE (UML)
CLASS DIAGRAM EXAMPLE WASHING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 46

SEQUENCE DIAGRAM

109
 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM
 Sequence diagram - interactions among the different
elements in the model

 It describes the dynamic behavior of the system

 They explain the interaction between objects and

collaborations

 It emphasizes on the time sequence of messages and

structural organizations of the objects

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM
 Sequence diagram shows the details of the use cases

 It shows the complete flow of information, function

and operations of the system

 It is used in planning and understanding the

functionality of existing and future scenario

 Time – vertical direction

 Header elements – Horizontal direction

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM
 Sequence Diagrams are suitable for following
scenarios:
 Usage scenario – to determine how the system
could be used
 Method logic – to explore logic of any function,
procedure or complex process
 Service logic – ideal way to explain high level
methods used by clients

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

Actor Object Activation

Bar Synchronous message
Lifeline
Notation Comment
Return
message

Alternate frame
Alt
If it is valid

Else

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM EXAMPLE PRODUCT PURCHASE

SYSTEM
 In this sequence diagram we have four objects
 Customer
 Product
 Stock
 Payment
 The message starts from the top and flows to the bottom
(waterfall manner)
 Dashed lines - duration for object
 Horizontal rectangles - activation of the object
 Messages sent - dark arrow and dark arrow head
 Return message - dotted arrow
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

SEQUENCE DIAGRAM EXAMPLE - PRODUCT PURCHASE

SYSTEM
 Customer object - to the product object
 Product object -to the stock object
 Stock object - saying yes or No.
 Product object sends - customer object.
 Customer object -payment object to pay money.
 Payment object - receipt to the customer object.

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
PRODUCT PURCHASE SYSTEM
Customer
Product Stock Payment
Request Product
In stock?

Yes/No
Yes/No

Payment

Receipt

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM EXAMPLE ELEVATOR SYSTEM

Sequence Diagram for Serving Elevator Button

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 58
 UNIFIED Modelling LANGUAGE (UML)
SEQUENCE DIAGRAM EXAMPLE VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

STATE DIAGRAM

119
 UNIFIED Modelling LANGUAGE (UML)

STATE DIAGRAM

 State diagram stores the status of object

 It shows the condition of system over a finite
instance of time
 It’s a behavioral diagram
 It also referred to as State machines and State-chart
Diagrams.
 It explains the dynamic behavior of a class
 State diagrams an be used to understand the
reaction of objects on receiving external stimuli
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

STATE DIAGRAM
 Uses of state chart diagram:
 We use it to depict event driven objects
 We use it for showing use cases in business context
 Shows the overall behavior of state machine
 We use it to model the dynamic behavior of the system .
 Steps to draw a state diagram:
 Identify the initial state and the final states.
 Identify the possible states in which the object can exist
 Label the events which trigger these transitions.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM SYMBOL NOTATIONS

Initial state Transition Symbol

State
Composite State

Final state
Self Transition

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
ONLINE ORDER MANAGEMENT Transitio
n

Send Special or
Idle order Normal
request order v
v
Initial Abnormal
state exit state
Order
Final confirmation
state v

Dispatch
order v

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM EXAMPLE ATM MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

 UNIFIED Modelling LANGUAGE (UML)
STATE DIAGRAM EXAMPLE ELEVATOR SYSTEM

Statechart
Statechart for for
"User" “Elevator
Behavior Control
System"

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

ACTIVITY DIAGRAM

126
 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM
 An activity diagram - behavioral diagram

 It shows the control flow from start to finish point

including other decisions paths that is being
executed

 It can explain both sequential and concurrent

processing

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM

 Uses of Activity chart diagram:

 Modelling work flow by using activities
 Modelling the logic of algorithm
 Shows the workflow process between users and
system
 Understanding system's functionalities.
 Investigating business requirements at a later
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)

ACTIVITY DIAGRAM
 Steps to draw a activity diagram:
 Identify the initial state and the final states.
 Identify the intermediate activities needed to
reach the final state from the initial state.
 Identify the conditions or constraints which cause
the system to change control flow.
 Draw the diagram with appropriate notations.
MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN
 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM SYMBOL NOTATIONS

Action Control flow Object flow

Activity

Initial node Final node Object node Decision node Merge node

Fork node
Join node

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
Activity Diagram of an Order Management System

Customer Order request

sends an system confirms the Condition
order order check
Start of request [No]
process
[Yes]

[Yes]
Confirm order
[No]
Termination

Dispatch order

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN

 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM EXAMPLE ELEVATOR SYSTEM

ELC – Elevator Logic Control

ERS – Elevator Request Service

Request Elevator Activity

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59
 UNIFIED Modelling LANGUAGE (UML)
ACTIVITY DIAGRAM EXAMPLE VENDING MACHINE

MODULE - 5 CSE3006 – EMBEDDED SYSTEM DESIGN 59

THANK YOU…