Re: [SystemSafety] Digest, Vol 25, Issue 12: IMPORTANT RESPONSE REQ <5day

From: Simon Whiteley < >
Date: Wed, 27 Aug 2014 21:08:12 +0100


Dear Martin, Friends and Colleagues,

I hope this email finds you all well.    

Martin, thank you for the notification of the opportunity to respond to the IET / Government invitation.  

I think the subject of Autonomous Vehicles and their Safety in the public domain is frightfully important and I would have jumped at the chance to contribute. However, and I'm sure it's the same for many others on this list, I don't have the time (currently) to dedicate to this worthy cause at such short notice, though I am very interested in getting involved and providing support where I can.  

I have made the following points for consideration and discussion by the members of this list (be gentle you lot! :-) ), and will also forward relevant ones to IET and others, as time allows.

I've also pointed out STAMP & the Euro STAMP Conference as I know that using STAMP would provide mega benefit to the "Autonomous Vehicles" enigma:    

  1. Definitions

Gov. paperwork apparently confuses terms and does not provide adequate definitions, this must be resolved:

  1. "Driverless" cars--> a car that does not need to be controlled by anyone on-board? Or a car that cannot be controlled by anyone on-board?

The general population may get the wrong impression if this is not firmly defined, and the various Marketing people need to be managed! This also raises questions about "off-board" control, e.g. via a smart phone (cold shiver!).

b. "Advanced Autonomous Safety Systems"--> this term is used seemingly interchangeably as though it refers to a fully autonomous "driverless car" (my definition: a car that does not need, or has no controls for, a human controller / driver). However, my understanding was that this term referred to and is associated with "Driver Assistance Systems" of the type that only assist the driver and are meant to be perceived as "assisting the driver" (whether that "perception" is technically correct or even appropriate is a whole different discussion!), not a system that eliminates the need for a driver (assists the elimination of the driver, that sounds really bad!)

c. "Full Automation" Vs. "High Automation", the only differences in definition are that no human intervention is required, and that the driver need not be "able" and "ready" to take over, which presents some interesting safety requirements beyond just the vehicle in isolation, but its interactions with other vehicles and the surrounding environment, which the review doesn't apparently focus on.

2) "Failures", "Testing" & Software

There is significant focus upon "Failures" and "Testing", which fails (!) to recognise that in a massively complex Road System with Autonomous / Normal Vehicles, "failures" do not have to occur to result in accidents, just interactions.

This is compounded by the fact that Autonomous Vehicles will likely be heavily dependent upon software that "does not fail" and cannot be exhaustively tested. Furthermore, there would be difficulties trying to envisage all potential real world interactions without trying to test them all too!

The focus here definitely needs re-thinking: Systems Thinking, i.e. Nancy Leveson's STAMP & STPA.

3) Compulsory Software Updates

The document suggests compulsory software updates, which opens a significant can of worms, especially in terms of what happens if the car is involved in an accident and hadn't had the software updated and how much the updates could cost and who could provide them.

Also, exactly how software updates are managed requires the utmost care, especially with the perception / reality of tricks certain mobile phone manufacturers are playing with "free" software "updates" and "planned obsolescence".

4) Human Monitoring of a Computer

The concept of a normal-everyday-Human sat monitoring a computer controlled vehicle waiting to detect and arrest a hazardous situation with only inches / milliseconds to respond is unreasonable and frankly dangerous.

I accept that certain members of the community may be perfectly adapted to such a task (i.e. a test pilot) and that this will be part of the "not-exhaustive testing", but Human-monitoring is not something that should be imposed wholesale onto just anyone, whether they themselves realise that this is what is required or not!

Humans are not designed or particularly competent for the monitoring and taking-control-when-the-wheels-fall-off task, and cannot be relied upon for such safety critical functions.

Let me be clear, there should be appropriate and adequate thought and analysis that either places the Human in the loop far enough that they do not get bored or complacent, or that they at least have a chance to arrest things should they go wrong. Let Humans play to their advantages, and not their disadvantages.

5) Vehicle Safety Data Recorders

As part of my Masters Project on the Development of Requirements for Vehicle Safety Data Recorders, I identified some very interesting and specific extra-requirements for Autonomous Vehicles and made associated comments that any Autonomous Vehicle should be fitted with a Data Recorder (akin to an aircraft, though my method identified new requirements beyond what aircraft are currently required to record) for two main reasons:

  1. To provide evidence that the Human Driver was / was not faulty;
  2. To provide evidence that the Autonomous Vehicle was / was not faulty.

