RailCommand has several user-facing heads that work together. Some tablet and browser-head details are actively changing, so treat this article as a concepts guide until the current tablet/browser UI labels are finalized.
Surfaces
- RailCommand web prepares the railroad.
- RailCommand desktop operates the railroad with local hardware and runtime state.
- Avalonia powers the native desktop/mobile/tablet app heads.
- Browser/tablet head can act as a paired or relay operator surface.
- UE5/local runtime owns local graph execution, safety state, and physical-hardware decisions.
Pairing and Relay Concepts
Tablet or browser operation should be tied to an authorized session, user, role, and train or control surface.
Current code includes pairing and browser relay concepts, including authenticated web-session tokens, ops-session group join, state snapshots, and fail-closed relay outcomes.
Safety Boundary
The tablet or browser head is an operator surface. It should not be treated as the physical-hardware authority.
If a relay call fails, state is stale, emergency stop is not confirmed, or hardware/runtime health is uncertain, stop movement and verify from the host/desktop/runtime side.
Active Code Pending
Tablet/browser head work is still changing. Final end-user screenshots and click-by-click instructions should wait until the active code settles.
Stable guidance today:
- Use desktop for live hardware authority.
- Use tablet/browser heads only within the session and role they are authorized for.
- Treat simulated or relay-limited operation as different from physical layout proof.
- Keep emergency stop and host verification available during live sessions.