What happens after the operator confirms: execution feedback in a tunnel management system
A tunnel response matrix defines what should happen. Each response case maps a specific incident scenario and traffic regime to the intended states of the tunnel’s controllable devices. Part one of this article covered how those cases are structured, why the matrix we engineered for the M85维也纳-霍尔斯坦隧道综合体 in Hungary runs to 122 defined operating states, and why the configuration should show real sign faces rather than device codes.
That work produces a reviewed statement of intent. It does not tell an operator what the tunnel has actually done with it. Between the first alarm and a confirmed field state sit detection, verification, selection and activation. The last is the least discussed during procurement.
Tunnel monitoring is fast, verification comes next
Detection is rarely the constraint now. Continuous real time monitoring across HD video, environmental sensors and traffic counting gives the control room a working picture, and automatic incident detection flags stopped vehicles, wrong-way traffic and pedestrians within seconds.
Position matters as much as presence. On the Hungarian M85 tunnel complex we built the monitoring around the physical layout, tube by tube and section by section, so the display shows which devices an event actually concerns. A stopped vehicle in section 4 and the same vehicle in section 9 lead to different cases.
The next step is verification. The control room has to confirm what happened, where, and which operating regime is active before a significant traffic or ventilation response begins. Automatic detection produces an alarm or an event candidate, and treating that candidate as a confirmed incident without a check is its own category of risk.
Once verification is complete, the remaining delay comes from the control workflow. The information is available, and the operator may still have to issue individual device commands. Time saved during detection is lost during execution.
Where live data fits
The obvious objection to a pre-engineered matrix is that conditions vary and a fixed table cannot cope. Variable conditions do not require operators to build a response from scratch. They determine which approved case applies. Fog, ice risk and heavy rain on the approach change which speed limit case applies and how far upstream the reduction begins. Traffic volume at the time shapes which junctions to close and whether diversion routes need activating.
Vehicle identification works the same way. LiDAR and video analytics distinguish vehicle classes and locate a stopped vehicle. Identifying a hazardous-goods vehicle needs a further source, such as recognition of an ADR orange plate and its identification numbers, or authorised routing records. Where that data is reliable, the platform can narrow the selection to a more specific case.
Write the division of labour down rather than leaving it implicit. Live data narrows the available cases and supplies the parameters for selection. Depending on the approved operating concept, the platform may recommend a case or activate defined low-risk actions automatically. Safety-critical changes stay subject to the configured confirmation and authorisation workflow. Determinism here is a property of the configuration: it describes the mapping between case and intended device states, and makes no claim about the field. Dynamic inputs, deterministic outputs.
What a tunnel management system does after activation
A response case is complete only when the platform also manages execution feedback, which means separating the command issued, the acknowledgement returned and, where the device exposes it, an independently verified field state. An acknowledgement can show that a subsystem received the command without showing that a barrier moved or a sign reached the requested aspect. The matrix defines the intended state. Device feedback shows which commands were acknowledged and which states the connected systems reported as active.
This separates a working implementation from a convincing demonstration. A sign that does not take up the commanded aspect, a PLC that becomes unreachable mid-sequence, a partial activation that leaves the tunnel in a state nobody designed: each is a credible failure mode over a long asset life, and each requires predefined behaviour.
Deviation handling is where the design decisions concentrate. Which mismatches raise an alarm and which enter a degraded-mode procedure. What the operator sees when a barrier has acknowledged the command and its end-position sensor has not reported the movement. Whether the sequence continues, pauses or rolls back. Answer those three during design, because an operator will not answer them well at 03:00.
What the log has to contain
The record shows that case 27 was activated at 03:14:22 by an identified operator. Alongside it, the log holds the commands issued, the acknowledgements from each subsystem and any deviation between the intended state and what the field reported. Three separate facts, kept separate: which case was chosen, what the system commanded, and what the equipment reported back.
Improvised responses leave a less structured trace. The log may hold every command, and investigators still have to reconstruct the intended state and compare it with the feedback available at the time.
Where the effort belongs
Incident reviews often focus first on operator performance. Training and procedures matter, though neither compensates for a control architecture that requires dozens of manual decisions during a time-critical event.
A mature tunnel management system moves that burden forward in time. Engineers define the cases, the tunnel safety officer and emergency-service representatives review them, and the project team validates execution under normal and degraded conditions. In live operation the operator verifies the situation, selects or approves a case, and watches what the field reports back.
The result is consistency across shifts and experience levels. A less experienced operator works within the same reviewed cases, authorisation rules and degraded-mode procedures as the most experienced person on the roster. Operational judgement stays with the operator, exercised inside a framework reviewed in advance and verifiable afterwards.
Lillyneir builds and integrates tunnel supervisory and control systems for motorway operators and road authorities. TM-Hub brings fourteen subsystem categories into one operational environment, with pre-engineered response cases configured through a real-sign-face editor and execution feedback from the field. It supports live operation at the M85 Vienna-Holstein Tunnel Complex in Hungary, commissioned in December 2024. To discuss how this would apply to your tunnel, contact our team.
