Pith. sign in

REVIEW 2 major objections 7 minor 46 references

ROSGuard: A Bandwidth Regulation Mechanism for ROS2-based Applications

T0 review · 2 major / 7 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read ROSGuard brings memory-bandwidth regulation to ordinary ROS2 systems.

desk verdict A genuinely new ROS2-level bandwidth regulation mechanism with a useful feasibility study, but the headline parity claim with specialized approaches rests on a zero-traffic assumption that is asserted, not measured. read the letter →

arxiv 2506.04640 v1 pith:Z7XHOEB3 submitted 2025-06-05 cs.AR

Jon Altonaga Puente , Enrico Mezzetti , Irune Agirre Troncoso , Jaume Abella Ferrer , Francisco J. Cazorla Almeida This is my paper
classification cs.AR
keywords ROS2memorybandwidthregulationmulticoretiminginterferencereal-timesystemsperformancemonitoringcountersmiddlewarecallbackprioritiesNVIDIAJetsonAGXOrin
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

The paper tries to show that the problem of multicore memory interference, usually attacked with specialized hardware or OS mechanisms operating at microsecond granularity, can be handled well enough inside the ROS2 middleware on a generic Linux stack. It presents ROSGuard, a set of cooperating ROS2 node archetypes that sample hardware performance counters on non-critical nodes and throttle those nodes when their memory traffic exceeds a configurable budget. On an NVIDIA Jetson AGX Orin, with both synthetic stress workloads and real vision benchmarks, critical nodes run close to their isolated execution time while non-critical nodes suffer only modest slowdown. The payoff is that a broad class of productized ROS2 applications with looser timing requirements can get interference protection without specialized platform support.

What carries the argument

The load-bearing mechanism is a priority-driven callback hierarchy inside each regulated ROS2 node. By mapping distinct callbacks to dedicated executors and OS threads with different SCHED_FIFO priorities on the same core, ROSGuard creates a high-priority state-control callback that can always preempt the node's nominal callback and switch it between normal, sampling, and throttling states. In the throttle state, a second-highest-priority callback runs an idle loop that blocks the nominal and sampling callbacks, stopping the core's memory traffic; a separate controller node on a dedicated core compares accumulated bandwidth against a setpoint and issues replenish commands at the end of each regulation window.

What would settle it

Run the same ROSGuard setup with an additional unrelated high-priority thread on the regulated core, or with a ROS2 executor that does not honor the documented callback-to-thread mapping, and measure the critical node's slowdown: if the critical node's slowdown approaches the unregulated contention case, or if activation delay grows beyond the regulation period, the preemption assumption fails.

Watch

Extended reading notes

Core claim

The central claim is that fine-grained, microsecond-level regulation is not the right fit for ROS2-based systems, and that a middleware-level regulator working at millisecond periods can be nearly as effective in protecting critical nodes. ROSGuard achieves this with a controller node that monitors last-level-cache events, either by having non-critical nodes sample and publish their own performance counters or by polling them externally, and with a throttle callback that preempts the non-critical node's nominal work so the core stops issuing memory requests. The paper reports activation delays below 200 µs for self-sampling and below 100 µs for external sampling, and slowdown results on SD-VBS workloads that are comparable to published MemGuard results when configured with similar regulation periods.

Load-bearing premise

The mechanism assumes that mapping each callback to its own executor and OS thread with SCHED_FIFO priorities reliably preempts the nominal callback, so a throttle command actually stops the core's memory requests.

Editorial extensions

If this is right

  • ROS2 applications on a generic Linux distribution can receive memory interference protection without hypervisor, hardware QoS, or real-time kernel modifications.
  • Millisecond-level sampling and regulation periods, which are a poor fit for hard real-time systems, are sufficient for the timing requirements of many production ROS2 workloads.
  • Because the regulator is expressed as ROS2 nodes, executors, and topics, it can be added to existing ROS2 architectures and reconfigured per node without platform-specific code.
  • External sampling removes the sampling overhead from the regulated node and reacts faster, making it the better default for bandwidth-hungry non-critical workloads.

Reading between the lines

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

  • If the preemption assumption holds across ROS2 executor implementations, the same callback-priority pattern could regulate other shared resources by swapping the sampled hardware event.
  • The millisecond granularity leaves a window of contention before throttle engages, so the approach is better suited to protecting applications with slack than to enforcing hard deadlines; tighter setpoints or admission control would be needed for the latter.
  • The comparison with MemGuard is across different platforms with different total bandwidth, so 'comparable' should be read as qualitative; a same-platform head-to-head would be needed to quantify the gap.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 7 minor

