Industrial Vending When the Network Drops

by a.huynh | 10th Aug 2026

Factories are hostile places for ordinary networks. Steelwork reflects and blocks wireless signals. Welders, drives and large motors make electrical noise. Mezzanines and new cells appear where nobody planned a cable. A cabinet installed in good faith next to a router in the stores office can be a very long radio hop away from the cell where the tools are actually needed. On the day the link fails, the operational question is blunt. Can a person still get the insert, the glove or the gauge, and will the business still know they took it?

A point-of-use system that refuses to open when it cannot see head office has traded a stockout risk for a network risk. A system that opens and then forgets the transaction has traded a network risk for a black hole in the stock figure. Resilience sits between those two failures. The cabinet has to keep serving the shift, keep a faithful local record, and catch up honestly when the connection returns.

What actually fails on a shop floor

The failure is rarely a dramatic outage of an entire site. It is a wireless access point rebooted during a maintenance window, a switch in a panel that overheated, a VPN to a hosted application that timed out, or a cabinet moved six metres during a layout change so that it now sits in a shadow. Night shift discovers it. Day shift discovers the consequences, which are either a queue of people who could not draw tools or a stock record that no longer matches the compartments.

Remote and yard-based work makes the same point in a stronger form. A SupplyMobile deployment that follows a maintenance task, or a store serving an oil and gas location with uneven links, cannot assume a cheerful, continuous connection. Even a conventional plant, with a competent IT team, will have minutes and occasionally hours in which a cloud session is not there. The design should assume those minutes, because the cutting tool does not wait for them to pass.

There is a planning failure underneath many of these incidents. The vending cabinet was specified as a stores asset and the network was assumed to be someone else’s finished product. Nobody walked the bay with a laptop. Nobody agreed what “working” means if the site link is down. The acceptance test was a successful issue at 10:00 on a Tuesday, which is the hour the network is least likely to be under strain.

Decide the local behaviour before you buy

Write the failure behaviour in plain sentences and put it in the specification. If the cabinet cannot reach the central application, it still identifies a user from a locally held permission list. It still opens the compartments that user is allowed to open. It still records the item, the quantity, the person and the time on local storage. It refuses transactions that would be unsafe to guess, such as issuing a gauge it cannot confirm is inside calibration, if that is the rule you care about more than availability. When the link returns, it sends the stored transactions in order, once, and the central stock figure moves by exactly what left the cabinet.

That last clause is where cheap designs fall over. A retry that posts the same issue twice will shrink the stock record below reality and trigger a replenishment you do not need, or it will confuse a return. A design that keeps working locally and then overwrites the local truth with an older central picture will resurrect stock that has already been used. The synchronisation rule has to be boring, sequential and visible. Stores should be able to see that a cabinet is in “caught up” or “holding transactions” without ringing the manufacturer.

Conflict handling deserves a sentence of its own. If someone changes a permission or a minimum in the central system while a cabinet is offline, the cabinet should finish its stored shift on the rules it had, then take the new rules, and the log should show the moment the rules changed. Silent merges are how stock figures become a matter of opinion.

Identity, calibration and the rules you will not bend

Local operation is not an excuse to drop control. A badge or PIN check that works from a cached list is still a check. An open-door mode “until IT gets in” is how the week of the outage becomes the month the data was abandoned. Agree the cache lifetime. A list refreshed every shift is a different risk from a list that has not been updated since a leaver’s last day three weeks ago. Leavers and lost badges should be manageable locally by a named supervisor, with that override itself recorded.

Calibration and quarantine are the rules most worth keeping even when the network is down. If the cabinet knows, from its last synchronisation, that a gauge is out of date, it should continue to withhold it. Availability of a blunt cutter is an inconvenience. Availability of an uncalibrated gauge is a quality escape. Write that distinction down so an engineer under pressure cannot talk a well-meaning supervisor into a bypass that the system then cannot explain.

Returns need the same local faithfulness. A tool brought back during an outage must be accepted, identified and time-stamped locally, or the central system will keep chasing a person who did the right thing at 02:00. The fastest way to destroy trust in a resilient design is to punish the night shift for using it.

Where to put the cabinet, and who owns the cable

Physical placement is a resilience decision. A cabinet on a reliable wired connection, on a network segment that production and IT both understand, will outperform a wireless cabinet that was put wherever the forklift could drop it. Where wireless is the only practical option, survey it at the height and in the condition the cabinet will live, with the line running, not on a quiet install day. Agree who is called when the link fails. A stores supervisor who has no route into IT, and an IT team who do not know the cabinet exists, will between them leave the cell without tools.

Power deserves the same honesty. A network that survives and a cabinet that does not, or the reverse, should be a conscious choice. If the process requires issue during a controlled power interruption, say so. If it does not, make sure a safe restart does not unlock doors or lose the last transactions. These are procurement questions. They are unglamorous, and they are the difference between a pilot that impressed everyone at the demonstration and a system the night shift will use in February.

Security sits beside resilience. A cabinet that stores identities and stock movements is a small operational system, not a dumb lock. Local storage, remote access for support, and the path back to the central application all need an owner. The National Cyber Security Centre’s Cyber Assessment Framework is a useful prompt for that conversation, because it asks whether you understand the asset, control who can reach it, and can keep operating when something goes wrong. The detailed security case belongs with your own IT and operational-technology leads. The stores specification should at least refuse the two extremes: a cabinet that cannot work for an hour without the cloud, and a cabinet that works offline by abandoning the record.

Test the failure, or you have only tested the demo

The acceptance test should include a pulled network cable or a disabled wireless connection, carried out with a real user badge and a real item. Confirm that the issue completes, that the local record exists, that a forbidden item stays forbidden, and that restoring the link produces one central transaction with the right time. Repeat it after a permission change made during the outage. Do it on the shift that will live with the result, not only with the project team.

Then write the one-page rule for supervisors. What still works. What is deliberately withheld. Who to call. How to tell that the cabinet has caught up. A resilient design that nobody can explain will be bypassed the first time it hesitates, and the bypass will become the process.

Write the outage into the support agreement

Resilience that lives only in a sales demonstration will be absent from the contract, and the contract is what you have at 02:00. Ask for a written description of offline behaviour, the maximum time transactions can be held locally, and what the cabinet does when that time is exceeded. Ask what a supervisor can do without a network, and what they must not be able to do. Ask for the synchronisation rule in a paragraph a stores supervisor can read. If the supplier cannot write it down, the design is not finished.

Agree an internal service level with IT that matches the shift pattern. A cabinet beside a manned cell needs a different response than a cabinet in a yard that is visited twice a day. The useful commitment is often simple: production-critical issue points are on a supported connection, faults are visible without someone happening to walk past, and a workaround that abandons the record is not the documented response. Review that commitment when the cell moves. Layout changes are the moment wireless assumptions go stale, and they happen more often than network redesigns.

Keep a small, local method for the items you will not risk. A shadow-boarded breakdown kit, checked weekly, covers the genuine emergency in which even a resilient cabinet is the wrong tool because the power is gone. It should be short, named and sealed in the sense that using it is an event. It is a complement to the cabinet, not a return to a drawer full of maybes.

Point-of-use control earns its place by being present at the moment of need. That moment will sometimes arrive while the wider network is having a bad night. Specify for that night at the beginning, and the spindle keeps turning with a record you can still believe in the morning.