2.

Characterizing Real-Time
Systems

2.1 Modeling real-time systems

2.2 Estimating program run times
2.3 Real-time measures
2.4 Real-time kernels
 Review
1. Introduction
1.1 Background
1.2 Real-time applications
1.3 Misconceptions
1.4 Issues in real-time computing
1.5 Structure of a real-time system

Spring 2001 Real-Time Systems (Shin) 2

 2.1 Modeling Real-Time
Systems
 Parameters of real-time tasks
– timing constraints of a task
• computation(execution) time, ci
• deadline
– relative deadline, di
– absolute deadline, Di
• release(arrival) time, ri
• laxity(slack), Li
For periodic tasks
• period, Ti
– hyperperiod, H: LCM of all periods
• phase, Ii
– the release time of the first instance

Spring 2001 Real-Time Systems (Shin) 3

 Parameters of real-time tasks (cont.)

– inter-task constraints/parameters
• preemptivity
• context switch time
• time caused by blocking, Bi
• time caused by preemption
• precedence constraints
• data dependency
• temporal dependency
• criticality of tasks

Spring 2001 Real-Time Systems (Shin) 4

 Performance measures
– reliability, R(t)
– availability, A(t)
– performability, P(L,t)
– response time
– throughput
• nominal capacity, usable capacity
– efficiency
– utilization
– cost/performance ratio
Spring 2001 Real-Time Systems (Shin) 5
 Modeling tools and methods
– natural languages
– mathematical specification
– flowcharts
– structure charts
– pseudo-codes
– finite state machines
– data flow diagrams
– petri net
– statecharts
Spring 2001 Real-Time Systems (Shin) 6
Petri Net

 Basic model
– bipartite graph
– BPN = ( P, T, A )
• P = { p1, p2, …, pn } places
• T = { t1, t2, …, tn } transitions
• A = { P x T } ∪ { T x P } directed arc
– Ai ⊆ P x T, Ao ⊆ T x P

Spring 2001 Real-Time Systems (Shin) 7

 A new job enters
the system
place
A job is
input list. The processor is
idle.

transition

A job is being
directed arc
Job processing
is completed.

A job is on
the output list.
A job leaves Modeling of a simple
the computer system.
Spring 2001 Real-Time Systems (Shin) 8
 Marked Petri Net
– tokens: A place pi has mi tokens.
– PN marking: M = { m1, m2, …, mn }
– model
• PN = ( P, T, A, M0 )
• M0 = { m01, m02, …, m0n } : net initial marking
– Rules
• A transition is enabled when all input places have
at least one token.
• Tokens ‘travel’ to the output places when the
enabled transition fires.
• The firing of a net produces new marking.

Spring 2001 Real-Time Systems (Shin) 9

 – Major characteristics of marked PN
• voluntary: fires only if it is enabled
• instantaneous
• complete: no partial firing
– System state
• a particular marking of the places
• changes through firing of the enable
transitions
• reachability tree

Spring 2001 Real-Time Systems (Shin) 10

 P1

t1

P2 P3

t4 t2 t3

P4 P5

An example of t5
marked PN

Spring 2001 Real-Time Systems (Shin) 11

 M0 = {1,0,0,0,0}
t1
M1 = {0,1,1,0,0}
t2 t3
M2 = {0,0,1,1,0} M3 = {0,1,0,0,1}

t4 t3 t2
M4 = {0,0,0,1,1}
M1
t4 t5
M3 M0

The reachability tree of the marked PN

Spring 2001 Real-Time Systems (Shin) 12
 Modeling of a railroad crossing
Approach
P1

t1 t4
P5

Before P2 P9
Crossing

up
t2 P6 P11

Within t6 t7
P3 t5
P7
P12 down
t3
Crossing
P10
Past
P4 P8
Computer

Spring 2001 Real-Time Systems (Shin) 13

 Timed Petri Net
– timing properties
– examples
• delay added to transitions
• timing constraints assigned to places
– model
• TPN = ( P, T, A, M0, D )
• D : a set of delays associated with transitions

p1 t1, d1 p2

Spring 2001 Real-Time Systems (Shin) 14

