Operational Health Matrix (OHM)

Operational Health Matrix (OHM) es el módulo operativo central de la Plataforma IIoT. Transforma el flujo de telemetría, los resultados de la analítica y los eventos de explotación en un ciclo de trabajo gestionado: desde la detección automática del problema hasta su resolución confirmada por datos.

OHM reúne en un único sistema:

• la detección de problemas técnicos, metrológicos y de integración;
• la correlación de síntomas y la identificación de la causa raíz probable;
• la creación y la gestión de objetos Operational Issue;
• la asignación de equipos responsables y de ejecutores;
• la gestión de plazos, prioridades y SLA;
• el seguimiento de tareas, comentarios, evidencias e historial de acciones;
• la verificación automática del resultado con los datos nuevos;
• la gestión de incidentes masivos;
• la evaluación del estado de los equipos y del parque;
• el cálculo de KPI operativos y de equipo;
• la acumulación de soluciones confirmadas en la base de conocimiento;
• el análisis asistido por AI, sin delegar en la inteligencia artificial la potestad de tomar decisiones críticas.

flowchart TD
  A["Telemetría"] --> B["Detectores"]
  B --> C["Evidence"]
  C --> D["Correlación y Root Cause"]
  D --> E["Operational Issue"]
  E --> F["Asignación y ejecución"]
  F --> G["Verificación con datos"]
  G --> H["Cierre y Knowledge Base"]
  H --> I["KPI y mejora continua"]

Propósito del módulo

Los sistemas de telemetría tradicionales responden bien a la pregunta:

¿Qué le ocurrió al dispositivo o a los datos?

Pero esto no basta para gestionar un parque grande. Una vez detectado el evento, la organización debe determinar:

• si la señal representa un problema real;
• si afecta a un único dispositivo o constituye un incidente sistémico;
• qué otros síntomas están vinculados a la misma causa raíz;
• quién es responsable de la resolución;
• en qué plazo debe completarse el trabajo;
• qué acciones se han emprendido ya;
• si la resolución ha quedado confirmada por datos objetivos;
• si el problema es recurrente;
• con qué eficacia funciona el proceso operativo.

OHM cierra todo este ciclo.

El resultado principal del módulo no es una notificación ni una fila de informe, sino un objeto operativo gestionado que tiene:

• un identificador;
• un tipo de problema;
• los activos afectados;
• evidencias;
• una criticidad (Severity);
• un nivel de confianza;
• una causa raíz probable y otra confirmada;
• un propietario;
• un ejecutor;
• un plazo;
• tareas;
• un historial;
• un estado de verificación;
• un resultado de la resolución;
• un enlace a la base de conocimiento;
• un impacto en los KPI.

Ventaja clave

La plataforma no se limita a registrar las desviaciones. La plataforma acompaña el problema hasta un resultado confirmado.

flowchart TD
  subgraph OPS["Plataforma IIoT y OHM"]
    direction TB
    O1["Detectó el problema"] --> O2["Verificó las evidencias"]
    O2 --> O3["Consolidó las señales relacionadas"]
    O3 --> O4["Determinó la prioridad"]
    O4 --> O5["Asignó la zona de responsabilidad"]
    O5 --> O6["Controla el plazo"]
    O6 --> O7["Verificó el resultado con los datos"]
    O7 --> O8["Guardó la solución confirmada"]
  end
  subgraph MON["Sistema de monitoreo"]
    direction TB
    M1["Detectó el problema"] --> M2["Aquí termina el trabajo del sistema"]
  end

Gracias a ello, OHM lleva la explotación de un modo reactivo a un modelo gestionado en el que cada desviación significativa tiene un propietario, un plazo, evidencias y un resultado medible.

Principios fundamentales

Issues en lugar de alarmas

Una alarma aislada no siempre equivale a un problema operativo.

Un único fallo físico puede generar decenas o cientos de eventos:

• no hay sesión de comunicación;
• no hay archivo;
• datos obsoletos;
• estado de la batería desconocido;
• no hay presión actual;
• error de entrega.

OHM no crea un elemento de trabajo aparte por cada síntoma. El sistema correlaciona las señales y crea un único Operational Issue cuando comparten una causa común.