Summary. The paper presents ROSGuard, a memory-bandwidth regulation mechanism implemented entirely at the ROS2 middleware level on a generic Linux stack. A dedicated controller node monitors PMC-based bandwidth estimates from non-critical (regulated) cores through either self-sampling (the nRT node publishes PMC values) or external sampling (the controller polls the PMU), and on threshold exceedance triggers a high-priority throttle callback that preempts the nominal callback on the offending core. This is realized by mapping ROS2 callback groups and executors to dedicated pthreads with SCHED_FIFO priorities and core affinities. The evaluation, on an NVIDIA Jetson AGX Orin with Isolbench and SD-VBS benchmarks, measures sampling overhead, activation delay, sensitivity to bandwidth threshold and regulation period, and compares slowdown ratios with published MemGuard results. The central claim is that ROSGuard achieves effectiveness comparable to specialized mechanisms such as MemGuard at millisecond-level granularity while being far more portable.

Significance. ROSGuard addresses a relevant gap: interference mitigation for productized ROS2 applications on mainstream Linux, where specialized hardware or OS support is typically unavailable. The design is clean, modular, and configurable, and the experimental campaign is unusually broad, varying sampling mode (self vs. external), sampling period, regulation period, bandwidth threshold, and benchmark pairs, while reporting both RT protection and nRT slowdown. The authors are appropriately cautious in several places, explicitly acknowledging that the MemGuard comparison is 'not totally fair' and that overheads are configuration dependent. If the central parity claim were convincingly supported, the contribution would be a useful, portable alternative for a wide class of systems. However, the current evidence does not yet fully support the headline claim for the specific reasons detailed below.

major comments (2)
  1. [Section III-B.3] The claim that a core running the THR callback generates 'no request ... on any shared hardware resource' is the load-bearing premise of the whole mechanism, but it is never verified by measurement. The THR callback is an idle loop: it still performs instruction fetches, may touch stack and data, and dirty cache lines left by the preempted NCT callback can be evicted and written back during the throttle interval. Hardware prefetchers and in-flight memory requests may also not be canceled by SCHED_FIFO preemption. The paper reports activation delay (Section IV-C) and slowdowns (Sections IV-D through IV-F), but no experiment measures L3 miss traffic, DRAM read/write requests, or memory-controller occupancy on the throttled core. Without that measurement (e.g., using memory-controller PMCs or a co-running traffic probe), the central parity claim with MemGuard/MemCore, which halt cores at a lower level, is unsupported.
  2. [Section IV-F, Figure 16] The only quantitative evidence for the abstract's 'comparable effectiveness' claim is Figure 16, which compares ROSGuard slowdowns with a MemGuard implementation reported in [8] on a different platform under different total available bandwidth. The authors themselves state that the comparison is 'not totally fair' and acknowledge that the apparent improvements for disparity and mser are 'probably justified by the overhead being compensated by a higher available bandwidth on the AGX Orin.' As presented, the figure does not support parity, because a higher-bandwidth platform can mask degradation that would appear on the reference platform. The central claim should either be substantiated with a same-platform or bandwidth-normalized comparison, or softened to a more modest claim of providing qualitatively similar protection with substantially higher portability.
minor comments (7)
  1. [Section IV-A, Table I] The benchmark characterization table is not labeled 'TABLE I' and is referenced as 'Table IV-A' in the text; it should be numbered and cited consistently.
  2. [Section IV-F] In the paragraph discussing Isolbench results, 'bandwidth_read, and bandwidth_read' repeats the first benchmark; the second occurrence should be 'bandwidth_write.'
  3. [Abstract] 'widespreadedly adopted' should be 'widely adopted.'
  4. [Section II-A] The author name 'Krounaer et al.' should be 'Kronauer et al.'
  5. [Section IV-D] The word 'benchamrks' is a typo for 'benchmarks.'
  6. [Section IV-B] The sentence 'a slowdown-ratio of 1.059% indicates an absolute increase of 59µs per ms' mixes a ratio and a percentage; Figure 7 plots a ratio near 1.059, so '1.059%' should be rephrased, for example as 'a 5.9% slowdown' or 'a slowdown ratio of 1.059.'
  7. [Section IV-D] The paper should report the absolute bandwidth reference values corresponding to the 15%, 20%, and 30% thresholds, since the thresholds are derived from per-benchmark maxima and the values are needed to reproduce and transfer the results across platforms.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: ROSGuard's 'comparable effectiveness' claim rests on measured slowdown ratios against isolation baselines; the empirically calibrated bandwidth thresholds are openly varied sensitivity knobs, the MemGuard comparison is self-admittedly imperfect, and the paper's self-citations are contextual rather than load-bearing.

