Re: y2k

[matthew@mail.usyd.edu.au (Matthew Geier)]

In article <36B6C245.48F13975@bigfoot.com>,
Notagunzel  <notagunzel@bigfoot.com> wrote:
>Roderick Smith wrote:
>
>> This hasn't had a nibble in m.t.r.m, so I am trying it more widely,
>> starting with my own territory.
>>
>> My students are working on an international challenge which seems to be
>> written by a Hollywood filmmaker:
>> Describe a railway crash in Japan caused by a y2k problem.
>>
>> AFAIK, virtually all railway safeworking is protected by hardware, which
>> fails safe.  Computers are used for *control*, not safety protection.  The
>> worst problem which y2k could cause is gridlock: everything halts.
>
>critical functions are unaffected.  About the most susceptible safety critical
>system I can suggest is the Section Authority Working Workstations.  I have
>seen zilch about their y2k compliance.  Anybody heard anything?
>
 But the SAW workstation is likely to crash and not be usable for issuing
orders. It would be highly unlikely that the operator would notice nothing
wrong and then issue conflicting orders accidently.

 As it has been pointed out, there are very few software interlockings and
a locking plant needs no idea of 'real time' only relative time.
 Yes the supervisory workstations could go haywire and attempt to clear
conflicting movements, but the interlocks in the field will prevent the trains
from ever seeing it.

 The worst senario on the ground is gridlock. The failure if any will be human,
if the supervisory computers go down and 'lock up' the field systems, a human
might issue 'pass signal at stop' orders in error and cause an accident, but 
it wont be a machine error as such.