[SystemSafety] Uber Advanced Technologies Group publishes its "Safety Case Framework"

[Martin, BJ]

Let’s not underestimate that what Uber has now done is set ‘Safety Case’ and graphical notations in the automotive vernacular as a basis for debate and development.

Uber have (belatedly - but without a regulator making them) set a challenge for the other AV developers to be this open and structured, where the rest have only written marketing material about safety values in their voluntary submissions to the NHTSA. I’m not from this industry but have been closely studying the
extant and evolving safety assurance frameworks and culture for the last couple of years as part for national standards and policy work.

Still a long way to go in maturing the accountability of safety in design for the industry.But along with the industry collective publication “Safety First in Automated Driving” from a thread a few weeks back - this is the right track.

Cheers,
--
BJ Martin
Safety and Certification Capability Lead
Nova Systems





From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de> On Behalf Of M A Jackson
Sent: Tuesday, 23 July 2019 11:01 PM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Uber Advanced Technologies Group publishes its "Safety Case Framework"

Control over the fixed infrastructure for AVs is a stronger constraint than is necessary in principle.

Design of any cyber-physical system and its proposed functions and behaviours must rely on assumptions about its operating environment in space and time. In principle, these assumptions must be explicitly articulated and analysed, and assessed for the risk that they may not hold. To give a topical illustration: the Apollo 11 designers had no control over the relevant environment; but they had sufficiently reliable knowledge of the relevant environmental properties and behaviours that could be assumed in the small region of the solar system in which the moonshot would take place.

Cars driven by people can cope with successfully with a wide environmental range—let’s call it E1. For a proposed AV design an explicit statement of the assumed environment E2 (presumably a subset of E1) is a sine qua non. Without this explicit statement announcements like Uber’s ATG Framework have little meaning. Control over the fixed infrastructure certainly makes this explicit statement very much easier. Another approach is strict geofencing in a specialised area. For example, a low-speed AV taxi service has been provided for a retirement community occupying a gated space of a few square miles, where the only road users are pedestrians, golf buggies, and the AV taxis.

— Michael Jackson



> On 23 Jul 2019, at 12:32, Olwen Morgan <olwen at phaedsys.com<mailto:olwen at phaedsys.com>> wrote:
>
>
> On 23/07/2019 03:31, Bruce Hunter wrote:
>
> <snip>
>
> Although it misses the supporting strategy or context, it is good that they have gone public with this but it needs wider scrutiny and judgement against accepted standards.
>
> <snip>
>
> Uber's strategy will, IMO, be largely irrelevant because they do not control the fixed infrastructure in which their AVs will run. Railways have a dedicated infrastructure for trains and aviation has dedicated infrastructures for both civil and military flight. AV's will not be using a dedicated infrastructure and they will be trying to shoe-horn safety into environmental constraints that their designers had no part in setting.
>
> I'm expecting AVs to work safely only where a such infrastructure can be provided, e.g. inter-terminal shuttles at airports or physically separate dedicated lanes on public roads. IMO no amount of in-vehicle technology is going to compensate for hazards arising from the existing design of non-dedicated infrastructure. The likely result, I suspect, will be a series of accidents before people realise that the lack of dedicated infrastructure is the critical problem.
>
>
> Olwen
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
> Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety<https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety>

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety<https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20190729/936188ed/attachment.html>