full rationale

ROSGuard is a system evaluation paper, not a derivation paper: its central claims of 'comparable effectiveness to specialized, finer-grained state-of-the-art solutions' and effective protection of critical nodes are supported by measured slowdown ratios (Figures 10-16) relative to isolation baselines, not by equations derived from its own inputs. The bandwidth metric (Eq. 1, Section IV-A) is a standard PMU-to-bandwidth conversion (bytes per second from l3_accesses and cycles) that is independent of the claimed outcome. The only fitted element is the bandwidth-threshold setpoint, which Section IV-D reports was 'empirically derived from observing the total measurable bandwidth with the most memory demanding benchmarks'; however, thresholds are employed as an openly varied configuration knob across a wide range (5%-30%, and then 20/30/40% to match MemGuard's published configuration), and the paper honestly documents the saturation regime (bandwidth_read at 30%) where protection degrades, so the setpoint does not force the headline result. The comparison to MemGuard (Figure 16) is made on a different platform with different available bandwidth, an unfairness the authors explicitly concede ('the comparison with MemGuard is not totally fair as results heavily depend on the total available bandwidth in the target'); this weakens the comparison's validity but is not circularity, since the reported ROSGuard values are measured rather than derived. The load-bearing premise in Section III-B.3 that a throttled core emits 'no request... on any shared hardware resource' is asserted rather than measured, and residual idle-loop traffic, cache write-backs, and in-flight memory requests could violate it; this is a correctness and validation gap, not a self-referential reduction. The paper's self-citations ([1], [34], [36]) to a safety-critical multicore survey and to the authors' earlier hardware-QoS mechanisms are contextual related-work support, are externally published and falsifiable, and do not carry the central argument. No equation in the paper reduces to its inputs by construction, and no fitted parameter is renamed as a prediction.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new physical or conceptual entity; it is a software system built from existing ROS2 and Linux abstractions. The load-bearing assumptions are about the reliability of the callback-preemption mechanism, the accuracy of the PMU-based bandwidth proxy, and the completeness of core isolation.

free parameters (3)
  • Bandwidth threshold setpoint = 15%, 20%, 30%, 40% of empirically measured total bandwidth
    Reference values empirically derived from observing the total measurable bandwidth with the most memory-demanding benchmarks (Section IV-D); used to trigger throttling and directly affect reported slowdowns.
  • PMC sampling period = 100 to 1000 microseconds across experiments
    Chosen by the authors to explore trade-offs; sensitivity is evaluated in Sections IV-B and IV-D, but the central claims depend on this hand-chosen parameter.
  • Regulation period = 1 to 5 milliseconds across experiments
    Chosen relative to benchmark execution times; Section IV-E evaluates the impact, but the reported effectiveness is configuration-dependent.
assumptions (3)
  • domain assumption ROS2 executor-to-OS-thread mapping with pthread priorities ensures deterministic preemption of callbacks.
    Design relies on a high-priority THR callback preempting the nominal callback to halt memory traffic (Sections III-B and III-C). If ROS2 or the OS scheduler does not honor this mapping, throttling fails.
  • domain assumption perf and PMU events provide an accurate proxy for memory bandwidth, using L2 misses / L3 accesses with 64-byte cache lines.
    The bandwidth metric in Eq. 1 assumes l3_accesses/cycles times frequency times 64 bytes estimates actual DRAM bandwidth; PMU event semantics and cache-hierarchy assumptions are not validated against direct DRAM counters.
  • domain assumption Core isolation and irq mapping remove all other memory-generating activity on regulated cores.
    Kernel parameters for core isolation and irq mapping are configured (Section IV-A); the throttling claim that 'no request will be generated by those cores' relies on this being complete.

how reviews work

0 comments
Cite this review

Pith. "Pith review of ROSGuard: A Bandwidth Regulation Mechanism for ROS2-based Applications." pith.science (2026). https://pith.science/paper/Z7XHOEB3

@misc{pith2026250604640,
  author       = {Pith},
  title        = {Pith review of: ROSGuard: A Bandwidth Regulation Mechanism for ROS2-based Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Z7XHOEB3}},
  note         = {Machine review of arXiv:2506.04640}
}
read the original abstract

