Further to the discussion (which I now can't reply to from Google) at
http://groups.google.co.uk/group/uk....2fcc64dc?hl=en

there is now a RAIB report at http://www.raib.gov.uk/cms_resources...d%20Bridge.pdf.

Haven't read it properly yet.

On 22 June, 13:46, MIG wrote:
Further to the discussion (which I now can't reply to from Google) athttp://groups.google.co.uk/group/uk.transport.london/msg/6d492b8d2fcc...

there is now a RAIB report athttp://www.raib.gov.uk/cms_resources/090622_R162009_Deptford%20Bridge....

Haven't read it properly yet.

I was most surprised to see the train that derailed was also exceeding
a temporary speed restriction at the time. Here's the wonderful Daily
WTFesque story of how this could happen:

"If the speed restriction is required to become more permanent, then
the data is added to an ‘Operational Restrictions List’, [...] a
document stored on a computer and is managed and controlled by a Serco
Docklands systems engineer. He collates the speed restriction data
(as well as other operational restrictions) and enters the data onto
the list."

"[..,] when a change to the operational restrictions list was made, a
paper copy was brought to the control centre and attached to a notice
board at
the side of the room. This was the only copy that existed in the
control room.

"When a re-boot happened, all the data from the operational
restrictions list had to be re-input manually by the control centre
controller. Re- boots were scheduled on a weekly basis for all three
vehicle control computers, and following any software upgrade or work
on the system.

"The entry of the data into the vehicle control computer systems was
usually via a keyboard/mouse interface. It was not easy to check the
data that had been
entered. The capture of the data on the vehicle control computer
monitor screens was difficult; the operational restrictions list data
was shown over many lines and pages of text and was extremely
difficult to extract and check.

"Operational restrictions list data that was being entered by the
control centre controller was not being checked, either by the control
centre controller or by a supervisor in the control centre."

"The majority of re-boots (and hence the re-input of operational
restrictions list data) happened between 03:00 hrs and 04:30 hrs.
This was at one of the busiest times for the control centre
controller. As well as re-entering and checking the operational
restrictions list data, the control centre controller also had to give
instructions to all passenger service agents that were coming on duty
to undertake sweeps, liaise with the depot controller on trains that
were being moved around the system from depots and generally co-
ordinate the railway operations at the start of the morning passenger
service."

--

And that's just one of many borked procedures this incident brought to
light (see paragraphs 214 onwards for a list). I've never seen an RAIB
report that paints an entire company in such a bad light.

U

On 22 June, 22:12, Paul Corfield wrote:
On Mon, 22 Jun 2009 13:38:39 -0700 (PDT), Mr Thant

wrote:
And that's just one of many borked procedures this incident brought to
light (see paragraphs 214 onwards for a list). I've never seen an RAIB
report that paints an entire company in such a bad light.

The issue for me is that it isn't really one company involved. There are
many different parties and while not entirely unusual in the rail
industry it does highlight that risks exist at interfaces - asset,
company, organisational. system.

I recognise Serco are the main party here and I wonder just how much
this has cost them financially and reputationally.
--
Paul C

Could the recent reported problems about trains not stopping in the
right places after infrastructure changes also be related to something
that initially had to be reentered after every reboot?

On Mon, 22 Jun 2009 13:38:39 -0700 (PDT)
Mr Thant wrote:


On 22 June, 13:46, MIG wrote:
Further to the discussion (which I now can't reply to from Google) athttp=
://groups.google.co.uk/group/uk.transport.london/msg/6d492b8d2fcc...

there is now a RAIB report athttp://www.raib.gov.uk/cms_resources/090622_=
R162009_Deptford%20Bridge....

Haven't read it properly yet.

I was most surprised to see the train that derailed was also exceeding
a temporary speed restriction at the time. Here's the wonderful Daily

It worries me a bit that the computer didn't spot the derailment and
happily carried on. Would it not be possible for it to check for signalling
current (or similar) flowing through every axle and if this current stops
on 1 axle but not the others then its a fair bet its become derailed?

B2003

wrote in :

It worries me a bit that the computer didn't spot the derailment and
happily carried on. Would it not be possible for it to check for
signalling current (or similar) flowing through every axle and if this
current stops on 1 axle but not the others then its a fair bet its
become derailed?

Possible, yes, but perhaps not cost-effective. Derailment detection
systems have often been proposed, but I'm not aware of many that have been
implemented. Your solution would give the occasional false alarm (eg on
rusty rails) which *might* be as dangerous as the very occasional
derailment.

On the whole, humans are much better and often faster at detecting
'something's not quite right' than technology, though that's not a reason
to be complacent.

IMHO, the number of failings uncovered by the report is appalling, and no
amount of technology will compensate for such widespread disregard of rules
and good practice.

Peter

--
Peter Campbell Smith ~ London ~ pjcs00 (a) gmail.com

On Tue, 23 Jun 2009 11:26:38 +0000 (UTC)
Peter Campbell Smith wrote:
implemented. Your solution would give the occasional false alarm (eg on
rusty rails) which *might* be as dangerous as the very occasional
derailment.

True.


On the whole, humans are much better and often faster at detecting
'something's not quite right' than technology, though that's not a reason
to be complacent.

What happens if theres no human in charge though? I'm thinking of various
completely automated systems such as Line 14 in Paris & various VAL systems
around France. Could a derailment (or whatever you call it on rubber tyred
systems) happen on them without power being lost? If the DLR was run in the
same way and no one in charge was on board we'd probably be looking at a
very nasty accident.

B2003

On Tue, 23 Jun 2009 11:26:38 +0000 (UTC)
Peter Campbell Smith wrote:

On the whole, humans are much better and often faster at detecting
'something's not quite right' than technology, though that's not a
reason to be complacent.

wrote in :

What happens if theres no human in charge though? I'm thinking of
various completely automated systems such as Line 14 in Paris &
various VAL systems around France. Could a derailment (or whatever you
call it on rubber tyred systems) happen on them without power being
lost? If the DLR was run in the same way and no one in charge was on
board we'd probably be looking at a very nasty accident.

Completely unstaffed systems are no doubt subjected to a risk assessment
and the risk, in the context of any mitigation measures, is judged
acceptable. Staff are expensive, so if you do away with them you may still
be able to spend quite a bit on accident prevention or mitigation to
achieve an equivalent safety case, and still come in at a lower cost. I
would imagine, though I don't know for sure, that unstaffed trains would
have passenger panic buttons, for example.

I can't think of any derailment on a driverless line that had serious
consequences, but of course nothing is 100% safe.

Peter

--
Peter Campbell Smith ~ London ~ pjcs00 (a) gmail.com

What happens if theres no human in charge though? I'm thinking of various
completely automated systems such as Line 14 in Paris & various VAL systems
around France. Could a derailment (or whatever you call it on rubber tyred
systems) happen on them without power being lost? If the DLR was run in the
same way and no one in charge was on board we'd probably be looking at a
very nasty accident.

To be fair the report implies that if the operator on the train was
indeed responsible for the emergency brakes being applied (and they
can't be 100% certain because - wait for it - the CCTV on the train
wasn't working), then he likely only beat a number of automated trips
by a second or two.

Of course, the report also points out that risk of a derailment in
which the train DIDN'T stop automatically, twisted and collided with
either an oncoming train or station infrasture had ALREADY been
assessed as the train-related incident with highest risk several years
back and that despite making concerned noises Serco and co. have still
done bugger all about it.