Embedded Choice UI

Embedded devices increasingly ship with a modern operator interface: a touchscreen, or a browser-based UI on a connected tablet. Building one is a full-stack web engineering effort: a React application, client-side state management, a real-time transport, responsive layouts, and the subjective design and flow work a good interface needs. Embedded teams are staffed for firmware, hardware, and real-time control — not web development. The operator interface either waits on a separate web discipline the team has to hire and manage, or it never reaches the standard the rest of the device meets.

Pivotal Rail hit exactly that constraint building a new automated single car test device (ASCTD) for the freight rail industry. The device needed a browser-based UI that ran on a tablet over WiFi, gave technicians a familiar experience after years on the legacy system, supported multiple people monitoring a test with one person in control, and handled report viewing and remote software updates. Pivotal's strength is rail domain knowledge and embedded engineering. What they did not want was to turn their embedded developers into web developers, or wait on a web team, to get the interface the device needed.

OEG built Embedded Choice UI: a web UI system an embedded device controls entirely through an MQTT API. The embedded developer defines the operator interface (screens, menus, prompts, status fields, input flows) as JSON templates that build into the device's control application. At runtime, the device drives that interface by publishing MQTT messages: template updates that change what is on screen, and data updates that fill it. The web layer is a generic renderer. It holds no device-specific logic and no device-specific code. An embedded developer who can publish an MQTT message can build and operate a modern web interface without writing web code.

The frontend is a client-side React application — Next.js and TypeScript — that runs in any standard browser and is responsive across tablets and laptops. A Python backend, built on Flask-SocketIO, bridges the browser to the device: it relays between each browser's WebSocket connection and the MQTT message bus the control application speaks. An nginx reverse proxy serves the frontend and terminates HTTPS; a Mosquitto broker carries MQTT between the web layer and the control module. Because the contract between device and UI is nothing but MQTT messages, the embedded side and the web side stay fully decoupled — either can change without touching the other, as long as the messages hold.

The operator behavior the technology needs is built in. Embedded Choice UI supports a single control mode and an unlimited monitor mode: one operator holds control of the device while any number of additional users watch the same live status, with a defined path to take control over. Real-time telemetry from the device streams to every connected browser. The technology also covers report generation and viewing and remote software updates, and it records test results to a time-series database for historical reporting.