EEL 6897 1

Software development for real-time engineering systems

EEL 6897 2

Acknowledgements

• These lecture slides were adopted from the slides of Andy Wellings

EEL 6897 3

Book

RTSJ Version 1.0.1

EEL 6897 4

Prerequisites

• You should already:

– be a competent programmer in an imperative programming language like C, C++, C# etc

– be able to program in sequential Java

– have a good understanding of Operating System Principles, in particular the mechanisms needed to support concurrency, e.g. processes, semaphores, etc

EEL 6897 5

Overall technical aims of the course

• To understand the basic requirements of concurrent and real-time systems

• To be able to create concurrent programs

• To be able to create advanced concurrent real-time systems

EEL 6897 6

Concurrent programming

• The name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronization and communication problems

• Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming

• Concurrent programming is important because it provides an abstract setting in which to study parallelism without getting bogged down in the implementation details

EEL 6897 7

Why we need it

• To fully utilise the processor

10-7

10-6

10-5

10-4

10-3

10-2

10-1

102

101

10-8

10-9

Res

pons

e ti

me

in s

econ

ds

100 human tape

floppy

CD

memory

processor

EEL 6897 8

Parallelism Between CPU and I/O DevicesCPU I/O Device

Initiate I/OOperation Process I/O

Request

Signal Completion

Interrupt I/ORoutine I/O Finished

Continue withOutstanding Requests

EEL 6897 9

Why we need it (cont’d)

• To allow the expression of potential parallelism so that more than one computer can be used to solve the problem

• Consider trying to find the way through a maze

EEL 6897 10

Sequential Maze Search

EEL 6897 11

Concurrent Maze Search

EEL 6897 12

Why we need it (cont’d)

• To model the parallelism in the real world

• Virtually all real-time systems are inherently concurrent — devices operate in parallel in the real world

• This is, perhaps, the main reason to use concurrency

EEL 6897 13

Air Traffic Control

EEL 6897 14

Why we need it

• Alternative: use sequential programming techniques

• The programmer must construct the system as the cyclic execution of a program sequence to handle the various concurrent activities

• This complicates the programmer's task and involves considerations of structures which are irrelevant to the control of the activities in hand

• The resulting programs will be more obscure and inelegant

• Decomposition of the problem is more complex

• Parallel execution of the program on more than one processor is more difficult to achieve

• The placement of code to deal with faults is more problematic

EEL 6897 15

Terminology

• A concurrent program is a collection of autonomous sequential processes, executing (logically) in parallel

• Each process has a single thread of control

• The actual implementation (i.e. execution) of a collection of processes usually takes one of three forms.

Multiprogramming– processes multiplex their executions on a single processor

Multiprocessing– processes multiplex their executions on a multiprocessor system

where there is access to shared memory

Distributed Processing– processes multiplex their executions on several processors which do

not share memory

EEL 6897 16

What is a real-time system?

• A real-time system is any information processing system which has to respond to externally generated input stimuli within a finite and specified period

– the correctness depends not only on the logical result but also the time it was delivered

– failure to respond is as bad as the wrong response!

• The computer is a component in a larger engineering system => EMBEDDED COMPUTER SYSTEM

• 99% of all processors are for the embedded systems market

EEL 6897 17

Terminology• Hard real-time — systems where it is absolutely

imperative that responses occur within the required deadline. E.g. Flight control systems.

• Soft real-time — systems where deadlines are important but which will still function correctly if deadlines are occasionally missed. E.g. Data acquisition system.

• Firm real-time — systems which are soft real-time but in which there is no benefit from late delivery of service.

• A system may have all hard, soft and firm real-time subsystems. Many systems may have a cost function associated with missing each deadline

EEL 6897 18

A simple fluid control system

Pipe

Flow meter

Valve

Interface

ComputerTime

Input flowreading

Processing

Output valveangle

EEL 6897 19

A Grain-Roasting Plant

Fuel Tank

Furnace

Bin

Pipe

fuel

grain

EEL 6897 20

A Process Control System

ProcessControl

Computer

ChemicalsandMaterials

ValveTemperatureTransducer

StirrerFinishedProducts

PLANT

EEL 6897 21

A Production Control System

ProductionControlSystem

Parts

Machine Tools Manipulators Conveyor Belt

FinishedProducts

EEL 6897 22

A Command and Control System

Temperature, Pressure, Power and so on

Terminals

Command and ControlComputer

CommandPost

Sensors/Actuators

EEL 6897 23

A Typical Embedded System

Algorithms forDigital Control

Data Logging

Data Retrievaland Display

OperatorInterface

InterfaceEngineeringSystem

RemoteMonitoring System

Real-TimeClock

Database

Operator’sConsole

Display Devices

Real-Time Computer

EEL 6897 24

Characteristics of a RTS

• Large and complex — vary from a few hundred lines of assembler or C to 20 million lines of Ada estimated for the Space Station

• Concurrent control of separate system components — devices operate in parallel in the real-world; better to model this parallelism by concurrent entities in the program

• Facilities to interact with special purpose hardware — need to be able to program devices in a reliable and abstract way

EEL 6897 25

Characteristics of a RTS

• Extreme reliability and safe — embedded systems typically control the environment in which they operate; failure to control can result in loss of life, damage to environment or economic loss

• Guaranteed response times — we need to be able to predict with confidence the worst case response times for systems; efficiency is important but predictability is essential