Rail Track Intrusion Detection, in Real Time

Rare incidents, purpose-built datasets. A person standing on a live track produces almost no footage to learn from, so IREX built the training data for it deliberately, and what uses that data is an ordinary rule an operator draws on a frame. US railroads call the same problem trespasser detection.

The Module

One Rule, Drawn on the Track Itself

Track intrusion is a documented ObjectTrack Pro use case, and the guide states it in two halves: take visual control over regular maintenance works on the track, and detect intentional or accidental intrusions into restricted areas. The same detector answers both, because both are the same question asked of the same region of the frame.

The module is a two-stage neural pipeline rather than a motion detector. A first convolutional network annotates objects of known classes on sampled frames and tracks them in between; a second network decides what class each object belongs to, here whether it is a person; only then is the object tested against the rule you drew. Because the classifier runs before the rule, weather, litter and rolling stock do not arrive in the alarm list as people.

The rule itself is Motion in region: switch Object type to People, draw the region of interest directly onto the track, choose whether the camera sees the scene from the top or from the side, and name the rule. The name matters more than it looks: it becomes the event name every operator and every later search works with, so "Man on track" is worth typing carefully.

One setting on that tab is the difference between a working channel and a useless one. Ignore people on trains excludes people inside the train box from the "Persons on track" decision, so passengers visible through doors and windows as a service arrives do not fill the monitor with alarms the moment a train pulls in.

The Settings

What an Operator Actually Sets

Everything below is drawn or typed per camera in the module settings, and changed without taking anything offline. Nothing here is fixed in the model, and nothing here needs a retrain when a platform is rearranged.

Region of Interest

The part of the frame to analyze, drawn as a polygon and editable vertex by vertex. It defaults to the whole frame, which on a station camera is almost never what you want: the region belongs on the track and the tunnel mouth, not on the platform.

Object Type: People

The detector class for this use case. The classifier decides whether the thing in the region is a person before the rule is tested, which is what keeps the rule from firing on everything that moves in a track bed.

Ignore People on Trains

Excludes people inside the train box from the "Persons on track" decision. Without it, every arriving service presents a row of people apparently standing in the region, and the monitor becomes unreadable within a day.

The Motion in Region Rule

The rule the use case is built on, named by the operator. The name you type becomes the event name the platform searches on, so a self-explanatory one is worth more than a short one.

Save Tracks

Stores the motion trajectories of the people in the scene so they can be searched in the media player afterwards. It is what turns a single alarm frame into a question about where somebody came onto the track.

Minimum Object Size

A person has to resolve to at least 1,024 pixels, meaning 32 × 32, before they are a candidate. This is the number that decides how far down a platform, or how far into a tunnel approach, one camera actually reaches.

The Hard Part

Training Data for an Event That Almost Never Happens

You Cannot Wait for Enough Incidents

A model learns from examples, and somebody falling onto a track produces almost no footage. Collecting more is not an option anyone would accept. So IREX built specialized safety analytics for railways, subways and air transportation and compiled the training data for these rare incidents deliberately, by working with transportation agencies and by generating synthetic 3D environments. IREX publishes no size for that dataset and no per-module accuracy figure: what is measured is your own cameras, during the pilot, against criteria agreed in writing.

Underground, Where Generic Analytics Give Up

That dataset work is what made the London Underground deployment possible. Track intrusion and train surfing are named as key modules there, alongside crowd management and unattended-item detection, and the point of the reference is the visual conditions rather than the size of the estate: reflection off wet track, tunnel mouths that are black at one end and lit at the other, and a platform that fills and empties every ninety seconds. Detection in those conditions is a dataset problem before it is a camera problem.

Real Time, Because the Question Is Real Time

The documented workflow is deliberately short. Confirm the cameras watching the track meet the module requirements, enable ObjectTrack Pro on them, build an alarm monitor scoped to those cameras and to the Motion in region rule, and switch notifications on. From there the event reaches the people you nominate through the Sover secure messenger with the frame, the camera and a playback link attached. With customizable alarm monitors and the urgent notification system, IREX documents response time falling to roughly one second in most cases.

See Real-Time Alerts & Evidence

The Boundary

Three Things on a Station That Are Not This Detector

