design for real time systems

8/9/2019 Design for Real Time Systems

1/30

1

DESIGN FOR REAL-TIME SYSTEMS

Real-time Systems - Systems in

which the correctness of the programdepends upon the time are which theresults are delivered as well as thevalues calculated.


2/30

December 25, 1997 Assistance - Yaru Liu 2

Outline

The introduction to real-time system Some key issues that differentiate the real-time

systems from other types of computer software

Analysis and simulation of real-time

systemsDesign for real-time systems


3/30


Real-time System OverviewReal-time software is highly coupled to theexternal world

Perform high-speed data acquisition andcontrol under severe time and reliabilityconstrainsTime is the most important issue in real-

time systemFast and real-time are not the same Real-time is predictability and meeting

deadlines, not necessarily fast.


4/30


System Considerations

Some differences between real-time software

development and other software engineeringeffort:

The design of a real-time system is resourceconstrainedReal-time systems are compact, yet complexReal-time systems often work without the

presence of a human user


5/30


Performance IssuesEach real-time design concern for softwaremust be applied in the context of system

performance

Coordination between the real-time tasksSynchronizationShared resources, e.g., memory, cpu

Processing of system interrupts I/O handling to ensure that no data are lost Specifying the systems internal and external

timing constraints Scheduling of tasks to guarantee meeting

deadlines


6/30


Performance IssuesThe performance of a real-time system isdetermined primarily by the systemresponse time and its data transfer rate System response time is the time within which a

system must detect an internal or external eventand respond with an action

The data transfer rate indicates how fast serialor parallel data, as well as analog or digitaldata, must be moved into or out of the system

Fu ndamental q u estion Does it meet all deadlines or not?


7/30


Performance Issues

Key parameters that affect the system

response time Context switching

the time and overhead to switch among tasks

Interrupt latency

the time lag before the switch is actually possible Speed of computation Speed of access to mass storage


8/30

December 25, 1997 Assistance - Yaru Liu

Interrupt handling

Software Interrupt handlingSave state of interrupted program

Determine nature of the interrupt

Service interruptRestore state of interrupted program

Return to interrupted program

Normal processing

flow

Interruptis posted


9/30


Nested Interrupt Handling


10/30


Real-time Date Bases

Distributed databases Multitasking is the commonplace and data are

often processed in parallel A failure of one database need not cause failure

of the entire system, if redundancy is build in Concurrency control problem. It involves

synchronizing the databases so that all copieshave the correct, identical information

Use of time stamps and locking.


11/30


Real-time operating systemsTwo broad classes of OS are used for RT work RTOS designed exclusively for RT applications General-purpose OS enhanced to provide RT RTOS

Beware false claims -- checkout capabilitiesMust provide non-blocking I/OMust provide a priority mechanism For interrupts For executing tasksRTOS must have a memory locking mechanismMust provide timing control mechanisms Time resolution should be 1 ms. or less.


12/30


Real-Time Operating Systems

Must provide memory sharing threads

Must provide efficient tasking (context)switchingShould provide synchronization mechanism

Advanced RTOS may provide task scheduling


13/30


Real-time languagesSome differences between a real-time languageand a general-purpose language Multitasking capability Constructs to directly implement real-time functions

timing managementtask scheduling

Features to help achieve program correctnesspackage structures -- enable information hidingstructured mutual exclusion -- monitor functionsstructured synchronization -- task rendezvoustype attributes -- e.g., range(A) for array A


14/30


Task Synchronization and

CommunicationThree general approaches Queuing semaphores

manage several queues Mailboxes

buffers which store message or message pointer sentfrom one process to another

Message systemsone process sends a message to another

Advanced concepts Tasking Rendezvous Monitors


15/30


Analysis and simulation of real-time systems

Tools for real-time system analysis Statistical Hard real-time guarantees

Simulation and modeling tools

Analyze a systems performance Build a prototype, execute it, and thereby get an

understanding of a systems behavior


16/30


Mathematical tools for real-timesystem analysis

DFD-like model Assign transitional probabilities between the

process states to each flow path Add to the process a unit cost that represents

the estimated ( or actual ) execution timerequired to perform its function

Add to the process an entrance value thatdepicts the number of system interrupts (or execution requests) corresponding to it


17/30


Mathematical tools for real-time

system analysis

Informationsource

2

3

1P in

Dataarrival rate

Unit cost = 4 .6

P12 = 0. 6

P13 = 0. 4

Compute:The expected number of visits to a processThe time spent in the system when processing begins at a specific processThe total time spent in the system


18/30


DFD for Real-Time


19/30


Queuing Model


20/30

December 25, 1997 Assistance - Yaru Liu 2 0

Queuing Reduction Rules


21/30


Simplifying Networks


22/30



The conceptual view

Functional view is captured with activity-charts, which are similar to conventional DFD Dynamic view uses state-charts ( similar to

CFD). Transitions between states are typically

triggered by events Integration: each level of an activity-chart,

there will usually be a state-chart


23/30


Example


24/30


Statechart for Example


25/30



The physical view The conceptual model is the foundation, but not

a real system Decompose a system into subsystem,component, sub-component

Relation to conceptual model

Analysis and simulation Statecharts syntactically correct

complete - no obviously missing label, namesconsistency - e.g., correctness of I/O


26/30



Running scenarios

Correctness of function or behavior Engineer can play role of user & enter tests

Programming simulations Simulation control language (SCL)

Automatic translation of activity andstatecharts into code


27/30


Real-time designIncorporate all of the fundamental concepts

and principles associated with high-qualitysoftwareA set of unique problems Representation of interrupts and context

switching Concurrency as manifested by multitasking andmultiprocessing

Inter-task communication and synchronization


28/30


Real-time design (contd) Wide variations in data and communication

rates

Resource management of shared resources Representation of timing constraints Need for scheduling Asynchronous processing

Necessary and unavoidable coupling withoperating systems, hardware, and other externalsystem elements

High reliability (usually)


29/30


Real-time designA number of modeling principles

Explicit atomicity Interleaving Nonterminating histories and fairness Closed system principle - include environment

with computer system in analysis Structuring state by objects Sometimes, physically measure task times


30/30


SummaryThe design of real-time software =all aspects of conventional software design

+ a new set of design criteria and concernsReal-time software must respond to real-world events in a time frame dictated bythose eventsClock or event drivenCan be very difficult to design and evenmore difficult to test, verify and validate

design for real time systems

Documents