Safety Controllers for Mobile Robots: A UK Pharma Plant Guide

Safety controllers for mobile robots are the certified hardware modules that execute a machine's safety functions — emergency stop, protective stop, speed limiting and scanner monitoring — independently of its navigation software. That independence is the whole point: if the navigation stack crashes, the safety controller still stops the truck. Since 5 December 1998 the Provisions and Use of Work Equipment Regulations (SI 1998/2306) have applied to every piece of work equipment in Great Britain, and they draw no distinction between a truck with a driver and one without. For a Plant Director on an MHRA-regulated site, that is where automation stalls. Your qualification protocol demands documented evidence that each safety function is independently rated and verified. The robot supplier offers a conformity declaration and a brochure. Your auditor wants the performance level, the validation record and proof the function was tested on your floor.

Why safety evidence stalls robot projects on regulated sites

Three forces collide on a regulated manufacturing site, and the safety controller sits at the intersection of all of them.

The first is procurement framing. Mobile robots are bought as vehicles — payload, lift height, runtime, aisle width. The safety controller is a line buried in an appendix, if it appears at all. By the time the qualification team asks which component executes the protective stop and to what performance level, the order is signed and the answer is whatever the manufacturer happened to fit.

The second is a category error about certification. A UKCA or CE mark tells you the manufacturer has declared conformity against the directives that apply to the machine. It does not tell you that machine is safe in your building, at your aisle widths, with your traffic. PUWER places the duty on the user, not the maker, and that duty does not transfer with the invoice.

The third is qualification culture itself. On an MHRA-regulated site nothing enters routine use without documented evidence that it does what it is specified to do. Your team is fluent in qualifying a filling line. A driverless truck that navigates by software, reroutes dynamically and shares floor space with people does not fit the template, so it lands in a queue nobody owns.

Navigation software is also updated far more often than safety hardware. The plant needs a component whose behaviour is fixed, rated and independently verifiable — and that is the one least likely to have been specified.

Safety controllers for mobile robots are the certified hardware that executes a robot's safety functions independently of its navigation software — and under PUWER 1998 they must be validated as part of your work equipment, not accepted on a supplier's assurance.

Lever 1 — Specify the safety controller before you specify the robot

Write the safety architecture into the tender, not the acceptance test. Three questions settle most of it.

Which functions are safety-rated? At minimum: emergency stop, protective stop from the scanner, speed limiting in defined zones, and safe direction or steering monitoring. Ask for each one named individually with its performance level, rather than a blanket claim that the truck is "safety certified".

Is the safety channel independent of navigation? A controller sharing the processor that runs the mapping stack gives you a single point of failure. A dual-channel architecture with a dedicated safety processor is what makes the function verifiable in isolation — and what lets you argue the case to an auditor without reference to software you cannot inspect.

Does it speak a documented interface? Fleet-level control has to command and monitor vehicles from more than one manufacturer. A controller that exposes its state over an open standard such as VDA 5050 keeps the orchestration layer — see M4 — vendor-neutral, and leaves you free to add a different machine class later without rewriting the safety case. FlyWei's safety controllers for mobile robots range documents the ratings and interfaces for each class.

Lever 2 — Validate the safety functions on your own floor

A performance level on a datasheet is a claim about a component. Your obligation concerns a system in a building. Close that gap with a validation run that follows how you qualify any other equipment.

Map the hazards first: blind corners, dock-door transitions, the pedestrian route that cuts the main aisle, the chilled airlock where condensation settles on a scanner lens. HSE guidance on workplace transport is built around exactly these interfaces between vehicles and people.

Then test each safety function against each hazard, and record it. Trigger the protective stop with a test piece at the scanner's rated detection height. Confirm the speed limit genuinely applies in the zone you drew. Force an emergency stop mid-lift and record the load's behaviour. Interrupt the network and confirm the truck holds safely rather than continuing on its last order.

Sign each test off with a named engineer, a date and a result. That record, not the brochure, is what your auditor reads — and it is what lets the plant move a robot from qualification into routine use.

Lever 3 — Build the PUWER and ISO 3691-4 evidence pack

Two references carry most of the regulatory weight, and naming them early shortens every later conversation.

PUWER 1998 is the duty. It requires work equipment to be suitable, maintained, inspected, and used only by people with adequate training and information. Regulation 11 deals with dangerous parts of machinery, which is where a moving mast and a powered fork sit. Where the truck lifts, LOLER 1998 applies alongside it.

ISO 3691-4 is the specification. It covers driverless industrial trucks and their systems, and it is the document an auditor expects referenced when you explain how the safety functions were chosen and verified. Standards are available through BSI.

Assemble the pack as one controlled document: the declaration and UKCA mark, each safety function with its rating, your site validation records, the traffic and pedestrian layout as built, the training record for supervisors, and the planned inspection interval. Reviewed annually, it answers an inspector's questions before they are asked.

Lever 4 — Standardise one controller family across a mixed fleet

Most plants do not automate in one move. A counterbalanced truck arrives for pallet movements, a narrow-aisle machine follows for high-bay, a low-profile unit handles dock-to-stock. Left alone, each arrives with a different safety architecture needing its own validation, spares, training and maintenance line.

Specifying a common controller family across the fleet collapses that. The safety case is written once against a known architecture and extended per machine class rather than rebuilt. Supervisors learn one diagnostic behaviour. Spares consolidate to a handful of part numbers. When a machine class is added, the qualification effort is incremental rather than repeated.

This is where an independent integrator earns its place. A single-manufacturer supply chain gives you whatever controller that manufacturer fits. Choosing across manufacturers lets the controller be the fixed point and the machine the variable — the right way round, because the controller is what your evidence pack rests on, and the machine is what changes when the process does.

What FlyWei does here

FlyWei is an independent UK systems integrator of autonomous forklifts and AMRs. We are not a manufacturer and not a reseller, which is precisely why the safety controller is a specification we set rather than one we inherit.

On a regulated pharmaceutical site the work runs in three stages. We start with the flow, not the machine: a 48-hour read on your highest-volume movement — typically production packing through to the quarantine or bonded area — establishes whether the flow suits a driverless truck at all, and which class fits. That may be a FlyWei autonomous reach truck for high-bay racking, a stacker class for mid-height, or a latent-jacking lifting robot where the load is a wheeled cage rather than a pallet.

We then specify the controller against your evidence requirement, naming and rating each safety function before anything is ordered, drawing on the range set out on our controllers page. Finally we run validation on your floor with your team, producing the signed records for your qualification pack.

M4 manages the fleet and holds the traffic rules; RDS dispatches work from the systems you already run, so robots take orders from your existing ERP and WMS rather than replacing them. Sites across the East Midlands corridor — Magna Park, DIRFT, Burton-on-Trent — run on this pattern, and our solutions pages set it out by sector.

Frequently asked questions