Real Time Software Engineering CO42018

1
Real Time Software Engineering(CO42018)

• Your lecturer for this module is Dr. Shaun Lawson
  - if you want to get hold of me the best thing is
  to email me at s.lawson_at_napier.ac.uk.
• This module aims to give you an overview of real
  time systems and software engineering issues.
• It will include a large amount of practical work
  based largely on concurrent Java.
• There will be a 2 hour lecture on Mondays from
  2.00-4.00pm in F27, followed by lab sessions on
  Fridays in clusters 9/10 from 12.00-1.00pm in the
  JKCC.
• The web page for the module can be found on the
  School of Computing pages under
  Teaching/Modules/Level-4.

2
Assessment and handouts(CO42018)

• The assessment for the module is based around a
  piece of coursework (worth 30) and a two hour
  written exam (worth 70 of the total mark).
• The coursework will be based around Java.
  Specific instructions for the coursework will be
  handed out soon.
• Each week I will hand out printed versions of my
  lecture presentation plus some occasional further
  reading material.
• There will be links to further online reading on
  the web page each week - it is essential that you
  check this.
• The lab tutorials will not be handed out on paper
  - they are made available online. Do not ask for
  paper versions.

3
Practical Sessions(CO42018)

• All tutorials are provided online as work-through
  exercises with lots of additional web-links and
  notes.
• The tutorials are accessed through the School of
  Computing SOC server from the Module homepage
  (accessed by going to Teaching, then Modules).
• You may work through the tutorials at your own
  speed - either during the time-tabled sessions,
  or in your own time.
• If you want to do the tutorials at home you will
  need a the Java SDK installed. Some later
  tutorials also use a small amount of Visual C.
• I will be present during the time-tabled lab
  sessions to help with any difficulties that you
  might be having with the tutorials.

4
Books and further reading(CO42018)

• There is no single text book that I'll be basing
  the module upon, so I do not suggest that you out
  and buy any expensive text-books.
• Having said this, quite a lot of my notes will
  come from Real-Time Systems and Programming
  Languages by Alan Burns and Andy Wellings, 3rd
  Edition, 2001, published by Addison Wesley (ISBN
  0201729881), UK35.99.
• This is the classic textbook for real time
  systems but deals, largely in Ada which we will
  not look at in detail.
• Note as well that each week I will often direct
  you towards some specialist extra reading for
  that weeks topic - usually this will be online
  material.

5
Objectives of this moduleCO42018

• To introduce you to the basic concepts of why we
  need real time systems, where they are used, and
  how they are implemented.
• To equip you with an in-depth knowledge of how
  real time systems work and how programming them
  may differ from programming conventional computer
  systems.
• To allow you to gain an understanding of the
  current requirements of the real time and
  embedded systems industry and to help equip you
  with the generic skills to become real time
  software engineers.
• Real time and embedded systems engineering is a
  highly sought after skill in graduates.

6
What is a real time system?(CO42018)

• A real time system (RTS) is any information
  processing system which has to respond to
  externally generated input stimuli within a
  finite and specified period.
• The correctness of a RTS depends not only on the
  logical result but also the time it was
  delivered. Failure to respond within the
  specified time period is as bad as a wrong
  result.
• RTSs are invariably part of the real world - and
  deal with critical issues such as finance, safety
  or even life itself.
• They are used in almost every computerised device
  in existence banking systems, motor cars,
  planes, defence systems, kitchen appliances, home
  entertainment systems, medical equipment, even
  embedded in home computers.

7
What are embedded systems (CO42018)

• Real time systems are frequently mixed up with or
  confused with embedded systems.
• An embedded system is a combination of hardware
  and software, and perhaps additional mechanical
  or other parts, designed to perform a specific
  function (contrast this with a general purpose
  computer).
• Example embedded systems include digital set top
  boxes, hard disk controllers, fuel injection
  systems, ABS, VCRs, games consoles, ethernet
  controllers, etc.
• Many embedded systems are also RTSs - but not
  always !
• Many RTSs are embedded - but not always !

This definition the work of Michael Barr (1999)
- see http//www.netrino.com/Books/EmbeddedC/
8
Hard and Soft RTSs(CO42018)

• The issue of what happens if a timing deadline is
  missed is a crucial one.
• If the RTS is part of an airplane flight control
  system it is possible for the lives of the
  passengers to be endangered.
• However if the RTS is part of a TV satellite
  decoding system then all that could happen is a
  corrupt data packet which may or may not affect
  the quality of Neighbours.
• The more severe the consequences of a missed
  deadline the more likely the system will be
  described as a HARD real time system.
• The less severe the more likely the system is
  described as a SOFT real time system.

9
Hard and Soft RTSs(CO42018)

• Hard real time - systems where it is absolutely
  imperative that responses occur within the
  required deadline (eg. flight control systems,
  life support machines).
• Soft real time - systems where deadlines are
  important but which will still function if
  deadlines are occasionally missed (e.g. data
  acquisition system, ATM machines).
• Real real time - systems which are hard real time
  and which the response times are very short (e.g.
  missile guidance systems, ABS braking systems).
