Abstract. Real-time robot security means preserving control deadlines under attack — across hardware, networking, ROS 2, synchronization and security controls.
This note accompanies a speech delivered at the Real-Time workshop at ROSCon 2019. It collects seven lessons from building distributed robotic systems in which security controls must coexist with timing constraints.
The central distinction is simple but consequential: real-time is not the same as real-fast. A fast system responds quickly on average. A real-time system provides evidence that its responses remain inside a specified bound. For a robot, security must preserve that bound even when activity is malicious.
Download the ROSCon 2019 slides · PDF · 48 slides · 1.9 MB ↓ Read the original publication ↗
1Real-time or real-fast?
In control, a real-time system is one whose correctness depends not only on what it computes, but also on when the result is produced. The deadline belongs to the application: a motor loop, a safety stop and a perception pipeline can each have a different bound.
Security discussions often use real-time to mean zero-latency detection or simply very rapid processing. That is useful, but it is not the control-system meaning. A security monitor can be extraordinarily fast on average and still be unsuitable for a critical robot if its worst-case delay is unbounded.
Real-time security for robotics means meeting the robot's deadlines despite malicious activity.
2The relevance of hardware
Timing and security both begin below the application. Robotic products are often prototyped on platforms that were not designed for safety-critical or security-critical work. Once the application's criticality is understood, the hardware architecture, interfaces and configuration should be selected to support it.
A real-time kernel cannot compensate for a link that introduces unbounded delay; encrypted middleware cannot repair an untrustworthy clock. The guarantee has to be built bottom up and checked end to end, across hardware and software.
3The link layer
Robotics work commonly concentrates on OSI layers 3–7 and treats the channel beneath them as a given. Ordinary switched Ethernet, however, was not designed to deliver frames within a declared worst-case time. Congestion therefore becomes both a performance concern and an attack surface.
In the experiment presented at the workshop, a 1 Gbit/s Ethernet link carrying 900 Mbit/s of background traffic produces latencies above 2 ms. An attacker able to create a local traffic burst can exploit the same weakness and make a controller miss its timing assumptions without compromising the application itself.
Original experimental plots from slides 11 and 14 of the deck; results from Time-Sensitive Networking for robotics (Gutiérrez et al., 2018).
Time-Sensitive Networking, and specifically the IEEE 802.1Qbv Time-Aware Shaper used here, separates scheduled traffic from best-effort traffic. Under the same saturation, the presented measurements remain at the microsecond level. The lesson is not that every robot needs the same link technology, but that its link layer has to match its timing and threat model.
4RTOS and the networking stack
A real-time operating system is necessary in many robots, but it is not sufficient for communication across machines. Interrupt placement, CPU affinity, queueing disciplines, device drivers and the network stack all shape the delay seen by the application.
The workshop measurements make the difference concrete. With 100 Mbit/s of background traffic, the tuned configurations that bind the real-time thread and network interrupts keep the measured round trip below 1 ms, while the untuned systems do not.
| Configuration | Maximum latency | Interpretation |
|---|---|---|
no-rt | 7160 µs | Vanilla kernel |
rt-normal | 2527 µs | PREEMPT-RT without affinity tuning |
rt-affinity | 568 µs | Real-time thread and network IRQs bound to a CPU |
rt-isolated | 617 µs | Real-time application on an isolated CPU |
The practical lesson is to test the complete communication path under contention. Declaring the operating system “real-time” says little about an end-to-end deadline if its networking path remains untuned.
5Communications middleware and ROS 2
ROS 2 and DDS sit above all of those choices, so middleware must preserve rather than hide their timing properties. The workshop tests compare a distributed ROS 2 path under system stress with and without real-time configuration. In the real-time runs, the measured maxima are roughly 2.1–2.7 ms and no deadline is missed; the untuned runs reach roughly 27–29 ms and do miss deadlines.
This supports bounded, approximately two-millisecond round-trip communication in the presented setup, but the number is not universal. The reusable result is the method: configure the layers together, load the system adversarially, and measure the bound that the particular robot actually needs. The experiments are documented in Towards a distributed and real-time framework for robots.
6Time synchronization in robot modules
Distributed deadlines only make sense when the modules agree on time. Without synchronization, publications from sensors and actuators drift across controller periods; the workshop measurements show message-arrival offsets approaching 100 ms. Precision Time Protocol narrows clock alignment principally to the sub-microsecond range, while synchronized message arrivals are contained to roughly 2.4 ms in the presented setup.
The clock is therefore a security boundary. An attacker who delays or falsifies synchronization messages can make correct computations arrive in the wrong control period. PTP and its grandmaster must be included in the threat model and protected with the same care as the control traffic. See Time Synchronization in modular collaborative robots for the experiment.
7Real-time security
Availability, integrity and confidentiality protect the robot's behaviour over time, yet the mechanisms that provide them also consume time. Encryption, authentication and access-control checks add work to every exchange. In the ROS 2 comparison presented on slide 44, average latency moves from 260 µs for plain communication to 1363 µs with the full security configuration.
This does not argue against protection. It argues against adding controls without a timing budget. Each robot and each subsystem needs a threat model that identifies the relevant attack vectors, then decides whether to mitigate, remove or accept them. The chosen controls must be measured under realistic and hostile load, and the assessment must be repeated as the system changes.
Security is not a product; it is a process. It needs to be assessed continuously and periodically.
The distinction between real-time and real-fast is the reflection that ties the seven lessons together. Speed is a desirable measurement. A deadline is an engineering promise. Real-time robot security is the work of keeping that promise when the environment is adversarial.
8References and source material
- Víctor Mayoral Vilches. Real-time security for robotics. Alias Robotics News, 7 November 2019.
- Real-time security for robotics — complete ROSCon 2019 slide deck, 48 slides.
- Gutiérrez et al. Time-Sensitive Networking for robotics, 2018.
- Gutiérrez et al. Real-time Linux communications: an evaluation of the Linux communication stack for real-time robotic applications, 2018.
- Gutiérrez et al. Towards a distributed and real-time framework for robots, 2018.
- Gutiérrez et al. Time Synchronization in modular collaborative robots, 2018.
- White et al. Security and Performance Considerations in ROS 2, 2018.
- DiLuoffo, Michalson and Sunar. Robot Operating System 2: The need for a holistic security approach to robotic architectures, 2018.