Resumen directo: integrar análisis de vídeo con Manitou no debería obligar a una CRA a sustituir su software receptor. El patrón más controlable consiste en enlazar cada señal con su clip, enviar el contexto mínimo a una API, recibir el resultado mediante un webhook autenticado y mostrar prioridad, relevancia y explicación dentro del flujo que ya utiliza el operador. La implantación debe contemplar reintentos, duplicados, trazabilidad y un modo seguro de continuar si el análisis no está disponible.
Una integración que respeta el sistema receptor
Manitou, de Bold Group, es una plataforma de automatización utilizada en operaciones de monitorización. En una integración de análisis de vídeo, Manitou continúa siendo el entorno en el que la CRA recibe y gestiona la alarma. El servicio de análisis actúa como componente especializado: recibe el clip y su contexto, procesa el evento y devuelve un resultado estructurado.
Esta separación reduce el acoplamiento. La CRA conserva cuentas, protocolos, contactos, estados y auditoría en el sistema de gestión; el analizador no necesita replicar toda esa lógica. Para mantenerla, conviene definir un contrato estable de identificadores y estados en lugar de depender de textos de pantalla o automatizaciones frágiles.
Componentes mínimos
- Origen de alarma: panel, VMS, cámara o plataforma que genera la señal y el vídeo asociado.
- Manitou o middleware de la CRA: correlaciona cuenta, zona, evento y procedimiento.
- API de análisis: acepta el medio y una tarea con contexto limitado.
- Receptor de webhooks: valida la notificación, evita duplicados y actualiza el evento correcto.
- Interfaz del operador: muestra el vídeo y la información de triaje sin ocultar las reglas de actuación.
La forma exacta de conectar estos componentes depende de la versión, módulos y opciones de integración disponibles en cada instalación. Antes de diseñar el conector, la CRA debe confirmar con Bold Group o su integrador qué interfaces están soportadas en su entorno. Este artículo describe un patrón técnico, no sustituye la documentación contractual de Manitou.
Flujo API paso a paso
El flujo de VideoIntelligence puede organizarse en cuatro operaciones. Los nombres siguientes reflejan el contrato del producto descrito en esta web; en una implantación se deben usar siempre la documentación y credenciales vigentes.
POST /v1/media: crea un recurso de medio y devuelve un identificador. La CRA conserva la relación entre ese identificador y la alarma de Manitou.PUT /v1/media/{id}/clip: carga el clip asociado. El conector debería comprobar formato, tamaño, duración y respuesta antes de solicitar el análisis.POST /v1/tasks: crea la tarea e incorpora el contexto necesario, como zona, horario o tipo de evento, sin enviar datos ajenos a la finalidad.- Webhook
alert.triggered: notifica el resultado. El receptor verifica la autenticidad, identifica la tarea y registra la actualización de forma idempotente.
Correlación: el detalle que evita resultados huérfanos
Cada paso es asíncrono y puede terminar en un orden distinto al esperado. Por eso se recomienda guardar, en una tabla de integración o mecanismo equivalente, el identificador de alarma de Manitou, el identificador de medio, el de tarea y el estado. No conviene usar el nombre de cámara o una marca de tiempo como única clave: pueden repetirse o variar entre sistemas.
Un identificador de correlación generado por la CRA puede viajar en los metadatos permitidos y aparecer en los registros. No debería incluir información personal legible si una referencia aleatoria es suficiente. La trazabilidad mejora cuando todos los componentes registran esa misma referencia junto con la fecha y el resultado de cada operación.
Ejemplo operativo: alarma perimetral nocturna
Manitou recibe una señal de la zona 7 y el middleware recupera un clip de veinte segundos. El conector crea el medio, carga el archivo y solicita análisis con el dato «perímetro exterior» y el estado horario aplicable. Mientras espera, la alarma permanece visible conforme al procedimiento de la CRA. Cuando llega el webhook, el conector valida su firma, busca la tarea y adjunta al evento la prioridad y la explicación. Si el webhook no llega dentro del plazo operativo, la señal no desaparece: sigue la ruta de contingencia definida por la central.
Seguridad, autenticidad y tolerancia a fallos
Una API de vídeo maneja material sensible y una notificación puede influir en el orden de trabajo. La seguridad no se limita a cifrar el transporte. Deben protegerse credenciales, archivos, registros, webhooks y permisos de cada servicio.
Verificar la firma HMAC del webhook
El receptor debe calcular la firma sobre el cuerpo original de la petición y compararla con la cabecera recibida usando una comparación en tiempo constante. Es importante verificar también una marca temporal o mecanismo equivalente para limitar ataques de repetición. El secreto debe almacenarse en un gestor de secretos, rotarse de manera controlada y no aparecer en logs.
La guía de seguridad de servicios web de OWASP reúne controles relevantes como TLS, autenticación, validación de entrada y limitación de peticiones. Para APIs, el OWASP API Security Project ofrece además un marco reputado para revisar riesgos comunes.
Idempotencia y reintentos
Las redes fallan y los emisores suelen reintentar. El receptor debe aceptar que el mismo webhook llegue más de una vez y producir el mismo estado final sin duplicar notas, alarmas o acciones. Una clave única por evento y tipo de notificación permite registrar el primer procesamiento y responder correctamente a los siguientes.
Para llamadas salientes, se pueden reintentar errores transitorios con espera creciente y un límite. No se debería reintentar ciegamente una petición inválida. Si la respuesta es ambigua, una clave de idempotencia evita crear varias tareas para la misma alarma. Las incidencias persistentes deben pasar a una cola de revisión o «dead letter» con alerta técnica.
Minimización y control de acceso
El conector debería enviar solo el clip y contexto necesarios. Nombres de abonados, teléfonos, códigos de acceso u otros datos del expediente no son imprescindibles para interpretar la escena. Las cuentas de servicio deben tener permisos mínimos y distintos por entorno; desarrollo no debería acceder a vídeos de producción.
Comparativa de decisiones de diseño
| Decisión | Opción recomendada | Riesgo que reduce |
|---|---|---|
| Entrega de resultado | Webhook firmado y consulta de respaldo | Suplantación y pérdida de notificación |
| Identificación | ID único de correlación | Asignar el resultado a otra alarma |
| Duplicados | Procesamiento idempotente | Notas o tareas repetidas |
| Caída del analizador | Continuidad del flujo original | Ocultar o bloquear alarmas |
| Datos enviados | Clip y contexto mínimo | Exposición innecesaria de información |
Qué debe recibir el operador
El resultado técnico solo crea valor si se traduce en una interfaz comprensible. Puede incluir relevant, priority_label, actividad observada y reasoning. Esas propiedades apoyan el triaje, pero la CRA debe definir su significado operativo. Por ejemplo, P0–P4 no debería asumirse como una clasificación legal o un estándar universal si es una escala interna del producto.
La explicación debe describir evidencia visible y limitaciones: «Persona cruza de exterior a interior por la zona perimetral; visibilidad parcial durante dos segundos». El operador necesita acceso al clip para contrastarla. Si la imagen está dañada o no contiene suficiente contexto, el sistema debe poder devolver «no verificable» en vez de una certeza artificial.
Mapeo a la interfaz de Manitou
El integrador puede mapear la prioridad a una cola, un atributo o una nota, según las capacidades soportadas. Antes de hacerlo debe resolver tres preguntas: qué verá el operador, qué ocurrirá si no hay resultado y qué datos quedarán en auditoría. El mapeo se prueba con cuentas de ensayo y nunca directamente con automatismos de respuesta no validados.
Plan de despliegue en una CRA
- Inventario: documentar versiones, origen de clips, formatos, volumen, latencia tolerable y campos disponibles.
- Entorno de prueba: usar credenciales y endpoints separados con clips autorizados para ensayo.
- Pruebas de contrato: comprobar respuestas válidas e inválidas, timeouts, firmas incorrectas, duplicados y eventos fuera de orden.
- Modo sombra: recibir resultados sin cambiar la cola del operador y compararlos con decisiones reales.
- Piloto limitado: activar la presentación para un grupo de cámaras y turnos, con reversión sencilla.
- Operación: monitorizar errores, colas, disponibilidad de clips y discrepancias, y revisar accesos y retención.
Los criterios de aceptación deben centrarse en comportamiento verificable: correlación correcta, ausencia de duplicados, continuidad ante fallos, comprensión por el operador y registro de decisiones. No basta con que la llamada devuelva un código 200 en una demostración.
Preguntas frecuentes
¿Hay que sustituir Manitou para añadir análisis de vídeo?
No es el patrón descrito aquí. Manitou conserva la gestión de la alarma y el análisis se incorpora mediante interfaces soportadas y un conector adaptado a la instalación.
¿Qué pasa si VideoIntelligence no responde?
La integración debe mantener el flujo original de la CRA y aplicar una contingencia documentada. Una dependencia auxiliar no debería hacer desaparecer ni bloquear la alarma.
¿Por qué usar webhooks en lugar de consultar constantemente?
El webhook comunica el resultado cuando está disponible y reduce consultas innecesarias. Una consulta de respaldo puede ayudar a reconciliar notificaciones perdidas.
¿La firma HMAC cifra el contenido?
No. Sirve para verificar autenticidad e integridad. El cifrado en tránsito requiere HTTPS/TLS, y el almacenamiento necesita sus propios controles.
¿Qué debe probarse antes de producción?
Formatos, correlación, reintentos, duplicados, firmas, timeouts, permisos, contingencia y visualización. También debe confirmarse el procedimiento con operadores y supervisores.
VideoIntelligence · Análisis de vídeo para CRA
De cada clip a una prioridad explicada, antes del operador
VideoIntelligence analiza el vídeo asociado a la alarma, indica relevancia y prioridad P0–P4, y devuelve una explicación a tu software de recepción mediante API. En la demo revisamos cómo encajaría en el flujo de tu central y cómo medirlo con tu propio histórico.