04/19/23 CTS 1

Real time Systems Modeling

Presented by CTS

04/19/23 CTS 2

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

04/19/23 CTS 3

Role of Software Design in Real-time Systems

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

04/19/23 CTS 4

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

04/19/23 CTS 5

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!

04/19/23 CTS 6

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

04/19/23 CTS 7

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

04/19/23 CTS 8

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

04/19/23 CTS 9

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

04/19/23 CTS 10

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

04/19/23 CTS 11

Computation of System Testing

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

04/19/23 CTS 12

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.

04/19/23 CTS 13

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

04/19/23 CTS 14

State Charts

Extension of finite state machines Allows concurrent finite state machines to

interact with each other

04/19/23 CTS 15

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

04/19/23 CTS 16

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

04/19/23 CTS 17

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.

04/19/23 CTS 18

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

04/19/23 CTS 19

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

04/19/23 CTS 20

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

04/19/23 CTS 21

Structuring into concurrent tasks

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

04/19/23 CTS 22

Defining the task interfaces

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

– Loosely coupled

– Closely coupled

Information Hiding Modules (IHM) Task Synchronization Modules (TSM)

04/19/23 CTS 23

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

04/19/23 CTS 24

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

04/19/23 CTS 25

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

04/19/23 CTS 26

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

04/19/23 CTS 27

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

04/19/23 CTS 28

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

04/19/23 CTS 29

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

04/19/23 CTS 30

Other Real Time Design Methods

MASCOT Hierarchical Software State Machines (HSSM) Galileo SADT SREM TAGS SARA ESPRESSO

04/19/23 CTS 31

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

04/19/23 CTS 32

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.

04/19/23 CTS 33

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.

04/19/23 CTS 34

Testing and Inspection

Testing and inspection are two different activities

Inspection may overlap with testing at integration testing

04/19/23 CTS 35

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)

04/19/23 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.

04/19/23 CTS 37

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.

04/19/23 CTS 38

Thank You