• Firm real time - systems which are soft real time
  but in which there is no benefit from late
  delivery of service (e.g. Sony Playstation).

10
Hard and Soft RTSs(CO42018)
system
class
why ?
toast gets burnt pizza gets burned missed
lectures distorted/corrupted audio distorted/corru
pted audio we can cope with a few minutesat an
incorrect temperature we cope with the odd
missing line
toaster cooker clock CD player Telephone central
heating set top box
firm firm hard hard hard soft soft
car fuel injection anti-lock brakes fuel
cut-off air bag life support fly-by-wire
smooth running, efficiency people die people
die people die people die people die
hard hard hard hard hard hard
11
Hard and Soft RTSs(CO42018)

• We have already seen that real time systems are
  very varied in their application
• We have also seen that RTSs are often
  responsible for the safety of human beings.
• Some RTSs we would like to be real real time -
  but in the broad scope of things they do not
  really have to be (such as our toasters, central
  heating systems, Nintendos, etc.)
• The more severe the consequences of a missed
  deadline the more likely the system will be
  described as a hard RTS. The less severe the
  consequences - the more likely the system is
  described as a soft RTS.
• Note the vagueness creeping into these
  definitions!

12
Simplified components of a RTS(CO42018)
Memory
Processor
inputs
outputs
Ill use this diagram (or derivatives of it) time
and time again during this module.
13
RTS Example1 set top box(CO42018)
Memory
encodedsignal fromsatellite dish
decoded analogueTV signal
Processor
DAC
Television
user input
14
Example2 fluid control system(CO42018)
input flow reading
flow meter
pipe
Memory
output valve angle
Processor
valve
fluid flow
15
Example3 process control system(CO42018)
multiple inputs from sensors
flow meter (1) flow meter (2) temp
sensors proximity sensors pressure sensors
Memory
multiple outputs
Processor
valve (1) valve (2) actuators feeders heaters
user interface
output product
16
Alternative RTS system model(CO42018)
Reproduced from Ian Sommervilles book Software
Engineering (1995)
17
Characteristics of RTSs(CO42018)

• RTSs can vary in size from a few lines of
  assembler or C to 20 million lines of Ada
  estimated for the Space Station.
• Concurrent control of components is often
  necessary since devices operate in parallel in
  the real world.
• RTSs usually require the facility to interact
  with special purpose hardware (sensors,
  actuators).
• Extreme reliability and safety is often important
  - RTSs often control the environment in which
  they operate failure to do this correctly can
  result in loss of life, damage to environment, or
  economic loss
• Guaranteed response times are required - we need
  to be able to predict the worst case response
  times - predictability is essential (RTSs must
  be deterministic).

18
Concurrency(CO42018)

• With a RTS parallel interaction with a number of
  separate sub-systems is often necessary since, in
  the real world, devices quite often operate side
  by side.
• A fundamental ability of a RTS therefore is that
  it can cope with running multiple tasks. The
  process of running multiple tasks is called
  concurrency.
• A RTS application may have to deal with
  communications lines, robot arms, disk arrays,
  engine controllers, heat sensors, altitude
  sensors, impact sensors etc. - the RTS must
  service multiple inputs all at once.
• We will now consider the rudimentary use of
  multiple individual tasks and how a RTS can seem
  to be running them all at once.

19
Example RTS - the Mars Rover control system

• The Mars Rover is an example of an autonomous
  vehicle control application - it is a real
  time system.
• The Mars Rover control system has to cope with
  a number of different inputs and outputs - all
  at the same time.

20
Mars Rover control system tasks (CO42018)

• take in the surrounding terrain for path mapping.
• take input from various sensors to tell it if its
  wheels are touching the ground.
• controlling the power being delivered to any and
  all of several different motors.
• sampling the air, temperature and light.
• scooping up little pieces of Mars.
• getting input from the command station back on
  earth.

You can see that some of these tasks are related
to each others (wheel sensors and motor power)
whilst others are completely unrelated
(temperature and motor power).
21
Trying to do everything at once (CO42018)
You can see that the job of the RTS is to provide
a timely response to a set of inputs. There are a
couple of approaches which we could adopt -

• use one process to step through and poll each
  input - this is can also be called the cyclic
  executive approach.
• use a number of processes - i.e. use a separate
  dedicated process for each task and use a
  multi-tasking kernel or Operating System (OS) to
  control this.

We will now examine each of these in more detail.
22
Using the cyclic executive (CO42018)

• The cyclic executive approach simply does
  everything using a never ending while loop.
• Imagine a a RT application where we need to read
  data from a port or two, and in response to that
  input, update a display appropriately and send
  off a couple of outputs - in other words
  consider a video game.
• You could decide to implement this in a big while
  loop -

while (1) / read the joystick port / /
recompute player position / / update the
display /
23
Using the cyclic executive (CO42018)

• The first problem with our while-loop solution is
  setting its cycle speed or frequency - how many
  time per second should it complete a cycle?
• In fact you only need to run the loop fast enough
  to service the input or output with the highest
  frequency.
