Analyzer1 — Plataforma de protocolos y analizador virtual

ARINC 429

Bus unidireccional de 32 bits. Cada palabra es autocontenida: 8 bits label (identifica el parametro), 2 bits SDI (source/destination), 19 bits datos (BNR o BCD), 2 bits SSM (sign/status matrix: normal/NCD/test/fail), 1 bit paridad. Velocidad: 12.5 kHz (low speed) o 100 kHz (high speed). Un cable = una direccion. Sin negociacion, sin handshake. Determinista por diseño.

Uso en A320: ADIRU → PFD/ND (datos de aire, actitud), FMGC → FCU (plan de vuelo), LGCIU → ECAM (estado tren).

MIL-STD-1553

Bus bidireccional command/response. Un Bus Controller orquesta quien habla cuando. Cada terminal tiene direccion de 5 bits (31 dispositivos), 31 subaddresses por terminal. Palabras de 20 bits (16 datos + sync + parity). Dual redundant (bus A + bus B). Velocidad: 1 Mbps. Usado en aviacion militar, satelites, ISS.

Relevancia formativa: Enseña el concepto de bus controlado vs bus libre, redundancia, time-division multiplexing.

AFDX / ARINC 664 Part 7

Evolucion Ethernet del A380/A350. Virtual Links con bandwidth reservado y scheduling deterministico. Cada VL tiene un ID fijo, un origen, destinos fijos, y un BAG (Bandwidth Allocation Gap) que garantiza latencia maxima. Switched full-duplex Ethernet 100Base-TX. Redundancia dual-lane.

Relevancia formativa: Puente entre Ethernet convencional y avionica determinista. Enseña QoS, virtual circuits, bandwidth reservation.

CANaerospace

Protocolo CAN para aviacion ligera y UAVs. Basado en CAN 2.0B (29-bit identifiers). Definicion estandar de message IDs para parametros de vuelo. Ligero, bajo coste, ideal para experimental y UAV.

OPC UA (Unified Architecture)

Protocolo de comunicacion industrial con modelo de informacion semantico. Cada servidor expone un Address Space — un grafo de nodos con tipos, atributos y relaciones. Un cliente puede descubrir que datos hay disponibles sin documentacion previa. Soporta lectura, escritura, suscripciones, eventos, metodos, y seguridad integrada.

Relevancia: El mas completo. Enseña modelado de informacion, descubrimiento, sesiones, seguridad. Companion specs para cada industria.

Modbus RTU / TCP

El abuelo de los protocolos industriales. Registros numerados (coils, discrete inputs, input registers, holding registers). Lectura/escritura directa por funcion (FC01-FC16). Sin metadatos — el significado de cada registro solo lo conoce la documentacion. RTU sobre RS-485, TCP sobre Ethernet.

Relevancia: Ubicuo, simple, excelente para enseñar el concepto basico de register-mapped I/O.

PROFINET / EtherCAT / CANopen

PROFINET: Real-time IO sobre Ethernet. Tres niveles: TCP/IP (no critico), RT (soft real-time), IRT (isochronous, <1ms). Usado en Siemens/industria europea.

EtherCAT: Procesamiento "on the fly" — el frame Ethernet pasa por cada nodo, cada uno lee/escribe sus datos sin almacenar-y-reenviar. Latencia extremadamente baja.

CANopen: Capa de aplicacion sobre CAN. PDOs (Process Data Objects) para datos ciclicos, SDOs (Service Data Objects) para configuracion. Object Dictionary estandarizado.

TCP/IP no es un protocolo mas en la lista — es la base sobre la que funcionan la mayoria de los demas

MQTT, OPC UA, Modbus TCP, WebSocket, STOMP, HTTP — todos viajan encapsulados dentro de TCP/IP. Incluso AFDX (avionica moderna del A380/A350) usa Ethernet/IP como capa de transporte. Entender TCP/IP es entender el medio universal de comunicacion digital del siglo XXI.

Las 4 capas del modelo TCP/IP

4. Aplicacion (OSI L5-L7): HTTP, FTP, SMTP, DNS, MQTT, OPC UA, Modbus TCP. La capa que ve el usuario y el programador. Cada protocolo de aplicacion define su propio formato de datos y semantica.

