LIVE SYSTEM ARCHITECTURE DOCUMENTATION

Cognitive Core
Technical Specification

Documentación técnica profunda de la plataforma de ingeniería cognitiva. Detalle de arquitectura de 3 capas, motores de inferencia neuro-simbólica y protocolos de integración industrial.

Rust/Python Core
RDF Knowledge Graph
WebSocket Mesh

Arquitectura Distribuida (Kernel Isolation)

Implementación de patrón "Shared-Nothing" para aislamiento multi-inquilino estricto.

La arquitectura del Cognitive Core no es simplemente una aplicación monolítica; funciona como un Hypervisor de Dominios Lógicos. El componente `DomainManager` (domain_manager.py) orquesta instancias aisladas de los motores cognitivos para cada "Tenant" o cliente, asegurando que los cálculos de física (Simulation Engine) y las inferencias de IA (Reasoning Engine) de un dominio nunca contaminen la memoria de otro.

Esta separación se garantiza mediante un diseño de 3 capas físicas estrictamente desacopladas, comunicadas exclusivamente a través de APIs RESTful y WebSockets asíncronos.

L1: Cognitive Gateway

Edge / Rust

"Los Sentidos". Abstracción de hardware y normalización de protocolos en el borde.

  • Drivers OT (Modbus, DNP3, OPC-UA)
  • Buffering Local (SQLite)
  • Normalización Semántica
CORE

L2: Cognitive Backend

Python / AsyncIO

"El Cerebro". Orquestación de motores cognitivos y gestión del conocimiento.

  • Knowledge Manager (RDFLib)
  • Simulation Engine (Physics)
  • Reasoning Engine (LLM RAG)

L3: Frontend Reactivo

React / WebGL

"El Rostro". Visualización técnica de alta densidad y control operativo.

  • Living Map (D3-Force)
  • WebSockets en tiempo real
  • UX Semántica Adaptativa
fig 1.0: system_topology.mermaid
OT / FIELD (L1) Modbus / DNP3 COGNITIVE BACKEND (L2) Semantic Engine RDF Knowledge Graph SWRL Rules Action Manager FRONTEND (L3) React SPA

Núcleo Semántico (Knowledge Graph)

El modelo de verdad. No usamos SQL para modelar la realidad, usamos Grafos RDF.

A diferencia de las bases de datos relacionales rígidas, Cognitive Core implementa ontologías estándar (CIM IEC 61970, WaterML, Brick Schema) para "entender" las relaciones físicas.

¿Por qué Grafos?

Permite consultas de trazabilidad complejas: "Encuentra todos los clientes críticos conectados aguas abajo de este transformador fallado" en milisegundos.

Algoritmo de Sincronización Diferencial ("Delta Sync")

El servicio `indexing_worker.py` no realiza volcados completos de base de datos, lo cual bloquearía el hilo principal. En su lugar, implementa una estrategia de "Check-Before-Compute" que minimiza el consumo de CPU en un 95% durante los ciclos de reposo.

Fase 1: Topology Snapshot (Inicio)

Al arrancar, el sistema consulta el conteo de vectores en Qdrant (operación O(1)). Si `count > 0`, asume que la topología estática es válida y salta la costosa ingesta de grafos RDF. Si detecta un índice vacío o corrupto, dispara `ingest_topology(engine.current_state)` que serializa el grafo en memoria.

Fase 2: Incremental Knowledge Sync (Loop)

El worker despierta cada 60s (configurable vía `INDEXING_INTERVAL`) y ejecuta un barrido diferencial basado en marcas de tiempo (`created_at >= UTC - 7d`). Esto previene la re-indexación de millones de eventos históricos.

  • BATCH_SIZE: 500 vectores por chunk (Env Var)
  • ENTITIES: Alerts, Incidents, Learned Rules
  • TARGET: Colección Qdrant particionada por DomainID
ontology_definition.ttl 
@prefix cim:  .
@prefix ex:  .

# Definición de Activo
ex:Trafo_T1 a cim:PowerTransformer ;
    cim:IdentifiedObject.name "Sub T1 115kV" ;
    cim:Equipment.EquipmentContainer ex:Sub_Norte ;
    ex:hasNominalPower "100"^^xsd:float .

