RealTime Systems

1
Real-Time Systems

• We are concerned with a system in which
• a computer controls a device or a process through
  actuators
• a sensor provides readings at periodic intervals
• the computer must respond by sending signals to
  actuators
• the computer may also have to respond to
  unexpected or irregular events

2
Limited Resources

• A responses must be delivered with a time-bound
• If a number of events occur close together, the
  computer needs to schedule the computations
• If this is not possible to achieve, we say that
  the system lacks sufficient resource.
• A system with unlimited resource and capable of
  processing at infinite speed could satisfy any
  time constraints
• If the computer is fast enough, there is no
  real-time problem

3
Consequences of Missing Deadlines

• No effect at all no deadlines needed
• The effects are minor and correctable soft
  deadlines
• The results are catastrophic hard deadlines

4
Example Control a Moving Car

• Consider a car controlled by commands radioed by
  an observer
• The has some has some inertia and a reaction time
• The observer must use a precise model to control
  the car successfully
• Using the information obtained within a time
  frame (n seconds), the observer must send
  commands to adjust the throttle settings and
  break positions, and initiate changes of gear
  when needed

5
Mine Pump and Control System
A Carbon monoxide sensor B Methane sensor C
Airflow sensor D High water sensor E low water
sensor
Pump Controller
Pump
B
C
A
D
E
Sump
6
Real-Time Programs

• A real-time program must
• interact with an environment which has time
  varying properties car, water level
• exhibit predicable time-dependent behavior
• execute on a system with limited resources

7
Hard to Predict the Timing

• A task may take different time under different
  conditions
• Tasks may have dependencies
• More than one processors may be needed in a
  system
• The nature of the application may require
  distributed computing, with nodes connected by
  communication lines.

8
System Development
Application dependent
Requirements
Program Specification
Mathematical Definition
Formal or semi-formal Rules
Program Design
Program Implementation
Programming Language
Hardware System
9
Requirements

• The demands placed on a real-time system is
  called the requirements.
• Requirements are application dependent
• Requirements include functional requirements and
  nonfunctional requirements, such as timing
  properties
• The functional and non-functional requirements
  must be precisely defined and together used to
  construct the specification of the system

10
Specification

• A specification is a mathematical statement of
  the properties to be exhibited by the system
• It states what the system should do within what
  timing bounds
• It does not say how the system does them
• Mathematical description and analysis are
  important in dealing with the complexities of
  real-problems

11
Mine Pump System

• Safety requirements
• The pump must not be operated if the methane
  level is critical
• The mine must be evacuated within one hour of the
  pump failing
• Alarms must be raised if the methane level, the
  carbon monoxide level or the airflow level is
  critical
• Operation requirement
• The mine is operated for three shifts a day
• For not more than one shift in 1000 to be lost
  due to high water level

12
Problem

• Consider the specifications
• The mine must always not violate the safety
  requirements
• The mine must always satisfy both the safety and
  operational requirements
• The mine must not be operated when the safety
  requirements are violated

13
The Goal of RA

• Write and verify a specification for the mine
  pump controller under which it can be shown that
• The mine is operated whenever possible without
  violating the safety and operational
  requirements.
• Safety properties, and Progress property

14
Assumptions

• There are often assumptions without which the
  requirements cannot be met
• what if the methane level can rise arbitrarily
  fast?
• what if the rate of change of the water level is
  unbounded?
• Note that
• the sensors operate by sampling at periodic
  interval
• the computer will take time to perform
  computation to send commands
• the pump will take time to start and stop
• The specification should also clearly state these
  assumptions

15
What but not How

• Under what conditions the mine must be evacuated,
  the pump must start or stop
• But not how and when these and how often these
  should be done, i.e. no information about
• How often the mine must be evacuated
• How normal operation is resumed after an
  evacuation
• These are design or implementation decisions to
  be made to meet the requirements

16
Developing a Specification

• The first step is to describe the requirements as
  properties, using math notation
• The often used math notions and symbols include
• Predicates, logical operators ?? ?? ?? ?, ???
• Mathematical relations and functions, constants,
  variables and intervals
