Arquitectura de buses y fronteras de comunicacion

Frontera 1 — in-memory. Diseñado para 60+ sensores a 60fps.

Bus interno de Sim1 optimizado para datos numericos de alta frecuencia. No es un event emitter — es un buffer compartido que los consumidores leen directamente.

Productor (SimulationEngine)

Escribe valores directamente en el buffer. Incrementa la version global y la version del sistema afectado. Sin callbacks, sin allocations.

// SimEngine escribe en cada tick
buffer.values[sensorIndex] = newValue;
buffer.status[sensorIndex] = sensorStatus(sensor, newValue);
Atomics.add(buffer.version, 0, 1);
buffer.systemVersion[systemIndex]++;

Consumidores (pull-based)

Cada consumidor guarda su ultimo lastVersion. En su RAF/tick, compara con la version global. Si cambio, lee los datos que necesita. Zero-copy.

// TabChart (30fps) — lee solo si hay datos nuevos
const currentVersion = Atomics.load(buffer.version, 0);
if (currentVersion !== this.lastVersion) {
  // Leer solo los sensores activos
  activeSensors.forEach(s => {
    const val = buffer.values[s.index];
    this.pushToRingBuffer(s.id, val);
  });
  this.lastVersion = currentVersion;
}

DebugBus esta diseñado para eventos de texto con nivel y categoria. Publicar 60 sensores × 60fps = 3600 eventos/segundo lo saturaria. Sim1Bus es un buffer numerico compartido que los consumidores leen cuando necesitan — pull, no push. La diferencia fundamental: DebugBus notifica a los suscriptores (push), Sim1Bus expone los datos para lectura (pull).

CommsManager esta diseñado para cruzar la Frontera 3 (red). Publicar por MQTT 3600 veces/segundo para datos que van a ser consumidos en la misma pestaña es un desperdicio absurdo: serializar JSON, pasar por el WebSocket al broker, volver por otro WebSocket, deserializar. Sim1Bus evita todo eso — acceso directo en memoria.

Solo cuando los datos necesitan salir del browser (instructor remoto, FDR en RabbitMQ Streams) se usa el SimulationCommsAdapter para publicar por CommsManager. Y lo hace a frecuencia reducida (1-10fps, no 60fps).

Frontera 1 — in-memory. Diseñado para eventos de texto con nivel y categoria.

Bus de diagnostico existente, usado por Debug1, ObjectRegistryContext, TabLog, TabConfig. Patron event emitter clasico: dbg.registry('info', 'hwObj registrado', data).

Sim1Bus y DebugBus son complementarios, no competidores:

Sim1Bus transporta datos numericos de alta frecuencia (valores de sensores, 60fps). Solo datos. Sin texto, sin niveles, sin categorias.

DebugBus transporta eventos discretos con contexto humano (fault inyectado, escenario cambiado, umbral cruzado). Baja frecuencia, alta legibilidad.

Un puente entre ambos: cuando un sensor cruza un umbral (detectado leyendo Sim1Bus), se emite un evento al DebugBus canal 'sim': dbg.sim('warn', 'EGT_L crossed caution: 852°C', { sensor: 'EGT_L', value: 852, threshold: 850 }).

Frontera 3 — Red. Diseñado para comunicacion entre maquinas via TCP/IP.

Orquestador de adaptadores de transporte. Cada adaptador implementa la misma interfaz (connect, disconnect, subscribe, publish). La app no sabe si los datos llegan por MQTT, WebSocket o STOMP.

RabbitMQ es el unico componente que habla 5 protocolos simultaneamente y traduce entre ellos.

Cada productor entra por la puerta que le conviene (MQTT, AMQP, STOMP) y cada consumidor sale por la suya. La traduccion es interna y transparente.

Analyzer1 tiene 3 puntos de intercepcion del trafico:

Tap interno (F1): Lee directamente del Sim1Bus o intercepta las llamadas encode() de los ProtocolAdapters. Todo in-memory, sin latencia.

Tap MQTT (F3): Suscribe a lru/# via MqttAdapter para ver el trafico real del hardware.

Tap Stream (F3): Lee historico desde RabbitMQ Streams para analisis post-mortem. Como un FDR replay.

En los tres casos, Analyzer1 aplica el ProtocolAdapter correspondiente para decodificar e inspeccionar los datos.

Si en el futuro movemos SimulationEngine a un Web Worker (para no bloquear el UI thread con el game loop de 60fps), necesitaremos transferir 60 sensores × 60fps entre threads. postMessage serializa y copia — demasiado lento. SharedArrayBuffer permite que ambos threads accedan al mismo bloque de memoria sin copia.

El diseño de Sim1Bus con Float64Array + Uint32Array version counter esta preparado para esta migracion. Si el backing store es un SharedArrayBuffer en vez de un ArrayBuffer, el Worker escribe y el UI thread lee sin serializar. Solo necesita Atomics para el version counter.

Requisito: SharedArrayBuffer necesita los headers Cross-Origin-Opener-Policy: same-origin y Cross-Origin-Embedder-Policy: require-corp. Caddy puede configurarlos.