[SystemSafety] a public beta phase ???

[Peter Bernard Ladkin]

On 2016-07-19 04:50 , Les Chambers wrote:
> ... That's what this journalist has done. 

John Naughton is primarily a systems engineer and academic. I sent him the link to the List archives.

> He says it's okay 33,000 people are killed every year. 

I read the following

[begin quote]
 Even a decade means a further 330,000 avoidable deaths in the US and corresponding numbers in other
countries. ..... do not the potential benefits [of road-vehicle automation, RVA] outweigh the costs
of the current carnage on our roads?
[end quote]

as saying, very clearly, that he's not OK with those figures. I wonder how you can have missed that?

What I am missing from your notes, Les, is any suggestion of criteria which would make RVA of
various sorts acceptable for you. I take it that some RVA is acceptable, because I don't (yet) see
you arguing against ABS or ESP.

And there is a lot of RVA around. Phil made the point that sophisticated RVA is now routinely
available in road vehicles of all sorts, not just Tesla cars.

Martyn and Michael have made the point that there are sophisticated moral questions of agency
involved in some RVA features. Some of them are already known and have been well discussed for half
a century, in the branch of moral philosophy known as trolleyology. There are other features such as
ABS which apparently don't worry us (I have seen no discussion here expressing reservations about
the value of a correctly-functioning ABS). I think it's time to say what is worrisome and what not.
Here's a classification which might help.

[begin classification]

1. There is the question as to whether the kit does what the manufacturer wants it to do. Think
Toyota unintended acceleration, the "kitchen sink" task and Michael Barr's demonstration via fault
injection that the task doesn't always do what Toyota claimed.

2. There is the question whether what the manufacturer wants the kit to do is appropriate. ABS is
apparently OK. ESP is apparently also OK. Automated full control with driver supervisory control is
apparently not.

2a. There has been a criterion around for some time in RVA that driver-assistance is OK, but
automated driving is not. So, cruise control whereby the vehicle maintains a set speed is OK.
Systems to recover traction in a wheel which has lost it during braking or cornering are OK.

2b. Then there are functions which interpret driver intent to some extent. ESP helps with some kinds
of manoeuvres in which it is presumed general driver intent is clear, but it does perform
uncommanded actions in the vehicle control chain (braking a wheel where no brake command has been
issued by the driver).

2c. Then there are functions which perform uncommanded actions for which no driver intent has been
indicated. Such as systems which maintain separation from other vehicles, in particular which will
apply brakes when separation to the same-direction preceding vehicle reduces quickly, even when the
driver has indicated no intent to brake. Or, systems which maintain the vehicle within a specific
lane on a highway; which will steer to hold the lane even when the driver has not indicated a
steering action.

2d. Then there are more sophisticated functions, all the way to automated driving, such as exhibited
by Google self-driving cars at low speed, and Tesla cars at higher speeds.

[end classification]

The notion of "driver intent" is malleable. The Ford Max-S presumably interprets "driver intent" as
wishing to stay within the posted speed limits. A driver driving such a vehicle could well put pedal
to the metal at a traffic light in town in a 30kph zone and should not thereby register an intent to
accelerate to 160kph, although in other vehicles that would be an appropriate interpretation of the
action. Similarly, a failure to command braking when traffic ahead slows down should not necessarily
be interpreted as a desire to perpetrate an auffahr accident; and, even were a driver to have such
intent, there are very good general grounds for inhibiting its execution (the health of the people
in front, for example).

Some functions are more important for road safety than others. There are a couple of fatal or
near-fatal accidents per week on the A2 motorway as it passes by Bielefeld (on the way from
Rotterdam to Moscow). A significant proportion of these are caused when truck drivers fail to slow
when traffic in the lane ahead slows or stops, and ram the end of the line (an auffahr accident). An
automatic same-lane separation-maintenance function installed on all trucks travelling on German
motorways, even if not perfectly implemented, would avoid most of these accidents. There is talk of
mandating it for trucks, in a similar manner to which truck performance recorders and
toll-registration devices are mandated. I think the argument for it is good.

Let me mention again some experiences bicycling in Bielefeld.

In over 60 years of cycling I have had four collisions with cars. All have been in Bielefeld; all
have been when I have been on a marked cycle path or lane and cars have violated that lane.

We drive on the right. On one occasion this year, I was almost killed by a driver overtaking me on
the left as I was performing a left turn (he subsequently went around the wrong side of a traffic
island). Last Saturday, in town in a 30kph zone, I signalled and manoeuvred to perform a left turn
while travelling at 28-30 kph, and the following car tried to overtake me on the left (and then
decided not to).

All six of these dangerous manoeuvres would have been inhibited by simple lane-following functions,
and the last two also by speed-inhibiting functions.

According to the police, a significant proportion of serious road accidents involve violation of
posted speed limits. There is a prima facie safety case for such a function to be mandated on all
vehicles.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160719/de231b48/attachment.pgp>