3. Transporte (OSI L4): TCP (fiable, ordenado, con control de flujo y congestion) y UDP (rapido, sin garantias, sin conexion). Los puertos (0-65535) identifican al proceso destino: HTTP=80, HTTPS=443, MQTT=1883, OPC UA=4840, Modbus=502, STOMP=61613.

2. Internet (OSI L3): IP (v4 e v6). Direccionamiento logico (IP addresses), fragmentacion, routing entre redes. Cada router lee solo esta capa para decidir el siguiente salto. Protocolos auxiliares: ICMP (ping, traceroute), ARP (IP→MAC), IGMP (multicast).

1. Acceso a red (OSI L1-L2): Ethernet, WiFi, PPP, fibra. El frame fisico con MAC addresses. CRC para deteccion de errores. Cada salto cambia las MAC (source/destination) pero mantiene las IP intactas.

Encapsulacion — la matrioska digital

Cada capa envuelve los datos de la capa superior con su propio header (y a veces trailer). Un dato de 7 bytes ("EGT=620") viaja asi:

Capa          Header            Payload                          Total
─────────────────────────────────────────────────────────────────────
Aplicacion    MQTT (2-5B)       {"v":620}  (7B)                  ~12B
Transporte    TCP  (20B)        [MQTT header + payload]          ~32B
Internet      IP   (20B)        [TCP header + MQTT + payload]    ~52B
Enlace        Eth  (14B+4B)     [IP + TCP + MQTT + payload]      ~70B
─────────────────────────────────────────────────────────────────────
              Overhead: 63B     Dato util: 7B                    90% overhead

Comparar con ARINC 429: el mismo dato ocupa 4 bytes con 0% overhead. TCP/IP paga ese coste a cambio de universalidad, routing, fiabilidad y compatibilidad con cualquier red.

TCP vs UDP — la decision fundamental

TCP (Transmission Control Protocol): Conexion establecida (3-way handshake: SYN → SYN-ACK → ACK). Entrega garantizada y ordenada. Retransmision automatica de paquetes perdidos. Control de flujo (sliding window) y congestion (slow start, congestion avoidance). Ideal para: MQTT, OPC UA, HTTP, transferencia de ficheros, cualquier dato donde la integridad es critica.

UDP (User Datagram Protocol): Sin conexion, sin garantias. Envia datagramas y olvida. Sin retransmision, sin orden. Header minimo (8 bytes vs 20 de TCP). Ideal para: DNS, VoIP, video streaming, telemetria en tiempo real donde un dato viejo es peor que un dato perdido, NTP, SNMP.

Decision para la LRU Platform: La telemetria de alta frecuencia (60fps de sensores) podria usar UDP dentro de la red local — si se pierde un frame de EGT a 620.1°C, el siguiente a 620.2°C lo reemplaza. Pero MQTT ya maneja esto sobre TCP con QoS 0 (fire-and-forget). Para comunicacion entre instructor y alumno en maquinas diferentes, TCP garantiza que los comandos llegan.

TCP/IP como protocolo encapsulador universal

Lo que hace unico a TCP/IP en nuestra plataforma es que no compite con los demas protocolos sino que los transporta:

MQTT viaja sobre TCP puerto 1883 (o 8883 con TLS). OPC UA sobre TCP puerto 4840. Modbus TCP sobre TCP puerto 502. WebSocket sobre TCP puerto 80/443 (upgrade desde HTTP). STOMP sobre TCP/WebSocket. Incluso los protocolos que no son nativamente IP pueden encapsularse: ARINC 429 sobre UDP para simulacion remota, CAN sobre TCP para gateways.

El analizador de protocolos puede mostrar esta encapsulacion visualmente: el alumno selecciona un mensaje MQTT y ve las 4 capas desplegables — la trama Ethernet que contiene el datagrama IP que contiene el segmento TCP que contiene el paquete MQTT que contiene el JSON con el valor del sensor.

Valor educativo en la LRU Platform

