Central VdS robótica: conexión a centrales receptoras de alarma y servicio

Un robot patrulla sin conexión a una central receptora es un sensor local con ruedas. Genera eventos que nadie confirma. Solo la conexión a una central receptora de alarmas y servicio (NSL) reconocida por VdS convierte una detección en una cadena de respuesta relevante para el seguro. Este artículo describe lo que los responsables de seguridad en plantas industriales y operadores KRITIS deben esperar al integrar plataformas robóticas en estructuras NSL VdS existentes, en lo técnico, contractual y regulatorio.

Central VdS robótica: por qué la conexión decide la certificación

La VdS Schadenverhütung GmbH es una entidad privada de certificación y ensayo, no un organismo estatal. Sus reconocimientos se consideran legalmente estado de la técnica reconocido. Los aseguradores de daños patrimoniales los aceptan como requisito de entrada para la cobertura. En la práctica: sin reconocimiento VdS de la NSL y sin conexión conforme a VdS, un siniestro queda sin reconocimiento de la cadena de detección durante el proceso de regulación.

Las NSL reconocidas por VdS son en Alemania el estándar de facto para la transmisión de alarmas en industria y KRITIS. Un robot patrulla que solo registra eventos locales en un log a bordo no entrega a aseguradores ni a autoridades una cadena de respuesta auditable. La directriz VdS 3138 define los requisitos técnicos de interfaz para verificación de alarma basada en vídeo y es la referencia central para evaluar flujos de eventos robóticos.

Los Quarero QR-2 y QR-3 entregan datos sensoriales en formatos que el equipo receptor reconocido por VdS puede procesar sin ruptura de protocolo. Esto incluye flujos de vídeo conformes a ONVIF, metadatos de evento estructurados y telemetría heartbeat. Sin esta compatibilidad surgen soluciones aisladas, vulnerables en lo regulatorio y en lo asegurador.

Requisitos de la NSL VdS para fuentes robóticas

Una NSL solo acepta fuentes sensoras como conectables si cumplen criterios técnicos mínimos definidos. Para plataformas robóticas rigen los siguientes umbrales de entrada.

Marcas de tiempo auditables. Todos los flujos de eventos deben estar sincronizados por NTP, habitualmente contra un servidor de tiempo redundante en la red del cliente. Si el reloj de un robot deriva más de 500 milisegundos, la correlación con otras fuentes sensoras pierde valor forense. [Referencia a la documentación de requisitos NSL pendiente]

Transmisión cifrada. TLS 1.3 es obligatorio. MQTT en texto claro o endpoints HTTP no autenticados son rechazados por equipos receptores reconocidos por VdS. La rotación de certificados se realiza al menos anualmente, en clases de protección superiores trimestralmente.

IDs de objeto unívocos. Cada robot y cada sensor recibe un ID unívoco que se almacena en la base de datos NSL y se referencia en el protocolo de eventos. No se admiten IDs anónimos o genéricos.

Calidad de vídeo. Mínimo 720p en verificación de alarma, térmico complementario en QR-2 y QR-3. Resoluciones inferiores impiden a los operadores realizar una evaluación visual fiable, y la alarma se clasifica como no verificable.

Heartbeat. Una señal heartbeat cada 60 segundos es estándar (cf. VdS 2311 o especificaciones del fabricante NSL; referencia pendiente). Si falta, la NSL dispara una alarma de sabotaje o disponibilidad. Este mecanismo es también la razón por la que no se operan robots con conexión radio inestable en una conexión NSL.

Anillo de memoria local. 72 horas de retención en el robot son el mínimo práctico. Aseguradores y autoridades investigadoras solicitan entregas forenses dentro de las 48 horas posteriores al evento.

Detalles de la plataforma en la descripción del QR-2 patrulla exterior y del QR-3 con LiDAR y detección de drones.

Cadena de escalado: del sensor robótico a la fuerza de intervención

La cadena de escalado se divide en cinco niveles. Cada nivel tiene una ventana temporal definida y una entrega documentada.

Nivel 1: detección a bordo. Detección de personas, anomalía térmica o eco de dron se clasifican localmente en el robot. Latencia inferior a 200 milisegundos.

