Flight controller

Not schedulable

2 of 4 tasks miss their deadlines. The worst, radio link, is 1,600 µs late.

Tasks: 4
Utilisation: 54.0%
Missing: 2 of 4

Response against deadline

Each bar is the task’s worst-case response, drawn to the scale of its own deadline, so every deadline stands on the same line.

1health monitor2,000 µs18,000 µs to spare
2attitude loop2,300 µs1,300 µs late
3radio link3,600 µs1,600 µs late
4flight log8,500 µs41,500 µs to spare

Its own executionWaiting: preemption, blocking, jitterPast the deadline

What to do about it

Every deadline is met with the shortest deadline first:

attitude loop
radio link
health monitor
flight log

List the tasks in this order, highest priority first, and check again.

Every task

Highest priority first. Times in microseconds.

#	Task	Result	WCET	Period	Deadline	Response	Slack
1	health monitor	Meets	2,000	20,000	20,000	2,000	18,000
2	attitude loop	Misses	300	1,000	1,000	2,300	−1,300
3	radio link	Misses	400	5,000	2,000	3,600	−1,600
4	flight log	Meets	3,000	50,000	50,000	8,500	41,500

Utilisation 54.0%.

Method and assumptions

Response-time analysis over the level-i busy period (Lehoczky, 1990), with release jitter (Tindell, Burns and Wellings, 1994), in exact integer arithmetic. Engine: dy-wcet 4.1.6, open source; its answers are checked against an independent oracle, an exhaustive search of small task sets and a simulated scheduler, and eight bounded Kani proofs gate every change to it.

Fixed-priority preemptive scheduling on one processor core. Priority is the order of the tasks, highest first.
Execution times, jitter and blocking are inputs. DY-WCET Pro does not measure them; the verdict is as good as the numbers it is given.
Kernel overheads — context switches, interrupt entry, tick handling — are included in the execution times or blocking given.
Blocking is the longest time a task can wait for a lower-priority task holding a shared resource, as under the priority ceiling protocol.
Deadlines may be shorter or longer than periods. A response that runs past its period is analysed over the whole busy period.
Values that were not whole microseconds were rounded toward the safe side: execution, jitter and blocking up; periods and deadlines down.

Reproduce this report

Input: tasks.toml (TOML, 444 bytes)
SHA-256: 7fe467b30e38bfe6562d341218fb87b53ad5dc3909864666d40814ea18b4d75b
Tool: DY-WCET Pro 1.0.0
Engine: dy-wcet 4.1.6, open source
Command: dywcet report tasks.toml

The input, exactly as read. Its SHA-256 is the one above.

1# A flight controller listed by importance rather than by rate.
2# dywcet check finds the miss and the order that fixes it.
3
4name = "Flight controller"
5
6[[task]]
7name   = "health monitor"
8wcet   = "2 ms"
9period = "20 ms"
10
11[[task]]
12name   = "attitude loop"
13wcet   = "300 us"
14period = "1 ms"
15
16[[task]]
17name     = "radio link"
18wcet     = "400 us"
19period   = "5 ms"
20deadline = "2 ms"
21
22[[task]]
23name   = "flight log"
24wcet   = "3 ms"
25period = "50 ms"

The same input gives this report byte for byte: it carries no date and nothing random. The verdict is exactly as good as the execution times, periods and deadlines it was given.