Automating a Wayside Fleet: Why Manual Steps Don't Scale Across Trackside Sites
A monitoring platform that watches ten location cases can be run by hand. One that watches a thousand cannot. Every task that a person has to perform site by site — configuring a new device, pushing a logic change, checking a setting is right, restarting a hung process — is a cost, a delay, and a chance to get it slightly wrong somewhere in the fleet. Automation is what makes fleet-scale monitoring economic, and this guide is about what to automate across a wayside estate and what makes it possible. Several of the techniques here come from IT practice, so each is named once for what it is and then explained in trackside terms — because the value is not in adopting the vocabulary, it is in what it buys the maintainer, the control room, and the delay-minutes.
The cost of manual site work
Consider the current model across a large wayside estate. When a firmware update is due on a monitoring unit, a technician travels to the location case, connects a laptop, applies the update, verifies it, and returns. Across a few hundred sites and a couple of changes a year, a meaningful share of a skilled team's time is spent not on diagnosis or repair, but on travelling between cabinets to perform routine, identical steps. Each visit is also an opportunity for a setting to be entered inconsistently, so the fleet gradually drifts out of a common baseline.
Reducing that manual, per-site effort is the objective of fleet automation. The aim is not to replace technicians, but to have the platform handle the routine, repetitive work so skilled staff focus on the diagnostic and repair tasks that genuinely require an engineer at the trackside. Each section below addresses a specific manual step — provisioning a device, deploying a change, maintaining configuration, and recovering from a routine fault — performed once, centrally, across the whole fleet rather than one cabinet at a time.
Provisioning without the site visit
The first manual step to remove is the initial build. Traditionally, commissioning a new monitoring device — or swapping a failed one — means a technician on site with a laptop, hand-entering the settings for that asset and that location. Get one value wrong and the replacement behaves subtly differently from the unit it replaced.
Zero-touch provisioning is the industry term for the alternative: a device that enrols and configures itself on power-up instead of being hand-configured on site. When a new unit is energised in the location case, it proves its identity, is issued its own certificate, and pulls down the configuration approved for its role and position — so a replacement axle-counter evaluator or level-crossing monitor comes up matching the one it replaced, with no laptop in the cabinet. What this buys the fleet is consistency and speed: every device is built from the same approved definition, commissioning a new site no longer waits on getting the right person to the right cabinet with the right settings, and a failed unit can be swapped by whoever is closest because the configuration arrives with the device, not with the engineer.
Deploying changes with confidence
The second manual step is updating what is already deployed. A change to a monitoring logic application — for example, a refined rule for detecting a point machine drawing excessive drive current — has traditionally required an engineer to test it as thoroughly as circumstances allow, then apply it to devices in the field with limited assurance that it behaves consistently everywhere.
CI/CD is the industry term for a tested, staged rollout that proves a change before it reaches a live site. In operational terms, the change is checked automatically against a suite of tests — and, where the risk warrants it, against a simulation or hardware-in-the-loop rig that behaves like the real asset — before it is permitted to ship. It is then released to a small canary group of sites first, monitored to confirm expected behaviour, and rolled out to the rest of the fleet only once that is established. If a staged rollout does not behave as expected, an automatic rollback returns the affected devices to the previous known-good version. The result is consistency: rather than each change being validated differently depending on who makes it, every change to how an asset is monitored is validated the same way, and reaches the fleet in a controlled sequence that can be halted.
Configuration as a controlled record
The third manual step is maintaining an accurate record of what each device is intended to be running. On many estates this information resides in a spreadsheet and in staff knowledge, which means there is no reliable way to confirm that every site matches its approved build.
Configuration as code — sometimes called infrastructure as code on the platform side — means holding the approved configuration for each device as a version-controlled record: a single source of truth, with a full history of who changed what and when. On top of this sits desired-state reconciliation, or GitOps: the platform continuously compares what is actually running on each device against that approved record and flags any difference — the drift. A setting altered manually during a callout and not recorded, or a unit returned from repair on an earlier configuration, is identified as drift the platform can correct or report, rather than remaining undetected until it causes a fault.
| IT term | What it means at the trackside | What it buys you |
|---|---|---|
| Zero-touch provisioning | A device that configures itself on power-up instead of being set up by hand in the location case | Consistent builds, faster commissioning, any technician can swap a unit |
| CI/CD | A tested, staged rollout of a logic or firmware change, proven before it reaches a live site | Every change validated the same way; a bad one caught on a canary site, not the whole fleet |
| Configuration as code | The approved configuration held as a version-controlled record, not a spreadsheet and memory | You can say with certainty what each device should be running, and see the change history |
| Desired-state reconciliation / GitOps | Continuously checking what is really running against what was approved, and flagging drift | A hand-edit or a stale unit shows up instead of hiding until it fails |
| Self-healing runbook | An agreed automatic response to a known, recoverable fault, with escalation if it fails | Routine recovery is handled automatically; staff are called only for faults needing judgement |
Automated recovery from routine faults
The fourth manual step is the after-hours callout for a routine problem. A monitoring process hangs, a mobile link fails over to its backup, or a non-vital asset enters a recoverable fault state — and a member of staff is called out to perform an action the system could have performed itself.
A self-healing runbook is an agreed, automated response to a known fault that runs as soon as the condition is detected: restart the affected process, fail over to the standby link, or reset the stuck non-vital asset. The safeguards are what make it dependable. Automated remediation is bounded — applied only to conditions where the correct response is known and validated, never to a fault the system does not recognise. Every attempt is logged. And if the automatic action does not clear the condition, it escalates to a person rather than retrying indefinitely or masking the problem. Staff are then engaged for the faults that genuinely require their judgement, rather than for a routine recovery a runbook can perform.
Tip: The distinction between safe and unsafe automated remediation lies in the escalation rule, not the sophistication of the fix. Automate only the responses you would be comfortable approving in advance, cap the number of automatic attempts, and make escalation to a person the default when the condition does not clear. An automation that repeatedly retries a failing action is worse than none, because it masks the fault rather than surfacing it.
What makes it possible: an API-first platform
None of the above works if the platform can only be driven by a person clicking a screen. Automation needs every action to be available to be scripted, and that is what API-first means: a well-documented, versioned interface — commonly REST or gRPC — over every operation the platform can perform, so provisioning, configuration, rollout, and recovery can all be invoked by software, not just by hand.
Two properties matter especially at the trackside. First, the platform should push events — through event streams and webhooks — so an integration reacts the instant something happens rather than constantly polling to ask. Second, operations should be idempotent: a command that is safe to send again if the mobile link drops mid-request, because a retry produces the same result rather than a duplicate action. On a low-bandwidth, intermittent mobile connection, that one property is the difference between a reliable automated command and one that occasionally does the job twice. A command-line tool or SDK on top of the same interface makes the whole system scriptable end to end, which is what lets a fleet-wide operation replace a hundred separate site visits.
Security is the hard requirement, not an afterthought
Automation means services and devices acting with no person present to log in, so the credentials behind those actions have to be strong — and never a shared static password copied between devices. Three practices carry most of the weight, and they are the same industrial-security posture that IEC 62443 sets out.
- Per-device identity and mutual authentication. Each device carries its own certificate under a per-device PKI, and connections use mutual TLS (mTLS) so both ends verify each other before anything is exchanged — a compromised or counterfeit unit cannot simply join the fleet.
- Short-lived tokens for service-to-service calls. Automated calls between platform components authenticate with the OAuth 2.0 client-credentials grant — exchanging a credential for a short-lived token — rather than holding a long-lived key that is dangerous if it leaks.
- Least privilege and a complete audit trail. Every automated action runs under fine-grained, role-based access (RBAC) with scoped, expiring tokens, so a component can do only what its job needs and no more. And every action — human or automated — is written to an audit trail recording who or what invoked it, when, and what changed.
The reason to state this so plainly is that automation widens the number of things that can act on the estate. That is only acceptable if each of them is authenticated, authorised to the minimum it needs, and accountable after the fact. Done properly, the monitoring overlay stays what it should be — a read-only, segmented observer of the assets that adds visibility without becoming a new way in.
Why it matters
The economics of wayside monitoring are decided by what happens after the first ten sites. A platform that still needs a person for every provisioning, every change, every configuration check, and every routine restart does not get cheaper per site as it grows — it gets more expensive and less consistent. Automating those steps is what lets a monitoring estate scale to hundreds or thousands of trackside assets without the headcount and the site visits scaling with it, and it is what keeps every device in the fleet on its approved, current, correct build. It rests on an open, API-first foundation and is held to an industrial security standard — so the skilled people are freed for the diagnostic and repair work only they can do.
Frequently asked questions
What does automating a wayside fleet actually mean?
It means replacing the manual, per-site handling of monitoring devices with actions the platform performs itself across the whole fleet. In practice that covers a device configuring itself when it is powered up instead of being set up by hand on site, a logic or firmware change being tested and rolled out in stages rather than flashed device by device, the approved configuration being held as a version-controlled record instead of tribal knowledge and a spreadsheet, and a stuck asset being restarted automatically before anyone is called out. The status quo being replaced is a technician hand-handling hundreds of trackside sites; automation removes that toil so the skilled people spend their time on diagnosis and repair, not on driving between location cases to do routine tasks.
What is zero-touch provisioning for trackside devices?
Zero-touch provisioning means a monitoring device enrols and configures itself when it is first powered up, instead of a technician hand-configuring it in the location case. On power-up the device proves its identity, is issued its own certificate, and pulls the configuration approved for its role and location — so a replacement unit at a level crossing comes up matching the one it replaced without a laptop on site. It removes the error-prone manual build step, keeps every device in the fleet consistent, and means commissioning a new site or swapping a failed unit no longer depends on getting the right person to the right cabinet with the right settings.
How does CI/CD apply to signalling logic applications?
CI/CD is the industry name for a tested, staged rollout of a change so it is proven before it reaches a live site. Applied to a monitoring logic application, a change is checked automatically against a suite of tests — and, where it matters, against a simulation or hardware-in-the-loop rig that behaves like the real asset — before it is allowed to ship. It is then released to a small canary group of sites first, watched, and only rolled out to the rest of the fleet once it is behaving, with an automatic rollback if it is not. The point is that a change to how a point machine or a level crossing is monitored is validated the same way every time, instead of relying on one engineer remembering to test it by hand.
What is configuration as code and how does drift detection help?
Configuration as code means the approved configuration for each device is held as a version-controlled record — a single source of truth with a full history of who changed what and when — rather than living in someone's head and a spreadsheet. Drift detection, sometimes called desired-state reconciliation or GitOps, is the platform continuously comparing what is actually running on each device against that approved record and flagging any difference. So if a setting was changed by hand during a callout and never written back, or a device came back from repair on an old configuration, the platform sees the drift and can correct it or raise it. Across a fleet of hundreds of sites this is the difference between knowing every asset matches its approved build and hoping it does.
Can automation safely fix faults on its own?
For a defined set of non-vital, recoverable conditions, yes. A self-healing runbook is an agreed, automated response to a known fault — restarting a hung monitoring process, failing over to a standby link, or resetting a stuck non-vital asset — that runs as soon as the condition is detected, including outside working hours, without waiting for a callout. The safeguard is that automated remediation is bounded: it is only applied to conditions where the safe response is known and validated, every attempt is logged, and if the automatic action does not clear the fault it escalates to a person rather than retrying indefinitely. It handles the routine recovery so staff are engaged only for the faults that genuinely require their judgement.
Why does automation need an API-first platform?
Automation is only possible if every action the platform can take is available to be scripted, not just clicked in a screen — and that is what API-first means: a well-documented, versioned interface (typically REST or gRPC) over every operation, event streams and webhooks so the platform can push a notification the moment something happens instead of being polled, and a command-line tool or SDK so the whole system is scriptable end to end. Two properties make this safe over a trackside link: operations should be idempotent, meaning a command is safe to send again if the mobile connection drops mid-request without causing a duplicate action, and events should be pushed so integrations react to change rather than constantly asking. Without an open API underneath, automation has nothing to call.
How is machine-to-machine access secured when there is no human logging in?
Automated actions are one service or device authenticating to another with no person present, so the credentials must be strong and never shared static passwords. Devices carry their own identity under a per-device PKI — a unique certificate each — and connect over mutual TLS (mTLS), where both ends verify each other's certificate. Service-to-service calls use short-lived tokens issued through the OAuth 2.0 client-credentials grant rather than a long-lived key. Every automated action runs under fine-grained, least-privilege authorisation — role-based access with scoped, expiring tokens so a component can do only what it needs — and every action is written to an audit trail recording who or what invoked it, when, and what changed. This is the role-based, least-privilege posture IEC 62443 sets out for industrial systems.
Does automation apply to the vital signalling system?
No. Automation lives in the non-vital, advisory and monitoring layer. It provisions devices, ships monitoring logic, reconciles configuration, and restarts non-vital processes — but changes to safety-critical signalling still follow the applicable assurance and change-control process under the EN 5012x (RAMS) lifecycle, including EN 50128 for software. Automation removes the manual toil around the vital system; it does not remove the assurance. The value is that the routine, repetitive work across the fleet is handled automatically while the safety case, the vital/non-vital separation, and the formal change control over the interlocking are all left exactly where they belong.
What should fleet automation look like for wayside assets?
RailNet Operations is being shaped around ideas like these — devices that provision themselves on power-up, logic and firmware changes rolled out in tested stages with automatic rollback, the approved configuration held as a record and reconciled against what is actually running, and routine faults handled by bounded self-healing runbooks that escalate when they cannot — all on an API-first platform, secured to an industrial standard. If you run monitoring across a large trackside estate, we would like to hear where the manual steps cost you most. Interested in helping explore what a platform like this could do?
Start a conversation