Nivel 2: plausibilización local. En 4 segundos, una segunda fuente sensora (por ejemplo, térmica tras RGB) confirma la detección. Si no se confirma, el evento se transmite con confidence-score bajo o se descarta.

Nivel 3: transmisión a la NSL VdS. Vídeo en vivo, geocoordenada y metadatos de evento se envían cifrados al equipo receptor. La transmisión se completa normalmente en menos de 2 segundos.

Nivel 4: verificación por operador. El operador NSL revisa el flujo, ordena una intervención por el servicio de vigilancia o cursa aviso a la policía. El tiempo de reacción está fijado en el SLA, habitual del sector: 30 segundos en alarmas prioritarias.

Nivel 5: tratamiento posterior. Protocolo de evento, secuencia de vídeo y decisión del operador se archivan como expediente cerrado. Esta documentación es la base para la regulación del siniestro y la acreditación KRITIS.

Verificación de alarma: cómo la robótica reduce falsas alarmas

El CCTV estático genera, según datos sectoriales del BDSW, tasas de falsa alarma de hasta el 95 por ciento. [Fuente: BDSW, Zahlen Daten Fakten, consultado 2025]. Consecuencia: los operadores NSL pasan la mayor parte de su turno verificando visualmente eventos irrelevantes. Las autoridades policiales reaccionan con tasas por intervenciones infundadas, en varios estados federados por encima de 200 euros por incidencia. [Referencia a la ordenanza de tasas del Land correspondiente pendiente]

La sensórica robótica múltiple (RGB, térmico, LiDAR) verifica antes de transmitir. Un evento de movimiento solo se considera alarma si al menos dos sensores independientes confirman el objeto. El QR-3 distingue además drones de aves mediante firma Doppler del módulo radar, lo que reduce de forma medible la tasa de falsa alarma en situaciones de perímetro.

Por cada evento se transmite a la NSL un confidence-score entre 0 y 1. Los operadores priorizan su cola según ese valor. Eventos con score superior a 0,85 se procesan de inmediato, valores inferiores entran en un bucle de revisión. La reducción demostrable de la tasa de falsa alarma baja dos partidas: la tarifa de gestión de la NSL y el riesgo de tasas policiales por intervención.

Contexto KRITIS: § 8a BSIG, Dachgesetz y obligación NSL

Los operadores de infraestructuras críticas deben acreditar según KritisV su capacidad de detección y respuesta. La componente física de esta obligación se equipara, en la práctica de supervisión, a la conexión a una NSL reconocida por VdS, porque allí se mantiene una respuesta 24/7 documentada.

La KRITIS-Dachgesetz precisa los requisitos de resiliencia física para operadores KRITIS desde 2026 (cf. BT-Drs. 20/9262, marzo de 2025). Detección, verificación e intervención deben ser acreditables como cadena de proceso cerrada. Un robot que solo notifica a un puesto interno de vigilancia no cumple esta acreditación. La cobertura 24/7 interna rara vez es viable en costes.

La Directiva NIS-2 exige tratamiento documentado de incidentes y obligaciones de notificación. Sin protocolo NSL, esta documentación queda incompleta: momento del evento, verificación y decisión del operador residen en sistemas distintos. Se recomienda una arquitectura de bus de eventos común en la que los eventos robóticos y los incidentes de seguridad TI sean correlacionables. Una visión general regulatoria la ofrece requisitos KRITIS de un vistazo, la perspectiva del consejo NIS-2 responsabilidad del consejo 2026.

EN ISO 13482 (resumen de la norma) define requisitos de seguridad para robots asistenciales y de servicio personales y es aplicable a plataformas patrulla móviles. No es una norma de detección, sino de seguridad de máquinas, y se aplica en auditorías KRITIS para evaluar la plataforma física.

Interfaces y protocolos: lo que cuenta en la integración

Los integradores buscan nombres concretos de protocolo, no metáforas de arquitectura. Para la conexión a NSL VdS son relevantes las siguientes interfaces.

ESPA 4.4.4. Estándar consolidado para la entrega clásica de alarma al equipo receptor NSL. Soportado por prácticamente todos los equipos receptores reconocidos por VdS y sigue siendo el denominador común para integraciones legacy.

ONVIF Profile T. Para transmisión de vídeo, compatible con equipos receptores reconocidos por VdS. Profile T soporta H.264 y H.265 así como streaming de metadatos, relevante para la transmisión de bounding-boxes y resultados de clasificación.

