Embedded Systems: Software Issues

Nidhi Majumder
International Institute of Information Technology Kolkata 700 091

Outline of the Talk

Scheduling Mechanisms They are the ones that distinguish between a real-time system and a general-purpose system Language Issues It is the language, which in conjunction with the hardware gives the support to the system designer what he or she wants to achieve
2

Scheduling Algorithms
Uniprocessor Scheduling Algorithms Multiprocessor Scheduling Algorithms

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
4

Assumptions for Classical Uniprocessor Scheduling Algorithms (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
5

Rate-Monotonic (RM) Scheduling Algorithm

Static-priority preemptive scheme Further assumptions
All tasks in the task set are periodic The relative deadline of a task is equal to its period

Last assumption simplifies the whole analysis, ensures that there can be at most one iteration of any task alive at any time
6

Notations Used
n number of tasks ei execution time of task Ti Pi period of task Ti Ii phasing of task Ti, so kth period of task Ti begins at time Ii + (k 1) Pi di relative deadline of task Ti Di absolute deadline of task Ti Ri release time of task Ti
7

A Typical Example of RM

11
0 1

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
21
2

12

21
3

31
4

13

31
5 6

14
7

22
8

Test for Schedulability

If the total utilization of n tasks is no greater than n (2 1/n -1), then the RM algorithm will be able schedule all the tasks to meet their respective deadlines This is sufficient but not a necessary condition

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<= P1 T2 can be scheduled successfully if its 1st iteration can find enough time over [0, P2], after scheduling all the iterations of T1 released over this time We must find some t <= P2 satisfying
t=

/
t P1

e1 + e2

Number of checks is finite, at multiples of P1

10

Necessary and Sufficient Condition (contd.)

Finally for T3
t=

t / P e + t / P e + e
1 1 2 2

Check at finite points where t is a multiple of P1 and/or P2

11

Conditions for General Case

t / P e Note that for 0 < t <= P , t / P = 1

Wi(t) = j = 1 to i
j j
i i

Li(t) = Wi(t) / t Li = min 0<= t <= Pi {Li(t)} L = max {Li} Task Ti can be feasibly scheduled iff Li <= 1 All the tasks can be scheduled iff L <= 1
12

Sporadic Task Handling

Tasks released irregularly, often in response to save special event in the operating environment. There must exist a maximum rate at which they can be released Some minimum inter-arrival time between the release of successive iteration of sporadic tasks exists Approach - Consider as periodic task with a period equal to the minimum inter-arrival time
13

Simple Approach
Define a fictitious periodic task of highest priority and of some chosen fictitious execution 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 processor remains idle
0 1 2 3 4 5 6 7 14 8

Deferred Server Approach

Whenever the processor is scheduled to run sporadic tasks, and no task is waiting, it executes other periodic tasks in order of priority However if sporadic tasks arrives, it preempts the other tasks and can occupy a total time up to the time allotted for sporadic tasks
0 1 2 3 4 5 6 7 15 8

Schedulability Criteria for DS Approach

Assumption Relative deadlines of all tasks equal to 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.5 Us if Us 0.5
0 1 2 3 4 5 6 7 8 16

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
17

A Typical Example
Consider the following aperiodic tasks
Task
1 2 3

Arrival Time
0 4 5

Execution Time Absolute Deadline

10 3 10 30 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, it runs till 17 and then finally T1 picks up
18

Schedulability Test for EDF

If all the tasks are periodic, we have relative deadlines equal to their periods, the task set can be scheduled if the total utilization is no greater than 1 However if the relative deadlines is not equal to the periods, then the expression is a bit complex Approach - Develop a schedule according to EDF to see if deadlines are met
19

Scheduling with Precedence and Exclusion Conditions

A precedence graph is given giving the dependency, sometimes they have AND/OR constraints Exclusion condition Not all tasks can preempt every other task
2 1 5 3 20 6 4

 System has primary and alternative versions of some particular task Versions vary in execution time and quality of output IRIS task Increased Reward with Increased Service Examples Calculation of e or Several Variations
Identical Linear Reward Function, Non-identical Linear Reward Function, 0-1 Reward Function, Identical Concave Reward Function, Non-identical Concave Linear Function
21

Multiple Task Versions

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 feasible schedule If not feasible, modify the allocation and check eg. For periodic tasks with relative deadline equal to their periods try to maintain a utilization < n (2 1/n -1) Communication costs need to be taken care of for multiprocessors
22

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
23

References
Coffman, E. G., Computer and Job-shop Scheduling Theory, Wiley, 1976 Liu C. L. and Layland J. W., Scheduling Algorithms for Multiprogramming in a Hard-real-time Environment, JACM, 20(1), 46-61, 1973 Krishna C. M., Shin K. G., Real-time Systems, McGraw-Hill Int. Editions, 1997
24

Language issues
What is a good real-time programming language?
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

25

Desired Characteristics
Most of them common to general-purpose programming languages
Readable Portable across platforms Modular One should be able to compile or debug the modules separately
26

Additional Demands for Real-time Applications

Deadlines should be met
Programmers should be able to specify priorities or run-time requirements Programmers must also have a way to specify absolute time intervals

Interfaces to devices like sensors, actuators should be easy to write

27

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 ambiguities Central committee to resolve ambiguities (Ada has one)
28

Complexity affects Portability

To make things portable one might want every feature in every implementation must exist in every other implementation Two problems can come up
Language may become trivial with few features To satisfy a wide spectra of users the language is overloaded with features

Solution in Ada Has a core set of features with several annexes, if a compiler writer supports an annex X, he has to support it fully
29

There is a limit to Portability

Real-time systems have to deal with a larger variety of devices compared to the generalpurpose computers Compromise
Keep a distinction between the machine-dependent and machine-independent parts of the program

To handle devices, language should support the programmer to specify absolute addresses and also to insert assembly language code fragments
30

Control over Scheduling

A real-time language should give a programmer more power or flexibility to schedule a particular task in order to 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
31

Need for an Accurate Clock

Hardware level need a stable quartz clock with reliable synchronization methods Language level granularity of the clock should be 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
32

Strong Data Typing

Each variable must be explicitly declared to have a particular data type Each data type has exclusive set of values and a set 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
33

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 chuck with ROOTS; use ROOTS
34

Exception (Run-time Error) Handling

More important for real-time languages as program crash may mean aircraft crash Desired Properties
Should not make the software cumbersome Should have low overheads Programmer should be able to specify recovery routines in response to various run-time errors

Exceptions are predefined or user-defined

35

Predefined Exception Conditions

CONSTRAINT_ERROR variable goes outside the prescribed bounds NUMERIC_ERROR inability to maintain adequate precision (Divide by zero) STORAGE_ERROR out of memory space PROGRAM_ERROR asserted when an exception occurs that is not captured by any other conditions TASKING_ERROR errors that arise due to incorrect use of tasking mechanism
36

A Typical Example
declare TEMPERATURE: float; TOO_HOT, TOO_COLD: exception; begin loop READ_TEMEPERATURE(TEMEPERATURE); if TEMPERATURE < 400 raise 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;
37

Anonymous Exceptions
If procedure B calls procedure C and C has a declared exception XX with no handling routine, then if such an exception is raised control is returned to B B knows that an exception is raised but has no way to recognize it as not declared in B We say XX is anonymous in B and may be caught using a catchall clause when others
38

Multitasking
As real-time computers often use parallel processors, realtime languages should support concurrency procedure XYZ is
task X; task body X is -- task body end X; task Y; task body Y is -- task body end Y;

begin
-- procedure body

end XYZ;
39

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 be sued to define a static priority level Ada9X real-time annex requires every system to support at least 31 distinct priority classes, actual number being implementation dependent

40

Task Scheduling
Two common scheduling mechanism supported are FIFO and changing static priority using pragma PRIORITY However real-time systems much advanced support to implement algorithms like Rate Monotone scheduling and earliest deadline first scheduling Real-time annex offers some assistance to the programmers in the form of
Task Dispatching policy Entry Queuing Policy
41

Timing Requirements from Next Generation Language

Specify that the duration between two events is no longer than a specified maximum and no shorter than a specified minimum Specify the maximum run time to be allocated to a particular task, if exceeded, raise exception. Results in asynchronous transfer of control Specify the absolute time at which a given task is to begin execution Specify that a particular task begins n seconds after some other task has been completed
42

Requirements (contd.)
Specify how soon a message is to be received after it is sent 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 for processing that loop Specify upper bounds on the size of any dynamic data structures, thus specifying a bound on the time required to pass them between procedures, or to allocate and deallocate storage
43

Experimental Languages
Flex developed by Univ. of Illinois 2 distinct characteristics
Powerful constraint specifications Ability to select one from multiple algorithms

Can run imprecise computations also simply by specifying when the computation must terminate A derivative of C++ with a preprocessor
44

Experimental Languages (contd.)

Euclid developed at University of Toronto Remarkable feature specifically designed to allow for reasonably accurate estimates of worstcase program run times Dynamic data structures not allowed escape route is each system implementation allows a maximal size for each data structure Recursion not allowed No while loops instead use for loops or timebounded loops
45

Programming Support Environment (PSE)

A good PSE is a must for good software The PSE for Ada is given by Stoneman specifications It suggests a layered approach for building PSE Rationale is to maximize portability by making the support environment as independent of the underlying hardware and kernel as possible PSE is very complex and expensive, so not possible to write for every new machine, hence portability is a must
46

Layered Programming Support Environment

APSE/user MAPSE KAPSE kernel hardware

KAPSE Kernel Ada PSE MAPSE Minimal Ada PSE APSE Ada PSE

47

References
Young, S.J., Real-time Languages: Design and Development, Ellis Horwood, 1982 Barnes, J. G. P., Programming in Ada Plus an Overview 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
48

Thank You

49