Otherwise, without that information a great number of injustices could occur, and Manufacturers / Regulators would not have the necessary feedback Safety information they need to control safety (Nancy Leveson's STAMP Hierarchical Control Structure Requirements).

This is before we tackle the elephant-in-the-room of always blaming Human Error on the part of the involved Pilots / Drivers, which prevents learning about the real causes of accidents and how to control them.

Obviously, privacy, security and data control / ownership were identified as massive cans of worms, which need to be resolved, but not at the expense of safety.  

For real, and immediate benefit, the Review Team could do a STAMP Analysis using STPA to identify the Unsafe Control Actions (Human, Technical (Hardware & Software), Social), derive appropriate Top-Level System Safety Requirements / Safety Constraints, and then feed those back into the Review Activity. This would answer literally all the questions included below (if the Hierarchical Control Structure was developed / detailed enough to answer them, based on available information) and answer others not already considered.

I can foresee literally tens of Unsafe Control Actions, both Human, Machine, Environmental and Regulatory that need to be identified and resolved with adequate and appropriate Safety Constraints, before the review is completed.

It is evident from the language and questions in the various Government documents that the Reviewers haven't foreseen many of the important and concealed / obscure Unsafe Control Actions, which is rather concerning, especially when considering the complexity of the Systems involved and how they compare to what we currently do in Aerospace & Defence!

This type of STPA only needs a small group of people to perform, it can be applied to the technical and regulatory / organisational aspects easily and it could would produce extremely-valuable results, within a matter of hours! And it can be done with limited information and iterated swiftly as further information becomes available.

I can help with this and would be prepared to take part in further discussions with those interested, but would find it a challenge in the urgent time scales mentioned.  

If anyone wants to find out more about STAMP, apart from reading Nancy's book (
629_Engineering_a_Safer_World.pdf> 29_Engineering_a_Safer_World.pdf), please give me a call / drop me an email, or pop along to the Euro #STAMP Conference 2014 in Stuttgart (22-23 September 2014):


I'll be there, if you want to have a chat.  

On a side note, I've recently created a LinkedIN Group that you are welcome to join, where I'm about to publish some interesting STAMP-related articles, of which Autonomous Vehicles & Data Recorders is going to be one such subject: "International STAMP (Systems-Theoretic Accident Modelling and Processes) Interest Group".  

It is my honest view that this is a situation where STAMP would make a MASSIVE difference, very quickly, to the spectre of Autonomous Vehicles and their Safety, which is a matter of significant importance to humanity and economic well-being which must be addressed before we build a massively complex, untestable, monster. And then release it on the public.  

All the very best,


p.s. See you in Stuttgart! :-) or at least in the LinkedIN Group!  

p.p.s Please be aware, I intend to offer a STAMP / STPA Training Workshop in the UK in the very near future and have already had talks with Professor Leveson with regards to her support and attendance in the UK.

If you are interested in knowing more, please let me know or visit my website.    

Kindest Regards,  

Simon P.P. Whiteley BEng (Hons) MSc MRAeS

DIRECTOR   M: +44(0) 7899 754090

E: <mailto:simon_at_xxxxxx



Whiteley Aerospace Safety Engineering & Management Limited Registered Office: Delta 606, Welton Road, Swindon, Wiltshire, England SN5 7XF, UK
Registered in England & Wales No: 6785948

VAT Registration No: 943 9340 07      