# REGLA SWRL (Lógica de Negocio)
# Si el trafo está sobrecargado -> Sugerir desconexión
Trafo(?t) ^ hasLoad(?t, ?load) ^ hasLimit(?t, ?limit) ^ swrlb:greaterThan(?load, ?limit)
-> hasStatus(?t, "CRITICAL_OVERLOAD") ^ suggestAction(?t, "Shed_Load")

The 9 Cognitive Engines

Especificación Técnica Detallada por Módulo

1. Simulation Engine

app.services.simulation_engine.py

El corazón físico del sistema. No es solo un repositorio de datos, es un Digital Twin Activo que mantiene el estado eléctrico/hidráulico en memoria.

Physics Plugins

Arquitectura modular que carga la lógica física dinámicamente (`importlib`). Soporta modo Legacy (cálculo interno Kirchhoff/Bernoulli) y Shadow Mode (espejo de baja latencia del Gateway Edge).

State Vector

Mantiene un vector de estado de alta frecuencia (Voltage, P, Q, Frequency) para cada nodo. Permite la inyección de fallos (`inject_fault`) para entrenamiento de operadores.

2. Alert Engine

app.services.alert_engine.py

Monitor determinístico de baja latencia. Evalúa reglas complejas sobre el flujo de telemetría en tiempo real para garantizar la seguridad operativa.

AST Evaluation

Las reglas no son hardcoded. Se compilan desde strings (`"voltage > 1.05"`) a Árboles de Sintaxis Abstracta (AST) de Python para una evaluación segura y ultrarrápida (microsegundos).

Deduplication Logic

Implementa ventanas de tiempo en memoria (Redis/Dict) para evitar "fatiga de alertas". Garantiza transacciones ACID al crear incidentes críticos.

3. Reasoning Engine

app.services.reasoning_engine.py

Cerebro conversacional basado en LLMs (DeepSeek-V3). Transforma lenguaje natural en consultas operativas y diagnósticos técnicos.

Context Injection (RAG)

Construye dinámicamente un prompt con 3 capas: 1) Telemetría Real-Time, 2) Grafo Semántico Vecino, 3) Alertas Activas.

Multi-Provider

Arquitectura agnóstica de LLM. Soporta OpenAI, DeepSeek y modelos locales. Fallback automático a modo "Offline" si la API falla.

4. Action Manager

app.services.action_manager.py

Orquestador de Self-Healing. Cierra el ciclo cognitivo ejecutando contramedidas automáticamente ante incidentes críticos.

Incident Lifecycle

Gestiona la máquina de estados completa: Detection -> Analysis -> Isolation -> Reconfiguration -> Restoration. Genera logs detallados para auditoría.

Template Mapping

Traduce intenciones abstractas ("ISOLATE") a comandos SCADA concretos ("OPEN CB-102") usando mapas de configuración definidos en `domain.yaml`.

5. Predictive Engine

app.services.predictive.engine.py

Radar temporal que proyecta el estado futuro del sistema para prevenir fallos antes de que ocurran.

Linear Regression

Modelo ultraligero (Scikit-Learn) para proyecciones inerciales de corto plazo (T+10 min). Ideal para tendencias de temperatura.

Facebook Prophet

Modelo estadístico robusto para series temporales de largo plazo (T+24h). Detecta estacionalidad diaria/semanal en la curva de demanda.

6. Rule Evolution

app.services.rule_evolution_service.py

Sistema de aprendizaje no supervisado. Descubre "lo desconocido" y propone nuevas reglas operativas.

Isolation Forest

Algoritmo de detección de anomalías espaciales. Identifica puntos de datos que se desvían de la normalidad estadística multidimensional.

Candidate Generation

Traduce patrones matemáticos a reglas SWRL legibles (`CandidateRule`). Estas requieren aprobación humana ("Human-in-the-loop") para activarse.

7. Semantic Engine

app.services.semantic.engine.py

Capa de entendimiento conceptual. Gestiona el Grafo de Conocimiento (KG) y la búsqueda vectorial.

Qdrant Vector DB

Indexa embeddings de alertas y reglas para búsqueda semántica ("Alertas similares a falla de aislamiento").

RDF & SPARQL

Gestiona relaciones ontológicas complejas (`Transformer a connected_to Line b`). Permite consultas inferenciales profundas con SPARQL.

8. Planning Engine

app.services.planning_engine.py

Arquitecto del futuro. Analiza restricciones de red y propone expansiones de infraestructura usando datos predictivos.

Expansion Analysis

Consulta predicciones de carga a largo plazo y las cruza con la capacidad nominal de los activos.

Asset Materialization

Crea activos "fantasmas" (`lifecycle=PLANNED`) en la ontología para simular el impacto de nuevas inversiones antes de construirlas.

9. Incident Timeline

app.models.incident.py

La "Caja Negra" del sistema. Asegura trazabilidad forense inmutable de cada decisión tomada por la IA.

Audit Trail

Registra cada transición de estado y acción automática con timestamps precisos. Esencial para análisis post-mortem y cumplimiento normativo.

Action Manager Logic

Flujo de detección y respuesta automática de incidentes.

Ciclo de Decisión de 6 Pasos

  1. 1

    Detection

    Polling loop (10s) identifica anomalía crítica en entidad.

  2. 2

    Analysis

    Reasoning Engine consulta LLM para diagnóstico de causa raíz.

  3. 3

    Generation

    Se crean acciones candidatas (Aislamiento, Reconfiguración).

  4. 4

    Validation

    Sandbox verifica que acción no viole restricciones físicas.

action_schema.json 
{
  "action_id": "uuid-v4",
  "type": "scada_command",
  "status": "pending_approval",
  "metadata": {
    "device_address": "192.168.1.100",
    "protocol": "dnp3",
    "command": "TRIP_BREAKER",
    "priority": "CRITICAL",
    "estimated_impact": {
      "customers_saved": 4500,
      "restoration_time": "2m"
    }
  }
}

Fault Tolerance & Reliability

Mecanismos de recuperación ante fallos y gestión de recursos.

Atomic Transactions & Rollback

Toda operación crítica (ej. creación de alertas o incidentes) está envuelta en transacciones atómicas de base de datos (`db.begin() ... db.commit()`).

En el `AlertEngine` (`alert_engine.py`), si falla la persistencia de una alerta, se ejecuta un rollback inmediato para evitar estados inconsistentes (Alertas fantasma). Además, se utiliza `db.refresh(obj)` para garantizar que el objeto en memoria tiene los IDs generados por la BD antes de pasar a la siguiente etapa.

Graceful Degradation

El sistema implementa patrones de "Lazy Loading" en los workers. Por ejemplo, el `indexing_worker` no carga el motor de física ni el motor de razonamiento (que consumen GBs de RAM), solo instancia el `KnowledgeManager` ligero.

Si un servicio externo (ej. Qdrant) no responde, el sistema captura la excepción, registra el error en `loguru` y continúa operando en modo degradado (sin búsqueda semántica), garantizando que las funciones críticas (SCADA/Alertas) nunca se detengan.

Frontend Component Map

Arquitectura SPA Modular (`src/components`).

/src/context

  • AuthContext.tsx
  • DomainContext.tsx

/src/services

  • scadaService.ts
  • semanticService.ts
  • geoService.ts

/components/cognitive

  • EvolutionPanel.tsx
  • NetworkGraph.tsx
  • ChatInterface.tsx
  • ActionControlCenter.tsx
  • AlertDashboard.tsx

/components/admin

  • DomainManager.tsx
  • UserManagement.tsx
  • SystemHealth.tsx
  • OntologyEditor.tsx

Security & Data Sovereignty

Zero Trust, Air-Gapped Ready & Cryptographic Isolation.

Estrategia de Autenticación (Auth0 / JWT)

El servicio `auth_service.py` implementa un esquema OAuth2PasswordBearer estricto. Los tokens de acceso (JWT) son firmados con algoritmo HS256 (o RS256 en producción) y contienen scopes granulares que definen no solo el rol (Admin/User), sino el acceso específico a cada Dominio Físico.

Para entornos desplegados en contenedores (Docker), utilizamos hashing de contraseñas mediante PBKDF2_SHA256, garantizando compatibilidad cruzada entre arquitecturas x86 y ARM64 donde `bcrypt` puede presentar inestabilidad.

RBAC (Role-Based Access Control)

El control de acceso no es binario. El sistema utiliza una tabla relacional intermedia `DomainAccess` que mapea N:M entre `Users` y `Domains`.

  • Nivel 0: SuperAdmin (Acceso a Kernel & Logs)
  • Nivel 1: Domain Owner (Gestión de Activos)
  • Nivel 2: Operator (Solo Visualización & Control)

Protocolo "Air-Gap"

La plataforma está diseñada para operar sin conexión a internet. Todos los modelos de LLM (si se usa LocalLLM), las librerías de mapeo y los motores de física están autocontenidos. El sistema no realiza llamadas externas ocultas (telemetría desactivada por defecto), cumpliendo con normativas de Soberanía de Datos Críticos (infraestructuras energéticas y militares).

The Cognitive Loop

El latido del sistema: Ciclo de decisión de 10 segundos.

T+0s: Ingesta & Normalización

El Gateway recibe tramas raw (Modbus/DNP3). El `Normalizer Service` las convierte a un esquema JSON canónico (`UnifiedDataSchema`). Se actualiza el caché en memoria (Redis/Dict).

T+3s: Simulación Física

Detectado el cambio de estado, el `Simulation Engine` (OpenDSS/EPANET) corre un flujo de carga (Load Flow). Calcula variables derivadas (pérdidas técnicas, margenes de seguridad) que no miden los sensores.

T+5s: Evaluación de Reglas (Alert Engine)

Con el estado enriquecido (Real + Simulado), el `Alert Engine` evalúa miles de reglas AST. Si se dispara una alerta critica, se crea un `Incident`.

T+8s: Razonamiento & Acción

El `Action Manager` toma el incidente. Si hay "Modo Autónomo" activo, consulta al `Reasoning Engine` por un plan de mitigación. Se ejecuta el comando de control (ej. abrir interruptor).

T+10s: Sincronización UI

Se emite un evento WebSocket al frontend. El `Living Map` se repinta. El ciclo comienza de nuevo.

Physical Deployment Spec

Containerización y Orquestación para Alta Disponibilidad.

Container Stack (Microservicios)

  • > cognitive-backend (FastAPI) El núcleo lógico. Escala horizontalmente (stateless excepto por managers en memoria).
  • > cognitive-worker-indexing (Python) Proceso background para embeddings. Consume mucha CPU/RAM. Se despliega en nodo separado.
  • > qdrant-vector-db (Rust) Almacenamiento persistente de vectores semánticos.
  • > timescaledb (PostgreSQL + Extension) BD relacional + Series de Tiempo para telemetría histórica.

Networking Strategy (Nginx)

Nginx actúa como Reverse Proxy y Terminador SSL (mTLS). Gestiona el enrutamiento de Websockets para `/ws/scada-stream` evitando el bloqueo del pool de hilos de Uvicorn principal.

Volume Persistence

Los dominios residen en `/opt/cognitive/domains` (mapeado como volumen). Esto permite "Hot-Reloading" de configuraciones YAML: al editar un archivo en disco, el `DomainManager` detecta el cambio en el siguiente ciclo de descubrimiento.

Advanced Cognitive Intelligence

Deep Reasoning, Predictive Analytics & Unsupervised Evolution.

5.1 The "Predictive Chat" Kernel (RAG Pipeline)

El "Chat" no es un simple wrapper de LLM. Es una interfaz de comando y control natural que implementa una arquitectura RAG (Retrieval-Augmented Generation) Recursiva. El `ReasoningEngine` (`reasoning_engine.py`) construye dinámicamente un "Context Window" de alta fidelidad antes de invocar al modelo (DeepSeek-V3).

Context Construction Strategy

  • [LAYER 1] Real-time Telemetry: Inyecta el último vector de estado (ej. 10s) de SCADA/IoT. El LLM "ve" el voltaje exacto en tiempo real.
  • [LAYER 2] Semantic Graph: Utiliza `semantic_engine` para buscar en Qdrant nodos relacionados (vecinos topológicos) al activo mencionado.
  • [LAYER 3] Active Alerts: Lista de violaciones de reglas activas para dar contexto situacional de urgencia.
# System Prompt Structure (Generated dynamically)
SYSTEM: You are the Intelligent Operator for domain 'EnerGen'.
ACCESS LEVEL: ROOT.
CONTEXT:
- Asset: SUB-BACATA-TR1 (Transformer)
- Telemetry: { active_power: 45.2MW, oil_temp: 89°C (CRITICAL) }
- Config: { max_temp: 85°C }
- Neighbor: LINE-782 (Connected)

USER QUERY: "¿Cuál es el riesgo actual?"
AI: "Riesgo Crítico. La temperatura del aceite (89°C) excede el umbral nominal (85°C)..."

5.2 Predictive Radar

El `PredictiveEngine` (`predictive/engine.py`) opera en paralelo al ciclo de control para proyectar estados futuros y evitar fallos antes de que ocurran.

  • Short-Term (Linear Regression): Proyección rápida (T+10min) usando Scikit-Learn. Ideal para detectar tendencias térmicas inerciales inmediatas. Costo computacional cercano a cero.
  • Long-Term (Facebook Prophet): Análisis de series temporales (T+24h) considerando estacionalidad (día/noche, demanda pico). Se ejecuta en `indexing_worker` para no bloquear.

5.3 Unsupervised Rule Evolution

El sistema aprende de lo que NO sabe. El `EvolutionService` utiliza algoritmos de detección de anomalías no supervisados para proponer nuevas reglas al operador humano.

Algorithm: Isolation Forest (iForest)
Input Features: Multivariate Telemetry Vectors
Output: Candidate Rule (Proposal)

*Las reglas "aprendidas" nunca se activan automáticamente. Pasan a un estado `PROPOSED` en la UI para validación humana (Human-in-the-Loop).

5.3 Unsupervised Rule Evolution

El sistema aprende de lo que NO sabe. El `EvolutionService` utiliza algoritmos de detección de anomalías no supervisados para proponer nuevas reglas al operador humano.

Algorithm: Isolation Forest (iForest)
Input Features: Multivariate Telemetry Vectors
Output: Candidate Rule (Proposal)

*Las reglas "aprendidas" nunca se activan automáticamente. Pasan a un estado `PROPOSED` en la UI para validación humana (Human-in-the-Loop).

Physics, GIS & Semantic Graphs

Modelado Físico, Mapeo Geoespacial y Ontologías Avanzadas.

6.1 Modular Physics Engine

La simulación no es rígida. El `SimulationEngine` implementa un sistema de Plugins Dinámicos (`PhysicsPlugin`) que carga la lógica de dominio en tiempo de ejecución (`importlib`).

  • MODE A: Legacy Simulation (OpenDSS/Plugin)

    Cuando no hay Gateway, el motor calcula flujos de potencia ("Load Flow") o hidráulica usando solvers matemáticos internos. Soporta inyección de fallos (`inject_fault`) para simulacros de entrenamiento.

  • MODE B: Shadow Mode (Gateway Sync)

    En producción, el simulador se "apaga" y entra en `Shadow Mode`. Sincroniza su estado interno consultando la tabla `domain_states` poblada por el Gateway Edge, actuando como un espejo digital de latencia < 500ms.

6.2 GIS & Network Schematics

La visualización (`NetworkGraph.tsx`) es híbrida. Combina capas geoespaciales (Lat/Lon) con topología lógica.

GIS Layer (Leaflet/Mapbox)

Renderiza activos sobre tiles reales. Maneja proyecciones CRS EPSG:4326.

Schematic Layer (Cytoscape)

Renderiza diagramas unifilares ortogonales auto-organizados (Auto-Layout).

6.3 Semantic Layer (RDF + SPARQL)

El sistema "entiende" el negocio mediante grafos de conocimiento estándar (W3C RDF). No usa esquemas SQL rígidos para definir relaciones, sino tripletas (Sujeto, Predicado, Objeto).

SPARQL Endpoints (Internal)

>> SELECT ?s ?p ?o WHERE { ?s rdf:type cim:Transformer }

Business Rules & Learning

Las reglas de negocio no son `if/else` hardcodificados. Se almacenan como modelos `LearnedRule` y se evalúan dinámicamente. El sistema permite:

  • Validación de Topología (Connectivity Checks)
  • Reglas operativas complejas ("Si X > 80% Y Z está OPEN")
  • Aprendizaje continuo de patrones de fallo.

Estrategia de Integración

Cognitive Manifest y Soporte Multi-Estándar.

The Cognitive Manifest (`cognitive-manifest.json`)

Para evitar deuda técnica, cada dominio nace de un archivo estricto de definición. El sistema soporta "Discovery-Driven Onboarding", donde la topología se autodescubre desde el Gateway.

bootstrap_strategy: "DISCOVERY"
industry_template: "energy-transmission-cim"

Frontend Architecture

Comprehensive Component Catalog & Engineering Specs

Cognitive Operations Suite

ChatPanel.tsx

Stream Reader

