Sie sind auf Seite 1von 81

Real Time Concepts of Embedded Systems

UNIT 1

MV Pankaj Lahari
Asst. Professor, EEE
UNIT 1
Introduction to Real Time Embedded System

Types of Real Time Systems

Real Time Applications

Features/ Characteristics of a Real Time System

Issues/ problems/ challenges in Real Time Systems

Performance measures of Real Time System, real-time


requirement specifications, modeling /verifying design tools (real-time UML,
state charts, etc.,).

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

Interacts with the environment makes the system intelligent/ smart

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)

Not programmable by end user

Examples of embedded systems : MP3 players, Washing machines, smart-phones,


GPSs, anti-lock braking systems, security alarms, LAN routers, airplane autopilot
systems, nuclear power-plant control systems

4
Embedded System Components
Its Hardware: Processor, I/O ports, Prripherals (ADC, DAC, Serial
Communication, etc), Timers etc

Its Software (Application Software) : The application-specific code


Note: There is no system software here, which initializes all the applications software,
etc. No booting from an external hard disk takes place.

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

Small Scale 8/16 bit c, Less


Embedded H/w, Less S/w, NO Non- Real Time
Systems RTOS

Medium Scale 16/32 bit c, DSPs,


Embedded RISCs, H/w S/w Real Time
Systems complexities, RTOS.

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]

The key component that is needed to build a real-time system is a Real-Time


Operating System (RTOS)

7
Few Examples of RTES

Medical Equipment

Airbag System in an Automobile

Aerospace (autopilot) systems

Nuclear Systems

Railway Traction Systems

Critical Power Electronic 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.

Firm Real Time Systems


A firm real-time system is one in which a few missed deadlines will not lead to total
failure, but missing more than a few may lead to complete and catastrophic system
failure.

Soft Real Time Systems


A soft real-time system is one in which performance is degraded but not destroyed by
failure to meet response-time constraints

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

A late answer is a wrong answer

Examples: Airbag System, Autopilot Systems

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

Example: Video streaming applications

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.

Slow Real Time Systems


Real Time systems whose response times are a second or more are classified as slow
real time systems

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]

REAL TIME SIMULATION


During a discrete-time simulation, the computation time may be longer or shorter than
the real time. This is called Offline Simulation

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

It compensates for the shortcomings of offline and onsite testing

Model-based Design (MBD): By using models, a common design environment is


available to every engineer involved in creating a system from beginning to end

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..

When a user or physical equipment


interacts with a real time model, they
can provide model inputs and get
model outputs, as it would with a real
plant

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.

Any model parameter can be read and updated continuously.

30
RTS Application Types

Rapid Control Prototyping (RCP)

Hardware-in-the-loop (HIL)

Fig: Control System Block Diagra


31
RTS Application Types Contd..
RCP:
-A plant controller is implemented using a real-time simulator and is connected to
a physical plant
-A controller prototype developed using a real-time simulator is more flexible,
faster to implement and easier to debug

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

Controller FPGA technology


Traction System(physical model) dSPACE- based simulation platform

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

Performance refers to the response time or throughput as seen by


the users

Performance metrics [14]


Memory

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

Efficient utilization of ROM and RAM is a metric for performance of the


system

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)

Embedded compilers generally have a large number of optimization settings.

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

An embedded system is typically notified of an event by means of an interrupt,


so the delay between the interrupt occurring and the response to that interrupt
the interrupt latency is critical

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

Specification: Refined requirements


containing enough information wrt design
process system architecture of the real time
application

Separating out requirements analysis and


specification is often necessary because
of the large gap between what the customers
can describe about the system they want and
what the architects need to design the system

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

For a real-time system, the functional and non-functional requirements must be


precisely defined and together used to construct the specification of the system.

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 be abstract so that


It can be checked for conformity against the requirement
Its properties can be examined independently of the way in which it will be
implemented

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

Decomposition of the real-time system into components is a major issue for


handling complexity

Some techniques for specifying and designing real time systems-


Finite State Machines
State Charts
Unified Modelling Language (UML)

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

States in FSM Signals


Take off TAK Mission Assignment MA
Navigation NAV Enemy Locked-On LO
Navigation/ evasive NAE Target Detected TD
Navigation/ attack NAA Mission Complete- MC
Landing- LAN Enemy evaded EE
Enemy destroyed - ED

Fig FSM for a system in avionics

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

Fig: Statechart depicting insideness


RTCES 2016_GVPCE(A)_unit 1 62
State Charts Contd [22]
- clustering/ abstraction, Refinement of states

(ii) Clustering in State Charts D is an


(i) Basic State Chart Abstraction of A and D - bottom up concept

(ii) Refinement in State Charts D is refined to consist A and C top-down concept

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]

Default state indication is done by a small arrow


One of the most frequent ways of entering a group of states is by the systems history in
that group. The simplest kind of this enter-by-history is entering the state most recently
visited.
It should be noted that an H generally means that history is applied only on the
level in which it appears
History can be made to apply all the way down to the lowest level
of states by attaching an asterisk to the H-entry.

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

Implementation view: This view captures the important components of the


system and their dependencies.

Deployment/ Environmental view: This view models how the different


components are implemented on different pieces of hardware.

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

Das könnte Ihnen auch gefallen