1. CHAPTER 3 A Reference Model of Real-Time Systems

2. Typical Real-Time Applications
controller
reference
A/D
control-law
computation
input
D/A
A/D
Sensor
Plant
Actuator
Fig. 1-1 A digital controller
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

3. Typical Real-Time Applications - continued
Do the following in each 1/180-second cycle:
Validate sensor data and select data source; in the presence of failure, reconfigure
the system.
Do the following 30-Hz avionics tasks, each once every six cycles:
- Keyboard input and mode selection
- data normalization and coordinate transformation
- tracking reference update
Do the following 30-Hz computations, each once every six cycles:
- control laws of the outer pitch-control loop
- control laws of the outer roll-control loop
- control laws of the outer yaw- and collective control loop
Do each of the following 90-Hz computations once every two cycles, using outputs
produced by 30-Hz computations and avionics tasks as input:
- control laws of the inner pitch-control loop
- control laws of the inner roll- and collective-control loop
Compute the control laws of the inner yaw-control loop, using outputs produced by
90-Hz control-law computations as input
Output commands.
Carry out built-in-test.
Wait until the beginning of the next cycle.
Fig. 1-3 An example: Software control structure of a flight controller
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

4. Ch.3 A Reference Model of Real-Time Systems
In This Chapter
A reference model of real-time systems
a workload model that describes the applications
a resource model that describes the system resources
algorithms that define how the application system uses the resources
We assume that workload characteristics are given to us a priori before the execution begins
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

5. Processors and Resources
We divide all the system resources into processors and resources
Processors are often called servers and active resources
computers, transmission links, disks, and database server
denoted by
Every job must have one or more processors to execute
Speed is the main attribute of a processor
Resources mean passive resources
memory, sequence numbers, mutexes, and database locks
A job may need some resources in addition to the processor (ex. semaphore)
Each resource may have one or more units
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

6. Temporal Parameters of Real-Time Workload
The workload on processors consists of jobs
job : a unit of work to be allocated processor time and other resources
task : a set of related jobs that execute to support a function of the system
Each job is characterized by
temporal parameter : timing constraints and behavior
functional parameter : intrinsic properties of the job
resource parameter : resource requirement
interconnection parameter : dependency with other jobs
Temporal parameter of a job
release time (or arrival time)
release-time jitter
absolute deadline
relative deadline
execution time or
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

7. Ch.3 A Reference Model of Real-Time Systems
Periodic Task Model
A period task is defined by the following task parameters
period : the minimum length of the interval times of consecutive jobs (i.e., interrelease interval)
execution time : the maximum execution time of all the jobs in
phase : the release time of the first job in
Other definitions
hyperperiod : the least common multiple of for
utilization of task :
total utilization
Deadline is usually assumed to be equal to its period (i.e., )
However, in general, it can be shorter than
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

8. Aperiodic and Sporadic Tasks
A real-time system is invariably required to respond to external events, and to respond, it executes aperiodic or sporadic jobs whose release time is not known a priori.
A task is aperiodic if the jobs in it have either soft deadline or no deadlines
We want to optimize the responsiveness of the system for the aperiodic jobs, but never at the expense of hard real-time tasks whose deadline must be met at all time
Tasks containing jobs that are released at random time instants and have hard deadlines are sporadic tasks
Our primary concern is to ensure that their deadlines are always met; minimizing their response times is of secondary importance
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

9. Precedence Constraints
The jobs are said to have precedence constraints if they are constrained to execute in some order
precedence relation
A job is a predecessor of another job (and is a successor of ) if cannot begin execution until the execution of completes
is an immediate predecessor of (and is an immediate successor of ) if and there is no other job such that
A job with predecessors is ready for execution when the time is at or later its release time and all of its predecessors are completed
precedence graph G=(J,<)
A directed graph to represent the precedence constraints among jobs
each vertex : a job in J
There is an directed edge from to when is an immediate predecessor of
task graph G=(V,E)
An extended precedence graph to describe the application system
(see Fig 3-1)
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

10. Data and Other Dependencies
Data dependency
In many real-time systems, jobs communicate via shared data
Each producer places the data generated by it in a shared address space to be used by the consumer at any time
(ex. navigation job and flight management job)
A parameter of an data dependency edge is the volume of the data
Temporal dependency
Some jobs may be constrained to complete within a certain amount of time interval relative to one another
temporal distance: the difference in the completion times of two jobs
Jobs are said to have a temporal distance constraint if their temporal distance must be no more than some finite value
(ex. display of video frames and the accompanying audio)
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

11. Data and Other Dependencies - continued
AND/OR precedence constraints
AND job : a job with more than one immediate predecessors must wait until all its predecessors have been completed before its execution
OR job : one which can begin execution if one or some its immediate predecessors has been completed
Conditional branches
Conditional execution can be represented by branch and join jobs
(cf. OR constraints versus AND constraints)
Pipeline relationship
There is an edge from to if the output of is piped into and the execution of can proceed as long as there are data for it to process
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

12. Ch.3 A Reference Model of Real-Time Systems
Example of Task Graph
(0, 7]
(2, 9]
(4, 11]
(6,13]
(8,15]
(2, 5]
(5, 8]
(8, 11]
(11, 14]
(14, 17]
(0, 5]
(4, 8]
(5, 20]
Conditional block
branch
join
(0, 6] J
(2, 10]
2/3
1/2
Fig. 3-1 Example of task graphs
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

