Pith. sign in

REVIEW 4 major objections 6 minor 52 references

Boomerang: Real-Time I/O Meets Legacy Systems

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Boomerang guarantees end-to-end I/O delays for pipelines that span a real-time OS and legacy Linux, and its evaluation keeps measured delays inside the bounds.

desk verdict Solid systems paper extending tuned pipes across a partitioning hypervisor, but the end-to-end 'guarantee' rests on unvalidated pre-profiled WCETs and the ACRN comparison isn't clean; still deserves peer review. read the letter →

arxiv 1908.06807 v2 pith:A7IAHD5P submitted 2019-08-19 cs.OS

Ahmad Golchin , Soham Sinha , Richard West This is my paper · ORCID
classification cs.OS
keywords real-timeI/Opartitioninghypervisormixed-criticalitysystemscomposabletunedpipesend-to-enddelayguaranteesQuestRTOSLinuxSCHED_DEADLINECANbus
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Boomerang is an I/O system that claims to guarantee end-to-end processing delays for sensing, processing, and actuation paths whose tasks run partly in a custom real-time OS (Quest) and partly in a legacy Linux system. It does this by turning each pipeline stage into a tuned pipe whose CPU budget and period are chosen by a constraint solver so that the sum of periods along the longest path stays within the required end-to-end delay. The paper argues that this gives mixed-criticality systems a way to use Linux's drivers, libraries, and accelerators while keeping time-critical I/O on an RTOS that is spatially isolated from everything else. In experiments with two CAN-bus pipelines on an Up Squared board, Boomerang kept measured delays below the computed bounds, whereas a standalone Linux system using SCHED_DEADLINE reservations missed the bounds and dropped packets, and the ACRN partitioning hypervisor was less predictable still.

What carries the argument

The central object is the composable tuned pipe (tpipe): a pipeline stage bound to a VCPU with an automatically computed budget $C_i$ and period $T_i$, connected to other pipes through either Simpson's four-slot asynchronous buffers (for freshness without blocking) or FIFO ring buffers (for lossless, rate-matched communication). The load-bearing identity is the end-to-end delay bound: for the longest path $l$, $\sum_{i\in l} T_i \le \text{e2e delay}$, with throughput bounded by $\min_i \{m_i/T_i\}$ and four-slot loss bounded by $\max\{1 - T_p/T_c\}$. The solver adjusts periods and budgets, halving producer periods and doubling consumer budgets, until the path meets the bound and all VCPUs pass a schedulability test on their PCPUs.

What would settle it

Run the paper's CAN-bus pipelines on an Up Squared board while forcing one callback to exceed its profiled worst-case execution time, for example by using a slower USB device or injecting cache misses; if any packet's end-to-end delay goes above the sum of the tuned-pipe periods on its path, the guarantee as stated has failed.

Watch

Extended reading notes

Core claim

The paper's central claim is that composable tuned pipes can give end-to-end timing guarantees to I/O paths that cross the boundary between an RTOS and a non-real-time legacy OS. A tuned pipe is a VCPU with a budget $C_i$ and period $T_i$; for a pipeline, Boomerang's constraint solver sets these parameters so that the sum of the periods on the longest path is no larger than the required end-to-end delay, with buffers sized so that blocking is avoided, and with all VCPUs satisfying a schedulability test (RMS or EDF) on their assigned physical cores. Interrupt handling in the RTOS is charged to IO VCPUs tied to the Main VCPU that issued the I/O, so bottom-half handlers run at the priority of the task they serve; in the Linux guest, tasks run under SCHED_DEADLINE with interrupts demoted to lower priority. The paper reports that for two CAN-bus pipelines spanning Quest and Linux, measured end-to-end delays stayed within bounds (for example, a maximum of 9.57 ms against a 10 ms bound), loss stayed within the allowed 20 percent, and throughput matched arrival rates, while Linux-only pipelines frequently exceeded the bounds and lost 28 to 56 percent of packets.

Load-bearing premise

The end-to-end guarantee rests on each callback's worst-case execution time being known from pre-profiling; if a callback ever runs longer than its profiled budget on real hardware, the solver's CPU budgets are too small and the delay bound no longer holds.

Editorial extensions