Interfaz conversacional RAG. Implementa Native Fetch Streams con `TextDecoder` para renderizado token-a-token. Gestiona el historial cliente-servidor y permite exportación local a Blob/PDF sin tocar el backend.

useChatStream() MarkdownRenderer

ActionControlCenter.tsx

Polling & Optimistic UI

Panel "Human-in-the-Loop". Utiliza estrategia de Short Polling (2s) para sincronizar estados de incidentes criticos. Implementa actualizaciones UI optimistas para la Aprobación/Rechazo de acciones acciones antes de confirmar con la API.

Optimistic Updates Audit Logs

PredictivePanel.tsx

Multi-Model Viz

Visualizador agnóstico de modelos (Linear, Prophet, LSTM). Renderiza intervalos de confianza usando CSS-based Bar Charts dinámicos para evitar el overhead de librerías de charting pesadas. Incluye mapas de calor de estacionalidad.

CSS Charts Prophet Integration

EvolutionPanel.tsx

State Management

Dashboard de Aprendizaje No Supervisado. Gestiona grandes listas de "Candidatos" (reglas propuestas) usando paginación virtual y filtrado en cliente. Sincroniza ciclos de aprendizaje con el backend (Isolation Forest).

Domain Engineering

NetworkGraph.tsx

D3 Force Sim

Motor físico puro D3.js. Implementa `d3.forceCollide` con radios dinámicos por tipo de activo. Utiliza filtros SVG `` personalizados para efectos de Glow/Resplandor en líneas de alta tensión activas.

d3-force SVG Filters

RDFGraphVisualization.tsx

High-Perf Graph

Inspector de Ontologías optimizado. Envuelto en `React.memo` estricto para evitar re-renders. Implemeta Semantic Zoom (LOD): oculta literales y etiquetas a bajo zoom (k menor a 0.8) para mantener 60FPS con +2500 nodos.

React.memo LOD Zoom

TopologySummary.tsx

Inventory Stats

Agregador de métricas en tiempo real. Calcula resúmenes de conectividad e islas eléctricas.

IncidentTimeline.tsx

Temporal Viz

Visualización cronológica de eventos SCADA. Mapea series de tiempo a eventos discretos de incidencia.

System Administration

GatewayManagement.tsx

110KB • The Beast

El componente más complejo. Incluye un Wizard "Smart Connect" para autodescubrimiento de dispositivos Modbus/REST. Gestiona arquitectura híbrida: registra Drivers en el puerto 8001 (Gateway) pero guarda Mapeos Semánticos en el puerto 8000 (Backend).

Smart Connect Wizard Hybrid API (8000/8001) CSS Topology Flow

DomainCreateModal.tsx

Generator Wizard

Wizard de aprovisionamiento. Selecciona Templates de Ontología (Energy/Water/Gas) y genera automáticamente Domain IDs basados en el Tenant. Orquesta la creación de schemas aislados en PostgreSQL.

Auto-ID Gen Ontology Templates

DomainManagement.tsx

Lifecycle Admin

Dashboard Multi-Tenant. Gestiona el ciclo de vida (Activo/Inactivo) de los dominios y sus usuarios. Permite activar motores cognitivos por región y monitorea el conteo de usuarios concurrentes.

Multi-Tenant CRUD Access Control

UserManagement.tsx

RBAC

Control de acceso basado en roles. Asigna permisos granulares a nivel de Dominio y Componente.

SystemAnalytics.tsx

Observability

Métricas de rendimiento de contenedores y salud de los Microservicios.

Core Services & Context

AuthContext.tsx

Manejo centralizado de tokens JWT, renovación de sesión y perfiles de usuario.

DomainContext.tsx

Propagación del `domain_id` activo a todos los micro-frontends.

semanticService.ts

Abstracción de cliente SPARQL. Transforma respuestas JSON-LD en objetos TypeScript.

scadaService.ts

Cliente WebSocket optimizado para telemetría de alta frecuencia (50ms).

INDUSTRY DATA MODEL (ONTOLOGY) PHYSICS KERNEL KEY ENTITIES
Energía IEC 61970 (CIM) OpenDSS / Pandapower Breaker, Transformer, ACLine
Water WaterML 2.0 (OGC) EPANET Pipe, Valve, Pump, Reservoir
Smart Buildings Brick Schema EnergyPlus AHU, Chiller, Zone, Sensor
Oil & Gas PPDM / PODS DWSIM Well, Pipeline, Compressor