• For example if the video on our game needs to be
  updated at 30 frames per second but we only need
  to poll the joystick 15 times a second then we
  run the loop at 30Hz - polling the joystick every
  other time the loop is run.
• The problem then is working out how to run the
  loop at exactly that frequency - this can be
  achieved using either interrupts or timers which
  well discuss later.

24
More problems with the cyclic executive

• Determining a higher harmonic frequency can be
  difficult - furthermore if it is too high there
  may not be enough time to get the tasks done in
  one cycle period.
• Imagine trying to calculate the harmonic
  frequency for a system with lots of inputs and
  outputs - for example if our system had multiple
  players each with joysticks, games pads, and
  keyboards - and what if it had audio as well as
  video output ? And what about force feedback ?
  And Internet ?
• Furthermore, the input polling has to be
  non-blocking - i.e. it cant hang the loop - it
  must respond immediately as to whether there is
  an input or not otherwise the entire system
  grounds to a halt.

25
Even more problems with the cyclic executive

• As mentioned, if the cycle time is very high
  there may not be enough time to do the required
  processing of an input in one cycle period - long
  computations of this kind are often typical in
  RTSs such as robot control systems, video
  processing etc.
• This would typically mean that the computation
  has to be broken up across a number of cycles -
  then further polling has to be implemented to see
  if it has finished !
• Finally, imagine now that the games app has to be
  ported to a different embedded system - one that
  runs at a slower clock speed to save on watts and
  money - porting the application as it stands
  would need a lot of fine tuning, testing and
  debugging - it may even be impossible to get it
  working at all !

26
Solution - use multiple tasking!(CO42018)

• The advantage of using multiple processes is
  simplicity.
• Each process is run as a distinct entity,
  separately scheduled by an operating system (OS),
  or kernel.
• You no longer need to manhandle the interactions
  between the various tasks in your big while-loop
  - instead you have a whole series of little
  while-loops each running at its own frequency
  doing what it needs to do for its particular job.
• The solution is more simple to code and is
  therefore more robust. It is also much more
  portable.
• In fact for anything other than very small RTSs
  where portability is important, multitasking is
  the only reasonable solution.

27
Multiple processes(CO42018)

• At any instant in time a CPU is running only one
  program - although it can appear to running
  several at once - this is because it is switching
  between tasks or processes very quickly (and
  hopefully efficiently !).
• A key idea is that a process is an activity of
  some kind - it has a program, an input, an output
  and a state.
• At any one time, a process can be in one of three
  different states -

• running (actually using the CPU at that instant)
• ready (runnable - temporarily stopped by the OS)
• blocked (unable to run until some event happens)

28
Possible process states (CO42018)
Running
2
1
3
Blocked
Ready
4

• running (actually using the CPU at that instant)
• ready (runnable - temporarily stopped by the OS)
• blocked (unable to run until some event happens)

29
Process state transitions(CO42018)

• Four transitional states are possible (see
  diagram).
• Transition 1 occurs when a running process
  discovers it cannot continue - e.g. it must wait
  for external input.The process is then blocked.
• Transitions 2 and 3 are triggered by the process
  scheduler.
• Transition 2 occurs when the scheduler decides
  that it is ready to allow the process some CPU
  time.
• Transition 3 occurs when the scheduler decides
  that a running process has run long enough and it
  is time to let other processes utilise some CPU
  time. The process is then termed ready - it
  would like to run but the scheduler says it has
  to wait.

30
Process state transitions(CO42018)

• Transition 4 occurs when the external event that
  a process was waiting for actually happens.
• If no other process is running at that instant
  then Transition 2 will be triggered and the
  process can start running.
• The subject of scheduling - that is deciding
  which process should run and for how long - is
  complex - many algorithms have been devised to
  try and balance the computing demands so that the
  system as a whole runs efficiently whilst being
  fair to individual processes.
• We will cover scheduling in detail next week.

31
Summary1(CO42018)

• A real time system is an information processing
  system which has to respond to externally
  generated input stimuli within a finite and
  specified period.
• The correctness of a RTS depends not only on the
  logical result but also the time it was
  delivered. Failure to respond within the
  specified time period is as bad as a wrong
  result.
• Two main classes of RTS have been identified
  hard real time systems and soft real time
  systems.
• RTSs are invariably part of a real world
  system - often dealing with critical issues such
  as finance, safety or (at the extreme) life
  itself. RTSs usually interact with special
  purpose hardware (sensors, actuators).

32
Summary2(CO42018)

• With a RTS concurrent interaction with a number
  of separate sub-systems is usually of paramount
  importance.
• A fundamental ability of a RTS therefore is that
  it can cope with running multiple processes - a
  process is run as a distinct entity, usually
  scheduled by an operating system (OS), kernel, or
  executive.
• The advantages of using multiple processes over
  cyclic executives are simplicity and
  portability.
• A single processor may be shared among many
  processes with some scheduling algorithm being
  used to determine when to stop work on one and
  start work on another.
• At any one time, a process can be in one of three
  different states - running, ready or blocked.