Keeping the field in step with the control room: PLC synchronisation and SCADA integration in tunnels
Many tunnel tenders open their SCADA system integration requirements the same way: which protocols does the platform support? The supplier answers with a list, the requirement is marked compliant, and lifecycle consistency often goes unspecified.
That question covers day one. It says little about year seven, after three ventilation studies and two response case revisions have passed through the configuration.
Where the approved configuration actually lives
The approved configuration and the deployed controller state sit in different parts of the architecture. The central tunnel management system may hold response case mappings, operating parameters, version records and device inventory. Field PLCs execute the device-level logic, interlocks and local sequences deployed to them.
These representations can differ in form, provided both trace back to the same approved baseline. Maintaining that traceability over a twenty-year asset life is harder than connecting the systems in the first place.
Why tunnel monitoring can miss silent divergence
An unreachable PLC announces itself: communication alarms fire and someone gets called out. A controller running a superseded configuration stays quiet. Conventional tunnel monitoring may show it online and responsive without confirming that it runs the approved program and parameter versions.
The gap may surface only during an incident, when there is little time to diagnose a configuration mismatch. Take a CO threshold revised after a ventilation study: approved, recorded centrally, still running at the old value in the field. Or a response case rewritten after a near-miss review, where the editor shows the corrected pattern while the tunnel executes an eighteen-month-old version. Both can pass a review limited to the central configuration, because the central record itself is correct.
Manual deployment is hard to govern
Parameters, response cases, inventory entries and interlock rules change at their own rate, through different approval routes. On the M85 Vienna-Holstein Tunnel Complex in Hungary, the configuration we deployed covers 122 defined operating states, and each one has to match what the field executes. A change signed off in March waits for the next night closure, and two more queue behind it.
In a weakly controlled deployment process, the same person may prepare, deploy and confirm the change, working from memory of what was in the batch. That removes the independent check and makes incomplete deployments hard to detect.
Scheduled verification and controlled reconciliation
The safer principle is to stop treating configuration verification as a commissioning task. The platform checks the deployed controller state against the approved baseline on a defined schedule, with on-demand checks after maintenance, controller replacement or configuration changes. Where the operating concept and risk assessment allow it, approved configuration can also be re-synchronised on a defined schedule, nightly in some deployments.
A scheduled check compares program versions, parameter sets, checksums and configuration package identifiers. Where it finds a difference, the platform creates a reconciliation record naming the controller, the versions found and the difference, then routes the required deployment through the approved change and authorisation process. A failed deployment stays visible until resolved, and the workflow records whether the change should be retried, revised or withdrawn. After a controller replacement, the same check identifies the departure from baseline. The approved restoration workflow then ensures that the authorised package is loaded and verified before the controller returns to service.
Two requirements make this defensible. Any deployment that changes controller logic needs a defined operating state, an approved transition procedure and a verified rollback path; a low-traffic window reduces operational impact without replacing those controls. Only approved packages should be eligible for deployment, with role-based authorisation, authenticated communication and a record of who authorised the change, which version went out and whether verification succeeded.
What SCADA system integration has to expose
Open, documented interfaces matter because the operator needs an independent way to verify the deployed state. The evidence usually includes program versions, parameter set identifiers, checksums, firmware versions, deployment timestamps and device acknowledgements.
Protocols such as OPC UA, Modbus, IEC 61850, BACnet and NTCIP may provide parts of that visibility, depending on the subsystem, the region and the vendor implementation. Protocol support alone guarantees none of it, so specify which version and configuration data has to be readable, and how it will be compared.
Where a subsystem exposes only a proprietary interface, verification becomes something the supplier performs and reports on. That may be perfectly reliable. It also leaves the operator unable to verify independently whether the field matches the centre, a poor position for the organisation carrying the safety obligation.
The integration question worth asking
Protocol coverage answers a day-one question. Whether the field and the control room still agree in year seven depends on verification, and that belongs in the tender rather than in commissioning.
Lillyneir integrates tunnel supervisory and control systems for motorway operators and road authorities, with experience across SCADA platforms, control protocols and multi-vendor subsystem environments. Our TM-Hub platform verifies the deployed PLC state against the approved configuration on a defined schedule and on demand, synchronising approved packages through the configured authorisation workflow, with reconciliation reporting for the operator. TM-Hub supports live operation at the مجمع أنفاق M85 (فيينا - هولشتاين) in Hungary, commissioned in December 2024. To discuss integration and verification on your tunnel, contact our team.
