Few security topics in Germany have shifted as fast as the protection of critical infrastructure.
Drones over industrial sites. Damaged cable runs. Irregularities at substations, pumping stations, data centers, and logistics hubs. What operators once filed under residual risk is now an operational matter — with reporting duties, audit questions, and board-level attention.
That list hides what is actually at stake. Behind each of those sites sits a supply, not a balance sheet. A substation is light and heating. A pumping station is drinking water. A data center is the emergency call, the patient record, the payment that clears. A logistics hub is, in the end, a stocked shelf in the supermarket.
Protecting critical infrastructure is therefore not purely a corporate matter. It is a public service, and it works in two directions: on actual availability, and on people's confidence that availability will hold. The two belong together. A society that doubts the reliability of its basic supply does not relax because the supply still works technically. And a security concept nobody can explain does not add to that confidence, however well it performs.
A second problem is getting worse at the same time, and it gets discussed far less: the perimeter can no longer be staffed around the clock. Security providers cannot find people. Night shifts are expensive. And a round walked at 3:40 a.m. is not the same round walked at 7:00 p.m.
That gap is where autonomous patrol robotics enters the conversation — usually with promises that are too large. This article sets out what a system like the PUMA M20 Protector genuinely contributes to perimeter security, where it stops, and which regulatory and organizational questions need answers before the first test run.
It is written for security leads, critical-infrastructure operators, and plant security managers who want to assess robotics as a working part of a security concept rather than as a demo.
Where classic perimeter security runs out
The standard setup has been stable for decades: fence, access control, fixed cameras, motion detectors, plus rounds walked by in-house or contracted staff.
It has three structural weaknesses.
1. Fixed cameras see what they see, and nothing else. Every mounted camera has a defined frame. Blind spots sit between those frames — and operations create new ones behind containers, transformer housings, pipe bridges, and parked trailers. Increasing coverage means more cameras, more masts, more cabling. That raises capital expenditure, not response capability.
2. Rounds are infrequent and uneven. Nobody walks a four-kilometer perimeter three times an hour at night. It gets walked once or twice per shift, and bad weather changes how. That is not a criticism of the people doing it. It is physics, cost, and availability.
3. Incidents are documented late and imprecisely. When an event has to be reconsidered later — by an authority, an insurer, or an auditor — the time-stamped footage of the exact spot in question is usually missing.
The actual job: repeatability, not heroics
Most expectations of security robotics point in the wrong direction. A patrol robot is not an intervention asset. It stops no one, holds no one, and engages with no one.
Its value sits elsewhere. It drives the same route, at the same quality, at hours when nobody else is out there — and captures comparable data at identical points.
That repeatability is the real break from a human round. It produces:
- a time series instead of a snapshot: the thermal reading at transformer 3 can be compared across weeks
- change detection: an open gate, a newly parked vehicle, a damaged fence panel stand out because a reference point exists
- audit-ready documentation: every run is logged, with timestamp and position
- night coverage without exposing staff in areas nobody likes to enter alone
When an incident has to be assessed, that matters more than how fast the robot can drive.
The PUMA M20 Protector on a perimeter route
The PUMA M20 Protector is an autonomous wheel-leg robot built by inMotion Robotic GmbH in Frankfurt, Germany. Wheel-leg does not mean it walks. The PUMA M20 drives on its wheels throughout. It clears stairs, curbs, and single obstacles by braking and locking each wheel individually. On a perimeter that is the whole difference from a plain wheeled chassis: a route does not have to stop at the first flight of stairs.
Four properties matter for perimeter work.
1. Sensors that hold up at night
The robot carries dual LiDAR (front and rear), front and rear cameras, a PTZ camera with thermal imaging, GNSS, an IMU, plus a microphone array and speaker. On a perimeter, the thermal PTZ is the decisive component: it picks up people and heat signatures regardless of lighting, where a standard camera returns black.
Custom payloads for gas detection, acoustic monitoring, or specialized sensing can be added. For energy and chemical sites, that is often the point where a security round doubles as an inspection round.
2. Analysis onboard, not in the cloud
Analysis happens onboard: multiple octa-core units host the ZYGO Cognitive AI Engine (from the PRO tier) for situation and behavior recognition. Exactly how much compute and storage you get depends on the variant and tier — settle that during the quote.
For critical-infrastructure operators this is a selection criterion, not a convenience feature. A security system whose detection logic depends on an external cloud link loses value at exactly the moment connectivity becomes part of the threat picture.
3. The Protector suite is the real product
Software decides day-to-day fitness more than mechanics do. The Protector suite (Basic, Basic+, PRO, Enterprise) provides route planning on satellite and 3D maps, geofencing, 360° live video with two-way audio, and alerts via app, e-mail, or messenger. Enterprise adds a REST API and webhooks; SSO is available from PRO.
API access is where a pilot turns into routine operation. An alert only becomes an alert chain once it lands in the existing control room, PSIM, or ticketing tool — otherwise it is one more app.
4. Outdoor endurance
Two variants. M20 Pro: IP66, −20 to +55 °C, roughly 3 hours or 15 km per charge, steps up to 25 cm. M20 Max: IP67, −30 to +55 °C, 3.5 to 5 hours or 16 to 20 km, steps up to 30 cm (availability announced). Both measure 0.82 × 0.43 × 0.57 m, use SLAM and omnidirectional obstacle avoidance, charge in about 1.5 hours, and support hot-swap batteries plus an optional autonomous charging dock. For the Protector configuration the manufacturer states a continuous payload of 15 kg. Those figures apply to the security bundle; unladen weight and payload differ across other configurations, so confirm them with the manufacturer for your specific setup.
What the robot does not do, and why that matters
A serious security concept starts with the limits of the tool.
- It does not repel. The PUMA M20 is unarmed and not built for physical intervention: it detects, documents, and alerts.
- It replaces neither access control nor the fence. It extends the existing perimeter line; it is not that line.
- It is not counter-drone. Airborne threats need different systems and a different legal basis. A ground robot can, at most, add observations from the ground.
- It is an asset that needs protecting itself. A networked, sensor-equipped robot belongs inside the security architecture: network segmentation, hardening, patch process, access roles. Anyone meeting NIS2 duties has to bring the robot into scope, not park it next to scope.
- It does not fix a process problem. If an alert reaches nobody today, a robot alert will also reach nobody — just more often.
Legal and organizational questions to settle before the pilot
In practice, projects fail on four unresolved points, not on technology.
Data protection. Camera runs across a site routinely capture employees. You need a legal basis, a data protection impact assessment, retention limits, purpose limitation, and a documented access model. The Protector suite is built around GDPR Art. 25, 28, and 32, and processes detection data entirely on-premise — the manufacturer runs the system with no cloud dependency at all. That is a solid argument for your impact assessment: what never leaves the site does not need to be assessed as a third-country transfer. Responsibility for purpose and scope stays with the operator.
Works council. A system capable of recording behavior triggers co-determination under German works constitution law (§ 87 (1) no. 6 BetrVG). Bring the works council in before the robot arrives on site, not after. A works agreement with a clear purpose description is the faster route in practice, not the slower one.
Regulation. NIS2 and the requirements for critical-infrastructure operators shift the burden from intent to evidence. A system that logs every run supplies exactly that material. The manufacturer states NIS2 alignment for the PUMA Protector, along with CE and RED conformity, and classifies the system as EU AI Act compliant — which matters, because biometric recognition carries its own obligations under that act. All the more reason to state plainly that no biometric identification happens without an explicit legal basis. How your site is classified depends on sector, thresholds, and the current state of national implementation — worth checking properly once, per project.
Security services law. Where a contractor performs the guarding, it remains guarding under § 34a GewO. The robot is equipment, not a guard. The manufacturer describes the operating model explicitly as human-in-the-loop: the system detects and escalates, a person decides. Responsibility for the alert response has to be assigned unambiguously in the contract.
Measurable security and the sense of being safe
Resilience is measured in numbers: recovery times, reporting deadlines, availability rates. Its public effect only shows up where people trust their supply again without thinking about it. For three groups, "feeling safe" gets very specific.
Employees. The night shift that used to walk an unlit fuel line or a remote transformer bay alone is the first group where something changes. A robot that covers the exposed stretches first and flags anything unusual moves that work from "uncertain and alone" to "checked and accompanied." That is not a side effect. It is often the first solid result a pilot produces.
Neighbors and the wider public. Critical infrastructure rarely sits in open country. Substations border residential streets, pumping stations sit near recreation areas, logistics centers line through-roads. Meeting a robot at the fence at night, having never heard of it, is not an offer of security — it is an irritation. Knowing beforehand why it runs, what it records, and what it does not, turns the same machine into visible protection.
Customers, partners, and municipalities. Tenders, supplier audits, and conversations with regulators increasingly ask not only which measures exist, but for the evidence. Complete run logs turn a statement of intent into a claim someone can check.
Acceptance comes from explanation, not from technology
A patrol robot is a visible object. That is both its opportunity and its risk. It can read as concrete proof that an operator takes its responsibility seriously — or as a surveillance device nobody was told about.
What makes the difference is usually small and cheap:
- Unarmed and recognizable. No martial styling, no suggestion of intervention. The robot documents; it does not act on anyone.
- Name the purpose before the first run. A short briefing for staff and the works council, and — where the site is visible from public ground — for neighbors and the municipality, with a named contact.
- Draw clear analysis limits. No biometric identification and no facial recognition without an explicit legal basis. What you never collect needs no explaining.
- Make data minimization visible. Retention limits, purpose limitation, and access roles belong in the communication, not only in the file.
- Report back. Being able to say after six months how many runs took place and what came of them turns the debate into one about facts rather than assumptions.
This is not public relations. A security system in critical infrastructure carries two jobs: it has to work, and it has to be explainable. The second is not optional — without acceptance, a security concept is hard to sustain internally and easy to attack from outside.
Building the business case on the right comparison
The most common evaluation error is a straight swap: robot instead of guard. It almost always misleads, because it equates two different services.
Three questions work better.
- What does covering the currently uncovered hours cost today? The honest answer is usually that they are not covered, because they cannot be staffed. The comparison is then coverage versus no coverage, not robot versus human.
- What does a missed incident cost? For critical infrastructure, the relevant figure is rarely property damage. It is downtime, the reporting obligation, and the burden of proof.
- What does the documentation save? Audit preparation, insurance evidence, and incident reconstruction consume time that rarely shows up in the security cost center.
The manufacturer cites 70% faster incident response, three times the area coverage of human rounds, and 98% availability in field use. Read those as vendor figures and verify them on your own perimeter — that is what a pilot is for.
A defensible decision in 90 days
A perimeter project can be assessed in a manageable timeframe, as long as it is not set up as a technology demonstration.
Weeks 1–2: map the perimeter. Define the route, name the blind spots, mark the critical points (gates, transformers, fuel areas, cable runs, emergency exits). Output: a map with prioritized stops.
Weeks 3–4: define the alert chain. Who receives which alert, through which channel, within what response time, with what escalation? Skip this and the pilot produces images instead of security.
Weeks 5–6: legal and co-determination. DPIA, works agreement, retention concept, network connection, and hardening. In parallel with the technical work, not after it.
Weeks 7–12: pilot operation against defined metrics. Useful ones: completed runs per night, time to alert confirmation, false-alarm rate per route segment, aborted runs and their causes, maintenance effort per week.
Why this robot fits our portfolio
Veyra Robotics does not sell robotics for its own sake. Our job is translation between technology and operations: which use case holds, which platform fits it, what integrates, what is regulatorily clean, and what operations look like after go-live.
The PUMA M20 Protector interests us because it combines three things that rarely appear together in the security market: a durable outdoor platform built in Europe, analysis onboard instead of a cloud dependency, and a software layer with open interfaces.
That does not make it the answer to every security question. It makes it a component you can test, integrate, and cost out — which is precisely what critical infrastructure requires.
More on the system is on the product page at /en/produkte/puma-m20. To talk through your own perimeter, reach us at /en/kontakt, and our solution areas are at /en/loesungen.
