Real Time Systems Design The RTS design is investigated using common component based model 1.

Real Time Systems Design

The RTS design is investigated using common component based model

1

Embedded vs. Real Time Systems

• Real Time System: Correctness of the system depends not only on the logical results, but also on the time in which the results are produced.

• Embedded system: is a computer system that performs a limited set of specific functions. It often interacts with its environment.

EmbeddedSystems

Real TimeSystems

2

Examples• Real Time Embedded:

– Nuclear reactor control– Flight control– Basically any safety critical system– GPS– MP3 player– Mobile phone

• Real Time, but not Embedded:– Stock trading system– Skype– Pandora

• Embedded, but not Real Time:– Home temperature control– Sprinkler system– Washing machine, refrigerator, etc.– Blood pressure meter

3

Characteristics of RTS

• Event-driven, reactive.• High cost of failure.• Concurrency/multiprogramming.• Stand-alone/continuous operation.• Reliability/fault-tolerance requirements.• Predictable behavior.

4

Time

digital clock

tick granule

now

instantinstantpast future

durationevent event

time line

5

Definitions

• 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.

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

6

Control systems

• Man-machine interface: input devices, e.g. keyboard and output devices, e.g. display

• Instrumentation interface: sensors and actuators that transform between physical signals and digital data

• Most control systems are hard real-time• Deadlines are determined by the controlled object, i.e. the temporal

behavior of the physical phenomenon

Operator Controlled Object

Real-Time Computer

System

Man-Machine Interface

Instrumentation Interface

7

Control system example

Example: A simple one-sensor, one-actuator control system.

control-lawcomputation

A/D

A/DD/A

sensor plant actuator

rk

yk

y(t) u(t)

uk

referenceinput r(t)

The systembeing controlled

Outside effects

8

Control systems cont’d.

Pseudo-code for this system:

set timer to interrupt periodically with period T;at each timer interrupt do

do analog-to-digital conversion to get y;compute control output u;output u and do digital-to-analog conversion;

end do

set timer to interrupt periodically with period T;at each timer interrupt do

do analog-to-digital conversion to get y;compute control output u;output u and do digital-to-analog conversion;

end do

T is called the sampling period. T is a key design choice. Typicalrange for T: seconds to milliseconds.

9

10

Taxonomy of Real-Time Systems

11


12


13

Taxonomy: Static

• Task arrival times can be predicted• Static (compile-time) analysis possible• Allows good resource usage (low idle time for

processors).

14

Taxonomy: Dynamic

• Arrival times unpredictable• Static (compile-time) analysis possible only for

simple cases.• Processor utilization decreases dramatically.• In many real systems, this is very difficult to

handle.• Must avoid over-simplifying assumptions

– e.g., assuming that all tasks are independent, when this is unlikely.

15

Taxonomy: Soft Real-Time• Allows more slack in the implementation• Timings may be suboptimal without being

incorrect.• Problem formulation can be much more

complicated than hard real-time• Two common and an uncommon way of handling

non-trivial soft real-time system requirements– Set somewhat loose hard timing constraints– Informal design and testing– Formulate as an optimization problem

16

Taxonomy: Hard Real-Time

• Creates difficult problems.– Some timing constraints are inflexible

• Simplifies problem formulation.

17

Taxonomy: Periodic• Each task (or group of tasks) executes

repeatedly with a particular period.• Allows some static analysis techniques to be

used.• Matches characteristics of many real

problems• It is possible to have tasks with deadlines

smaller, equal to, or greater than their period.– The later are difficult to handle (i.e., multiple

concurrent task instances occur).

18

Periodic

• Single rate:– One period in the system– Simple but inflexible– Used in implementing a lot of wireless sensor

networks.

• Multi rate:– Multiple periods– Should be harmonics to simplify system design

19

Taxonomy: Aperiodic

• Are also called sporadic, asynchronous, or reactive.

• Creates a dynamic situation• Bounded arrival time interval are easier to

handle • Unbounded arrival time intervals are

impossible to handle with resource-constrained systems.

Example: Adaptive Cruise Control• Demo video

