Choosing a Tunnel Automation Supplier: Integration and Commissioning Checks

Choosing a tunnel automation supplier means looking beyond control-system features to verify how reliably the solution will integrate with your equipment and perform underground. A convincing demonstration tells procurement teams relatively little about what happens when a machine controller rejects a command, a communications link drops, or an overnight software update changes an interface.

Those are the moments when unclear responsibilities become expensive. The equipment manufacturer may blame the network integrator; the integrator may point to undocumented PLC logic. Meanwhile, excavation stops, commissioning crews remain on site, and the buyer pays for uncertainty.

The strongest purchasing decision therefore rests on evidence: defined interfaces, realistic tests, measurable acceptance criteria, and a clear route from factory demonstration to underground handover.

Define what the supplier is actually being asked to control

“Tunnel automation” can describe very different scopes. A package might provide monitoring and reporting, supervisory control of auxiliary systems, TBM process optimization, or remote operation of underground mobile equipment. These are not interchangeable purchases, and their safety, connectivity, and commissioning requirements differ substantially.

Before comparing bids, divide the project into control domains. For a mechanized tunnelling project, these might include the TBM, conveyors, ventilation, pumping, power distribution, guidance, and surface control room. A mining development may also involve drilling jumbos, battery-electric LHD loaders, traffic management, and charging infrastructure.

For every domain, identify whether the supplier will monitor, recommend, command, or execute a safety-related function. An analytics platform that recommends operating adjustments should not be evaluated as though it directly controls machine motion.

Require a responsibility matrix covering the owner, automation supplier, equipment OEM, electrical contractor, and communications provider. It should name who supplies interface documentation, modifies existing software, approves control changes, witnesses testing, and resolves faults crossing organizational boundaries. Assign one accountable lead for end-to-end integration rather than leaving coordination to the buyer by default.

Make interface compatibility a documented commitment

A proposal stating “compatible with standard PLC and SCADA systems” is not enough. Compatibility depends on controller models, firmware, software versions, available communication modules, access permissions, and the behavior of individual signals.

Ask the tunnel automation supplier for a preliminary interface control document during tender clarification. It need not contain every final tag, but it should demonstrate that the supplier understands the installed equipment and the work required to connect it.

Protocol support alone does not establish interoperability. Two systems may both support OPC UA or Modbus TCP while using different units, quality indicators, naming conventions, or command sequences. A pressure value without an agreed unit—or a stale value displayed as live—can undermine otherwise sound control decisions.

Request an interface register with an owner and closure date for each unresolved point. Price outstanding integration work explicitly, including OEM attendance and access to protected controller code.

Underground connectivity: evaluate failure, not just coverage

A surface demonstration rarely reproduces an advancing tunnel. Equipment moves, services extend, radio paths change, and cables face mechanical damage, water, dust, and maintenance activity. Network design must reflect that changing environment.

Instead of accepting a generic coverage promise, ask for an application-specific communications budget. Remote machine operation, alarm delivery, historian uploads, and video streams have different requirements for latency, jitter, packet loss, and bandwidth. The supplier should explain which functions remain local and which depend on a continuous connection.

For wireless systems, require a survey and validation plan covering representative machine positions and operating conditions. For fibre or wired networks, check extension arrangements, protected routing, switch locations, power backup, and recovery after cable damage. Redundant links offer limited protection if they share the same vulnerable route or power supply.

Most importantly, define what happens when communications degrade. Does the machine continue under local control, transition to a controlled stop, or inhibit selected functions? The correct response depends on the equipment and hazard assessment. It should not be improvised during commissioning.

Ask the tunnel automation supplier to demonstrate safe state transitions

“Fail-safe” is not a complete specification. A safe response for one subsystem may create problems elsewhere: stopping a conveyor, pump, or ventilation function without considering the wider operating condition can introduce additional hazards.

Require a cause-and-effect matrix showing responses to communication loss, sensor failure, power interruption, conflicting commands, emergency stops, and controller restart. For remote or autonomous equipment, include loss of localization and interactions with personnel exclusion or access-control arrangements where applicable.

The supplier should distinguish ordinary automation from safety-related controls. Identify which functions require a safety integrity or performance level assessment, which party performs it, and which standards apply under the project’s jurisdiction. References to IEC 61508, IEC 62061, or ISO 13849 should identify their relevance to the actual system—not serve as blanket assurances.

Recovery deserves as much attention as stopping. Verify whether communications restoration permits automatic resumption, requires operator acknowledgement, or demands local inspection. Test the transition between local, remote, manual, and automatic modes, including who has command authority at each stage.

Use factory acceptance testing to expose integration gaps early

Factory acceptance testing (FAT) is valuable when it challenges the delivered configuration. A polished demonstration using simplified data and ideal connectivity offers little protection against site delays.

