Laboratorio práctico de certificación

Objetivo

Que una activación de la analítica perimetral solo llegue al operador si es razonablemente real, y que llegue con contexto visual.

Problema que resuelve

Exceso de falsas alarmas y alarmas sin contexto: el operador dejó de mirar la cámara porque el 95 % de lo que recibe no requiere acción, y cuando algo ocurre no tiene forma de decidir rápido.

Funciones evaluadas

Árbol Dispositivo → Dominio → Objeto Habilitación selectiva de eventos Evento como disparador Obtener estado del objeto Condición DateTime Get snapshot dinámico Template Language {{ }} Analyze Image with AI Tipos de evento propios Dispatch event con evidencia Google Sheets KPI

Actividades

• Decido qué eventos habilitar y cuáles apagar, y justifico cada exclusión por escrito.
• Creo los tipos de evento propios que necesito, con nombre de negocio y nivel de severidad.
• Construyo el flujo disparado por la analítica de la cámara A.
• Aplico una restricción horaria.
• Consulto el estado de una fuente independiente.
• Uso al menos un metadato del evento como condición, no solo como disparador.
• Obtengo evidencia visual de la cámara que originó el evento.
• La verificación produce un veredicto inequívoco.
• Emito el evento de negocio con al menos dos imágenes.
• Registro todos los descartes con motivo y URL de la evidencia.
• Decido y justifico el orden de las verificaciones. Una tiene costo por ejecución.
• Construyo el KPI de falsas alarmas evitadas.

Condiciones mínimas

• C1 · Ningún evento llega al operador sin al menos una imagen adjunta.
• C2 · Al menos dos fuentes independientes de confirmación, además del disparador.
• C3 · La instantánea es dinámica: depende de la cámara que originó el evento.
• C4 · Al menos un metadato de la analítica condiciona el flujo.
• C5 · La verificación produce un valor booleano comparable, no texto libre.
• C6 · Toda rama false está conectada y produce un registro.
• C7 · Los descartes persisten fuera de Netsocs con motivo y evidencia recuperable.

Evidencias de este bloque

• Justificación escrita de eventos habilitados y excluidos.
• Captura del payload del evento con los metadatos anotados.
• Lienzo completo con los nodos renombrados.
• Captura del JSON Editor mostrando la variable {{ }}.
• Dos ejecuciones del mismo flujo con imágenes de cámaras distintas.
• Hoja de descartes con al menos 10 filas reales.
• KPI de falsas alarmas evitadas.

Casos de prueba asociados

T1 · T2 · T3 · T4 · T5 · T7 · T8 — ver la sección 06.

Objetivo

Que el sistema sepa, en todo momento, cuántas cámaras están sirviendo de verdad — no cuántas están encendidas.

Problema que resuelve

Muchas organizaciones pueden conocer si una cámara está conectada, pero no disponen de una métrica unificada que combine disponibilidad, calidad de imagen y grabación útil. Una cámara desenfocada, tapada o girada hacia una pared sigue reportando online.

Funciones evaluadas

Eventos de salud de canal Activador programado Obtener objetos Iterar elementos Modificar propiedad de un objeto KPI con drill-down Playback desde el NVR

Actividades

• Construyo el KPI de disponibilidad con la propiedad que entrega el driver, con drill-down.
• Compruebo si ese KPI detecta el problema de la cámara C. Si no lo detecta, ahí está la razón de este bloque.
• Diseño una ronda programada sobre los canales de video y justifico la frecuencia por costo y riesgo.
• Defino el criterio de utilidad de la imagen con veredicto inequívoco.
• Escribo el diccionario de valores de mi propiedad calculada antes de implementarla.
• Creo la propiedad mediante A.T.O.X. y construyo el KPI de utilidad de video.
• Añado la rama reactiva: los eventos nativos de salud producen un evento de negocio con criticidad.
• Verifico que el bucle se cierra y que la salida done hace algo útil.
• Resuelvo qué ocurre si llega una alarma y la cámara que debe verificarla está degradada.

Condiciones mínimas

• C8 · Existe una ronda programada que itera sobre los canales de video.
• C9 · Existe al menos una propiedad calculada por A.T.O.X., con diccionario documentado.
• C10 · Existen cuatro KPIs: disponibilidad, utilidad de video, falsas alarmas evitadas y cumplimiento.

