Most platform barrier projects are bought on the hardware: post spacing, cable diameter, lift height, wind load. The management layer usually appears in the specification as a single line, something like "central control system included", and gets settled in the last meeting before delivery.

That is backwards. The hardware does one thing, and it does it the same way every hour of the day. The management layer decides whether the barrier opens at the right moment, whether a fault is noticed before a passenger notices it, and whether anyone can prove what happened afterwards. In service, that is where most of the trouble shows up.

This article describes what a platform barrier control platform actually does, using the architecture we build and commission, so that the next tender you write has something specific to ask for.

The control hierarchy is the product

A platform barrier is not one machine. It is a row of lifting units, a local control station at each platform side, and a management layer above them. Commands can arrive from several places at once, so the first thing the platform has to define is who wins.

Our hierarchy runs, from highest priority to lowest: emergency stop, local control box (LCB), handheld remote, platform local station (PSL), local control platform, then the central management platform. The rule behind the ordering is simple: the closer a person is to the equipment, the more authority they have.

The practical consequence matters more than the list. When an LCB is switched into maintenance or locked out, upper-level commands must be rejected, not queued. If the central platform can still lower a barrier that a technician has locked out, the hierarchy is decoration. Ask any vendor how their system behaves in that state; the answer tells you whether they have actually commissioned one.

What the platform can see

The management layer works at unit level, not at the level of "the barrier". Each lifting unit reports its own state: raised, lowered, travelling, fault, or manual. On a double-unit installation the two posts are treated as two independent devices, which is what allows one side to be serviced while the other keeps working.

Units can be grouped by platform side, by train formation, or by boarding zone, and regrouping is a software operation rather than a rewiring job. That matters at stations where different rolling stock stops at different positions through the day: the same hardware, grouped differently, serves an eight-car train in the morning and a sixteen-car set at peak.

Above the unit view sits a status board: current state of every group, the last command and who issued it, and running counts by day, month and total. Operations teams use the counts far more than they expect to, because it is the quickest way to spot a unit that is cycling twice as often as its neighbours.

Alarms that carry weight

A platform barrier generates a lot of events. The useful ones are sorted into three tiers: severe, important and general. A severe alarm is the kind that stops boarding; an important one needs attention during the shift; a general one is recorded and reviewed later. Without that sorting, every event looks the same and the alarm list stops being read.

The sources are worth knowing. Infrared beam pairs watch the platform edge and trigger when a person or object crosses the warning line. Obstacle detection works during travel, and the unit reverses rather than forcing through. Intrusion triggers a fast audible alarm and the signal goes up to the monitoring terminal immediately.

Visual and audible indication sits on the same layer: red for closed, green for open, amber flashing while moving, voice prompts during travel, and a display showing the next service and car numbers. None of it is sophisticated, but all of it has to be driven by the platform, not wired as a separate system that drifts out of sync with the barrier state.

The audit trail nobody asks for until they need it

Every command is logged with user, time, unit and action. In normal operation nobody looks at it. After an incident, it is the difference between a five-minute answer and a week of speculation.

The log answers questions that come up regularly in practice: was the barrier down when the train arrived, who raised it, was the local box in maintenance at the time, did the gate interlock fire before or after the door release. Regulators and insurers increasingly ask for this record, and retrofitting logging into a system that was never designed for it is not realistic.

How it connects to the station

The fieldbus layer is CAN, with dual redundant Ethernet above it on Cat 6a cabling. At the station interface we offer Modbus TCP as the preferred protocol, with dry contacts as the fallback for operators whose systems will not take a network feed.

That combination is enough for SCADA integration without custom development on either side. The station control room sees the barrier as a set of points it can read and command, which is what most operators actually want: not a second screen, but the barrier appearing inside the screen they already watch.

Interfaces are also reserved for ATO, passenger information and the production control platform, and the system can be interlocked with ticket gates so that gates opening lowers the barrier and the end of ticket checking raises it. Where train detection is available, the barrier can follow it automatically; where it is not, the barrier stays an actuator and waits for a command. That distinction is covered in more detail in our article on the AI vision linkage system.

What happens when the network drops

The barrier has to keep working when the network does not. Local control stays live, the PSL keeps operating its own platform side, and the central platform loses visibility but not authority over safety functions, because those were never delegated to it.

The same principle applies to sensing. If the platform cannot establish whether a train is present, it raises an alarm and hands the decision to staff. It does not guess. A barrier that lowers on a bad inference is worse than a barrier that stays up and asks for a human.

Commissioning, firmware and change control

Parameter changes, grouping changes and firmware updates are done online through the platform. At a station with twenty platform sides, that is the difference between a two-hour job and a two-week programme of night shifts.

It also creates a requirement: every change should be logged and attributable, and firmware versions should be visible per unit. Ask for that in writing. A management platform that cannot tell you which units are running which firmware will eventually cost more than it saved.

Six things to write into the tender

First, the control hierarchy, stated explicitly, with the rule that local lockout rejects remote commands.

Second, the protocol. Name Modbus TCP and dry contacts, and say which points the station system needs to read and write.

Third, the unit model. Confirm that double units report as two devices and that grouping is configurable without rewiring.

Fourth, alarm tiers and destinations. Say which events must reach the control room, and which can stay in the log.

Fifth, the audit log. Retention period, fields recorded, and who can export it.

Sixth, the failure behaviour. What the barrier does on loss of network, loss of sensing, and loss of main power, stated as a behaviour rather than a promise.

Where the platform fits

A management platform does not make a barrier safer on its own. It makes the safety behaviour visible, repeatable and provable, which is what turns a piece of equipment into something an operator can run for fifteen years without surprises.

The automatic platform guardrail range ships with this control layer as standard, and the same platform is used on non-rail applications such as BRT, airport and ferry terminal platforms where there is no signalling system to lean on.

If you are writing a specification, send us the platform layout and the interfaces your station system already supports. We will come back with a point list and a control scheme rather than a brochure. Company background is on the about page.