• Control system• Hard Real Time• Multi-rate periodic

• Camera• GPS• Low-speed mode for

rush hour traffic

United States Patent 7096109 20

http://www.google.com/url?sa=t&source=web&cd=8&ved=0CDsQtwIwBw&url=http://www.youtube.com/watch?v=CkEipB8lvOA&ei=eXJ2TMDMN4GdlgeY0ZTsCw&usg=AFQjCNFkdAFNyZUd_TAtmfKBXbW0d53-1g

Data Acquisition and Signal-Processing Systems

• Examples:– Video capture.– Digital filtering.– Video and voice compression/decompression.– Radar signal processing.

• Response times range from a few milliseconds to a few seconds.

• Typically simpler than control systems

21

Other Real-Time Applications• Real-time databases.

• Examples: stock market, airline reservations, etc.• Transactions must complete by deadlines.• Main dilemma: Transaction scheduling algorithms and real-time

scheduling algorithms often have conflicting goals.• Data is subject temporal consistency requirements.

• Multimedia.• Want to process audio and video frames at steady rates.

– TV video rate is 30 frames/sec. HDTV is 60 frames/sec.– Telephone audio is 16 Kbits/sec. CD audio is 128 Kbits/sec.

• Other requirements: Lip synchronization, low jitter, low end-to-end response times (if interactive).

22

Are All Systems Real-Time Systems?

• Question: Is a payroll processing system a real-time system?– It has a time constraint: Print the pay checks every two weeks.

• Perhaps it is a real-time system in a definitional sense, but it doesn’t pay us to view it as such.

• We are interested in systems for which it is not a priori obvious how to meet timing constraints.

23

The “Window of Scarcity”

• Resources may be categorized as:

– Abundant: Virtually any system design methodology can be used to realize the timing requirements of the application.

– Insufficient: The application is ahead of the technology curve; no design methodology can be used to realize the timing requirements of the application.

– Sufficient but scarce: It is possible to realize the timing requirements of the application, but careful resource allocation is required.

24

Example: Interactive/Multimedia Applications

sufficientbut scarceresources

abundantresources

insufficientresources

Requirements(performance, scale)

1980 1990 2000Hardware resources in year X

RemoteLogin

NetworkFile Access

High-qualityAudio

InteractiveVideo

The interestingreal-timeapplicationsare here

The interestingreal-timeapplicationsare here

25

OS or not?

Hardware

Operating

System

User Programs

Typical OS Configuration

Hardware

Including Operating

System Components

User Program

Typical Embedded Configuration

26

Foreground/Background Systems• Task-level, interrupt level• Critical operations must

be performed at the interrupt level (not good)

• Response time/timing depends on the entire loop

• Code change affects timing

• Simple, low-cost systems

27

RTS Programming• Because of the need to respond to timing demands made by different stimuli/responses,

the system architecture must allow for fast switching between stimulus handlers.• Because of different priorities, unknown ordering and different timing requirements of

different stimuli, a simple sequential loop is not usually adequate.• Real-time systems are therefore usually designed as cooperating processes with a real-time

kernel controlling these processes.

Concurrent programming

28

Real Time Java?

• Java supports lightweight concurrency (threads and synchronized methods) and can be used for some soft real-time systems.

• Java is not suitable for hard RT programming but real-time versions of Java are now available that address problems such as– Not possible to specify thread execution time;– Uncontrollable garbage collection;– Not possible to access system hardware;– Etc.

– Real-Time Specification for Java– Sun Java Real-Time System

Requires a Real Time OS underneath (e.g., no Windows support)

29

Classification of Scheduling Algorithms

All scheduling algorithms

static scheduling(or offline, or clock driven)

dynamic scheduling(or online, or priority driven)

static-priorityscheduling

dynamic-priorityscheduling

30

Scheduling strategies

• Non pre-emptive scheduling– Once a process has been scheduled for execution, it runs to

completion or until it is blocked for some reason (e.g. waiting for I/O).

• Pre-emptive scheduling– The execution of an executing processes may be stopped if a higher