Fase 1 — Overhead awareness: El alumno ve que enviar "620" via MQTT cuesta 70 bytes pero via ARINC 429 cuesta 4. Entiende visceralmente por que la aviacion clasica no usa IP.

Fase 2 — Wireshark virtual: El traffic monitor puede mostrar los paquetes a nivel TCP/IP: sequence numbers, ACKs, window sizes, retransmissions. El alumno ve como TCP recupera un paquete perdido.

Fase 3 — Comparativa de transporte: El mismo sensor enviado por TCP (fiable, 20B overhead) vs UDP (rapido, 8B overhead) vs WebSocket (persistent, 2B frame overhead tras handshake) vs QUIC (UDP + fiabilidad, 0-RTT).

Fase 4 — Tunneling y VPN: Como un protocolo industrial (Modbus RTU sobre RS-485) se puede encapsular en TCP/IP para control remoto: Modbus RTU → Modbus TCP gateway → TCP → IP → VPN → Internet → IP → TCP → Modbus TCP → PLC. Cada capa añade overhead pero gana alcance.

RabbitMQ no es un protocolo mas — es la infraestructura que hace posible que los protocolos se comuniquen entre si

Si TCP/IP es la carretera universal, RabbitMQ es la estacion central de clasificacion donde los mensajes se reciben, enrutan, almacenan y distribuyen a sus destinos. Cada protocolo llega a RabbitMQ por su propia puerta (MQTT por el puerto 1883, AMQP por el 5672, STOMP/WS por el 15674) y RabbitMQ los traduce internamente a un modelo comun de exchanges, queues y bindings.

Este es el punto clave para Analyzer1: RabbitMQ ya traduce entre protocolos. Un ESP32 publica por MQTT en el topic lru/eng1/egt. RabbitMQ lo convierte internamente a un mensaje AMQP en el exchange amq.topic con routing key lru.eng1.egt. Node-RED lo consume por AMQP, lo procesa, y lo publica en otro exchange. La PWA lo recibe por STOMP/WebSocket.

Analyzer1 puede interceptar en cualquier punto de esta cadena:

Tap MQTT: Suscribirse a lru/# para ver todo el trafico hardware.

Tap AMQP: Crear una cola temporal con binding al exchange de interes — no afecta al flujo existente.

Tap Stream: Leer el stream historico para analisis post-mortem — como un FDR replay.

En cada tap point, Analyzer1 puede aplicar el ProtocolAdapter correspondiente para decodificar los datos: si viene por MQTT, aplica MqttProtocolAdapter para mostrar la estructura del paquete MQTT. Si viene por AMQP, muestra las propiedades AMQP (exchange, routing key, headers, delivery mode).

RabbitMQ es el unico componente que ya implementa la traduccion multi-protocolo en produccion. No es una simulacion — es infraestructura real funcionando. Cuando implementemos los ProtocolAdapters de aviacion (ARINC 429, 1553) e industrial (OPC UA, Modbus), estos pueden publicar y consumir por los mismos exchanges de RabbitMQ. Un adaptador ARINC 429 simulado publica frames binarios en un exchange dedicado; cualquier consumidor (Analyzer1, FDR, otro alumno) puede recibirlos por el protocolo que prefiera.

RabbitMQ Streams son el FDR natural. Append-only, offset-based, persistente. Un stream de simulacion graba todos los frames de todos los protocolos con timestamp. Reproducirlo es simplemente leer desde un offset — exactamente como funciona un FDR real.

El management API es util para Analyzer1. Puerto 15672 expone estadisticas en tiempo real: mensajes/segundo por queue, conexiones activas, exchanges con bindings. Analyzer1 puede consumir esta API para mostrar las estadisticas de trafico en el traffic monitor.

Analyzer1 opera en las fronteras de comunicacion de la plataforma. Para un analisis completo de las 4 fronteras, los buses disponibles, y cuando usar cada uno, ver el documento de arquitectura de buses.

F1 (in-memory): Analyzer1 lee del Sim1Bus directamente para generar frames con ProtocolAdapters. Sin latencia, sin serializar.

F3 (red): Analyzer1 suscribe a topics MQTT via CommsManager para ver trafico real del hardware.

