Translation pending for PL — the English text below is canonical.

Use cases · 12 min read

Video wall for transport control rooms: rail, ATC, port, motorway, metro — where software fits and where it doesn't

Last updated: 2026-05-17

Transport control rooms — rail operations centres, air traffic control, port VTS, motorway traffic management, metro OCC, airport operations — share a physical wall format with telco NOCs and broadcast MCRs, but the engineering and procurement problems are substantially different. Human safety is in scope, decades-long operator continuity matters, the incumbent integrators (Frequentis, Indra, Thales, Siemens, Alstom, Hitachi, Saab) supply end-to-end chains the wall has to coexist with, and regulatory frames (EN 50128 / 50129, EUROCONTROL, IMO performance standards) dictate which components can sit in which tier. This article maps the sub-verticals, draws the line between certified primary systems and software secondary visualisation, and lays out where a software-defined wall is appropriate — and where it is not.

What "transport control room" actually covers

The phrase covers at least seven distinct operational environments. Lumping them together produces tender language that fits none of them.

  • Rail Operations Centre (OCC). Manages train movements, signalling state, traction power, station CCTV, and incident response across a railway or metro network. Operator continuity over decades; signalling certified to EN 50128 / EN 50129; integrator stack typically Hitachi (formerly Ansaldo STS), Alstom (formerly Bombardier), Siemens Mobility, or CRRC depending on territory.
  • Air Traffic Control (ATC) tower. Aerodrome control — ground movement, runway in use, weather, light state. Frequentis VCS is the common voice-communications backbone; airfield CCTV, METAR/TAF, and surface movement radar fill the wall.
  • Area Control Centre (ACC). En-route control across sectors of airspace. Wall renders sector-load dashboards, weather hazards, MET briefings, inter-FIR coordination — the primary radar and flight-strip system sits on individual controller consoles, not the wall.
  • Airport Operations Control Centre (AOCC). Ground operations and turnaround coordination — gate allocations, baggage system state, ground transport, security incidents, weather impact on operations. Wall is wide and shared across multiple domain controllers.
  • Port Vessel Traffic Service (VTS). Shore-side maritime traffic coordination — radar plus AIS overlay, CCTV, weather, tide and current, vessel manifests. Saab (now Hexagon), Kongsberg, Indra, and Frequentis supply the certified VTS chains.
  • Motorway / Traffic Management Centre (TMC). Real-time traffic flow, variable-message-sign state, CCTV mosaic, incident response, seasonal weather overlay. Often shared with public-safety dispatch in smaller deployments.
  • Metro / urban transit OCC. Train tracking on a smaller closed network, station CCTV, fare-gate state, passenger-information system health. Often part of a combined transit + bus operations centre.

The procurement of a wall for any of these starts by naming which environment it serves. A wall sized for a rail OCC is not a wall sized for an ATC tower.

The certification tiers — and where a software wall sits

Transport regulation operates in vertical layers. The wall is one of several components that have to know which layer they occupy.

Primary safety layer (certified). Signalling interlocks (EN 50128 / 50129 for rail), ATC radar processing and electronic flight strip systems (EUROCONTROL specs), ECDIS-style navigation displays on ships' bridges (IMO performance standards), SCADA primary HMIs (IEC 61508 functional safety where applicable). Software walls do not occupy this layer in 2026 and are not designed to.

Operational visualisation layer (uncertified, mission-important). Common operating picture, CCTV walls, weather overlays, incident-response dashboards, social and public-information channels, integrator-vendor HMIs (which are themselves certified upstream but render through a standard browser at the wall). This is the layer where software walls belong, and where the IP video transition has made them practical.

Information layer (informational). Public-information screens, passenger information, dispatcher reference material, training mode, after-action review. Software walls handle this comfortably and have for years.

