Modelo de dominio operativo

Modelo de dominio operativo

Operational Health Matrix se apoya en un modelo de dominio operativo unificado que define las entidades principales, las relaciones y las zonas de responsabilidad en el conjunto de la Plataforma IIoT.

Cada proceso, detector, endpoint de la API y componente analítico trabaja sobre el mismo modelo de dominio, lo que garantiza la coherencia en todo el sistema.

El modelo de dominio elimina la ambigüedad, minimiza la duplicación de datos y proporciona un lenguaje operativo común a todos los componentes de la plataforma.

Entidades principales

El dominio de Operational Health Matrix está formado por las siguientes entidades principales:

• Asset
• Detector
• Evidence
• Operational Issue
• Task
• Root Cause
• Health
• Knowledge Article
• Massive Incident
• SLA Policy
• Team
• User
• Notification
• Attachment
• Comment
• Audit Record

Cada entidad es propietaria de su ciclo de vida y participa en uno o varios flujos de trabajo operativos.

Asset (activo)

Asset es la entidad central de la plataforma.

Todo objeto físico o lógico supervisado se representa como un Asset.

Ejemplos típicos:

• medidor de gas
• sensor de presión
• corrector
• RTU
• pasarela
• controlador de válvula
• unidad de telemetría
• dispositivo de comunicación
• componente de software

Cada Asset contiene:

• identificador único;
• tipo;
• modelo;
• fabricante;
• número de serie;
• propietario;
• región de explotación;
• configuración;
• versión de firmware;
• perfil de comunicación;
• estado del ciclo de vida.

Detector

Detector es el componente analítico responsable de transformar la telemetría en observaciones operativas.

Detector no crea lógica de negocio.

Su responsabilidad se limita a identificar patrones observables y a generar evidencias.

Los atributos de Detector incluyen:

• Identifier
• Version
• Canon
• Confidence
• Status
• Accuracy Metrics
• Health

Evidence (evidencia)

Evidence representa una prueba inmutable que respalda una conclusión operativa.

Evidence puede proceder de:

• la telemetría;
• los registros de comunicación;
• los registros de auditoría;
• la confirmación del usuario;
• fotografías cargadas;
• diagnósticos del sistema;
• sistemas externos.

Evidence no puede modificarse después de su creación.

Si se requiere una corrección, se crea un nuevo objeto Evidence y se conserva la versión anterior.

Operational Issue (problema operativo)

Operational Issue representa un problema operativo confirmado que requiere investigación o resolución.

Cada Operational Issue contiene:

• Canon;
• Severity;
• Priority;
• Status;
• Owner;
• Root Cause;
• SLA Policy;
• Verification State;
• Operational History.

Operational Issue es el objeto operativo principal de la plataforma.

Task (tarea)

Task representa una acción ejecutable necesaria para resolver un Operational Issue.

Las tareas no pueden existir de forma independiente.

Cada Task pertenece exactamente a un Operational Issue.

Un Operational Issue puede contener varias tareas.

Root Cause (causa raíz)

Root Cause representa la razón subyacente confirmada de uno o varios Operational Issues.

Varios Operational Issues pueden hacer referencia a la misma Root Cause.

Esta relación permite la analítica operativa a escala de toda la empresa y la identificación de problemas recurrentes.

Health (salud)

Health es un indicador operativo calculado.

Health existe para:

• el activo;
• el emplazamiento;
• la región;
• la organización;
• el ecosistema completo.

Los valores de Health siempre se calculan de forma automática.

Knowledge Article (artículo de la base de conocimiento)

Knowledge Article almacena experiencia operativa validada.

Cada artículo puede hacer referencia a:

• problemas canónicos;
• causas raíz;
• tipos de activos;
• versiones de firmware;
• procedimientos operativos;
• documentación del fabricante.

Massive Incident (incidente masivo)

Massive Incident agrupa varios Operational Issues originados por un mismo evento operativo.

Proporciona un único objeto de gestión para los incidentes de infraestructura a gran escala.

Principios operativos

Operational Health Matrix sigue varios principios arquitectónicos que definen el comportamiento de cada subsistema.

El activo primero (Asset First)

Todo evento operativo se asocia a un Asset.

Los activos siguen siendo los objetos primarios a lo largo de todo el ciclo de vida.

Operación centrada en los Issues

La explotación se gestiona mediante Operational Issues y no mediante alarmas o eventos de telemetría individuales.

Decisiones basadas en Evidence

Toda conclusión operativa debe estar respaldada por uno o varios objetos Evidence.

Las suposiciones sin respaldo nunca se tratan como hechos confirmados.

Primero la Root Cause, después la resolución

Las acciones correctivas se dirigen, siempre que es posible, a causas confirmadas y no a síntomas observables.

El humano en el circuito (Human-in-the-Loop)

La plataforma respalda la toma de decisiones operativas, pero nunca sustituye la responsabilidad de la ingeniería.

Las acciones críticas requieren confirmación humana explícita.

Analítica explicable

Las conclusiones analíticas se mantienen transparentes.

Cada recomendación incluye las evidencias que la respaldan e información sobre el nivel de confianza.

Auditoría inmutable

El historial operativo no puede reescribirse.

Cada modificación genera un nuevo registro de auditoría.

Enfoque API-first

Todas las capacidades de la plataforma son accesibles a través de API documentadas.

Las interfaces de usuario y las integraciones externas se apoyan en los mismos servicios operativos.

Arquitectura orientada a eventos

Los cambios operativos se propagan en forma de eventos.

Esto hace posibles las integraciones asíncronas y las canalizaciones de procesamiento escalables.

Modelo de datos operativo

La plataforma sigue un modelo de datos operativo unificado.

flowchart TD
    A["Asset"] --> DET["Detector"]
    A --> EV["Evidence"]
    A --> ISSUE["Operational Issue"]
    ISSUE --> TASK["Task"]
    ISSUE --> RC["Root Cause"]
    ISSUE --> SLA["SLA Policy"]
    ISSUE --> CMT["Comment"]
    ISSUE --> ATT["Attachment"]
    A --> HLT["Health"]
    A --> KB["Knowledge Articles"]

Propiedad

Cada entidad tiene exactamente un propietario de su ciclo de vida.

Reglas de ciclo de vida

El modelo de dominio respeta varios invariantes:

• Los activos nunca se eliminan mientras existan Operational Issues históricos.
• Evidence es inmutable.
• Las tareas no pueden existir sin un Operational Issue.
• Las Root Causes pueden ser compartidas por varios Issues.
• Los valores de Health se calculan y no pueden editarse manualmente.
• Los Audit Records son de solo adición (append-only).
• Los Knowledge Articles se mantienen versionados a lo largo de todo su ciclo de vida.

Estas restricciones garantizan la coherencia, la trazabilidad y la reproducibilidad en toda la plataforma Operational Health Matrix.