priority process requires service.

• Scheduling algorithms– Round-robin;– Rate monotonic;– Shortest deadline first;– Etc.

31

Real-time operating systems

• Real-time operating systems are specialised operating systems which manage the processes in the RTS.

• Responsible for process management and resource (processor and memory) allocation.

• Do not normally include facilities such as file management.

14 32

Operating system components

• Real-time clock– Provides information for process scheduling.

• Interrupt handler– Manages aperiodic requests for service.

• Scheduler– Chooses the next process to be run.

• Resource manager– Allocates memory and processor resources.

• Dispatcher– Starts process execution.

33

Interrupt servicing

• Control is transferred automatically to a pre-determined memory location.

• This location contains an instruction to jump to an interrupt service routine.

• Further interrupts are disabled, the interrupt serviced and control returned to the interrupted process.

• Interrupt service routines MUST be short, simple and fast.

34

Metrics for real-time systems differ from that for time-sharing systems.

– schedulability is the ability of tasks to meet all hard deadlines– latency is the worst-case system response time to events– stability in overload means the system meets critical deadlines even if all

deadlines cannot be met

What’s Important in Real-Time

Time-Sharing Systems

Real-Time Systems

Capacity High throughput Schedulability

Responsiveness Fast average response Ensured worst-case response

Overload Fairness Stability

35

Limited ResourcesLimited Resources

Common Component based software engineering (CBSE) technologies (JavaBeans, CORBA and COM) are seldom used as they:

Require excessive processing requirements

Require excessive memory requirements

Provide unpredictable timing characteristics

System Level AnalysisSystem Level Analysis

At system level we analyze to determine if the system composed fulfils the timing requirements.

Several different mature analysis methods exist, for example, analysis for priority-based systems and pre-run-time scheduling techniques

Real-time Component ModelsReal-time Component Models

Using a standard operating system in a real-time application, such as windows NT must be done carefully, as it was designed to be used so.

Application-specific Component Models Application-specific Component Models

Maintain a component library which the application engineer can use when developing an application.

In addition to infrastructure components, domain specific component models, which in fact have been used for many years for certain domains must be considered.

IEC 61131-3 Application Structure IEC 61131-3 Application Structure

Global and direct variables

Access path

Executioncontrol path

Variableaccess path

FBTask

Program Program

FB FB

Task

Program

Task

Program

FB FB

Task

Resource Resource

Configuration

Communication Function

FunctionBlock

Variable

A Configuration in IEC 61131-3A Configuration in IEC 61131-3

Encapsulates all software for an application and consists of one or several resources which provide the computational mechanisms.

A Program in IEC 61131-3A Program in IEC 61131-3

A program is written in any of the languages proposed in the standard, for example:

Instruction lists

Assembly languages

Structured text

A high level language similar to Pascal

Ladder diagrams

Function block diagrams (FBD)

A Port-based Object ApproachA Port-based Object Approach

The model is based upon the development of domain-specific components which maximize usability, flexibility and predictable temporal behavior.

Independent tasks are the bases for the PBO model.

Whenever a PBO needs data for its computation, it reads the most recent information from its in-ports, irrespective of its producer.

The PBOs are in their nature periodic and the system can be analyzed using traditional schedulability analysis.

A Port-based Object A Port-based Object

Port-based objectVariable input ports

Variable output ports

Resource ports for communication with sensors and actuators

Configuration parameters

Designing Component-based RTSDesigning Component-based RTS

System specification

Top-level design

Detailed design

Scheduling / interface check

Obtain components timing behavior on

target platform

System verification Final product

Component library

Create specifications for the new components

Implement and verify new components using classical development

methods

Add new components

to library

Architecture analysis

Top-level Design Top-level Design

The first stage of the development process involves de-composition of the system into manageable components

Detailed Design Detailed Design

At this stage a detailed component design is performed, by selecting components to be used from the candidate set.

Architecture Analysis Architecture Analysis

At this stage it is time to check that the system under development satisfies extra-functional requirements such as:

Maintainability

Reusability

Modifiability

Testability

Scheduling Scheduling