If this is right

  • Mixed-criticality automotive and avionics systems can run safety-critical sensing and actuation on an RTOS while offloading rich services such as cameras, GPUs, and machine-learning libraries to Linux, without dedicating separate hardware.
  • A legacy OS can be made part of a hard real-time path if its tasks use reservation scheduling and its interrupts are demoted below task priority; the bottleneck is interrupt handling, not the OS itself.
  • Boomerang-style partitioning removes the hypervisor from runtime resource management, shrinking the trusted code base and avoiding VMExits during inter-guest communication.
  • Pipeline QoS specifications can express throughput, loss, and delay together: a four-slot pipeline tolerates known loss rates for sensor data, while a FIFO pipeline enforces lossless throughput.
  • The design extends to multiple-input, multiple-output pipelines, since the delay constraint is applied per longest path and the throughput constraint per bottleneck output.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The same composition mechanism should carry over to any legacy guest that offers reservation-based scheduling and lets interrupt handling be demoted or isolated; Windows or Android guests would be natural next targets, though the paper only demonstrates Linux.
  • Because the guarantee rests on profiled worst-case execution times, Boomerang would benefit from coupling each tpipe callback to a runtime enforcement mechanism such as budget exhaustion traps that convert a WCET violation into a detectable pipeline failure rather than a silent deadline miss.
  • The endpoint capability model left as future work could turn Boomerang into a substrate for secure information-flow control: if pipe connectivity is restricted by access policies, the same delay analysis would bound leakage channels, an idea the paper mentions but does not develop.
  • A testable extension is to use the same tuning equations with different schedulers, such as global EDF or partitioned EDF across many cores, and derive the analogous sum-of-periods bound; the paper's single-core-per-path analysis may understate the complexity on heterogeneous hardware.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper presents Boomerang, a partitioning hypervisor that co-locates the Quest RTOS and a Linux guest on separate cores of a multicore machine, partitioning CPU cores, memory, and I/O devices between the guests. The main contribution is a composable 'tuned pipe' abstraction: each pipeline stage is a callback bound to a VCPU or server with a budget C_i and period T_i, and a constraint solver sets these parameters from pre-profiled per-callback WCETs so that the sum of periods along the longest path is within a user-specified end-to-end delay, while throughput and loss requirements are handled for FIFO and four-slot buffering. The evaluation on an Up Squared board with CAN bus traffic compares Boomerang against standalone Linux using SCHED_DEADLINE and against the ACRN hypervisor, for asynchronous, synchronous (FIFO), and MIMO pipelines. The measurements show Boomerang staying within the computed delay bounds in the tested runs, while Linux SMP and ACRN do not.

Significance. If the end-to-end guarantees are taken as validated, Boomerang offers a useful integration point for mixed-criticality systems that need legacy Linux services alongside RTOS-timed I/O. The design strength is that the delay bound is computed a priori by the constraint solver and then checked by measurement, so the evaluation is a genuine check of the design rather than a post-hoc fit. The RTOS-side handling of interrupt bottom-halves via IO VCPUs addresses a real priority-inversion problem in Linux. However, the validity of the guarantee rests on pre-profiled WCETs, which are not shown to be safe upper bounds, and the Linux-side pipeline stage is subject to unmodeled interrupt interference. The ACRN comparison is also not apples-to-apples. These issues affect the central claims enough that revision is required, but the core ideas are defensible.

