Picture a warehouse that never existed, staffed by people who are composites. Nothing below happened anywhere. The tale follows a small robotics operations crew through the first year of looking after the security of their own robot fleet, and it shows what SOC Ops looks like when the people doing it are mechanics and controls engineers rather than career security analysts. If you run machines for a living, parts of it may feel familiar.
Day zero: the whiteboard
The crew managed forty autonomous carts that moved pallets between racking and dock doors. Every cart reported to a central controller over the site network, and the controller reported to cloud dashboards. One quiet Tuesday a cart stopped responding for eleven minutes. It turned out to be a loose antenna. But the shift supervisor asked a question nobody could answer: if it had been an intruder instead of an antenna, who would have noticed, and how?
The crew drew boxes on a whiteboard. They had read the Ops Atlas page about SOC Ops, which sets out a lifecycle for building a monitoring capability: design first, stand-up second, steady operation third. The Atlas wants the design stage scaled to the threat, and it quotes UK guidance to the effect that no single template fits every organisation. A forty-cart warehouse does not need a glass room with wall screens. It needs agreement on who watches what.
They made three decisions that afternoon. The controller’s logs would be gathered in one place. One named person per shift would own the alert queue. And whatever that person decided would be written down.
Day one: learning what normal looks like
The first month produced very little useful detection, and the crew had to resist the urge to buy something clever. The Atlas relays Australian government guidance that a baseline cannot be rushed in a day, and warns that a baseline taken from a system already compromised bakes the problem in. So they spent weeks watching ordinary traffic: when carts woke up, which servers they spoke to, how firmware updates behaved on Sunday nights.
Those weeks felt like maintenance rounds, and in a sense they were. Anyone who has tracked how a machine sounds when healthy will recognise the idea. The KPIs in our piece on robotic performance indicators for factory managers are the production side of the same instinct: you cannot judge a number without a sense of its usual range.
During this stage they also made a boring but important decision about the people. Per the Atlas, ENISA observes that small organisations frequently merge incident handling and monitoring into one group, and that is how the crew ended up: four people on a rota, never fewer than two on duty. They knew that did not amount to round-the-clock cover, so they documented exactly which hours were thin and who could be reached by phone.
Day two: operating, tuning, rehearsing
By the third month the queue was alive. Some alerts were real, such as a technician’s laptop joining the cart network without approval. Many were harmless: a vendor’s diagnostic tool, a contractor’s tablet, a firmware push no one had announced. At first the crew called these false alarms and muted them. Then someone noticed that muting a whole rule had also hidden a genuine odd login, and the team adopted the Atlas’s rule: no suppression without an owner and an expiry date.
The weekly review became the rhythm of the operation. Every Friday the crew counted outcomes, reported a typical wait and a slowest-tenth wait for each shift, and looked at how many closed items had been reopened. The overnight figure was bad, as the Atlas predicts for teams that only measure averages. Their answer was modest: move one maintenance task to the evening handover so a second person was awake when the overnight batch ran.
They also practised. Twice a year they ran a tabletop exercise, a talked-through scenario where someone played an intruder poking at the carts, and the Atlas’s Day 2 list mentions purple-team style practice and tabletops for the same reason. The exercises exposed gaps no dashboard did, such as the fact that nobody knew who could authorise stopping the whole fleet.
The handover that saved a Saturday
The crew’s pass-down note was a single page, signed by the outgoing and incoming supervisors, with one rule: anything the incoming person had not accepted stayed with the outgoing one. One Saturday an unfinished item about a misbehaving charging station was left off the note. The outgoing supervisor, who still owned it by rule, got a call from the incoming lead at 6 a.m., and the problem was handled before the first cart left its bay. The rule cost a phone call and saved a morning.
Where the story meets the shop floor
Automated guided vehicles already carry a lot of operational logic, and the full guide to warehouse AGV automation explains how the fleet fits into the wider system. What the story adds is the human layer on top: someone looks at the signals, decides and writes it down. The crew had learned two more lessons by year end. Limit automatic actions to proven rules on low-stakes devices, with a rate limit, so a mistaken rule cannot park the whole fleet. And keep the decisions about critical machines in human hands.
- Design in proportion. Match the effort to the threat and the headcount.
- Baseline before cleverness. Weeks of watching normal traffic were worth more than any purchase.
- Dated suppressions. Every mute needs a name and an end date.
- Weekly numbers. Medians, slow tenths and reopened items, by shift.
- Rehearse. Tabletops expose ownership gaps.
A year on, the crew still had no glass room. What they had was a queue they could explain, a record of every decision and a rota with honest gaps. For a fleet of forty carts that was enough, and it is the kind of enough that other operators can aim for too.