Statecharts
 Statecharts
– FSA + depth + orthogonality + broadcast
comm
– depth : represented by ‘insideness’ of states
– orthogonality : by dashed lines separating
states
– broadcast communication : labelled arrows
 Combines the best of data flow and FSA
 Represents concurrency and intertask
comm.
 CASE tool: STATEMATE by i-Logix
Spring 2001 Real-Time Systems (Shin) 15
 dead
bt - in bt - rm/clh
alive bt - dy

main power
weak OK
displays bt - wk
beep - rt
beep
light
t - hits - tm b
[in{enab}] on off

b - up

alarm-st chime-st
a[in{alarm}] c-enab
enab disab t-hits-hr d [in{chime}]

a[in{alarm}] c-beep quiet c-disab

beep-st d [in{chime}]

Statechart: High-level description of the watch

Spring 2001 Real-Time Systems (Shin) 16

 dead
bt-in bt-dy
ali ve bt-rm/clh

main
power

displays
update
t-min
c
min d
date weak
A state chart
b
c c
c
d
bt-wk for the digital
time
hour sec
c
watch
c a ok
date day chime a
c alarm
a
a
c
stopwatch zero c b
d[in{off}] b H up-alarm light
min
disp run hour
reg on
d c off
b c
[in{on}] d b t-min
lap off
H b b-up

on
beep-rt
t-tits-tm
2-min
beep [in{enab}]
[not in{stopwatch}]

alarm-st chime-st
c-enab d[in{chime}]
d[in{alarm}] t-hits-hr
enab disab c-beep quit c-disab
beep-st
d[in{alarm}] d[in{chime}]

Spring 2001 Real-Time Systems (Shin) 17

 2.2 Estimating Execution
Times
 Factors affecting runtime
estimation
– source codes
– compilers
– operating systems
– machine architectures
• # registers
• pipelining
• cache
– input data
Spring 2001 Real-Time Systems (Shin) 18
 Approaches
– measure execution times while running a
program with test data
• test data may not cover all cases possible
• test environment may be different from reality
– estimate by simulating using specification or
modeling languages
• results may not reflect the actual target system
– Predict using source-level timing schema

Spring 2001 Real-Time Systems (Shin) 19

Estimating based on source-level
timing schema
 To predict temporal behavior of
programs written in high-level
languages
 Timing schema
– produces guaranteed best- and worst-case
bounds
– includes control costs and interference

[ Ref: Park, Shaw “Experiments with a program

timing tool based on source-level timing
schema” RTSS’90 ]

Spring 2001 Real-Time Systems (Shin) 20

 Timing tool
– computes estimates of the
best-/worst-case execution times of a
program P
– given bounds of execution times for
• elementary expressions
• control structures
• statements
• procedures
• loops
– runs on a bare machine without OS
Spring 2001 Real-Time Systems (Shin) 21
 Timing schema approach
(1) Decompose a statement S into basic
component called atomic block.
(2) Predict the implementation of each atomic
block. - code prediction
(3) Determine the execution times of the
atomic blocks based on code prediction.
(4) Compute execution time of the statement,
T, using the times of its atomic blocks and
timing schema.
(5) Result: T(S) = [ tmin(S), tmax(S) ]

Spring 2001 Real-Time Systems (Shin) 22

 Timing schema approach - An example
Given S1: a = b + c
(1) decompose into atomic block
T(S1) = T(b) + T(+) + T(c) + T(a) + T(=)
(2) code prediction
b : move M, R /* mov b, d0 */
+ : add M, R /* mov c, d0 */
c, a : none
= : mov R, M /* mov d0, a */
(3), (4) execution time ← T(b) + T(+) + T(=)

Spring 2001 Real-Time Systems (Shin) 23

 Timing schema for control statements
S : if (exp) then S1 else S2
T(S) = [min(t1low, t2low), max(t1up, t2up)]
where
[t1low, t1up] = T(exp) + T(S1) + T(then)
[t2low, t2up] = T(exp) + T(S2) + T(else)
 Timing schema and code prediction for