Multicore timing interference, arising when multiple requests contend for the same shared hardware resources, is a primary concern for timing verification and validation of time-critical applications. Bandwidth control and regulation approaches have been proposed in the literature as an effective method to monitor and limit the impact of timing interference at run time. These approaches seek for fine-grained control of the bandwidth consumption (at the microsecond level) to meet stringent timing requirements on embedded critical systems. Such granularity and configurations, while effective, can become an entry barrier for the application of bandwidth control to a wide class of productized, modular ROS2 applications. This is so because those applications have less stringent timing requirements but would still benefit from bandwidth regulation, though under less restrictive, and therefore more portable, granularity and configurations. In this work, we provide ROSGuard, a highly-portable, modular implementation of a timing interference monitoring and control mechanism that builds on the abstractions available on top of a generic and portable Linux-based software stack with the Robotic Operating System 2 (ROS2) layer, a widespreadedly adopted middleware for a wide class of industrial applications, far beyond the robotic domain. We deploy ROSGuard on an NVIDIA AGX Orin platform as a representative target for functionally rich distributed AI-based applications and a set of synthetic and real-world benchmarks. We apply an effective bandwidth regulation scheme on ROS2-based applications and achieve comparable effectiveness to specialized, finer-grained state-of-the-art solutions.

Figures

Figures reproduced from arXiv: 2506.04640 by the authors.

