Automating the Processes of Selecting an Appropriate Scheduling Algorithm and Configuring the Scheduler Implementation for Time Triggered Embedded Systems 1st edition by Ayman Gendy, Michael Pont ISBN 3540876977 9783540876977 pdf download
Automating the Processes of Selecting an Appropriate Scheduling Algorithm and Configuring the Scheduler Implementation for Time Triggered Embedded Systems 1st edition by Ayman Gendy, Michael Pont ISBN 3540876977 9783540876977 pdf download
https://ebookball.com/product/automating-the-processes-of-
selecting-an-appropriate-scheduling-algorithm-and-
configuring-the-scheduler-implementation-for-time-triggered-
embedded-systems-1st-edition-by-ayman-gendy-michael-pont-
isbn/
https://ebookball.com/product/resilience-in-the-aviation-system-1st-
edition-by-antonio-chialastri-simone-pozzi-
isbn-3540876977-9783540876977-13626/
https://ebookball.com/product/the-art-of-the-art-of-designing-
embedded-systems-1st-edition-by-jack-
ganssle-9780080499352-008049935x-8874/
1 Introduction
Developers creating software for use in the majority of “desktop” applications face a
very different set of challenges from those creating embedded software. For example,
the time interval within which the desktop system responds to a command may vary
significantly without causing a major problem: by contrast, even small variations in
timing behaviour (milliseconds or much less) in embedded systems may prove life
threatening in (for example) an industrial, automotive or medical system.
There are two common approaches used in building real-time embedded systems:
event-triggered (ET) and time-triggered (TT). The ET approach may prove cost
effective in cases where the system must handle many aperiodic and sporadic events
([4], [5]), since the conversion of such events to periodic events may reduce the
system utilisation. On the other hand “time-triggered systems are to be preferred with
respect to fault tolerance” [4] and are also considered as best match for supporting
safety critical applications ([1], [2], [3], [4]). In addition, it is widely recognised that
“Very safety critical systems, like X-by-wire require fault-tolerance and redundancy.
The implementation of such systems probably will fail without the framework of time-
triggered architectures” [5]. For these reasons, this paper focuses on systems with a
TT architecture.
M.D. Harrison and M.-A. Sujan (Eds.): SAFECOMP 2008, LNCS 5219, pp. 440–453, 2008.
© Springer-Verlag Berlin Heidelberg 2008
Automating the Processes of Selecting an Appropriate Scheduling Algorithm 441
2 Related Work
In this section we review previous work in this area.
A wide range of software architectures can be used for real-time systems, ranging
from a simple scheduler to a full real-time operating system (RTOS).
For resource-constrained embedded systems, which have a very limited memory
and CPU performance, a simple form of “time triggered co-operative” (TTC) – a form
of cyclic executive – scheduler ([2], [8], [12], [14], [15]), “which has low run-time
overhead”[14], is often used. For safety-critical applications which have hard real-
time constraints, such as low jitter requirements, TTC architectures demonstrate very
low levels of task jitter [16], and can maintain their low-jitter characteristics even
when techniques such as dynamic voltage scaling (DVS) are employed to reduce
system power consumption [17].
The TTC implementation discussed in this paper executes each task in a predefined
time intervals which is derived from a scheduler “tick”. The scheduler tick is usually
signalled by an interrupt associated with the (periodic) overflow of a hardware timer.
At each tick the status of each task is updated and tasks which are due to run are
dispatched. The processor is then often placed in an “idle” mode, where it will
remain until the next tick (in order to reduce the system power consumption).
442 A.K. Gendy and M.J. Pont
When implementing a TTC or TTH scheduler, the system designer has to determine
some parameters (including the length of the tick interval, the order in which tasks
must be dispatched, and the initial delay - or phase - of each task). Inappropriate
choice of these parameters may affect systems reliability (by violating task
constraints) or lead to unnecessarily high levels of task jitter and / or to increased
system power consumption. It has been demonstrated in previous studies that the
problem of determining these parameters is NP-hard ([7], [8], [9], [10]).
In order to cope with this challenge, schedulability analysis and scheduler design
have been studied extensively over many years: see, for example, work by Liu and
Layland [22] through to work by Xu [7]. Researchers have proposed solutions based
on simulated annealing techniques [9], constraint programming heuristics [30], branch
and bound algorithm ([28]), and genetic algorithms [29].
None of the work summarised above relates directly to TTC / TTH architectures:
instead, most previous studies have tended to focus on “conventional” RT operating
systems (e.g. VxWorks: [29]). Such operating systems exceed the resource require-
ments available in the types of processor considered in this study.
As noted above the TTSA1 algorithm helps to automate the process of both
scheduler selection and configuration. If a suitable scheduler is identified for a given
task set, TTSA1 attempts to determine the suitable scheduler parameters (the tick
interval) and task parameters (such as the task order and task offset). In determining
these parameters, TTSA1 aims to ensure that: (i) task constraints are met; (ii) power
consumption is “as low as possible”; (iii) a fully co-operative scheduler architecture is
employed whenever possible.
The input to TTSA1 is a list of task specifications and constraints. The algorithm
tests the schedulability of the given task set, first using the TTC scheduler. If the task
set cannot be scheduled with this scheduler, the process is repeated using the TTH
scheduler. The algorithm calculates a suitable tick interval, along with the task order
and the required offset value for each task if all the tasks are schedulable; otherwise a
list of the schedulable tasks is generated.
To achieve this result, TTSA1 begins by sorting the tasks according to two criteria:
a) task precedence, b) task deadline, laxity, period, WCET, or jitter. It is then
assumed that the first task will run with zero offset and the algorithm tries to find a
suitable offset for the second task, using the longest possible tick interval. If such an
offset is identified (and the constraints of both tasks are met), a third task is added to
the system and the process is repeated. We carry on in this way until all tasks have
been scheduled (if this proves possible).
3.1 Overview
Despite its attractive features, the TTSA1 algorithm fails to find a suitable schedule
for a set of tasks in some cases. For example assume that for a given set all tasks
have deadlines equal to their periods. Assume also that this set includes two short
tasks (Task S1 and Tasks S2), and at least one long task (Task L).
Table 1. Task specifications for task set that cannot be scheduled with TTC/TTH
The TTSA1 algorithm fails to find a suitable schedule for this set if:
Deadline (S1) < WCET (S1) + WCET (L)
and
Deadline (S2) < WCET (S2) + WCET (L)
444 A.K. Gendy and M.J. Pont
Table 2. Task specifications for task set that can be scheduled with TTC/TTH
For example Task B and / or Task C shown in Table 1 will miss their deadlines
every time Task A runs if these three tasks are scheduled using TTC / TTH. To
overcome this situation, while still using a TTC / TTH architecture, long task(s) can
be divided into multiple short tasks ([3],[8], [16]): for example Task A can be divided
into two segments, Segment SA1 and Segment SA2, as shown in Table 2.
As previously indicated, testing the schedulability of a set of tasks and finding a
suitable scheduler for them (if any) is an NP-hard problem. The problem becomes
more complex if some parts of some tasks are required to exclude parts of other tasks
in the set. For example, it may be that Segment SA2 in Task A excludes Segment SB3
and Segment SC2 in Task B and Task C respectively, and Segment SB1 in Task B
excludes Segment SC1 in Task C.
In this section we extend our previous TTSA1 algorithm to deal with such
situations. We call the resulting algorithm TTSA2. The input to TTSA2 is a list of
task specifications and constraints, including critical-section boundaries.
The TTSA2 algorithm tests the schedulability of the given task set, first using the
TTC scheduler, if possible, otherwise it will try the TTH, considering each task as a
single segment. If the task set cannot be scheduled the process is repeated after
dividing one or more long tasks into two or more shorter tasks. The algorithm
calculates a suitable tick interval, the task order, the smallest number of task segments
along with the required offset value for each task and task segment if all the tasks are
schedulable; otherwise a list of the schedulable tasks and task segments is generated.
To achieve this result, TTSA2 begins (like TTSA1) by sorting the tasks according
to two criteria: a) task precedence, b) task deadline, laxity, period, WCET, or jitter. It
is then assumed that the first task will run as one segment with zero offset and the
algorithm tries to find a suitable offset for the second task (in one segment), using the
longest possible tick interval (the greatest common divisor of the task periods). If
such an offset is identified (and the constraints of both tasks are met), a third task is
added to the system and the process is repeated. We carry on in this way until all
tasks have been scheduled (if this proves possible). If a schedule cannot be found at
any stage the last task added to the design is removed and divided into two segments.
After adding the segmentation overhead and updating the segment deadlines (as
explained in the next subsections), the search proceeds (Fig. 1).
Please note that this search process is not exhaustive, and might be described as “best
characteristics first” approach: for example, it starts with a long tick interval (which is
known to reduce power consumption) and it gradually reduces the tick interval until it
matches the timing needs of the application (if ever). We proceed iteratively, stopping
the search when we have identified the first workable solution. We assume that -
because we have begun the search with “best characteristics” - any schedule identified
will represent a good (but not necessarily completely optimal) solution.
Automating the Processes of Selecting an Appropriate Scheduling Algorithm 445
START
Arrange tasks;
// Common divisors of task periods in descending order
GCD[t] = {GCD1, GCD2, …, GCDm}, t=1, 2,,.., m;
Sched_Strategy = {TTC, TTH};
If Task T is divided into n segments, ST1, ST2.., STn, then the TTSA2 algorithm
calculates the deadline of each segment as follows:
Deadline (STn) = Deadline (T) . (1)
Deadline (STi-1) = Deadline (STi) – WCET (STi), where i = n, n-1, n-2…,2 . (2)
Please notice the deadline of Segment SA1 in Table 2 as an example.
To be able to divide long tasks into multiple short tasks accurate information about
the task WCET and the points at which the task can / cannot be pre-empted (the critical
446 A.K. Gendy and M.J. Pont
sections boundaries) must be specified. This can be done using techniques such as the
“single path programming paradigm” ([24], [25]) or code balancing techniques [23].
If a task is divided into two or more segments, the TTSA2 algorithm takes
segmentation overhead into account. This overhead represents the time needed to
save the context of the current segment and the time needed to restore this context
when the next segment becomes ready to run. The time required for saving the
context (Context_Saving_overhead) may not be the same as that required for loading
the context (Context_Loading_overhead).
If Task T is divided into n segments, ST1, ST2.., STn, then the TTSA2 algorithm
updates the segments WCETs to reflect this overhead, as follows:
WCET (ST1) = WCET (ST1) + Context_Saving_overhead . (3)
Assume we have a set of n independent tasks and that each consists of s segments.
Investigating the schedulability of these tasks by means of a BaB algorithm requires
testing n paths, each of length n!, this has a complexity of O(n.n!) which is
“computationally intractable and cannot be used in practical systems when the
number of tasks is high”[27].
As noted elsewhere [11], the offset of each task can be any value in the range [0,
Period], in ticks. Taking all possible offset combinations (tn), where t is the period,
and considering each task as set of s segments, each may has different offset, the
complexity will increase to O(tn.s .n!).
By contrast, the TTSA2 algorithm does not try all paths. In addition, it does not
change the task or / and segment offset of a given task once it has been added
successfully to the schedule (that is, added without causing violation of the constraints
of any of the tasks and segments which have been included in the schedule
previously). The complexity of this algorithm is O(n.s.t).
Automating the Processes of Selecting an Appropriate Scheduling Algorithm 447
Precedence
If it is required that Task A precedes Task B, then, in any tick, Task B is allowed to
start its execution only after Task A completes its execution (e.g. see [28]).
In the current study, the precedence relation between any two tasks, A and B, is
(pseudo) randomly generated iff
P(A) = P(B) . (7)
and
P(A) ≥ ( WCET(A) + WCET (B) ) . (8)
Exclusion
If it is required that Segment SA2 in Task A excludes Segment SB3 in Task B, then, at
any tick, Segment SA2 is not allowed to pre-empt Segment SB3 and vice versa [28].
In the current study some tasks segments in each set were (pseudo) randomly
selected to have an exclusion relation between them.
Distance
The distance relation between any two tasks, A and B, can be defined as the minimum
distance between the completion of Task A and the start of Task B [29].
In the current study the precedence relation between two tasks was (pseudo)
randomly generated according to Equation 9.
448 A.K. Gendy and M.J. Pont
Latency
The latency relation between any two tasks, A and B, can be defined as the maximum
distance between the completion of Task B and the start of Task A [29].
In the current study the latency relation between two tasks was (pseudo) randomly
generated as follows:
If there are no distances constraint between Task A and Task B then:
(WCET(A) + WCET (B)) ≤ Latency(A, B) ≤ Max (P(A), P(B)) (11)
given that:
Max (P(A), P(B)) ≥ (WCET(A) + WCET (B)) . (12)
Otherwise:
(WCET(A) + WCET (B) + Distance (A,B)) ≤ Latency(A, B) ≤ P(A) . (13)
TTC TTH
3-task set
TTSA1 TTSA2 BaB1 BaB2 TTSA1 TTSA2 BaB1 BaB2
Minimum number of trials 2.00E+00 2.00E+00 2.00E+00 2.00E+00 2.00E+00 2.00E+00 2.00E+00 2.00E+00
Maximum number of trials 2.70E+02 5.80E+02 2.97E+03 4.66E+06 1.65E+02 3.30E+02 2.83E+03 1.99E+05
Average number of trials 2.46E+01 4.63E+01 3.51E+02 1.75E+04 1.59E+01 3.04E+01 1.97E+02 2.08E+03
Total number of trials 2.46E+04 4.63E+04 3.51E+05 1.75E+07 1.59E+04 3.04E+04 1.97E+05 2.08E+06
Total time (s) 4.00E+00 4.00E+00 3.90E+01 8.49E+02 2.50E+00 2.50E+00 2.50E+01 1.17E+02
TTC TTH
4-task set
TTSA1 TTSA2 BaB1 BaB2 TTSA1 TTSA2 BaB1 BaB2
Minimum number of trials 3.00E+00 3.00E+00 3.00E+00 3.00E+00 3.00E+00 3.00E+00 3.00E+00 3.00E+00
Maximum number of trials 2.65E+02 5.30E+02 7.23E+04 1.60E+08 2.65E+02 5.30E+02 4.21E+04 2.78E+07
Average number of trials 3.49E+01 7.01E+01 5.45E+03 5.30E+05 2.49E+01 4.99E+01 3.24E+03 1.13E+05
Total number of trials 3.49E+04 7.01E+04 5.44E+06 5.29E+08 2.49E+04 4.99E+04 3.23E+06 1.13E+08
Total time (s) 3.50E+00 4.50E+00 2.22E+02 1.73E+04 2.50E+00 4.50E+00 1.11E+02 4.17E+03
TTC TTH
5-task set
TTSA1 TTSA2 BaB1 BaB2 TTSA1 TTSA2 BaB1 BaB2
Minimum number of trials 4.00E+00 4.00E+00 4.00E+00 4.00E+00 4.00E+00 4.00E+00 4.00E+00 4.00E+00
Maximum number of trials 1.40E+02 3.14E+02 1.03E+06 1.21E+09 1.02E+02 2.26E+02 1.33E+06 1.98E+08
Average number of trials 4.04E+01 8.58E+01 8.84E+04 2.04E+07 2.93E+01 6.34E+01 5.41E+04 5.09E+06
Total number of trials 4.04E+04 8.58E+04 8.84E+07 2.04E+10 2.93E+04 6.34E+04 5.41E+07 5.09E+09
Total time (s) 2.50E+00 6.00E+00 3.69E+03 2.94E+06 2.50E+00 3.50E+00 5.26E+03 3.79E+05
Fig. 2. Number of Scheduled task sets (3 Fig. 3. Number of Scheduled task sets (4
interdependent tasks in each set) interdependent tasks in each set)
Fig. 4. Number of Scheduled task sets (5 Fig. 5. Number of Scheduled task sets (50
interdependent tasks in each set) interdependent tasks in each set)
Automating the Processes of Selecting an Appropriate Scheduling Algorithm 451
maximum period of 200 ms. The task sets were (pseudo) randomly created according
to the constraints described previously. To reduce the length of the major cycle, task
periods were (pseudo) randomly generated as a multiple of 20 ms.
The results from this test are shown in Fig. 5. It took approximately 1 minute to
complete the schedulability test for one set of 50 tasks using TTSA2-EDF, and a total
of approximately 6 minutes to complete the test for TTSA2-All. It was not possible
to complete this search using a BaB approach as this would have required performing
a huge number of trials.
References
1. Domaratsky, Y., Perevozchikov, M.: Highly dependable time-triggered operating system-
static scheduling approach and effective run-time implementations, Dedicated Systems
Magazine, pp. 77–84 (October-December 2000)
2. Kopetz, H.: Real-Time Systems, Design Principles for Distributed Embedded
Applications. Kluwer Academic, Dordrecht (1997)
3. Pont, M.J.: Patterns For Time-Triggered Embedded Systems. Addison-Wesley, Reading
(2001)
452 A.K. Gendy and M.J. Pont
24. Puschner, P., Burns, A.: Writing Temporally Predictable Code. In: Proc. 7th IEEE
International Workshop on Object-Oriented Real-Time Dependable Systems, pp. 85–91
(January 2002)
25. Puschner, P.: The Single-Path Approach Towards WCET-Analysable Software. In: Proc.
IEEE International Conference on Industrial Technology, pp. 699–704 (December 2003)
26. Cucu, L., Sorel, Y.: Non-Preemptive Multiprocessor Scheduling for Strict Periodic
Systems with Precedence Constraints. In: Proc. 23rd Annual Workshop of the UK
Planning and Scheduling Special Interest Group, PLANSIG 2004, Cork, Ireland
(December 2004)
27. Buttazzo, G.: Hard Real-Time Computing Systems: Predictable Scheduling Algorithms
and Applications. Kluwer Academic, Dordrecht (1997)
28. Xu, J., Parnas, D.L.: Scheduling Processes with Release Times, Deadlines, Precedence and
Exclusion Relations. IEEE Transactions on Software Engineering 16(3), 360–369 (1990)
29. Sandström, K., Norström, C.: Managing Complex Temporal Requirements in Real-Time
Control Systems. In: 9th IEEE Conf. Engineering of Computer-Based Systems. IEEE,
Sweden (2002)
30. Ekelin, C., Jonsson, J.: Evaluation of Search Heuristics for Embedded System Scheduling
Problems. In: Proc. Int. Conf. Principles and Practice of Constraint Programming, Paphos,
Cyprus, pp. 640–654 (2001)
31. Reeves, G.: What Really Happened on Mars?, – Authoritative Account (1997),
http://research.microsoft.com
Other documents randomly have
different content
Alma, i. 17
Bothnia, Gulf of, Russian aims, i. 9, 41, 42
Boxer Rebellion, i. 136, 154, 155
Bulgaria:
Turko-Servian War, i. 24, 25;
Russian behaviour in, i. 29, 30
Burun, M., on the Russian fleet, i. 236, 237, 240, 241
Caucasus, the:
her Russian frontier, i. 5, 8, 33, 34, 57, 58;
her troops, i. 26, 114
Cavalry:
not sufficiently used, ii. 151, 152;
failure of the officers, ii. 153–155, 288;
details of units, ii. 162
Censorship, necessity for press, ii. 176
Charles XII., King of Sweden, war with Russia, i. 5
Cherniaeff, General, Geok Tepe, i. 32
Chichagoff, General, his alarmist reports, ii. 302, 321, 322
China:
peaceful attitude of, i. 5;
Peking Treaty, i. 35;
Russian frontier and trade, i. 67, 68;
war with Japan, i. 69, 151, 201–204;
Russian policy, i. 72, 157;
the awakening of, i. 91;
Boxer Rebellion and treaty with Russia, i. 154–162;
her alarm at Russia’s policy, i. 170;
Russian treatment of the Chinese, ii. 190, 191
Chin-chou, battle of, i. 257
Civil disorder, repression of, ii. 125
Constantinople, Russian advance to walls of, i. 30, 82
Cossacks. See Cavalry
Crimean War:
strength of Russian army, i. 13;
Russia’s unpreparedness, i. 16, 101, 109;
Inkerman, i. 18;
siege of Sevastopol, i. 19;
a premature peace, i. 20–22
Dalny:
Russian annexation of, i. 69;
Japanese use of, i. 127;
its fortifications, i. 172, ii. 207;
commerce, i. 190;
coal storage at, i. 246
Danube, the, Russian acquisition and loss of the mouths of, i.
13, 16, 19, 24, 32
Defence schemes, ii. 26–30
Dembovski, General, at Mukden, ii. 285, 286
Demchinski, M., Were we Ready for War? i. 111
Djam, Russian force at, i. 84
Dragomiroff, General, and quick-firing artillery, i. 136;
his theories, ii. 8, 10, 11
Dubniak Hill, capture of, i. 25
Dukhovski, General, Governor-General and Commander in the
Pri-Amur district,
and the Siberian Railway, i. 151, 171
Dushkevitch, Colonel, i. 302
Japan:
peaceful attitude of, i. 5;
Russia and Saghalien, i. 35;
Peking Treaty, i. 35;
war with China, i. 69, 151, 202–204;
events leading up to the war with Russia, i. 123–130, 151,
157–166, 170, 177–179;
the Royal Timber Company, i. 172;
Kuropatkin’s visit to, and impressions of, i. 174, 175, 217–
223;
progress of negotiations, i. 188, 193;
Russia’s bluff, i. 193–198;
her early history, i. 199;
birth of her army, i. 200–202;
expedition to China, i. 203;
her estimated strength, i. 203, 208, ii. 192;
expansion for war, i. 204–206;
her loss in the war with Russia, i. 207, ii. 192;
her sea-transport, i. 209;
Russian criticisms on the army of, i. 210;
her officers in Russian employ, i. 212;
her reserve troops, i. 213;
the samurai spirit, i. 214;
her resentment with Russia, i. 215;
her system of education, i. 217–219;
Korea a vital question, i. 219;
German and English appreciations of, i. 222, 223;
her disembarkations on Liao-tung Peninsula and Kuan-tung
unhindered, i. 225;
her advantages, i. 226;
their moral tone, i. 227;
the nation with the army, i. 228;
partial exhaustion, i. 230, 235, ii. 194, 195;
strength of the fleets in the Far East, i. 236, 237;
the naval battles near Port Arthur and Vladivostok, i. 238–
241;
her victories at the Yalu, Chin-chou and Te-li-ssu, i. 257, 258,
ii. 38, 83;
her treaty with Great Britain, i. 269;
relative positions after fifteen months’ war, ii. 31–35, 39–44;
her losses, ii. 192, 193;
Kuropatkin’s summary of the war, ii. 217–287, 314–335
Jassy, Treaty of, i. 6
Jilinski, General, Headquarter Staff, i. 206, 256
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
ebookball.com