MDM/AMI completo: Head End System, VEE, gestión de consumos y control remoto

1. Planteamiento Completo

Idea propia del equipo, en desarrollo desde hace varios años. En 2024 se materializó en una propuesta comercial para el sector eléctrico colombiano que no avanzó a contratación. Ahora se retoma como producto propio de rensoftlabs, en fase de ideación formal.

Problema a resolver

1. Fragmentación de fuentes: medidores y concentradores de múltiples marcas y protocolos (DLMS/COSEM, ANSI C12.19/C12.22, propietarios) que no hablan entre sí ni con el sistema comercial sin una capa de integración dedicada.
2. Calidad de la medición: sin un proceso VEE sistemático, cientos o miles de lecturas por medidor-mes producen facturación incorrecta y reclamos.
3. Desconexión entre medición y control operativo: suspender/reconectar el servicio depende de visitas de campo sin un canal de comandos confiable.

Objetivo del producto

Construir un MDM completo con HES propio capaz de capturar mediciones multi-protocolo/ multi-marca, procesarlas con un pipeline VEE auditable, entregar consumos validados al sistema comercial, y enviar comandos de control (suspensión/corte/reconexión).

Alcance

Fuera de alcance por ahora: CIS/facturación completo, GIS/SCADA/ADMS/OMS, app móvil de campo y BI avanzado.

Mercado objetivo

ESP pequeñas/medianas (energía, acueducto, gas) en LatAm que ya invirtieron o van a invertir en medición inteligente pero no tienen presupuesto ni interés en un MDM de gran escala. Primer piloto natural: sector eléctrico colombiano, por el interés ya validado en 2024.

Riesgos identificados

• Interoperabilidad real entre fabricantes de medidores (cada uno implementa el protocolo con variaciones).
• Volumen de datos: salto de 1 lectura/mes a miles por medidor-mes.
• Ciberseguridad del canal de control — la funcionalidad de mayor impacto si falla.
• Regulación local sobre medición y corte de servicio (CREG en Colombia, etc.).

2. Arquitectura general Completo

Principios rectores, stack tecnológico y vista de componentes de extremo a extremo (Meter to Cash).

Principios rectores

• Núcleo agnóstico de protocolo/utility — cada protocolo/marca vive en un adaptador desacoplable.
• Multi-tenencia desde el modelo de datos (no solo desde la capa web).
• El canal de control (SCR) es la parte más sensible — más fricción deliberada que el resto.
• Madurez operativa realista: Docker + systemd + nginx, como el resto del portafolio — Kubernetes solo si el escalamiento lo exige.
• No reinventar lo que ya existe: DLMS/COSEM se implementa apoyándose en una librería abierta y madura (Gurux), no desde cero.

Vista de componentes

flowchart LR
    subgraph MED["Medición"]
        M1[Medidores / Concentradores]
    end
    subgraph HES["HES · Head End System"]
        AD[Adaptadores de protocolo\nDLMS/COSEM · ANSI C12 · propietario]
        SCR[Módulo SCR\nSuspensión/Corte/Reconexión]
        SCH[Programador de lecturas\ny comandos]
    end
    subgraph MDM["MDM · Meter Data Management"]
        RAW[(Almacén crudo\nlecturas + eventos)]
        VEE[Motor VEE\nValidación→Estimación→Edición]
        CONS[Gestión de Consumos\nagregación, reglas de crítica]
    end
    BUS{{Bus de eventos / API interna}}
    CIS[CIS/Facturación\npropio o del cliente]
    PORTAL[Portal web + API pública\nmulti-tenant]
    M1 <--> AD
    AD --> SCH --> RAW
    SCR --> AD
    RAW --> VEE --> CONS
    CONS --> BUS
    BUS --> CIS
    BUS --> PORTAL
    PORTAL --> SCR
    

Stack tecnológico por capa

Multi-tenencia y seguridad

Esquema compartido con Row-Level Security de PostgreSQL como aislamiento entre clientes — cada tenant es una fila más, no un despliegue aparte. El módulo SCR nunca se expone directo al portal: toda orden de control requiere rol autorizado explícito, queda firmada y con auditoría inmutable antes de llegar al adaptador HES.

