Un sistema de comando y despacho de emergencias puede parecer listo cuando las consolas de operador están en línea, los terminales de campo pueden registrarse y la interfaz principal muestra un estado normal. Estas comprobaciones confirman que los componentes individuales funcionan, pero no demuestran que el flujo de trabajo completo de emergencia operará correctamente.

Antes de la entrega, las pruebas deben seguir el mismo camino que un incidente real: se reporta un evento, la sala de control identifica su origen, el operador selecciona los recursos de comunicación apropiados, se entregan instrucciones al personal de campo, se registran las respuestas y el sistema continúa operando si falla un enlace de red, un servidor o la fuente de alimentación.

Plan de aceptación

La aceptación comienza con un plan de pruebas aprobado. Sin criterios de éxito y fracaso definidos, el equipo del proyecto puede realizar numerosas demostraciones mientras deja preguntas operativas críticas sin resolver.

El plan debe basarse en el diseño del sistema, la matriz de comunicaciones, los procedimientos de incidentes y los requisitos contractuales. Debe identificar las funciones que se van a probar, los resultados esperados, los responsables de las pruebas, los requisitos de evidencia y el personal autorizado para aprobar cada resultado.

Cada caso de prueba necesita:

• Un número de prueba único y una categoría funcional.

• Las condiciones iniciales del sistema y la red.

• Las acciones del operador requeridas para realizar la prueba.

• El resultado esperado y el tiempo de respuesta máximo permitido.

• Los dispositivos, extensiones, grupos y ubicaciones involucrados.

• La evidencia que se debe conservar, como registros, grabaciones, capturas de pantalla o registros de alarmas.

• El procedimiento para registrar defectos y completar una nueva prueba.

El inventario de equipos también debe verificarse antes de comenzar las pruebas funcionales. Los nombres de los dispositivos, direcciones IP, cuentas SIP, ubicaciones de instalación, puertos de switch, versiones de firmware y fuentes de alimentación deben coincidir con los registros aprobados. Un terminal con nombre incorrecto puede completar una llamada con éxito mientras muestra la ubicación incorrecta al despachador.

Sincronice el reloj del sistema antes de recopilar evidencia. Los registros de despacho, las grabaciones de llamadas, los eventos de alarma, las imágenes de video y las acciones del operador no se pueden correlacionar con precisión cuando diferentes subsistemas utilizan referencias de tiempo diferentes.

Comunicación de campo

Cada terminal instalado debe probarse desde su ubicación real. Probar un solo dispositivo de muestra no confirma el estado de otras rutas de cable, puertos de switch, micrófonos, altavoces, cámaras o entradas de alarma externas.

Llamadas de voz

Las llamadas de prueba deben cubrir teléfonos de campo, intercomunicadores SIP, consolas de despacho, teléfonos IP, canales de radio y cualquier conexión telefónica externa autorizada. Verifique tanto la comunicación entrante como la saliente.

El operador y el usuario de campo deben intercambiar frases operativas completas que contengan una ubicación, un número de equipo y una instrucción. Un simple tono o la frase "¿Puede oírme?" solo confirma que existe audio. No demuestra que la información importante se pueda entender con precisión.

Verifique lo siguiente:

• Identificación correcta del destino y la fuente.

• Audio bidireccional claro sin recortes, eco o retraso excesivo.

• Funcionamiento confiable del teclado, línea directa, marcación rápida y botón único.

• Tono de llamada, baliza o indicador visual de llamada correctos.

• Liberación adecuada de la llamada y retorno al estado inactivo.

Acceso por radio

Cuando las redes de radio privadas están conectadas a través de una puerta de enlace RoIP, la prueba debe cubrir más que la calidad de voz. La comunicación por radio suele ser semidúplex, por lo que la activación PTT, el tiempo de liberación y el comportamiento de canal ocupado son importantes.

El audio de despacho no debe comenzar antes de que la radio conectada esté lista para transmitir. De lo contrario, las primeras palabras de una instrucción pueden perderse. La prueba también debe confirmar si la plataforma evita la transmisión o advierte al operador cuando el canal de radio está ocupado.

Pruebe cada canal de radio controlado de forma independiente. El nombre del canal que se muestra en la consola debe corresponder al puerto de la puerta de enlace correcto, la radio conectada y el grupo de conversación.

Video e intercomunicador

Para terminales de videointercomunicador, verifique el establecimiento de video, la orientación de la imagen, la sincronización de audio y video, y la identificación del dispositivo. La mala iluminación, el contraluz, la congestión de la red y los perfiles de video incorrectos pueden afectar el rendimiento incluso cuando el terminal está registrado normalmente.

Si la plataforma permite que un despachador abra un flujo de cámara o llame a un terminal de videointercomunicador, la operación debe probarse a través del flujo de trabajo real de la consola, en lugar de directamente desde la página de configuración del dispositivo.

Control de despacho

La consola de despacho es donde los recursos de comunicación se convierten en parte de un proceso operativo. Las pruebas deben reproducir llamadas normales, solicitudes simultáneas y eventos urgentes en lugar de presentar cada función por separado.

Identidad y ubicación

Una llamada entrante debe mostrar información que el operador pueda usar de inmediato. Un número de extensión genérico es insuficiente cuando la sala de control gestiona cientos de puntos de campo.

Los nombres de los dispositivos deben describir la ubicación o función real, como "Salida norte del túnel 03", "Punto de carga 2 de la granja de tanques" o "Sala de control de subestación". Si se incluye SIG, la selección del evento debe abrir la posición correcta en el mapa sin que el operador tenga que buscar manualmente.

El equipo de prueba puede intercambiar temporalmente las identidades de dos terminales de campo para confirmar que se detecta una discrepancia de ubicación antes de la entrega. Después de completar esta prueba negativa, restaure la configuración aprobada y repita la verificación de ubicación.

Manejo de prioridades

Las llamadas de emergencia pueden necesitar tener prioridad sobre la comunicación rutinaria. Las pruebas deben establecer cómo se comporta la plataforma cuando llega una llamada urgente mientras el operador está manejando otra llamada.

Dependiendo del diseño aprobado, el sistema puede mostrar una alerta de prioridad, poner la llamada rutinaria en espera, enrutar el evento a otra posición o permitir que un supervisor intervenga. El resultado observado debe coincidir con el procedimiento operativo documentado.

Escalación y transferencia

Las llamadas también deben probarse cuando el operador principal no está disponible, está ocupado o fuera de línea. Después de un período definido, la plataforma puede enrutar la llamada a otra consola, un grupo de servicio, un supervisor o un número externo.

Registre la secuencia completa, incluida la duración del tono de llamada, el orden de los destinos, la información de ubicación, el estado de prioridad y el registro final de la llamada. Una ruta que solo funciona cuando todos los operadores están en línea no proporciona un flujo de trabajo de emergencia confiable.

Conferencias y comunicación grupal

La respuesta a emergencias puede requerir que varios departamentos se unan a una sola sesión de voz. Las pruebas de conferencia deben cubrir la adición y eliminación de participantes, el control de silencio, la grabación de llamadas y la inclusión de recursos de radio o teléfonos externos cuando sea compatible.

Verifique la búsqueda grupal según la tabla de zonas aprobada. Un mensaje destinado a un taller o sección de túnel no debe entregarse a un área no relacionada, mientras que un mensaje autorizado para todo el sitio debe llegar a cada terminal requerido.

Solución relacionada: Sistemas de comunicación para comando y despacho de emergencias

Vinculación del sistema

Las funciones de alarma, video, SIG, control de acceso y comunicación a menudo son entregadas por subsistemas separados. Las pruebas de aceptación deben confirmar cómo se mueve la información entre ellos y qué ve el operador después de cada evento.

Activación de alarma

Active cada tipo de alarma conectado a través de la interfaz de campo o una entrada de prueba aprobada. La plataforma debe mostrar el tipo de evento correcto, el nombre del dispositivo, la ubicación, la hora y la prioridad.

Si el diseño incluye acciones automáticas, verifíquelas individualmente. Estas acciones pueden incluir abrir una vista de cámara, notificar a un grupo de servicio, reproducir un mensaje grabado, iniciar una llamada o resaltar un área afectada en el mapa.

La vinculación automática también debe verificarse contra eventos repetidos y estados de entrada que cambian rápidamente. Un sensor que cambia de estado varias veces no debe crear llamadas no controladas, transmisiones repetidas o un número inmanejable de indicaciones para el operador.

Verificación por video

La vinculación de alarma a video debe abrir la cámara asociada con la ubicación del evento. Verifique el video en vivo, el nombre de la cámara, la disponibilidad de la transmisión y el control del operador.

También se debe incluir la falla de la cámara. Si la cámara asociada está fuera de línea, la plataforma debe mostrar una falla clara en lugar de dejar al operador con una ventana en blanco que podría confundirse con un retraso de carga.

Registros de eventos

Un registro completo de incidentes puede incluir la alarma original, el acuse de recibo del operador, las llamadas salientes, la comunicación por radio, la actividad de conferencia, la selección de video y el cierre final del evento.

Estos registros deben usar una fuente de tiempo consistente y una identidad de evento común cuando la integración lo permita. El personal autorizado debe poder recuperar la secuencia sin buscar en varios sistemas independientes utilizando marcas de tiempo no relacionadas.

Pruebas de fallos

Una arquitectura redundante no se demuestra hasta que se aíslan deliberadamente componentes seleccionados. Planifique estas pruebas cuidadosamente para que se comprenda el impacto esperado en el servicio y se pueda detener la actividad de manera segura si ocurre una condición inesperada.

Interrupción de la red

Desconectar un enlace ascendente seleccionado o deshabilitar un puerto de switch de prueba puede confirmar cómo se comportan los terminales durante una interrupción de la red. Registre:

• Qué tan rápido se detecta la falla.

• Si las llamadas activas se interrumpen.

• Si los terminales se registran a través de una ruta de respaldo.

• Qué funciones de comunicación local permanecen disponibles.

• Si el servicio normal regresa automáticamente.

Si el sitio depende de una conexión WAN a una plataforma central, la conmutación local requiere especial atención. El registro de aceptación debe indicar si los terminales de campo aún pueden contactar a una sala de control local, usar un servidor secundario u operar a través de una ruta de comunicación alternativa.

Conmutación por fallo del servidor

Detener el servicio activo de control de llamadas puede confirmar si el servidor en espera asume la responsabilidad. Mida la detección de fallos, la recuperación del registro y el tiempo necesario antes de que se puedan realizar nuevas llamadas.

La recuperación del registro por sí sola no es suficiente. Después de la conmutación por fallo, repita las llamadas de voz, la búsqueda, la grabación y las operaciones de despacho para confirmar que el entorno en espera contiene la configuración requerida y puede acceder a los servicios de soporte.

Corte de energía

Las pruebas de energía de respaldo deben incluir servidores de comunicaciones, consolas de operador, switches de red, puertas de enlace y terminales de campo. Un teléfono alimentado a través de PoE aún depende del switch ascendente y su fuente de alimentación.

Verifique la duración de respaldo requerida, la generación de alarmas, el estado de la batería y la recuperación ordenada después de que regrese la energía. Cuando se incluyan generadores, observe la transición entre la energía de la red, el suministro de batería y la energía del generador.

Recuperación de componentes

El comportamiento de recuperación merece la misma atención que la falla en sí. Un servidor o ruta de red restaurado no debe crear registros duplicados, enrutamiento incorrecto, alarmas repetidas o conmutación inestable entre servicios primarios y de respaldo.

Los operadores necesitan una indicación clara cuando un componente falla y cuando vuelve al servicio. La recuperación silenciosa puede dejar a la sala de control sin saber que el sistema operó en un estado degradado.

Capacidad y entrega

Los sistemas de emergencia deben probarse más allá de una sola llamada activa. Durante un incidente importante, varias alarmas, llamadas, canales de radio, transmisiones de video y tareas de búsqueda pueden activarse en un período corto.

Operaciones concurrentes

La prueba de carga debe reproducir el número aprobado de llamadas de voz simultáneas, acciones de despacho, sesiones de grabación, canales de radio y transmisiones de video. También debe incluir servicios de fondo representativos como monitoreo, operaciones de base de datos y procesamiento de alarmas.

Observe el uso del procesador, el consumo de memoria, el rendimiento de la red, el tiempo de establecimiento de llamadas, la calidad de los medios y la integridad de la grabación. El objetivo no es simplemente llevar el sistema al fallo, sino confirmar que la capacidad operativa aprobada se puede mantener sin perder funciones críticas.

Permisos y seguridad

Los roles de usuario deben probarse con cuentas reales. Un operador necesita acceso a los recursos de comunicación requeridos para el área asignada, pero no debe poder cambiar la configuración del servidor ni utilizar grupos restringidos.

Revise el acceso de administrador, las políticas de contraseñas, los registros de auditoría, las rutas de mantenimiento remoto, los servicios de red no utilizados y los archivos de respaldo antes de la entrega. Las credenciales predeterminadas y las cuentas de puesta en servicio temporales deben eliminarse o desactivarse.

Documentación final

Los documentos de entrega deben reflejar el sistema instalado en lugar de la propuesta original. El paquete final debe incluir:

• Diagramas de arquitectura del sistema y de red.

• Inventario de dispositivos y registros de ubicación.

• Tablas de extensiones, grupos de llamadas y zonas de búsqueda.

• Reglas de prioridad, escalación y conmutación por fallo.

• Direcciones IP, VLAN y asignaciones de puertos de switch.

• Versiones de software, firmware y configuración.

• Procedimientos de copia de seguridad y restauración.

• Registros de prueba completados y excepciones no resueltas.

• Responsabilidades de mantenimiento y procedimientos de contacto.

Asigne un propietario, una acción correctiva y una fecha de nueva prueba a cada elemento fallido. El registro de aceptación final debe distinguir entre funciones completadas, limitaciones aprobadas y defectos pendientes. Esto evita que los acuerdos de puesta en servicio temporales se conviertan en condiciones permanentes no documentadas.

La entrega solo debe realizarse después de que el flujo de trabajo completo de incidentes haya pasado en condiciones normales, de carga máxima y de fallos definidos. El registro de aceptación firmado debe mostrar qué funciones se verificaron, qué limitaciones se aprobaron y qué defectos aún requieren acciones correctivas.

Preguntas frecuentes

¿Cuál es la diferencia entre FAT y SAT?

Las pruebas de aceptación en fábrica (FAT) verifican los equipos y las funciones configuradas antes de la entrega, generalmente en un entorno controlado. Las pruebas de aceptación en sitio (SAT) verifican el sistema instalado con su cableado, red, terminales, integraciones y condiciones operativas reales.

¿Quién debe aprobar los resultados de la aceptación?

La aprobación normalmente involucra al integrador del sistema, al propietario técnico, al equipo de red, a los representantes de operaciones y a la organización responsable de los procedimientos de emergencia. Los flujos de trabajo críticos para la seguridad no deben ser aprobados únicamente por el proveedor del equipo.

¿Se pueden realizar las pruebas de aceptación en un sistema en vivo?

Algunas pruebas se pueden completar durante la operación normal, pero las pruebas de fallos, prioridad y alta carga pueden afectar los servicios activos. Estas actividades requieren una ventana de prueba aprobada, un procedimiento de reversión y una coordinación clara con los operadores.

¿Cuándo se requieren pruebas de regresión?

Las pruebas de regresión son apropiadas después de actualizaciones importantes de software, reemplazo de servidores, cambios de enrutamiento, rediseños de red o cambios de integración. El alcance debe incluir la función modificada y cualquier flujo de trabajo dependiente que pueda verse afectado.

¿Cómo se debe almacenar la evidencia de las pruebas?

Las hojas de prueba, registros, grabaciones, capturas de pantalla y registros de defectos deben almacenarse bajo acceso controlado con nombres de archivo coherentes e información de versión. El período de retención debe seguir las políticas de ingeniería, seguridad y cumplimiento de la organización.