API REST con OAuth2. Para metadatos de evento, consultas de estado y cambios de configuración. Los tokens OAuth2 se emiten con vida corta (típicamente 15 minutos) y se renuevan vía refresh.

SIA DC-09. Vía opcional para conexión a NSL legacy cuyos receptores IP no están actualizados a stacks modernos. DC-09 transporta eventos Contact-ID o SIA sobre IP y está extendido en centrales receptoras antiguas.

Quarero entrega conectores preconfigurados para las ocho mayores NSL VdS de la región DACH. Los conectores incluyen tablas de mapping, gestión de certificados y lógica heartbeat. El esfuerzo de integración se limita a aperturas de red y formación de operadores.

Aspectos contractuales y comerciales

La tarifa de conexión NSL se sitúa habitualmente entre 80 y 200 euros mensuales por objeto, con independencia de si la fuente sensora es un robot, una instalación CCTV o una central de intrusión. [Referencia o estudio de mercado pendiente]. Esta partida permanece estable cuando se añade un sistema robótico o se sustituyen vigilantes.

Los robots en el modelo Robotics-as-a-Service comienzan en Quarero desde 3.200 euros mensuales por plataforma, conexión NSL incluida en el setup. Frente a vigilantes 24/7, que según zona tarifaria y cualificación cuestan entre 15.000 y 25.000 euros mensuales [referencia, por ejemplo convenio salarial BDSW, pendiente], una combinación de NSL más uno o dos robots sustituye a dos puestos en ronda continua. Un cálculo detallado lo aporta la comparativa TCO de vigilancia.

El SLA con la NSL define dos tiempos de reacción: el tiempo de gestión del operador (típicamente 30 segundos hasta la verificación) y el tiempo de llegada de la fuerza de intervención (típicamente 20 minutos en zonas urbanas, 30 a 45 minutos en zonas rurales). Ambos valores deben fijarse contractualmente y ser medibles en los protocolos de evento.

Los aseguradores aceptan el protocolo NSL VdS como prueba de siniestro sin peritaje adicional. Esto reduce los procesos de regulación de semanas a días. La preparación forense propia en caso de siniestro queda en gran parte eliminada.

Camino de implementación en 14 días

La conexión NSL de una flota robótica no es un proyecto de varios meses si la NSL ya dispone de un equipo receptor moderno. Un calendario típico es el siguiente.

Día 1 a 3: selección y aclaración. Selección de la NSL VdS, revisión del equipo receptor existente. Pregunta: ¿hay un receptor IP que procese ONVIF y REST, o debe usarse SIA DC-09 como vía legacy? Aclaración de plazos contractuales y tarifas de conexión.

Día 4 a 7: setup de red. Establecimiento de un túnel VPN entre flota robótica y NSL. Intercambio de certificados, configuración de reglas de firewall. Test de la conexión TLS 1.3 y validación de la sincronización temporal.

Día 8 a 10: mapping de eventos. Configuración de la tabla de mapping: ¿qué tipo de evento robótico dispara qué código de alarma en la NSL? Alarmas de prueba sobre todas las clases de detección relevantes. Formación de operadores en el manejo de la interfaz de vídeo en vivo y en la evaluación del confidence-score.

Día 11 a 12: operación de prueba. Operación en vivo con escalado reducido. Las alarmas se gestionan en la NSL, pero las intervenciones solo se disparan en acuerdo con el responsable de seguridad. Objetivo: validación de la tasa de falsa alarma en condiciones reales.

Día 13 a 14: recepción. Acta de recepción por el responsable de seguridad, liberación formal de la conexión, paso a operación regular con cadena de intervención completa. Inscripción en la documentación KRITIS y comunicación al asegurador de daños patrimoniales.

Para situaciones de perímetro con detección combinada terrestre y aérea conviene la lectura paralela de protección perimetral para parques industriales.

Siguiente paso

Si su NSL VdS ya está conectada y desea comprobar si su equipo receptor existente puede procesar fuentes robóticas sin sustitución de hardware, concierte una conversación técnica en reservar primera reunión técnica. Entregamos una matriz de compatibilidad para su NSL concreta y un plan de integración por escrito con estimación de esfuerzo.