while statement
S : while (exp) stmt;
T(S) = (N+1) ·T(exp) + N · T(stmt) +
T(while,N)
where N is a pair of loop bounds (i.e., N = [nmin , nmax])

Spring 2001 Real-Time Systems (Shin) 24

 (continued)
Gnu C’s code generation rules:

start_loop L1:
exp exp
S ==> exit_if_false
==> JRF L2
stmt stmt
end_loop JRA L1
L2:
where JRF means “jump_relative if false,”
and JRA means “jump_relative always.”

Spring 2001 Real-Time Systems (Shin) 25

Code prediction:

T(exp) : T(expcode)
T(stmt) : T(stmtcode)
T(while,N) : N · T(JRF, fail) + T(JRF, succ) + N ·
T(JRA)

where expcode and stmt code are predicted codes for

exp and stmt, and JRF, fail is a jump instruction whose
branch is not taken.

Spring 2001 Real-Time Systems (Shin) 26

 Timing tool design
– The timing tool consists of
• preprocessor
• language analyzer
• architecture analyzer
– preprocessor
• interprets user commands
• prepares the working environment for the tool
• converts the internal time scale(clock cycle) into
a real time scale(microseconds)
– architecture analyzer
• maintains instruction execution times for
language analyzer

Spring 2001 Real-Time Systems (Shin) 27

 (continued)
– Language analyzer
Preprocessor

Language analyzer

Parser
Procedure Loop
times bounds
Time schema

Code prediction

Architecture analyzer
Spring 2001 Real-Time Systems (Shin) 28
 An example using the timing tool
struct {
int key;
int value;
} data[15];

binary_search(x)
{
int favalue, mid, up, low ;
[low bound, upper bound]
low = 0 ;
[ 16, 16 ]
up = 14 ;
[ 20, 20 ]
fvalue = -1 / * all data are positive */;
[ 20, 20 ]
Spring 2001 Real-Time Systems (Shin) 29
while (low <= up)
*** WHILE statement ***
Input LOOP-BOUNDS [1, 4]
{
mid = (low + up) >> 1;
[ 52, 52 ]
if ( data[mid].key == x ) { /* found */
up = low - 1;
[ 40, 40 ]
fvalue = data[mid].value;
[ 72, 72 ]
} [ 112, 112 ]
else /* not found */
if (data[mid].key > x ) up = mid - 1; [ 40, 40 ]
else low = mid + 1; [ 40, 40 ]
[ 128, 134 ]
[ 206, 222 ]
}
[ 258, 274 ]
[ 352, 1340 ]

Spring 2001 Real-Time Systems (Shin) 30

return fvalue;
[ 26, 26 ]
}
[ 434, 1422 ]

*** Target procedure( binary_sea )

Cycles = [ 478, 1466 ]
Times = [ 48.62, 149.13 ] (microseconds)

*** Target procedure( binary_sea ) body time

Cycles = [ 434, 1422 ]
Times = [44.15, 144.65 ] (microseconds)

Spring 2001 Real-Time Systems (Shin) 31

 2.3 Real-Time Measures
 Rhealstone metric
– task switching time, tts
– preemption time, tp
– interrupt latency time, til
– semaphore shuffling time, tss
– deadlock breaking time, tdb
– datagram throughput, tdt
– Rhealstone number, R = ∑i(1/ti)

Spring 2001 Real-Time Systems (Shin) 32

 Task
Number
n

t i
Task 3 tTS  i 1
n
Task 2

Task 1

t 1 t 2 t 3 Time

Definition of task switching time

Spring 2001 Real-Time Systems (Shin) 33

 Tasks

Interrupt
Handler

Current
Running
Task

t IL Time

Definition of interrupt latency time

Spring 2001 Real-Time Systems (Shin) 34

 Tasks

Semaphore Task 1 Task 2

Ownership

Task 2

Task 1

t1 t2 t3 t4 t5
Time
Task 1 t SS
requests Task 1
semaphore relinquishes
semaphore
Task 2 has a higher priority. Task 2 Task 2
requests obtains
semaphore semaphore

Definition of semaphore shuffling time

Spring 2001 Real-Time Systems (Shin) 35
 Critical
