Skip to main content

Lab Notebook · Rail PA/PIDS Control

A control-room front end for a light-rail line — the gap between a demo and something operators trust

In April 2023 we built a React frontend for a light-rail line's PA and PIDS control, for station operators — the first major React project for real railway operations. It was in progress, deployed to a dev environment, when the record was taken. The real lesson wasn't React — it was what 'ready for a control room' actually demands that a normal dashboard doesn't.

JR
Jon RossFounder, vocabotics — 15 years building safety-critical systemsLab report · dated 15 April 2023
Verified by a human. Drafted with AI, verified by a human. Jon Ross, 15 Apr 2023
Living document. Reviewed 15 Apr 2023
Entry date
15 April 2023
Category
Tooling
Lead over the world
the discipline, not the lead
Access
🔓 Public
ResearchPartly proven

The first time React had to meet a control room, not a dashboard — where a wrong click has a real cost and glanceability isn't a nice-to-have.

React + Redux
state-managed control frontend
Docker + GitHub Actions
CI/CD pipeline in place
v2
in-progress version at time of record

Honest evaluation

Partly proven

A real, working control-room frontend existed and reached a dev environment; it never carried live operator traffic, so the harder claim — 'ready for a control room' — was not tested to completion.

What would prove or disprove it further

What would prove or disprove it further: deployment to production with real operators using it to issue live announcements, measured against error rate and response time under normal operating load, would either confirm the control-room bar was actually met or show exactly where a dev-environment build still falls short of it.

The evidence — full reasoning behind the verdict

Verdict: partly-proven. A real React + Redux control-room frontend was built, containerised, and deployed to a dev environment with CI/CD in place — that part is real, working evidence. But the report is explicit that this was version 2, in progress, and never reached production or carried live operator traffic, so the actual bar this project named — control-room-grade error tolerance, glanceability, and tolerance for the cost of a wrong click — was never tested against real operators under real pressure.

The useful result here isn't the code, it's naming the bar correctly: the report identifies exactly what "ready for a control room" requires that a normal admin dashboard doesn't, before the system reached the point where that bar could be tested for real. That's a genuine, if partial, insight — earned by building far enough to see what was still missing, not by finishing the job.

This was the founder's first major React project built for real railway operations, not a demo. That distinction — real operations, not a demo — turned out to be the whole lesson.

What it was

A React frontend for a light-rail line's PA (Public Address) and PIDS (Passenger Information Display System) control, built for station operators to manage live announcements and passenger displays from a control-room interface.

What we built

Research

A React + Redux application with a Material-UI interface, containerised with Docker and built on a GitHub Actions CI/CD pipeline. At the time of this record it was version 2 of the frontend, in progress and deployed to a dev environment — a real system being iterated toward operational use, not yet carrying live traffic.

What we learned — including the honest negative(s)

The real lesson had nothing to do with React as a framework. It was about the gap between a demo and something an operator actually relies on under pressure. Control-room software for safety-critical operations has a different bar than a typical admin dashboard: error tolerance (a wrong input has real consequences, not just an undo), glanceability (an operator has to read state instantly, not parse it), and the cost of a wrong click (a misdirected PA announcement or a wrong platform display is not a cosmetic bug). None of that shows up by default in a well-built React app — it has to be designed for on purpose.

The honest edge is straightforward: this was "in progress," not a finished green-field system, and the specific line and operator are never named here — referred to only as a light-rail line, safety-critical / global rail & metro operations.

Where it went / status

In progress at the time of this record, deployed to a dev environment. This is the origin point of a much longer rail-domain thread that runs through the rest of the portfolio — later work in the same space, on monitoring, agentic tender scanning, and full production-grade PA/PIDS control platforms, all trace back to the control-room lessons learned here first.

What is still open — kept visible

The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.

  • In progress, not finished — a version-2 build, deployed only to a dev environment at the time of the audit.
  • Control-room UX for safety-critical systems has a materially different bar than a typical dashboard: error tolerance, glanceability, and the cost of a wrong click all have to be designed for explicitly, not assumed.
  • The specific line and operator are never named — referred to only as a light-rail line / safety-critical global rail & metro operations.

Sources

  1. vocabotics project audit — light-rail PA/PIDS control frontend (React, Redux, Material-UI), Apr 2023vocabotics internal project history · as of April 2023

    We use cookies.