It’s just an emergency brake application. The train doesn’t know whether this was triggered by the AWS, a break in the door interlock circuit, the driver or some other reason. As such the time-out has nothing to do with the AWS or any other safety system.
I had been given to understand that the time-out was to ensure that the train actually did come to a full stop. Having a time-out also prevents drivers using the emergency brake as just another brake step.
That's not entirely correct. Most units don't have an emergency time out, while some other stock does. The timer and time out in the case of AWS (as queried by the OP) comes from the TPWS interface. It's important to differentiate here. An AWS brake demand will still cause the red "brake demand" light on the unit to flash. The emergency brake application will still be exactly the same as per a TPWS intervention.
Where a time out for a driver initiated emergency brake is provided, this is to provide thinking time and is usually adjustable.
In most cases, units with a time out wont run the timer for anything other than a driver initiated EB, so a break in train wire 4 wont cause a time out. This may differ for a minority of traction.
Do you mean the TPWS timer? Yes this is a separate system from the rest of the train, but the expiry of that timer has no bearing on the train’s own emergency brake time-out. You may still need to wait a while longer before being able to release the brake.
Again, where a time out is fitted.
The 60 second delay on brake release after an emergency brake application was introduced on older stock when across the industry emergency brake rate was increased to 12%g and the fatigue life for the bogies was shortened by the forces involved in the higher brake rate. To avoid emergency brake being used as a normal service brake step, and the bogie fatigue life running out prematurely, the 60 second delay was introduced so that emergency brake use in service would cause a delay and this would be picked up by the existing delay attribution/monitoring systems and the emergency brake use would come to light and the driver would get a talking to.
So, the current mitigation to an EB application is that the brake isn't releasable until the unit stops. This effectively prevents using emergency as a service brake, as unless you have incredibly precise braking points and god-like judgement of the railhead and trains brake performance, you can't use emergency for anything like an accurate stop.
The TPWS interface time out is to prevent the driver failing to notice the brake application has been due to TPWS/AWS.
To explain this in more detail:
When AWS slow to cancel or TPWS overspeeds/Train stop loops activate, the TPWS unit applies brakes to emergency. There is then a 1 minute timer started, before which the brakes will not release. On older, series 1 TPWS interfaces, the driver must also press the AWS cancel button to release the brake. If this is done after the 1 minute time out, the brake will stay applied until whatever point the the button is pressed.
Compare this to any other EB application. If its a sporadic fault, quite often the brake releases as soon as the train comes to a stand - quite different to the above.
Equally, if the reason is a serious fault, pass com etc, the driver will have to establish the reason for the brake application in order rectify it and to get the brake to release. Again, quite different to the specific circumstances around a TPWS brake demand.
The reason for all this is that TPWS is piggybacked on AWS on the older iteration. Therefore, an AWS brake demand routes through the same interface, even though, in itself, it is not an operational incident. A TPWS brake demand, however, is a serious operational incident. Failure to recognise this, or even worse, a willful reset of the system and failure to report, is a serious violation of the H&S at work act, therefore, the system needs to provide a very unique way of signalling to the driver what has happened.