-----Original Message-----
From: systemsafety-bounces_at_xxxxxx [mailto:systemsafety-bounces_at_xxxxxx systemsafety-request_at_xxxxxx Sent: 27 August 2014 11:00
To: systemsafety_at_xxxxxx Subject: systemsafety Digest, Vol 25, Issue 12  

Send systemsafety mailing list submissions to


To subscribe or unsubscribe via the World Wide Web, visit  


or, via email, send a message with subject or body 'help' to  

<mailto:systemsafety-request_at_xxxxxx systemsafety-request_at_xxxxxx  

You can reach the person managing the list at


When replying, please edit your Subject line so it is more specific than "Re: Contents of systemsafety digest..."    

Today's Topics:  

  1. Review of the legislative and regulatory framework for

      testing driverless cars (Martin Lloyd)    


Message: 1

Date: Wed, 27 Aug 2014 10:30:56 +0100

From: Martin Lloyd < <mailto:martin.farside_at_xxxxxx martin.farside_at_xxxxxx

To: <mailto:systemsafety_at_xxxxxx systemsafety_at_xxxxxx

Subject: [SystemSafety] Review of the legislative and regulatory

                framework for testing driverless cars

Message-ID: < <mailto:53FDA550.6010102_at_xxxxxx 53FDA550.6010102_at_xxxxxx

Content-Type: text/plain; charset="utf-8"; Format="flowed"  

Dear Colleagues  

The UK IET (Institute of Engineering Technology) is inviting contributions to a submission on this matter, as shown below. It is very disappointing that I only received this notice yesterday. However, despite the lack of time perhaps individual members of this list could make a response. I am particularly exercised by the software implications of driverless cars and the standards that should be applied to them.    

*_Review of the legislative and regulatory framework for testing driverless cars


In the Autumn Statement 2013, the Government announced its plan to review the legislative and regulatory framework for developing and testing driverless cars in the UK, reporting by the end of 2014.  

The Department for Transport is interested in comments on any regulatory or other issues that may need to be addressed in considering the testing of cars with advanced autonomous safety systems on public roads, and the areas where new regulation may be necessary in order to maintain road safety and provide the appropriate safeguards in the introduction of this novel technology.  

The DfT are interested in hearing views on the below questions;  

    of driving experience be specified for drivers involved in testing

    driverless cars with high automation?

    behaviour should still apply or are any exemptions from these

    required, if so please specify?

    that the vehicle is operating autonomously, or capable of autonomous

    operation? For example, a warning signal showing autonomous

    operation or a distinguishing sign (different number plate, sticker

    on windscreen, etc.) indicating the potential capability of

    autonomous operation?

    users about the testing of highly autonomous cars?

    road users, or the risks of interaction with driverless cars, and

    possible mitigation measures?

    regime, when operating driverless cars with high automation?

    testing of prototype cars with high automation?

    prototype cars with high automation might not comply with?

    steering) or any specific systems/technologies (e.g. ABS, ESC) where

    regulation needs to be amended or developed, as a priority ?

    to permit the testing of driverless cars, or ensure their safety?

    issues as driverless cars age, and possible requirements to address


    course, decisions would be required as to the level of taxation and

    whether the capability for autonomous operation would be recorded on

    the DVLA database, in order to provide data on uptake, but that

    seems to be outside the scope of this initial review. Do you have

    any comments on this approach?

    the testing of cars with high automation?

    offer suitable insurance products?

    introduction and testing of driverless cars?

    and privacy, when considering the testing of cars with high automation?

    for driverless cars alongside conventional ones, or (b) support

    creating a special regime via specific regulations to permit the

    testing of driverless cars under certain circumstances or

    constraints? (Or does it not matter as long as the regulations are

    appropriate and clear?)

    to cover the testing of driverless cars with high automation? Do you

    consider any other regulations or aspects of driving practice would

    pose a barrier, or do you consider that extra conditions would need

    to be imposed? Please give full details.  

The Institution of Engineering and Technology Trustees propose submitting a response to this consultation <
<>> and invite comments from Members who have expertise in this area and have studied the consultation documents. In its capacity as a professional body the IET will confine itself to only addressing those questions that are within its area(s) of competence.  

Members contributing are asked to state their relevant experience.All inputs will be treated confidentially in the production of a corporate view and individual contributors will not be named. ?Member? should be interpreted as IET Technician Members, Members and Fellows.  

For more information and a summary of the questions, please refer to the consultation document <

The deadline for response to this consultation is the *_01 September 2014_*. Please send your responses to Sahar Danesh < <mailto:sdanesh_at_xxxxxx mailto:sdanesh_at_xxxxxx  

Full details located here

< <>>.  

For more information and other submissions, please visit our website <

IET Policy  

Michael Faraday House,

Six Hills Way,



SG1 2AY  


Kind regards


Martin Lloyd




Dr M H Lloyd CEng FIET



Tel: +44(0)118 941 2728

Mobile: +44(0)786 697 6840





-------------- next part --------------

An HTML attachment was scrubbed...

URL: <

ents/20140827/ee50ba77/attachment-0001.html> nts/20140827/ee50ba77/attachment-0001.html> ------------------------------ _______________________________________________ systemsafety mailing list <mailto:systemsafety_at_xxxxxx systemsafety_at_xxxxxx <> End of systemsafety Digest, Vol 25, Issue 12 ********************************************
_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Wed Aug 27 2014 - 22:08:35 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST