Embeded System Software Issues

7/28/2019 Embeded System Software Issues

1/49

1

Embedded Systems:

Software Issues

Nidhi MajumderInternational Institute of Information Technology

Kolkata 700 091


2/49

2

Outline of the Talk

Scheduling MechanismsThey are the

ones that distinguish between a real-time

system and a general-purpose system

Language IssuesIt is the language,

which in conjunction with the hardware

gives the support to the system designerwhat he or she wants to achieve


3/49

3

Scheduling Algorithms

Uniprocessor Scheduling Algorithms

Multiprocessor Scheduling Algorithms


4/49

4

Uniprocessor Scheduling

Rate Monotonic (RM) Algorithm

Rate Monotonic Deferred Server (DS)

Algorithm

Earliest Deadline First (EDF) Algorithm

Algorithms with Precedence and Exclusion

Conditions

Algorithms for Multiple Task Versions


5/49

5

Assumptions for Classical

Uniprocessor SchedulingAlgorithms (RM and EDF) All tasks are fully preemptable and the

cost of preemption is negligible Only processing requirements are

significant, all other resource

requirements are negligible

All tasks are independent, i.e. there are no

precedence constraints


6/49

6

Rate-Monotonic (RM) Scheduling

Algorithm Static-priority preemptive scheme

Further assumptions

All tasks in the task set are periodicThe relative deadline of a task is equal to its

period

Last assumption simplifies the wholeanalysis, ensures that there can be at mostone iteration of any task alive at any time


7/49

7

Notations Used

n number of tasks

eiexecution time of task Ti

Piperiod of task Ti

Iiphasing of task Ti, so kth period of task Ti

begins at time Ii + (k1) Pi

direlative deadline of task Ti Diabsolute deadline of task Ti

Rirelease time of task Ti


8/49

8

A Typical Example of RM

3 tasks with P1 = 2, P2 = 6 and P3 = 10

e1= 0.5, e2 = 2, e3 =1.5

I1 = 0, I2 = 1, I3 = 3

P1 < P2 < P3 => T1 has highest priority,

followed by T2, followed by T3

0 1 2 3 4 5 6 7 8

11 21 12 21 31 13 31 14 22


9/49

9

Test for Schedulability

If the total utilization ofn tasks is no greater

than n (2 1/n -1), then the RM algorithmwill be able schedule all the tasks to meet

their respective deadlines

This is sufficient but not a necessary

condition


10/49

10

Necessary and Sufficient

Condition for RM Schedulability Assume that in our earlier example the task phases were all

zero, I1 = I2 = I3 = 0

As T1 has highest priority, the necessary and sufficient

condition for it to be feasibly scheduled is that e1


11/49

11

Necessary and Sufficient

Condition (contd.) Finally for T3

t =t / P1e1 +t / P2e2 + e3

Check at finite points where t is a multiple

of P1 and/orP2


12/49

12

Conditions for General Case

Wi(t) =j = 1 to it / Pjej

Note that for 0 < t


13/49

13

Sporadic Task Handling

Tasks released irregularly, often in responseto save special event in the operatingenvironment.

There must exist a maximum rate at whichthey can be released

Some minimum inter-arrival time betweenthe release of successive iteration of sporadictasks exists

Approach - Consider as periodic task with aperiod equal to the minimum inter-arrival time


14/49

14

Simple Approach Define a fictitious periodic task of highest

priority and of some chosen fictitiousexecution period

During the time of this task, processor runs

any sporadic tasks awaiting service Outside this interval, processor attends

periodic tasks

However if during those intervals, no sporadic

tasks are waiting then processorremainsidle

0 1 2 3 4 5 6 7 8


15/49

15

Deferred Server Approach Whenever the processor is scheduled to

run sporadic tasks, and no task iswaiting, it executes other periodic tasks

in order of priority However if sporadic tasks arrives, it

preempts the other tasks and canoccupy a total time up to the time

allotted for sporadic tasks

0 1 2 3 4 5 6 7 8


16/49

16

Schedulability Criteria for DS

Approach Assumption Relative deadlines of all tasks equalto their periods

Let Us be the processor utilization allocated to the

sporadic tasks and U be the total utilization(sporadic + periodic), then the sufficiency (not

necessary) condition is

U 1 Us if Us 0.5Us if Us 0.5

0 1 2 3 4 5 6 7 8


17/49

17

Preemptive Earliest Deadline First

(EDF) Algorithms Processor executes that task whose absolute

deadline is the earliest

Dynamic priority scheduling algorithm

Also called deadline-monotonic scheduling

algorithm

Optimal algorithm for uniprocessor

scheduling


18/49

18