A procurement that mixes the layers produces a wall that is over-engineered for tier 3, under-engineered for tier 1, and right for nothing. The right framing is to spec each layer separately and then ask whether the same physical wall surface can host the operational and information layers, with the primary safety layer rendered on certified equipment elsewhere in the room (or on the controller's own console).

The incumbent integrator landscape

Transport differs from telco NOC in how the procurement is structured. Telco NOC walls are usually a greenfield decision; transport walls almost always coexist with — and sometimes are bundled by — a domain integrator. Knowing the landscape avoids procurement decisions that ignore the integrator dynamics.

  • Rail: Hitachi Rail (signalling, OCC platforms), Alstom (signalling, mainline ETCS), Siemens Mobility (signalling, metro ATC), Thales (signalling), CAF Signalling, CRRC (China), Frequentis (voice and operational communications across operators).
  • ATC / ATM: Frequentis (voice and operational comms — present in most European and APAC ANSPs), Indra (radar and ATM platforms), Thales TopSky, Leonardo SELEX (radar), Lockheed Martin (US ERAM), Raytheon (STARS).
  • Port VTS / VTM: Saab (now Hexagon Maritime), Kongsberg Maritime, Indra Maritime, Frequentis MarineComms, Wärtsilä Voyage.
  • Motorway / road TMC: Swarco, Cubic Transportation Systems, Kapsch TrafficCom, HARRIS / L3 (US), Indra Tráfico (Spain / LatAm).
  • Metro / urban transit: Hitachi Rail STS (formerly Ansaldo), Thales Urban Rail Signalling, Alstom Urbalis, Siemens Trainguard.

Most of these vendors will quote the wall as part of their bid. The operationally and commercially smart move is often to decouple — procure the certified integrator chain separately from the visualisation wall, so the wall can refresh on a commodity cycle (5-7 years) while the integrator chain stays on its own (10-15 year) cycle. Bundling them locks the refresh cadence together and inflates TCO.

Typical source mix per sub-vertical

Source mix drives the wall sizing more than display count. Each sub-vertical has a different shape.

  • Rail OCC (16-32 displays): CCTV mosaic from stations and depots (RTSP, 40-200 cameras rotated on the wall), train tracking from the integrator HMI (browser-rendered), signalling overview (browser-rendered), weather hazard map, incident response panel, social and news feeds for situational awareness. CCTV dominates the source count; the integrator HMIs dominate the decision time.
  • ATC tower (8-16 displays): Aerodrome CCTV (multiple PTZ angles), surface movement radar output (rendered to wall, raw on controller console), METAR/TAF, lighting state, runway in use overview. Fewer sources, denser information per tile.
  • AOCC (12-20 displays): Operational dashboard from the airport ops platform (browser- rendered), baggage system status, gate allocation board, ground transport state, weather impact overlay, security incident channel, social / media feeds during disruption events.
  • Port VTS (8-12 displays): VTS picture from the certified chain (rendered as confidence tile), AIS overlay, CCTV of quays and approaches, weather + tide + current, vessel manifest and pilotage state.
  • Motorway TMC (16-32 displays): CCTV mosaic from gantry and bridge cameras (often 100+ cameras rotated), VMS state map, congestion heat map, weather and road-surface state, incident ticket queue.
  • Metro / transit OCC (12-24 displays): Live train tracking from the signalling HMI (browser), station CCTV, fare-gate and crowd state, PIS (passenger information system) health, lift / escalator state.

Two patterns hold across all of them: CCTV is the source-count dominator (RTSP-heavy ingest, often 30-200 cameras rotated through the wall surface), and integrator HMIs are the decision-time dominators (browser-rendered, sized large, watched constantly). A wall spec'd for either one alone misses the other.

What's changing in 2026

Software-defined walls only became viable in transport in the last 2-3 years. Three converging shifts crossed the threshold together.

  • Integrator HMIs went browser-native. Frequentis VCS, Indra MiOCC, Hitachi Rail signalling dashboards, modern Alstom and Siemens platforms all render through standard browsers. A wall that renders web sources as first-class tiles can host the same HMI the controller sees on their console.
  • IP video reached transport infrastructure. RTSP-capable IP cameras displaced legacy SDI / coax CCTV in most new builds and refresh projects since 2020. NDI appears in operational sub-systems (training, conference, briefing rooms within OCCs). ST 2110 and IPMX are in early deployment in ATM radar pipelines.
  • TCO pressure on long-cycle refresh. Matrix-controller hardware refresh for a sizeable transport wall ranges €800k-€2M including cabling and integration. Commodity Linux servers with perpetual-licence software walls land an order of magnitude lower, with a 5-7 year commodity-hardware refresh cycle instead of 10-15 year proprietary chassis cycle. See TCO breakdown — the same maths applies to transport secondary walls.

Where Craft Wall fits per sub-vertical

Honest scope, sub-vertical by sub-vertical:

  • Rail OCC: secondary CCTV walls, common operating picture overlays, incident response panels, adjacent training and briefing rooms. Renders the Frequentis / Hitachi / Alstom / Siemens browser-rendered HMIs as first- class tiles alongside the CCTV mosaic. Not the signalling chain.
  • ATC tower: aerodrome CCTV mosaic, METAR/TAF web feeds, lighting and ground movement overviews. Pairs with the certified controller console equipment rather than replacing it.
  • ACC / AOCC: common operating picture, weather overlays, ops dashboards, ground transport, baggage state. The cleanest fit — most sources are browser-rendered or RTSP, and the certified ATC radar / flight strip systems stay on controller consoles where they belong.
  • Port VTS: confidence tile of the certified VTS picture, CCTV of quays and approaches, weather and tide dashboards, vessel manifest. Sits alongside the Saab / Kongsberg / Indra primary chain.
  • Motorway TMC: very strong fit. CCTV is most of the source count, VMS state and congestion heat maps are web, ticket queues are web. No primary safety chain at the wall — the chain is in the field equipment (gantries, sensors).
  • Metro OCC: secondary CCTV, PIS health, lift and escalator status, station crowd monitoring. Signalling stays on the certified HMI (Hitachi STS, Thales Urban Rail, Alstom Urbalis, Siemens Trainguard).

Air-gap is more common in transport than in telco NOC — many critical operations centres are intentionally disconnected from the public internet. On-prem deployment on commodity Linux without cloud telemetry is a procurement requirement, not a nice to have.

Tender language to spec correctly

Phrases that consistently produce the right outcome in transport tenders:

  • "Visualisation tier separate from certified safety chain." Explicit decoupling. The wall is not in the signalling / radar / ECDIS chain; it renders alongside those chains.
  • "Browser-rendered HMI as a first-class source type." Forces the wall to handle integrator browser HMIs (Frequentis, Indra, Hitachi, Alstom, Siemens) as first-class tiles, not as screen-share fallbacks.
  • "RTSP-native CCTV ingest at ≥ 32 concurrent streams per node." CCTV is source-count dominator; spec it explicitly rather than assuming.
  • "Air-gap capable; no mandatory cloud control plane; no outbound telemetry." Critical-infrastructure procurement language; rules out cloud-managed architectures that cannot operate disconnected.
  • "Compatible with separate refresh cycle from the certified integrator chain." Decouples the wall procurement from the integrator refresh schedule — protects against bundled-refresh TCO inflation.
  • "Operator continuity over decade-scale deployment." Forces vendors to demonstrate backwards-compatible UI evolution, not Silicon-Valley-style "we redesigned everything in v3".

For the wider compliance frame across sectors (rail, ATC, port, motorway, plus the cross-cutting cybersecurity regulation that increasingly applies), the compliance regulatory guide works through the jurisdiction map.

Read next

For the companion E-use-cases articles in other verticals, see the NOC reference architecture for telco operations and the broadcast monitoring guide for MCR and PCR walls — much of the secondary-tier engineering carries across. For the procurement-and-bake-off playbook that ties the spec language above into a tender process, see the bake-off playbook.

Frequently asked questions

Can a software video wall be used in a safety-critical transport control room?

Not as part of the safety chain. SIL-rated dispatcher consoles, signalling interlocks, ECDIS displays, ATC radar consoles, and SCADA primary HMIs are certified end-to-end (EN 50128 / EN 50129 for rail, IEC 61508 for general functional safety, EUROCONTROL specs for ATC, IMO performance standards for ECDIS). A general-purpose software wall belongs one tier away — secondary situational awareness, common operating picture overlays, incident response panels, CCTV walls, weather and traffic dashboards — rendered alongside the certified primary systems without entering the safety chain. The procurement question is not 'is the wall certified' but 'is the wall correctly positioned outside the safety chain'.

Does Craft Wall meet EN 50128 or EN 50129?

No. EN 50128 (software for railway control and protection) and EN 50129 (safety-related electronic systems) certify the safety-chain components — interlocks, signalling, primary dispatcher HMIs. A general-purpose video wall does not occupy that tier and is not designed to. Craft Wall is appropriate for secondary visualisation in a rail OCC — CCTV walls, common operating picture, weather, social, incident-response dashboards — sitting alongside the certified Frequentis, Hitachi, Siemens, Alstom, or Indra dispatcher systems without touching the signalling chain.

What's the difference between an ATC tower wall, an ACC wall, and an AOCC wall?

An ATC (Air Traffic Control) tower handles aerodrome ground and local airspace; the wall typically renders the airfield CCTV mosaic, weather (METAR/TAF), runway lighting state, and ground movement radar. An ACC (Area Control Centre) handles wide-area en-route control; the wall renders sector-load dashboards, weather hazard overlays, MET briefings, and inter-FIR coordination state — the primary radar plus electronic flight strip system is on the controller's own console. An AOCC (Airport Operations Control Centre) handles ground operations and turnaround coordination; the wall renders the operational dashboard, baggage system state, gate allocations, ground transport, weather, and incident overlays. Three different walls, three different source mixes — common operator-vendor (Frequentis, Indra, Thales) but the visualisation tier is often procured separately.

How is a transport control wall different from a telco NOC wall?

Three structural differences. First, regulatory weight: transport carries human-safety regulation (rail signalling, ATC separation, port collision avoidance), telco does not. Second, operator continuity: transport dispatchers stay in role for decades, telco NOC operators rotate every 2-3 years — the wall has to be intuitive enough for a decade of muscle memory. Third, vendor landscape: transport is dominated by integrators (Frequentis, Indra, Thales, Siemens, Alstom, Hitachi, Saab) who supply end-to-end, often including the wall; telco is fragmented across separately procured NMS, ticketing, and observability tools. A transport wall procurement may have to coexist with an integrator's existing display surface, where a telco NOC wall is usually a greenfield decision.

What about ECDIS and the port VTS chain?

ECDIS (Electronic Chart Display and Information System) is the IMO-mandated primary navigation display for ships; it belongs on the bridge, not on a shore VTS wall. The shore VTS chain at a port — radar, AIS overlay, CCTV, weather, tide and current — is the operational picture for shore controllers. Vendors like Saab (now Hexagon), Kongsberg, Indra, and Frequentis supply the certified VTS systems; a software wall renders the secondary operational picture around the primary VTS console, not the VTS console itself. The line is the same as in rail and ATC: certified system primary, software wall secondary, both visible on the same operator's desk.

Why are software walls only now arriving in transport when telco NOCs adopted them years ago?

Three reasons converging in 2025-2026. First, the integrator stack moved off proprietary X-Window dispatcher consoles onto browser-rendered HMIs in the last five years (Frequentis VCS, Indra MiOCC, Hitachi Rail systems) — a browser-rendering wall is now a first-class citizen rather than a foreign object. Second, the IP video transition (NDI in operational sub-systems, ST 2110 with IPMX in primary radar feeds, RTSP for IP CCTV) finally reached transport infrastructure; a wall that ingests IP video without proprietary capture cards became viable. Third, the TCO pressure on long-cycle transport refresh budgets pushed procurement to consider commodity Linux + software-defined alternatives to €1.5M+ matrix-controller refresh chassis. None of these is sudden — they accumulated until the threshold flipped.

Related reading