major comments (4)
  1. [Section III-A and III-E] The end-to-end guarantee is built on the assumption in Section III-A that each callback has a known worst-case execution time based on pre-profiled timing information, and Section III-E states that C_i is derived from this WCET. Profiling alone does not establish a worst-case bound: it cannot capture rare cache, TLB, or microarchitectural states or input-dependent path variations unless the profiling campaign exhaustively exercises them. Table I sets the tightest budgets at 0.1 ms, yet no per-callback execution-time measurements or profiling methodology are reported. If any callback occasionally exceeds C_i, the server throttles that pipe and the affected message is deferred to a later period, so the sum-of-periods bound in Section III-E is no longer valid. As written, the 'guarantee' is conditional on an unverified WCET bound; the paper should either provide evidence that the profiled values are safe upper bounds (for example, a measurement methodology with margins, or static WCET analysis) or soften the guarantee claim accordingly.
  2. [Section IV (setup) and Section II] Pipeline 1's Linux-side stage ProcData (τ4) runs on Core 1, where Section IV states that all device interrupts other than xHCI are redirected, and where 11 background tasks generate disk and network I/O. Section II explicitly conditions SCHED_DEADLINE scheduling guarantees on the absence of interrupt interference. The delay bound in Table I therefore does not account for interrupt-induced delays on the cross-guest path, which is exactly the path the paper claims as its principal new capability. The measurements show the bound is met in these runs, but a guarantee requires that the interference source be modeled or excluded; without that, the cross-guest delay claim is empirical rather than assured.
  3. [Section IV-B] The ACRN comparison is confounded: Boomerang and Linux SMP use Yocto Linux kernel 4.9.99 with PREEMPT_RT, while the ACRN SOS and UOS use ClearOS Linux kernel 4.19.73 (as recommended by the ACRN developers). The paragraph also states that Quest was intentionally not ported to ACRN. Because the compared systems differ in both the hypervisor and the guest OS, the observed latency differences cannot be attributed to Boomerang's design. The Abstract's claim that Boomerang 'outperforms' ACRN is not supported by a controlled comparison.
  4. [Section III-E] The bound stating that worst-case end-to-end delay equals the sum of the tuned-pipe periods is justified only by the special-case example in Figure 7, in which all tasks have the same service time and period. No proof is given for pipelines with different C_i/T_i, arbitrary phase offsets, multi-CPU paths, or mixed Quest/Linux scheduling. If the bound is intended as a formal guarantee, the authors should state the assumptions (e.g., each stage consumes at most one quantum per period, no release jitter, no scheduling overhead) and provide a concise derivation; otherwise the reader cannot verify the central claim for the general pipelines used in the evaluation.
minor comments (6)
  1. [Section III-B] The terms 'RT_ASYNC' and 'RT_FIFO' are introduced before the buffering modes are explained; consider defining them at first use.
  2. [Section III-E] In the toy example, the symbol T is used both for the number of tasks and the common period, which is confusing; use n for the number of tasks.
  3. [Section IV-A] The caption of Figures 10a and 10b contains a typo: 'show the the performance' should read 'show the performance'.
  4. [Section IV-A] End-to-end delay results are limited to the first 200 packets, and the claim that 'similar behavior was observed for more extensive runs' is not supported by data; consider showing a longer trace or a summary statistic.
  5. [Section IV-B] The statement 'As Boomerang already outperforms Linux SMP, it follows that ACRN's lack of timing predictability makes it inferior' is a non-sequitur; the ACRN comparison needs explicit data.
  6. [Section VI] The source-code release is promised as 'will be made available' at www.questos.org; if code is not available at the time of review, reproducibility would be strengthened by including the experimental configuration and raw data in a supplement.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the delay bound is a design-time sum of VCPU periods, and the measured end-to-end delays are an independent empirical check; the main caveat is the assumed pre-profiled WCET, which is a soundness assumption, not a circular fit.

full rationale

The paper's central derivation (Section III-E) sets each tuned pipe's budget C_i and period T_i via a constraint solver before execution, with C_i assumed equal to a pre-profiled WCET, and then defines the worst-case end-to-end delay as the sum of the T_i on the longest path. The evaluation (Section IV) measures packet round-trip delays and compares them against these pre-computed sums (e.g., Table II: Boomerang max 9.57 ms vs. 10 ms bound). Because the periods are selected before the measurements and are not fit to the measured delay curves, the measurements are a genuine validation rather than a renamed prediction. The paper does invoke the authors' own prior systems (Quest [8], Quest-V [10], tuned pipes [7]), but these are used as implementation infrastructure and background; the end-to-end delay argument is self-contained and does not reduce to those citations. The explicit assumption that each callback has a known WCET 'based on pre-profiled timing information' (Section III-A) and that 'Ci is derived by pre-profiling the WCET' (Section III-E) is a real soundness limitation: profiling is not proof of a worst-case bound, and if a callback overruns C_i the sum-of-periods guarantee can fail. However, that is an unsupported assumption about the environment, not a circular step: the derivation would be valid if the WCET bounds were true, and the evaluation is an independent test of the design. No equation in the paper is identical by construction to a fitted or measured output; the delay bound is not defined in terms of the measured delays. Accordingly, no circularity is present.