A Typical Example Consider the following aperiodic tasks

Task Arrival Time Execution Time Absolute Deadline

1 0 10 30

2 4 3 10

3 5 10 25

T1 starts immediately

T2 arrives at 4, as d2 < d1, it preempts T1 T3 arrives at 5, as d3 > d2, lower priority than T2, so waits

When T2 finishes at 7, T3 has higher priority than T1, itruns till 17 and then finally T1 picks up


19/49

19

Schedulability Test for EDF

If all the tasks are periodic, we have relativedeadlines equal to their periods, the task setcan be scheduled if the total utilization is

no greater than 1

However if the relative deadlines is notequal to the periods, then the expression is a

bit complex Approach - Develop a schedule according

to EDF to see if deadlines are met


20/49


21/49

21

Multiple Task Versions System has primary and alternative versions ofsome particular task

Versions vary in execution time and quality ofoutput

IRIS taskIncreased Reward with IncreasedService

Examples Calculation ofe or

SeveralVariations Identical Linear Reward Function,

Non-identical Linear Reward Function,

0-1 Reward Function,

Identical Concave Reward Function,

Non-identical Concave Linear Function


22/49

22

Multiprocessor Scheduling Optimal assignment to multiple processors in all

practical cases turn out to be NP-complete

So must use heuristics

Schedule following some simple criteria and then

expect to be lucky enough to get a feasibleschedule

If not feasible, modify the allocation and check

eg. For periodic tasks with relative deadline equal

to their periods try to maintain autilization < n (2 1/n -1)

Communication costs need to be taken care offor multiprocessors


23/49

23

Multiprocessor Scheduling

Heuristics Utilization Balancing Algorithm

Next-fit Algorithm

Bin-packing Algorithm

Myopic offline scheduling Algorithm

Focused Addressing and Bidding Algortihm

Buddy Strategy

Assignment with Precedence Constraints


24/49

24

References

Coffman, E. G., Computer and Job-shopScheduling Theory, Wiley, 1976

Liu C. L. and Layland J. W., SchedulingAlgorithms for Multiprogramming in aHard-real-time Environment, JACM, 20(1),46-61, 1973

Krishna C. M., Shin K. G., Real-timeSystems, McGraw-Hill Int. Editions, 1997


25/49

25

Language issues

What is a good real-time programminglanguage?

It enables the programmer to give directions to

the computer with low probability of error It increases the clarity of thought in the

domain for which it is targeted

Finally improves the quality of the resulting

software

Ada9x turned out to be so


26/49


27/49

27

Additional Demands for Real-time

Applications Deadlines should be met

Programmers should be able to specify

priorities or run-time requirementsProgrammers must also have a way to specify

absolute time intervals

Interfaces to devices like sensors, actuatorsshould be easy to write


28/49

28

Portability Issues

Programmer should have the option of

specifying minimum acceptable precision of

each variable irrespective of the host m/c Compilers should follow some uniform

code of conduct 2 solutions

Language specs without any ambiguitiesCentral committee to resolve ambiguities (Ada

has one)


29/49

29

Complexity affects Portability

To make things portable one might want everyfeature in every implementation must exist inevery other implementation

Two problems can come up

Language may become trivial with few features

To satisfy a wide spectra of users the language isoverloaded with features

Solution in Ada Has a core set of features withseveral annexes, if a compiler writer supports anannex X, he has to support it fully


30/49

30

Real-time systems have to deal with a larger

variety of devices compared to the general-

purpose computers Compromise

Keep a distinction between the machine-dependent and

machine-independent parts of the program

To handle devices, language should support theprogrammer to specify absolute addresses and also

to insert assembly language code fragments

There is a limit to Portability


31/49

31

Control over Scheduling

A real-time language should give a programmer

more power or flexibility to schedule a particular

task in orderto meet hard deadlines Programs should be better analyzable for

schedulability

Some features of present day languages are not

recommended for use like variable-sized arrays(allocation issues) or recursion which give timing

analysis a hard time


32/49

32

Need for an Accurate Clock

Hardware level need a stable quartz clock with

reliable synchronization methods

Language level granularity of the clock shouldbe sufficiently fine to take care of all practical

situations eg. Ada9x allows 1 s

Keep everyday clocks separate from real-time

clocks

The former is sometimes frozen for a few seconds or

adjusted when time zones are crossed


33/49

33

Strong Data Typing Each variable must be explicitly declared to have

a particular data type

Each data type has exclusive set of values and aset of operations associated with it

Implicit type conversions not allowed Explicit type conversions allowed

Ada supports subtypes with specific ranges subtype FirstHalf is TIME range 10.00..13.00