tDB = ta + tb
Resource
Owner
Task 3
high priority
Task 2
medium priority

Task 1
low priority

t1 t2 t3 t4 t5 t6
tA tB
Task 1
gets a resource Task 1
releases
the resource
Task 3 Task 3
requests gets the
the resource resource

Deadlock breaking timing diagram

Spring 2001 Real-Time Systems (Shin) 36
 TASK 1 Datagram TASK 2

Acknowledgement

Datagram throughput measured in kbytes/sec

Spring 2001 Real-Time Systems (Shin) 37

 Process dispatch latency time
– interrupt response time
• hardware delay
• completion of current instruction
• interrupt latency
– interrupt routine
• preprocessing
• interrupt servicing
• post processing
– software recognition of the need for context
switch
– context switch
Spring 2001 Real-Time Systems (Shin) 38
interrupt response time interrupt routine software
recognition
context
of the need
hard- finish switch
interrupt pre- interrupt post- for context
ware current
latency processing servicing processing switch
delay instr.

High priority interrupt occurs. Real-time task execution

Process dispatch latency time

Spring 2001 Real-Time Systems (Shin) 39

 2.4 Real-Time Kernels
 Characteristics of real-time software
– no virtual memory
– priority-based scheduling
– static resource allocation
– no file system
– usually one application program
– fast interprocess data transmission
– fast context switching and interrupt
processing
– small size

Spring 2001 Real-Time Systems (Shin) 40

 Types of real-time kernels
– polling loop
– cyclic executive, “big loop”
– coroutines
– interrupt-driven system
– foreground/background
– real-time multitasking executive
– real-time operating system

Spring 2001 Real-Time Systems (Shin) 41

 Kernel service
– Basic services
• task management
• intertask communication and synchronization
• interrupt management
• time management
– Additional services
• memory management
• device management
• file management
• fault-tolerant features

Spring 2001 Real-Time Systems (Shin) 42

 Functions of kernel services
– task management
• create/delete
• suspend/resume
• update of priority, preemptibility, etc.
• inquiry of task state, priority, etc.
– intertask communication and
synchronization
• semaphore: wait/signal
• mailbox: send/receive
• queue: enqueue/dequeue
• event flag: pend/post

Spring 2001 Real-Time Systems (Shin) 43

 (continued)
– memory management
• dynamic memory allocation
• memory locking
– device management
• standard character I/O service
• device drivers
– fault-tolerant functions
• hardware fault management routines
• exception processing

Spring 2001 Real-Time Systems (Shin) 44

 Languages
- Fortran
TCP/IP -C
- Pascal
FDDI - Ada
Networking Process
I/O
NFS and
Real-time OS Interfaces
communi- - VME
- Real-time UNIX
cations - Futurebus+
Hardware
architecture
- multiprocessors
- microprocessors Application
- ASICs and VLSI
Databases generators
CASE tools
Man-machine
interface and
graphics
- X Window system
- MOTIF

Model of an open system for real-time applications

Spring 2001 Real-Time Systems (Shin) 45
 Development
environment

Real-time
application
programs

Design Execution
environment environment

Real-time systems software - A perspective

Spring 2001 Real-Time Systems (Shin) 46
 Scheduler and schedules
– terminology
• scheduler: assigns processors to tasks
• schedule: an assignment of all the tasks in the
system on the available processors
– valid schedule
• Every processor is assigned to at most one task at
any time.
• Every task is assigned at most one processor at any
time
• No task is scheduled before its release time
• The total amount of processor time assigned to each
task is equal to its maximum or actual execution
time.
• All the precedence and resource usage constraints
are satisfied.
Spring 2001 Real-Time Systems (Shin) 47
 Scheduler and schedules (cont’d)

– feasible schedule
• definition: a valid schedule by which
every task completes by its deadline
• a set of tasks is schedulable according to
a scheduling algorithm if the scheduler
always produces a feasible schedule
• a hard real-time scheduling algorithm is
optimal if the algorithm always produces
a feasible schedule for a given set of
tasks

Spring 2001 Real-Time Systems (Shin) 48