Operaciones basadas en evidencias

Toda conclusión automática debe ser explicable.

Un Issue contiene:

• los valores de origen;
• las marcas de tiempo;
• el identificador del detector;
• la versión del algoritmo;
• los umbrales aplicados;
• un enlace al informe especializado correspondiente;
• el historial de recurrencias;
• las señales relacionadas;
• el resultado de la correlación.

El usuario siempre puede seguir el camino que va desde la telemetría original hasta el Issue creado.

Primero la causa raíz (Root Cause)

OHM distingue entre:

• síntoma — la desviación observada;
• causa — el factor técnico u organizativo que produjo la desviación;
• causa raíz — el factor primario cuya eliminación evita la repetición de un grupo de síntomas.

Ejemplo:

flowchart LR
  S1["Síntoma 1: falta el archivo horario"] --> RC["Causa raíz probable: degradación de la fuente de alimentación"]
  S2["Síntoma 2: la última sesión fue hace 9 días"] --> RC
  S3["Síntoma 3: la tensión de la batería iba descendiendo"] --> RC
  S4["Síntoma 4: la duración de las sesiones iba aumentando"] --> RC

Cierre confirmado por datos

El ejecutor comunica que el trabajo está hecho, pero el estado final resolved solo se establece después de verificar el resultado.

flowchart TD
  V1["Trabajo realizado"] --> V2["awaiting_verification"]
  V2 --> V3["Los datos nuevos confirman la normalización"]
  V3 --> V4["resolved"]

Para los problemas que no pueden comprobarse mediante telemetría se aplica una verificación manual controlada, con comentario obligatorio y evidencia de respaldo.

El activo (Asset) en el centro del modelo

Todos los eventos, Issues, trabajos y métricas se vinculan a activos:

• nodos de medición;
• correctores;
• contadores;
• sensores;
• módems;
• gateways;
• tarjetas SIM;
• componentes de servidor;
• canales de integración;
• versiones de software.

La ficha del activo muestra la salud actual, el historial de degradación, los Issues activos, los trabajos realizados y la recurrencia de los problemas.

La responsabilidad es de la persona, la AI asiste

La AI ayuda a:

• resumir Evidence;
• jerarquizar las hipótesis;
• encontrar casos similares;
• proponer soluciones conocidas;
• detectar nuevos clústeres;
• pronosticar el riesgo de fallo.

La AI no puede, por sí sola:

• cambiar la prioridad;
• asignar responsabilidades;
• cerrar un Issue;
• confirmar una Root Cause como hecho establecido;
• modificar los SLA;
• ejecutar acciones críticas sobre los equipos.

Reproducibilidad por diseño

Todos los cálculos significativos son reproducibles. Para cada resultado, la plataforma guarda:

• la versión del detector;
• la versión del Canon;
• la versión del modelo de correlación;
• el conjunto de datos utilizado;
• la hora de cálculo;
• los umbrales;
• la configuración;
• el origen del cambio.

Lugar de OHM en la arquitectura de la Plataforma IIoT

OHM se sitúa entre la capa analítica y la gestión de la explotación.

flowchart TD
  PHY["Activos físicos"] --> DATA["Capa de datos e integración IIoT"]
  DATA -->|"Datos normalizados"| ANL["Analítica y detección"]
  ANL -->|"Evidence y resultados del análisis"| OHM["Operational Health Matrix"]
  OHM -->|"API, eventos, integración"| ENT["Sistemas corporativos"]

Composición de las capas:

Fuentes de datos

OHM utiliza:

• la telemetría actual;
• los archivos horarios, diarios y de eventos;
• los registros de las sesiones de comunicación;
• los datos de pasaporte y de registro;
• los estados de los dispositivos;
• los datos de la batería;
• la presión, la temperatura, el caudal y el volumen;
• los eventos de manipulación;
• las versiones de firmware;
• los parámetros de comunicación;
• los resultados de los informes especializados;
• las observaciones manuales de los usuarios;
• los eventos de sistemas externos.

Proveedores de Evidence

Cualquier módulo analítico de la plataforma puede actuar como fuente de evidencias.

Ejemplos:

Explore el módulo