Robotics Control Room VdS: connection to emergency and service control rooms

A patrol robot without a control room link is a local sensor on wheels. It generates events that nobody acknowledges. Only the connection to a VdS-approved emergency and service control room (Notruf- und Service-Leitstelle, NSL) turns a detection into an insurance-relevant response chain. This article describes what security managers in industrial and KRITIS operations must expect technically, contractually and from a regulatory perspective when integrating robotic platforms into existing VdS-NSL structures.

Robotics Control Room VdS: why the link decides on certification

VdS Schadenverhütung GmbH is a private-sector certification and testing body, not a state authority. Its approvals are legally treated as recognised state of the art. Property insurers accept this status as a prerequisite for coverage. In practice this means: without VdS approval of the NSL and without VdS-compliant connection, a loss event remains in the claims process without recognition of the detection chain.

VdS-approved NSL are the de facto standard in Germany for alarm transmission in industry and KRITIS. A patrol robot that only stores local events in an onboard log delivers neither insurers nor supervisory authorities an auditable response chain. Guideline VdS 3138 defines technical interface requirements for video-based alarm verification and is the central reference against which robot event streams must be measured.

Quarero QR-2 and QR-3 deliver sensor data in formats that VdS-approved receiving systems can process without protocol breaks. This includes ONVIF-compliant video streams, structured event metadata and heartbeat telemetry. Without this compatibility, isolated solutions emerge that are vulnerable in regulatory and insurance terms in the event of a claim.

VdS-NSL requirements for robotic sensor sources

An NSL only accepts sensor sources as connectable if they meet defined minimum technical criteria. For robotic platforms the following points apply as the entry threshold.

Audit-grade timestamps. All event streams must be NTP-synchronised, typically against a redundant time server in the customer network. If a robot's clock drifts by more than 500 milliseconds, correlation with other sensor sources loses its forensic value. [Source reference to NSL requirements documentation required]

Encrypted transmission. TLS 1.3 is mandatory. Cleartext MQTT or unauthenticated HTTP endpoints are rejected by VdS-approved receiving systems. Certificate rotation occurs at least annually, quarterly for higher protection classes.

Unique object IDs. Every robot and every sensor receives a unique ID, stored in the NSL database and referenced in the event log. Anonymous or generic IDs are not permitted.

Video quality. At least 720p for alarm verification, thermal as a complement on QR-2 and QR-3. Lower resolutions mean dispatchers cannot make a reliable visual assessment, and the alarm is classified as non-verifiable.

Heartbeat. A heartbeat signal every 60 seconds is standard (cf. VdS 2311 or NSL vendor specifications; source reference required). If it fails, the NSL triggers a sabotage or availability alarm. This mechanism is also why robots with unstable wireless links are not operated in NSL connection.

Local ring buffer. 72 hours of retention on the robot is the practical minimum. Insurers and investigating authorities request forensic submissions within 48 hours of an event.

Platform-side details are in the descriptions of the QR-2 outdoor patrol and the QR-3 with LiDAR and drone detection.

Escalation chain: from robot sensor to intervention force

The escalation chain has five stages. Each stage has a defined time window and a documented handover.

Stage 1: Onboard detection. Person detection, thermal anomaly or drone echo are classified locally on the robot. Latency under 200 milliseconds.

Stage 2: Local plausibility check. Within 4 seconds, a second sensor source (for example thermal after RGB) confirms the detection. If confirmation fails, the event is passed on with a low confidence score or discarded.

Stage 3: Transmission to VdS-NSL. Live video, geo-coordinate and event metadata go encrypted to the receiving system. Transmission is normally completed in under 2 seconds.

Stage 4: Dispatcher verification. The NSL operator reviews the stream, orders an intervention by the guard service or places a police emergency call. Reaction time is fixed in the SLA, typically 30 seconds for priority alarms.

Stage 5: Post-processing. Event log, video sequence and dispatcher decision are archived as a closed case. This documentation is the basis for claims settlement and KRITIS evidence.

Alarm verification: how robotics reduces false alarms

Static CCTV produces false alarm rates of up to 95 percent according to industry data from BDSW. [Source: BDSW, Zahlen Daten Fakten, accessed 2025] The consequence: NSL dispatchers spend most of their shift visually checking irrelevant events. Police authorities respond with fee notices for unfounded callouts, in several federal states above 200 euros per incident. [Source reference to the respective state fee regulation required]

Robotic multi-sensor fusion (RGB, thermal, LiDAR) verifies before transmission. An event only counts as an alarm if at least two independent sensors confirm the object. The QR-3 also distinguishes drones from birds via Doppler signature of the radar module, which markedly reduces the false alarm rate in perimeter situations.

A confidence score between 0 and 1 is transmitted to the NSL with each event. Dispatchers prioritise their queue based on this value. Events with a score above 0.85 are processed immediately, lower values run into a review loop. The demonstrable reduction in the false alarm rate cuts two cost items: the NSL processing fee and the risk of police callout fees.

