Software development for real-time engineering systems EEL 6897 1

advertisement
Software development for
real-time engineering systems
EEL 6897 1
Acknowledgements
• These lecture slides were adopted from the slides of
Andy Wellings
EEL 6897 2
Book
RTSJ Version 1.0.1
EEL 6897 3
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 4
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 5
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 6
Why we need it
Response time in seconds
• To fully utilise the processor
10
2
1
10
0
10
-1
10
-2
10
-3
10
-4
human
tape
floppy
CD
10
10
10
10
10
10
-5
-6
-7
-8
-9
memory
processor
EEL 6897 7
Parallelism Between CPU and I/O Devices
CPU
I/O Device
Initiate I/O
Operation
Process I/O
Request
Signal Completion
Interrupt I/O
Routine
I/O Finished
Continue with
Outstanding Requests
EEL 6897 8
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 9
Sequential Maze Search
EEL 6897 10
Concurrent Maze Search
EEL 6897 11
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 12
Air Traffic Control
EEL 6897 13
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 14
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 15
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 16
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 17
A simple fluid control system
Interface
Pipe
Input flow
reading
Flow meter
Processing
Output valve
angle
Valve
Time
Computer
EEL 6897 18
A Grain-Roasting Plant
Bin
Furnace
Fuel Tank
grain
Pipe
fuel
EEL 6897 19
A Process Control System
Process
Control
Computer
Valve
Chemicals
and
Materials
Temperature
Transducer
Stirrer
Finished
Products
PLANT
EEL 6897 20
A Production Control System
Production
Control
System
Finished
Products
Parts
Machine Tools
Manipulators
Conveyor Belt
EEL 6897 21
A Command and Control System
Command
Post
Command and Control
Computer
Temperature, Pressure, Power and so on
Terminals
Sensors/Actuators
EEL 6897 22
A Typical Embedded System
Real-Time
Clock
Algorithms for
Digital Control
Engineering
System
Interface
Data Logging
Remote
Monitoring System
Data Retrieval
and Display
Display
Devices
Database
Operator’s
Console
Operator
Interface
Real-Time Computer
EEL 6897 23
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 24
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
EEL 6897 25
Download