Real time Systems Modeling

Presented by CTS

03/10/15

CTS

Real Time Systems Modeling

Task Testing

each task is tested independently

Behavioral Testing
Detects behavioral errors
Inter task testing
uncovers time related errors
System Testing

03/10/15

CTS

Role of Software Design in Real-time

Systems
Life cycle activities
Real-Time systems analysis
Design representations
Design methods

03/10/15

CTS

Real time Design as Life Cycle Activity

Like any software system, real-time systems

should be developed using an appropriate

lifecycle model
Small decisions at a low level of detail can have

a disproportionately large impact at higher

levels of abstraction
Role of prototyping in the life cycle
Role of simulation and analysis in the life cycle

03/10/15

CTS

Real time requirements - Definition

real-time software system is often part of a

larger embedded system.

a systems requirements definition phase will

precede the software requirements definition.

This is where the system's functional

requirements are allocated between the

hardware and software.
Software engineers must be actively involved at

this stage!
03/10/15

CTS

Real time requirements cont.

System is broken down into its constituent

components
Must address issue of concurrent tasks at this

point
Consideration of states and event sequences is

done as well

03/10/15

CTS

Real-time Detailed Design

Algorithmic details of each system task or

component is defined. Special attention to

algorithms for resource sharing, interrupts,
intertask communications, I/O,...

03/10/15

CTS

Real time Testing

Since real-time systems are often embedded

systems, testing or V&V is often more complex

than of other systems. May require hardware
prototypes, simulations, and/or performance
analysis

03/10/15

CTS

Real time system analysis

Models both H/W and S/W system elements
(to derive system timing and sizing information)
Represents control in a probabilistic manner

using:
network analysis
queuing theory
graph theory
03/10/15

CTS

McCabe Analysis Method

Represent transform bubbles as process states in a

Markov chain (A finite state machine with probabilities for each

transition, that is, a probability that the next state is s j given that the
current state is si.)

Represent flows as transitions between process

states
Assign transition probabilities to each path
Each 'bubble' is assigned a *unit cost*
Model is analyzed to compute:

expected number of visits to a process

time spent in the system when processing begins at a specific
process
total time spent in the system

03/10/15

CTS

10

Computation of System Testing

Life cycle activities
utilization
expected queue length
expected number in subsystem
expected time in queue
expected time in system

03/10/15

CTS

11

Design Representations
Many ways to express a design
These are representations, in the same way as

our alphabet is a representation of words, the

way we express the English language. These
representations likewise, express the design.
They are the alphabet of the design.

03/10/15

CTS

12

Data Flow / Control Flow Diagrams

Life cycle activities
Used in Real-Time Structured Analysis
Extensions of DFDs to include control process

and control flow

Control flows represent events and control
Control transformations control execution of

data transformations and are specified by state

transition diagrams or decision tables
03/10/15

CTS

13

State Charts
Extension of finite state machines
Allows concurrent finite state machines to

interact with each other

03/10/15

CTS

14

Real time software Design method

Real-Time S/W design poses unique problems
Representation of interrupts and context

switching
Concurrency through multitasking and

multiprocessing
Intertask communication and synchronization
Wide variations in data and communication

rates
03/10/15

CTS

15

Real time Software Design Methods

Representation of timing constraints
Special requirements for error handling and

fault recovery
Asynchronous processing
Unavoidable coupling with O/S, H/W, and

external devices

03/10/15

CTS

16

Data Flow Oriented Design Method

Most widely used method in the industry
The data flow diagram, data dictionary, and other

notation normally associated with the

methodology do not adequately support real-time
design problems
Design Approach for Real-Time Systems

(DARTS) developed by Hassan Gomaa provides

extensions that allow real-time system designers
to adapt data flow techniques to R-T applications.
03/10/15

CTS

17

Requirements for a Real Time Design

Method
the method must provide:
a mechanism for representing task communication

and synchronization
a notation for representing state dependency
an approach that connects conventional data flow

methods to the real-time world

03/10/15

CTS

18

DARTS
DARTS - Design Approach for Real Time Systems
The DARTS design method can be thought of as

extending the Structured Analysis / Structured

Design method by providing an approach for
structuring the system into tasks as well as a
mechanism for defining the interfaces between tasks.
In this sense, it draws on the experience gained in
concurrent processing. As with other design
methods, DARTS is intended to be iterative.
03/10/15

CTS

19