F3 (replay): Analyzer1 lee RabbitMQ Streams para analisis post-mortem de sesiones grabadas.

L7 Aplicacion: Como se nombran y organizan los datos. Labels ARINC vs topics MQTT vs nodos OPC UA. El alumno entiende por que unos son numeros fijos (labels) y otros son strings jerarquicos (topics).

L6 Presentacion: Como se codifican los valores. BNR (binary) vs BCD (decimal) vs JSON vs UA Binary. El mismo numero 620.0 ocupa 19 bits en ARINC, 4 bytes en float IEEE 754, o 7 caracteres en JSON.

L5 Sesion: Quien controla la conversacion. Bus controller (1553) vs broker (MQTT) vs sin sesion (ARINC). Concepto de polling vs pub/sub vs free-running.

L2 Enlace: Como se empaqueta un frame. Palabras fijas de 32 bits (ARINC) vs frames variables (Ethernet). Concepto de overhead: ARINC tiene 0% overhead, MQTT sobre TCP/IP tiene ~80% overhead para el mismo dato.

L1 Fisica: Como viajan los bits por el cable. Bipolar Return-to-Zero (ARINC) vs Manchester (1553) vs diferencial (CAN). El alumno ve la forma de onda y entiende por que cada codificacion existe.

Debug1 (referencia)

DebugContext (isOverlayOpen, toggleOverlay) → Debug1Overlay (createPortal + useDraggableResizable) → Debug1 mode="overlay". En paralelo: ruta /Debug1 → Debug1 mode="page". Boton 🐛 en Header.

Sim1 (referencia)

Sim1Context (isOverlayOpen, engineRunning) → Sim1Overlay (createPortal + useDraggableResizable) → Sim1 compact. En paralelo: ruta /Sim1 → Sim1. Boton 🔬 en Header.

Analyzer1 (nuevo)

Analyzer1Context (isOverlayOpen, activeProtocol, captureRunning) → Analyzer1Overlay → Analyzer1 compact. Ruta /Analyzer1 → Analyzer1 mode="page". Ademas: TabAnalyzer en Sim1 → Analyzer1 mode="embed". Boton 📡 en Header.

Visualizacion bit a bit de un frame individual. Cada campo coloreado y anotado. Para ARINC 429:

Bit:  31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
      ├P─┤├──SSM──┤├────────────── DATA (BNR 19 bits) ──────────────┤├─SDI─┤├────── LABEL (octal) ───┤
Valor:  1   0  0    0  0  1  0  0  1  1  0  1  1  0  0  0  0  0  0   0  1    1  1  0  1  0  0  1  1
Campo:  P   NCD     620.0°C (scaled BNR)                              01     Label 211 (EGT)

Hover sobre cada campo muestra tooltip con: nombre, significado, rango valido, valor actual. Click abre documentacion del campo.

Timeline de mensajes en scroll continuo, estilo Wireshark. Columnas configurables:

Timestamp · Source · Protocol · Label/Topic · Data · Status · Decoded value

Filtros: por protocolo, por label/topic, por sistema, por status (normal/NCD/test/fail), por rango de valor. Trigger/breakpoint cuando un valor cruza un umbral. Rate counter (mensajes/segundo por canal). Color coding: verde=normal, ambar=caution, rojo=warning/fail.

Seleccionar un frame del traffic monitor y ver su encapsulacion por capas OSI. Vista vertical: cada capa muestra que bytes añade, cuantos bytes de overhead, y que funcion cumple. Click en una capa expande su detalle.

Ejemplo para un MQTT publish de EGT=620:

L7: {"v":620} (7 bytes utiles) → L5: MQTT PUBLISH header (2 bytes) → L4: TCP header (20 bytes) → L3: IP header (20 bytes) → L2: Ethernet frame (14 bytes) → L1: Preambulo (8 bytes). Total: 71 bytes para transportar 7 bytes de dato. Overhead: 90%.

Comparar con ARINC 429: L7: label+data (4 bytes) → L2: word (0 bytes extra) → L1: Bipolar RZ. Total: 4 bytes. Overhead: 0%.