3. Diseño Completo

Modelo de datos, contratos de API y flujos de secuencia, bajo un principio no negociable.

Patrón de configuración cacheada

sequenceDiagram
    participant BD as PostgreSQL (fuente de verdad)
    participant Loader as Config Loader (job)
    participant Cache as Snapshot local (JSON)
    participant Motor as Motor VEE / Adaptador HES
    BD->>Loader: SELECT reglas/mapeos vigentes
    Loader->>Cache: escribe snapshot versionado
    Motor->>Cache: carga al iniciar y en cada refresco
    Note over Motor: Procesa lecturas sin tocar la BD por registro
    BD-->>Loader: cambio de regla (evento)
    Loader-->>Cache: nuevo snapshot
    Cache-->>Motor: recarga en caliente
    

Modelo de datos — entidades núcleo

tenant, medidor, concentrador, protocolo_medidor,
regla_vee (versionada), regla_critica_consumo,
nivel_aprobacion_control, rol_permiso,
lectura_cruda (hypertable Timescale), lectura_validada,
evento_medidor, orden_control, consumo

Flujo de lectura (Meter to Cash)

sequenceDiagram
    participant Medidor
    participant HES as Adaptador HES
    participant Raw as Almacén crudo
    participant VEE as Motor VEE
    participant Cons as Gestión de Consumos
    participant CIS
    Medidor->>HES: trama de protocolo
    HES->>HES: normaliza con mapeo OBIS (caché)
    HES->>Raw: inserta lectura_cruda
    Raw-->>VEE: notifica nueva lectura
    VEE->>VEE: aplica reglas_vee vigentes (caché)
    VEE->>Raw: inserta lectura_validada
    VEE-->>Cons: evento lectura.validada
    Cons-->>CIS: consumo facturable listo
    

Flujo de control (SCR) con aprobación

sequenceDiagram
    participant Portal
    participant Cons as Gestión de Consumos/CIS
    participant SCR as Módulo SCR
    participant HES as Adaptador HES
    participant Medidor
    Portal->>Cons: solicita orden_control
    Cons->>Cons: valida nivel de aprobación (BD)
    Note over Cons: rol autorizado aprueba si aplica
    Cons->>SCR: orden aprobada (firmada)
    SCR->>HES: ejecutar comando
    HES->>Medidor: comando nativo del protocolo
    Medidor-->>HES: confirmación
    HES-->>SCR: resultado
    SCR-->>Cons: orden_control.confirmada (auditoría)
    

Historias de usuario base (motor VEE)

• Como operador VEE, quiero que el sistema marque lecturas fuera del rango configurado para revisarlas antes de facturar.
• Como operador VEE, quiero que el sistema estime lecturas faltantes según el método configurado, para no interrumpir la facturación.
• Como operador VEE, quiero editar manualmente una lectura errónea, dejando registro de quién y por qué.
• Como administrador, quiero cambiar un umbral de validación sin desplegar código, para ajustar la sensibilidad por tenant o temporada.

4. Plan de sprints Completo

MVP acotado a un solo protocolo y un solo tenant piloto, para no repetir el patrón de 2024 (propuesta grande, ninguna oportunidad avanzó).

Alcance del MVP

• Protocolo: DLMS/COSEM vía Gurux · Un (1) tenant piloto
• Pipeline VEE completo · Gestión de Consumos básica
• Módulo SCR con aprobación humana obligatoria en el 100% de las órdenes (default más seguro)
• Bus: Redis Streams · Autenticación: JWT propio

Supuesto de equipo (ajustable): 2 desarrolladores backend + 1 QA a medio tiempo + el usuario como Product Owner/arquitecto. Sprints de 2 semanas.

Roadmap — 10 sprints (~5 meses)

Criterios de éxito del piloto

• Ciclo Meter-to-Cash corrido de punta a punta con datos reales.
• Cero datos hardcodeados verificables en auditoría de código.
• Al menos una orden de control ejecutada y confirmada end-to-end.
• Feedback del tenant piloto documentado para decidir si automatizar el SCR en la siguiente iteración.