Live Processing or Recorded Data: What Actually Needs a VPN?

A robot that stops being useful one room away has a link problem or a workload problem long before it has a VPN problem. Encryption protects a path; it does not extend radio coverage, and it does not make a remote computation finish sooner. The decision in front of you is which work genuinely has to cross the network, and that answer usually removes more traffic than people expect. Three conditions settle it, and throughput is not one of them.

Three arrangements, one dependency question

The table separates the arrangements by what depends on the link, not by which software appears in the diagram.

No row in that table is a safety argument. Control and safety functions still need a qualified answer for delay, packet loss and a dropped connection, and no tunnel indicator supplies one. The table tells you where the dependency lives, which is the part a network design can actually change.

Condition one: does the answer have to be timely?

If a remote result feeds a controller, the network sits inside the control loop, and its delay, jitter and outages become control properties. If the same result only feeds a display, a dashboard or a person watching, the identical delay is cosmetic.

Closed-loop work over a wireless link is possible, and it is also where most "the VPN is slow" reports originate, because the tunnel is the visible component while the radio and the routing are the cause. Measure the round trip of the actual message rather than the tunnel's own ping, then ask whether the number fits the loop's budget. When it does not, move the step onboard instead of negotiating a stricter service level for a link nobody in the room controls. Record the measured number with the conditions it was taken under, because the next report will arrive without them.

Condition two: what rate, direction and interruption can you declare?

Write down the data, the rate, the direction and the longest interruption the application tolerates. An upstream camera stream and a downstream command channel fail in different ways, and an interruption that a stationary inspection tolerates will end a moving task.

Keep the physical attachment and the tunnel separate when comparing options, since a stronger radio and a smaller workload are different repairs. A large transfer that eventually completes proves nothing about a time-sensitive result arriving consistently, and a healthy tunnel proves nothing about the radio behind it.

Then reduce the demand instead of defending it. Downsample the observation stream, send summaries or deltas, and leave raw sensor data onboard where storage is cheap and transmission is not. A smaller payload weakens the case for a faster link, and often removes the need for one.

Condition three: who must see it, and what stays local

Observation is usually a much smaller requirement than processing. If a person must watch the camera and a log must exist afterwards, that is telemetry plus storage; if a model must run, ask first whether it can run onboard with only its result forwarded. Moving the heavy step onboard removes the synchronous dependency and leaves a transfer that can be retried.

Two ROS participants existing on the same robot does not justify a tunnel by itself. Node reachability, application authorization and a local recovery plan are separate problems, and a VPN answers only the first, and only for the traffic it is asked to route.

Recording a dataset is its own design, with its own commands

For a version-scoped example, the ROS 2 Jazzy recording tutorial covers recording selected topics, inspecting the resulting bag and playing it back. Record the approved observation topics, name the run, and keep the message definitions and configuration beside it.

ros2 bag record -o run42 /scan /camera/image_raw
ros2 bag info run42
ros2 bag play run42

Do not record every topic because the tool makes it easy. Storage fills, camera and location data carry sensitivity, and a bag of unlabelled topics is an analysis problem for whoever opens it next. The deployed distribution decides the commands as well: tooling written for ROS 1 bags does not transfer to ROS 2 bags, so match the documentation to the version installed on the robot.

Play back in an isolated analysis or simulation environment. Recorded command topics replayed into a live robot's actuators is an accident, and the prevention is a separate ROS domain or no hardware in the loop at all.

Decide where the dependency belongs and write it down: a VPN protects an exchange that has to happen, onboard processing removes an exchange that never needed to be synchronous, and a recorded dataset replaces a live consumer with a later one. Then test the disconnected case on purpose, with the local job still running, before anyone calls the design finished.