Skip to content
LexDataLexData
PlatformIndustriesCustomers
DocsThe Field GuideBlogWhy models drift
AboutCareersSecurityContact
Log inStart now
← All posts

Industries · 7 min read

Railway safety with trackside cameras, zones and a signaller who can live with the alerts

People and vehicles boxed, the track bed and crossing drawn as zones, the frame sent to the control room, and a false alarm rate a signaller will keep reading.

Summary

This post describes railway safety from the trackside and platform cameras an operator already has: people and vehicles boxed, the track bed and the level crossing drawn as zones on the image, and an alert to the control room with the frame attached. It concludes that the false alarm rate has to be set to what a signaller will keep reading, and that rain and night are the frames that come back for review. It is for rail operations and control room teams.

Rajiya Sultana · Engineering Manager · Sep 30, 2026

Camera on a pole over a fenced yard at dusk, fence and vehicle boxed, generated scene with detections from our model

At 6:45 pm a van stalls on the level crossing at the end of a single-track section. The barriers are up, the next train is a few minutes out, and the driver of the van is on the phone to a breakdown service. The camera on the pole beside the crossing has been recording the van since it stopped. The signaller, in a control room some distance away, has a screen with that camera on it among many others, and is looking at a different one.

The train driver will see the van on the approach, with the braking distance a train needs. The camera saw it two minutes earlier, and two minutes is the whole point.

Object detection on people and vehicles is the easy half

The classes are the ones every trackside camera needs: person, vehicle, and on platforms a few more for the things that end up on the track bed, a pram, a bag, a bicycle. Object detection on those classes is a solved shape of problem, provided the model is trained on the operator's own frames, from the operator's own poles, in the light those poles actually get.

You type the classes once, Lexi puts a box on every person and vehicle in every frame, and a person checks each box before the model trains. The frames come from the crossing camera and the platform cameras at the times that matter. On a railway that means the evening peak, the last train, and the hour before the first one when the track bed is dark and the only light is the platform's own.

That is the easy half. Finding a person is not the question a signaller asks. The question a signaller asks is where that person is standing, and a box cannot answer it alone.

The track bed and the crossing are zones on the image

The camera beside the crossing sees the road on both sides, the crossing itself, the track running off in each direction, and the footpath along the fence. A vehicle on the road is traffic. A vehicle on the crossing with the barriers down is the alert. The model boxes vehicles; the zone says which ones matter.

Each zone is a polygon drawn on the camera's image: the crossing deck on camera 4, the track bed beyond the platform edge on camera 7, the yellow line and the strip past it on camera 8. The rule pairs a class with a zone and a state: a vehicle inside the crossing zone while the barriers are down, a person inside the track bed zone at any time.

The hazard zone intrusion use case says what makes this fragile, and it is the part a railway has to take seriously. The zone lives in image space rather than in the world, and everything depends on the camera meaning today what it meant the day the zone was drawn. A maintenance trolley that clips the pole on camera 7 moves the track bed zone onto the platform, and from then on every waiting passenger is on the track.

The alert reaches the control room with the frame

A rule is written as a sentence, with a severity and a cooldown, and approved before it goes live. A person in the track bed zone on camera 7 is high severity with no cooldown. A person past the yellow line on camera 8 is routine, with a cooldown, since people step over that line every minute of the peak and step back. What arrives on the signaller's screen is the frame with the person boxed and the zone drawn, the camera name and the time.

The frame is what makes the alert usable. A signaller with a text line saying "intrusion, camera 7" has to find the camera and look; a signaller with the frame sees the person, sees where they are, and can act in the seconds that matter. On the sites we watch, the alert lands beside the camera feed it came from, so the signaller's next action is one glance rather than a search.

The signaller on the evening shift keeps a note stuck to the edge of the screen listing the regulars: the man who walks his dog along the fence path at 7 pm, the fox that crosses at the far end of the down platform. The note exists because the model has no idea who is a regular, and for a while it will alert on all of them.

The false alarm rate is set to what a signaller will keep reading

This is where I would spend the most time, and it is a review problem more than a model problem. A signaller who gets forty alerts in a shift, thirty-eight of them the dog walker, stops looking at alerts by the end of the week, and the thirty-ninth was the van.

The rate is brought down in three places. The rule confirms before it fires, so a person has to be inside the zone on several consecutive sampled frames rather than one, which drops the fox and keeps the person who has climbed down. The zone edges are drawn tight to the track bed rather than generously, since a generous zone catches the platform edge crowd. And every alert the signaller dismisses is counted, per camera, per week, and read as the review metric it is.

That dismissal count is the honest measure of whether the system is working. A rising dismissal rate on camera 8 with the same zone and the same weather says the model has started boxing something new, and the frames behind the dismissals say what.

Rain and night are the frames that come back

The model that was trained on a dry spring meets its first November of wet rails and low sun. Headlights on a wet crossing throw a reflection down the track that reads as a vehicle. Sodium light on the platform at 5 am makes every coat the same orange. Rain on the lens of camera 4 turns the van into a smear that the model boxes on one frame and loses on the next.

The drift catalog files this as rain, fog and dust: conditions the model rarely saw in training arrive for a week, detection falls off, then it recovers. On a railway the falling off is not silence; it is doubted frames, and those are the ones a person reviews.

LexData takes the trackside model through its whole life. You type what to look for, Lexi puts a box on every person and vehicle in every frame, and a person checks each label before anything trains on it. The model then watches the crossing and platform cameras, in the cloud, on your servers, or on a runner beside the recorder. Frames it is unsure of come back to a person, the corrections retrain it, and the new version replaces the old one with no downtime. The wet November frames are in the version that watches the crossing in December.

The camera has to mean today what it meant when the zone was drawn

The last failure is the quietest. Nobody logs the day the trolley clipped the pole on camera 7. The model keeps finding people, the zone keeps sitting where it was drawn, and the two have quietly parted. The signaller's dismissal count on camera 7 climbs over a fortnight, and the frames behind it show passengers on the platform, boxed, inside a zone that used to be the track bed.

The drift catalog calls it a camera moved, and the fix is the cheapest on the list: redraw the zone from the new framing, relabel a short window of frames from that camera, and fold them in. The dismissal count is what tells you it happened, because nobody else will.

See it on your own footage.

Start with your footage

More in Industries

Industries · 6 min read

Perimeter security with fixed cameras, object detection and a drone sent to look

A frame every two seconds is enough to catch a person at the fence, a CPU is enough to run it, and the drone is the second look rather than the detector.

Andreas Ohrvall · Sep 30, 2026

Industries · 7 min read

Food service QA with a camera over the tray packing line

Every component on the tray gets a box, the missing one is flagged before the sealer, and the alert count is read against the line's own history.

Ayman Quadir · Sep 30, 2026

Industries · 6 min read

Custom vision models for industrial robots, trained on your own castings

The plant's own castings labeled from the cell's camera, defect, orientation and grasp point as the three questions, and a new variant handled by labeling it.

Andreas Ohrvall · Sep 30, 2026

LexData
LexData

Product

  • Platform
  • Industries
  • Use cases

Resources

  • Docs
  • The Field Guide
  • Blog
  • Why models drift

Industries

  • Energy & utilities
  • Oil & gas
  • Agriculture
  • Manufacturing
  • Insurance
  • Retail
  • Robotics

Company

  • About
  • Customers
  • Careers
  • Contact

Trust

  • Security
  • Privacy
  • Terms

Stay updated

What we learn running vision models in production.

See everything.
Miss nothing.

Stay updated

What we learn running vision models in production.

Terms of use & Privacy policy

© 2026 LexData Labs · All rights reserved