13. Functional Parameters
Preemptivity of jobs
A job is preemptable if its execution time can be suspended at any time to allow the execution of other jobs and, later on, can be resumed from the point of suspension
A job may be preemptable everywhere except for a small portion which is constrained to be nonpreemptable
(ex.) interrupt handling job (why?)
Context-switch time is the preemption overhead
Criticality of jobs
The importance (or criticality) of a job is a positive number that indicates how critical the job is with respect to other jobs
During an overload when it is not possible to schedule all the jobs to meet their deadlines, it may make sense to sacrifice the less critical jobs so that the more critical jobs can meet their deadlines
(ex.) flight control job > navigation job > cruise control job
weighted average response time or weighted average tardiness
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

14. Functional Parameters - continued
Optional executions
Some jobs or portions of jobs may be indicated as optional
If an optional job or an optional portion of a job completes late or is not executed at all, the system performance may degrade, but nevertheless function satisfactorily
Mandatory jobs (or portions of jobs) must be executed to completion
During a transient overload when it is not possible to complete all the jobs in time, we may choose to discard optional jobs so that the mandatory jobs can complete in time
(ex.) In a collision avoidance system, we may consider the job that computes the correct evasive action and informs the operator optional
While the job that generates a warning and displays the course of the object about to collide with it in time mandatory
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

15. Functional Parameters - continued
Laxity type and laxity function
The laxity type indicates whether its timing constraints are soft or hard
It can be sometimes supplemented by a usefulness function
It gives the usefulness of the result produced by the job as a function of its tardiness
Usefulness functions can guide the choice and implementation of scheduling strategies
Value
1, 2. hard real-time jobs
2. “better never than late”
3. point-of-sales transaction
4. stock price update transaction 3 4
tardiness 1 2
Fig. 3-3 Example of usefulness functions
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

16. Resource Parameters of Jobs
A resource parameter is preemptivity
If jobs can use every unit of a resource in an interleaved fashion, the resource is preemptable
A resource is nonpreemptable, if each unit of the resource is constrained to be used serially
In other words, once a unit of a nonpreemptable resource is allocated to a job, other jobs needing the unit must wait until the job completes its use
(ex.) the lock on a data object in a database
Resource graph
A resource graph describes the configuration of the resources
vertex : processor or (passive) resource
is-a-part-edge
A memory is a part of a computer, and so is a monitor
accessibility edge
If there is a connection between two CPUs in the two computers, then each CPU is accessible from the other computer
A parameter is the cost for sending a unit of data
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

17. Model of Real-Time Systems
Three elements of the model of real-time systems
The application system is represented by a task graph
It gives the processor time and resource requirements of jobs, the timing constraints of each job, and the dependencies of jobs
A resource graph describes the configuration of the resources
It describes the amounts of the resources available to execute the application system, the attributes of the resources, and the rules governing their usage
Between them are the scheduling and resource access-control algorithms used by the operating system
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

18. Model of Real-Time Systems - continued
scheduling and
resource access-control
processors
resources
Fig. 3-4 Model of real-time systems
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

19. Scheduler and Schedules
The scheduler assigns processors to jobs
A schedule means an assignment of all the jobs in the system on the available processors produced by the scheduler
We assume that the scheduler produces only valid schedules:
Every processor is assigned to at most one job at any time
Every job is assigned at most one processor at any time
No job is scheduled before its release time
Depending on the scheduling algorithm(s) used, the total amount of processor time assigned to every job is equal to its maximum or actual execution time
All the precedence and resource usage constraints are satisfied
An implicit assumption is that jobs do not run in parallel on more than one processor to speed up their execution
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

20. Feasibility and Optimality
A valid schedule is feasible if every job completes by its deadline
We say a set of jobs is schedulable according to a scheduling algorithm if when using the algorithm the scheduler always produces a feasible schedule
A hard real-time scheduling algorithm is optimal if the algorithm always produces a feasible schedule if there are feasible schedules
Conversely, if an optimal algorithm fails to find a feasible schedule, the given set of jobs cannot feasibly be scheduled by any algorithm
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems

21. Ch.3 A Reference Model of Real-Time Systems
Performance Measures
Lateness vs. tardiness
The lateness is the difference between completion time and deadline
It can be a negative value (What about tardiness?)
(ex.) packet transmission in a packet-switched network
Makespan
What if when all the jobs have the same release time and deadline?
If the makespan is less than or equal to the length of their feasible interval, the jobs can meet their deadline
Average response time
The most commonly used performance measure for soft real-time jobs
In a system that has a mixture of jobs with hard and soft deadlines, the objective of scheduling is typically to minimize the average response time of soft deadline jobs while ensuring all hard deadline jobs complete in time
Miss rate, loss rate, and invalid rate
miss rate: percentage of jobs that are executed but completed too late
loss rate: percentage of jobs that are not executed at all
invalid rate: miss rate + loss rate
© Cheol-Hoon Lee SSLab, CNU, 2015
Ch.3 A Reference Model of Real-Time Systems