Inspection robots on a depot's own pool
A depot inspects the same train every night with crawlers, drones, and cameras from different suppliers, and keeps what it finds for years. A Czar Grid in the depot runs the inspection models and holds the record.
· 4 min read
IN SHORT
A rail depot runs its inspection models on a Czar Grid in its own rack rather than on each crawler or in each supplier's cloud. Under-frame, pantograph, and wheel inspection from robots and drones of different suppliers is served from one pool over the depot's network, and every finding is written to a record the depot keeps. Tasks that cross suppliers, such as shunting, wash, and inspection, are authored once in Agency Studio, approved by a named role, and replayable.
Every night a depot brings the same trains back under the same roof and asks the same question of each of them: is this unit fit to go out in the morning. The answer is assembled from under-frame crawlers, pantograph cameras on the gantry, wheel-profile stations on the entry road, and drones over the roof, bought from different suppliers in different years. The models that read what those machines see are too large for a crawler to carry, and what they find is too sensitive to send to someone else's servers. The depot also keeps the record of every finding for as long as the rolling stock runs. A pool in the depot runs the models and holds the record, and that is the shape of Czar Grid on a rail site.
What is in the shed at night
A maintenance shed is a mixed fleet by nature. The under-frame crawler came with the bogie contract, the pantograph camera with the overhead-line work; the wheel station was a separate purchase, and the drones that survey the roof are newer still. Each arrived with its own vision software, its own idea of where images go, and in most cases its own cloud account. Beside them are the shunters and the wash plant that move and clean the trains between inspections.
None of these machines needs to be replaced for the pool to serve them. Each supplier's software calls the pool over the depot's own network for the perception it cannot run on board, inside the time budget the machine has. Safety, stops, and motion limits stay on the robot as the vendor built them; the pool answers questions, it does not drive the machine.
Why a cloud and a GPU on every crawler both fail
The cloud fails on three counts. Each supplier's cloud is a separate uplink from a depot network that would rather have none, carrying imagery of the operator's own rolling stock to a third party. A finding has to be in the record before the train leaves the shed, not after an overnight sync completes, and a model in a distant region cannot promise that. And the imagery and the maintenance history belong to the operator, who answers for the unit's condition long after any supplier contract has ended.
A GPU on every machine fails differently. A crawler sized for its hardest frame carries that hardware under a train for the whole shift and uses it for a fraction of it. The same model has to be loaded, updated, and verified on every unit separately, and capacity that sits on the crawler cannot be shared with the drone or the wheel station, so the depot buys the peak several times over and still cannot pool it.
Inspection under the train, on site
On the Grid, the inspection models run in the depot's own rack. Inference serves under-frame, pantograph, and wheel models to whichever machine asks, from any supplier, within its budget. Each finding is written to one record with the image it was drawn from, the model version that read it, and the unit and time it refers to. Retrieval lets the engineer who signs the unit off see that finding beside the unit's history rather than in a supplier's portal.
The models improve on the depot's own fleet. Adaptation tunes them overnight on the depot's captures, so a kind of wear particular to this operator's stock and routes is learned here rather than approximated from a general set. Evaluation checks each adapted model against a held-out set of the depot's own images before Inference serves it. Nothing in that loop leaves the building.
A task the depot can sign
Inspection is one of several jobs that cross suppliers. A unit is shunted into the shed, washed, inspected from underneath and above, and shunted out again, and each step belongs to a different machine and often a different vendor.
Agency Studio on the Grid is where that sequence is written. The depot authors the task once: the order of steps, the machines each step may use, the conditions under which it stops and waits for a person, and the role that approves it. A named role approves the task before it runs, every run is recorded, and any run can be replayed when an engineer wants to know why a unit was released or held. The task is bounded, so an unexpected condition ends in a hold and a question for a person, not an improvisation.
What stays in the depot, and who holds it
The imagery, the adapted models, the task definitions, and the record all sit on the depot's own hardware, under the depot's own access rules. Watchman verifies the integrity of what the nodes are running. On a connected site, Local Bridge permits only the routes the depot declares, typically the maintenance management system and the suppliers' fleet software, and denies the rest by default. On an air-gapped site there is no route out, and updates arrive as signed bundles carried into the room.
Placing and buying the pool
The nodes go in the depot's own rack, on the depot's own network. The subscription is for the configured Grid: hardware, platform license, and sustainment in one line, fixed for the term, and it does not move when another crawler or a second drone supplier joins the pool. Where an inspection supplier would rather ship the pool with its own equipment under its own name, it does so as Czar Chassis, which is the same Grid reaching the depot by another route.
What the operator ends up with is a shed where the machines keep their jobs, the suppliers keep their software, and the depot keeps what matters to it: the models that read its trains, the record of what they found, and a task it can sign its name to.
Questions this raises
- Do the inspection robots have to be replaced to use the pool?
- No. Each supplier's software calls the pool over the depot's network for the perception it cannot run on board, and the machine keeps its own safety, stops, and motion limits. The crawler, the drone, and the wheel station stay as they were bought; what changes is where the large models run and where the findings are written.
- Where does a finding go once the pool has made it?
- To one record on the depot's own hardware, with the image it came from, the model version that read it, and the unit and time it refers to. The engineer who signs a unit off reads it beside the unit's maintenance history rather than in a supplier's portal. Nothing in that record leaves the depot.
- Can a depot that is air-gapped still run the pool?
- Yes. On an air-gapped site there is no route out at all, and updates arrive as signed bundles carried into the room. On a connected site, Local Bridge permits only the routes the depot declares, such as the maintenance management system and the suppliers' fleet software, and denies the rest by default.
KEEP READING