[SystemSafety] Interesting new publication about safety for autonomous vehicles

[paul_e.bennett at topmail.co.uk]

On 11/07/2019 at 10:29 AM, "Olwen Morgan" <olwen at phaedsys.com> wrote:
>
>And another thing ...
>
>London Underground signalling was always safer that BR signalling 
>because of the use of interlocking machines. These are units 
>containing 
>a set of vertical bars and a set of horizontal bars. Notches in 
>the bars 
>ensure that they can only fit together in a finite number of 
>configurations, each of which corresponds to a safe setting of 
>signals 
>and points. It is physically impossible to set the points into a 
>state 
>such that two trains would be on a collision course with each 
>other 
>(except for a separation violation on the same track with trains 
>heading 
>in the same direction).
>
>Gauge violations are possible as, for example, at Barons Court 
>(and a 
>few other stations) where it is technically possible for a large 
>sub-surface train (as on Circle and District lines) to be routed 
>into a 
>tunnel for smaller deeper lines. Again the safety measure is 
>simple and 
>physical. At the entrance to the smaller bore tunnel there is a U-
>tube 
>containing mercury. A big train trying to enter a small tunnel 
>will 
>break the U-tube, cause the mercury to be release and thereby 
>break a 
>circuit causing the traction current to be shut off.
>
>The interlocking machines are prone to wear and all the switching 
>is in 
>relays which are prone to spark erosion. On the other hand, a 
>direct 
>software simulation of the interlocking states has always seemed 
>to me 
>to offer the best route to attain a fundamentally correct point-
>setting 
>algorithm.
>
>regards,
>
>Olwen

Olwen's comments about the physical interlocking measures in some
systems, are a valid argument regarding autonomus vehicles. Easier
to implement than pure software measures on a single processor.

The Nuclear Robotics System that I designed the software foi handled
irradiated nuclear fuel in preparation for its recycling at Sellafied. We
used mechanical 'Shotbolts' in conjunction with various physical limit
switches as a positional proving method to guarantee that the machine
was in an expected state before the next sequence of operations could
be begun. We also used a number of semaphoeres to ensure that we
were in the expected software routine.

With the tracks as a guidance, the issue of other vehicles approaching
from unexpected directions are minimised. There is no such provision
on the roads, and the sensors deployed rely on clever electronics, or
software systems to determine such occurences.

Additionally, in rail based systems, you do not have too much incidence
of persons on the track (although I know it does happen from time to time).

Hence, my earlier remark about needing a much more indepth knowledge
of the sensor integrity during operation.

Could we do software interlocking such that when implemented would test
out as robust as if we had done it mechanically? It is a tall ask I think, but
one where this community should aspire to be able to achieve. 

Regards

Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
-- 
********************************************************************
Paul E. Bennett IEng MIET.....
Forth based HIDECS Consultancy.............
Mob: +44 (0)7811-639972
Tel: Due to relocation - new number TBA. Please use Mobile.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************