Assumptions & free parameters 2 free parameters · 8 assumptions · 0 invented entities

The central guarantee depends on the pre-profiled WCET being a true worst case, on standard real-time schedulability results, on the partition hypervisor providing true spatial isolation without runtime VMExits, on the four-slot and FIFO buffer models being accurate, and on Linux reservation scheduling behaving when interrupt handling is demoted. The per-pipe budgets and periods are configuration choices made by the constraint solver, not fitted constants. No new physical entities are introduced.

free parameters (2)
  • Per-tpipe budget C_i and period T_i = e.g., C=0.1ms, T=2ms for CanRead (Table I)
    Chosen by the constraint solver or set by hand for the evaluation; the delay bound is the sum of these T_i, so the guarantee is conditional on these values.
  • IO VCPU utilization bound U_IO = not specified
    Quest assigns a utilization bound U_IO to each device-class IO VCPU; the paper does not state its value, and the evaluation's schedule assumes it.
assumptions (8)
  • domain assumption Pre-profiled WCET values for each callback are safe upper bounds for all executions
    Section III-A/E: 'Boomerang assumes that Ci is derived by pre-profiling the WCET of the corresponding task function.' If WCET is underestimated, the delay guarantee fails.
  • standard math Sporadic Server VCPUs receive at least C units of execution every T when runnable if the schedulability test passes
    Section II-A, from Sprunt's Sporadic Server; this is a standard result.
  • standard math Rate-monotonic schedulability bound sum(C_i/T_i) <= n(2^{1/n}-1) and EDF bound sum(C_i/T_i) <= 1 apply to the VCPU set
    Section III-E, citing Liu & Layland; standard results.
  • domain assumption The partitioning hypervisor provides spatial isolation and no runtime VMExits during normal guest operation
    Section III: the hypervisor is only used for bootstrap and EPT setup; if this fails, guest interference breaks timing.
  • standard math Four-slot communication guarantees freshness and integrity without blocking
    Section III-B, citing Simpson's four-slot algorithm; a standard result.
  • domain assumption The loss-rate bound for four-slot pipelining is max(1 - T_p/T_c) for stages with T_c > T_p
    Section III-E; an analytic model assuming periodic arrivals and one message per period.
  • domain assumption FIFO buffers sized by the solver prevent blocking delays
    Section III-E condition 3; if rate matching fails or bursts exceed buffer space, the delay bound breaks.
  • domain assumption Linux SCHED_DEADLINE tasks receive their reserved CPU budgets if interrupts are demoted
    Section II, case 2: 'legacy OS tasks are isolated from timing unpredictability caused by interrupts' by demoting interrupts; the evaluation shows Linux alone fails without this isolation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Boomerang: Real-Time I/O Meets Legacy Systems." pith.science (2026). https://pith.science/paper/A7IAHD5P

@misc{pith2026190806807,
  author       = {Pith},
  title        = {Pith review of: Boomerang: Real-Time I/O Meets Legacy Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/A7IAHD5P}},
  note         = {Machine review of arXiv:1908.06807}
}
read the original abstract

This paper presents Boomerang, an I/O system that integrates a legacy non-real-time OS with one that is customized for timing-sensitive tasks. A relatively small RTOS benefits from the pre-existing libraries, drivers and services of the legacy system. Additionally, timing-critical tasks are isolated from less critical tasks by securely partitioning machine resources among the separate OSes. Boomerang guarantees end-to-end processing delays on input data that requires outputs to be generated within specific time bounds. We show how to construct composable task pipelines in Boomerang that combine functionality spanning a custom RTOS and a legacy Linux system. By dedicating time-critical I/O to the RTOS, we ensure that complementary services provided by Linux are sufficiently predictable to meet end-to-end service guarantees. While Boomerang benefits from spatial isolation, it also outperforms a standalone Linux system using deadline-based CPU reservations for pipeline tasks. We also show how Boomerang outperforms a virtualized system called ACRN, designed for automotive systems.

Figures

Figures reproduced from arXiv: 1908.06807 by the authors.