subtype SecondHalf is TIME range 14.00..17.00

Fixed-point type programmer specifies accuracy type FRAC is delta 0.001 range 0.111..0.999


34/49

34

In Support of Hierarchy

Blocks Information Hiding

Procedures and Functions

Packages Specification + Body

Written, debugged and compiled separately

Placed in a library for others use

Improved security

Maintenance more efficient plug and chuckwith ROOTS; use ROOTS


35/49


36/49

36

Predefined Exception

Conditions CONSTRAINT_ERRORvariable goes outside

the prescribed bounds

NUMERIC_ERROR inability to maintain

adequate precision (Divide by zero) STORAGE_ERRORout of memory space

PROGRAM_ERRORasserted when anexception occurs that is not captured by any other

conditions TASKING_ERRORerrors that arise due to

incorrect use of tasking mechanism


37/49

37

A Typical Exampledeclare

TEMPERATURE: float;

TOO_HOT, TOO_COLD: exception;

begin

loop

READ_TEMEPERATURE(TEMEPERATURE);

if TEMPERATURE < 400raise TOO_COLD;

elseif TEMPERATURE > 450

raise TOO_HOT;

end if;

end loop;

exception

when TOO_COLD =>put(Warning: Too Cold);

when TOO_HOT =>

put(Warning: Too Hot);

end;


38/49

38

Anonymous Exceptions

If procedure B calls procedure C and C hasa declared exception XX with no handling

routine, then if such an exception is raisedcontrol is returned to B

B knows that an exception is raised but hasno way to recognize it as not declared in B

We say XX is anonymous in B and may becaught using a catchall clause when others


39/49

39

Multitasking

As real-time computers often use parallel processors, real-time languages should support concurrency

procedure XYZ istask X;

task body X is

-- task body

end X;

task Y;

task body Y is

-- task bodyend Y;

begin-- procedure body

end XYZ;


40/49

40

Tasks (continued)

Tasks can have rendezvous points, where they

wait if reached earlier

Tasks can have different priority levels. The

pragma (compiler directive) PRIORITY can besued to define a static priority level

Ada9X real-time annex requires every system to

support at least 31 distinct priority classes, actualnumber being implementation dependent


41/49

41

Task Scheduling Two common scheduling mechanism supported

are FIFO and changing static priority usingpragma PRIORITY

However real-time systems much advanced

support to implement algorithms like RateMonotone scheduling and earliest deadline firstscheduling

Real-time annex offers some assistance to theprogrammers in the form of Task Dispatching policy

Entry Queuing Policy


42/49


43/49

43

Requirements (contd.)

Specify how soon a message is to be received after it issent

Specify how soon a message must be processed after

receipt by the receiving task Specify the periodic scheduling of task

Specify for each loop the maximum time allowed forprocessing that loop

Specify upper bounds on the size of any dynamic datastructures, thus specifying a bound on the time required topass them between procedures, or to allocate anddeallocate storage


44/49

44

Experimental Languages

Flex developed by Univ. of Illinois

2 distinct characteristics

Powerful constraint specificationsAbility to select one from multiple algorithms

Can run imprecise computations also simply

by specifying when the computation mustterminate

A derivative of C++ with a preprocessor


45/49

45

Experimental Languages

(contd.) Euclid developed at University of Toronto

Remarkable feature specifically designed toallow for reasonably accurate estimates of worst-

case program run times Dynamic data structures not allowed escape

route is each system implementation allows amaximal size for each data structure

Recursion not allowed No while loops instead use for loops or time-

bounded loops


46/49

46

Programming Support

Environment (PSE) A good PSE is a must for good software

The PSE for Ada is given by Stonemanspecifications

It suggests a layered approach for building PSE Rationale is to maximize portability by making the

support environment as independent of theunderlying hardware and kernel as possible

PSE is very complex and expensive, so notpossible to write for every new machine, henceportability is a must


47/49

47

Layered Programming Support

Environment

hardware

kernel

KAPSE

MAPSE

APSE/user

KAPSE

Kernel Ada PSE

MAPSE Minimal Ada PSE

APSE Ada PSE


48/49

48

References

Young, S.J., Real-time Languages: Design and

Development, Ellis Horwood, 1982

Barnes, J. G. P., Programming in Ada Plus anOverview of Ada 9X, Addison-Wesley, 1994

Krishna C. M., Shin K. G., Real-time Systems,

McGraw-Hill Int. Editions, 1997

Burns A., Lister A. M., Wellings A. J., A Review

of Ada Tasking, Springer-Verlag, 1987


49/49

49

Thank You

Embeded System Software Issues

Documents

Transcript of Embeded System Software Issues