Why randomised patrol routes are a security requirement, not a feature

Any patrol that repeats can be timed. A guard who walks the same loop at the same pace leaves the same gap at the same point every night, and anyone watching from outside the fence only needs a few nights to learn it. A robot that repeats a route is worse, because it repeats more precisely than a person ever could.

That is why randomised routing sits in the core of MoLogica’s patrol design and not in a settings menu. Every route is randomised, and the next route is drawn after every dock. Nobody on site, including the people who configured the fleet, can tell an outsider where the robot will be at 02:00.

What “timing the gap” looks like

On a long perimeter or a large yard, a predictable patrol creates a schedule of exposure. If the loop takes a fixed time and starts from a fixed point, every section of fence is unwatched for a known window. People planning cable theft or a break-in at a depot do not need inside help to exploit that. They need patience and a vantage point.

Inside help makes it easier still. A patrol pattern that a guard can describe over the phone is a pattern that can be sold. Randomisation removes the thing worth selling. There is no route to leak, because the route does not exist until the robot leaves the dock.

How a randomised patrol runs

The patrol starts as an instruction in plain language, such as “patrol the north fence, check the fuel-store padlock, then the vehicle yard.” The mission layer turns that into waypoints, behaviours and checks. Randomisation then changes the order and the path between them:

• The sequence of checkpoints changes from lap to lap.
• On a perimeter, the direction changes too: clockwise, anticlockwise or cross-site.
• After every dock, a new route is drawn, so a charging break does not reset the robot to a known starting pattern.
• Inspection stops still happen at every defined checkpoint. Randomisation changes when the robot arrives, not whether the check is done.

In MoLogica’s simulated 31 by 16 m warehouse depot, the end-to-end proof gate ran on randomised routes with inspection stops, a self-dock, an undock and a second lap. It passed four times in a row on different random seeds: 32 of 32 patrol legs, 8 of 8 docks and 16 of 16 correct inspection verdicts. Different seeds means different routes, so the result shows the navigation stack does not depend on one rehearsed path.

The cost of randomising

Randomisation is not free, and it is worth being plain about the trade-off.

A fixed loop can be planned for perfect spacing. If you know exactly where every robot is, you can space them evenly around a perimeter so that no section goes unwatched for longer than a set interval. Randomised routes give up some of that spacing efficiency. Two robots can drift closer together than an optimised schedule would allow, and a section can wait a little longer than it would on a fixed plan.

To hold the same worst-case coverage, a randomised fleet needs more bodies. In MoLogica’s fleet design model, randomising raises a perimeter fleet from 4 to 5 bodies to 6 or 7. That figure comes from the design model, not from a real site. Fleets are sized to the loop, the speed, the duty cycle and the randomisation overhead, and every real perimeter will differ.

Why the extra bodies are worth it

The extra robots do two jobs.

First, they buy unpredictability. A fleet of six or seven on randomised routes is far harder to read from outside the fence than four on a timetable, because there are more bodies and none of them follows a pattern.

Second, they double as redundancy. Robots charge, and robots occasionally fault. In a fleet sized with no slack, a robot on the dock is a gap in coverage. In a fleet sized for randomisation, the margin is already there. Rotation through the docks keeps coverage up while individual bodies charge, and a fault does not leave a section of fence unwatched.

The same logic applies to spares held at the site. A spare is a larger share of a small fleet than a large one: two robots plus one spare is 50% extra, while twenty plus two is 10%. Randomisation overhead and spares overlap, so the larger the fleet, the smaller each overhead becomes in proportion.

Smaller batteries, more bodies

Randomised coverage also shapes the choice of body. A fleet built for unpredictable coverage is better served by smaller batteries that charge fast and more bodies in rotation than by a few large robots with long run times. More bodies mean more independent positions on the perimeter at any moment, and quick charging keeps the rotation tight.

The indoor pilot body runs about 2.5 hours per charge and the mid-industrial body about 3 hours. Those are short enough that docking is part of the patrol design from the start, and long enough that rotation keeps several robots on patrol at once.

What randomisation does not do

Randomisation makes a patrol hard to predict. It does not make a patrol complete on its own. It works alongside the rest of the design:

Layer	What it adds	Status
Randomised routes	No pattern to time or sell	Proven in simulation
Per-waypoint inspection	A verdict and a timestamped image at every checkpoint	Proven in simulation
Self-docking and rotation	Coverage holds while bodies charge	Self-docking proven in simulation
Tamper alerting	A robot that leaves its route or loses its link raises an alarm	Designed
Night-first sensors and thermal	Detection in the hours when most risk sits	Designed

Tamper alerting matters here in particular. Randomised routes mean the system always knows where each robot should be, even though nobody outside does. A body that leaves its planned route is itself an alert.

The point for a security manager

A predictable patrol gives an outsider a schedule. A randomised one gives them nothing to work with. The cost is a few more bodies in the fleet design, and those bodies earn their place twice: as unpredictability and as cover for charging and faults.

That is why it is a requirement. A patrol that can be timed protects the site only from people who have not bothered to watch it.

Where this stands

Randomised routing, inspection stops and self-docking are proven in simulation, in a simulated warehouse depot, across four runs on different random seeds. The fleet sizing figures come from a design model, not from a real site. Tamper alerting, thermal detection and perimeter fleets on industrial bodies are designed and not yet tested on real hardware. The first physical robot is on the bench, and pilot sites are the next stage.

Book a demo to see a randomised patrol run in simulation.