At this point we must check that the temporal requirements of the system can be satisfied, assuming time budgets assigned in the detailed design stage.

In other words, we need to make a schedulability analysis of the system based on the temporal requirements of each component

WCET Verification WCET Verification

Performing a worst-case analysis can either be based on measurements or on a static analysis of the source code.

What is more interesting in the test cases is the execution time behavior shown as a function of input parameters as shown in the following slide.

An Execution Time GraphAn Execution Time Graph

Execution time

Input domain 1 domain 2 domain 3

The execution time shows different values for the different

input sub-domains.

Maximum execution time per sub-domainMaximum execution time per sub-domain

Execution time

Input domain 1 domain 2 domain 3

Implementation of New Components Implementation of New Components

New components; Those not already in the library must be implemented. The designer of the component has two requirements:

The functional requirements

The assigned time budget

System Build and Test System Build and Test

Finally, we build the system using old and new components.

We must now verify the functional and temporal properties of the system obtained.

If the verification test fails, we must return to the relevant stage of the development process and correct the error.

Component Library Component Library

Is the most central part of any CBSE system as it contains binaries of components and their descriptions.

A component library containing real-time components should provide the following:

Memory requirements

Worst cast execution time (WCET) test cases

Dependencies

Environment assumptions

Composition of ComponentsComposition of Components

Component 1

(C1)

Component 2

(C3)

Component n

(C2)

in1_Cnew

in2_Cnew

in3_Cnew

in4_Cnew

in_C1

in2_Cn

in1_C2

in2_C2

out_C1

out_C2

out1_Cn

out2_Cn

out1_Cnew

out2_Cnew

out3_Cnew

New Component (Cnew)

End-To-End DeadlinesEnd-To-End Deadlines

End-to-end deadlines

Are set such that the system requirements are fulfilled in the same way as the time budgets are set

Should be specified for the input to and output from the component since the WCET cannot be computed since its parts may be executing with different periods.

Specification Of Timing Attributes Specification Of Timing Attributes

We specify virtual timing attributes of the composed component, which are used to compute the timing attributes of sub-components, ie:

IF virtual period is set to P,

THEN the period of a sub-component A should be fA * P

AND the period of B is fB * P,

WHERE fA and fB are constants for the composed component, which are stored in the component library

RT Components in Rubus OSRT Components in Rubus OS

Rubus:

Is one of a few real-time operating systems currently available which have some concept of components.

Is a hybrid operating system, in the sense that it supports both pre-emptive static scheduling and fixed priority scheduling.

A Task and Its InterfacesA Task and Its Interfaces

The timing requirements are specified by release-time, deadline, WCET and period

Task: BrakeLeftRight Period: 50 ms Release time: 10 ms Deadline: 30 ms Precedes: outputBrakeValues WCET: 2 ms

oil pressure

speed

….

brake left wheel

brake right wheel

Task state information

A Composed System in the Red Model of RubusA Composed System in the Red Model of Rubus

The task depicted below is required to execute before the outputBrakeValues task, (i.E. Task BrakeLeftRight precedes task outputBrakeValues).

Component: BrakeLeftRight

oil pressure

speed

brake left wheel

brake right wheel

State information

input 1

input 2

Component:

OutputBrakeValues

State information

Composition of Components in Rubus Composition of Components in Rubus

Task:BrakeLeftRight

oilpressure

speed

brake left

brake right


Task:OutputBrakeValues


Component: BrakeSystem

pressure

speed

An embedded realtime application using Rubus An embedded realtime application using Rubus

(CBSE) model in the design development(CBSE) model in the design development

Conclusion

• The Rubus component model (CBSE) provides:– Methods to express the infrastructure of software

functions, i.e., the interaction between software functions in terms of data-flow and control-flow

– The resulting architecture is formal enough for analysis of timing and memory properties

– The components and the infrastructure allow for a resource efficient mapping onto a run-time structure

64

Real Time Systems Design The RTS design is investigated using common component based model 1.

Documents

Transcript of Real Time Systems Design The RTS design is investigated using common component based model 1.