Figure 1
Figure 1. (a) Round-trip I/O in a single OS, and (b) possible [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. VCPU scheduling hierarchy in Quest [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. shows a logical representation of a single tuned pipe (a.k.a., tpipe). A pipe has one pipe processor and two endpoints, with one endpoint for input and the other for output. A pipe processor is represented by a VCPU, guaranteeing at least C units of execution time every T time units when runnable. Pipe processors are associated with tasks bound to Main VCPUs, or threaded interrupt handlers bound to I/O VCPUs [PITH_… view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: Example composition of a device and task pipe for [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: An example pipeline with multiple inputs & outputs [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Worst-case delay: Dintpipe1tpipe2Dout. The worst-case end-to-end delay is when each of the T − 2 tasks other than those for tpipe1 and tpipe2 run immediately after the data, Din, has arrived. Then, tpipe2 executes and processes old input data before tpipe1 is able t…
Figure 8
Figure 8. Figure 8: Boomerang experimental setup. and powertrain applications in a real vehicle. Each of these channels produced data at 20%, 30% and 40% of their 500kbps bandwidths, respectively. Channels 4 and 5 (CAN4-5) were replaced with Arduino UNOs [24] equipped with CAN shields, to…
Figure 9
Figure 9. Figure 9: End-to-end delay with no expected loss. As Linux is unable to achieve the same level of timing guarantees, even when tasks are guaranteed CPU reservations, there are some lost packets as observed by the missing data points in Figures 9a and 9b. Table II summarizes the …
Figure 10
Figure 10. Figure 10: End-to-end delay with 20% allowed loss. System Min (ms) Max (ms) Avg (ms) Loss (%) Pipeline 1 (Delay bound = 11 ms) Boomerang 0.64 10.96 4.87 3.5 Linux SMP 2.24 98.21 14.46 55 Pipeline 2 (Delay bound = 8.5 ms) Boomerang 0.64 2.38 1.07 0 Linux SMP 3.49 96.02 13.91 50 T…
Figure 11
Figure 11. Figure 11: Inter-sandbox communication in ACRN. The ACRN tuned pipe implementation uses a virtual net￾work bridge and tap devices for inter-sandbox communication [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: ACRN versus Linux SMP for asynchronous communica [PITH_FULL_IMAGE:figures/full_fig_p011_12.png]
Figure 13
Figure 13. Figure 13: FIFO buffered synchronous communication. [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 14
Figure 14. Figure 14: MIMO pipeline delay guarantees. V. RELATED WORK A. Operating Systems Mercer et al implemented processor capacity reserves in the Mach micro-kernel [12], to provide tasks with budgets and periods. Steere et al used a reservation-based scheme along with a feedback-based…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 52 canonical work pages

  1. [1]

    A Co mparison of Partitioning Operating Systems for Integrated Systems,

    R. O. Bernhard Leiner, Martin Schlager and B. Huber, “A Co mparison of Partitioning Operating Systems for Integrated Systems,” i n Proceedings of the 26th International Conference on Computer Safety, Re liability and Security (SAFECOMP) , Nuremberg, Germany, 18-21 September 2007

    work page 2007

  2. [2]

    Deterministic Architecture and Middlewa re for Domain Control Units and Simplified Integration Process Applied to ADAS,

    G. Niedrist, “Deterministic Architecture and Middlewa re for Domain Control Units and Simplified Integration Process Applied to ADAS,” 2016, https://www.tttech.com/technologies/adas

    work page 2016

  3. [3]

    LynxSecure Embedded Hypervisor and Separation Kernel, 2019, https://info.lynx.com/products/lynxsecure-programmable-processor- partitioning-system

    work page 2019

  4. [4]

    AUTOSAR, 2019, AUTomotive Open System ARchitecture – http://www.autosar.org

    work page 2019

  5. [5]

    Wind River Systems, August 2008, ARINC 653 - An Avionics S tandard for Safe, Partitioned Systems

    work page 2008

  6. [6]

    Jailhouse Partitionin g Hypervisor,

    Siemens Corporate Technology, “Jailhouse Partitionin g Hypervisor,” October 2014, https://github.com/siemens/jailhouse

    work page 2014

  7. [7]

    Tuned Pipes: End-to-E nd Through- put and Delay Guarantees for USB Devices,

    A. Golchin, Z. Cheng, and R. West, “Tuned Pipes: End-to-E nd Through- put and Delay Guarantees for USB Devices,” in Proceedings of the 39th IEEE Real-Time Systems Symposium (RTSS) , Dec 2018, pp. 196 – 207

    work page 2018

  8. [8]

    Virtual-CPU Scheduling in the Quest Operating System,

    M. Danish, Y . Li, and R. West, “Virtual-CPU Scheduling in the Quest Operating System,” in 2011 17th IEEE Real-Time and Embedded Technology and Applications Symposium . IEEE, 2011, pp. 169–179

    work page 2011

Show all 52 references
  1. [9]

    Process-Aware Interrupt Scheduli ng and Ac- counting,

    Y . Zhang and R. West, “Process-Aware Interrupt Scheduli ng and Ac- counting,” in Proceedings of the 27th IEEE International Real-Time Systems Symposium , ser. RTSS ’06. Washington, DC, USA: IEEE Computer Society, 2006, pp. 191–201

    2006

  2. [10]

    A Virtualize d Separation Kernel for Mixed-Criticality Systems,

    R. West, Y . Li, E. Missimer, and M. Danish, “A Virtualize d Separation Kernel for Mixed-Criticality Systems,” ACM Transactions on Computer Systems, vol. 34, no. 3, pp. 8:1–8:41, Jun. 2016

    2016

  3. [11]

    Loo k Mum, No VM Exits! (Almost),

    R. Ramsauer, J. Kiszka, D. Lohmann, and W. Mauerer, “Loo k Mum, No VM Exits! (Almost),” in Proceedings of the 13th W orkshop on Operating Systems Platforms for Embedded Real-time Applications (OS PERT), 2017

    2017

  4. [12]

    Processor Capac ity Reserves for Multimedia Operating Systems,

    C. W. Mercer, S. Savage, and H. Tokuda, “Processor Capac ity Reserves for Multimedia Operating Systems,” in Proceedings of the IEEE Inter- national Conference on Multimedia Computing and Systems , 1994

    1994

  5. [13]

    The Rate Monotonic Sch eduling Algorithm: Exact Characterization and Average Case Behavi or,

    J. Lehoczky, L. Sha, and Y . Ding, “The Rate Monotonic Sch eduling Algorithm: Exact Characterization and Average Case Behavi or,” in Proceedings of the IEEE Real-Time Systems Symposium (RTSS) , 1989

    1989

  6. [14]

    Scheduling Sporadic and Aperiodic Events i n a Hard Real- Time System,

    B. Sprunt, “Scheduling Sporadic and Aperiodic Events i n a Hard Real- Time System,” Software Engineering Institute, Carnegie Me llon, Tech. Rep., 1989

    1989

  7. [15]

    Scheduling Algorithms for M ultiprogram- ming in a Hard Real-Time Environment,

    C. L. Liu and J. W. Layland, “Scheduling Algorithms for M ultiprogram- ming in a Hard Real-Time Environment,” Journal of the ACM , vol. 20, no. 1, pp. 46–61, 1973

    1973

  8. [16]

    Four-slot Fully Asynchronous Communicat ion Mechan- ism,

    H. Simpson, “Four-slot Fully Asynchronous Communicat ion Mechan- ism,” IEEE Computers and Digital Techniques , vol. 137, pp. 17–30, January 1990

    1990

  9. [17]

    Commu- nication Centric Design in Complex Automotive Embedded Sys tems,

    A. Hamann, D. Dasari, S. Kramer, M. Pressler, and F. Wurs t, “Commu- nication Centric Design in Complex Automotive Embedded Sys tems,” in Proceedings of the 29th Euromicro Conference on Real-Time S ystems, Dagstuhl, Germany, 2017

    2017

  10. [18]

    ISO 26262-3: Road vehicles - Functional safety - P art 3: Concept phase ,

    ISO, “ISO 26262-3: Road vehicles - Functional safety - P art 3: Concept phase ,” 2011

    2011

  11. [19]

    Making information flow explicit in histar,

    N. Zeldovich, S. Boyd-Wickizer, E. Kohler, and D. Mazie res, “Making information flow explicit in histar,” in OSDI ’06: Proceedings of the second USENIX symposium on Operating systems design and imp le- mentation, 2006, pp. 263–278

    2006

  12. [20]

    Labels and Event Processes in the Asbestos Operating System,

    P . Efstathopoulos, M. Krohn, S. V anDeBogart, C. Frey, D . Ziegler, E. Kohler, D. Mazi` eres, F. Kaashoek, and R. Morris, “Labels and Event Processes in the Asbestos Operating System,” in SOSP ’05: Proceedings of the twentieth ACM symposium on Operating systems princip les. N...

    2005

  13. [21]

    Secure Computer System: U nified Exposition and Multics Interpretation,

    D. E. Bell and L. J. LaPadula, “Secure Computer System: U nified Exposition and Multics Interpretation,” Mitre Corporatio n, Bedford, MA, Tech. Rep. ESD-TR-75-306, March 1976

    1976

  14. [22]

    Model Checking Simpson’s Four-slot Fully A synchronous Communication Mechanism,

    J. Rushby, “Model Checking Simpson’s Four-slot Fully A synchronous Communication Mechanism,” Computer Science Laboratory–SRI Inter- national, Tech. Rep. Issued , 2002

    2002

  15. [23]

    Integrating Multimedia Appl ications in Hard Real-Time Systems,

    L. Abeni and G. Buttazzo, “Integrating Multimedia Appl ications in Hard Real-Time Systems,” in Proceedings of the 19th IEEE Real-time Systems Symposium, 1998, pp. 4–13

    1998

  16. [24]

    Arduino Homepage, 2019, http://arduino.cc

    2019

  17. [25]

    A Paravi rtualized Android for Next Generation Interactive Automotive System s,

    S. Sinha, A. Golchin, C. Einstein, and R. West, “A Paravi rtualized Android for Next Generation Interactive Automotive System s,” in Pro- ceedings of the 21st International W orkshop on Mobile Compu ting Systems and Applications (HotMobile 2020) , Austin, Texas, USA, March 3–4 2020

    2020

  18. [26]

    A Feedback-driven Proportion Allocator for Real-rate Sch eduling,

    D. C. Steere, A. Goel, J. Gruenberg, D. McNamee, C. Pu, an d J. Walpole, “A Feedback-driven Proportion Allocator for Real-rate Sch eduling,” in Proceedings of the Third Symposium on Operating Systems Des ign and Implementation, ser. OSDI ’99. USENIX Association, 1999, pp. 145–...

    1999

  19. [27]

    PREEMPT RT, 2019, https://rt.wiki.kernel.org/index.php/Main Page

    2019

  20. [28]

    SCHED DEADLINE Policy,

    Linux, “SCHED DEADLINE Policy,” 2019, https://www.kernel.org/doc/Documentation/scheduler/sched- deadline.txt

    2019

  21. [29]

    LitmusRT : A Testbed for Empirically Comparing Real- time Multiprocessor Schedulers,

    J. M. Calandrino, H. Leontyev, A. Block, U. C. Devi, and J . H. Anderson, “ LitmusRT : A Testbed for Empirically Comparing Real- time Multiprocessor Schedulers,” in 2006 27th IEEE International Real- Time Systems Symposium (RTSS’06) . IEEE, 2006, pp. 111–126

    2006

  22. [30]

    VxWorks, 2019, https://www.windriver.com/products /vxworks/

    2019

  23. [31]

    MERT-A Multi-environment Re al-time Operating System,

    D. Bayer and H. Lycklama, “MERT-A Multi-environment Re al-time Operating System,” in ACM SIGOPS Operating Systems Review , vol. 9, no. 5. ACM, 1975, pp. 33–42

    1975

  24. [32]

    J. J. Labrosse, MicroC/OS-II: The Real Time Kernel . CRC Press, 2002

    2002

  25. [33]

    Y odaiken, The RT Linux Manifesto , 1999

    V . Y odaiken, The RT Linux Manifesto , 1999

    1999

  26. [34]

    Wind River Systems, 2019, https://www.windriver.com/products/linux/

    2019

  27. [35]

    Linux Real Time Applicatio n Interface (RTAI) in Low Cost High Performance Motion Control,

    L. Dozio and P . Mantegazza, “Linux Real Time Applicatio n Interface (RTAI) in Low Cost High Performance Motion Control,” Motion Con- trol, vol. 2003, no. 1, pp. 1–15, 2003

    2003

  28. [36]

    Xenomai, Last Released: 2018, https://xenomai.org/

    2018

  29. [37]

    cfsLinux,

    NASA, “cfsLinux,” 2019, https://cfs.gsfc.nasa.gov/

    2019

  30. [38]

    Embedded Configurable Operating System,

    eCos, “Embedded Configurable Operating System,” http://ecos.sourceware.org/, 2019

    2019

  31. [39]

    OAR Corporation, “ RTEMS,” Last Release: 2016, https://www.rtems.org/

    2016

  32. [40]

    FreeRTOS,

    Real Time Engineers Ltd., “FreeRTOS,” 2019, https://w ww.freertos.org/

    2019

  33. [41]

    Wind River Hypervisor,

    W. R. Systems, “Wind River Hypervisor,” 2019, https://www.windriver.com/products/operating-systems/virtualization/

    2019

  34. [42]

    Mentor Embedded Hypervisor,

    Mentor, “Mentor Embedded Hypervisor,” 2019, https://www.mentor.com/embedded-software/hypervisor/

    2019

  35. [43]

    eVM for Windows,

    Tenasys, “eVM for Windows,” 2019, https://www.tenasys.com/products/evm-for-windows/

    2019

  36. [44]

    Xtratum : a Hyper- visor for Safety Critical Embedded Systems,

    M. Masmano, I. Ripoll, A. Crespo, and J. Metge, “Xtratum : a Hyper- visor for Safety Critical Embedded Systems,” in 11th Real-Time Linux W orkshop. Citeseer, 2009, pp. 263–272

    2009

  37. [45]

    RT-Xen: Towards Rea l-time Hypervisor Scheduling in Xen,

    S. Xi, J. Wilson, C. Lu, and C. Gill, “RT-Xen: Towards Rea l-time Hypervisor Scheduling in Xen,” in Proceedings of the ninth ACM international conference on Embedded software . ACM, 2011, pp. 39– 48

    2011

  38. [46]

    Xen and the Art of Virtualiz ation,

    P . Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neuge- bauer, I. Pratt, and A. Warfield, “Xen and the Art of Virtualiz ation,” in ACM SIGOPS operating systems review , vol. 37, no. 5. ACM, 2003, pp. 164–177

    2003

  39. [47]

    The Design and V erification of Secure System s,

    J. Rushby, “The Design and V erification of Secure System s,” in Eighth ACM Symposium on Operating System Principles (SOSP) , Asilomar, CA, Dec. 1981, pp. 12–21, (ACM Operating Systems Review , V ol. 15, No. 5)

    1981

  40. [48]

    SYSGO, “PikeOS,” Last release: V ersion 4.2, April 2017 , http://www.sysgo.com/products/pikeos-rtos-and-virtualization-concept

    2017

  41. [49]

    Muen - An x86/64 Separ ation Kernel for High Assurance,

    R. Buerki and A.-K. Rueegsegger, “Muen - An x86/64 Separ ation Kernel for High Assurance,” University of Applied Sciences Rapperswil (HSR), Tech. Rep, 2013

    2013

  42. [50]

    Project ACRN, 2019, https://projectacrn.org/

    2019

  43. [51]

    Making Paths Explicit in the Scout Operating System,

    D. Mosberger and L. L. Peterson, “Making Paths Explicit in the Scout Operating System,” in Proceedings of the Second USENIX Symposium on Operating Systems Design and Implementation , ser. OSDI ’96. New Y ork, NY , USA: ACM, 1996, pp. 153–167

    1996

  44. [52]

    RAD– FLOWS: Buffering For Predictable Communication,

    R. Pineiro, K. Ioannidou, S. A. Brandt, and C. Maltzahn, “RAD– FLOWS: Buffering For Predictable Communication,” in Proceedings of the 17th IEEE Real-Time and Embedded Technology and Applica tions Symposium, April 2011, pp. 23–33. 13

    2011

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.