Agree the FAT procedure before contract award, then refine it as the design develops. It should identify the hardware and software baseline, simulated interfaces, actual interfaces, expected outcomes, and evidence required for each test. Where OEM controllers cannot attend the factory test, document the limitations and schedule the missing verification.

A useful FAT includes:

• Signal verification: scaling, units, quality flags, timestamps, alarm thresholds, and missing-data behavior.
• Command sequences: permissions, permissives, acknowledgements, rejected requests, and timeouts.
• Fault injection: link interruption, unavailable sensors, controller restart, and loss of supporting services.
• Operational loading: representative tag volumes, alarm bursts, historian traffic, and simultaneous operator sessions.
• Recovery: backup restoration, configuration recovery, event reconciliation, and controlled restart.

Record results against individual requirements, not simply “pass” against a broad system description. Classify defects by severity and define which prevent shipment, which permit conditional release, and who pays for retesting. An unresolved factory issue should arrive on site with a named owner and agreed remedy—not disappear into meeting minutes.

Write site acceptance criteria before mobilization

Site acceptance testing (SAT) should establish that the integrated system works in its intended environment. It is not merely a repeat of FAT after installation, nor should it depend on the vague condition that “the customer is satisfied.”

Separate installation checks, functional acceptance, safety validation, and an operational reliability demonstration. This makes failures easier to diagnose and avoids using production trials to discover basic wiring or configuration errors.

Each acceptance criterion needs a test method, operating conditions, evidence source, and responsible witness. Depending on scope, measurable items could include command acknowledgement time, alarm delivery, historian completeness, recovery time, or positioning performance. Set limits from operational requirements and risk assessment rather than borrowing generic thresholds.

Define availability carefully. State the observation period, planned maintenance treatment, attributable downtime, and exclusions. Without those definitions, an availability figure can conceal repeated resets or shift responsibility for integration failures onto other contractors.

Also agree the prerequisites: stable power, network readiness, OEM support, access to equipment, approved operating procedures, and trained personnel. Procurement should establish how delays are documented and how standby charges are approved when those prerequisites are not met.

Protect operational data and long-term maintainability

A system can pass commissioning and still leave the owner dependent on the supplier for routine changes. Evaluate maintainability before technical selection is complete.

Clarify ownership and access rights for raw process data, alarms, configuration files, historian records, and derived analytics. Ask whether exports remain available without an active cloud subscription and whether timestamps, units, and quality metadata survive extraction. A downloadable report is not equivalent to usable operational data.

Cybersecurity requirements should cover network segmentation, role-based access, controlled remote support, audit logs, credential management, and vulnerability handling. IEC 62443 can provide a useful framework, but any compliance claim should specify the product, system, or development process covered.

Contractually address backups, software licences, supported versions, patch validation, rollback procedures, and end-of-support notice. Where source code cannot be transferred, consider appropriate escrow or continuity arrangements. The practical question is straightforward: can the owner restore and maintain the installation if the original commissioning engineer is unavailable?

Compare evaluated cost, not the automation package price

The lowest equipment-and-software quote may exclude the work most likely to disrupt the schedule. Normalize bids against the same scope and assumptions before making a commercial comparison.

Build the evaluated cost from five components:

1. Initial supply: controllers, servers, operator stations, gateways, licences, and engineering.
2. Integration: OEM modifications, interface development, network upgrades, and third-party attendance.
3. Commissioning: travel, shifts, underground access, testing, retesting, and standby arrangements.
4. Lifecycle support: subscriptions, cybersecurity maintenance, spares, training, and version upgrades.
5. Change and exit: additional tags, equipment expansion, data migration, and replacement of unsupported components.

Keep uncertainty visible. If an interface remains unverified, request a priced allowance, unit rates, and a change-control mechanism rather than treating the exposure as zero. Where possible, link milestone payments to accepted design documents, FAT evidence, SAT completion, and delivery of the handover package.

Compare supplier experience by relevant conditions, not project count alone. Experience with a fixed pumping station does not automatically establish competence in TBM integration or remotely operated LHDs. Ask for references involving comparable equipment, communications constraints, and commissioning responsibilities.

The award decision should survive the first difficult shift

Before selecting a tunnel automation supplier, procurement should be able to answer four questions confidently: who owns every critical interface, what happens when the system loses information or control, how acceptance will be demonstrated, and what the owner can maintain independently after handover.

A credible bidder will identify assumptions and limits rather than hide them. That transparency may make a proposal look less effortless, but it gives the buyer something far more useful: a contract that can be managed when underground conditions stop matching the demonstration.

Choose the supplier whose integration obligations, test evidence, and support arrangements remain clear under pressure. That is a stronger basis for controlling cost than either a long feature list or a low initial price.