Passenger information system (PIS) and automatic passenger counter (APC)

PIS / SIV + APC: one onboard platform

A software platform that synchronises the route, train events, passenger information and counting. PIS maintains the journey model; APC-Curator aggregates sensors; displays, LEDs, audio and backoffice receive a consistent state. Designed for commuter, regional, metro and intercity services.

The software does not replace the TCMS, physical GPS or door sensors. It integrates third-party equipment and turns their signals into passenger information and occupancy data. Scope, signal quality and performance are validated for each fleet.

What a deployment includes

PIS / SIV module: passenger information

The active route drives a shared journey cycle. Each change updates displays, LEDs and audio, and coordinates counting when APC is included.

Operational functions

In variants without TCMS station events, approach announcements are triggered by odometry and route distances: a reference threshold of 1,500 m, adjustable per station. GPS is recorded for progress and diagnostics but does not trigger audio in this configuration. The logic is validated against each project’s signals.

It is not an isolated sensor: it discovers third-party PCS / IBIS-IP counters, reads and resets them at journey milestones and aggregates boardings and alightings by door, car, unit and train. Final accuracy also depends on the sensor and installation validation.

1. 01

   Service start

   line-start activates counting. Sensors retain the reset performed when the previous service ended.

2. 02

   Counting at each station

   On approach, in-motion noise is reset; counters are read live with doors open; station-exit consolidates the final delta.

3. 03

   Closure and snapshot

   line-stop consolidates the final stop, saves the end-of-line snapshot and resets live occupancy.

In coupled formations only MAIN queries physical sensors. APC state is replicated to AUX over HTTP, without sharing the MQTT broker between units. When direction reverses, TrainConfig is updated and the new leading server has the synchronised snapshot.

On fleets without a reliable door signal, IRIS station events act as the platform reference. The origin can be configured to count boardings only; this option is agreed and validated against the service closure logic.

Synchronised HMI, TFT, LED and public address

HMI and content are available per project in Spanish, English, Catalan, Portuguese, Swedish, Norwegian and Basque. Packages include text and audio per language; the combination is defined with the operator.

Train integration: TCMS adapters

TrainEvent and TrainConfig maintain a stable internal contract. Each adapter translates the manufacturer’s signals without rewriting PIS/APC logic; specific interfaces are agreed per rolling-stock series.

TrainConfig: the shared train map

The map arrives from the adapter over MQTT or is loaded through the API. Explorer cross-checks it against network discovery to act only on expected devices.

• Formation: coupled units, cars, server positions and direction.
• Inventory: TFTs, LEDs and APC sensors with assigned addresses and zones.
• MAIN/AUX roles: fixed priorities or priorities delegated to the TCMS adapter.

APIs, protocols and data

REST JSON contracts documented through OpenAPI 3 / Swagger with data validation. HMI and TFTs receive SSE updates; device interoperability uses VDV301 / IBIS-IP.

Integration API areas

The current foundation is VDV301 + MQTT JSON. A dual-stack evolution towards ITxPT, MQTT 5 / AIS is considered when required by the project; no ITxPT label or certification is claimed. Available contracts are confirmed by application type and version.

PIS Cloud, content and APC reporting

Project connectors for PdC-GMV, SJGSS, IRIS / SEPSA, Mediahub / Televic and fleet supervision over MQTT and HTTP healthchecks. Connectivity, formats and cloud scope are agreed with the operator.

Technical specification summary

What the fleet environment must provide

• A stable onboard LAN and addressing consistent with TrainConfig.
• Agreed formation, movement, door or equivalent, GPS and/or odometry signals.
• PCS / VDV301 APC sensors at in-scope doors, except for agreed variants.
• Compatible TFTs / LEDs, an NTP source and appropriately sized disk capacity and logging policy.
• A validated route package: stations, distances, text, audio and thresholds.

Summary based on the supplied platform 2026.10 datasheet. Final interfaces, variants, versions and requirements are confirmed during engineering for each rolling-stock series. It does not replace the integration manual or constitute a certification declaration.

Modules and scope per fleet

A common foundation with modules and connectors defined in the offer. Not every variant includes APC, PA, LEDs or cloud.

1. 01

   Define the fleet

   Leading-end servers, cars, TFTs, LEDs, doors, languages, cloud and available signals.

2. 02

   Agree interfaces

   TCMS signal matrix, TrainEvents and PIS/APC OpenAPI contracts.

3. 03

   Configure rolling stock

   TrainConfig, inventory, roles, PA, LEDs and counting options.

4. 04

   Prepare content

   HMI/TFT identity and the operator’s actual route package.

5. 05

   Validate on the bench

   FAT with simulation, displays, audio, events and counting.

6. 06

   Tune in service

   SAT for real signals, announcement thresholds and counting verification.

Operations include online or offline Uptrain updates, deployment inventories, diagnostics and logs sized for daily service. Support, data retention and maintenance terms are agreed per project.

Frequently asked questions