A stopped vehicle becomes a fire.

The tunnel operation, modelled as what it does rather than what it is built from. At its boundary it controls lane use and speed, keeps the atmosphere breathable and the escape route clear, admits or diverts vehicles at the portal, and manages incidents.

Incident management runs as a lifecycle: an alert is raised, assessed, and either promoted to an incident or stood down; a response is determined; requests go out to the field systems, signs, lane signals, ventilation, public address, patrols; the response is monitored; and the incident is resolved when the alert is no longer reported. Traffic incidents are typed, a vehicle stopped in a live lane being one of twelve, and each type carries its own response set. Fire is treated as an enclosure incident with an automatic response, because the time lost waiting for an operator is itself a hazard.

Two decisions taken in the model matter for what follows. Traffic incidents are operator-initiated; enclosure incidents are not. And a stopped vehicle is resolved when it is no longer detected, not when a patrol removes it, because a vehicle can simply drive on.

A vehicle stops in a live lane. On its own that is a traffic incident. In the context the tunnel is deployed into, it is the first link in a chain.

• Following traffic arrives at motorway speed with nowhere to go. A collision behind the stopped vehicle is the first outcome, and the more likely one.
• The occupants leave the vehicle and are now pedestrians in a live lane.
• The vehicle, or the collision, produces a fire. In the open this is a vehicle fire; in an enclosure it is a smoke event that fills the space people must escape through.

What decides which outcome the operation reaches is the state of its own outputs at the time: whether the lane behind the vehicle has been closed and speed reduced, whether the ventilation is pushing smoke away from the queue or into it, whether an evacuation instruction has reached the people in the tunnel, and how long each of those took. Traffic density and the delay before the stopped vehicle is noticed set the severity. The same stop at three in the morning and in the evening peak are different scenarios.

Each of these is written down as a scenario with a stated scope, so a reviewer can see what was considered and what was deliberately left out.

What the tunnel as a whole must do about the chain, stated as operational needs before any decision about which system provides them.

• Notice the stopped vehicle quickly enough that the lane can be closed before the queue forms.
• Close the lane, slow the approaching traffic, and get a patrol to the vehicle.
• If there is fire, confirm it and locate it. Smoke alone is weak evidence in a tunnel: diesel exhaust, dust and the airflow that smears smoke along the bore all confound it. Heat, flame or a manual call point confirm directly; smoke alone sends the operator to the cameras.
• Scale the response to the confidence in the evidence. Close on weak evidence; suppress only on a confirmed and located fire, because deluge on the wrong zone does harm of its own.
• Protect people first: drive the ventilation to keep the escape route clear, tell people what to do on every channel they can receive, and bring the emergency services.
• Do not let the response wait on the operator. If a fire alert is not acknowledged within a defined period, the automatic response starts, with the period set so the Austroads response targets are met.

Each of these carries the risk reduction it is expected to deliver, which is what turns it from a good intention into something that can later be specified and verified.

Now the other direction. The systems that deliver those mitigations are modelled as components performing functions, exchanging information over links, and the analysis asks how each mitigation can fail to arrive. This is where the model earns its keep, because the failure paths are traced through it rather than listed from memory.

• Video-based incident detection misses the stopped vehicle in dense traffic, or the camera covering that lane is the one that has failed.
• The operator is handling something else and the fire alert sits unacknowledged.
• The supervisory controller that orchestrates ventilation, closure, advisories and displays fails, and takes all of them with it.
• Low-voltage power is lost, and sensors, actuators and the operator's console go together.
• One video path serves incident detection, fire verification and the operator's view of the tunnel. A single failure removes all three at once.
• Fire detection relies on one technology, so one confound can both raise and confirm a fire, or suppress both.
• Deluge is released onto the wrong zone.

A finding from the case study. The model showed that the evacuation instruction, correctly determined by the fire response, had no path to the public address system. The need was stated; the item never reached the component that would voice it. Nothing in the equipment list would have shown that. Tracing the information did.

The controls that close those failure paths, and the system requirements they become. Each requirement is traceable back to the scenario in stage 02 that it exists for.

• An independent fire panel with its own detectors and its own battery, so fire detection and confirmation survive loss of the supervisory controller and loss of low-voltage power.
• A hardwired manual deluge release at that panel, so suppression remains possible when everything else is down.
• Diverse detection technologies, heat, flame and manual call, so no single failure or confound can both raise and confirm.
• Battery-backed operator console, and a stated list of what still depends on the supervisory controller once these are in place.
• A fire alert acknowledgement timeout, with the period specified against the response targets, and the automatic response that follows it.
• Evacuation messaging to every channel the public can receive, including the public address path the model found missing.
• Resolution of a stopped-vehicle incident defined by the vehicle no longer being detected, so the incident does not stay open after the vehicle has driven on.

None of these is exotic. Several are already in the guides. The difference is that each one arrives with the scenario it answers, the risk reduction it is expected to deliver, and the failure path it closes, so when the design or the operating concept changes, the requirements affected can be found rather than rediscovered.