A rail estate raises four different questions and this page answers one of them. The other three are separate modules with separate rules, separate camera positions and separate thresholds, and running them together on the same channel is normal.

  1. Crowding at the Platform Edge

    Density on the platform is CrowdCount, not an intrusion rule. It estimates up to 3,000 people in a region you define and alerts on potentially dangerous crowding while there is still time for a steward to act, then counts precisely afterwards for the review.

    See Crowd Management
  2. A Bag Nobody Came Back For

    Unattended luggage is the Abandoned bag rule in the same module, with its own object type, its own proximity filter and its own re-trigger interval. It is a crowded-public-space problem rather than a track one, and it has its own page.

    See Abandoned Object Detection
  3. Fire and Smoke in a Tunnel

    FireTrack detects fire and smoke across large indoor and outdoor spaces, long before a point sensor reacts, which in a tunnel or a deep concourse is the whole argument. It is a different module and not a rule inside this one.

    See Fire & Smoke Detection

Requirements

What the Camera Has to Give It

Camera Mount
Fixed cameras only. PTZ, mobile-phone uploads and drone footage are not supported inputs for ObjectTrack Pro, because the region is drawn on a frame that does not move.
Placement
3 to 15 m mounting height, tilt +15° to +90°, pan −75° to +75°, roll −5° to +5°, and more than 50 pixels per meter inside the region of interest. Contrast against the background needs to reach 20%, which is the figure a dark track bed works against.
Stream
1280 × 720 to 2592 × 1944 at 10 to 30 fps. Computational complexity is rated high, so channel planning matters more here than on a light module.

FAQ

How can you detect something with almost no training footage?

By building the data rather than waiting for it. IREX compiled the training datasets for these rare incidents in collaboration with transportation agencies and by generating synthetic 3D environments, which is what made reliable detection in the visual conditions of underground stations achievable. IREX does not publish the size of that dataset, and publishes no per-module accuracy figure either: the numbers that count are the ones measured on your own cameras during the pilot.

Does it work in a tunnel or on a dark platform?

Those are the conditions it was built for, and the constraint is stated as a number rather than a promise. The module needs more than 50 pixels per meter inside the region of interest and 20% contrast between the object and the background, from a mount 3 to 15 m up with tilt between +15° and +90°. Where a track bed is dark, that is a lens, mount and lighting question the site survey answers, and it is the same question the London Underground deployment had to answer camera by camera.

Will it alarm every time a train pulls in?

Not if Ignore people on trains is switched on, which is what that setting exists for: people inside the train box are excluded from the "Persons on track" decision, so passengers visible through doors and windows do not read as people standing in the region. It is the first thing to check on a channel that is producing an unusable number of events.

Can it tell a track worker from an intruder?

Not by itself, and no detector should claim to. The module reports that a person is in the region you drew, and the documented use case covers both halves on purpose: visual control over scheduled maintenance work on the track, and intentional or accidental intrusion into a restricted area. Which one it is comes from context an operator has and the camera does not, which is why an alarm monitor can also be put on a schedule so a rule that is routine at ten in the morning is an alarm at two.

Do you detect train surfing?

Train surfing is named as a key module on the London Underground deployment, alongside track intrusion, crowd management and unattended-item detection. What the user guide documents as a configurable rule is the track-intrusion case on this page, so treat surfing as a deployed capability to scope with IREX engineering against your own rolling stock and camera positions rather than as a switch in the settings pane.

Is this a life-safety system?

No, and the distinction matters more here than almost anywhere. IREX products are expressly not life-saving or emergency systems, and IREX does not warrant that they will prevent loss, damage or injury. The detector raises an event for a person to verify and act on. It does not stop a train, it does not talk to signaling, and nothing in the platform responds autonomously.

Can we run it on a PTZ camera or on drone footage?

No. ObjectTrack Pro is documented as fixed cameras only, with no PTZ, mobile-phone uploads or drone sources, because the rule is measured inside a region drawn on a frame that does not move. A PTZ still has a place on a rail estate: an operator can drive it manually from the player to get a closer look after a fixed camera has raised the alarm.

How accurate is it on our cameras?

That is the right question, and the honest answer is that we measure it rather than quote it. IREX does not publish per-module accuracy figures, because a number from another city’s cameras tells you very little about yours. Accuracy is benchmarked on your own feeds during the pilot, against two or three success criteria agreed in writing before it starts, and the measured numbers are what go into the contract.

What camera quality does it need?

Any camera that supports ONVIF or streams RTSP with H.264 or H.265 on a static IP can be connected, but connection is not the bar. Each module sets its own resolution, mount position, height, and angle-of-view requirements in the camera requirements, the flagship modules need higher-resolution imagery of the scene than a bare stream, and the recommended primary stream is 1920 × 1080 or 1920 × 1440. A site survey confirms every camera against the module it will run.

Does this run on its own or does someone have to watch it?

It runs on its own and alerts a person. Detections are signals for a human to verify: no response runs autonomously, and the verification and decision are logged against the same Case ID as the detection.

Start on One Platform

One station camera, one region drawn on the track, and a week of ordinary service. That settles the placement question better than a specification comparison.