Evidencias de este bloque

• Diccionario de valores de la propiedad calculada.
• Ficha de un objeto mostrando la propiedad creada.
• Historial de ejecuciones con N iteraciones por ciclo.
• Ambos KPIs, con al menos uno en drill-down.
• Justificación escrita de la frecuencia elegida y su costo estimado.

Casos de prueba asociados

T5 · T6 · T9 · T10 · T14 — ver la sección 06.

Objetivo

Que ningún evento crítico se quede sin que alguien lo atienda, y poder demostrarlo con un reloj.

Problema que resuelve

El evento llega, nadie lo atiende y no hay segundo nivel automático. Nadie sabe si el aviso llegó ni cuánto tardó la atención, de modo que el cumplimiento del servicio no es demostrable.

Funciones evaluadas

Objetos virtuales Modificar estado de un objeto Activador programado Iterar elementos Recognitions Notificación multicanal KPI de cumplimiento

Actividades

• Diseño el modelo de estados del incidente y lo dibujo antes de configurar nada.
• Decido dónde vivirá el estado y dónde vivirá el tiempo en Netsocs.
• Creo los objetos virtuales necesarios, organizados por dominio.
• Construyo el flujo de apertura: evidencia de dos cámaras, apertura del incidente y notificación.
• Construyo el flujo de vigilancia que revisa los incidentes abiertos.
• Defino qué señal indica que un operador ya atendió, y hago que el escalamiento la respete.
• Aseguro que un mismo incidente no se escala dos veces al mismo nivel.
• Calculo y registro el tiempo de atención al cerrarse.
• Construyo el KPI de cumplimiento.

Condiciones mínimas

• C11 · Existe un mecanismo de escalamiento por tiempo sin confirmación, y el reconocimiento del operador lo detiene.
• C12 · Existe una política de reconocimientos escrita: qué clasifica la máquina y qué la persona.

Evidencias de este bloque

• Diagrama del modelo de estados.
• Capturas de los objetos virtuales y sus propiedades.
• Lienzos de ambas automatizaciones, renombrados.
• Video cronometrado del ciclo completo: apertura → escalamiento → acuse → cierre.
• Log mostrando los eventos del mismo incidente correlacionados.
• Declaración de los umbrales utilizados en la sesión.

Casos de prueba asociados

T11 · T12 · T13 — ver la sección 06.

Objetivo

Dejar la solución documentada, exportada y transferible a otro integrador.

Problema que resuelve

Automatizaciones que solo entiende quien las hizo: nodos con el nombre por omisión, sin una nota que explique por qué se verifica en ese orden, y sin exportación. Cuando esa persona no está, la solución no se puede mantener ni reproducir en otra instalación.

Funciones evaluadas

Exportación de automatizaciones Documentación en el lienzo

Actividades

• Escribo la política de reconocimientos: una línea por estado, quién lo aplica y bajo qué condición.
• Renombro todos los nodos y añado al menos dos notas por automatización.
• Exporto todas las automatizaciones.

Condiciones mínimas

• C13 · Todos los nodos renombrados, ≥ 2 notas por automatización y todo exportado.
• C14 · Práctica obligatoria. La propiedad desenfoque la escribe la automatización, en ambos sentidos, sobre el objeto iterado. Cambiarla a mano no cuenta.
• C15 · Práctica obligatoria. Existe el KPI «Cámaras desenfocadas» con datasource Conteo de objetos, filtro por propiedad y agrupación por Dispositivo, con drill-down operativo.
• C16 · Práctica obligatoria. Se demuestra la recuperación: una cámara corregida desaparece del KPI tras reejecutar.

Casos de prueba asociados

T15 — ver la sección 06.

Problema que resuelve

Exceso de falsas alarmas y alarmas sin contexto visual.

Evento iniciador

Evento sobre el objeto de analítica de la cámara A. CONFIRMADO EN VIDEO

Condiciones

