1

ECNG6600-- Real-Time Systems

Slides from Real-Time Systems: Ada 95, Real-Time Java and Real-Time POSIX by Burns and Wellings
www.cs.york.ac.uk/rts/RTSBookThirdEdition.html

Alan Burns and Andy Wellings, 2001

Prerequisites
Basic understanding of Assembly Language and C Basic understanding of Computer Architectures.
CISC RISC

Basic understanding of Operating Systems

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

Overall Technical Aims of the Course

To understand the basic requirements of real-time systems and how these requirements have influenced
the design of real-time programming languages and real-time operating systems the design of microprocessor systems for real time embedded control systems

To understand the implementation and analysis techniques which enable the requirements to be realised.

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

What is a real-time system (RTS)?

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
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

Real-Time Languages and OSs

User Programs Operating

User Program Including Operating

Hardware

Hardware

System

System Components

Typical OS Configuration

Typical Embedded Configuration

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

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. Real real-time systems which are hard real-time and which the response times are very short. E.g. Missile guidance system. Firm real-time systems which are soft real-time but in which there is no benefit from late delivery of service.

A single system may have all hard, soft and real real-time subsystems. In reality many systems will have a cost function associated with missing each deadline
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

A simple fluid control system

Interface Pipe

Input flow reading

Flow meter

Processing

Output valve angle Time Computer

Valve

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

A Widget-Packing Station

Switch Computer

Switch Assembly line

Bell Line controller 0 = stop 1 = run

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

Box

A Command and Control System

Command Post

Command and Control Computer

Temperature, Pressure, Power and so on Terminals Sensors/Actuators

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

10

A Typical Embedded System

Real-Time Clock Algorithms for Digital Control Interface Engineering System

Data Logging

Remote Monitoring System

Database Data Retrieval and Display Display Devices

Operators Console

Operator Interface

Real-Time Computer
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

11

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 Freedom 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

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

12

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

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

13

Summary
Two main classes of such systems have been identified:
hard real-time systems soft real-time systems

The basic characteristics of a real-time or embedded computer system are:

largeness and complexity, extreme reliability and safety, concurrent control of separate system components, real-time control, interaction with hardware interfaces, efficient implementation.

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

14

Characteristics of Real-Time Systems

Large and Complex Concurrent control of system components Facilities for hardware control Extremely reliable and safe Real-time facilities Efficiency of execution

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

15

Decomposition and Abstraction

Decomposition the systematic breakdown of a complex system into smaller and smaller parts until components are isolated that can be understood and engineered by individuals and small groups TOP DOWN DESIGN Abstraction Allows detailed consideration of components to be postponed yet enables the essential part of the component to be specified BOTTOM UP DESIGN

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

16

Modules
A collection of logically related objects and operations Encapsulation the technique of isolating a system function within a module with a precise specification of the interface
information hiding separate compilation abstract data types

How should large systems be decomposed into modules? The answer to this is at the heart of all Software Engineering!

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

17

Information Hiding
A module structure supports reduced visibility by allowing information to be hidden inside its body The specification and body of a module can be given separately Ideally, the specification should be compilable without the body being written

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

18

Abstract data types

A module can define both a type and the operations on the type. The details of the type must be hidden from the user. As modules are not first class, the type must be declared and instances of the type passed as a parameter to the operation. To ensure the user is not aware of the details of the type, it is either defined to be private (as in C++) or always passed as a pointer (as you would do in C). An incomplete declaration of the type is given in the .h file.
Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

19

Object-Oriented Programming (OOP)

OOP has:
type extensibility (inheritance) automatic object initialisation (constructors) automatic object finalisation (destructors) run-time dispatching of operations (polymorphism)

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.

20

Summary
Module supports: information hiding, separate compilation and abstract data types Separate compilation enables libraries of precompiled components to be constructed The decomposition of a large program into modules is the essence of programming in the large The use of abstract data types or object-oriented programming, provides one of the main tools programmers can use to manage large software systems

Original Slides Alan Burns and Andy Wellings, 2001 Modified - CLR-Jan 2002, Sep 2005.