Professional Documents
Culture Documents
UNIT 1
MV Pankaj Lahari
Asst. Professor, EEE
UNIT 1
Introduction to Real Time Embedded System
2
Embedded (?) System
Embedded Processor can mean:
A processor is sharing the bed the silicon wafer with all its components
(memory, peripherals, I/O ports, etc) ( System-on-chip ) [6]
The program (the instructions/ code/ logic) is embedded inside the
processor
Embedded System: A system that has software embedded into its hardware,
and is dedicated for a specific application(s) or a specific part of an application/
product or part of a larger system [1]
(OR)
It is a combination of software and hardware which is dedicated for one or few
specific purposes.
3
General Purpose System vs Embedded System
Embedded Systems
System on Chip
Special purpose
Rarely need an external intervention (once they start their job they do it for a long
time and they do it very well, unlike PCs where every task has to be initiated by the
user)
4
Embedded System Components
Its Hardware: Processor, I/O ports, Prripherals (ADC, DAC, Serial
Communication, etc), Timers etc
RTOS (If real time): Supervises the application software and organises the
accesses to various system resources based on the priorities and timing
constraints of the tasks in the system.
5
Types of Embedded Systems [2]
Based on
Based on
performance of
Functional
Microcontroller/
Requirements
processor
Configurable
Sophisticated Processors, ASIPs,
Embedded PLAs, Highly
Systems complex H/w S/w
designs
Real Time Embedded System
Real Time Embedded System: An embedded system whose correctness
depends not only on the correctness of the output but also it timeliness.
(or)
A real time system is any information processing system which has to respond to
externally generated input stimuli (/events) within a finite and specified time
This predictable deadline has nothing to do with speed. The response has to be
within a known limited amount of time, whether it is a microsecond, an hour, a
day or a month. [1]
7
Few Examples of RTES
Medical Equipment
Nuclear Systems
8
Types of Real Time Embedded Systems [4]
- Classification 1
Hard Real Time Systems
A hard real-time system is one in which failure to meet a single deadline may lead to
complete and catastrophic system failure.
9
Hard Real Time Systems [2][3]
Hard real time systems are designed to absolutely guarantee that a task will
execute in a certain worst-case time frame.
Tasks have to be executed in known amount of time; failing to meet their time
deadlines result in serious damages
A hard real-time system is a real-time system that must meet its deadlines with a
near-zero degree of flexibility
10
Soft Real Time Systems [2][3]
Soft real time systems are designed to satisfy the timing requirements but not with
absolute certainty
A soft real-time system is a real-time system that must meet its deadlines but with a
degree of flexibility.
Tasks have to be executed in known amount of time; failing to meet their time deadlines
result in serious damages
11
Characteristics of Hard vs Soft RTES [3]
12
Types of Real Time Embedded Systems [5]
- Classification 2
Fast Real Time Systems
A real time system that works with sub-second response times is called FAST real time
system.
Soft Real Time Systems can be fast too eg: data transfer may occur by a
router with nanoseconds rate, but it is a soft real time system.
Hard Real Time Systems can be slow too- eg: The cadmium rods inside a
nuclear reactor need not be pulled out at lightening speed.
13
Characteristics/ Features of RTES [7]
Single-Functioned
Single-functioned means specific functions. The RTES is usually meant for very
specific functions.
Generally a special purpose microprocessor executes a program over and over again
for a specific purpose
Example: we never reboot a refrigerator/ washing machine
Time Constrained
Every real-time task is associated with some time constraints.
One form of time constraints that is very common is deadlines associated with tasks
Other types of timing constraints are delay and duration (times of ISRs, response
times in case of event failures etc)
It is the responsibility of the real-time operating system (RTOS) to ensure that all tasks
meet their respective time constraints.
14
Characteristics/ Features of RTES Contd
Correctness Criterion
Unlike conventional systems, correctness implies not only logical correctness of the
results, but the time at which the results are produced is important.
A logically correct result produced after the deadline would be considered as an
incorrect result
Safety-Criticality
For traditional systems, safety and reliability are independent concerns
In many real-time systems there are no fail-safe states. Therefore, any failure of the
system can cause severe damages. Such systems are said to be safety-critical systems.
In a safety-critical system, the absence of fail-safe states implies that safety can only
be ensured through increased reliability
Thus, for safety-critical systems the issues of safety and reliability become
interrelated
15
Characteristics/ Features of RTES Contd
Concurrency
A real-time system usually needs to respond to several independent events within
very short and strict time bounds
The real-time system must process data from all the sensors
concurrently, otherwise signals may be lost and the system may malfunction
Example: chemical plant automation- controls the rate of reaction by changing the
different parameters of reaction such as pressure, temperature, chemical
concentration.
Example 2: a cars cruise controller continually monitors and reacts to speed and
brake sensors. It must compute acceleration or
deceleration amounts repeatedly within a limited time
Reactive
Real-time systems are often reactive. A reactive system is one in which an ongoing
interaction between the computer and the environment is maintained
16
Characteristics/ Features of RTES Contd
Distributed and Feedback Structure
In many real-time systems, the different components of the system are naturally
distributed across widely spread geographic locations
The different events of interest arise at the geographically separate locations
Many distributed as well as centralized real-time systems have a feedback structure
Task Criticality
Task criticality is a measure of the cost of failure of a task.
Task criticality is determined by examining how critical are the results produced by the
task to the proper functioning of the system.
A real-time system may have tasks of very different criticalities.
It is therefore natural to expect that the criticalities of the different tasks must be taken
into consideration while designing for fault-tolerance
17
Characteristics/ Features of RTES Contd
Custom Hardware
A real-time system is often implemented on custom hardware that is specifically
designed and developed for the purpose
An embedded programmer cannot afford the level of hardware independence as in
general purpose systems, since his code interacts directly with the underlying hardware
In contrast to the traditional computation of the output as a simple function of the input
data, real-time systems do not produce any output data but enter into an on-going
interaction with their environment.
The computations in a real-time system can be considered to be non-terminating
Stability
Under overload conditions, real-time systems need to continue to meet the deadlines of
the most critical tasks, though the deadlines of non-critical tasks may not be met.
This is in contrast to the requirement of fairness for traditional systems even under
overload conditions.
18
Characteristics/ Features of RTES Contd
Exception Handling [8]
Many real-time systems work round-the-clock and often operate without human
operators
The extent and complexity of the exception handling mechanisms will make it
difficult to calculate and meet timing constraints
Programmed Exception Handling, Default Exception Handling
19
Applications of RTES
Mainly two general classes of applications [9]
Event Response Applications
Closed-loop Control Applications
Event response applications require a response to a stimulus in a certain amount of time
Eg: Automated visual inspection of assembly line parts, Automated Car Assembly
Plant
In this visual inspection system, for example, each part must be photographed and
analyzed before the assembly line moves
In contrast, closed-loop control systems, such as an automotive cruise control system,
continuously process feedback data to adjust one or more outputs
Eg: automated chemical plant, a real-time computer periodically monitors plant
conditions. The plant conditions are determined based on current readings of pressure,
temperature, and chemical concentration of the reaction chamber. These parameters
are sampled periodically. Based on the values sampled at any time, the automation
system decides on the corrective actions necessary at that instant to maintain the
chemical reaction at a certain rate
20
Applications Areas [7]
Industrial Applications
Industrial applications constitute a major usage area of real-time systems.
A few examples of industrial applications of real-time systems are: process control
systems, industrial automation systems, SCADA applications, test and measurement
equipments, and robotic equipments
Automated Car Assembly Plant - The time constraint imposed on the workstation
computer is that the workstation must complete its work before the work product
moves away to the next workstation.
Supervisory Control And Data Acquisition (SCADA)-
In SCADA systems to collect raw data (called events of interest). These data are then
processed and stored in a real-time database.
An example of a SCADA application is an Energy Management System (EMS).
An EMS helps to carry out load balancing in an electrical energy distribution network.
The EMS senses the energy consumption at the distribution points and computes the
load across different phases of power supply. It also helps dynamically balance the
load.
21
Applications Areas [7]
Medical : robots, MRI scanners, radiation therapy equipments, bedside monitors
Robot used in Recovery of Displaced Radioactive Material: Radioactive materials
such as Cobalt and Radium are used for treatment of cancer. At times during
treatment, the radioactive Cobalt (or Radium) gets dislocated and falls down. Since
human beings can not come near a radioactive material, a robot is used to restore the
radioactive material to its proper position
Peripheral equipments :A few examples of peripheral equipments that contain
embedded real-time systems are: laser printers, digital copiers, fax machines,
digital cameras, and scanners.
Eg: Laser Printer: Activities by the embedded system include getting data from the
communication port(s), typesetting fonts, sensing paper jams, noticing when the
printer runs out of paper, etc
The most complex activity that the microprocessor performs is driving the laser
engine. The basic command that a laser engine supports is to put a black dot on the
paper. The laser engine has no idea about the exact shapes of different fonts, font
sizes, etc
22
Applications Areas [7]
The embedded microprocessor receives print commands on its input port and
determines how the dots can be composed to achieve the desired document and
manages printing the exact shapes through a series of dot commands issued to the
laser engine
Automotive and Transportation: A few examples of automotive and
transportation applications of real-time systems are: automotive engine control
systems, road traffic signal control, air-traffic control, high-speed train control,
car navigation systems, and MPFI engine control systems.
Careful experiments have suggested that for optimal energy output, the required
fuel injection rate is highly nonlinear with respect to the vehicle speed and
acceleration. Also, experimental results show that the precise fuel injection through
multiple points is more effective than single point injection. In MPFI engines, the
precise fuel injection rate at each injection point is determined by a computer
The processor primarily controls the ignition timing and the quantity of fuel to be
injected. The latter is achieved by controlling the duration for which the injector
valve is open popularly known as pulse width
23
Applications Areas [7]
Telecommunication Systems: Few examples are cellular
systems, video conferencing, and cable modems
Eg: Cellular System: A cellular system usually maps a city into cells. In each cell, a
base station monitors the mobile handsets present in the cell. Besides, the base station
performs several tasks such as locating a user, sending and receiving control messages
to a handset, keeping track of call details for billing purpose, etc
Aerospace: Real-time systems in aerospace applications are: avionics,
flight simulation, airline cabin management systems, satellite tracking systems,
and computer on-board an aircraft.
Computer On-board an Aircraft: As soon as the pilot
switches to the auto pilot mode, an on-board computer takes over all controls of the
aircraft including navigation, take-off, and landing of the aircraft. In the auto pilot
mode, the computer periodically samples velocity and acceleration of the aircraft.
From the sampled data, the on-board computer computes X, Y, and Z co-ordinates of
the current aircraft position and compares them with the pre-specified track data.
24
Applications Areas [7]
Internet and Multimedia Applications: Video conferencing and multimedia
multicast, Internet routers and switches.
Consumer Electronics: set-top boxes, audio equipment, Internet telephony,
microwave ovens, intelligent washing machines, home security systems, air
conditioning and refrigeration, toys, and cell phones.
Eg: converting input voice to digital signals by deploying digital signal processing
(DSP) techniques, converting electrical signals generated by the microphone to output
voice signals, etc
Defence Applications: Missile guidance systems, antimissile systems, satellite-
based surveillance systems.
Miscellaneous Applications: real-time systems have found numerous other
applications in our every day life.
Eg: Railway Reservation System
25
Applications Areas [10]
In a real-time simulation, the real-time simulator used must accurately produce the
internal variables and outputs within the same length of time that its physical
counterpart would.
(For digital simulation, which is the one suitable for real time simulation, it is
assumed that a simulation with discrete-time and constant step duration is performed,
ie, fixed time-step duration)
26
Application Areas [9] :
Offline Simulation vs Real Time Simulation
27
Why Real Time Simulation (RTS)?
The main idea using real time control is to smoothen transition from the non- real
analysis and simulation to the real time experiments and implementation
Design issues can be discovered earlier in the process, enabling required tradeoffs
to be determined and applied, thereby reducing development costs
28
Why RTS? Contd..
29
Why RTS? Contd..
Testing costs can be reduced.
RTS can replace risky and / or expensive tests using physical test benches.
Testing results are more repeatable since real-time simulator dynamics do not change
through time the way physical systems do
A model executed on a real-time simulator can also be modified online, which is not
possible with a real plant.
30
RTS Application Types
Hardware-in-the-loop (HIL)
HIL:
- A physical controller is connected to a virtual plant executed on a real-time
simulator, instead of to a physical plant
32
RTS Application Types Contd..
33
An RTS application from ABB: Traction
In the case of traction applications, the controller operates on the power electronics of the
traction converter inside the train
The Physical model replaces the converter and the train, while the controller remains
connected in a closed-loop fashion with this physical model
The traction RTS has, in addition, a virtual vehicle control unit on which the desired
tractive effort or speed reference are set in the same way as on the real vehicle by the
driver
34
HIL Simulation
35
Few Implemented Electrical Applications of RTS-
1. Front panel of Green house parameter monitoring system
36
Few Implemented Electrical Applications of
RTS-
2. Synchrophasors
37
Issues in Real Time Computing [11] [13]
Meeting the deadlines
One brute way of meeting the deadlines is to speed up the hardware so that the
program runs faster
Increasing the CPU clock rate makes the system more expensive too.
Hardware Requirements:
Not only the controller/ processor is to be selected but also the amount of memory,
peripherals devices needed for communication etc are to be selected.
Performance deadlines as well as (manufacturing) cost constraints are to be met, and
hence, hardware choices are important
Too little hardware and the system fails to meet its deadlines; Too much hardware
and it becomes too expensive!
38
Issues in Real Time Computing [11]
Power Consumption
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 slower. But
that might lead to missing deadlines sometimes.
Restricted development environments
The tools used to develop software and hardware for real time systems are much more
limited than those available for general purpose systems.
The code is generally compiled on a PC, and then download it on to the embedded
processor.
To debug the code after an undesired operation, we must once again rely on the
program running on the PC
39
Issues in Real Time Computing [11]
Complex Testing
Absence of standard I/O devices limited observability & controllability
No keyboards or screens are readily available for an embedded computing system,
making it difficult to see what is happening and affecting the systems operation
Debugging gets very difficult because of this.
How do we design for upgradability
The system being designed should be able to add features by changing software
How can we design a system that will provide the required performance for software
that we have not written yet ?
40
Issues in Real Time Computing [12]
Presence of combination of hard and soft real time tasks/activities in a
system [12]
Scheduling for soft real time tasks is indeed harder than hard real time tasks as it
requires that when necessary, some timing constraints should be relaxed in some
optimal manner, provided the quality of service remains acceptable
Synchronous vs Asynchronous real time (time driven vs event driven) [12]
Synchronous one guarantees everybody gets something, asynchronous winner
takes all winner being elected by the application of scheduling criteria
Divide between application software & real time system
The application software is immaterial and untimed. Its real time properties depend
on the speed of the underlying platform and the interaction with external
environment.
41
Issues in Real Time Computing [13]
Recovering from Internal Failures
Software Failures in a Task : This becomes even more important in a Real-time
system because sequence of events can result in a large number of scenarios. It may
not be possible to test all the cases in the laboratory environment
Processor Restart: It is not possible to bring down the complete system on failure of
a single node thus design the software to handle independent failure of any of the
nodes.
This involves two activities: Handling Processor Failure , Recovering Context for
the Failed Processor
Link Failure : The system should be able to isolates a link failure and reroute
messages so that link failure does not disturb the message communication.
Recovering from External Failures
Invalid Behavior of External Entities
Inter Connectivity Failure
42
Issues in Real Time Computing [13]
Working with Distributed Architectures
Most Real-time systems involve processing on several different nodes. The system
itself distributes the processing load among several processors. This introduces
several challenges in design
Maintaining Consistency
Initializing the System: Initializing a system with multiple processors is far more
complicated than bringing up a single machine
Inter -Processor Interfaces
Load Distribution: When multiple processors and links are involved in message
interactions distributing the load evenly can be a daunting task.
Centralized Resource Allocation
Race Conditions and Timing
A race condition is defined as a situation in which multiple threads/tasks or
processes read or write to a shared data object and the final result depends on the
order of execution
43
Performance Measures of Real Time System
Latency
CPU load
Software Performance Metrics
RTCES 2016_GVPCE(A)_unit 1 44
Performance Metric - Memory
All embedded systems have some limitations on available memory
There are a number of factors that affect the memory footprint of an RTOS. The
CPU architecture is key. The number of instructions can vary drastically from one
processor to another (so looking at size figures for, say, PowerPC gives no indication of what the
ARM version might be like)
RTCES 2016_GVPCE(A)_unit 1 45
Performance Metric - Interrupt Latency
The time related performance measurements are probably of most concern to
developers using an RTOS
A key characteristic of a real time system is its timely response to external events
It is to be known whether the supplied figure(from the vendor) is the best or the
average.
RTCES 2016_GVPCE(A)_unit 1 46
Performance Metric- CPU Load [16]
CPU utilization, U, as the amount of time not in the idle task
Each task gives a load to the CPU that equals the task execution time divided by
the task period
CPU load equal to 0.1 (10%) means the CPU is underutilized and spends its
90% time in a waiting mode/ idle mode/ idle task
RTCES 2016_GVPCE(A)_unit 1 47
Software Performance Metrics [17]
Performance profiling
A means of determining where a system is spending its time on a function-by-function
basis
AB timing
This is a means of measuring the time that it takes to get from one specified point in
code to another
The most crucial timing measurement for real-time systems, as it allows developers to
verify whether the timing objectives for a piece of code are being satisfied.
Response to external events
This is a means of measuring the time between an external event occurring and the
software responding to that event (e.g., interrupt latency periods)
RTOS task performance
Task deadline performance measurements
Task profiling performance measurements
RTCES 2016_GVPCE(A)_unit 1 48
Measuring the performance of RTS
Software-only methods
Stack sampling
Code instrumentation
Source code instrumentation
Object code instrumentation
Hardware assisted methods
Logic Analyzers
In-circuit Emulators
Tests for measuring real time operating system performance [15]
Tests for message passing
Tests for task synchronization and event handling
Test for the speed of task switching
Test for the speed of interrupt handling
RTCES 2016_GVPCE(A)_unit 1 49
Measuring the performance of RTS [18]
Benchmark Programs
a benchmark is the act of running a computer program, a set of programs, or other
operations, in order to assess the relative performance of an object, normally by
running a number of standard tests and trials against it.
Eg: Rhealstone benchmark set of six C programs for measuring Average task
switch time, Average interrupt latency, Inter-task message latency, semaphore shuffle
time
Performance Monitors
Performance monitoring consists of gathering data on a system during its operation
and condensing them into a form suitable for interpretation. Monitoring tools fall into
one of the four categories: hardware monitors, software monitors, firmware monitors
and hybrid monitors.
One may consider most of the mentioned benchmarks as software monitors. In order
to obtain more precise results, one may introduce external monitoring devices
(hardware monitors), or observe timing events at a lower level (firmware monitors).
When hardware monitors have some internal logic for the interpretation of measured
times we speak about hybrid monitors.
RTCES 2016_GVPCE(A)_unit 1 50
Real Time Systems Requirement-specifications [4],[19]
Requirements: informal description from the
consumer about the real time application
The demands placed on a real-time system
arise from the needs of the application and
are called the requirements
RTCES 2016_GVPCE(A)_unit 1 51
Types of Requirements [11],[19]
Functional Requirements
Define the operations of the system and their effects
Include description of all system inputs and the sequence of operations associated
with each input set
Non-functional requirements
Performance
Cost 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
Power Consumption
RTCES 2016_GVPCE(A)_unit 1 52
Sample Requirements Form [11]
RTCES 2016_GVPCE(A)_unit 1 53
Specifications of Real Time System [4],[11],[19]
The first task in developing a specification is to make the informal description
more precise.
A specification should not enforce any decisions about the structure of the
software, the programming language to be used or the kind of system on which
the program is to be executed: these are properly implementation decisions
RTCES 2016_GVPCE(A)_unit 1 54
Specification Techniques [19]
Formal
Formal methods are based on the use of rigorous discrete mathematics and logic for
building descriptions and specifications of a real time system
Informal
The specification cannot be transliterated into mathematical notation ; thus, cannot be
properly analysed
Eg Flowchart
Semiformal
Partly mathematical
Conlusion: For real time systems, formal specifications are necessary mostly
RTCES 2016_GVPCE(A)_unit 1 55
Typical Formal Specification Example [4]
RTCES 2016_GVPCE(A)_unit 1 56
Design Tools for Real Time Systems
Specifying and designing real-time systems is complex because real-time systems
require logical correctness as well as timing correctness
RTCES 2016_GVPCE(A)_unit 1 57
Finite State Machines [4]
Finite state automation (FSA), Finite state machine (FSM) or state transition
diagram (STD) is a formal mathematical model used in the specification and
design of a wide range of systems.
FSMs rely on the representation of a system by a fixed number of unique states
FSM can be represented in diagrammatic, set-theoretic or matrix representations
RTCES 2016_GVPCE(A)_unit 1 58
Finite State Machines [4]s
RTCES 2016_GVPCE(A)_unit 1 59
Finite State Machines [4]s
RTCES 2016_GVPCE(A)_unit 1 60
Finite State Machine Contd [4]
If the FSM does not depict outputs during
transitions, it is called Moore transition
A Finite State Machine which depicts
outputs during transitions is called Mealy
transition
Mathematically-
S is set of all the states Fig: A generic Mealy Machine for a
3 state machines with 3 events,
i is the initial state 3 outputs
T set of terminal states
Signma is the set of events or symbols used
to mark the transitions
Delta transition function that describes the
next state of the machine given the current Fig: Transition Matrix for above FSM
state
set of outputs (if mealy transition)
RTCES 2016_GVPCE(A)_unit 1 61
State Charts [4]
State charts combine FSMs with data flow
diagrams and braodcast communication
State charts = FSM + depth + orthogonality
+ broadcast communication
FSM : Finite State Machine
Fig: State chart format
Depth (abstraction): represents level of
detail insideness of the states
Orthogonality (concurrency): represents
existence of separate (isolated) tasks
Broadcast communication: method
allowing different orthogonal processes to
react to the same event
State chart resembles a FSM where each
state contains its own FSM that describes it
behaviour
RTCES 2016_GVPCE(A)_unit 1 63
State Charts Contd
Orthogonality Example Y is the orthogonal product of A and D
RTCES 2016_GVPCE(A)_unit 1 64
Default States in Statecharts [22]
RTCES 2016_GVPCE(A)_unit 1 65
Unified Modelling Language [20]
Object-oriented Decomposition of
Real-time Systems
The principal component of object
oriented design is the object.
An object includes a set of
attributes which define its internal
state
When implemented in a
programming language these
attributes usually become the
variables or constants held in a
data structure.
Class is a form of type definition
All objects derived from same
class have same characteristics,
although their attributes may have
different values
A class also defines the operations
that determine how the objects
interacts with rest of the world
RTCES 2016_GVPCE(A)_unit 1 66
UML Diagrams [21]
Different UML diagrams provide different perspectives of the software system to
be developed and facilitate a comprehensive understanding of the system.
Such models can be refined to get the actual implementation of the system.
The UML diagrams can capture the following five views of a system:
Users view
Structural view
Behavioural view
Implementation view
Environmental view
RTCES 2016_GVPCE(A)_unit 1 67
UML diagrams views [21]
Users view
This view defines the functionalities (facilities) made available by the system to its
users
The users view is a black-box view of the system where the internal structure, the
dynamic behavior of different system components, the implementation etc. are not
visible.
The users view is very different from all other views in the sense that it is a
functional model compared to the object model of all other views
Use case diagrams are used here
Structural view / Design View
The structural view defines the kinds of objects (classes) important to the
understanding of the working of a system and to its implementation.
It also captures the relationships among the classes (objects). The structural model is
also called the static model, since the structure of a system does not change with time.
Class and object diagrams
RTCES 2016_GVPCE(A)_unit 1 68
UML diagrams views Contd [21]
Behavioural view/ Process View
The behavioural view captures how objects interact with each other to
realize the system behaviour. The system behaviour captures the time-dependent
(dynamic) behaviour of the system
State charts
Sequence Diagrams
RTCES 2016_GVPCE(A)_unit 1 69
Use Cases [21]
Use cases represent the different ways in which a system can be used by the
users
The use cases do not mention any specific algorithm to be used
or the internal data representation, internal structure of the software, etc.
A use case typically represents a sequence of interactions between the user
and the system.
Each stick person icon is normally referred to as an actor.
An actor is a role played by a user with respect to the system use.
The line connecting the actor and the use case is called
the communication relationship
Both the human users and the external systems can be represented by
stick person icons. When a stick person icon represents an external system, it
is annotated by the stereotype <<external system>>
RTCES 2016_GVPCE(A)_unit 1 70
Use Cases Contd
Use cases can be represented by drawing a use case diagram and writing an
accompanying text elaborating the drawing.
In the use case diagram, each use case is represented by an ellipse with the
name of the use case written inside the ellipse.
All the ellipses (i.e. use cases) of a system are enclosed within a rectangle
which represents the system boundary. The name of the system being modelled
appears inside the rectangle
The different users of the system are represented by using the stick person icon
RTCES 2016_GVPCE(A)_unit 1 71
Example- Use case diagram for ATM
RTCES 2016_GVPCE(A)_unit 1 72
Class Diagrams
A class diagram describes the static structure of a system. It shows how a system
is structured rather than how it behaves
The static structure of a system comprises of a number of
class diagrams and their dependencies.
The main constituents of a class diagram are classes and their relationships:
generalization, aggregation, association, and various kinds of dependencies
RTCES 2016_GVPCE(A)_unit 1 73
Class Diagrams Contd [20]
Relationships between objects & classes
Association: objects that communicate
with each other but have no ownership
relation between them
Aggregation : a complex object made of
smaller objects
Composition: a type of aggregation in
which the owner doesnt allow access to
component objects
Generalization: allows to define one class
in terms of another
Derived Classes: Inherits all attributes
from its base class.
Multiple inheritance derived class has
more than one base class
UML consists inheritance to be a form of
generalization (unfilled arrow)
RTCES 2016_GVPCE(A)_unit 1 74
Multiple Inheritance in Class diagrams [20]
The derived class inherits the attributes of both its base classes
RTCES 2016_GVPCE(A)_unit 1 75
Eg system representation
using class diagram:
In this diagram, a customer
(CUSTOMER Class) has a mobile
device (MOBILE_DEVICE Class) and
card (CARD Class) which may
be credited (CREDIT_CARD Class) or
debit (DEBIT_CARD Class) card. The
customer enquires from the billsection
(BILL_SECTION Class) through
network available on the mobile
device. The main role of this bill
section is to generate the bills and after
the payment of the
bills, this section sends a copy to the
Electricity Department (ELECT_DEPT
Class) and SMS to the mobile device of
the customer. The payment of the bill is
only done after the verification of the
customer card by the
bank consortium
(BANK_CONSORTIUM Class) which
has separate verification department
(VERIFICATIONClass).
RTCES 2016_GVPCE(A)_unit 1 76
State charts in UML [20]
RTCES 2016_GVPCE(A)_unit 1 77
Sequence Diagrams UML [20]
Sometimes it is useful to show the sequence of operations over time
Sequence diagrams show timing vertically
The dashed lines are the lifelines, which shows for how long is an object alive
The boxes along the dashed lines show the focus of control in the sequence, ie,
when the object is actively processing
RTCES 2016_GVPCE(A)_unit 1 78
Eg system representation using sequence diagram
RTCES 2016_GVPCE(A)_unit 1 79
References
[1]
[2]
[3]
[4] Text by Laplante
[5] Embedded Realtime Systems Programming by Pankaj Gupta
[6]-Embedded Systems by B Kanta Rao
[7] NPTEL chapter 28
[8]
[9]
[10]
[11] Challenges from ES Wayne Wolf
80
References Contd
[12] Modelling real time systems challenges and work directions (by Joseph
Sifakins)
[13] issues in real time design (eventhelix.com)
[14]
[15]
[16]
[17] performance metrics(software) by nxp
[18]
[19]Real-time Systems Specification, Verification and Analysis Edited by Mathai
Joseph
[20] ES by Wayne Wolf section 1.3
[21] NPTEL chapter 37
[22] Statecharts: A Visual Formalism For Complex Systems by David Harel
http://www.inf.ed.ac.uk/teaching/courses/seoc/2005_2006/resources/statecharts.p
df
81