1. Ventana horaria — DateTime. CONFIRMADO EN VIDEO
2. Estado del sensor de una segunda cámara — Obtener estado del objeto + If. CONFIRMADO EN VIDEO
3. Presencia de persona en la escena — Analyze Image with AI o analítica de terceros por Send HTTP request. CONFIRMADO EN VIDEO

Orden sugerido: primero la condición gratuita, después la barata y solo al final la costosa. La decisión y su justificación son tuyas.

Acciones

• Dispatch event con evidencia adjunta.
• Google Sheets — una fila por descarte, con motivo y URL.
• Opcional: Ejecutar acción de objeto para audio disuasivo o relé. VALIDAR ANTES DE USAR

Excepciones a resolver

• La segunda cámara no responde.
• El servicio de análisis falla o excede el tiempo.
• La hoja externa no está disponible.
• Ráfaga de activaciones sobre el mismo objeto.

Resultado esperado

Solo las activaciones que superan las verificaciones llegan al operador, y llegan con foto. El resto queda registrado con su motivo y su evidencia, alimentando el KPI que demuestra el valor del filtrado.

Problema que resuelve

Falta de escalamiento y de confirmación de que la acción se ejecutó.

Evento iniciador

Dos automatizaciones coordinadas: una Evento crítico para la apertura, y un Activador programado de alta frecuencia para la vigilancia. CONFIRMADO EN VIDEO

Condiciones

1. ¿El incidente sigue abierto? — Obtener objetos filtrando por propiedad de estado.
2. ¿El operador ya lo atendió? — consulta del reconocimiento.
3. ¿Ha superado el umbral del nivel actual? — If sobre la diferencia de tiempo.

Acciones

• Modificar el estado de un objeto sobre el objeto virtual del incidente.
• Dispatch event de apertura y de cada escalamiento.
• Notificación al destinatario del nivel correspondiente.

Excepciones a resolver

• Doble escalamiento al mismo nivel.
• Incidente cerrado durante el ciclo.
• Cámara complementaria caída al abrir.
• Ciclo más largo que el intervalo del activador.

Resultado esperado

Un evento crítico abre un incidente con evidencia y notifica. Si nadie responde, escala al vencer cada umbral sin repetir el nivel anterior. Cuando el operador reconoce, el escalamiento se detiene y el tiempo de atención queda calculado.

Problema que resuelve

El control de acceso registra quién presentó la credencial, no quién pasó. Accesos fuera de horario y accesos acompañados quedan invisibles.

Evento iniciador

Evento sobre el objeto de la fuente de identidad. Si no hay hardware de acceso disponible, un objeto virtual de tipo botón con Button trigger cumple la misma función lógica — declarándolo. CONFIRMADO EN VIDEO

Biométricos Control ID y Hikvision aparecen en el catálogo de dominios pero no se demostró su evento en vivo. VALIDAR ANTES DE USAR

Condiciones

1. ¿Dentro del horario autorizado? — DateTime.
2. ¿Cuántas personas hay en la escena? — verificación visual o analítica de conteo.

Acciones

• Tres Dispatch event diferenciados: acceso verificado, fuera de horario y posible acceso acompañado.
• Set event recognition automático solo en el caso normal.
• Registro del expediente en la hoja externa.

Resultado esperado

El operador ve solo excepciones; el auditor ve el expediente completo y puede saltar al video grabado desde el evento.

Problema que resuelve

Falta de correlación entre intrusión y video, y dificultad para integrar fabricantes distintos.

Evento iniciador

La fuente de intrusión es intercambiable: entrada de alarma de la propia cámara, PIR, contacto seco, o un tercero publicando en un Webhook. CONFIRMADO EN VIDEO

Paneles Hikvision y AJAX están integrados como drivers, pero su evento disparando una automatización no se demostró. VALIDAR ANTES DE USAR

Condiciones

1. ¿El sistema estaba armado? MOSTRADO O MENCIONADO
2. ¿La cámara de la zona muestra actividad?
3. ¿Hay una persona en la escena?

Acciones

• Dispatch event identificando la zona, no solo la cámara.
• Notificación multicanal.
• Registro de descartes.

Resultado esperado

El operador recibe la intrusión confirmada con las imágenes de la zona correcta y puede saltar al video grabado. Las activaciones con el sistema desarmado no lo molestan, pero quedan registradas.