Introduction to Embedded Systems Research: Scheduling...
Transcript of Introduction to Embedded Systems Research: Scheduling...
Introduction to Embedded Systems Research:Scheduling, embedded OSs, and CPS
Robert Dick
[email protected] of Electrical Engineering and Computer Science
University of Michigan
Fovea
Lens
Cornea
Variable Resolution
and Position Sampling
Change-Adaptive
Signalling
Spatial State
Cache
(Occipital
Place Area)
Analasys, e.g.,
Classification
Adequate
decision confidence?
Sampling Guidance
Y
N
Long-Term Memory
Decision /
Result
(b) Iterative, multi-round human vision system.
Image Signal
Processor
Application Processor
(CPU and/or GPU)
CloudDecision /
Result
(a) Conventional machine vision pipeline.
Image Sensor: typically
homogeneous RGGB or RCCC.
Demosaicing, binning,
denoising, gamma
correction, and compression.
Hardware Feature
Extraction Accelerator
or
Feature extraction on
raw captured data.
Runs CNN, LSTM or
other analysis algorithm.
May drop computation on less
important data, but already payed
Image Signal Processor transfer cost.
May render decision or (at high
energy cost) do feature extraction
and defer decision to cloud.
Minimalistic
Image Pre-Processor
Application Processor
(CPU and/or GPU)
CloudDecision /
Result
Image Sensor: capture only the
most important
data for decision accuracy.
Efficient gamma
correction
and binning.
Decide based on features.
Very high energy cost for
wireless data transfer.
Scene Cache
Capture ControllerHardware Feature
Extraction Accelerator
or
Adequate
decision confidence?
or
Y
N
Captures most relevant
and rapidly changing data.
Learns important sample locations
from prior rounds.
Maintains state built from
prior still-relevant samples.
Determine and
transmit
relevant data.
Decide based on features.
Very high energy cost for
wireless data transfer.
Issue commands to
capture important data.
(c) Goal: multi-round, energy-efficient, low-latency
continuous learning machine vision.
Feature extraction on sparse captured
data with similar distribution to processed data.
Continuously learn features and important
data based on prior captures.
1.1040
2.1041
385
2.1039
704
1.1039
36
2.1040
1734
0.1039
1
3.1040
4
4.1039
642
3.1039
4.1040
409
3.1041
396665
5.1042
108612774
5.1040
337
4.1041
10644
6.1044
117
6.1039
609
6.1045
164
6.1040
841434 723938
6.1042
209
5.1041
4 12 164
5.1045
529417
5.1044
140105 88
5.1039
154 10551 90677
7.1039
1248
7.1047
2106
7.1040
29773362 241966 22903106
6.1041
3119 1936 40
6.1047
4128 253
8.1050
4
8.1042
9.1050
24784
8.1039
89632
8.1044
2840
8.1040
1088
9.1039
10.1040
4
11.1039
957
10.1050
144
11.1040
156
10.1041
32 16
10.1047
87780
10.1045
2152
10.1039
1165
12.1040
145
13.1052
2404
12.1042
24
12.1045
33008
12.1044
8217
12.1041
8
12.1039
135427
14.1049
113
14.1040
229
13.1050
132
13.1042
74433
13.1041
17187
13.1040
2715
13.1039
170059 90
15.1040
16
15.1050
242 1225
14.1050
237
14.1042
6200
14.1041
4
14.1044
720
14.1052
20
14.1039
84 36939
16.1040
88
15.1049
6
15.1039
56
17.1054
2919
16.1050
129
16.1041
36
16.1047
49154
16.1045
2632
16.1049
27
16.1052
16
16.1039
222734
18.1048
133
18.1039
3439
18.1040
241
17.1050
16
18.1049
36 339224
17.1042
172832
17.1041
49620 448
17.1040
1376493 2883
17.1045
72
17.1044
1073
17.1049
55441826
17.1048
124 3648290
17.1052
3547
17.1039
2484110477445
17.1047
24
19.1040
72
19.1039
6 88 60631617
18.1041
28 76
18.1047
3305
18.1054
13744
20.1040
109
20.1039
269
19.1052
8
19.1047
11712
19.1049
10
19.1054
7520
21.1039
82
20.1049
5
20.1047
4896
20.1054
864
22.1040
4
22.1050
23.1040
4
22.1039
144
24.1058
3389
23.1050
76
24.1040
4
23.1042
17528
23.1041
4
23.1054
24
23.1044
6234
23.1058
261
23.1049
4
23.1052
2944
23.1039
3069658
25.1040
80
24.1050
4
24.1039
58
25.1039
26.1040
4
27.1039
489
26.1050
4
27.1040
4
26.1047
3808
26.1045
2248
26.1058
113 80
26.1049
11
26.1039
66
26.1054
840
28.1055
84266 1542
27.1042
1229
27.1041
29619
27.1058
12
27.1049
3984
27.1048
35337
29.1040
262
29.1056
164
29.1039
742
28.1050
4 2464
28.1042
2137912
29.1055
1128
28.1041
4 2633 4
28.1040
2716132 691
28.1058
24 84 32
28.1049
36176 3
28.1048
1192 48
28.1039
365 110957 24475
29.105029.104229.104129.104729.104529.105829.104929.105229.1054
2
3
4
5
6
7
8
0 1 2 3 4 5 6 7 8
Pow
er
(mW
)
Time (s)
35 40 45 50 55 60 65 70 75 80 85 90
-8 -6 -4 -2 0 2 4 6 8
-8
-6
-4
-2
0
2
4
6
8
35 40 45 50 55 60 65 70 75 80 85 90
Temperature (°C)
Position (mm)
Temperature (°C)
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Outline
1. Realtime systems
2. Rate Monotonic Scheduling
3. Real-time and embedded operating systems
4. Cyber-physical systems overview
5. Deadlines and announcements
2 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Section outline
1. Realtime systemsTaxonomyDefinitionsCentral areas of real-time study
3 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Taxonomy of real-time systems
DynamicStatic
4 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Taxonomy of real-time systems
Soft Hard
5 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Taxonomy of real-time systems
Single rate Multi−rate
Periodic Aperiodic
Bounded
arrival intervalUnbounded
arrival interval
6 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Taxonomy of real-time systems
DynamicStatic Soft Hard Single rate Multi−rate
Periodic Aperiodic
Bounded
arrival intervalUnbounded
arrival interval
7 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Taxonomy of real-time systems
DynamicStatic Soft Hard Single rate Multi−rate
Periodic Aperiodic
Bounded
arrival intervalUnbounded
arrival interval
8 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Static
Task arrival times can be predicted.
Static (compile-time) analysis possible.
Allows good resource usage (low processor idle time proportions).
Sometimes designers shoehorn dynamic problems into static formulationsallowing a good solution to the wrong problem.
9 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Dynamic
Task arrival times unpredictable.
Static (compile-time) analysis possible only for simple cases.
Even then, the portion of required processor utilization efficiency goes to0.693.
In many real systems, this is very difficult to apply in reality (more on thislater).
Use the right tools but don’t over-simplify, e.g.,
We assume, without loss of generality, that all tasks are independent.
10 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Soft real-time
More slack in implementation.
Timing may be suboptimal without being incorrect.
Problem formulation can be much more complicated than hard real-time.
Two common (and one uncommon) methods of dealing with non-trivial softreal-time system requirements.
Set somewhat loose hard timing constraints.
Informal design and testing.
Formulate as optimization problem.
11 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Hard real-time
Difficult problem. Some timing constraints inflexible.
Simplifies problem formulation.
12 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Periodic
Each task (or group of tasks) executes repeatedly with a particular period.
Allows some nice static analysis techniques to be used.
Matches characteristics of many real problems. . .
. . . and has little or no relationship with many others that designers try topretend are periodic.
13 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Periodic → single-rate
One period in the system.
Simple.
Inflexible.
This is how a lot of wireless sensor networks are implemented.
14 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Periodic → multirate
Multiple periods.
Can use notion of circular time to simplify static (compile-time) scheduleanalysis E. L. Lawler and D. E. Wood, “Branch-and-bound methods: Asurvey,” Operations Research, pp. 699–719, July 1966.
Co-prime periods leads to analysis problems.
15 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Periodic → other
It is possible to have tasks with deadlines less than, equal to, or greater thantheir periods.
Results in multi-phase, circular-time schedules with multiple concurrent taskinstances.
If you ever need to deal with one of these, see me (take my code). This classof scheduler is nasty to code.
16 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Aperiodic
Also called sporadic, asynchronous, or reactive.
Implies dynamic.
Bounded arrival time interval permits resource reservation.
Unbounded arrival time interval impossible to deal with for anyresource-constrained system.
17 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Section outline
1. Realtime systemsTaxonomyDefinitionsCentral areas of real-time study
18 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Definitions
Task.
Processor.
Graph representations.
Deadline violation.
Cost functions.
19 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Task
Some operation that needs to be carried out.
Atomic completion: A task is all done or it isn’t.
Non-atomic execution: A task may be interrupted and resumed.
20 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Processor
Processors execute tasks.
Distributed systems.
Contain multiple processors.
Inter-processor communication has impact on system performance.
Communication is challenging to analyze.
One processor type: Homogeneous system.
Multiple processor types: Heterogeneous system.
21 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Task/processor relationship
Matrix
FIR
Tooth
Road
WC exec time (s)
310E−3
...
...
...
...
7.7E−6
330E−9
4.1E−6
IBM PowerPC 405GP 266 MHz
IDT79RC32364 100 MHz
Imsys Cjip 40 MHz
Relationship between tasks, processors, and costs.
Examples: power consumption or worst-case execution time.
22 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Cost functions
Mapping of real-time system design problem solution instance to cost value.
I.e., allows price, or hard deadline violation, of a particular multi-processorimplementation to be determined.
23 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Back to real-time problem taxonomy: jagged edges
Some things can dramatically complicate real-time scheduling.
Data dependencies.
Unpredictability.
Distributed systems.
Heterogeneous processors.
Preemption.
24 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Section outline
1. Realtime systemsTaxonomyDefinitionsCentral areas of real-time study
25 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Central areas of real-time study
Allocation, assignment and scheduling.
Operating systems and scheduling.
Distributed systems and scheduling.
Scheduling is at the core of real-time systems study.
26 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Operating systems and scheduling
How does one best design operating systems to
Support sufficient detail in workload specification to allow good control, e.g.,over scheduling, without increasing design error rate.
Design operating system schedulers to support real-time constraints?
Support predictable costs for task and OS service execution.
27 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Distributed systems and scheduling
How does one best dynamically control
The assignment of tasks to processing nodes...
... and their schedules.
for systems in which computation nodes may be separated by vast distancessuch that
Task deadline violations are bounded (when possible)...
... and minimized when no bounds are possible.
28 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
The value of formality: optimization and costs
The design of a real-time system is fundamentally a cost optimizationproblem.
Minimize costs under constraints while meeting functionality requirements.
Functionality requirements are actually just constraints.
Why view problem in this manner?
Without having a concrete definition of the problem.
How is one to know if an answer is correct?
More subtly, how is one to know if an answer is optimal?
29 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TaxonomyDefinitionsCentral areas of real-time study
Optimization
Thinking of a design problem in terms of optimization gives design teammembers objective criterion by which to evaluate the impact of a designchange on quality.
Know whether your design changes are taking you in a good direction
30 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Outline
1. Realtime systems
2. Rate Monotonic Scheduling
3. Real-time and embedded operating systems
4. Cyber-physical systems overview
5. Deadlines and announcements
31 R. Dick EECS 507
Primary publication
C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogrammingin a hard-real-time environment,” J. of the ACM, vol. 20, no. 1, pp. 46–61,Jan. 1973.
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Rate mononotic scheduling (RMS)
Single processor.
Independent tasks.
Differing arrival periods.
Schedule in order of increasing periods.
No fixed-priority schedule will do better than RMS.
Guaranteed valid for loading ≤ ln 2 = 0.69.
For loading > ln 2 and < 1, correctness unknown.
Usually works up to a loading of 0.88.
33 R. Dick EECS 507
Rate monotonic scheduling
1973, Liu and Layland derived optimal scheduling algorithm(s) for thisproblem.
C. L. Liu and J. W. Layland, “Scheduling algorithms for multiprogrammingin a hard-real-time environment,” J. of the ACM, vol. 20, no. 1, pp. 46–61,Jan. 1973.
Schedule the job with the smallest period (period = deadline) first.
Analyzed worst-case behavior on any task set of size n.
Found utilization bound: U(n) = n · (21/n − 1).
0.828 at n = 2.
As n→∞, U(n)→ log 2 = 0.693.
Result: For any problem instance, if a valid schedule is possible, theprocessor need never spend more than 31% of its time idle.
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Optimality and utilization for limited case
Simply periodic: All task periods are integer multiples of all lesser taskperiods.
In this case, RMS/DMS optimal with utilization 1.
However, this case rare in practice.
Remains feasible, with decreased utilization bound, for in-phase tasks witharbitrary periods.
35 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Rate monotonic scheduling
Constrained problem definition.
Over-allocation often results.
However, in practice utilization of 85%–90% common.
Lose guarantee.
If phases known, can prove by generating instance.
36 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Critical instants
Definition
A job’s critical instant a time at which all possible concurrent higher-priorityjobs are also simultaneously released.
Useful because it implies latest finish time
37 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Definitions
Period: T .
Execution time: C .
Process: i .
Utilization: U =∑m
i=1Ci
Ti.
Assume Task 1 is higher priority than Task 2, and thus T1 < T2.
38 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Critical instants
C1
T1
C1
C2
C1
T1 T1
Case 1 Case 2
T2
39 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Case 1 I
All instances of higher-priority tasks released before end of lower-priority taskperiod complete before end of lower-priority task period.
C1 ≤ T2 − T1
⌊T2
T1
⌋.
I.e., the execution time of Task 1 is less than or equal to the period ofTask 2 minus the total time spent within the periods of instances of Task 1finishing within Task 2’s period.
Now, let’s determine the maximum execution time of Task 2 as a function ofall other variables.
Number of T1 released =⌈T2
T1
⌉so C2,max = T2 − C1
⌈T2
T1
⌉.
40 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Case 1 II
I.e., the maximum execution time of Task 2 is the period of Task 2 minus thetotal execution time of instances of Task 1 released within Task 2’s period.
41 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Case 1 III
In this case,
U = U1 + U2
=C1
T1+
C2,max
T2
=C1
T1+
T2 − C1
⌈T2
T1
⌉T2
=C1
T1+ 1−
C1
⌈T2
T1
⌉T2
= 1 + C1
(1
T1− 1
T2
⌈T2
T1
⌉)
42 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Case 1 IV
Is 1T1− 1
T2
⌈T2
T1
⌉≤ 0?
If T2 = T1 + ε, this is
1
T1− 1
T1 + ε
⌈T1 + ε
T1
⌉=
1
T1− 2
T1 + εwhich is less than or equal to zero.
Thus, U is monotonically nonincreasing in C1.
43 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Case 2 I
Instances of higher-priority tasks released before end of lower-priority taskperiod complete after end of lower-priority task period.
C1 ≥ T2 − T1
⌊T2
T1
⌋.
C2,max = T1
⌊T2
T1
⌋− C1
⌊T2
T1
⌋.
U1 = C1/T1.
U2 = C2/T2 = T1
T2
⌊T2
T1
⌋− C1
T2
⌊T2
T1
⌋.
U = U1 + U2 = T1
T2
⌊T2
T1
⌋+ C1
(1T1− 1
T2
⌊T2
T1
⌋).
44 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Minimal U I
C1 = T2 − T1
⌊T2
T1
⌋.
U = 1− T1
T2
(⌈T2
T1
⌉− T2
T1
)(T2
T1−⌊T2
T1
⌋).
Let I =⌊T2
T1
⌋and
f = T2
T1.
Then, U = 1− f (1−f )I+f .
To maximize U, minimize I , which can be no smaller than 1.
U = 1− f (1−f )1+f .
45 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Minimal U II
Differentiate to find mimima, at f =√
2− 1.
Thus, Umin = 2(√
2− 1)≈ 0.83.
Is this the minimal U? Are we done?
46 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Proof sketch for RMS utilization bound
Consider case in which no period exceeds twice the shortest period.
Find a pathological case: in phase
Utilization of 1 for some duration.
Any decrease in period/deadline of longest-period task will causedeadline violations.
Any increase in execution time will cause deadline violations.
47 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Proof sketch for RMS utilization bound
See if there is a way to increase utilization while meeting all deadlines.
Increase execution time of high-priority task.
e′i = pi+1 − pi + ε = ei + ε.
Must compensate by decreasing another execution time.
This always results in decreased utilization.
e′k = ek − ε.
U ′ − U =e′ipi
+e′kpk− ei
pi− ek
pk= ε
pi− ε
pk.
Note that pi < pk → U ′ > U.
48 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Proof sketch for RMS utilization bound
Same true if execution time of high-priority task reduced.
e′′i = pi+1 − pi − ε.
In this case, must increase other e or leave idle for 2 · ε.
e′′k = ek + 2ε.
U ′′ − U = 2εpk− ε
pi.
Again, pk < 2→ U ′′ > U.
Sum over execution time/period ratios.
49 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Proof sketch for RMS utilization bound
Get utilization as a function of adjacent task ratios.
Substitute execution times into∑n
k=1ekpk
.
Find minimum.
Extend to cases in which pn > 2 · pk .
50 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Notes on RMS
DMS better than or equal RMS when deadline 6= period.
Why not use slack-based?
What happens if resources are under-allocated and a deadline is missed?
51 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Multiprocessor breaks critical instant
P1
P2
1
2
3
4
1
3
2 4P1
P2
52 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Outline
1. Realtime systems
2. Rate Monotonic Scheduling
3. Real-time and embedded operating systems
4. Cyber-physical systems overview
5. Deadlines and announcements
53 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Many options
eCos.
LynxOS.
MontaVista Linux.
QNX.
RTAI.
RTLinux.
Symbian OS.
VxWorks.
FreeRTOS.
Etc.
54 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Threads
Threads vs. processes: Shared vs. unshared resources.
OS impact: Windows vs. Linux.
Hardware impact: MMU.
55 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Threads vs. processes
Threads: Low context switch overhead.
Threads: Sometimes the only real option, depending on hardware.
Processes: Safer, when hardware provides support.
Processes: Can have better performance when IPC limited.
56 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Software implementation of schedulers
TinyOS.
Light-weight threading executive.
µC/OS-II.
Linux.
Static list scheduler.
57 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
TinyOS
Most behavior event-driven.
High rate → livelock.
Research schedulers exist.
58 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
BD threads
Brian Dean: Microcontroller hacker.
Simple priority-based thread scheduling executive.
Tiny footprint (fine for AVR).
Low overhead.
No MMU requirements.
59 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
µC/OS-II
Similar to BD threads.
More flexible.
Bigger footprint.
60 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Old Linux scheduler
Single run queue.
O (n) scheduling operation.
Allows dynamic goodness function.
61 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
O (1) scheduler in Linux 2.6+
Written by Ingo Molnar.
Splits run queue into two queues prioritized by goodness.
Requires static goodness function.
No reliance on running process.
Compatible with preemptable kernel.
62 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
O (log n) scheduler in Linux 2.6.23+
Written by Ingo Molnar.
Used red-black tree to maintain accumulated task times.
Always schedules task with least accumulated time.
Weights accumulated time based on priority.
63 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Real-time Linux
Run Linux as process under real-time executive.
Complicated programming model.
RTAI (Real-Time Application Interface) attempts to simplify.
Colleagues still have problems at > 18 kHz control period.
64 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Real-time operating systems
Embedded vs. real-time.
Dynamic memory allocation.
Schedulers: General-purpose vs. real-time.
Timers and clocks: Relationship with HW.
65 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Real-time operating systems
Interaction between HW and SW.
Rapid response to interrupts.
HW interface abstraction.
Interaction between different tasks.
Communication.
Synchronization.
Multitasking
Ideally fully preemptive.
Priority-based scheduling.
Fast context switching.
Support for real-time clock.
66 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
General-purpose OS stress
Good average-case behavior.
Providing many services.
Support for a large number of hardware devices.
67 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
RTOSs stress
Predictable service execution times.
Predictable scheduling.
Good worst-case behavior.
Low memory usage.
Speed.
Simplicity.
68 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Predictability
General-purpose computer architecture focuses on average-case.
Caches.
Prefetching.
Speculative execution.
Real-time embedded systems need predictability.
Disabling or locking caches is common.
Careful evaluation of worst-case is essential.
Specialized or static memory management common.
69 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
RTOS overview
Memorymanager
BasicIO
managerTask
IPC
ISRTimer
etc.
ABSMPEGencoding
Applications
RTOSservices
Communication
Micro−browser
Messagecomposer Database
Organizer
Tasks
Hardware
Other hardware
Network interface
Processor Memory
Timer
70 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Outline
1. Realtime systems
2. Rate Monotonic Scheduling
3. Real-time and embedded operating systems
4. Cyber-physical systems overview
5. Deadlines and announcements
71 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Cyber-physical systems
Computer systems involving interaction with the physical world.
Sensing →
Signal processing →
Analysis and control →
Actuation.
All tied together via models and hardware/software implementations.
72 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Cyber-physical systems disciplines
Modeling
and
specification
Embedded
system
design
Real−time
systems
Control
systems
Digital
signal
processing
Cyber−
physical
systems
Robotics
73 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Relationship with IoT
Substantial overlap.
IoT systems arguably needn’t involve control theory and actuation, althoughthey often do.
CPS need not involve slow, unreliable networks, although they often do.
74 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Outline
1. Realtime systems
2. Rate Monotonic Scheduling
3. Real-time and embedded operating systems
4. Cyber-physical systems overview
5. Deadlines and announcements
75 R. Dick EECS 507
Realtime systemsRate Monotonic Scheduling
Real-time and embedded operating systemsCyber-physical systems overview
Deadlines and announcements
Deadlines and announcements
18 February: L. Zhang, B. Tiwana, Z. Qian, Z. Wang, R. P. Dick, Z. M.Mao, and L. Yang, “Accurate online power estimation and automatic batterybehavior based power model generation for smartphones,” in Proc. Int. Conf.Hardware/Software Codesign and System Synthesis, Oct. 2010, pp. 105–114.
Deadline change: You can delay your project proposal revision from 12 to 15February if you need to speak with me first.
76 R. Dick EECS 507