Figure 1
Figure 1. Relation among ROS2 elements and OS-level threads, exploited in [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Overview of the ROSGuard components. The red arrows indicate control-actions. The green arrows indicate the feedback-loop. III. ROS2-BASED BANDWIDTH REGULATION SCHEME ROSGuard deploys a fully-functional bandwidth regulation solution on top of the ROS2 middleware, with enhanced portability and modularity. The overall mechanism is con￾sistent with state-of-the-art bandwidth regulation approaches (e.g., [9]) and aims a… view at source ↗
Figure 3
Figure 3. Minimal ROSGuard setup. logic is applied, the metric considered for the regulation is assessed against the predefined setpoint. If such value is exceeded, the control module signals the corresponding (non-critical) cores to stop consuming further bandwidth. We evaluate the effect of setpoint selection in Section IV-D. ROSGuard regulation logic can be applied on configurable timing intervals so that inhibition of nRT… view at source ↗
Figures from the paper (9 more)
Figure 5
Figure 5. Figure 5: Architecture of one CPU cluster in the NVIDIA Jetson AGX Orin. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 7
Figure 7. Figure 7: Impact of sampling the PMU on the execution-time overhead of an [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]
Figure 6
Figure 6. Figure 6: Distribution of the duration of the PMC callback. The plot shows the minimum (▽), maximum (△), and median (×) value for each sampling period. input datasets for the applications come in a variety of sizes. We use the vga resolution datasets so the working sets fit in t…
Figure 8
Figure 8. Figure 8: Distribution of the activation delay, i.e. the time measured from [PITH_FULL_IMAGE:figures/full_fig_p009_8.png]
Figure 10
Figure 10. Figure 10: Slowdown ratios for two instances of bandwidth_read, measured when scheduled to run in parallel, at various bandwidth-thresholds. Sampling period and regulation period set to 1 and 5 ms, respectively. Monolithic regulation is reported as a reference. 1 1.2 1.4 1.6 1.8…
Figure 14
Figure 14. Figure 14: Slowdown ratios for two instances of bandwidth_read, measured when scheduled to run in parallel, with interval-based regulation at 30 %. The sampling period is set to 500 µs. on ROSGuard self-sampling configuration, as it is the bottom line in terms of nRT nodes’ over…
Figure 12
Figure 12. Figure 12: Slowdown ratios suffered by mser when deployed as nRT application, in parallel with another instance of mser as RT node at various bandwidth￾thresholds, varying the sampling periods. 1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 2 0100020003000400050006000 Slowdown (ratio) Re…
Figure 15
Figure 15. Figure 15: Slowdown ratios measured when running various benchmark combinations with interval-based regulation at [PITH_FULL_IMAGE:figures/full_fig_p011_15.png]
Figure 16
Figure 16. Figure 16: Comparison of slowdown ratios to those reported for the [PITH_FULL_IMAGE:figures/full_fig_p011_16.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

46 extracted references · 43 canonical work pages

  1. [8]

    Coherence-Aided Memory Bandwidth Regulation ,

    I. Izhbirdeev, D. Hoornaert, W. Chen, A. Zuepke, Y . Hammad, M. Caccamo, and R. Mancuso, “ Coherence-Aided Memory Bandwidth Regulation ,” in2024 IEEE Real-Time Systems Symposium (RTSS). Los Alamitos, CA, USA: IEEE Computer Society, Dec. 2024, pp. 322–335. [Online]. Available: https://doi.ieeecomputersociety.org/10. 1109/RTSS62706.2024.00035

    arXiv 2024

  2. [1]

    Multi-core devices for safety- critical systems: A survey,

    J. Pérez-Cerrolaza, R. Obermaisser, J. Abella, F. J. Cazorla, K. Grüttner, I. Agirre, H. Ahmadian, and I. Allende, “Multi-core devices for safety- critical systems: A survey,”ACM Comput. Surv., vol. 53, no. 4, pp. 79:1–79:38, 2020

    work page 2020

  3. [2]

    Impact, challenges and prospect of software-defined vehicles,

    Z. Liu, W. Zhang, and F. Zhao, “Impact, challenges and prospect of software-defined vehicles,”Automotive Innovation, vol. 5, no. 2, pp. 180–194, 2022

    work page 2022

  4. [3]

    Embedded systems: Many cores - many problems,

    R. Wilhelm and J. Reineke, “Embedded systems: Many cores - many problems,” in7th IEEE International Symposium on Industrial Embedded Systems, SIES 2012, Karlsruhe, Germany, June 20-22, 2012. IEEE, 2012, pp. 176–180. [Online]. Available: https://doi.org/10.1109/SIES.2012.6356583

    work page arXiv 2012

  5. [4]

    Analysis of memory-contention in heterogeneous COTS mpsocs,

    M. Hassan and R. Pellizzoni, “Analysis of memory-contention in heterogeneous COTS mpsocs,” in32nd Euromicro Conference on Real-Time Systems, ECRTS 2020, July 7-10, 2020, Virtual Conference, ser. LIPIcs, M. Völp, Ed., vol. 165. Schloss Dagstuhl - Leibniz- Zentrum für Informatik, 2020, pp. 23:1–23:24. [Online]. Available: https://doi.org/10.4230/LIPIcs.ECRT...

    work page doi:10.4230/lipics.ecrts.2020.23 2020

  6. [5]

    Denial-of-service attacks on shared cache in multicore: Analysis and prevention,

    M. Bechtel and H. Yun, “Denial-of-service attacks on shared cache in multicore: Analysis and prevention,” in2019 IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), 2019, pp. 357–367

    work page 2019

  7. [6]

    Memguard: Memory bandwidth reservation system for efficient performance iso- lation in multi-core platforms,

    H. Yun, G. Yao, R. Pellizzoni, M. Caccamo, and L. Sha, “Memguard: Memory bandwidth reservation system for efficient performance iso- lation in multi-core platforms,” in2013 IEEE 19th Real-Time and Embedded Technology and Applications Symposium (RTAS), 2013, pp. 55–64

    work page 2013

  8. [7]

    Memory bandwidth management for efficient performance isola- tion in multi-core platforms,

    ——, “Memory bandwidth management for efficient performance isola- tion in multi-core platforms,”IEEE Transactions on Computers, vol. 65, no. 2, pp. 562–576, 2016

    work page 2016

Show all 46 references
  1. [9]

    Mem- pol: Policing core memory bandwidth from outside of the cores,

    A. Zuepke, A. Bastoni, W. Chen, M. Caccamo, and R. Mancuso, “Mem- pol: Policing core memory bandwidth from outside of the cores,” in 2023 IEEE 29th Real-Time and Embedded Technology and Applications Symposium (RTAS), 2023, pp. 235–248

    2023

  2. [10]

    H-MBR: Hypervisor-Level Memory Bandwidth Reservation for Mixed Criticality Systems,

    A. Oliveira, D. Costa, G. Moreira, J. Martins, and S. Pinto, “H-MBR: Hypervisor-Level Memory Bandwidth Reservation for Mixed Criticality Systems,” inSixth Workshop on Next Generation Real-Time Embedded Systems (NG-RES 2025), ser. Open Access Series in Informatics (OASIcs), P. ...

    2025 doi

  3. [11]

    SP- IMPact: A Framework for Static Partitioning Interference Mitigation and Performance Analysis,

    D. Costa, G. Moreira, A. Oliveira, J. Martins, and S. Pinto, “SP- IMPact: A Framework for Static Partitioning Interference Mitigation and Performance Analysis,” inSixth Workshop on Next Generation Real-Time Embedded Systems (NG-RES 2025), ser. Open Access Series in Informatics...

    2025

  4. [12]

    Bandwatch: A system-wide memory bandwidth regulation system for heterogeneous multicore,

    E. Seals, M. G. Bechtel, and H. Yun, “Bandwatch: A system-wide memory bandwidth regulation system for heterogeneous multicore,” in29th IEEE International Conference on Embedded and Real-Time Computing Systems and Applications, RTCSA 2023, Niigata, Japan, August 30 - Sept. 1, 2...

    2023

  5. [13]

    Memory Latency Distribution-Driven Regulation for Temporal Isolation in MPSoCs,

    A. Saeed, D. Hoornaert, D. Dasari, D. Ziegenbein, D. Mueller- Gritschneder, U. Schlichtmann, A. Gerstlauer, and R. Mancuso, “Memory Latency Distribution-Driven Regulation for Temporal Isolation in MPSoCs,” in35th Euromicro Conference on Real-Time Systems (ECRTS 2023), ser. Lei...

    2023

  6. [14]

    Analyzing arm’s MPAM from the perspective of time predictability,

    M. Zini, D. Casini, and A. Biondi, “Analyzing arm’s MPAM from the perspective of time predictability,”IEEE Trans. Computers, vol. 72, no. 1, pp. 168–182, 2023. [Online]. Available: https: //doi.org/10.1109/TC.2022.3202720

    2023

  7. [15]

    White paper: Solving Multicore Interfer- ence for Safety Critical Applications,

    GreenHills Software, “White paper: Solving Multicore Interfer- ence for Safety Critical Applications,” https://www.ghs.com/download/ whitepapers/GHS_multicore_interference.pdf, 2021

    2021

  8. [16]

    Supporting temporal and spatial isolation in a hypervisor for arm multicore platforms,

    P. Modica, A. Biondi, G. Buttazzo, and A. Patel, “Supporting temporal and spatial isolation in a hypervisor for arm multicore platforms,” in IEEE International Conference on Industrial Technology (ICIT), 02 2018, pp. 1651–1657

    2018

  9. [17]

    Robotic Operating System (ROS) version 2

    “Robotic Operating System (ROS) version 2.” https://www.ros.org/, 2025

    2025

  10. [18]

    Invited Paper: On the Granularity of Bandwidth Regulation in FPGA-Based Heterogeneous Systems on Chip,

    G. Brilli, G. Valente, A. Capotondi, T. Di Mascio, and A. Marongiu, “Invited Paper: On the Granularity of Bandwidth Regulation in FPGA-Based Heterogeneous Systems on Chip,” in22nd International Workshop on Worst-Case Execution Time Analysis (WCET 2024), ser. Open Access Series...

    2024 doi

  11. [19]

    Robot operating system 2: Design, architecture, and uses in the wild,

    S. Macenski, T. Foote, B. Gerkey, C. Lalancette, and W. Woodall, “Robot operating system 2: Design, architecture, and uses in the wild,” Science Robotics, vol. 7, no. 66, p. eabm6074, 2022. [Online]. Available: https://www.science.org/doi/abs/10.1126/scirobotics.abm6074

    2022 doi

  12. [20]

    Shrinking pomcp: A framework for real-time uav search and rescue,

    Y . Zhang, B. Luo, A. Mukhopadhyay, D. Stojcsics, D. Elenius, A. Roy, S. Jha, M. Maroti, X. Koutsoukos, G. Karsai, and A. Dubey, “Shrinking pomcp: A framework for real-time uav search and rescue,” 11 2024

    2024

  13. [21]

    Real-time performance moni- toring of a cnc milling machine using ros 2 and aws iot towards industry 4.0,

    D. Patel, C. Maiti, and S. Muthuswamy, “Real-time performance moni- toring of a cnc milling machine using ros 2 and aws iot towards industry 4.0,” inIEEE EUROCON 2023 - 20th International Conference on Smart Technologies, 2023, pp. 776–781. 12

    2023

  14. [22]

    Ros 2 in a nutshell: A survey,

    A. S. Al-Batati, A. Koubaa, and M. Abdelkader, “Ros 2 in a nutshell: A survey,”Preprints, October 2024. [Online]. Available: https://doi.org/10.20944/preprints202410.1204.v2

    2024

  15. [23]

    Response time analysis for dynamic priority scheduling in ros2,

    A. A. Arafat, S. Vaidhun, K. M. Wilson, J. Sun, and Z. Guo, “Response time analysis for dynamic priority scheduling in ros2,” inProceedings of the 59th ACM/IEEE Design Automation Conference, ser. DAC ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 301–30...

    2022

  16. [24]

    Latency analysis of ros2 multi-node systems,

    T. Kronauer, J. Pohlmann, M. Matthé, T. Smejkal, and G. Fettweis, “Latency analysis of ros2 multi-node systems,” in2021 IEEE Interna- tional Conference on Multisensor Fusion and Integration for Intelligent Systems (MFI), 2021, pp. 1–7

    2021

  17. [25]

    Performance evaluation of real-time ros2 robotic control in a time-synchronized distributed network,

    L. Puck, P. Keller, T. Schnell, C. Plasberg, A. Tanev, G. Heppner, A. Roennau, and R. Dillmann, “Performance evaluation of real-time ros2 robotic control in a time-synchronized distributed network,” in 2021 IEEE 17th International Conference on Automation Science and Engineeri...

    2021

  18. [26]

    Picas: New design of priority-driven chain-aware scheduling for ros2,

    H. Choi, Y . Xiang, and H. Kim, “Picas: New design of priority-driven chain-aware scheduling for ros2,” in2021 IEEE 27th Real-Time and Embedded Technology and Applications Symposium (RTAS), 2021, pp. 251–263

    2021

  19. [27]

    Compros: A composable ros2 based architecture for real-time embed- ded robotic development,

    S. Dehnavi, M. Koedam, A. Nelson, D. Goswami, and K. Goossens, “Compros: A composable ros2 based architecture for real-time embed- ded robotic development,” in2021 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), 2021, pp. 6449–6455

    2021

  20. [28]

    Response-time analysis of ros 2 processing chains under reservation- based scheduling,

    D. Casini, T. Blass, I. Lütkebohle, and B. B. Brandenburg, “Response-time analysis of ros 2 processing chains under reservation- based scheduling,”Dagstuhl Artifacts Ser., vol. 5, pp. 05:1–05:2,

  21. [29]

    Real-time control architecture based on xenomai using ros packages for a service robot,

    R. Delgado, B.-J. You, and B. W. Choi, “Real-time control architecture based on xenomai using ros packages for a service robot,”Journal of Systems and Software, vol. 151, pp. 8–19, 2019. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0164121219300160

    2019

  22. [30]

    Real-time linux communications: an evaluation of the linux communication stack for real-time robotic applications,

    C. S. V . Gutiérrez, L. U. S. Juan, I. Z. Ugarte, and V . M. Vilches, “Real-time linux communications: an evaluation of the linux communication stack for real-time robotic applications,” 2018. [Online]. Available: https://arxiv.org/abs/1808.10821

    2018 arXiv

  23. [31]

    CROS-RT: Cross- Layer Priority Scheduling for Predictable Inter-Process Communication in ROS 2,

    S. Kim, H. S. Chwa, J. Song, K. Lee, and S. Oh, “CROS-RT: Cross- Layer Priority Scheduling for Predictable Inter-Process Communication in ROS 2,” in31st IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS 2025), 2025

    2025

  24. [32]

    Road Vehicles – Functional Safety, 2009

    International Organization for Standardization,ISO/DIS 26262. Road Vehicles – Functional Safety, 2009

    2009

  25. [33]

    Bru: Bandwidth regulation unit for real-time multicore processors,

    F. Farshchi, Q. Huang, and H. Yun, “Bru: Bandwidth regulation unit for real-time multicore processors,” 04 2020, pp. 364–375

    2020

  26. [34]

    Maximum- contention control unit (mccu): Resource access count and contention time enforcement,

    J. Cardona, C. Hernandez, J. Abella, and F. J. Cazorla, “Maximum- contention control unit (mccu): Resource access count and contention time enforcement,” in2019 Design, Automation & Test in Europe Conference & Exhibition (DATE), 2019, pp. 710–715

    2019

  27. [35]

    Profiling and controlling i/o-related memory contention in cots heterogeneous platforms,

    M. Zini, G. Cicero, D. Casini, and A. Biondi, “Profiling and controlling i/o-related memory contention in cots heterogeneous platforms,”Soft- ware: Practice and Experience, vol. 52, 11 2021

    2021

  28. [36]

    Leveraging Hardware QoS to Control Contention in the Xilinx Zynq UltraScale+ MPSoC,

    A. Serrano-Cases, J. M. Reina, J. Abella, E. Mezzetti, and F. J. Cazorla, “Leveraging Hardware QoS to Control Contention in the Xilinx Zynq UltraScale+ MPSoC,” in33rd Euromicro Conference on Real-Time Systems (ECRTS 2021), ser. Leibniz International Proceedings in Informatics ...

    2021

  29. [37]

    Bao: A Lightweight Static Partitioning Hypervisor for Modern Multi-Core Embedded Systems,

    J. Martins, A. Tavares, M. Solieri, M. Bertogna, and S. Pinto, “Bao: A Lightweight Static Partitioning Hypervisor for Modern Multi-Core Embedded Systems,” inWorkshop on Next Generation Real-Time Embedded Systems (NG-RES 2020), ser. Open Access Series in Informatics (OASIcs), M...

    2020 doi

  30. [38]

    Supporting temporal and spatial isolation in a hypervisor for arm multicore platforms,

    P. Modica, A. Biondi, G. Buttazzo, and A. Patel, “Supporting temporal and spatial isolation in a hypervisor for arm multicore platforms,” in 2018 IEEE International Conference on Industrial Technology (ICIT), 2018, pp. 1651–1657

    2018

  31. [39]

    Memguard, memory bandwidth management in mixed criticality virtualized systems - memguard kvm scheduling,

    N. Dagieu, A. Spyridakis, and D. Raho, “Memguard, memory bandwidth management in mixed criticality virtualized systems - memguard kvm scheduling,” inThe Tenth International Conference on Mobile Ubiquitous Computing, Systems, Services and Technologies (UBICOMM 2016), 2016, pp. ...

    2016

  32. [40]

    Memory utilization-based dynamic bandwidth regu- lation for temporal isolation in multi-cores,

    A. Saeed, D. Dasari, D. Ziegenbein, V . Rajasekaran, F. Rehm, M. Pressler, A. Hamann, D. Mueller-Gritschneder, A. Gerstlauer, and U. Schlichtmann, “Memory utilization-based dynamic bandwidth regu- lation for temporal isolation in multi-cores,” in2022 IEEE 28th Real- Time and E...

    2022

  33. [41]

    E-warp: A system- wide framework for memory bandwidth profiling and management,

    P. Sohal, R. Tabish, U. Drepper, and R. Mancuso, “E-warp: A system- wide framework for memory bandwidth profiling and management,” in 2020 IEEE Real-Time Systems Symposium (RTSS), 2020, pp. 345–357

    2020

  34. [42]

    NVIDIA Orin Series System-on-Chip Technical Ref- erence Manual, Version: 1.2, 2023,

    NVIDIA, “NVIDIA Orin Series System-on-Chip Technical Ref- erence Manual, Version: 1.2, 2023,” https://developer.nvidia.com/ orin-series-soc-technical-reference-manual, accessed: April 2025

    2023

  35. [43]

    Isolbench,

    H. Yun, “Isolbench,” https://github.com/CSLKU/IsolBench, accessed: April 2025

    2025

  36. [44]

    Taming non-blocking caches to improve isolation in multicore real-time systems,

    P. K. Valsan, H. Yun, and F. Farshchi, “Taming non-blocking caches to improve isolation in multicore real-time systems,” in2016 IEEE Real- Time and Embedded Technology and Applications Symposium (RTAS), 2016, pp. 1–12

    2016

  37. [45]

    Sd-vbs: The san diego vision benchmark suite,

    S. K. Venkata, I. Ahn, D. Jeon, A. Gupta, C. Louie, S. Garcia, S. Belongie, and M. B. Taylor, “Sd-vbs: The san diego vision benchmark suite,” in2009 IEEE International Symposium on Workload Character- ization (IISWC), 2009, pp. 55–64. 13

    2009

  38. [2019]

    Available: https://api.semanticscholar.org/CorpusID: 195825437

    [Online]. Available: https://api.semanticscholar.org/CorpusID: 195825437

Pith tools

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