• F T1?T2, VT, b,e, b,e),(b,e, (b,e)

17
Variables in MPS

• Water
• Let Water represent the water level at any time
• Water Time ? Real
• Let WaterIn and WaterOut represent the rates at
  which water enters and leavs the sump
• WaterIn, WaterOut Time ? Real
• The depth of water at time t2 Water(t2) is
• Water(t2) Water(t1)
  (WaterIn(t)-WaterOut(t))dt

18
Water Continued

• HighWater and LowWater represents the high and
  low sensor positions
• LowWaterltHighWaterltDangerWater
• If HighWaterLowWater, then only one sensor is
  needed

19
Methane Level

• The level of methane
• Methane Time ? Real
• DangerMethane represents the critical methane
  level
• The rates at which the methane flows in and out
• MethaneIn, MethaneOut Time ? Real
• For all t1,t2,
• Methane(t2) Methane(t)
• (MethaneIn(t)-Metha
  neOut(t))dt

20
A Mathematical Formulation of the Specification

• Methane(t)??DangerMethane ?? Pumping(t)
• Methane(t)gtDangerMethane ? Alarming(t)
• ?t1,t2. (t2- t1gt60)? ?t?t1,t2.fail(t)
• ?
• ?tlt t160.Empty(t)
• ?t0 t100. ti- ti-11shift.
• ?!i. ?t ?ti-1,
  ti.DangerWater(t)

21
The Specification of the Pump Controller

• When the water is high and methane is low, start
  the pump
• Water(t) gt HightWater ? Methane(t)ltDangerMetha
  ne
• ?
• Pumping(t)
• When methane is dangerous, stop the pump
• Methane(t)gtDangerMethane ?? Pumping(t)

22
Adding Reaction Time

• Water(t) gt HightWater ? Methane(t)ltDangerMethane
• ?
• ?TltR.Pumping(tT)
• Methane(t)gtDangerMethane MethaneMargin
• ?
• ?TltR. ? Pumping(tT)

23
Sensors

• Water(t)gtHighWater ? HW(t)
• Water(t)gtLowWater ? LW(t)
• HW(t)??HW(t)
• Methane(t)gtDangerMethane ? DM(t)
• Methane(t)ltDangerMethane ? ?DM(t)
• Methane(t)gtHighMethane? HM(t)

24
Refining The Controller Specification

• HW(t) ? ?HM(t) ? ?TltR.Pumping(tT)
• HM(t) ? ?TltR. ? Pumping(tT)
• Control Specification
• HW(t) ? ?HM(t) ? PumpOn(t)
• HW(t) ? HM(t) ? PumpOff(t)
• Assume that
• A1 df PumpOn(t) ? TltR.Pumping(tT)
• A2 df PumpOff(t) ? ?TltR. ? Pumping(tT)

25
Assumptions

• A3 df WaterIn is bounded by MaxWaterIn
• A4 df MaxWaterIn lt PumpRate
• A5 df Pumping(t) ?Water(t)gt0
• 
  ?WaterOut(t)gtPumpRate
• A6 df HighWater (?R)MaxWaterIn ltDangerWater
• A7 df HighMethane (?R)MaxMethaneIn
• 
  ltDangerMethane
• A8 df The methane leve does not reach
  DangerMethane more than once in 1000 shifts

26
Validation/Verification

• Prove
• A1 ? ? A8?Control Specification
• ?
• Mathematical Formulation

27
A Model of the Control Program
Off
On
HW??HM
0,R
HM
0,R
From this the program is easy to code
28
V-Diagram Model of Software Development
Requirements analysis and capture
29
An Introduction to Scheduling

• Consider a simple real-time program
• Loop // period T
• Senor_Input.Read(d)
• S // deadline D
• End Loop
• The computation of S must always take less than
  D.

30
Analysing Execution Time

• If S consists solely assignments, accurate
  estimate is possible
• Difficult when S is of the form
• if d 5 then Senor_Output.Write(20)
• elseif dlt10 then Sensor_Output.Write(25)
• else
• Senor_Output.Write()
• Endif
• But still possible compute the
• executing time statically

31
How about

• when S is a loop with a number of paths?
• while xgtdy loop
• end
• The number of iterations depends on the input
  value d
• If the range of d is known, still possible to
  find the total number of iterations.
• Real-time programs analysis is only concerned
  with terminating programs

32
Worst-Case Execution Tim

• In general
• impossible to know in advance exactly how long a
  program execution will take
• may be possible to find the range of possible
  values of the execution time
• analysis uses just the worst-case execution time
  for the program
• assume that the worst-case upper bound to the
  execution time can be computed for any real-time
  program

33
Meeting Deadline

• Real-time system

• Program P
• receives an even an event from a sensor every T
  unit of time
• in the worst case an even requires C units of
  computation time
• assume the deadline D
• C ? D ? T

Computer
Sensor
T
T
C
Time
inputs
34
Multiple Tasks

• If a program receives from two sensors
• every event from the sensors needs C1 or C1

• Assume deadlines are the same as the periods
• Under what conditions will these deadlines be
  met?
• In General, if a program receives from n sensors,
  how can it be determined if the deadline for each
  device will be met?

T1
2 T1
3T1
4 T1
T2
2T2
35
A Simple Model

• A program consists of
• n independent tasks
• invoked periodically by events

• System model
• one processor
• periodically receives external events
• events are not buffered and trigger invocations

invoked? Ti, Ti
Taski
eventi? Ti, Ti
Ready
36
Things can be complicated

• Program may have
• asporadic/aperiodic tasks
• may communicate with each other

• A system may also have more than one processors
• Only consider the simpler model in this section

invoked? Ti,?,
Task
invoked? L,U
Task
37
Static Scheduling

• Assume tasks ?1,?2, ,?n with periods
• T1, , Tn
• Create a fixed scheduling table according to
  which tasks will be despatched for execution at
  run run-time
• scheduled off-line, no overhead
• - no flexibility
• - difficult to cater for sporadic tasks which may
  occur occasionally, if ever, but which has high
  urgency when they do occur

38
Scheduling with Priorities

• The priority of a task represents the the urgency
  or importance of the task
• Represented by an integer
• The urgency is in reverse order to the numeric
  order of the priority, 1 is the highest

39
Priority-Based Execution

• When the processor is idle, the ready task with
  the highest priority is chosen for execution
• Once chosen, a task is run to completion
  non-pre-emptive

40
Pre-emptive Execution

• When the processor is idle, the ready task with
  the highest priority is chosen for execution
• At any time execution of the task can be
  pre-empted of a higher priority becomes ready

41
Example

• priority Period Comp.Time
• ?1 1 7 2
• ?2 2 16 4
• ?3 3 31 7

overrun
42
Remarks

• Sometimes, the priorities allotted tasks can be
  used to solve such problems
• In this case, however, there is no allocation of
  priorities under which ?1 will meet its deadline
• Is there any other way around?

43
Priorities with Pre-Emption
7
14
20
6
16
21
All deadlines are met