KRITIS context: § 8a BSIG, KRITIS Umbrella Act and NSL requirement

Operators of critical infrastructure must demonstrate their detection and response capability under KritisV. The physical component of this obligation is equated in supervisory audit practice with connection to a VdS-approved NSL, because there a documented 24/7 response is maintained.

The KRITIS Umbrella Act (KRITIS-Dachgesetz) specifies the physical resilience requirements for KRITIS operators from 2026 (cf. BT-Drs. 20/9262, status March 2025). Detection, verification and intervention must be demonstrable as a closed process chain. A robot that only reports to an internal guard station does not meet this evidence requirement. 24/7 in-house staffing is rarely cost-covering.

The NIS-2 Directive requires documented incident handling and reporting obligations. Without NSL protocol this documentation remains incomplete: event time, verification and dispatcher decision sit in different systems. A common event bus architecture is recommended, in which robot events and IT security incidents can be correlated. An overview of the regulatory situation is provided by KRITIS requirements at a glance, the board perspective by NIS-2 board liability 2026.

EN ISO 13482 (standard overview) defines safety requirements for personal care and service robots and is applicable to mobile patrol platforms. It is not a detection standard but a machine safety standard, and is used in KRITIS audits to assess the physical platform.

Interfaces and protocols: what matters in integration

Integrators look for concrete protocol names, not architecture metaphors. For the link to VdS-NSL the following interfaces are relevant.

ESPA 4.4.4. The established standard for classic alarm handover to NSL receiving systems. Supported by practically all VdS-approved receiving systems and remains the common denominator for legacy integrations.

ONVIF Profile T. For video transmission, compatible with VdS-approved receiving systems. Profile T supports H.264 and H.265 as well as metadata streaming, which is relevant for transmitting bounding boxes and classification results.

REST API with OAuth2. For event metadata, status queries and configuration changes. OAuth2 tokens are issued with short lifetimes (typically 15 minutes) and renewed via a refresh mechanism.

SIA DC-09. Optional path for connection to legacy NSL whose IP receivers are not upgraded to modern stacks. DC-09 transports Contact-ID or SIA events over IP and is widespread in older receiving centres.

Quarero supplies preconfigured connectors for the eight largest VdS-NSL in the DACH region. The connectors include mapping tables, certificate management and heartbeat logic. Integration effort is limited to network approvals and dispatcher training.

Contractual and commercial aspects

The NSL connection fee is typically between 80 and 200 euros monthly per object, regardless of whether the sensor source is a robot, a CCTV system or an intrusion alarm panel. [Source reference or market survey required] This item therefore stays stable when a robotic system is added or guard posts are replaced.

Robots in the Robotics-as-a-Service model start at Quarero from 3,200 euros monthly per platform, NSL connection included in the setup. Compared to 24/7 guard posts, which depending on tariff area and qualification cost 15,000 to 25,000 euros monthly [source reference, e.g. BDSW wage agreement, required], a combination of NSL plus one to two robots replaces two posts in continuous patrol. A detailed calculation is provided by the TCO comparison for guard services.

The SLA with the NSL defines two reaction times: the dispatcher processing time (typically 30 seconds to verification) and the response time of the intervention force (typically 20 minutes in urban areas, 30 to 45 minutes in rural areas). Both values must be fixed contractually and measurable in the event logs.

Insurers accept the VdS-NSL protocol as proof of loss without further appraisal. This shortens claims processes from weeks to days. In-house forensic preparation in a loss event is largely eliminated.

Implementation path in 14 days

Connecting a robot fleet to an NSL is not a multi-month project if the NSL already has a modern receiving system. A typical schedule looks as follows.

Day 1 to 3: selection and clarification. Selection of the VdS-NSL, review of the existing receiving technology. Question: is an IP receiver available that processes ONVIF and REST, or must a legacy path via SIA DC-09 be used? Clarification of contract terms and connection fees.

Day 4 to 7: network setup. Construction of a VPN tunnel between the robot fleet and NSL. Certificate exchange, configuration of firewall rules. Testing the TLS 1.3 connection and validating time synchronisation.

Day 8 to 10: event mapping. Configuration of the mapping table: which robot event type triggers which alarm code in the NSL? Test alarms across all relevant detection classes. Dispatcher training on operating the live video interface and on evaluating the confidence score.

Day 11 to 12: trial operation. Live operation with reduced escalation. Alarms are processed in the NSL, but interventions only triggered in consultation with the security manager. The goal is validation of the false alarm rate under real conditions.

Day 13 to 14: acceptance. Acceptance protocol by the security manager, formal release of the connection, transition into regular operation with full intervention chain. Entry into the KRITIS documentation and notification to the property insurer.

For perimeter situations with combined ground and air detection, parallel reading on perimeter protection for industrial parks is recommended.

Next step

If your VdS-NSL is already connected and you want to check whether your existing receiving system can process robotic sensor sources without a hardware change, arrange a technical conversation via book a technical initial consultation. We deliver a compatibility matrix for your specific NSL and a written integration plan with effort estimate.