DARTS cont.
Steps in the DARTS Approach:
Develop Context Diagram
Perform Decomposition
Develop Control Specs
Develop Process Specs
Develop Data Dictionary
Structure Into Concurrent Tasks
Define Task Interfaces
Design Each Task using Structured Design
03/10/15
CTS

20

Structuring into concurrent tasks

Task Grouping Criteria:
Dependency on I/O
Time-critical functions
Computational requirements
Functional cohesion
Temporal cohesion
Periodic execution
03/10/15

CTS

21

Defining the task interfaces

Task Communication Modules (TCM)
Message Communication Modules (MCM)
Loosely coupled
Closely coupled

Information Hiding Modules (IHM)

Task Synchronization Modules (TSM)

03/10/15

CTS

22

Defining the task interfaces cont.

Loosely Coupled Message Communication

Module
Task Communication Modules (TCM)
Message Communication Modules (MCM) --

Loosely coupled--one task needs to pass info to

another and the two tasks may proceed at

different speeds

03/10/15

CTS

23

Defining the task interfaces cont.

Closely Coupled Message Communication

Module
Task Communication Modules (TCM)
Message Communication Modules (MCM) --

Closely coupled--info passed from one task to

another but the first task cannot proceed until it

has received a reply from the second

03/10/15

CTS

24

Defining the task interfaces cont.

Information Hiding Module
Task Communication Modules

(TCM)Information
Hiding Modules (IHM) -- When a data store

needs to be accessed by two or more tasks

03/10/15

CTS

25

Defining the task interfaces cont.

Task Synchronization
Task Synchronization Modules (TSM) -- only a

notification of an event occurrence is required

and no data transfer necessary

03/10/15

CTS

26

Task Design
Structured Design

Design each individual task using structured

analysis techniques
State Dependency in Transaction Processing
Problem: Transaction Centered Design can't
handle state dependency
Solution: Create a State Transition Manager
(STM)
Maintains the current state of the system
Maintains a state transition table defining all
legal and illegal transitions
03/10/15

CTS

27

State Transition Manager

Checks state transition tables for legal states

changes

If legal, changes state

Otherwise, returns negative response

In DARTS, the STM is designed as a TCM (Task

Communication Modules) of the IHM

(Information Hide Modules) type

Maintains a data structure (State Transition Table)

Contains the access procedures that check the validity of task
requests and perform the state transitions
Requests must be mutually exclusive

Example : Air Traffic Controlling system

03/10/15
CTS

28

Air Traffic Control System

Constraints
data acquisition must be conducted at pre-

specified intervals,
analysis must be performed within specified

execution time constraints,

the data base must be updated at defined

intervals
controller interaction should not impede any

other system functions

03/10/15

CTS

29

Other Real Time Design Methods

MASCOT
Hierarchical Software State Machines (HSSM)
Galileo
SADT
SREM
TAGS
SARA
ESPRESSO
03/10/15

CTS

30

Summary
In real-time systems, when is more important

than what
Real-time systems pose special and unique

problems to the designer

Special lifecycle considerations for real-time

systems
Many design notations and methodologies can

be used for real-time systems

03/10/15

CTS

31

Real Time System - Testing

The crucial factor in real-time

applications is time, which offers major

challenges when testing is conducted.
Parallelism of the tasks have to be

considered when designing a test case.

Impact of hardware faults on software

processing must be considered when

testing.
03/10/15

CTS

32

Real-Time Systems - Testing

Steps
Task testing: Each task is tested independently.
Behavioral testing: Detects behavioral errors.

Behavior is simulated using CASE tools.

Inter-task testing: Uncovers time-related errors.

Asynchronous tasks are tested with different

data rates.
System testing: Uncovers HW/SW IF errors.

03/10/15

CTS

33

Testing and Inspection

Testing and inspection are two different

activities
Inspection may overlap with testing at

integration testing

03/10/15

CTS

34

Testing and Metrics

Defect density (number of defects / LOC)
Error density (number of errors / LOC)
Quality index (number of defects in field / total

defects found during development)

03/10/15

CTS

35

Conclusion
Testing never ends, it gets transferred from you

to the customer.
Testing + Inspection = Quality
Testing moves from white box testing towards

black box testing.

Testing begins at the unit level then moves to

integration, validation, and system.

Testing is different from inspection.
03/10/15

CTS

36

Conclusion
Testing never ends, it gets transferred from you to
the customer.
Testing + Inspection = Quality
Testing moves from white box testing towards
black box testing.
Testing begins at the unit level then moves to
integration, validation, and system.
Testing is different from inspection.
03/10/15

CTS

37

Thank You

03/10/15

CTS

38